Question Updating Containers directly

[Telos]

Typically updating Docker containers involves downloading an updated image, and re-launching the container.

One of my containers, when launched, phones home and auto-updates itself. So far this has worked without a flaw. I presume though that if I were to restart this container, it would fall back to the image I last downloaded. Is that correct?

Today I noticed that another running container has offered to self-update. Since its underlying image has not yet been updated, I'm wondering about the advisability of permitting the container to self-update. Is there a downside doing this, apart from "losing" the update if the container is restarted?

 

[one-eyed-king]

Even though containers are considered ephemaral/disposable they hold state until they get destroyed.
For instance if you use a docker-compose.yml and change the tag, the old container will be destroyed and replaced with a new one (with a different container id). A container restart does not destroy a container. It is comparible to shutdown and restart of a computer. While a destroyed container is like formating the harddisk and installing the os from scrach.

There is nothing wrong in running updates in a running container. It will write the data in the copy-on-write layer. Though, the prefered approach in the container world is to update the image to a recent version that includes latest os patches. This is what makes linuxserver.io and bitnami images so amazing... they get update evey couple of days.

 

[Telos]

Thank you for that clarification I didn't realize that some of my containers would be self-updating, and I wasn't sure whether to accept or decline. After accepting the update, the container (jdownloader) continues to perform as expected.

I still plan to periodically update containers as features/security upgrades are included.

 

[Seaprobe]

Others, such as Homebridge, have a supported means to provide updated components without needing to destroy and replace the container, and still persist the updates across container destroy/launch.

 

[one-eyed-king]

There is nothing wrong in running updates in a running container.

I didn't think this thru. The answer should have been: it depends!

Lets asume that an application in version x is baked into an image and this application depends on a database.
If the application is updated within the container to version x+1,..., x+n, and one of those updates modify the database schema with breaking changes, so it becomes incompatible with previous versions.. If the you recreate the container and the application is not updated before it starts, you might end up in a non functioning state and have to wait until a new image with least this version of the application gets released.

For instance, the oficial Plex image updates the application version before it starts the pms server. NZBHydra specificly warns (or even disallows?! can't remember exactly) if it is running in a container and auto updates are enabled.

@Saeprobe: then they must store the updates in the volumes.

One more thing: even though I used destroy to describe the removal of a container in my previous post, the correct docker lingo is remove

 

[Seaprobe]

@one-eyed-king yes, homebridge maps to a folder like the typical "/config" and also includes sub-directories for plug-ins. That allows most updates to be done with the container running. Major updates to the core, of course, require the delete container dance.