Rappelez-vous que nous utilisons la configuration du modèle indiquée dans le diagramme ci-dessous, et faites attention aux étiquettes disponibles, car nous les utiliserons activement dans nos exemples.
| Composants logiciels | Versions |
|---|---|
| Plateforme de conteneurs Red Hat OpenShift | 4.5.7 |
| Gestion avancée des clusters Red Hat | 2.0 Groupe de correctifs 2.0.2 |
Dépôt Git
Nous utiliserons également le référentiel Git de l'article précédent:
| Branche | La description |
|---|---|
| config | Stocke les fichiers de base pour les applications utilisées dans tous les environnements. |
| Prod | Stocke les fichiers de superposition pour les applications utilisées dans les environnements de production. |
| étape | Stocke les fichiers de superposition pour les applications utilisées dans les environnements de test |
Déploiement bleu / vert avec Red Hat ACM
Dans l'article précédent, nous avons déployé notre application reverseewords dans deux environnements, développement et production. Disons que, en développement, nous avons la version 0.0.3 et en production - 0.0.2.
Supposons maintenant que les développeurs ont publié la version 0.0.4 et que nous souhaitons effectuer un déploiement bleu-vert sur les clusters de développement et de production en utilisant les capacités GitOps d'ACM.
Dans l'article précédent, nous avons créé les ressources Channel, PlacementRules, Subscriptions et Applications nécessaires dans ACM, de sorte que lorsque nous déploierons la nouvelle version, seul Git fonctionnera dans les deux clusters.
Mettre à jour l'application dans l'environnement de développement
Puisque toutes les ressources requises ont déjà été créées, il suffit de changer les descriptions des applications dans Git afin de mettre à jour les versions dans les environnements correspondants.
REMARQUE. Comme nous ne faisons ici que démontrer les capacités GitOps d'ACM, nous allons pousser les modifications directement dans les branches du référentiel, ce qui n'est pas bon. Dans la vraie vie, vous devriez avoir un processus bien défini pour apporter des modifications à différents environnements, vous pouvez en savoir plus à ce sujet ici .
1. Accédez à notre référentiel Git cloné:
REMARQUE: Si vous avez reproduit les exemples de l'article précédent, vous disposez déjà d'une branche clonée de ce référentiel .
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Tout d'abord, nous souhaitons mettre à jour la version de l'application dans l'environnement de développement afin de pouvoir la tester avant de pousser les modifications dans l'environnement de production. Par conséquent, nous travaillerons avec la branche scène.
git checkout stage
3. Vous devez maintenant mettre à jour la superposition pour le déploiement de l'application afin que ce déploiement utilise la nouvelle image de version (0.0.4).
Jusqu'à présent, la version 0.0.3 est en cours d'exécution dans le cluster de développement.
sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Avant de valider les modifications, vérifiez l'état actuel de l'application dans le cluster de développement.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Comme vous pouvez le voir, la version 0.0.3 est actuellement en cours d'exécution dans l'environnement de développement:
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
5. Validez le fichier et poussez-le vers la branche de scène.
REMARQUE. Encore une fois, dans la vraie vie, vous ne devriez pas. Vous devez avoir un processus bien défini pour cela.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed development reverse-words app version to v0.0.4"
git push origin stage
6. Puisque nous avons déjà un abonnement, lors de la détection d'un nouveau commit dans notre référentiel et notre branche, ACM exécutera des actions pour changer l'état de l'actuel à l'état souhaité, comme écrit dans Git.
oc --context dev -n reverse-words-stage get pods
Comme vous pouvez le voir, des changements ont été détectés et la nouvelle version du pod est déployée avec la nouvelle version de l'application.
NAME READY STATUS RESTARTS AGE
reverse-words-5ff744d4bd-kkfvn 0/1 ContainerCreating 0 3s
reverse-words-68b9b894dd-jfgpf 1/1 Running 0 109m
7. Lançons maintenant la requête à l'application et vérifions que nous avons déployé la version 0.0.4.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Stage Release v0.0.4. App version: v0.0.4
8. La version de production reste intacte.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
9. Vous pouvez maintenant exécuter les tests de validation et, si tout va bien, déployer la nouvelle version de l'application en production.
Mise à jour de l'application dans l'environnement de production
1. Accédez au référentiel Git cloné.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Nous pensons que nous avons testé avec succès la nouvelle version de l'application dans le cluster de développement et qu'il est temps d'apporter les modifications appropriées pour la déployer sur le cluster de production. Nous allons donc maintenant travailler avec la branche prod.
git checkout prod
3. La superposition pour le déploiement de l'application doit être mise à jour afin que ce déploiement utilise la nouvelle image de version (0.0.4).
Jusqu'à présent, la version 0.0.2 est en cours d'exécution dans le cluster Production
sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Avant de valider les modifications, vérifiez l'état actuel de l'application dans le cluster de production.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Comme vous pouvez le voir, la version 0.0.2 est actuellement en cours d'exécution dans l'environnement de production:
Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2
5. Validez le fichier et poussez-le vers la branche prod.
REMARQUE. Encore une fois, dans la vraie vie, vous ne devriez pas. Vous devez avoir un processus bien défini pour cela.
git add apps/reversewords/overlays/deployment.yaml
git commit -m "Pushed production reverse-words app version to v0.0.4"
git push origin prod
6. Puisque nous avons déjà un abonnement, lors de la détection d'un nouveau commit dans notre référentiel et notre branche, ACM exécutera des actions pour changer l'état de l'actuel à l'état souhaité, comme écrit dans Git.
oc --context pro -n reverse-words-prod get pods
Comme vous pouvez le voir, des changements ont été détectés et la nouvelle version du pod est déployée avec la nouvelle version de l'application.
NAME READY STATUS RESTARTS AGE
reverse-words-68795d69ff-6t4c7 0/1 ContainerCreating 0 5s
reverse-words-7dd94446c-vkzr8 1/1 Running 0 115m
7. Lançons maintenant la requête à l'application et vérifions que nous avons déployé la version 0.0.4.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production Release v0.0.4. App version: v0.0.4
8. Voilà, nous avons mis à jour notre application à la version 0.0.4 dans les deux environnements: Développement et Production.
Conclusion
Dans la première partie de cette série, nous avons couvert les aspects d'ACM qui entrent dans la catégorie GitOps. Aujourd'hui, nous avons appris à utiliser ACM pour le déploiement bleu-vert, la migration d'applications entre les clusters et la reprise après sinistre. Dans le prochain article, nous vous montrerons comment migrer de manière transparente une application reverseewords entre nos clusters à l'aide d'ACM.