bind-mounts: rename the filefrom_jekyll_project

1 files changed, 176 insertions, 0 deletions

diff --git a/_posts/2020-05-06-docker-bind-mounts.md b/_posts/2020-05-06-docker-bind-mounts.md
new file mode 100644
index 0000000..9853331
--- /dev/null
+++ b/_posts/2020-05-06-docker-bind-mounts.md
@@ -0,0 +1,176 @@
+---
+title: 'Docker: bind mounts & file ownership'
+excerpt: Docker + bind mounts + non-root users = pain.
+---
+If you want to:
+
+1. run your Docker service as a user other than root,
+2. share a writable directory between your host and the container,
+
+you're in for a treat!
+The thing is, files stored in the shared directory retain their ownership (and
+by that I mean their UIDs and GIDs, as they're the only thing that matters)
+after being mounted in the container.
+
+Case in point:
+
+    docker run -it --rm -v "$( pwd ):/data" alpine touch /data/test.txt
+
+would create file ./test.txt owned by root:root.
+
+You can fix that by using the `--user` parameter:
+
+    docker run -it --rm -v "$( pwd ):/data" --user "$( id -u ):$( id -g )" alpine touch /data/test.txt
+
+That would create file ./test.txt owned by the current user (if the current
+working directory is writable by the current user, of course).
+
+More often though, instead of a simple `touch` call, you have a 24/7 service,
+which absolutely mustn't run as root, regardless of whether `--user` was
+specified or not.
+In such cases, the logical solution would be to create a regular user in the
+container, and use it to run the service.
+In fact, that's what many popular images do, i.e. [Redis][Redis Dockerfile] and
+[MongoDB][MongoDB Dockerfile].
+
+[Redis Dockerfile]: https://github.com/docker-library/redis/blob/cc1b618d51eb5f6bf6e3a03c7842317b38dbd7f9/6.0/Dockerfile#L4
+[MongoDB Dockerfile]: https://github.com/docker-library/mongo/blob/5cbf7be9a486932b7e472a39e432c9a444628465/4.2/Dockerfile#L4
+
+How do you run the service as regular user though?
+It's tempting to use the `USER` directive in the Dockerfile, but that can be
+overridden by `--user`:
+
+    $ cat Dockerfile
+    FROM alpine
+    
+    RUN addgroup --gid 9099 test-group && \
+        adduser \
+            --disabled-password \
+            --gecos '' \
+            --home /home/test-user \
+            --ingroup test-group \
+            --uid 9099 \
+            test-user
+    
+    RUN touch /root.txt
+    USER test-user:test-group
+    RUN touch /home/test-user/test-user.txt
+    
+    CMD id && stat -c '%U %G' /root.txt && stat -c '%U %G' /home/test-user/test-user.txt
+
+    $ docker build -t id .
+    ...
+
+    $ docker run -it --rm id
+    uid=9099(test-user) gid=9099(test-group)
+    root root
+    test-user test-group
+
+    $ docker run -it --rm --user root id
+    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
+    root root
+    test-user test-group
+
+I suppose that's the reason why many popular images override ENTRYPOINT, using
+a custom script (and `gosu`, which is basically `sudo`, I think) to forcefully
+drop privileges (for example, see [Redis][Redis entrypoint],
+[MongoDB][MongoDB entrypoint]).
+
+[Redis entrypoint]: https://github.com/docker-library/redis/blob/cc1b618d51eb5f6bf6e3a03c7842317b38dbd7f9/6.0/docker-entrypoint.sh#L11
+[MongoDB entrypoint]: https://github.com/docker-library/mongo/blob/5cbf7be9a486932b7e472a39e432c9a444628465/4.2/docker-entrypoint.sh#L12
+
+Now, what if such service needs persistent storage?
+A good solution would be to use Docker volumes.
+For development though, you often need to just share a directory between your
+host and the container, and it has to be writable by both the host and the
+container process.
+This can be accomplished using _bind mounts_.
+For example, let's try to map ./data to /data inside a Redis container (this
+assumes ./data doesn't exist and you're running as regular user with UID 1000;
+press Ctrl+C to stop Redis):
+
+    $ mkdir data
+
+    $ stat -c '%u' data
+    1000
+
+    $ docker run -it --rm --name redis -v "$( pwd )/data:/data" redis:6.0
+    ...
+
+    $ stat -c '%u' data
+    999
+
+As you can see, ./data changed its owner from user with UID 1000 (the host
+user) to user with UID 999 (the `redis` user inside the container).
+This is done in Redis' ENTRYPOINT script, just before dropping root privileges
+so that the `redis-server` process owns the /data directory and thus can write
+to it.
+
+If you want to preserve ./data ownership, Redis' image (and many others)
+explicitly accomodates for it by _not_ changing its owner if the container is
+run as anybody other than root.
+For example:
+
+    $ mkdir data
+
+    $ stat -c '%u' data
+    1000
+
+    $ docker run -it --rm --name redis -v "$( pwd )/data:/data" --user "$( id -u ):$( id -g )" redis:6.0
+    ...
+
+    $ stat -c '%u' data
+    1000
+
+Sometimes `--user` is not enough though.
+That specified user is almost certainly missing from container's /etc/passwd,
+it doesn't have a $HOME, etc.
+All of that could cause problems with some applications.
+
+One scenario I had to deal with is making an image that bundles all the gems
+(and a specific Ruby version) for my Ruby web application.
+That application shouldn't be run as root, but it must be able to pick up code
+changes on the fly, and I should be able `docker exec` into the container,
+update the dependencies (along with Gemfile[.lock], and those changes should be
+reflected on the host without messing up file metadata), and restart the app.
+It's quite easy to install the dependencies in the Dockerfile, but they (along
+with the mapped Gemfile[.lock]) should be writable by the user running the
+service.
+The solution often suggested is to create a container user with a fixed UID
+(that would match the host user UID).
+That way, it would be able to update the dependencies stored in the container,
+as well as write to the bind mount owned by the host user with the same UID.
+Additionally, file ownership info would be preserved on the host!
+
+We can create a user with a fixed UID when
+
+1. building the image (using build `ARG`uments),
+2. first starting the container by passing the required UID using environment
+variables.
+
+The advantages of creating the user when building the image is that we can also
+install the dependencies in the Dockerfile, thus eliminating the need to
+rebuild them for every other application.
+The disadvantage is that the image would need to be rebuilt for every user on
+every machine.
+
+Creating the user when first starting the container has the advantage of not
+requiring image rebuilds.
+But, as the dependencies need to be installed after creating the user, you'd
+have to waste resources by installing them for every user and every app on
+every machine (each time when creating a container).
+
+For my project [jekyll-docker] I opted for the former approach, making sure the
+`jekyll` process runs with the same UID as the user who built the image (unless
+it was built by root, in which case it falls back to a custom UID of 999).
+
+[jekyll-docker]: https://github.com/egor-tensin/jekyll-docker
+
+Useful links
+------------
+
+* [Docker and \-\-userns-remap, how to manage volume permissions to share data between host and container?](https://stackoverflow.com/q/35291520/514684)
+* [What is the (best) way to manage permissions for Docker shared volumes?](https://stackoverflow.com/q/23544282/514684)
+* [Handling Permissions with Docker Volumes](https://denibertovic.com/posts/handling-permissions-with-docker-volumes/)
+* [File Permissions: the painful side of Docker](https://blog.gougousis.net/file-permissions-the-painful-side-of-docker/)
+* [Avoiding Permission Issues With Docker-Created Files](https://vsupalov.com/docker-shared-permissions/)