Remarque perev. - Avec cet article, nous entamons une série de traductions consacrées au thème du Déploiement Zero Downtime. Les publications suivantes mettront en évidence le déploiement de nouvelles versions de l'application avec la base de données et le déploiement dans Kubernetes.
Malgré le fait que la solution technique décrite ci-dessous soit controversée, le but de cet article est de familiariser directement le lecteur avec l'approche de déploiement Blue-Green, qui, incidemment, s'applique non seulement aux applications Spring.
L'objectif du déploiement Blue-Green est d'éliminer les temps d'arrêt lors du déploiement d'une nouvelle version de l'application.
Les temps d'arrêt sont associés à l'indisponibilité des serveurs lorsqu'une nouvelle version d'une application est installée pour remplacer l'ancienne. L'idée du déploiement Blue / Green est de déployer la nouvelle version de l'application dans un endroit séparé où vous pouvez tester, jusqu'à ce que la décision finale soit prise de la passer en tant que principale.
Dans cet article, nous verrons comment configurer le déploiement bleu-vert des applications de démarrage Spring. Nous utiliserons Nginx comme serveur Web principal pour rediriger les demandes entrantes vers nos applications.
Configuration du serveur
Ce guide suppose que vous disposez d'un serveur et d'une application de démarrage Spring en cours d'exécution qui peuvent y être déployés.
Sur le serveur, accédez à votre répertoire personnel et créez deux dossiers: blue et green . Ensuite, nous avons besoin de deux liens symboliques available et de testing . Ces liens pointeront vers un dossier bleu ou vert. Par exemple, si available pointe vers le green , alors le testing pointe vers le blue .
mkdir blue mkdir green ln -s ./green ./available ln -s ./blue ./testing
Chaque dossier contiendra sa propre application Spring et sa configuration Nginx. À un moment donné du déploiement, les deux applications fonctionneront simultanément (bien que sur des ports différents), et pour passer de l'application bleue au vert, il suffit de changer la configuration Nginx en vert ou en bleu.
Configurations Nginx
Disons que nous avons un domaine springsite.com. La configuration verte de Nginx redirigera tous les appels vers springsite.com/api/ vers l'application green sur le port 8080 et tous les appels vers springsite.com/api-test/ vers l'application blue sur le port 8090.
Créons ces fichiers de configuration. Ouvrez votre éditeur préféré et ajoutez le contenu suivant.
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8090/api; } location /api-test { proxy_pass http://localhost:8080/api; } } include servers/*; }
http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name mysite.com; location /api { proxy_pass http://localhost:8080/api; } location /api-test { proxy_pass http://localhost:8090/api; } } include servers/*; }
La structure du fichier devrait ressembler à ceci:
--root |--- blue |--- nginx.conf.blue |--- app-V2.jar |--- green |--- nginx.conf.green |--- app-V1.jar |--- available -> ./green |--- testing -> ./blue
Supposons que nous voulons déployer une nouvelle version dans un conteneur blue . Nous pouvons le tester alors que la version précédente est toujours disponible . Une fois que tout le monde sera satisfait de la nouvelle version, nous n'aurons plus qu'à changer les liens!
Créez le fichier swap.sh dans le dossier contenant les dossiers blue et green :
touch swap.sh chmod +x swap.sh
Ajoutez le contenu suivant au fichier swap.sh :
#!/bin/bash testing_now=$(ls -l ./ | grep testing) if [[ "$testing_now" == *blue ]] then testing="blue" active="green" else testing="green" active="blue" fi #remove current links rm ./available rm ./testing rm -f /etc/nginx/nginx.conf #create new links with the active/inactive reversed ln -s ./$inactive ./available ln -s ./$active ./testing ln -s /home/ubuntu/spring/$active/nginx.conf /etc/nginx/nginx.conf #reload the http server service nginx reload echo swap completed $active is now available
À ce stade, nous pouvons exécuter 2 applications Spring sur les ports 8090 et 8080 et les modifier en exécutant sudo ./swap.sh .
Déployer
Grâce aux liens symboliques, nous savons que l'application principale est toujours indiquée par available , et celle de test par testing . Par conséquent, nous devons toujours déployer une nouvelle version de l'application dans le dossier testing aide d'un lien symbolique. On suppose que nous venons de packager l'application, et maintenant nous pouvons la télécharger en utilisant scp .
scp -r -i ~/.ssh/MyKeyPair.pem <package name.jar> <user>@<ip>:spring/testing
Continuez
La configuration d'un déploiement Blue-Green sur votre serveur réduira considérablement les temps d'arrêt . Ce guide explique comment déployer de nouvelles versions de votre application résidant sur le même serveur physique. Il peut être adapté aux situations avec plusieurs serveurs physiques et un équilibreur de charge. Cependant, cela nécessitera d'avoir deux fois plus d'environnements de production que nécessaire. Pour une très grande infrastructure, cela est impossible ou extrêmement coûteux.
Cela conduit à la question: comment les grandes entreprises parviennent-elles à publier de nouvelles versions de leurs applications sans interruption? Pensez à Google ou Facebook qui sont toujours disponibles!
L'utilisation du déploiement Blue-Green ici n'est pas réaliste en raison du grand nombre de serveurs nécessaires. Les mises à jour des applications se font progressivement: les serveurs sont mis hors service un par un, puis retournés après la mise à jour. De plus, de nouvelles versions sont également publiées progressivement: au début, seule une petite partie des serveurs fonctionnera avec la nouvelle version. Ensuite, si aucun problème ou bogue n'a été trouvé, de plus en plus de serveurs démarreront avec le nouveau code. À ce stade, les mesures de performances importantes telles que le processeur, la mémoire et les performances des requêtes sont évaluées. Si tout s'est bien passé, la sortie est terminée et une nouvelle version de l'application sera lancée sur tous les serveurs du monde.
Conclusion
J'espère que vous comprenez maintenant comment résoudre le problème des temps d'arrêt grâce au déploiement Blue-Green. Vous pouvez maintenant configurer le déploiement bleu-vert de base de votre application Spring avec NGINX.
Comme vous l'avez peut-être remarqué, lorsque nous utilisons cette solution, les anciennes et actuelles versions de vos applications fonctionnent simultanément et les deux sont connectées à la base de données. Cela peut entraîner des problèmes inattendus lors du changement de la structure de la base de données. Cet excellent article https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database décrit comment gérer ces situations.
Et enfin, vous pourriez être intéressé par le fait qu'AWS et Google Cloud Compute offrent des services de déploiement Blue-Green prêts à l'emploi:
https://aws.amazon.com/quickstart/architecture/blue-green-deployment/
https://cloud.google.com/solutions/continuous-delivery/
Lisez également d'autres articles sur notre blog: