Description
Describe the feature
The CDK currently provides DockerVolume, provides us the ability to create a bind mount, exposing a file or directory on the host to Docker, in my scenario to a Docker based Lamdba build.
However Docker also provides volumes, which are completely managed by Docker, and independent of the host OS and file system. For any build scenario where there's value in caching assets, a Docker volume is going to be a better, more robust, and more platform independent option than a bind mount.
Use Case
I'm using Gradle to manage builds for my Java Lambdas. I'd like to be able to provide a persistent volume to the Docker based build as /root/.gradle that each build can cache information to, for use by future builds.
I've tried doing this using DockerVolume, which as I understand Docker terminology actually provides us the ability to create a bind mount. The problem I face is the Java 11 bundling image, like most Docker images, runs as root.
So if I try using a bind mount the files written back to the host operating system are owned by root. Having files written to user home directories that are owned by root is a surprising and bad side effect of running a cdk build. And having a build write files to subdirectories of /root also seems surprising and wrong.
Being able to use a Docker named volume is the perfect solution to this caching issue, and any other scenario where caching might be wanted across multiple Docker based builds.
Proposed Solution
It's kind of messy, because the name DockerVolume is already being used for a Bind Mount. Otherwise I'd suggest a new class called DockerVolume.
However as DockerVolume is already defined, I think the cleanest thing would be for the DockerVolume constructor to provide a new parameter, volume_name. host_path and volume_name would be mutually exclusive. If you provide host_path, you get the existing behavior where you get a bind mount. If you provide volume_name, you get a named volume mounted, using the Docker default options.
Docker volumes have a lot of options this suggestion doesn't expose. However once this is implemented, it would be an simple extension to then allow setting of those options, possibly by exposing a volume_options parameter on the DockerVolume constructor.
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
CDK version used
2.26.0
Environment details (OS name and version, etc.)
Ubuntu 20.04 on WSL 2 within Windows 10.0.19044