I’ve just set WatchTower to one-shot runs and whenever I have some time to fix eventual issues, I start the WatchTower container, it’ll pull any updates and stop again. No need to mess with my compose files (all set to
latest) and no need for pull requests or similar.Sounds like your would benefit from using dockcheck.sh for your use case.
This. Except for a few projects that have given me headaches for an automatic update before (I’m looking at you Jellyfin). Those I have them locked to a version and only upgrade when I think it’s truly stable (spoiler: stable release was not stable) and when I know I will have time to fix things that may broke.
Yeah, if you run
latest, there’s no need for renovate. I don’t thoughInteresting. Can you clarify what you meant by one-shot runs?
I have watchtower running all the time, would it be worth it/is it best practice to stop it
If I understood correctly, he manually runs watchtower to poll rather than leaving it running all the time. What wasn’t clear to me was if he has it doing the updates (evidenced by him saying he cleans up where needed after) or just pull down the updated images and he then manually restarts/rebuilds the container.
I leave it running all the time and it only updates at something like 03:00. The only containers I don’t have set to latest are DBs as major updates tend to break things.
Yes, I’ve set
WATCHTOWER_RUN_ONCEand run it manually (letting it download and automatically apply the updates) when I find time. In the rare case something breaks, I can fix it immediately or roll back the broken container by setting the label to the previous version.Thank you. Side question:
Still a docker noob. I find I have a lot of orphaned images. What do people normally do, schedule a purge or just prune them manually every once in a while?
I don’t know fully what’s they are doing. But here’s my workflow with watchtower.
I have a cron task that runs watchtower every day on monitor-mode and only-once one time a day. That creates a list on what containers can be uograded. They using shourrr (it’s already integrated with watchtower it’s just an environment variable to do this) I send myself a message to my phone informing me of what updates are available. If I see fit to upgrade everything I just run watchtower once without monitor mode to upgrade all. I have pendant to automate this last part in a way that I just answer to the bot that’s informing me of the updates and should apply the command without having me ssh into the server. But as for now I have to ssh and run a script I have at hand to launch the upgrade with watchtower.
There are some problematic containers that I don’t want to upgrade this way. For those I have their compose files version locked and I upgrade them manually when I want.
Not sure why Renovate is necessary when Komodo has built-in functionality to update Docker images/containers. I wish there was an option to check less often (like once a day), maximum time is hourly.
Also, if you’re using Komodo and have one big repo of compose files, consider just saving your entire config toml to a repo instead. You end up with something akin to Terraform or Cloudformation for your Docker hosts
I haven’t used Komodo, but would it commit to the updated docker files to git? Or just use the “latest” tag and follow that? In the latter case you can’t easily roll back, nor do you have a reproducible setup.
I guess I don’t get that granular. It will respect the current docker compose image path. So. if you have the
latesttag, that’s what it will use. Komodo is a big topic: https://komo.do/That seems like a really big downside to me. The whole point of locking down your dependencies and using something like renovate is that you can know exactly what version was used of everything at any given point in time.
If you work in a team in software, being able to exactly reproduce any prior version is both very useful and consider basically required in modern development. NixOS can be used to that that to the entire system for a Linux distro (it is an interesting project but there are parts of it I dislike, I hope someone takes those ideas and make it better). Circling back to the original topic: I don’t see why deploying images should be any different.
I do want to give Komodo a try though, hadn’t heard about it. Need to check if it supports podman though.
I use it in a homelab, I don’t need to apply prod/team/high-availability solutions to my Audiobookshelf or Mealie servers. If an upgrade goes wrong, I’ll restore from backup. Honestly, in the handful of years I’ve been doing this, only one upgrade of an Immich container caused me trouble and I just needed to change something in the compose file and that was it.
I get using these strategies if you’re hosting something important or just want to play with new shiny stuff but, in my humble opinion, any extra effort or innovating in a homelab should be spent on backups. It’s all fun and games until your data goes poof!
I haven’t used Komodo yet, does it change the compose files in the repo as well? I thought it’s just reading, not writing. Personally I like the workflow of Merge Requests that Renovate provides.
Not sure what you mean with the second paragraph. Which config toml?
Komodo is a big topic so I’ll leave this here: komo.do.
In a nutshell, though, all of Komodo is backed by a TOML-based config. You can get the config for your entire setup from a button on the dashboard. If have all of your compose files inline (using the editor in the UI) and you version control this file, you can basically spin up your entire environment from config (thus my Terraform/Cloudformation comparison). You can then either edit the file and commit, which will allow a “Resource Sync” to pick it up and make changes to the system or, you can enable “managed mode” and allow committing changes from the UI to the repo.
EDIT: I’m not really sure how necessary the inline compose is, that’s just how I do it. I would assume, if you keep the compose files in another repo, the Resource Sync wouldn’t be able to detect the changes in the repo and react ¯\_(ツ)_/¯
I’ve never seen komodo before, it seems like a cool project. If it supported moving workloads between servers, I’d probably consider switching away from k8s to it to have something simpler
