App in Kubernetes bereitstellen
Continuous Delivery wird am 12. Februar 2027 in den folgenden Regionen eingestellt: au-syd, ca-mon, ca-tor, us-east. Code Risk Analyzer und DevOps Insights werden ebenfalls zu diesem Zeitpunkt in allen Regionen abgeschafft. Wenn jedoch eine Region diese Funktionen nicht aktiv nutzt, können die Funktionen in dieser Region früher eingestellt werden und keine neuen Instanzen mehr annehmen. Weitere Informationen
In diesem Lernprogramm erfahren Sie, wie eine offene Toolchain unter Verwendung verschiedener Bereitstellungsstrategien erstellt wird. Außerdem erfahren Sie, wie Toolchains im Service IBM Cloud® Continuous Delivery implementiert werden und wie eine einfache Webanwendung (App) mithilfe von Toolchains entwickelt und bereitgestellt wird.
Dieses Lernprogramm ist browserbasiert. Sie können auch eine ähnliche offene Toolchain in Terraform erstellen, wie im IBM Cloud Terraform-Provider-Beispiel ibm-cd-toolchain-simple-helm gezeigt.
In diesem Lernprogramm werden Bereitstellungsstrategien verwendet, die Kubernetes als Bereitstellungsziel verwenden. Die Toolchain, die in diesem Lernprogramm verwendet wird, implementiert DevOps-Standardverfahren wie Code-Scanning, Abnahmetests, Git -Repositorys sowie Funktionen für kontinuierliche Integration und Continuous Delivery. Nachdem Sie einen Kubernetes-Cluster und eine Toolchain erstellt haben, ändern Sie den Code Ihrer App und übertragen die Änderung per Push-Operation in das Git Repos and Issue Tracking-Repository. Wenn Sie Änderungen mit Push-Operation auf Ihr Repository übertragen, erstellt und implementiert die Tekton-basierte Delivery Pipeline automatisch den Code.
Tekton ist ein quelloffenes, herstellerunabhängiges, Kubernetes-natives Framework, das Sie zum Erstellen, Testen und Bereitstellen von Anwendungen verwenden können. Tekton bietet eine Reihe gemeinsamer Komponenten für den Aufbau von Systemen für kontinuierliche Integration und kontinuierliche Bereitstellung. Als Open-Source-Projekt wird Tekton von der Continuous Delivery Foundation verwaltet. Das Ziel ist die Modernisierung von Continuous Delivery durch Bereitstellung von Branchenspezifikationen für Pipelines, Workflows und andere Bausteine. Mit Tekton können Sie bei Cloud-Providern oder lokal Systeme erstellen, testen und implementieren, indem Sie die zugrunde liegenden Implementierungsdetails abstrahieren. Tekton-Pipelines sind in Continuous Delivery integriert.
Die in diesem Lernprogramm verwendete Vorlage funktioniert entweder mit dem Standard- oder Lite-Plan für Kubernetes. Mit dem Standardplan können Sie über den DNS-Namen auf Ihre App zugreifen. Im Lite-Plan können Sie mithilfe des Knotenports auf Ihre Anwendung zugreifen.
Sie können eine Implementierungsstrategie verwenden, um eine Anwendung in einer Produktionsumgebung kontrolliert zu aktualisieren. Die Verwendung einer Bereitstellungsstrategie bietet die folgenden Vorteile:
- Vermeiden von Anwendungsausfallzeiten.
- Ermöglichen von Produktionstests für neue Funktionen, ohne die Kunden zu beeinträchtigen.
- Begrenzung der Auswirkungen von Produktionsproblemen auf eine Untergruppe von Benutzern.
- Aktivieren eines schnellen Rollbacks auf die vorherige Version, wenn Probleme gefunden werden.
Es sind viele mögliche Implementierungsstrategien verfügbar. Im Allgemeinen sind sie davon abhängig, dass mehrere Instanzen der Anwendung ausgeführt werden und wie die verschiedenen Instanzen aktualisiert werden. Sie können die folgenden gängigen Implementierungsstrategien in Continuous Delivery vorkonfigurieren:
- Grundlegend
- Implementiert das neue Release, indem alle aktiven Instanzen gleichzeitig gestoppt und aktualisiert werden, was zu Ausfallzeiten führt. Für ein Rollback müssen Sie die vorherige Version erneut bereitstellen, was zusätzliche Ausfallzeiten verursacht. Obwohl diese Strategie einfach und schnell ist und geringen Ressourcenbedarf bezüglich der Laufzeit hat, ist sie am risikoreichsten und verursacht Ausfallzeiten. Die Bereitstellungsstrategie Basic wird für kritische Apps, die hoch verfügbar sein müssen, nicht empfohlen.
- Rollierende Aktualisierung
- Ähnlich wie die Basic-Strategie ist diese Bereitstellungsstrategie einfach, schnell und hat einen geringen Laufzeitressourcenbedarf. Da jedoch jede aktive Instanz einzeln heruntergefahren und aktualisiert wird, um Ausfallzeiten zu vermeiden, müssen Sie für ein Rollback das vorherige Release erneut implementieren. Dieser zeitaufwendige Ansatz kann Probleme verursachen, wenn die aktuelle Version der App in der Produktion beschädigt ist.
- Blau-Grün-Bereitstellung
- Erstellt zwei separate, permanente Produktionsumgebungen (blau und grün), von denen jeweils nur eine den Datenverkehr empfängt. Das aktuelle Release wird immer in der inaktiven Umgebung implementiert und der Datenverkehr wird nach Abschluss der Implementierung ohne Ausfallzeit auf diese Umgebung umgeschaltet. Da Sie nur den Datenverkehr auf die unveränderte Umgebung umschalten müssen, verursacht ein Rollback keine Ausfallzeit. Da diese Strategie zwei vollständige Produktionsumgebungen erfordert, ist der Ressourcenbedarf höher. Diese Strategie ermöglicht jedoch leistungsfähige Entwicklerabläufe wie etwa die Möglichkeit, neue App-Versionen in der Produktionsumgebung zu testen, bevor sie den Kundendatenverkehr zulässt. Blau-Grün-Implementierung unterstützt auch ein schnelles Rollback.
- Canary-Release
- Stellt ein neues Release parallel zur ursprünglichen Produktionsumgebung (ähnlich wie Blau-Grün) ohne Ausfallzeit bereit. Der Datenverkehr, der sowohl an die aktualisierte als auch an die ursprüngliche Instanz gesendet wird, wird verwaltet, sodass die neue Version für eine kontrollierte Untergruppe von Benutzern verfügbar ist, während die Bereitstellung fortgesetzt wird. Im Lauf der Zeit wird der Datenverkehr, der an die neue Version gesendet wird, erhöht, bis der gesamte Datenverkehr dorthin gesendet wird. An diesem Punkt können Sie die alte Produktionsumgebung stoppen. Für ein schnelles Rollback können Sie den gesamten Datenverkehr, während die Implementierung läuft, an die ursprüngliche Produktionsumgebung weiterleiten. Da bei dieser Strategie nur während der Bereitstellung zwei vollständige Produktionsumgebungen benötigt werden, ist der Ressourcenverbrauch insgesamt geringer als bei der Blue-Green-Bereitstellung. Die Bereitstellungsstrategie für das Canary-Release ist die langsamste, wenn Sie von einem früheren Release zu einem aktuellen Release der Software wechseln, die implementiert wird. Mit Canary-Implementierungen können Unternehmen zwei verschiedene Softwareversionen nebeneinander in der Produktion testen.
Vorbereitende Schritte
Stellen Sie vor Beginn dieses Lernprogramms sicher, dass die folgenden Ressourcen vorhanden sind:
-
Ein IBM Cloud-Konto. Abhängig von Ihrem IBM Cloud-Kontotyp kann der Zugriff auf bestimmte Ressourcen eingeschränkt sein. Abhängig von den Grenzwerten für Ihren Kontoplan sind bestimmte Funktionen, die für einige der Implementierungsstrategien erforderlich sind, möglicherweise nicht verfügbar. Weitere Informationen über IBM Cloud Konten finden Sie unter Einrichten Ihres IBM Cloud Kontos und Upgraden Ihres Kontos.
-
Ein Kubernetes-Cluster und ein API-Schlüssel. Sie können diese Ressourcen entweder über die Benutzeroberfläche oder über die Befehlszeilenschnittstelle erstellen. Es kann einige Zeit dauern, bis der Cluster bereitgestellt ist. Wenn der Cluster erstellt wird, durchläuft er die Phasen 'Wird bereitgestellt', 'Anstehend' und 'Bereit '. Weitere Informationen zu Kubernetes-Clustern finden Sie unter Kubernetes-Cluster. Obwohl Sie Rolling- und Blue-Green-Bereitstellungen für Lite-Pläne verwenden können, müssen Sie einen Kubernetes-Cluster für Standardpläne erstellen.
-
Eine Instanz des Continuous Delivery-Service.
-
Optional. Geheime Schlüssel, die in einem Vault für die Verwaltung geheimer Schlüssel gespeichert und zentral von einem einzigen Standort aus verwaltet werden. Weitere Informationen zur Auswahl aus den verschiedenen Angeboten für Verwaltung geheimer Schlüssel und Datenschutz finden Sie unter Geheime IBM Cloud-Schlüssel verwalten. Wenn Sie noch nicht über eine Instanz des gewünschten Vault-Providers für die Verwaltung geheimer Schlüssel verfügen, erstellen Sie eine solche Instanz.
-
Optional. Ein Namensbereich, der über die Befehlszeile der Container-Registry erstellt wird. Um einen Namensraum zu erstellen, geben Sie den folgenden Befehl ein:
ibmcloud cr namespace-add <my namespace>Alternativ können Sie einen Namensbereich auf der Seite Container Registry erstellen. Weitere Informationen zum Erstellen eines Namensbereichs an diesem Standort finden Sie unter IBM Cloud Container Registry-Service.
Toolchain erstellen
In diesem Schritt erstellen Sie eine Toolchain für Kubernetes-App entwickeln. Der Kubernetes-Zielcluster wird während der Toolchain-Konfiguration mithilfe Ihres IBM Cloud-API-Schlüssels und Ihres Kubernetes-Clusternamens konfiguriert. Sie können diese Einstellungen später ändern, indem Sie die Delivery Pipeline-Konfiguration aktualisieren. Jeder Code, der im Zielzweig des Git-Repositorys zusammengeführt wird, wird automatisch erstellt, validiert und im Kubernetes-Cluster bereitgestellt.
Klicken Sie zum Erstellen einer Toolchain für Kubernetes-App entwickeln auf
Alternativ können Sie in der IBM Cloud Konsole auf das Menü-Symbol (
) > Plattformautomatisierung > Toolchains klicken. Klicken
Sie auf der Seite Toolchains auf Toolchain erstellen. Klicken Sie auf der Seite Erstellen einer Toolchain auf Entwickeln einer Kubernetes Anwendung.
Den Toolchain-Namen und die Region konfigurieren
Überprüfen Sie die Standardinformationen für die Toolchain-Einstellungen. Der Name der Toolchain macht sie in IBM Cloud identifizierbar. Stellen Sie sicher, dass der Name der Toolchain innerhalb Ihrer Toolchains für dieselbe Region und Ressourcengruppe in IBM Cloud eindeutig ist.
Die Region der Toolchain kann sich von der Region des Clusters und der Registry unterscheiden.
Die Bereitstellungsstrategie auswählen
Die Toolchain erstellt eine Continuous Deployment-Pipeline, um das Docker-Image der Anwendung auf IBM Cloud® Kubernetes Servicebereitzustellen. Wählen Sie die Bereitstellungsstrategie aus, die Sie verwenden wollen. Je nachdem, welche Bereitstellungsstrategie Sie auswählen (Rolling, Blau-Grün, oder Canary), müssen Sie weitere Details angeben.
-
Klicken Sie auf die Bereitstellungsstrategie, die Sie für Ihre Toolchain verwenden wollen.
für die Bereitstellung von AppsStrategien für die Bereitstellung -
Klicken Sie auf Weiter.
Repository für den Anwendungsquellcode konfigurieren
Im Anwendungsschritt werden die empfohlenen Optionen für das Quellcode-Repository der Anwendung standardmäßig angezeigt. Um alle verfügbaren Optionen für die zugrunde liegende Git-Integration anzuzeigen, klicken Sie auf Erweiterte Optionen. Standardmäßig verwendet die Toolchain das Standardbeispiel, das die Beispiel-App als von IBM gehostetes Git Repos and Issue Tracking-Repository klont.
Sie können den Namen des App-Repositorys ändern. Die Region des Repositorys bleibt die gleiche wie die Region der Toolchain.
Die Toolchain-Vorlage stellt eine Beispiel-NodeJS-App bereit. Wenn Sie ein vorhandenes Anwendungsrepository für die Toolchain verlinken wollen, wählen Sie Eigene App verwenden aus und geben Sie die URL für das Repository an. Die Toolchain unterstützt nur Links zu vorhandenen Git Repos and Issue Tracking-Repositorys.
Standardmäßig wird die Vorlage des Anwendungsrepositorys in Ihrer Git Repos and Issue Tracking-Organisation geklont. Zum Ändern der Organisation aktivieren Sie Erweiterte Optionen und geben den Eigner des Repositorys an.
Das Bestandsrepository konfigurieren
Das Bestandsrepository zeichnet die Details der Artefakte auf, die von den Toolchains für die kontinuierliche Integration erstellt werden. Sie können entweder ein neues Inventar-Repository erstellen, das ein Klon der Inventar-Repository-Vorlage ist, oder ein bereits vorhandenes Inventar-Repository verwenden, das von mehreren Toolchains gemeinsam genutzt wird.
Standardmäßig wird die Bestandsrepository-Vorlage in Ihrer Git Repos and Issue Tracking-Organisation geklont. Um die Organisation zu ändern, wählen Sie Erweiterte Optionen aus und geben den Eigner des Repositorys an.
Geheime Schlüssel sicher speichern
Für mehrere Tools innerhalb dieser Toolchain sind geheime Schlüssel erforderlich, z. B. ein IBM Cloud-API-Schlüssel. Sie müssen alle geheimen Schlüssel sicher in einem Vault für geheime Schlüssel speichern und sie entsprechend den Anforderungen der Toolchain referenzieren.
Mit IBM Cloud können Sie aus verschiedenen Angeboten für das Management geheimer Schlüssel und den Datenschutz auswählen, mit denen Sie Ihre sensiblen Daten schützen und Ihren geheimen Schlüssel zentralisieren können. Im Schritt "Geheime Schlüssel" können Sie angeben, welche Vaultintegrationen für geheime Schlüssel in Ihrer Toolchain hinzugefügt oder entfernt werden sollen. Weitere Informationen zum Hinzufügen und Entfernen von Vaultintegrationen, einschließlich der Voraussetzungen und mithilfe von Hinweisen, finden Sie unter Geheime IBM Cloud-Schlüssel verwalten.
Durch Verwendung von Hinweisen in einer Vorlage wird eine Toolchain automatisch mit vorkonfigurierten geheimen Schlüsseln gefüllt. Sie brauchen keine geheimen Schlüssel manuell aus Vaultintegrationen auszuwählen, die der Toolchain zugeordnet sind.
In diesem Lernprogramm wird IBM Secrets Manager als Vault für geheime Schlüssel verwendet.
IBM Secrets Manager speichert sicher und wendet geheime Schlüssel wie API-Schlüssel, Imagesignatur, oder HashiCorp-Berechtigungsnachweise, die Teil Ihrer Toolchain sind, an.
Weitere Informationen zur Verwaltung Ihrer Geheimnisse in IBM Key Protect oder HashiCorp, finden Sie unter Geheimnisse.
Implementierungsziel konfigurieren
Konfigurieren Sie den Kubernetes-Zielcluster für die Bereitstellung der App. Nachdem die App die Build-, Test- und Scanphase bestanden hat, stellt die Pipeline das erstellte App-Image im Kubernetes-Zielcluster bereit. Diese Implementierung ist jetzt für Abnahmetests oder Integrationstests bereit.
Wenn der API-Schlüssel den erforderlichen Zugriff hat, werden die folgenden Felder automatisch mithilfe des API-Schlüssels geladen, der entweder erstellt, aus einer Vault abgerufen, oder manuell angegeben wird. Wenn der API-Schlüssel gültig ist, werden Werte für die Container Registry-Region und die Namensbereich-Clusterregion, den Namen, den Namensbereich und die Ressourcengruppe automatisch eingetragen. Sie können jedes dieser Felder entsprechend Ihrer Konfiguration aktualisieren.
-
App-Name: Der Name der App. Der Standardname der App ist
hello-containers. -
IBM Cloud-API-Schlüssel: Der API-Schlüssel, der für die Interaktion mit dem
ibmcloud-CLI-Tool in mehreren Tasks verwendet wird. Verwenden Sie eine der folgenden Methoden, um den API-Schlüssel anzugeben, den Sie verwenden möchten:- Klicken Sie auf das Schlüsselsymbol, um einen vorhandenen API-Schlüssel aus einem geheimen Vault Ihrer Wahl zu importieren.
- Kopieren Sie einen vorhandenen API-Schlüssel und fügen Sie ihn ein.
- Klicken Sie auf Neu, um einen API-Schlüssel zu erstellen.
- Generieren Sie eine neue
api-key, wenn kein API-Schlüssel vorhanden ist.
Sie können den generierten API-Schlüssel sofort in einer vorhandenen Vault für geheime Schlüssel Ihrer Wahl speichern.
Die App wird mithilfe der von Ihnen angegebenen Bereitstellungsstrategie bereitgestellt. Das folgende Beispiel zeigt die Details für eine Rolling- oder Blue-Green-Bereitstellung.
Wenn Sie die Bereitstellungsstrategie Canary gewählt haben, müssen Sie zusätzliche Details zum Bereitstellungsziel angeben.
-
Größe des Canary-Schritts: Definiert den Umfang des Datenverkehrs, der an das neue Release der Canary-Implementierung umgeleitet werden soll.
-
Intervall für Canary-Schritt: Definiert das Zeitintervall zwischen den einzelnen Canary-Tests für die Umstellung auf das neue Release der Canary-Implementierung.
Optionale Toolintegrationen hinzufügen
Sie können die IBM Cloud® DevOps Insights-Toolintegration ohne zusätzliche Konfiguration zu Ihrer Toolchain hinzufügen.
DevOps Insights ist in der erstellten Toolchain enthalten. Sie brauchen keine Konfigurationsschritte für DevOps Insights anzugeben. Die Pipeline für kontinuierliche Integration verwendet automatisch die DevOps Insights-Instanz, die in der Toolchain enthalten ist. DevOps Insights aggregiert Code-, Test-, Build- und Bereitstellungsdaten, um Einblick in die Geschwindigkeit und Qualität aller Ihrer Teams und Releases zu liefern.
Klicken Sie auf Weiter.
Das Toolchain-Setup abschließen
Klicken Sie auf der Seite 'Übersicht' auf Erstellen. Zum Einrichten Ihrer Toolchain werden mehrere verschiedene Schritte automatisch ausgeführt.
Sie können die einzelnen Toolchain-Integrationen konfigurieren, nachdem die Pipeline erstellt wurde.
Neue Toolchain erkunden
Nach der Erstellung der Toolchain werden alle Toolintegrationen, die Teil der Toolchain sind, in einem Diagramm dargestellt.
Pipelines erkunden
Sie können die Pipelines erkunden, um sich einen Einblick in den Toolchainablauf und die verschiedenen, innerhalb der jeweiligen Pipelines ausgeführten Operationen zu verschaffen. Die soeben erstellte Toolchain enthält drei Pipelines:
- Pipeline für Pull-Anforderungen: Wird ausgeführt, wenn ein Entwickler Änderungen aus seinem Entwicklungszweig mit dem Masterzweig oder einem anderen Zweig im Repository zusammenführt. Über die Pipeline für Pull-Anforderungen werden die Komponententests und statischen Scans für den Anwendungsquellcode ausgeführt.
- Pipeline für kontinuierliche Integration: Wird ausgeführt, wenn Sie eine Änderung mit der Masterverzweigung des Anwendungsquellcodes zusammenführen. Die Pipeline für kontinuierliche Integration führt den Komponententest, die Codeabdeckung und statische Scans für den Anwendungsquellcode, die CIS-Prüfung und die Stücklistenprüfung aus. Die Continuous Delivery-Pipeline generiert auch die binären Build-Artefakte und lädt sie in die IBM Cloud® Kubernetes Service, wie in der Toolchain konfiguriert, hoch. Die Pipeline für kontinuierliche Integration generiert die Metadaten der Build-Artefakte und speichert sie im Bestandsrepository.
- Pipeline für kontinuierliche Bereitstellung: Implementiert Build-Artefakte in der Implementierungsumgebung. Die Pipeline überprüft die erfolgreiche Bereitstellung der App durch Ausführen der Statusprüfung. Sie müssen diese Pipeline manuell auslösen, nachdem die Pipeline für kontinuierliche Integration erfolgreich abgeschlossen wurde. Abhängig von der ausgewählten Bereitstellungsstrategie werden weitere Auslöser zur Continuous-Delivery-Pipeline hinzugefügt.
Ausführen der Pull-Anforderung und der Pipelines für die kontinuierliche Integration
Erstellen Sie zum Starten der Pipeline für Pull-Anforderungen eine Zusammenführungsanforderung in Ihrem App-Repository:
- Klicken Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys auf das
compliance-app-<timestamp>-App-Repository. - Erstellen Sie im Master-Repository einen Zweig.
- Aktualisieren Sie Code in der Beispielknoten-App oder der Readme-Datei und speichern Sie diese Änderungen.
- Übergeben Sie die Zusammenführungsanforderung.
- Klicken Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys auf das Repository
pr-pipeline, um die Pipeline für Pull-Anforderungen zu starten. Die entsprechende Zusammenführungsanforderung in Ihrem App-Repository verbleibt im Wartestatus, bis alle Phasen der Pipeline für Pull-Anforderungen erfolgreich abgeschlossen wurden. - Nachdem die Pipeline für Pull-Anforderungen erfolgreich ausgeführt wurde, können Sie sie auswählen, um die abgeschlossenen Schritte zu untersuchen.
Um die Pipeline für kontinuierliche Integration zu starten, führen Sie die Zusammenführungsanforderung für kontinuierliche Integration in Ihrem App-Repository zusammen:
- Wechseln Sie zur Zusammenführungsanforderung.
- Führen Sie die Anforderung zusammen, sodass Ihre Änderungen in den Masterzweig Ihres App-Repositorys kopiert werden. Die Pipeline für kontinuierliche Integration wird automatisch ausgelöst.
- Klicken Sie auf der Übersichtsseite für die Toolchain für die kontinuierliche Integration auf der Karte Repositorys auf das
ci-pipeline-Repository, um die Pipeline für die kontinuierliche Integration zu starten. - Nach erfolgreicher Ausführung der Pipeline für die kontinuierliche Integration können Sie auf die Pipelineausführung klicken, um die abgeschlossenen Schritte zu untersuchen.
Praxis der Linksverschiebung
In der Welt der sicheren App-Entwicklung ist "shift-left" eine Praxis, die Probleme wie Fehler und Sicherheitslücken verhindert und aufspürt und die Einhaltung der Vorschriften frühzeitig im Softwareentwicklungsprozess überprüft. Diese Praxis, die Qualitätsprüfungen zu einem früheren Zeitpunkt im Entwicklungszyklus durchzuführen, umfasst die folgenden Praktiken:
- Führen Sie so früh wie möglich Prüfungen aus, die für den Code oder das Repository selbst ausgeführt werden können und das erstellte Image nicht benötigen. Diese Prüfungen verhindern, dass nicht konformer Code mit dem Masterzweig des Repositorys zusammengeführt wird. Da die Beweise nicht in der Pull-Request-Pipeline gesammelt werden, besteht das Ziel darin, die Überprüfung der Einhaltung der Vorschriften in eine frühere Phase des Entwicklungsprozesses zu verlagern.
- Alle Prüfungen werden in jeder Pipelineausführung ausgeführt. Wenn eine vorherige Prüfung fehlschlägt, geht die Pipeline zur nächsten Prüfung über. Um zu bewerten, ob Fehler in Ihrer Ausführung auftreten, überprüfen Sie den letzten Schritt Ihrer Pipeline, der über ein Pipeline-Auswertungsprogramm verfügt.
Ergebnisse von Komponententests und Schwachstellenscans werden in der DevOps Insights-Instanz innerhalb der Toolchain veröffentlicht. Klicken Sie zum Überprüfen dieser Ergebnisse auf die Kachel DevOps Insights in der Toolchain und wechseln Sie zur Seite 'Qualitätsdashboard'.
Um zu bewerten, ob Fehler in Ihrer Pipelineausführung auftreten, überprüfen Sie den letzten Schritt Ihrer Pipeline, der über ein Pipeline-Auswertungsprogramm verfügt.
Continuous Delivery-Pipeline kennenlernen
Die Pull-Anforderung und die Pipelines für kontinuierliche Integration sind in allen Bereitstellungsstrategien einheitlich. Das Design und die Implementierung der Continuous Delivery-Pipeline basieren auf der Bereitstellungsstrategie, die Sie zuvor in diesem Lernprogramm ausgewählt haben.
Dieses Lernprogramm veranschaulicht, wie die Rolling-Bereitstellungsstrategie mithilfe der Beispiel-App funktioniert.
Rolling-Bereitstellung kennenlernen
Die in diesem Lernprogramm verwendete Rolling-Bereitstellungsstrategie veranschaulicht, wie Sie eine Bereitstellungsstrategie mit dem Continuous Delivery-Service verwenden können, um Ihre Produktionsworkloads auf Kubernetes auszuführen. Die Continuous Delivery-Pipeline stellt zwei Auslöser für die Rolling-Bereitstellung bereit. Sie können eine Continuous Delivery-Pipeline auf eine der folgenden Arten starten:
- Lösen Sie die Continuous-Delivery-Pipeline manuell aus.
- Lösen Sie die Continuous-Delivery-Pipeline automatisch nach jeder
Merge-Aktion im Bestandsrepository aus. Nach der Zusammenführung müssen Sie die Ausführung der Continuous Delivery-Pipeline manuell auslösen.
Ein Git Repos and Issue Tracking-Auslöser ist so konfiguriert, dass er eine automatische Continuous Delivery-Pipeline auslöst, er ist jedoch standardmäßig deaktiviert. Sie können diesen Auslöser nach dem ersten Hochstufen einer Änderung aktivieren.
Da die Rolling-Bereitstellungsstrategie alle Produktionsinstanzen inkrementell mit der neuen Softwareversion aktualisiert, kommt es nicht zu Ausfallzeiten. Die Rollback-Bereitstellungsstrategie erfordert jedoch, dass Sie das vorherige Release erneut bereitstellen, was einige Zeit bis zum Abschluss dauern kann.
Nach erfolgreicher Ausführung der Continuous Delivery-Pipeline können Sie die App-URL im Schritt perform deployment der Continuous Delivery-Pipeline lokalisieren.
Nächste Schritte
Wenn Sie die in Kubernetes ausgeführte Beispielapp entfernen möchten, müssen Sie den Kubernetes-Cluster bereinigen:
-
Rufen Sie die Homepage von Kubernetes Cluster auf.
-
Wählen Sie den Cluster aus, in dem die Beispielapp ausgeführt wird.
-
Klicken Sie auf Kubernetes-Dashboard.
-
Wählen Sie an der Position, an der die Beispielapp ausgeführt wird, Namensbereich aus.
Kubernetes Namensraum -
Löschen Sie die zugehörigen Bereitstellungen, Services und Ingress-Ressourcen, die im ausgewählten Namensbereich aufgelistet sind.
Sie brauchen Hilfe?
IBM Cloud der KI-Assistent von IBM, der von watsonx unterstützt wird, soll Ihnen dabei helfen, sich mit der Arbeit in IBM Cloud vertraut zu machen und mithilfe des Katalogs verfügbarer Produkte und Dienstleistungen Lösungen zu entwickeln. Siehe "Hilfe vom KI-Assistenten erhalten ".
Weitere Unterstützungsoptionen finden Sie unter Hilfe und Unterstützung für Continuous Delivery.