We are your futur    —  Guybrush

Discussions

Ansibiliser Lexpage

Guybrush 4501 Bob
Reprise automatique du message précédent.
Ok. Je retiens (et note, surtout :-D) ç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 :-D]

[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 :-D 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]


Ce message a été modifié 2 fois. Dernière modification : 23 janvier 2019 à 16:47 par Guybrush.

Fabe 379 Maitre jedi
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.


Ce message a été modifié 1 fois. Dernière modification : 23 janvier 2019 à 17:51 par Fabe.

Guybrush 4501 Bob
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é ^^

Répondre

Vous devez être inscrit et identifié.