Deployment-Strategien verstehen

Die in diesem Artikel beschriebenen Architekturen veranschaulichen, wie Sie eine moderne Anwendung mit Blue-Green- und Canary-Deployment-Strategien erstellen und bereitstellen. Deployment-Strategien sind Modelle und Übungen, die Anwendungsänderungen oder Anwendungsupgrades ermöglichen. Mit Deployment-Strategien können DevOps-Teams definieren, wie Anwendungen in der Produktionsumgebung bereitgestellt werden.

Durch die Wahl zwischen verschiedenen Deployment-Strategien können Administratoren die richtigen Kompromisse zwischen dem Risiko des Deployments eines neuen Release, den Auswirkungen des neuen Release auf die Benutzer und dem Infrastruktur-Overhead vornehmen, der für die Implementierung der Strategie erforderlich ist. Wir möchten unseren Kunden mehr Optionen geben, um den richtigen Kompromiss angesichts ihrer Anwendungsanforderungen zu erzielen.

Informationen zu Blue-Green Deployments

Mit einer Blue-Green-Bereitstellungsstrategie möchten DevOps-Teams eine neue Version ihrer Anwendung mit zwei identischen Umgebungen freigeben, in denen eine von ihnen zu einem bestimmten Zeitpunkt aktiv ist. Die aktuelle Version der Anwendung wird in der aktiven Umgebung bereitgestellt, während die neue Version in der Standbyumgebung bereitgestellt wird.

Das Deployment in der Standbyumgebung wirkt sich nicht auf die aktive Umgebung oder den Benutzertraffic aus. Die Releasepipeline DevOps kann Validierungstests für die neue Version ausführen. Sobald sie genehmigt ist, wird sie zur Produktion hochgestuft, indem der Benutzertraffic einfach in die Standbyumgebung gewechselt wird. Dieser Prozess wird für jedes neue Release der Anwendung wiederholt.

Der Hauptvorteil dieser Strategie besteht darin, dass sie nahezu keine Ausfallzeit und sofortige Rollback-Funktionen bietet. Bei Problemen mit der neuen Version kann der Traffic sofort auf die vorherige stabile Version zurückgesetzt werden. Außerdem kann die Standbyumgebung debuggen, was im Anwendungsrelease nicht erfolgreich war.

Das folgende Diagramm veranschaulicht eine Blue-Green-Deployment-Architektur:

Beschreibung der Abbildung blue-green-deployment.png

Blue-Green-Deployment-Komponenten kennenlernen

Die vorhergehende Architektur enthält die folgenden Komponenten.

• Region

  Eine OCI-Region ist ein lokalisierter geografischer Bereich, der ein oder mehrere Data Center enthält, die als Availability-Domains bezeichnet werden. Regionen sind nicht von anderen Regionen abhängig, und große Distanzen können sie trennen (über Länder oder sogar Kontinente). Die Architektur verwendet eine einzelne Region.

• DevOps-Projekt

  Eine logische Gruppierung von DevOps-Ressourcen, die zur Implementierung eines CI/CD-Workflows erforderlich sind. DevOps-Ressourcen können Artefakte, Build-Pipelines, Deployment-Pipelines, externe Verbindungen, Trigger und Umgebungen sein. DevOps-Projekte erleichtern die Aktivierung von Logging, Monitoring und Benachrichtigungen für alle DevOps-Ressourcen.

• Build-Pipeline

  Eine Build-Pipeline nimmt eine Commit-ID aus den Quellcode-Repositorys an und verwendet diesen Quellcode, um Ihre Build-Anweisungen auszuführen. "Build Pipelines" definiert eine Reihe von Phasen für den Erstellungsprozess - Softwareartefakte erstellen, testen und kompilieren, Artefakte an OCI-Repositorys bereitstellen und optional ein Deployment auslösen. Sie definieren den Ablauf und die Anweisungen der Build-Ausführung in der Build-Spezifikationsdatei.

• Phasen erstellen

  Phasen sind einzelne Aktionen, die während einer Ausführung einer Pipeline ausgeführt werden. Dabei werden folgende Build-Phasen erwähnt: Managed Build-Phasen: Eine verwaltete Build-Phase zum Erstellen und Testen des Quellcodes. Phase "Artefakte bereitstellen": Eine Phase, mit der die Ausgaben der Build-Phase an verschiedene Repositorys übertragen werden. Likes Container-Images an Container-Repository und Deployment-Manifest in Artefakt-Registry übergeben werden. Deployment aufrufen: Eine Phase zum Aufrufen einer Deployment-Pipeline nach Abschluss der Build-Phasen, zusammen mit dem Parsen der exportierten Variablen von der Managed Build-Phase in die Deployment-Pipelinephasen.

• Code-Repository

  Private Git-Repositorys, die vom DevOps-Service gehostet werden. Mit unseren DevOps Code-Repositorys können Sie Quellcode speichern, verwalten und entwickeln. Deployment-Pipeline Eine Abfolge von Schritten zum Bereitstellen und Bereitstellen einer Gruppe von Artefakten in einer Zielumgebung. Der Ablauf und die Logik Ihres Softwarerelease können durch die Definition von Phasen gesteuert werden, die seriell oder parallel ausgeführt werden können.

• Deployment-Phasen

  Phasen sind einzelne Aktionen, die während einer Ausführung einer Pipeline ausgeführt werden. Hier werden verschiedene Build-Stufen genannt:

  • Deployment blauer/grüner OKE oder Deployment blauer/grüner Instanzgruppen: Bereitstellen des aktualisierten Codes in Zielumgebungen.
  • Deployment-Validierung: Optionale Phase zur Validierung der Deployments (Via-Funktionen)
  • Kontrolle: Genehmigung: Kontrollphase zur Genehmigung des Deployments in der Zielproduktionsumgebung.
  • Blue/Green OKE Traffic Shift oder Blue/Green Instance Group Traffic Shift: Endgültige Phase, in der der der Produktionsdatenverkehr auf die zuletzt bereitgestellte Umgebung umgeschaltet wird.

• DevOps Artefakt

  Ein DevOps-Artefakt ist ein Referenz- oder Zeiger auf eine Datei, Binärdatei, ein Package, ein Manifest oder ein Bild, aus dem Ihre Anwendung besteht. Informieren Sie beim Erstellen eines Artefakts Oracle DevOps über den Quellspeicherort des eigentlichen Artefakts. DevOps unterstützt OCI Container Image Registry und OCI-Artefakt-Registry-Repositorys.

• Artefakt-Repository

  Das Artefakt-Repository erstellt Repositorys, um ähnliche Artefakte zu gruppieren. Wenn das Repository erstellt wird, können Sie Artefakte in das Repository hochladen. Diese Artefakte sind eine Sammlung von Textdateien, Binärdateien und Deployment-Manifesten, die in die Ziel-Deployment-Umgebung bereitgestellt werden. Jedes Artefakt hat einen Namen, der aus seinem Pfad: Version besteht. Der Pfad ist eine Zeichenfolge zum Organisieren der Artefakte.

• OCI-Logging- und Benachrichtigungsservices

  Der OCI-Logging-Service speichert Logs für das Deployment. Die Deployment-Laufzeitausgabe und die endgültigen Ergebnisse des Deployments werden als Logeinträge angezeigt. OCI Notifications bietet einen Überblick über den aktuellen Status des Deployment-Projekts und dessen Ressourcen und führt alle erforderlichen Maßnahmen durch. Beispiel: Sie werden benachrichtigt, wenn ein wichtiges Ereignis, z.B. eine Phase in einer Bereitstellungspipeline, die auf Genehmigung wartet. Wenn Sie die Benachrichtigung erhalten, können Sie zu DevOps-Deployment-Pipelines gehen und die Phase genehmigen.

• Deployment-Umgebungen

  Eine Umgebung ist eine Sammlung von Computing-Ressourcen eines Kunden, in denen Artefakte bereitgestellt werden. Umgebungen können eine Funktion, eine virtuelle Compute-Machine-(VM-) oder eine Bare-Metal-Instanz oder ein OKE-Cluster sein. Das Blue Green-Deployment ist nur für OKE-Cluster und virtuelle Compute-Maschinen verfügbar.

Vor- und Nachteile von Blue-Green Deployments verstehen

Beim Deployment einer modernen Anwendung können sowohl Vor- als auch Nachteile eine Blue-Green-Strategie verwenden.

Die Vorzüge von Blue-Green Deployments sind:

• Blue Green Deployments ermöglichen schnelle und risikofreie Deployments.
• Sie ermöglichen mit einem effektiven einfachen Rollback-Mechanismus.
• Sie ermöglichen eine effektive Orchestrierung von A/B-Softwaretests.
• Keine oder nahezu keine Ausfallzeit, da die Produktion immer über eine aktive Umgebung (hinter einem Load Balancer) bedient wird.

Die Kons der Blue-Green Deployments sind:

• Für das Aufrechterhalten der Umgebung eines Blue-Green-Deployments sind hohe Kosten für identische Umgebungen und Ressourcen erforderlich.
• Sie müssen beide Umgebungen eng überwachen, um das Release zwischen zwei identischen Umgebungen zu verwalten.
• Die Verwaltung von Datenbankabhängigkeiten zwischen Deployments ist kompliziert.

Informationen zu kanarischen Deployments

Bei einer Canary-Deployment-Strategie wird das Anwendungsrelease inkrementell für einen Teil der Benutzer freigegeben. Zunächst wird die neue Version in einer Kanarischen Umgebung ohne Benutzerverkehr bereitgestellt. Die Releasepipeline DevOps kann Validierungstests für die neue Version ausführen und, sobald sie bereit ist, nur einen Teil der Benutzer an die kanarische Umgebung weiterleiten.

Mit dieser Technik kann das DevOps-Team die neue Anwendungsversion anhand des realen Benutzertraffics auswerten. Sie können die beiden Anwendungsversionen nebeneinander vergleichen, bevor die neue Version in eine größere Benutzerbasis eingeführt wird. Sie bietet auch Risikominderung, da die neue Version nur für eine kleine Teilmenge der Benutzer aktiviert ist. Diese Benutzer können bei Problemen einfach zurück zur vorherigen Version wechseln.

Das folgende Diagramm veranschaulicht eine Canary-Deployment-Strategie:

Beschreibung der Abbildung canary-deployment.png

Kanarische Deployment-Komponenten verstehen

Die vorhergehende Architektur enthält die folgenden Komponenten.

• Region

  Eine OCI-Region ist ein lokalisierter geografischer Bereich, der ein oder mehrere Data Center enthält, die als Availability-Domains bezeichnet werden. Regionen sind nicht von anderen Regionen abhängig, und große Distanzen können sie trennen (über Länder oder sogar Kontinente). Die Architektur verwendet eine einzelne Region.

• DevOps-Projekt

  Eine logische Gruppierung von DevOps-Ressourcen, die zur Implementierung eines CI/CD-Workflows erforderlich sind. DevOps-Ressourcen können Artefakte, Build-Pipelines, Deployment-Pipelines, externe Verbindungen, Trigger und Umgebungen sein. DevOps-Projekte erleichtern die Aktivierung von Logging, Monitoring und Benachrichtigungen für alle DevOps-Ressourcen.

• Build-Pipeline

  Eine Build-Pipeline nimmt eine Commit-ID aus den Quellcode-Repositorys an und verwendet diesen Quellcode, um Ihre Build-Anweisungen auszuführen. Build Pipelines definieren eine Reihe von Phasen für den Erstellungsprozess - das Erstellen, Testen und Kompilieren von Softwareartefakten, das Bereitstellen von Artefakten für OCI-Repositorys und optional das Auslösen eines Deployments. Sie definieren den Ablauf und die Anweisungen der Build-Ausführung in der Build-Spezifikationsdatei.

• Phasen erstellen

  Phasen sind einzelne Aktionen, die während eines Laufs einer Pipeline stattfinden. Dabei werden folgende Build-Phasen erwähnt:

  • Verwaltete Build-Stufen: Eine verwaltete Build-Phase zum Erstellen und Testen des Quellcodes.
  • Phase "Artefakte bereitstellen": Eine Phase, in der die Ausgaben der Build-Phase an verschiedene Repositorys übertragen werden. Gefällt Containerimages wie Container-Repository und Deployment-Manifest in Artefakt-Registry.
  • Deployment aufrufen: Eine Phase zum Aufrufen einer Deployment-Pipeline, sobald die Build-Phasen abgeschlossen sind, zusammen mit dem Parsen der exportierten Variablen von der Managed Build-Phase zur Deployment-Pipelinephase.

• Code-Repository

  Private Git-Repositorys, die vom DevOps-Service gehostet werden. Mit unseren DevOps Code-Repositorys können Sie Quellcode speichern, verwalten und entwickeln.

• Deployment-Pipeline

  Eine Abfolge von Schritten zum Bereitstellen und Bereitstellen einer Gruppe von Artefakten in einer Zielumgebung. Der Ablauf und die Logik Ihres Softwarerelease können durch die Definition von Phasen gesteuert werden, die seriell oder parallel ausgeführt werden können.

• Deployment-Phasen

  Phasen sind einzelne Aktionen, die während einer Ausführung einer Pipeline ausgeführt werden. Hier werden verschiedene Build-Stufen genannt:

  • Canary OKE Deployment oder Canary Instance Group Deployment: Bereitstellen des aktualisierten Codes in Zielkanarumgebungen.
  • Deployment-Validierung: Optionale Phase zur Validierung der Deployments (Via-Funktionen)
  • Canary OKE Traffic Shift oder Canary Instance Group Traffic Shift: Stage zum Wechseln des Traffics in die Kanarenumgebung basierend auf dem Ramp-Grenzwert (% des zu verschiebenden Traffics).
  • Kontrolle: Genehmigung: Kontrollphase zur Genehmigung des Deployments in der Zielproduktionsumgebung.
  • Kann Instanzgruppenproduktion bereitstellen oder OKE-Produktion bereitstellen: Endgültige Phase, in der der der Produktionsdatenverkehr auf die zuletzt bereitgestellte Umgebung umgestellt wird.

• DevOps Artefakt

  Ein DevOps-Artefakt ist ein Referenz- oder Zeiger auf eine Datei, Binärdatei, ein Package, ein Manifest oder ein Bild, aus dem Ihre Anwendung besteht. Informieren Sie beim Erstellen eines Artefakts Oracle DevOps über den Quellspeicherort des eigentlichen Artefakts. DevOps unterstützt OCI Container Image Registry und OCI-Artefakt-Registry-Repositorys.

• Artefakt-Repository

  Das Artefakt-Repository erstellt Repositorys, um ähnliche Artefakte zu gruppieren. Wenn das Repository erstellt wird, können Sie Artefakte in das Repository hochladen. Diese Artefakte sind eine Sammlung von Textdateien, Binärdateien und Deployment-Manifesten, die in die Ziel-Deployment-Umgebung bereitgestellt werden. Jedes Artefakt hat einen Namen, der aus seinem Pfad: Version besteht. Der Pfad ist eine Zeichenfolge zum Organisieren der Artefakte.

• OCI-Logging- und Benachrichtigungsservices

  Der OCI-Logging-Service speichert Logs für das Deployment. Die Deployment-Laufzeitausgabe und die endgültigen Ergebnisse des Deployments werden als Logeinträge angezeigt. OCI Notifications bietet einen Überblick über den aktuellen Status des Deployment-Projekts und dessen Ressourcen und führt alle erforderlichen Maßnahmen durch. Beispiel: Sie werden benachrichtigt, wenn ein wichtiges Ereignis, z.B. eine Phase in einer Bereitstellungspipeline, die auf Genehmigung wartet. Wenn Sie die Benachrichtigung erhalten, können Sie zu DevOps-Deployment-Pipelines gehen und die Phase genehmigen.

• Deployment-Umgebungen

  Eine Umgebung ist eine Sammlung von Computing-Ressourcen eines Kunden, in denen Artefakte bereitgestellt werden. Umgebungen können eine Funktion, eine virtuelle Compute-Machine-(VM-) oder eine Bare-Metal-Instanz oder ein OKE-Cluster sein. Das Blue Green-Deployment ist nur für OKE-Cluster und virtuelle Compute-Maschinen verfügbar.

Vor- und Nachteile von kanarischen Deployments verstehen

Beim Deployment einer modernen Anwendung können sowohl Vor- als auch Nachteile eine kanarische Strategie verwenden.

Die Vor-Ort-Bereitstellungen sind:

• Damit können Sie zwei Anwendungsversionen nebeneinander mit echten Benutzern testen.
• Für die neue Version gibt es keine Ausfallzeit.
• Das Rollback zu einer früheren Version ist sehr einfach und bietet das geringste Risiko.

Kons of Canary Deployments:

• Das Testen und Validieren eines neuen Release ist möglicherweise skalierbar.
• Das Abrufen des Feedbacks aus Benutzertests für ein neues Release ist eine zeitaufwendige Aufgabe.