CI/CD-Pipeline für Cloud-Deployments mit Github-Aktionen und Oracle Cloud Infrastructure DevOps Service erstellen
- Um zu verhindern, dass alle Deployment-Ziele mit einem Service verbunden sind, der sich außerhalb einiger Ihrer Sicherheitsebenen befindet.
- Teile eines Deployment-Prozesses können je nachdem, wann Infrastructure as Code (IaC) möglicherweise Teil des Deployment-Prozesses ist, unterschiedlich sein.
- Minimieren Sie die potenziellen Auswirkungen der Latenz in Deployment-Prozessen. Die Ausführung des letzten Schritts wird also lokal mit nur lokalen Verbindungen und Abhängigkeiten gesteuert.
- Sie können Kontrollassets verwalten und freigeben, die sich über mehrere Umgebungen hinweg an einer zentralen Stelle erstrecken. Anstatt verteilte Quellen zu haben.
Diese Referenzarchitektur befasst sich mit diesen Überlegungen, indem sie Teile ihres Service außerhalb von Oracle Cloud nutzen (z.B. GitHub und andere innerhalb von OCI, wie DevOps). Diese Referenzarchitektur prüft den Deployment-Prozess (CD) auf Oracle Cloud Infrastructure(OCI)-Plattformen: Oracle Container Engine for Kubernetes (OKE), Functions und Compute-Instanzen. Das allgemeine Containerimage wird mit einem separaten Service (so dass das Element universell ist) erstellt und dann von DevOps bereitgestellt, damit es nicht direkt mit OKE kommuniziert.
Durch die Automatisierung von Software-Releases mit Pipeline-Bereitstellung wird die Entwicklerproduktivität gesteigert und Sie können Features häufiger und mit weniger Fehlern freigeben. Sie trägt dazu bei, Ausfallzeiten bei der Bereitstellung zu vermeiden und die Komplexität der Aktualisierung von Anwendungen zu automatisieren. Oracle DevOps kann von beiden Kunden verwendet werden, die Workloads von On Premise oder anderen Clouds zu OCI migrieren und Kunden neue Anwendungen auf OCI entwickeln.
Architektur
In dieser Referenzarchitektur wird eine Beispielanwendung aus GitHub mit GitHub-Aktionen und dem OCI-Service DevOps bereitgestellt. Die Anwendung wird im OKE-Cluster bereitgestellt.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
Beschreibung der Abbildung devops-arch.png
- Region
Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center, sogenannte Availability-Domains, enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie (über Länder oder sogar Kontinente) trennen.
Die Architektur verwendet eine einzelne Region.
- Externes CI-System
Diese Architektur verwendet GitHub Actions als externes kontinuierliches Integrationssystem. GitHub Aktionen automatisieren, anpassen und führen Softwareentwicklungsworkflows aus dem GitHub-Repository aus. Hier wird mit GitHub-Aktionen Code erstellt und dann mit Docker containerisiert. Wenn das containerisierte Image bereit ist, überträgt GitHub Actions das Image in ein OCI-Artefakt-Repository (Alternativ wird das Artefakt in einem zentralen Speicherort abgelegt, an dem die GitHub-Aktionen so konfiguriert werden können, dass DevOps das Artefakt zum Abrufen des Artefakts nudgeiert. Dies bedeutet, dass Inhalt gezogen, nicht gedrückt wird). Nach Abschluss der Übertragung in das Artefakt-Repository wird die OCI-Deployment-Pipeline DevOps gestartet. Je nach Ihren Anforderungen können Sie auch andere kontinuierliche Integrationssysteme wie Jenkins oder Gitlab verwenden.
Wenn IaC-Techniken verwendet werden, könnte die Pipeline vor dem Deployment Services wie Resource Manager verwenden, um eine Umgebung zu instanziieren und diese Ressourcen nach Abschluss mit Resource Manager zu entfernen.
Die Devops-Deployment-Pipeline kann die resultierende Ausgabe auch an einem sicheren Ort für Berichte speichern.
- DevOps project
Ein DevOps-Projekt ist eine logische Gruppierung von Ressourcen, die zur Implementierung Ihrer CI/CD-Workload (Continu Integration and Deployment) erforderlich sind. DevOps-Ressourcen können Artefakte, Deployment-Pipelines und Umgebungen sein. DevOps-Projekte erleichtern die Aktivierung von Logging, Überwachung und Benachrichtigungen für alle DevOps-Ressourcen.
- Deployment-Pipeline
Eine Deployment-Pipeline enthält die Anforderungen, die erfüllt sein müssen, um eine Reihe von Artefakten für eine Umgebung bereitzustellen. Pipelines enthalten Phasen, die die Bausteine einer Pipeline sind. Eine Pipeline kann mehrere Phasen haben, die seriell oder parallel ausgeführt werden, sodass Sie den Ablauf und die Logik Ihres Software-Release steuern können.
- BereitstellungsphasenPhasen sind einzelne Aktionen, die während einer Pipeline-Ausführung ausgeführt werden. Die DevOps-Deployment-Pipeline enthält die folgenden vordefinierten Staging-Typen, die Sie in Ihrem Releaseprozess verwenden können:
- Rollierendes Deployment: Ein inkrementelles Release für OKE, Funktionen oder Instanzgruppen.
- Wait: Wait N Sekunden.
- Manuelle Genehmigung: Fahren Sie fort, wenn eine Genehmigung erteilt wurde; beenden Sie den Vorgang, wenn eine Genehmigung abgelehnt wurde.
- Funktion aufrufen: Benutzerdefinierte Aufgaben und Integration ausführen, indem Sie eine Funktion aufrufen und ein Artefakt von Anforderungsparametern übergeben.
- DevOps Artefakt
Ein DevOps-Artefakt ist eine Referenz oder ein Zeiger auf Dateien, Binärdateien, Packages, Manifeste oder Images, aus denen Ihre Anwendung besteht. Beim Erstellen eines Artefakts müssen Sie Oracle DevOps über den Quellspeicherort des eigentlichen Artefakts informieren. DevOps unterstützt Repositorys der OCI Container Image Registry und der OCI Artifact Registry.
- Artefakt-Repository
Mit dem Artefakt-Repository werden Repositorys erstellt, um ähnliche Artefakte zu gruppieren. Nachdem das Repository erstellt wurde, können Artefakte in sie hochgeladen werden. Diese Artefakte sind eine Sammlung von Textdateien, Binärdateien und Deployment-Manifesten, die an die Ziel-Deployment-Umgebung geliefert werden. Jedes Artefakt hat einen Namen, der aus seinem Pfad erstellt wird: Version. Der Pfad ist eine Zeichenfolge zum Organisieren der Artefakte.
- OCI-Logging- und -Benachrichtigungsservices
OCI Logging Service speichert Logs für das Deployment. Die Laufzeitausgabe des Deployments und die endgültigen Ergebnisse des Deployments werden als Logeinträge angezeigt. Der OCI-Benachrichtigungsservice bietet Einblick in den aktuellen Status des Deployment-Projekts und seiner Ressourcen und führt alle erforderlichen Maßnahmen durch. Beispiel: Sie werden benachrichtigt, wenn ein wichtiges Ereignis, z.B. eine Phase in einer Bereitstellungs-Pipeline, die auf die 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 Compute Virtual Machine-(VM-) oder Bare-Metal-Instanz oder ein OKE-Cluster sein.
- Oracle Kubernetes-Cluster (OKE): Oracle Container Engine for Kubernetes ist einen vollständig verwalteten, skalierbaren und hochverfügbaren Service, mit dem Sie Ihre containerisierten Anwendungen in der Cloud bereitstellen können.
- Compute-Instanzen: Mit dem OCI Compute-Service können Sie Compute-Hosts in der Cloud bereitstellen und verwalten. Sie können Compute-Instanzen mit Ausprägungen starten, die Ihren Ressourcenanforderungen für CPU, Arbeitsspeicher, Netzwerkbandbreite und Speicher entsprechen.
- Funktionen: Oracle Functions ist eine vollständig verwaltete, mehrmandantenfähige, hochskalierbare, bedarfsgesteuerte Functions-as-a-Service-Plattform. Sie basiert auf OCI der Unternehmensklasse und wird von der Open-Source-Engine Fn Project unterstützt.
Empfehlungen
- VCN
Bestimmen Sie beim Erstellen eines VCN die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich im standardmäßigen privaten IP-Adressbereich befinden.
Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.
Diese Architektur verwendet ein öffentliches VCN zum Hosten des OKE-Clusters. Sie können auch ein privates VCN verwenden. Verwenden Sie in diesem Fall ein NAT-Gateway, um dem Cluster Zugriff über das öffentliche Internet zu gewähren.
- Compute-Ausprägungen
Diese Architektur verwendet ein Oracle Linux-BS-Image mit der Flex-Ausprägung E3 oder E4 mit minimalen Ressourcen, um Compute-Hosts in den OKE-Clusterknoten zu hosten. Wenn Ihre Anwendung mehr Speicher oder Kerne benötigt, können Sie eine andere Ausprägung auswählen.
- OKE
Diese Architektur wird als Zielendpunkt im OKE-Cluster bereitgestellt. Die Worker-Knoten werden auf einem E3- oder E4 Oracle Linux-BS bereitgestellt. Diese Architektur verwendet drei Worker-Knoten im Cluster. Sie können jedoch bis zu 1,000 Knoten in jedem Cluster erstellen.
- Container-Image-Registry
Diese Architektur stellt Registry zur internen Verwendung als private Docker-Registry bereit. Docker-Images werden in die Registry übertragen und daraus abgerufen. Sie können Registry auch als öffentliche Docker-Registry verwenden, sodass jeder Benutzer mit Internetzugriff und Kenntnis der entsprechenden URL Images aus öffentlichen Repositorys in Oracle Cloud abrufen kann.
- Artefaktregistrierung
Diese Architektur erstellt ein Artefakt für die Software und Konfiguration, die von einem OKE-Cluster verwendet werden. Die Architektur erstellt ein Artefakt-Registry-Repository zur internen Verwendung. Softwarebinärdateien, Text- und Deployment-Konfigurationen werden in das Artefakt-Registry-Repository hochgeladen und daraus heruntergeladen.
Überlegungen
Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte.
- DevOps-unterstützte Deployments
DevOps unterstützt Deployments in OKE, Compute-Hosts und Funktionen. Diese Architektur wird in einem OKE-Cluster bereitgestellt. Sie sollten das Deployment für andere Endpunkte basierend auf den Anforderungen in Erwägung ziehen.
- Linux-Support
Nur Linux-Hosts werden für Instanzgruppen-Deployments in Compute-Instanzen unterstützt.
- Bereitgestellte Artefakte
Artefakte, die mit DevOps bereitgestellt werden sollen, müssen in einer OCI-Artefakt-Registry oder einem Repository der Container-Image-Registry enthalten sein.
- Anwendungen gruppieren
Als Best Practice wird empfohlen, jede Anwendung und alle zugehörigen Microservices in einem einzelnen Projekt zu gruppieren. Stellen Sie sicher, dass das Value Proposition des Prozesses verstanden wird und die Divisionen beibehalten werden.
Bereitstellen
Um diese Architektur bereitzustellen, befolgen Sie die Anweisungen zum Deployment der Java-Anwendung in dieser Live-Übung: