cdk-assets: Improve error message when docker is not installed and CDK_DOCKER is not set.

[vsiravar]

Describe the bug

When docker is not installed and a user wants to use a drop in replacement, if the user does not set CDK_DOCKER=, the error message says "Unable to execute 'docker' in order to build a container asset. Please install 'docker' and try again." https://github.com/aws/aws-cdk/blob/main/packages/cdk-assets/lib/private/docker.ts#L186

Expected Behavior

Error message should inform users about CDK_DOCKER environment variable which can be set to support drop in replacements for docker.

Current Behavior

Error message is very docker specific. "Unable to execute 'docker' in order to build a container asset. Please install 'docker' and try again."

Reproduction Steps

1. Uninstall docker.
2. Clone https://github.com/aws/aws-cdk/
3. yarn install
4. NODE_OPTIONS=--max-old-space-size=8192 npx lerna run build --scope=aws-cdk-lib --scope=@aws-cdk-testing/framework-integ
5. cd packages/@aws-cdk-testing/framework-integ/test/aws-lambda/test && node integ.bundling.js

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.79.1 (build 2e7f8b7)

Framework Version

No response

Node.js Version

v18.16.0

OS

macOS 13.3.1

Language

Typescript

Language Version

No response

Other information

No response

[pahud]

Yes we should add CDK_DOCKER in our document or contributing guide. But at this moment, according to the Setup of the contributing guide, Docker >=19.03 with the running daemon is required.

[pahud]

related to #23680 (comment)

[vsiravar]

Makes sense, should it additionally be added to the error message as well, informing the user to either set CDK_DOCKER or have a docker daemon running when either of the dependencies are not configured?

[athewsey]

Any progress on this? #23680 was closed as completed in Jan, but I keep having customers ask (today also) whether it's possible to use CDK features like PythonFunction, DockerImageFunction, DockerImageAsset with alternative container build/runtimes - because the documentation for these features is so Docker-oriented. The availability of other options feels more like secret magic than a supported solution that Docker-constrained users can find out about.