this post was submitted on 07 Jul 2023
111 points (99.1% liked)

Selfhosted

60970 readers
570 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world
111
How do you keep docker/podman containers up-to-date? (lemmy.world)
submitted 3 years ago by cat@lemmy.world to c/selfhosted@lemmy.world
66 comments fedilink hide all child comments
 

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 are viewing a single comment's thread
view the rest of the comments
[–] mea_rah@lemmy.world 2 points 3 years ago

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.