Docker image update process

Hi

Question… if running a docker image and it’s 3-5 versions behind, the newest.
I can see that I need to stop the docker and remove it, and then install the new one…

My issue/question is… what about the config for the running docker image, is there a way to export that and import it to the new docker image, or do I need to setup the new docker image with the configuration again?

Or is there an other way, to simply update an already running docker image, to newest version and to get the new benefits of it?

BR Thomas

The approach desribed is the way to “update” a container (actualy replace it):
– pull latest image
– remove old container
– create or run new container using the same arguments as the old container

Background info: a container is always based on an exact image (identified by it’s sha256 checksum) - this can not be changed afterwards. That’s why the old container needs to be removed and a new container (based on the new image) needs to be created.

This pretty much depends wether you mapped volumes from the host inside the container to persist permanent data outside the container or not. If done right there is no need to export anyting. If the curent container is configured wrong, things will be way more complicated and chances to lose data are high.

It depends: do you happen to have created your container using a compose file? In that case the whole update procedure would be simply docker-compose pull && docker-compose up -d (note: if persistant data is mapped in volumes!). docker-compose deployments always replace containers where contiguration changes/new images are detected.

I highly recommend to make yourself aquainted with docker-compose if you haven’t already as it will make life much easer.

Note: your OP applies docker terminology, but not in the right way

A docker image is a “fixed template” used to create a container → what you run is a container, not an image and also not “a docker”.
Runtime configuration/persistent data never exists in the image → it only exists in the scope of a container, and if done right the runtime configuration/persistent data is mapped outside the container using volumes to persist this data on the host or on a remote share, if done wrong the data is written directly into the container and will be permanently lost when the container is removed.