2

I'm configuring a docker container for development purposes with the intent to re-configure it (minimally) for k8s cluster deployment. Immediately I run into the issue of user permissions with volume mounts to my local source directory.

For deployment to the cluster I will bake my source directory into the image, which is really the only change I would want to make for deployment.

I've read many SO articles suggesting running as your local user/group id (1000/1000 in my case).

But all of those questions seem to glance over a seemingly critical detail. When you use --user to alter your user ID within the docker container you lose root, and along with it a lot of functionality, for example whoami doesn't work. It seems to become very cumbersome to test configuration changes in the docker environment, which is common during development.

The options for developing directly into the docker container seem very limited:

  • Add user/group 1000/1000 to the docker image, which seems to violate the run-anywhere mantra of docker/kubernetes.
  • chown all your files constantly during development and use root in the container.

Are there other options to this list that is more palatable for developing directly into a docker container?

David Parks
  • 30,789
  • 47
  • 185
  • 328
  • 1
    I belive the reason why `whoami` doesn't work is because your process can't find the username/group for the user Id you've specified. If you mount the following two files, `whoami` should work, I believe: `-v /etc/passwd:/etc/passwd -v /etc/group:/etc/group` – mandark Jul 21 '19 at 11:48
  • That seems to improve things, I still have the overarching question about workflow though. The Dockerfile installs everything as root by default, my user can access most of it, but can't change configurations easily. I can log into the container as root whenever configuration changes are necessary. This usually involves validating some process runs then updating the Docker file and is less common than code changes, so the extra login might be ok. Then when I burn a tagged release into the image everything will just run as root at that point. This seems like a reasonable workflow. – David Parks Jul 21 '19 at 16:57
  • After mulling this over longer it seems that the correct approach is to create a user in the container and build application processes as that user. While developing you need to map the docker uid (1000 in most defaults) to your development desktop uid. In my case I'm conveniently 1000, so I can bypass this step, but this page appears to describe the process: https://docs.docker.com/engine/security/userns-remap/ if someone understands the process and can provide a detailed answer that would still be quite helpful. – David Parks Jul 22 '19 at 17:48

0 Answers0