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.
How To: Automate version update for your selfhosted Docker containers with Gitea, Renovate, and Komodo
Submitted 1 week ago by tofu@lemmy.nocturnal.garden to selfhosted@lemmy.world
Comments
mbirth@lemmy.ml 1 week ago
uninvitedguest@lemmy.ca 1 week ago
Sounds like your would benefit from using dockcheck.sh for your use case.
daniskarma@lemmy.dbzer0.com 1 week ago
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.
tofu@lemmy.nocturnal.garden 1 week ago
Yeah, if you run
latest, there’s no need for renovate. I don’t thoughspacegoat@lemmy.world 1 week ago
Interesting. 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
daniskarma@lemmy.dbzer0.com 1 week ago
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.
d00phy@lemmy.world 1 week ago
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.
shiftymccool@programming.dev 1 week ago
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
Vorpal@programming.dev 1 week ago
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.
shiftymccool@programming.dev 1 week ago
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
tofu@lemmy.nocturnal.garden 1 week ago
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?
shiftymccool@programming.dev 1 week ago
Komodo is a big topic so I’ll leave this here (komo.do)[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.
johntash@eviltoast.org 1 week ago
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
MangoPenguin@lemmy.blahaj.zone 3 days ago
I just use the built in Komodo update checkbox for each stack. No extra config needed, and for things like postgres that don’t do major version updates very well I pin the major version in the tag.