3 ms·
It’s very nice to have the option for auto update, but in reality would anyone wants their containers to auto deploy newer versions? Aside from the security ex
by meitham 4y ago
It’s very nice to have the option for auto update, but in reality would anyone wants their containers to auto deploy newer versions? Aside from the security exposure (specially if you were on a Scandinavian’s holiday) there is the risk of backward incompatibility such as changes around config, db migration, cli arts or anything else the container might consume but sits outside the container!
- Arnavion 4y agoUsing it with `:latest` is going to have the problem you described and is not the expected usage. It's more feasible to use it with a release line tag, like `postgres:15`, where you expect updated images to be backward-compatible. Alternatively, one place where `:latest` would make sense is if they're your images, and you're relying on podman-auto-update to update a fleet of servers to start running the latest version of a service as soon as you push the new image.
- config_yml 4y agoHow do people automate this kind of thing, like rolling out a specific image via CI? Generating the systemd files, copying via scp and systemd reload via scripted ssh?
- txtsd 4y agoI would like to know this too. Is it stored in a dotfiles-like repo, then cloned, and `stow`ed?
- zokier 4y agoI imagine Ansible could take care of the grunt work here, or something else like it
- nine_k 4y agoCome on, scp :) Ansible / salt / puppet, etc would do this for you in a nicer way. Or maybe Nomad. Or k8s + ArgoCD would do that from the fact of a commit to a git repo.
- config_yml 4y agoI guess in "Make it as simple as possible, but not simpler", scp is too simple for you? But you also mentioned five different beasts to master, so I'm not so sure ;)
- nine_k 4y agoIf all you need is to update some files, with minimal error handling, scp is fine! (Well, rsync is probably a better option now, but scp would still work.) As you get progressively bigger, you can consider other options.
- francis-io 4y agoI guess it would all depend on the scale. For my home servers which just run personal things (like a kanban board as a todo list) I just use watchtower[0]. This requires mounting the docker socket into this container, which is not ideal. In a production environment, id expect pinning of the docker sha and setting docker tags as immutable. Some software projects exist to scan for updates and draft PRs automatically for changes (I can't remember the name of the software but it begins with R). [0] https://containrrr.dev/watchtower/ https://containrrr.dev/watchtower/
- cascandaliato 4y ago> I can't remember the name of the software but it begins with R Renovate maybe? https://www.mend.io/free-developer-tools/renovate/ https://www.mend.io/free-developer-tools/renovate/ I use it for my home server and I love it because it takes care of Dockerfiles too and version changes are saved in git, which means that a rollback is just a matter of switching back to a previous commit and rebuilding your containers (in addition to restoring a backup of your Docker volumes).
- yrro 4y agoYou could use Ansible with the podman_container task to keep your containers running.
- noirscape 4y agoIt varies a lot on what you're using. Postgres in particular is a bugbear because updating dockerized Postgres is hell at best and requires several backups in case you screw up. OTOH a bog standard python server backend can probably keep running for quite a while on alpine:latest without issue because it's not very reliant on much in terms of strange package availability (maybe old python versions that get deprecated every once in a while).
- deleted 4y ago[deleted]
- zokier 4y agoThat is a problem if you do not have strong controls on the publishing side. Ultimately the point of cicd is that changes get deployed mostly automatically, it doesn't matter if its accomplished by servers using :latest tag lr some automation going and reconfiguring servers or something else