In previous posts, I’ve talked about some of the things we can do with mounts in dev containers. Another great use for mounts is to make files on the host computer available in the dev container. For example, it’s possible to utilize a mount to make your Amazon Web Service (AWS) credentials and configurations available to your container.
The AWS tools and SDKs expect to find the files in %USERPROFILE%\.aws on Windows and $HOME/.aws on other platforms (as documented
here
). To make the local folder available in the container, we have to mount it to the appropriate location in the container.
The source folder is different depending on the operating system, so we take advantage of the fact that generally only the HOME or USERPROFILE environment variable is available (depending on the OS). Consequently, we can make the container support both platforms by specifying both variables. Because the environment variables are coming from the host platform, we use localEnv to reference them. The complete source path:
${localEnv:HOME}${localEnv:USERPROFILE}/.aws
The destination should be $HOME/.aws, but the dev container’s HOME variable isn’t always available. Consequently, we need to manually specify the folder. For example, on Ubuntu running as root, the path may be /root/.aws.
We will use a bind mount to connect the local file system to the container file system. This will allow changes to be shared between the two. Each bind mount has a consistency. This is specified to minimize performance issues related to maintaining consistency. When we are connecting a Linux container to Windows or Mac hosts, Docker can simply link the two sets of files. Docker supports the following
consistency models
:
- Delegated. The container’s copy of the file system is authoritative. Writes performed in the container may not be immediately reflected on the host. If the container crashes, there is a chance that changes are lost in some circumstances.
- Cached. The host’s view is authoritative. Updates on the host can be delayed before they appear in the container. This is best for high-read processes.
- Consistent. Perfect consistency, where the host and container have identical views at all times. This can have the most severe restrictions to ensure that writes are always synchronized and available.
Since the host is authoritative and high-read, the optimal choice is cached. The final mount configuration looks like this:
1"source=${localEnv:HOME}${localEnv:USERPROFILE}/.aws,target=/root/.aws,type=bind,consistency=cached"Once this is added to the devcontainer.json. you should see the files immediately available the next time you use the dev container.
Happy DevOp’ing!