firstrun file at /
Closed this issue · 9 comments
The container always thinks it's starting as firstrun, which makes sense considering the file is baked into the image on /.
Should it not be moved into backuppc's config or home directory, so it can properly be removed after the actual first run, and stay removed? 😄
Probable cause why this hasn't been caught yet: to really adhere to Docker's principle of stateless, we remove the container every time it is restarted, which unfortunately isn't default.
Using the 4.3.0-2 image.
In fact, this is not what is happening. When the container is starting for the first time, the file will be here, because it is in the associated image. So the first run logic in the entrypoint will be executed, leading at the end to the file be deleted.
So this logic will not be run again for this container. Meaning that stop/start will not run this logic.
However, if the container is recreated for any reason, the logic will be executed again.
The main purpose here, is to ensure that backuppc installation is executed when the version of backuppc is upgraded, as an upgrade implies a recreation of the container. By this way, if backuppc maintainers decide to make some upgrade, on the directory layout, or the configuration file for instance (that are, obviously, persisted beyond container lifetime), theses changes will be applied seamlessly with the upgraded container.
It is how in particular I allow people to dockerize easily an existing backuppc 3.x instance, something that seems to be very popular!
That is very fair, however I'm not sure the correct approach.
The idea is awesome, but I think it can be executed differently to allow re-creation of containers (which, IMHO, should definitely be how it is).
One solution I can immediately think of is to put an extra variable in config.pl with a string (e.g. the version number or commit hash of the image) and put a similar variable in the entrypoint script. If they match, firstrun is not executed, and vice versa.
If you're OK with something like this, I can work on a PR tomorrow.
Do you mean there is a problem with my current approach? Is it a problem that backuppc is reinstalled on a container whose the persisted content is of the same version that this new container?
Why, yes. As it is now, with the firstrun file in the container being deleted, the container isn't disposable. Containers in general should be ephemeral/disposable, as that's kinda the concept of them 😄
You can find many sources on the web that recommend to make containers disposable. Here's one example, and another.
We run all of our containers with the --rm flag, and a puppet module we use defaults to the same.
OK. I see your point, and I agree that putting a state in the container in the form of this /firstrun file violates the principle of disposable containers. It was a convenient trick to avoid unnecessary reprocessing in the docker.
But if I follow this logic, we should do the contrary of what you are proposing, I think. Indeed, at start (either after creation or later), the container should never assume any existing state, so it should execute all the installation logic each time.
Otherwise, everything that the container does for its startup is closely coupled to the persisted volumes attached to it.
Sounds good!
At least, for the most part. I am not sure if changing the config.pl on every start up is desirable behaviour (as that one is stored in a volume). Our config management tool (puppet) isn't particularly fond of that either :)
For one, I think we can replace localhost with a variable here, maybe an idea to just read /etc/hostname and recommend setting the container's hostname with docker run --hostname.
Now I'm not sure how to handle this (or if this is even normal behaviour), but the CgiUserConfigEdit variable in config.pl also gets modified each time... I'll probably need to look into this further, though.
This is fixed now? It's ok that my config.pl and my htpasswd get overwritten every time with unsafe default settings just because I run docker-compose up -d, without even a chance to set an envvar like DONT_OVERRIDE_CONFIG?