• MangoPenguin@lemmy.blahaj.zoneEnglish
    2·
    1 month 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.

  • mbirth@lemmy.mlEnglish
    1·
    2 months ago

    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.

    • spacegoat@lemmy.worldEnglish
      0·
      2 months 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.comEnglish
        1·
        2 months 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.

  • shiftymccool@programming.devEnglish
    0·
    2 months 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.devEnglish
      1·
      2 months 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.devEnglish
        01·
        2 months ago

        I guess I don’t get that granular. It will respect the current docker compose image path. So. if you have the latest tag, that’s what it will use. Komodo is a big topic: https://komo.do/

        • Vorpal@programming.devEnglish
          0·
          2 months ago

          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.