Why this complicated setup? Komodo handles auto update by itself. It also update the whole stack at once, so no shutdown of the BD while the app stays up. Just have 2 checkboxes to tick.
The less stuff the better, it’s essential in case you have a failure. I only have to redeploy komodo, then all my stacks will be ready to get back online. I even removed watchtower.
Your comment is spreading false information. With the stable release the Immich team has committed to no breaking changes except for major version upgrades, so if you pin to 2.x.x you will be perfectly fine
I use rsync to backup, I can delete and restore the whole drive if i want at any time.
I use watchtower to keep things updated. If you schedule the rsync and watchtower correctly, you can get the backup done before the upgrade and there’s basically no lost data with the rollback.
I use uptime Kuma for monitoring, and it shoots me an email with details on what failed.
OpenMediaVault does this as well if you use the built in Docker system. I have it set to back up containers every Sunday at 1 am, at which time it pulls any new images. You can set the number of backups to retain and roll back if there are any issues.
I’ve been doing this in my kubernetes cluster since immich was less than v1.49.0 (that’s the earliest I can find but it’s been over 4 years).
Your comment could have been more constructive: something like “this is really cool, just be sure you don’t auto merge PRs without reading the patch notes. Learn about the process before you roll this out to your mission critical systems!”
This is a learning opportunity (possibly even for you). Show others how to do things well and the whole community can benefit.
I’ve been running this setup for a few months now and haven’t looked back. Works super well, and essentially acts as an approval process for letting a container update or not.
The author also recently added a followup article to this one for using Forgejo instead, made migrating the setup super easy.
I’m not familiar with Watchtower, I assume it will restart the container/stack if a new image is found. The biggest difference is that an edit to the git repo causing the container to be redeployed. This means the git repo becomes the source of truth and its possible to redeploy even when config changes get merged.
Gitops is your friend
https://nickcunningh.am/blog/how-to-automate-version-updates-for-your-self-hosted-docker-containers-with-gitea-renovate-and-komodo
Why this complicated setup? Komodo handles auto update by itself. It also update the whole stack at once, so no shutdown of the BD while the app stays up. Just have 2 checkboxes to tick.
The less stuff the better, it’s essential in case you have a failure. I only have to redeploy komodo, then all my stacks will be ready to get back online. I even removed watchtower.
Which isn’t a great idea with all the breaking changes. I’d assume it gets better after v2, but still.
Your comment is spreading false information. With the stable release the Immich team has committed to no breaking changes except for major version upgrades, so if you pin to 2.x.x you will be perfectly fine
That’s what I thought, but last time I looked I only saw a “release” tag, no “v2” tag. Did I miss something?
I automate my upgrades, but I also automate my backups, and monitoring.
If an upgrade breaks something, my health monitor lets me know and I can roll back to the previous day.
What tools do you use for the monitoring, backup and rollback?
I use rsync to backup, I can delete and restore the whole drive if i want at any time.
I use watchtower to keep things updated. If you schedule the rsync and watchtower correctly, you can get the backup done before the upgrade and there’s basically no lost data with the rollback.
I use uptime Kuma for monitoring, and it shoots me an email with details on what failed.
OpenMediaVault does this as well if you use the built in Docker system. I have it set to back up containers every Sunday at 1 am, at which time it pulls any new images. You can set the number of backups to retain and roll back if there are any issues.
This is the way
I’ve been doing this in my kubernetes cluster since immich was less than v1.49.0 (that’s the earliest I can find but it’s been over 4 years).
Your comment could have been more constructive: something like “this is really cool, just be sure you don’t auto merge PRs without reading the patch notes. Learn about the process before you roll this out to your mission critical systems!”
This is a learning opportunity (possibly even for you). Show others how to do things well and the whole community can benefit.
You sound condescending af.
This is a learning opportunity (possibly even for you)
Hey everyone has a learning opportunity. Some even have a separate production system!
Did you learn anything?
I’ve been running this setup for a few months now and haven’t looked back. Works super well, and essentially acts as an approval process for letting a container update or not.
The author also recently added a followup article to this one for using Forgejo instead, made migrating the setup super easy.
This looks a lot more complicated that Watchtower. Is this something different or add other functionality?
I’m not familiar with Watchtower, I assume it will restart the container/stack if a new image is found. The biggest difference is that an edit to the git repo causing the container to be redeployed. This means the git repo becomes the source of truth and its possible to redeploy even when config changes get merged.