I used to simply use the ‘latest’ version tag, but that occasionally caused problems with breaking changes in major updates.
I’m currently using podman-compose and I manually update the release tags periodically, but the number of containers keeps increasing, so I’m not very happy with this solution. I do have a simple script which queries the Docker Hub API for tags, which makes it slightly easier to find out whether there are updates.
I imagine a solution with a nice UI for seeing if updates are available and possibly applying them to the relevant compose files. Does anything like this exist or is there a better solution?
You must log in or register to comment.
WatchTower can auto uodate your container or notify you when an update is available, I use it with a Matrix account for notifications
Yes, https://containrrr.dev/watchtower/ is a great tool. Used it myself for a whole now.
I use DIUN (docker image update notifier). You can watch tags with it and it will notify you when updates are available. I have it email me Saturday morning. I like it a lot more than watchtower.
You read breaking changes before you update things, that’s how.
Seriously. All this talk of automatically updating versions has my head spinning!
It kind of depends on what are your priorities. In my experience it’s usually much easier to upgrade to latest version from previous version, than to jump couple versions ahead, because you didn’t have time doing upgrades recently…
When you think about it, from the development point of view, the upgrade from previous to last version is the most tested path. The developers of the service probably did exactly this upgrade themselves. Many users probably did the same and reported bugs. When you’re upgrading from version released many months ago to the current stable, you might be the only one with such combination of versions. The devs are also much more likely to consider all the changes that were introduced between the latest versions.
If you encounter issue upgrading, how many people will experience the same problem with your specific versions combination? How likely are you to see issue on GitHub compared to a bunch of people that are always upgrading to latest?
Also moving between latest versions, there’s only limited set of changes to consider if you encounter issues. If you jumped 30 versions ahead, you might end up spending quite some time figuring out which version introduced the breaking change.
Also no matter how carefully you look at it, there’s always a chance that the upgrade fails and you’ll have to rollback. So if you don’t mind a little downtime, you can just let the automation do the job and at worst you’ll do the rollback from backup.
It’s also pretty good litmus test. If service regularly breaks when upgrading to latest without any good reason, perhaps it isn’t mature enough yet.
We’re obviously talking about home lab where time is sometimes limited, but some downtime usually not a problem.
I use watchtower and hope nothing will break. I never read breaking changes.
When an issue happens, I just search the internet or change the tag to a known working version until the issue is resolved.
I can afford to have my server down for a few days. It’s not critical to me.
I just use docker compose files. Bundle my arr stack in a single compose file and can docker compose pull to update them all in one swoop.
Compose is the best. Way more granular control. And makes migration entirely pain free. Just ran into the case for it. Set it and forget it, use the same compose for updates.
Just so I understand, you’re using your compose file to handle updating images? How does that work? I’m using some hacked together recursive shell function I found to update all my images at once.
There’s plenty of tutorials out there for it. A quick DuckDuckGo search turned up this as one of the first results, but the theory is the same if you wanted to bundle ‘arr containers instead of nginx/whatever. https://www.digitalocean.com/community/tutorials/workflow-multiple-containers-docker-compose
Essentially you create docker compose file for services, within which you have as many containers as you want set up like you would any other compose file. You ‘docker compose pull’ and ‘docker compose up -d’ to update/install just like you would for individual docker container, but it does them all together. It sounds like others in the thread have more automated someone with services dedicated to watching for updates and running those automatically but I just look for a flag in the app saying there’s an update available and pull/ up -d whenever it’s convenient/I realize there’s an update.
This one dockers.
I use podman auto-update command.
I’d also like to see what others use
I originally used this too, but in the end had to write my own python script that basically does the same thing and is also triggered by systemd. The problem I had was that for some reason podman sometimes thinks there is a new image, but when it pulls it just gets the old image. This would then trigger restarts of the containers because auto-update doesn’t check if it actually downloaded anything new. I didn’t want those restarts so had to write my own script.
Edit: but I lock the version manually though e.g. nextcloud 27 and check once a month if I need to bump it. I do this manually in case the upgrade needs an intervention.
I use something called What’s Up Docker to check for docker updates. It integrates nicely with Home Assistant, so I made a card on my server state dashboard that shows which containers have updates available. I’ll check every so often and update my docker-compose files.
I pin versions and stick to stable releases as I want stability. Everything is behind a VPN so I’m not too worried. I check them and update once a week or so.
Auto update with “latest” version tag, and re-pull to a specific previous version if there are problems. Got too many containers to keep up with individual versions
By manually updating the whole thing.
“Gus are you cra–”
Eh, its a good brain exercise.
