Use Case: Run As User

History

Most of the issues my coworkers and I have run into are related to the /run-as-user script used as the container entrypoint. Essentially, this script enables a process that executes to run as a specified UID and GID in the system. This was important in the beginning because all our development work was done in a Linux VM (RedHat) using Docker v1.3 with fig and as an organization we were just learning about Docker and what it was and how it worked.

Because of the fig dependency, and the way the operations team had us using Docker, and the fact that this was really just an added burden to the engineering teams who now needed to support and work with these container things even though their primary job was writing software, everything always executed as root (UID=0). That made it frustrating and difficult to begin to normalize around build tools in our development environment that ran out of containers (as an effort to make the dev environments match our CI process) because all files were always written to the mounted volume as root, causing random issues with other development workflows related to file permissions.

For example, executing a composer install or similar would cause all vendor/ files written to be written as root which is frustrating when you have to edit a vendor file for testing or delete the vendor directory or the dependency managers lock file, etc., because you continuously found yourself having to rerun your last command with sudo.

Solution

Clearly the preferred solution is to write the files out as the current user, so my solution was to create a user in the image to perform that role for me and a script to bootstrap that user. So, a user and group named dev was added to the image.

Because when the dev user is created it's assigned a UID and GID for the image and is unrelated to the host system, and because all of our docker daemons ran as UID 0 we ran all docker and fig (and later, docker-compose) commands with sudo, that wasn't sufficient to write files with unproblematic ownership. Often the files were written as a UID/GID that didn't exist on the host which had most of the same issues as writing them out as root.

To work with that, the run-as-user script was added that would read the UID and GID values of the host directory that was volume mounted into the image (generally at the /src mountpoint) and then modify that dev user with those values via usermod and groupmod. And that script was set as the container ENTRYPOINT and any docker run arguments used were passed to the script resulting in a container command that looks something like

/run-as-user npm install

Because in our dev environments the docker daemons run as root and in order to run docker commands without sudo we simply added our user to the docker group, we didn't have a good way to

created this script was created