Déploiement sans temps d'arrêt : mettez à niveau votre application dockerisée avec la technique Blue-Green

Dans un article que j'ai écrit il y a un mois, j'ai expliqué comment déployer en continu votre application Web Python dans un environnement de production (ou de pré-dev/staging).

J'ai récemment été chargé de créer un microservice (utilisant Python et FastAPI) pour faire correspondre deux voix et donner un score de prédiction si elles correspondaient ou non. Les parties prenantes avaient demandé une fonction de déverrouillage vocal.

Nous avons eu une réunion d'ingénierie et je me suis levé pour assumer la tâche (ou mon chef s'est levé pour moi, haha).

C'était une tâche intéressante, car je n'avais jamais travaillé (formé ou autre) avec un modèle ML auparavant. Il m'a fallu une semaine pour concevoir, créer et envoyer le code à une instance AWS EC2. Je suis un grand fan de CI/CD, j'ai donc utilisé ce avec quoi j'étais le plus à l'aise - GitHub Actions.

Une semaine plus tard… Des changements ont été demandés et je voulais essayer une nouvelle technique [de déploiement] sur laquelle j'avais fait des recherches. J'avais besoin que l'application de microservice docker s'exécute correctement sur l'instance AWS EC2 pour ne pas subir de temps d'arrêt lors du redéploiement.

Et j'avais le tour parfait dans mes manches.

Cette astuce est : la technique bleu-vert .

Selon le livre blanc AWS sur les déploiements bleus/verts, il s'agit d'une stratégie de déploiement dans laquelle vous créez deux environnements distincts mais identiques.

Un environnement (bleu) exécute la version actuelle de l'application et un environnement (vert) exécute la nouvelle version de l'application. L'utilisation d'une stratégie de déploiement bleu/vert augmente la disponibilité des applications et réduit les risques de déploiement en simplifiant le processus de restauration en cas d'échec d'un déploiement.

Une fois les tests terminés sur l'environnement vert, le trafic des applications en direct est dirigé vers l'environnement vert et l'environnement bleu est obsolète.

En termes simples, la technique de déploiement bleu/vert est un moyen de réduire les temps d'arrêt et les risques en exécutant deux environnements de production identiques.

Si c'est la première fois que vous entendez une telle technique de déploiement, il n'y a absolument rien à craindre, je vous fournirai des étapes détaillées qui vous aideront à réaliser un déploiement bleu-vert.

Passons directement aux étapes :

1. Commencez par créer une nouvelle image docker avec votre code mis à jour et étiquetez-la avec un nouveau numéro de version.

   
   

 $ docker build -t myexample:v2 .

Cela créera une nouvelle image Docker avec la balise myexample:v2 en utilisant le Dockerfile dans le répertoire actuel.

Où myexample:v2 est le nom de l'image docker nouvellement créée. Dans mon cas, c'était le nom du projet ML. Par exemple, docker build -t companyx-servicename-backend:v2

2. Démarrez un nouveau conteneur Docker à partir de la nouvelle image, mais ne l'exposez pas encore au monde extérieur.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

Cela démarrera un nouveau conteneur Docker avec le nom myexample-v2 à partir de l'image myexample:v2 .

3. Attendez que le nouveau conteneur démarre et s'initialise, en vous assurant qu'il fonctionne correctement.

   
   

 $ docker logs myexample-v2

Utilisez la commande docker logs pour vérifier les journaux du nouveau conteneur afin de vous assurer qu'il a démarré et initialisé correctement.

4. Utilisez un proxy inverse, tel que NGINX, pour acheminer le trafic vers les anciens et les nouveaux conteneurs. Configurez votre proxy inverse pour écouter les demandes et les transférer vers l'ancien et le nouveau conteneurs. Cela vous permettra de déplacer progressivement le trafic vers le nouveau conteneur.

Voici un exemple de configuration NGINX qui route deux conteneurs :

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Cette configuration configure un groupe en amont appelé myexample avec deux serveurs : myexample-v1 et myexample-v2 . Le mot-clé backup est utilisé pour marquer le second serveur comme serveur de sauvegarde. La directive proxy_pass est utilisée pour transmettre les requêtes au groupe amont myexample .

Assurez-vous de mettre à jour la configuration du proxy inverse pour refléter le nom et le port de votre application.

5. Déplacez progressivement le trafic de l'ancien conteneur vers le nouveau conteneur en ajustant la configuration du proxy inverse.

   
   

Pour déplacer le trafic vers le nouveau conteneur, ajustez la configuration du proxy inverse pour donner plus de poids au nouveau conteneur. Cela peut être fait en supprimant le mot-clé backup de la directive server :

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Cela obligera NGINX à envoyer plus de requêtes au conteneur myexample-v2 . Surveillez votre application et ajustez la configuration selon vos besoins jusqu'à ce que tout le trafic soit acheminé vers le nouveau conteneur.

6. Une fois que tout le trafic est acheminé vers le nouveau conteneur, vous pouvez arrêter et retirer l'ancien conteneur en toute sécurité.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

Cela arrêtera et supprimera l'ancien conteneur, libérant ainsi des ressources sur le serveur.

Conclusion

Je suis novice dans cette technique et évidemment je n'y connais pas grand chose. Mais je vais continuer à apprendre ses compromis et d'autres techniques qui fonctionneront mieux. Avez-vous un tour ou deux dans votre manche que vous aimeriez partager avec moi ?

Je l'apprécierai. Laissez-moi l'avoir (dans la section des commentaires).

Ah, ah. N'oubliez pas de vous abonner à ma newsletter ennuyeuse. J'ai appris beaucoup de choses depuis Q1 et je les partagerai bientôt. Ciao.