I am currently switching from docker compose to kubernetes. Along with that, I am changing from using the :latest tag on everything to explicit versions.

Now, it’s a lot of work to check all the GitHub pages for the releases and updating.

Is there some kind of dashboard that ideally would show me (per app) the version I am running vs. the current version from GitHub? (With a link to the release notes, while we are at it…).

Or is my workflow wrong to begin with? (Haven’t looked too deep into something like argocd, maybe that’s the answer?)

  • dfense@lemmy.worldOPEnglish
    6·
    6 days ago

    Wow, thanks for all the great answers so far. As for why not latest:

    1. Read a lot online and read multiple times it’s “bad practice”
    2. Own experience: had latest on an app which crashed and wouldn’t come up again. Got the backup of the persistent volume back and then had the problem that latest at that point is not the same as latest when I spun it up. Actually had no idea which version I was running last and consequently what I would need to pull to fit my backup. In case I have to restore my cluster, this problem is multiplied.
    3. I run NixOS on everything, so I am clearly biased towards reproducibility.
    4. I am running Services for family and a fire brigade (nothing mission critical, just support stuff, but still…). Stability is important, as sometimes I do not have the time to immediately react to an issue. I prefer a lazy Sunday morning to update/fix and then leave it alone and stable.

    So, probably a combination of latest for low criticality and pinned on critical stuff (e.g. authentication, access, etc.)

  • bla_bla_bla@feddit.orgEnglish
    2·
    6 days ago

    Any reason why you want to switch to explicit releases? The only containers I use explicit releases on are databases.

  • vegetaaaaaaa@lemmy.worldEnglish
    1·
    5 days ago

    I use RSS feeds, bump version numbers when a new release is out, git commit/push and the CI does the rest (or I’ll run the ansible playbook manually).

    I do check the release notes for breaking changes, and sometimes hold back updates for some time (days/weeks) when the release affects a “critical” feature, or when config tweaks are needed, and/or run these against a testing/staging environment first.

  • just_another_person@lemmy.worldEnglish
    11·
    6 days ago

    When using semantic versioning of anything, it’s an intention to run that specific version. AKA version pinning or locking. Meaning you DON’T want it automatically updating unless you do it manually.

    You especially don’t want this happening in a k8s cluster if you intend to run replicas with pulls enabled for obvious reasons.

    As for being notified of updates, there are some tools out there for this, but I believe they only check for pulling specific tags, or latest tag. The way container registries work wouldn’t make it obvious what exactly you’d want to update, because there is no concept of tag inheritance. This means if a new tag showed up in a repo, you wouldn’t know if it’s an update to your specific current version of aomething, or just another tag. They don’t work like packages in this sense.