use the USER directive #187
Conversation
There was a problem hiding this comment.
LGTM! The entrypoint changes may cause some users to run into issues starting the container with a different command, for example:
$ docker run -it ghcr.io/thelounge/thelounge shThis will now have to be
$ docker run --entrypoint sh ghcr.io/thelounge/theloungeThe release mechanism uses "conventional/semantic" commits to pick up changes for the changelog, so this PR should have a semantic commit message if it is to be included in the changelog. Not sure what the ideal scope would be but I'd suggest using feat: ....
Yes, tried to say as much in the commit message. But that's an anti pattern and I don't really think we should cater to those much. ACK re the convention commit thing, I'll fix that up, sorry, I didn't look at the convention. |
We are currently using a custom entrypoint script. However docker has a built in volume / user approach so we can get rid of this custom approach altogether. The benefit of this is that it just works across the stack and we don't need to teach users to run it with `--user node` and such. Further, using thelounge as an entrypoint means that you don't need to exec to a running container but can just spawn a throwaway container (probably with --rm) when you want to manage users etc. This does have some limitations though if people use bind mounts. Docker doesn't have the ability to auto chown things (podman does, with the U option to -v). So let's suggest named volumes instead (which is better anyways) Existing users should not be impacted, as the entrypoint script did the permission setup for them already, so even the new container should just continue to work. People who manually mess with the container will have to use --entrypoint /bin/sh or such, but they shouldn't treat containers like pets, so breaking that is of no concern.
|
addressed all review comments now I think |
We are currently using a custom entrypoint script. However docker has a built in volume / user approach so we can get rid of this custom approach altogether.
The benefit of this is that it just works across the stack and we don't need to teach users to run it with
--user nodeand such. Further, using thelounge as an entrypoint means that you don't need to exec to a running container but can just spawn a throwaway container (probably with --rm) when you want to manage users etc.This does have some limitations though if people use bind mounts. Docker doesn't have the ability to auto chown things (podman does, with the U option to -v).
So let's suggest named volumes instead (which is better anyways)
Existing users should not be impacted, as the entrypoint script did the permission setup for them already, so even the new container should just continue to work.
People who manually mess with the container will have to use --entrypoint /bin/sh or such, but they shouldn't treat containers like pets, so breaking that is of no concern.