Il faut comprendre que Docker, ce n'est pas fait pour déployé un Apache HTTPD ou un Nginx et servir des fichiers statiques. Le but, c'est déployé une application un peu complexe (avec plusieurs dépendances). Imagine une mise à jour où tu dois non seulement changer les binaires, mais aussi changer les droits sur les fichiers, en ajouter certains, en déplacer d'autre, etc. Dans un cas classique, il faut bien faire les opérations de mise à jour en preprod, valider que ça fonctionne, et bien faire les mêmes en prod sans se planter. Si on a loupé une étape (ou si les tests étaient mal faits) et qu'il faut revenir en arrière, il faut bien défaire ce qu'on a fait (de nouveaux sans se planter).
Avec docker, du déploie une image en preprod, si ça marche, tu déploie la même image en prod et tu es bien sûr que c'est exactement la même. S'il faut revenir en arrière, tu peux simplement reprendre l'image précédente.
(il est évidemment possible d'avoir une solution intermédiaire avec un système d'automatisation, mais tu reviens moins facilement en arrière)
Évidemment, dans ce cas, on ne parle que de la mise à jour du code. On ne va pas pouvoir facilement revenir en arrière si on foire le changement de schéma de base de données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: mises à jours et docker
Posté par claudex . En réponse au journal Les outils de l'IT pour un FabLab. Évalué à 7.
Il faut comprendre que Docker, ce n'est pas fait pour déployé un Apache HTTPD ou un Nginx et servir des fichiers statiques. Le but, c'est déployé une application un peu complexe (avec plusieurs dépendances). Imagine une mise à jour où tu dois non seulement changer les binaires, mais aussi changer les droits sur les fichiers, en ajouter certains, en déplacer d'autre, etc. Dans un cas classique, il faut bien faire les opérations de mise à jour en preprod, valider que ça fonctionne, et bien faire les mêmes en prod sans se planter. Si on a loupé une étape (ou si les tests étaient mal faits) et qu'il faut revenir en arrière, il faut bien défaire ce qu'on a fait (de nouveaux sans se planter).
Avec docker, du déploie une image en preprod, si ça marche, tu déploie la même image en prod et tu es bien sûr que c'est exactement la même. S'il faut revenir en arrière, tu peux simplement reprendre l'image précédente.
(il est évidemment possible d'avoir une solution intermédiaire avec un système d'automatisation, mais tu reviens moins facilement en arrière)
Évidemment, dans ce cas, on ne parle que de la mise à jour du code. On ne va pas pouvoir facilement revenir en arrière si on foire le changement de schéma de base de données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche