I wrote a very simple right-to-the-point Docker introduction post if you’re new to Docker.
If you want to see your code changes applied right away to a running Docker container, you need to make sure to run the container using the share volumes tag: -v
(or --volume
).
The -v tag expects as a parameter the host path, followed by colon (:), followed by the destination path inside the container:
-v /home/projects/my-app:/src
The parameter above will bind your local /home/projects/my-app
directory to the container’s /src
directory. That means that all changes you make to the files under /home/projects/my-app
will be accessible in the container’s /src
folder, allowing you to execute or inspect the code there in /src
.
You use the -v
tag when you first run the container:
$ docker run -v /home/projects/my-app:/src -it ubuntu bash
The line above starts a container running ubuntu, giving you access to the command line (the -it
and the bash
parts) and binds your local path /home/projects/my-app
to the container’s /src
That’s very useful but you might run into a problem where after starting the container, you try to make changes to the code in your text editor and when trying to save the changes, there’s a permission error message.
This post explains why this happens in great detail but the gist of it is that Docker runs the container as root so all its files belongs to root and your user in your local host is not the same user (even if your user has root privileges!). So when you try to save the changes locally, the container goes “whoa, whoa, whoa, watcha doin’ there?”
Here’s how to fix the volume sharing permission in docker: you tell Docker to run the container as the host’s current user. To accomplish this use the -u
or --user
tag:
--user $(id -u):$(id -g)
There are a few things happening here. This parameter is telling the user tag to:
- get the current user’s UID (user ID)
id -u
- wrapped in a shell resolver
$()
- tell the container
:
- to get the current user’s GUID (group ID)
id -g
- wrapped in a shell resolver
$()
The end result is that now the Docker container will run as the current host user and will therefore have the same permissions inside and outside the container. Voilà!
Reference:
The post Docker for development: make local files visible to a container with volume mapping was originally published at flaviabastos.ca