Solved update Docker container without losing settings?

[chenks]

How do you update a docker container to a new version without losing your config?
There is a newer version of Jackett out and the Docker image has been updated.

I just don't want to lose all the settings and config.

 

[wwwampy]

I always do it like this:

Docker - How to update a Docker container

Open Docker UI: Registry > search for image name you want to update > Download image Stop...

www.synoforum.com

Works without losing the config and settings.

 

[chenks]

excellent!

 

[fredbert]

Um, what do you mean by

I just don't want to lose all the settings and config.

If you mean the config that you used in Docker package to create the new container, but not any of the data inside the container, then you do just download the latest image, stop the container, clear the container, and restart it.

But if there's data within the container that you also want to keep then you should map these locations to NAS folders: it's part of the container config in Docker. Have a look at my tutorial for setting up FreshRSS and PostgreSQL and they both have Volumes tab settings for mapping folders.

You can do this to an existing container by mounting a NAS folder in the container to an unused folder name. You then copy the container folder contents to the mounted folder. Next, stop the container, remap the NAS folder to mount over the actual container folder, and restart the container. You may have to assign environment variables for NAS User ID and GroupP ID that the container will use to write/read the folder's data ... depends on the container itself. Example:

My container has data in /var/myapp and I want to keep this between image updates.

1. Create an NAS folder, say, /docker/myapp
2. Stop the container and add a volume mount from /docker/myapp to /var/myapptemp
3. Restart container and go to the Details/Terminal page of the container, now create a terminal session.
4. In the session cp /var/myapp/* /var/myapptemp, or whatever you need to get it all across to the folder.
5. Stop the container and remap the mount so now it's /docker/myapp to /var/myapp
6. Restart the container.
7. Now you can check if adding a file in /docker/myapp it becomes visible in /docker/myapp

 

[fredbert]

@chenks for a continued discussion on container data and what happens when you 'Clear' to update the image, have a look here Docker volumes vs bind mounts

 

[chenks]

what i meant was, for example.

a new Jackett version was released.
so i wanted to update without losing the config that Jackett has already set.
using the "clear" option gave me the result i was looking for.

all the containers have /config mapped to a folder within a folder called "docker", in this instance /docker/jackett

 

[fredbert]

Ok, good. So you had a bind mount to a NAS folder and that's where your container data is stored.

 

[itsjasper]

You can also use Watchtower to automatically update containers.

 

[Telos]

You can also use Watchtower to automatically update containers.

Automatic update is seldom a good idea. YMMV.

 

[jphermans]

You can also use Watchtower to automatically update containers.

Indeed, this is a really good one to update your containers, but some containers you may not update directly when a update is there otherwise it's not working anymore. An example of such container is unifi controller. That's why I using another update and that's ouroboros. Here you can make lists of what container may be upgraded or not. Link ouroboros.

Automatic update is seldom a good idea. YMMV.

Always good if it's done for you. So you don't have to worry about it.

 

[itsjasper]

For my mind, as one of the benefits of Docker is the ease of which you can recreate containers, it seems a no brainer to allow auto-updates.

I prefer less babysitting and only to have to get involved when things break, because of lack of time and competing demands on time. The notifications tell me when something breaks; and yep, it's happened to me also.

My process is that if the same container breaks twice through Watchtower then it gets excluded. And anything core or critical (e.g. a Unifi controller), I'd exclude from Watchtower on a matter of principle.

I totally get why people prefer to manually update themselves, but it gets old pretty quickly at scale without automation. Not sure why it gets the bad press on forums generally.

How to exclude certain containers for updates: Container selection - Watchtower

 

[fredbert]

I guess in production environments then automatic updates can lead to day 1 bugs.

When patching (not talking about Docker here) then, IME, there is a period of technical validation and also assessment of changes vs implemented/activated features. If there is no change to the features being used then a decision not to update is often taken: a longer running version with known peculiarities being thought better than no useful fixes and potential for new bugs.

Generally I do this for Plex ... the centrally updated package gets released very often (every few days or so it seems). I check what has changed and decide whether to update this time. For instance, recently I've not bother when all changes were for DVR features and again not the very latest that added back support for FreeBSD.

 

[Telos]

I don't need the hassle of failed updates.

I delay Windows updates for 2-3 weeks, to see how they play out. The same philosophy holds for DSM updates (many have been withdrawn), Synology packages, Plex, and Docker.

As a consumer-level user, unless the update resolves a problem I have or offers a feature I'm seeking, updating for the sake of being "updated" is senseless. All my PCs are imaged daily as a minimum.

In a commercial enterprise, updates should be vetted before they are rolled out. Auto-update if you like, but in my experience, it is seldom warranted/recommended.

 

[chenks]

Generally I do this for Plex ... the centrally updated package gets released very often (every few days or so it seems). I check what has changed and decide whether to update this time. For instance, recently I've not bother when all changes were for DVR features and again not the very latest that added back support for FreeBSD.

the problem with that though is small incremental updates can be more "stable" than leaving updates until you end up with a hug version change with multiple changes.

should you get a problem, and with plex you almost certainly will, you will struggle to pinpoint the potential culprit.