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/containers.py at main · docker/docker-py · GitHub I see a user attribute in the docker code but no way to set it from prefect/docker.py 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/docker.py? Am I overlooking a simpler solution?
Thanks!
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!
1 Like
nice work, this makes so much sense!