It's a feature for a multi-tenant deployment if you use user remaps. Maybe you only allow specific tenant containers with tenant specific uid/gid.

1. Nope, they are not pre-baked. They are built at runtime from env vars on each machine. 2. One step, setting up two vars. They can be set by a build script. Lots of things have build scripts way more complicated than this.

The only tedious thing is you have to adapt this for every image type you run.

> The only tedious thing is you have to adapt this for every image type you run.

The tedious thing is that this escalates into complexity whenever you have to deal with K developers using M projects developed by N teams each using a different way to handle this:

Do I need to set USERID for project foo, or UID? Does it default to 1000 or the author's UID? Oh, someone has a problem with our project, did they remember to set COMPANY_USERID in their bashrc? Oh, wait, they're using zsh, how do you do that there? Oh, but they followed this other project's readme and that set COMPANY_USERID but not COMPANY_GROUPID...

Docker is supposed to simplify this by unification and a limited API surface, and applying hacks like this on top kind of kills that whole premise.

> Do I need to set USERID for project foo, or UID? Does it default to 1000 or the author's UID? Oh, someone has a problem with our project, did they remember to set COMPANY_USERID in their bashrc? Oh, wait, they're using zsh, how do you do that there? Oh, but they followed this other project's readme and that set COMPANY_USERID but not COMPANY_GROUPID...

You set it to the output of id -u and id -g. It's two lines. There are definitely lots of things more complex when dealing with docker than this.

You provide the team with a script containing those two lines and a docker-compose wrapper and you're set.

Of course it would have been better not to have to care about these things, but hey, at least you're not installing and configuring 4-5 services to bootstrap an application.

If you have to build it on each machine, I would not consider that easily/universally distributable. One of the key points of Docker is you can build once (in your CI or someone else's) and run it on any machine. I think that was GP's point.

Sure, great, let me just rebuild all my docker images on every single machine they run on thereby completely defeating the point of having images in the first place.

You start from a base image of your choice. You only build the user replacement part.

You run docker-compose build ONCE and you're set. On my machine, it takes five seconds.

Heck, you can even run docker-compose build everytime you start the application, it will use the cached build and take less than one second.

---

Correction: the docker-compose up -d takes care of the build process the first time it runs.

Literally, it takes more to complain about the issue than build the image ONCE.

And reproducibility goes straight out the window. And how do you even interop this with kubernetes?

The solution is for docker-compose (or plain docker).

I don't think the reproducibility is out. It's the same app, the same image, the same intended user, you just inject, once, the local user and group ids.

but that _requires_ you to build-at-runtime, which is sometimes not the best way to deploy a docker app. if you have one app that you want to run on many nodes, you'll want to set up a docker registry and have the nodes pull pre-built images.

Of course, but really only build once on every machine. The subsequent starts use the cached build, even after reboot.

In fact, docker-compose up -d takes care of the build thing by itself. It's a five second tradeoff for the lifetime of the application.

For anyone that uses immutable infrastructure where servers’ configuration is never once built and subsequent deployments result in replacement with entirely new VMs, building once per machine still happens every time there is a deployment. You don’t ever reboot these machines.

In environments where vulnerability scanning of docker images used is important, running anything in production that isn’t stored in a docker registry kind of breaks things.

This approach also won’t work with container orchestrators like Kubernetes, ECS, Lambda, CloudRun, etc.

Where I can see doing a docker build of a small layer that just sets file perms potentially being useful is for container based dev environments to be ran on laptops and workstations.