Denken Sie daran, dass wir die in der folgenden Abbildung gezeigte Modellkonfiguration verwenden, und beachten Sie die dort verfügbaren Beschriftungen, da wir sie in unseren Beispielen aktiv verwenden werden.
| Softwarekomponenten | Versionen |
|---|---|
| Red Hat OpenShift Container-Plattform | 4.5.7 |
| Red Hat Advanced Cluster Management | 2.0 Fixpack 2.0.2 |
Git-Repository
Wir werden auch das Git-Repository aus dem vorherigen Artikel verwenden:
| Ast | Beschreibung |
|---|---|
| config | Speichert Basisdateien für Anwendungen, die in allen Umgebungen verwendet werden. |
| Prod | Speichert Overlay-Dateien für Anwendungen, die in Produktionsumgebungen verwendet werden. |
| Bühne | Speichert Overlay-Dateien für Anwendungen, die in Testumgebungen verwendet werden |
Blau / Grün-Bereitstellung mit Red Hat ACM
Im vorherigen Artikel haben wir unsere Reverseewords-Anwendung in zwei Umgebungen bereitgestellt: Entwicklung und Produktion. Nehmen wir an, in der Entwicklung haben wir Version 0.0.3 und in der Produktion - 0.0.2.
Angenommen, die Entwickler haben Version 0.0.4 veröffentlicht, und wir möchten eine blaugrüne Bereitstellung für die Entwicklungs- und Produktionscluster mithilfe der GitOps-Funktionen von ACM durchführen.
Im vorherigen Artikel haben wir die erforderlichen Ressourcen für Channel, PlacementRules, Subscriptions und Applications in ACM erstellt, sodass bei der Bereitstellung der neuen Version nur Git in beiden Clustern funktioniert.
Aktualisieren der Anwendung in der Entwicklungsumgebung
Da bereits alle erforderlichen Ressourcen erstellt wurden, müssen wir nur die Anwendungsbeschreibungen in Git ändern, um die Versionen in den entsprechenden Umgebungen zu aktualisieren.
HINWEIS. Da wir hier nur die GitOps-Funktionen von ACM demonstrieren, werden wir Änderungen direkt in die Zweige des Repositorys übertragen, was nicht gut ist. Im wirklichen Leben sollten Sie über einen genau definierten Prozess verfügen, um Änderungen an verschiedenen Umgebungen vorzunehmen. Weitere Informationen hierzu finden Sie hier .
1. Gehen Sie zu unserem geklonten Git-Repository:
HINWEIS: Wenn Sie die Beispiele aus dem vorherigen Artikel reproduziert haben, haben Sie bereits einen geklonten Zweig dieses Repositorys .
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Zunächst möchten wir die Version der Anwendung in der Entwicklungsumgebung aktualisieren, damit wir sie testen können, bevor wir Änderungen an der Produktionsumgebung vornehmen. Deshalb werden wir mit der Bühnenbranche zusammenarbeiten.
git checkout stage
3. Jetzt müssen Sie das Overlay für die Anwendungsbereitstellung aktualisieren, damit für diese Bereitstellung das neue Versionsabbild (0.0.4) verwendet wird.
Bisher wird Release 0.0.3 im Entwicklungscluster ausgeführt.
sed -i "s/v0.0.3/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Überprüfen Sie vor dem Festschreiben von Änderungen den aktuellen Status der Anwendung im Entwicklungscluster.
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Wie Sie sehen können, wird Version 0.0.3 derzeit in der Entwicklungsumgebung ausgeführt:
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
5. Übernehmen Sie die Datei und verschieben Sie sie in den Stage-Zweig.
HINWEIS. Noch einmal, im wirklichen Leben solltest du nicht. Sie müssen dafür einen genau definierten Prozess haben.
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. Da wir bereits ein Abonnement haben, führt ACM nach dem Erkennen eines neuen Commits für unser Repository und unseren Zweig Aktionen aus, um den Status vom aktuellen zum gewünschten Status zu ändern, wie in Git geschrieben.
oc --context dev -n reverse-words-stage get pods
Wie Sie sehen, wurden Änderungen erkannt und die neue Version des Pods wird mit der neuen Version der Anwendung bereitgestellt.
NAME READY STATUS RESTARTS AGE
reverse-words-5ff744d4bd-kkfvn 0/1 ContainerCreating 0 3s
reverse-words-68b9b894dd-jfgpf 1/1 Running 0 109m
7. Führen Sie nun die Anforderung an die Anwendung aus und stellen Sie sicher, dass wir Release 0.0.4 bereitgestellt haben.
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. Die Produktionsfreigabe bleibt erhalten.
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. Jetzt können Sie die Validierungstests ausführen und, wenn alles in Ordnung ist, die neue Version der Anwendung in die Produktion einführen.
Aktualisieren der Anwendung in der Produktionsumgebung
1. Wechseln Sie zum geklonten Git-Repository.
cd /path/to/acm-app-lifecycle-blog/forked/repository/
2. Wir glauben, dass wir die neue Version der Anwendung im Entwicklungscluster erfolgreich getestet haben und es an der Zeit ist, die entsprechenden Änderungen vorzunehmen, um sie im Produktionscluster bereitzustellen. Daher werden wir jetzt mit dem Produktzweig arbeiten.
git checkout prod
3. Sie müssen das Overlay für die Anwendungsbereitstellung aktualisieren, damit für diese Bereitstellung das neue Versionsabbild (0.0.4) verwendet wird.
Bisher wird Release 0.0.2 im Produktionscluster ausgeführt
sed -i "s/v0.0.2/v0.0.4/g" apps/reversewords/overlays/deployment.yaml
4. Überprüfen Sie vor dem Festschreiben von Änderungen den aktuellen Status der Anwendung im Produktionscluster.
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Wie Sie sehen können, wird Version 0.0.2 derzeit in der Produktionsumgebung ausgeführt:
Reverse Words Release: Stage Release v0.0.2. App version: v0.0.2
5. Übernehmen Sie die Datei und verschieben Sie sie in den Produktzweig.
HINWEIS. Noch einmal, im wirklichen Leben solltest du nicht. Sie müssen dafür einen genau definierten Prozess haben.
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. Da wir bereits ein Abonnement haben, führt ACM nach dem Erkennen eines neuen Commits für unser Repository und unseren Zweig Aktionen aus, um den Status vom aktuellen zum gewünschten Status zu ändern, wie in Git geschrieben.
oc --context pro -n reverse-words-prod get pods
Wie Sie sehen, wurden Änderungen erkannt und die neue Version des Pods wird mit der neuen Version der Anwendung bereitgestellt.
NAME READY STATUS RESTARTS AGE
reverse-words-68795d69ff-6t4c7 0/1 ContainerCreating 0 5s
reverse-words-7dd94446c-vkzr8 1/1 Running 0 115m
7. Führen Sie nun die Anforderung an die Anwendung aus und stellen Sie sicher, dass wir Release 0.0.4 bereitgestellt haben.
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. Das war's, wir haben unsere Anwendung in beiden Umgebungen auf Version 0.0.4 aktualisiert: Entwicklung und Produktion.
Fazit
Im ersten Teil dieser Reihe haben wir die Aspekte von ACM behandelt, die unter die Kategorie GitOps fallen. Heute haben wir gelernt, wie ACM für blau-grüne Bereitstellungen, Anwendungsmigration zwischen Clustern und Notfallwiederherstellung verwendet wird. Im nächsten Beitrag zeigen wir Ihnen, wie Sie Ihre Reverseewords-Anwendung mithilfe von ACM nahtlos zwischen unseren Clustern migrieren können.