Setting Docker user for flow

I have my flow running in a Docker container on my laptop, thanks to the prefect blog. On the server I want the flow to run as a particular non-root user to limit the amount of code running as root. Outside of prefect I do this with the compose.yaml user attribute.

Poking around in docker-py/ at master · docker/docker-py · GitHub I see a user attribute in the docker code but no way to set it from prefect/ at main · PrefectHQ/prefect · GitHub .

I can run the agent as a non-root user and grant it access to communicate with the docker socket but pretty sure the flow is then running as root. Setting a non-root user in the image is complicated because the host and container can easily have different numeric uids. How hard is it to add a user attribute to prefect/infrastructure/ Am I overlooking a simpler solution?


1 Like

A simple (and recommended) solution is to run the agent process outside of Docker - e.g. running it in a conda environment pointing to your PREFECT_API_URL. Otherwise, it can get complicated and lead to issues of running docker in docker

I am running the prefect agent as a system service, non-root user outside of Docker in a python virtual env. At first I tried deploying the flow code with LocalFileSystem but ran into issues with permissions or missing dependencies or something where I ended up copying files manually to get it working. I had the flow running with the right user without Docker but pushing new code was going to be messy. I decided to try making a Docker image for deploying my code instead of debugging the mess. Now I’ve solved the deploy problem with dockerhub and I want to set the user in the container that runs the flow.

you can set user as follows in a Dockerfile:

USER 1000:1000

True, though it’d be nice to not bake the numeric user id into the docker image so I can run the same image in a dev environment and in production. I’d like the code in the container running as the same user as the agent.

You can have a user 1000 in a production image as well - I may not know enough to help you here but I don’t see any downsides, perhaps you can teach me that

You may get better advice on that here:

I’m pretty sure that if the docker image has a numeric user id the container will use that id, which is fine as long as it doesn’t interact with the host. I got myself into a pickle because the container writes to a volume mounted on the host filesystem. The directory on the host is owned by www-data so the container needs to run as the host’s www-data, whatever user id that happens to be.

I found a different solution: I created a deploy that runs the flow in a local process and am running the agent in a container as the www-data user, specified in compose.yaml. This avoids the container in container complication and lets me update the agent and flow by pushing a new docker image.
Thank you for offering some other solutions to consider!

nice work, this makes so much sense!