Zugehörige Inhalte

• Einführung in Continuous Delivery
• Einführung in Cluster
• Einführung in Toolchains

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.

1. Klicken Sie auf die Bereitstellungsstrategie, die Sie für Ihre Toolchain verwenden wollen.

   

2. 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 enthält eine Beispiel -Spring-App für Java™, die einen Maven-Build verwendet. 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-Repo erstellen, das ein Klon der Inventar-Repo-Vorlage ist, oder ein bestehendes Inventar-Repo verwenden, das Sie zwischen verschiedenen Toolchains gemeinsam nutzen.

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.

VPC-Details konfigurieren

Konfigurieren Sie die Toolchain, indem Sie Informationen zu den VPC- und Virtual Server-Instanzen (VSI) angeben.

Sie haben die VPC und die VSI mithilfe von IBM Cloud® Schematics und Terraform bereitgestellt, als Sie die zu verwendende Bereitstellungsstrategie ausgewählt haben.

• Virtuelle private Cloud-Region: Wählen Sie die Region aus, in der Sie die VPC bereitgestellt haben.
• Name der virtuellen privaten Cloud: Wählen Sie die VPC aus, die Sie mithilfe der Terraform-Vorlage bereitgestellt haben. Optionen umfassen alle verfügbaren VPCs in der ausgewählten Region.
• Benutzername für VPC-Instanzen: Geben Sie den Benutzernamen an, den Sie bei der Bereitstellung der VPC-Instanz konfiguriert haben. Alle VSIs in Ihrer VPC benötigen einen Benutzernamen und einen SSH-Schlüssel, um sich anzumelden und diese Instanz bereitzustellen.
• Base64-Encoded SSH-Schlüssel für VPC-Instanzen: Geben Sie den privaten SSH-Schlüssel im Format base64-encoded für den öffentlichen SSH-Schlüssel an, den Sie beim Bereitstellen der VPC-Instanzen konfiguriert haben.

Bastionshost-Details konfigurieren

Die Terraform-Vorlage erstellt außerdem eine VSI zur Verwendung als Bastionshost. Ein Bastionshost bietet eine sichere Möglichkeit, eine Verbindung zu den VSIs in Ihrer VPC herzustellen, um Bereitstellungs- und Wartungstasks auszuführen. Der Bastionshost stellt mithilfe der Berechtigungsnachweise (Benutzername und SSH-Schlüssel), die Sie in den VPC-Details konfiguriert haben, eine Verbindung zu den VSIs über SSH her.

Für die Toolchain müssen Sie sich bei den VSIs innerhalb der VPC anmelden, um die App-Binärdatei bereitzustellen, die App zu starten und zu stoppen und die Abhängigkeit von Drittanbietern für die Ausführung der App herunterzuladen. Alle diese Tasks werden mithilfe der SSH-Tunnelung mit dem Bastionshost ausgeführt. Die Toolchain verwendet dieselben Berechtigungsnachweise für die Anmeldung beim Bastionshost, die vom Bastionshost verwendet werden, um eine Verbindung zu den VSIs herzustellen.

• Bastionshost: Wählen Sie die VSI aus, die von der Terraform-Vorlage als Bastionshost bereitgestellt wird.

Details der Lastausgleichsfunktion konfigurieren

Die Beispielapp, die auf den VSIs in Ihrer VPC bereitgestellt wird, zeigt eine einfache Webseite an Port 8080 an. Um die App mithilfe eines DNS-Namens über das Internet verfügbar zu machen und den Datenverkehr auf mehrere VSIs, die die App ausführen, zu verteilen, stellt die Terraform-Vorlage eine Lastausgleichsfunktion für Anwendungen bereit. Alle VSIs, welche die App ausführen, bilden den Back-End-Pool der Server für die Lastausgleichsfunktion.

Die Toolchain verwendet die Details für die Lastausgleichsfunktion und zwei Back-End-Pools, um den Live-App-Datenverkehr während des Blau-Grün-Bereitstellungsprozesses zu konfigurieren und umzuleiten. Der blaue Back-End-Pool und der grüne Back-End-Pool enthalten die gleiche Anzahl von VSIs. Immer nur einer der Pools bedient aktiv den Live-Datenverkehr, während der andere inaktiv bleibt, indem eine ältere Version der App ausgeführt wird. Die Lastausgleichsfunktion tauscht oder wechselt den Back-End-Pool, der den Live-Datenverkehr bei jeder Implementierung bedient. Während der blaue Back-End-Pool aktiv ist, stellt die nächste Bereitstellung die App auf VSIs im grünen Back-End-Pool bereit und macht sie aktiv, während der blaue Back-End-Pool passiv ist.

Konfigurieren Sie die Toolchain, indem Sie Informationen zur Lastausgleichsfunktion angeben:

• Name der Lastausgleichsfunktion: Wählen Sie die Anwendungslastausgleichsfunktion aus, die von der Terraform-Vorlage bereitgestellt wird.
• Name des blauen Back-End-Pools: Wählen Sie den blauen Back-End-Pool aus, den die Terraform-Vorlage für die Lastausgleichsfunktion bereitstellt.
• Name des grünen Back-End-Pools: Wählen Sie den grünen Back-End-Pool aus, den die Terraform-Vorlage für die Lastausgleichsfunktion bereitstellt.

Nachdem die Details für die deployment target-Schritte ausgefüllt wurden, fahren Sie mit dem nächsten Schritt fort.

Artefaktspeicher konfigurieren

Durch Änderungen an der Quelle wird die Continuous Integration-Pipeline ausgelöst. Wenn eine kontinuierliche Integrationsausführung erfolgreich ist, wird ein Build- oder ein binäres Artefakt erstellt und im transienten Speicher gespeichert und anschließend in den Ziel-VSIs implementiert.

Sie können IBM Cloud Object Storage verwenden, um transiente Build-Artefakte in der Toolchain zu speichern. Die Pipeline für kontinuierliche Integration erstellt die ausführbare Datei .jar für die Spring-Java-Beispielanwendung.

Alternativ können Sie Artifactory verwenden, wenn Sie über eine eigene Artifactory-Instanz verfügen.

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:

1. Klicken Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys auf das compliance-app-<timestamp>-App-Repository.
2. Erstellen Sie im Master-Repository einen Zweig.
3. Aktualisieren Sie Code in der Beispielknoten-App oder der Readme-Datei und speichern Sie diese Änderungen.
4. Übergeben Sie die Zusammenführungsanforderung.
5. Klicken Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys auf das Repositorypr-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.
6. 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:

1. Wechseln Sie zur Zusammenführungsanforderung.
2. 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.
3. 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.
4. 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.

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 Blue-Green-Bereitstellungsstrategie mithilfe der Beispiel-App funktioniert.

Blue-Green-Bereitstellung kennenlernen

Die in diesem Lernprogramm verwendete Blue-Green-Bereitstellungsstrategie veranschaulicht, wie Sie eine Bereitstellungsstrategie mit dem Continuous Delivery-Service verwenden können, um Ihre Produktionsworkloads auf VPC auszuführen. Die Continuous Delivery Pipeline stellt drei Auslöser für die Blue-Green-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.
• Wechseln Sie zwischen blauen und grünen Implementierungen für einen automatisierten Rollback.

Dieses Lernprogramm zeigt, wie die Blue-Green-Bereitstellungsstrategie mithilfe der Beispiel-App funktioniert.

1. Führen Sie den manuellen Auslöser aus der Continuous Delivery-Pipeline aus, um die erste Version der App bereitzustellen.

   

2. Suchen Sie die App-URL im Schritt release der Continuous Delivery-Pipeline und klicken Sie auf die URL, um zu überprüfen, ob die App ausgeführt wird.

   

3. Aktualisieren Sie den App-Code und bestätigen Sie Ihre Änderungen. Aktualisieren Sie für die Beispielapp die Willkommensnachricht:

   a. Klicken Sie auf der Übersichtsseite der Toolchain auf der Karte Repositorys auf das Beispiel-App-Repository.

   b. Aktualisieren Sie die Willkommensnachricht in der Datei utils.js.

   c. Warten Sie, bis die Ausführung der Pipeline für kontinuierliche Integration erfolgreich abgeschlossen wurde.

4. Führen Sie den manuellen Auslöser aus der Continuous Delivery-Pipeline aus und warten Sie, bis die Ausführung der Continuous Delivery-Pipeline erfolgreich abgeschlossen ist.

5. Überprüfen Sie die App-URL erneut, um sicherzustellen, dass die aktualisierte App bereitgestellt wurde. Beide App-Versionen werden gleichzeitig ausgeführt. Der gesamte Netzverkehr fließt zur aktualisierten App.

6. Testen Sie den Rollback, indem Sie den Auslöser switch-blue-green über die Continuous Delivery-Pipeline ausführen. Warten Sie, bis die Ausführung der Switch-Trigger-Pipeline erfolgreich abgeschlossen wurde.

   

7. Überprüfen Sie die App-URL erneut, um sicherzustellen, dass die vorherige Version der App angezeigt wird.

Sie können den Switch-Auslöser mehrmals ausführen, um zwischen der vorherigen und der neuesten Version der App zu wechseln.