Ok. Je retiens (et note, surtout ) ça

Si à chaque release de l'applicatif (y compris un petit changement dans les settings), il faut une nouvelle version de l'image, alors la question suivante est : est-il possible, pendant qu'un conteneur tourne, de builder une nouvelle version du conteneur, et de switcher de façon "pratiquement transparente" entre la version "runnée" et la version "à runner" pour limiter le downtime, ou également pour éviter d'avoir à stopper/redémarrer les autres conteneurs en lien avec celui qui doit être "remplacé" ?


[Edit : je vois que docker-compose a une commande up -d pour redémarrer un conteneur suite à un (potentiel) changement d'image. Mais je ne vois pas si cela implique successivement un stop / build / run, ou bien si c'est un build / stop / run, auquel cas le downtime est plutôt faible, ou encore un build / run as temp / stop / rename "temp", auquel cas le downtime est pratiquement nul. Je vais voir si la doc est plus verbeuse que Stack Overflow à ce sujet ]

[Edit 2 : Ok, le -d est juste pour le mode "detach" qui est, je pense, le paramètre que je devrai utiliser si je veux supporter ça via systemd (je lirai là dessus plus tard). Ce qui fait que je n'ai pas encore réponse à ma question De ce que je vois, il semble qu'il soit nécessaire de se tourner vers d'autres solutions (WatchTower est notamment cité) qui sont typiquement utilisés dans des approches cloud. Peut-être que je ne devrai pas m'inquiéter d'un downtime de quelques secondes]

GuybrushDe ce que je vois, il semble qu'il soit nécessaire de se tourner vers d'autres solutions (WatchTower est notamment cité) qui sont typiquement utilisés dans des approches cloud. Peut-être que je ne devrai pas m'inquiéter d'un downtime de quelques secondes

Oui, ou ça peut s'implémenter à la main mais c'est à voir si ça vaut le coup.
En gros ça consiste à avoir durant un temps court une instance (container) de chaque image exposant sur un port différent.
Ensuite, reconfigurer dynamiquement un load balancer (nginx ?) pour faire entrer le nouveau conteneur dans le cluster, attendre que les connexions se ferment sur l'ancien, et le sortir du cluster.

Ah ouais, ça me fait penser que j'utilise gunicorn via un file socket pour l'instant, il va peut-être falloir que je change ça aussi pour plus de facilité ^^