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?
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.
Sorry if it’s obvious, but I don’t see a way to use Matrix for notifications on their documentation and my searching is coming up blank. Do you by chance have a tutorial for this?
Here is how I did it:
docker run -d \
--name watchtower \
-v /var/run/docker.sock:/var/run/docker.sock \
-e WATCHTOWER_NOTIFICATION_URL=matrix://username:password@domain.org/?rooms=!ROOMID:domain.org \
-e WATCHTOWER_NOTIFICATION_TEMPLATE="{{range .}}[WatchTower] ({{.Level}}): {{.Message}}{{println}}{{end}}" \
containrrr/watchtower
Edit: I created a pull request to the WatchTower documentation, here: https://github.com/containrrr/watchtower/pull/1690
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.
Since my “homelab” is just that, a homelab, I’m comfortable with using :latest-tag on all my containers and just running docker-compose pull and docker-compose up -d once per week.
This is mostly my strategy too. Most of the time I don’t have any issues, but occasionally I’ll jump straight to a version with breaking changes. If I have time to fix I go find the patch notes and update my config, otherwise I just tag the older version and come back later.
I’ve recently been moving my containers from docker compose into pure ansible though since I can write roles/playbooks to push config files and cycle containers which previously required multiple actions on docker compose. It’s also helped me to turn what used to be notes into actual code instead.
The beer way I’ve found is to wait till something breaks. Message around on forums asking why I’m getting errors till someone recommends update and restart.
Blindly Remove the docker. Recreate.
And hope none of the configs break. ✌️💛
You read breaking changes before you update things, that’s how.
Seriously. All this talk of automatically updating versions has my head spinning!
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.
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.
It depends on the project. If the project doesn’t make an effort to highlight them I would consider using a different one.
But any decent OSS will make a good change log for their updates that you can read.
I’ve just been updating my containers every week or so and if something breaks I’ll try and fix it. It would definitely be preferable to “fix” in advance, but with enough containers getting updated, checking/reading every change becomes a fair amount of work. Most of the time nothing breaks.
Downvotes are cool but if this is a bad way of doing things just tell me.
