I am trying to devise some best practices for containers that should be immutable.
I know that state should mostly be in named volumes, but here I would like some opinions about /etc:
Note that sometimes there is mutability on /etc : For example I have containers where I add users for ssh login (large containers with applications)
Putting /etc on a named volume makes container upgrading hard: If I update something that needs a new /etc configuration file which I did not mutate, then I need to control for that.
Not putting /etc on a named volume means taking explicit control of mutated files there (copying them somewhere and restoring them on container restart.
Any opinions on how to deal with /etc mutability that one wants to store?
Thanks
Could you pass in the users that need to be present at runtime?
docker run -e USERLIST=alice,bob,etc
An entrypoint script could deal with adding those users to /etc/passwd (which could be a symlink to a location backed by an anonymous volume, perhaps)
Others may have better insight than myself on this topic.
That is a very good start thanks. In my case I am also using long running containers that I could add users at runtime. If I kill the container, I would like those users to persist.
I think can actually sort this problem with an external LDAP server, but I think there is a fair use case where one sees partial changes to /etc and wants to persist only those partial changes.
Anytime you want to persist state, you’ll need to have a volume to store it in. The symlink trick might be a nice happy medium to make that work. At the same time, one of the ideas behind immutable infrastructure is that if you do need to change something, you throw away the old instances that have the config that you don’t need, and replace them with instances that do have that config.
I do like the symlink idea. This is what I think I will do:
create a named volume /persist/etc
At the entrypoint see which files are there and create the symlink.
Thanks!