Fail early if Docker daemon is not available

[clstokes]

When using the Docker provider in a large deployment (e.g. aws-ts-thumbnailer), a Pulumi update can get pretty far along before failing on the Docker image build because the Docker daemon is not running or unavailable. This leaves the user and the update in an awkward state - best case they start docker and continue, worst case they have to install docker which can be a hassle depending on the platform.

Can the docker provider do a check as a part of the preview to determine if the environment is ready to go? This seems similar to the aws provider checking for credentials.

[lukehoban]

Note that to do this properly probably requires #132 so that we can fail at provider configuration time.

My suggestion would be to invest time in that issue instead of trying to patch things like this - as that will address a broad range of issues with the current implementation of this.

[stack72]

Ok, I am going to leave this to be part of #132 so will move it outside of 0.32

[AaronFriel]

There are a couple reasons I'm inclined to close this as by-design:

First, Pulumi does not eagerly instantiate default providers at application start; default providers are initialized on demand. The Image resource - or any other - will be created at approximately the same time as the provider.

Second, when we connect to the daemon, we don't know what the user will ask of that daemon to do. Particularly as we move to support cross platform builds (#471), not all Docker Engine daemons are configured for cross platform builds (with binfmt using QEMU). The platform field of an Image resource can cause a build to fail at the point of performing the build.

This issue is analogous to deploying a resource to Kubernetes. Moving kube-api-server detection into the provider create is insufficient to determine if resource creates will fail due to Kubernetes version or installed CRDs, and for most workflows the resource create occurs moments after the provider.

[AaronFriel]

We're going to look at #51 to ensure the Docker Image resource uses provider config if possible. That may provide some degree of detection, however we cannot address this issue generally by design.