CI/CD-Pipeline für Ihren Datenverarbeitungsworkflow einrichten

Last reviewed 2023-04-20 UTC

In dieser Anleitung wird beschrieben, wie Sie mit verwalteten Produkten auf Google Cloud durch Implementierung von Methoden zur kontinuierlichen Integration und kontinuierlichen Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD) eine CI/CD-Pipeline für die Datenverarbeitung einrichten. Data Scientists und Datenanalysten können die Methoden der CI/CD-Verfahren anpassen, um eine hohe Qualität, Wartbarkeit und Anpassungsfähigkeit der Datenprozesse und Workflows sicherzustellen. Sie können folgende Methoden anwenden:

Versionskontrolle des Quellcodes.
Automatisches Erstellen, Testen und Bereitstellen von Anwendungen.
Isolation der Umgebung und Abgrenzung von der Produktion.
Replizierbare Verfahren zur Einrichtung der Umgebung.

Diese Anleitung richtet sich an Data Scientists und Datenanalysten, die Datenverarbeitungsjobs zur periodischen Ausführung erstellen, um ihre Forschung und Entwicklung (F&E) so zu strukturieren, dass Arbeitslasten im Rahmen der Datenverarbeitung systematisch und automatisch verwaltet werden.

Bereitstellungsarchitektur

In dieser Anleitung verwenden Sie die folgenden Google Cloud-Produkte:

Cloud Build zur Einrichtung einer CI/CD-Pipeline zum Erstellen, Bereitstellen und Testen eines Datenverarbeitungsworkflows sowie der Datenverarbeitung selbst. Cloud Build ist ein verwalteter Dienst, mit dem Ihr Build auf Google Cloud ausgeführt wird. Ein Build setzt sich aus einer Reihe von Build-Schritten zusammen, die jeweils in einem Docker-Container ausgeführt werden.
Cloud Composer zum Definieren und Ausführen der Workflowschritte, z. B. Starten der Datenverarbeitung, Testen und Überprüfen der Ergebnisse. Cloud Composer ist ein verwalteter Apache Airflow-Dienst, der eine Umgebung bereitstellt, in der Sie komplexe Workflows erstellen, planen, überwachen und verwalten können, z. B. den Datenverarbeitungsworkflow in dieser Anleitung.
Dataflow zum Ausführen des WordCount-Beispiels für Apache Beam zur Veranschaulichung eines Datenprozesses.

CI/CD-Pipeline

Im Großen und Ganzen setzt sich die CI/CD-Pipeline aus den folgenden Schritten zusammen:

Cloud Build verpackt das WordCount-Beispiel mithilfe des Maven-Builders in einer selbstausführenden Java Archive(JAR)-Datei. Der Maven-Builder ist ein Container, in dem Maven installiert ist. Wenn ein Build-Schritt für die Verwendung des Maven-Builders konfiguriert ist, werden die Aufgaben von Maven ausgeführt.
Cloud Build lädt die JAR-Datei in Cloud Storage hoch.
Cloud Build führt für den Code des Datenverarbeitungsworkflows Einheitentests aus und stellt den Workflowcode für Cloud Composer bereit.
Cloud Composer ruft die JAR-Datei ab und führt den Datenverarbeitungsjob in Dataflow aus.

Im folgenden Diagramm sind die Schritte der CI/CD-Pipeline ausführlich dargestellt:

Architekturdiagramm der CI/CD-Pipeline

In dieser Anleitung werden die Bereitstellungen für die Test- und Produktionsumgebung in zwei verschiedene Cloud Build-Pipelines unterteilt – eine Test- und eine Produktionspipeline.

Die Testpipeline im vorangegangenen Diagramm setzt sich aus den folgenden Schritten zusammen:

Ein Entwickler übergibt Änderungen am Code an Cloud Source Repositories.
Die Änderungen lösen in Cloud Build einen Test-Build aus.
Cloud Build erstellt die selbstausführende JAR-Datei und stellt sie im JAR-Test-Bucket in Cloud Storage bereit.
Cloud Build stellt die Testdateien in den Testdatei-Buckets in Cloud Storage bereit.
Cloud Build stellt die Variable in Cloud Composer so ein, dass sie auf die neu bereitgestellte JAR-Datei verweist.
Cloud Build testet den gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) für den Datenverarbeitungsworkflow und stellt ihn im Cloud Composer-Bucket in Cloud Storage bereit.
Die Workflow-DAG-Datei wird in Cloud Composer bereitgestellt.
Cloud Build löst den neu bereitgestellten Datenverarbeitungsworkflow aus.
Wenn der Integrationstest des Datenverarbeitungs-Workflows bestanden wurde, wird eine Nachricht an Pub/Sub veröffentlicht, die im Datenfeld der Nachricht einen Verweis auf das letzte selbstausführende JAR (aus den Airflow-Variablen) enthält.

Die Produktionspipeline im vorangegangenen Diagramm setzt sich aus den folgenden Schritten zusammen:

Die Pipeline für die Produktionsbereitstellung wird ausgelöst, wenn eine Nachricht in einem Pub/Sub-Thema veröffentlicht wird.
Ein Entwickler genehmigt die Pipeline für die Produktionsbereitstellung manuell und der Build wird ausgeführt.
Cloud Build kopiert die neueste selbstausführende JAR-Datei aus dem JAR-Test-Bucket in den JAR-Produktions-Bucket in Cloud Storage.
Cloud Build testet den Produktionsdatenverarbeitungs-Workflow-DAG und stellt ihn im Cloud Composer-Bucket in Cloud Storage bereit.
Die Produktionsworkflow-DAG-Datei wird in Cloud Composer bereitgestellt.

In dieser Anleitung wird der Produktionsdatenverarbeitungs-Workflow in derselben Cloud Composer-Umgebung wie der Testworkflow bereitgestellt, um eine konsolidierte Ansicht aller Datenverarbeitungsworkflows zu erhalten. Für die Zwecke dieser Anleitung werden die Umgebungen mithilfe verschiedener Cloud Storage-Buckets getrennt, in denen die Eingabe- und Ausgabedaten abgelegt werden.

Zur vollständigen Trennung der Umgebungen müssen in verschiedenen Projekten mehrere Cloud Composer-Umgebungen erstellt werden, die standardmäßig voneinander getrennt sind. Diese Trennung trägt zum Schutz der Produktionsumgebung bei. Dieser Ansatz wird in dieser Anleitung nicht weiter erörtert. Weitere Informationen zum Zugriff auf Ressourcen in mehreren Google Cloud-Projekten finden Sie unter Dienstkontoberechtigungen festlegen.

Datenverarbeitungsworkflow

Die Anleitung zum Ausführen des Datenverarbeitungsworkflows in Cloud Composer ist in einem in Python geschriebenen gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) definiert. Im DAG werden alle Schritte des Datenverarbeitungsworkflows zusammen mit ihren jeweiligen Abhängigkeiten untereinander definiert.

Die CI/CD-Pipeline stellt die DAG-Definition aus Cloud Source Repositories automatisch in jedem Build in Cloud Composer bereit. Durch diese Vorgehensweise wird dafür gesorgt, dass Cloud Composer immer die neueste Workflowdefinition hat, ohne dass der Nutzer sich darum kümmern muss.

In der DAG-Definition für die Testumgebung ist neben dem Datenverarbeitungsworkflow ein End-to-End-Testschritt festgelegt. Dieser sorgt dafür, dass der Datenverarbeitungsworkflow ordnungsgemäß ausgeführt wird.

Im folgenden Diagramm ist der Datenverarbeitungsworkflow dargestellt.

Datenverarbeitungsworkflow in vier Schritten

Der Datenverarbeitungsworkflow umfasst die folgenden Schritte:

Ausführung des WordCount-Datenprozesses in Dataflow.
Herunterladen der Ausgabedateien aus dem WordCount-Prozess. Der WordCount-Prozess gibt drei Dateien aus:
- download_result_1
- download_result_2
- download_result_3
Herunterladen der Referenzdatei mit dem Namen download_ref_string.
Prüfen des Ergebnisses anhand der Referenzdatei. Bei diesem Integrationstest werden alle drei Ergebnisse zusammengefasst und die zusammengefassten Ergebnisse mit der Referenzdatei verglichen.
Veröffentlichen Sie eine Nachricht an Pub/Sub, nachdem der Integrationstest bestanden wurde.

Durch die Verwendung eines Frameworks zur Aufgabenorchestrierung wie Cloud Composer zum Verwalten des Datenverarbeitungsworkflows lässt sich der Code für den Workflow vereinfachen.

Tests

Neben dem Integrationstest, mit dem eine End-to-End-Überprüfung des Datenverarbeitungsworkflows vorgenommen wird, werden in dieser Anleitung zwei Einheitentests behandelt. Bei den Einheitentests handelt es sich um automatische Tests des Codes für die Datenverarbeitung und des Codes für den Datenverarbeitungsworkflow. Der Test des Codes für die Datenverarbeitung ist in Java geschrieben und wird automatisch während des Maven-Build-Prozesses ausgeführt. Der Test des Codes für den Datenverarbeitungsworkflow ist in Python geschrieben und wird als eigenständiger Build-Schritt ausgeführt.

Ziele

Cloud Composer-Umgebung konfigurieren.
Cloud Storage-Buckets für Ihre Daten erstellen.
Build-, Test- und Produktionspipelines erstellen.
Build-Trigger konfigurieren.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build, Cloud Source Repositories, Cloud Composer, and Dataflow APIs.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Cloud Build, Cloud Source Repositories, Cloud Composer, and Dataflow APIs.

Enable the APIs

Beispielcode

Der Beispielcode befindet sich in zwei Ordnern:

Der Ordner env-setup enthält Shell-Skripts für die Ersteinrichtung der Google Cloud-Umgebung.
Der Ordner source-code enthält den Code, der im Laufe der Zeit entwickelt wird, von der Quelle gesteuert werden muss und automatische Build- und Testprozesse auslöst. In diesem Ordner gibt es folgende Unterordner:
- Der Ordner data-processing-code enthält den Apache Beam-Prozessquellcode.
- Der Ordner workflow-dag enthält die Composer-DAG-Definitionen für die Datenverarbeitungsworkflows mit den Schritten für das Entwerfen, Einbinden und Testen des Dataflow-Prozesses.
- Der Ordner build-pipeline enthält zwei Cloud Build-Konfigurationen – eine für die Testpipeline und eine für die Produktionspipeline. Er enthält auch ein Supportskript für die Pipelines.

Für die Zwecke dieser Anleitung befinden sich die Quellcodedateien für die Datenverarbeitung und für den DAG-Workflow in verschiedenen Ordnern im selben Quellcode-Repository. In einer Produktionsumgebung befinden sich die Quellcodedateien in der Regel in eigenen Quellcode-Repositories und werden von verschiedenen Teams verwaltet.

Umgebung einrichten

In dieser Anleitung führen Sie alle Befehle in Cloud Shell aus. Cloud Shell wird am unteren Rand der Google Cloud Console als Fenster angezeigt.

Öffnen Sie Cloud Shell in der Google Cloud Console:

Cloud Shell öffnen

Klonen Sie das Beispielcode-Repository:

git clone https://github.com/GoogleCloudPlatform/ci-cd-for-data-processing-workflow.git

Führen Sie ein Skript aus, um Umgebungsvariablen festzulegen:
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
source set_env.sh
```
Mit dem Skript werden die folgenden Umgebungsvariablen festgelegt:
- Ihre Google Cloud-Projekt-ID.
- Ihre Region und Ihre Zone.
- Der Name Ihrer Cloud Storage-Buckets, die von der Build-Pipeline und dem Datenverarbeitungsworkflow verwendet werden.
Da Umgebungsvariablen zwischen Sitzungen nicht beibehalten werden, müssen Sie sie zurücksetzen, wenn Ihre Cloud Shell-Sitzung während der Arbeit mit der Anleitung beendet oder getrennt wird.

Cloud Composer-Umgebung erstellen

In dieser Anleitung richten Sie eine Cloud Composer-Umgebung ein.

Fügen Sie in Cloud Shell die Rolle Cloud Composer v2 API Dienst-Agent Extension (roles/composer.ServiceAgentV2Ext) zum Konto des Cloud Composer Dienst-Agents hinzu:

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member serviceAccount:service-$PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

Erstellen Sie in Cloud Shell die Cloud Composer-Umgebung:
```
gcloud composer environments create $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --image-version composer-2.0.14-airflow-2.2.5
```
Hinweis: Das Bereitstellen der Cloud Composer-Umgebung erfolgt in der Regel innerhalb von etwa 15 Minuten, kann jedoch bis zu einer Stunde dauern. Warten Sie, bis dieser Vorgang abgeschlossen ist, bevor Sie mit den nächsten Schritten fortfahren.
Führen Sie ein Skript aus, um die Variablen in der Cloud Composer-Umgebung festzulegen. Die Variablen werden für die Datenverarbeitungs-DAGs benötigt.
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
chmod +x set_composer_variables.sh
./set_composer_variables.sh
```
Mit dem Skript werden die folgenden Umgebungsvariablen festgelegt:
- Ihre Google Cloud-Projekt-ID.
- Ihre Region und Ihre Zone.
- Der Name Ihrer Cloud Storage-Buckets, die von der Build-Pipeline und dem Datenverarbeitungsworkflow verwendet werden.

Cloud Composer-Umgebungsattribute extrahieren

Cloud Composer verwendet zum Speichern von DAGs einen Cloud Storage-Bucket. Wenn Sie eine DAG-Definitionsdatei in den Bucket verschieben, werden die Dateien automatisch von Cloud Composer gelesen. Sie haben den Cloud Storage-Bucket für Cloud Composer bei der Erstellung der Cloud Composer-Umgebung erstellt. Beim folgenden Verfahren extrahieren Sie die URL für die Buckets und konfigurieren dann die CI/CD-Pipeline so, dass DAG-Definitionen für den Cloud Storage-Bucket automatisch bereitgestellt werden.

Exportieren Sie in Cloud Shell die URL für den Bucket als Umgebungsvariable:

export COMPOSER_DAG_BUCKET=$(gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.dagGcsPrefix)")

Exportieren Sie den Namen des Dienstkontos, das Cloud Composer verwendet, um Zugriff auf die Cloud Storage-Buckets zu erhalten:

export COMPOSER_SERVICE_ACCOUNT=$(gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.nodeConfig.serviceAccount)")

Cloud Storage-Buckets erstellen

In diesem Abschnitt erstellen Sie eine Reihe von Cloud Storage-Buckets, um Folgendes zu speichern:

Artefakte der Zwischenschritte des Build-Prozesses.
Die Ein- und Ausgabedateien für den Datenverarbeitungsworkflow.
Den Staging-Speicherort für die Dataflow-Jobs zum Speichern von Binärdateien.

So erstellen Sie Cloud Storage-Buckets:

Erstellen Sie in Cloud Shell Cloud Storage-Buckets und erteilen Sie dem Cloud Composer-Dienstkonto die Berechtigung zum Ausführen der Datenverarbeitungsworkflows:
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
chmod +x create_buckets.sh
./create_buckets.sh
```

Pub/Sub-Thema erstellen

In diesem Abschnitt erstellen Sie ein Pub/Sub-Thema, um Nachrichten zu empfangen, die vom Integrationstest des Datenverarbeitungsworkflows gesendet wurden, um automatisch die Produktions-Build-Pipeline auszulösen.

Öffnen Sie in der Google Cloud Console die Seite Pub/Sub-Themen.

Zur Seite „Themen“
Klicken Sie auf Thema erstellen.
So konfigurieren Sie das Thema:
- Geben Sie als Themen-ID integration-test-complete-topic ein.
- Prüfen Sie, ob die Option Standardabo hinzufügen aktiviert ist.
- Lassen Sie die anderen Optionen deaktiviert.
- Wählen Sie für Verschlüsselung die Option Von Google verwalteter Verschlüsselungsschlüssel aus.
- Klicken Sie auf Thema erstellen.

Quellcode per Push an Cloud Source Repositories übertragen

In dieser Anleitung haben Sie eine einzelne Quellcodebasis, für die Sie eine Versionskontrolle durchführen müssen. Mit dem folgenden Schritt wird gezeigt, wie eine Codebasis entwickelt wird und sich mit der Zeit verändert. Immer wenn Änderungen per Push an das Repository übertragen werden, wird die Build-, Bereitstellungs- und Testpipeline ausgelöst.

Übertragen Sie in Cloud Shell den Ordner source-code per Push in Cloud Source Repositories:

gcloud source repos create $SOURCE_CODE_REPO
cp -r ~/ci-cd-for-data-processing-workflow/source-code ~/$SOURCE_CODE_REPO
cd ~/$SOURCE_CODE_REPO
git init
git remote add google \
    https://source.developers.google.com/p/$GCP_PROJECT_ID/r/$SOURCE_CODE_REPO
git add .
git commit -m 'initial commit'
git push google master

Dies sind Standardbefehle zum Initialisieren von Git in einem neuen Verzeichnis und zum Übertragen des Inhalts per Push in ein Remote-Repository.

Cloud Build-Pipelines erstellen

In diesem Abschnitt erstellen Sie die Build-Pipelines, mit denen der Datenverarbeitungsworkflow erstellt, bereitgestellt und getestet wird.

Zugriff auf Cloud Build-Dienstkonto gewähren

Cloud Build stellt Cloud Composer-DAGs bereit und löst Workflows aus, die aktiviert werden, wenn Sie zusätzlich Zugriff auf das Cloud Build-Dienstkonto gewähren. Weitere Informationen zu den verschiedenen verfügbaren Rollen bei der Arbeit mit Cloud Composer finden Sie in der Dokumentation zur Zugriffssteuerung.

Fügen Sie in Cloud Shell dem Cloud Build-Dienstkonto die Rolle composer.admin hinzu, damit der Cloud Build-Job Airflow-Variablen in Cloud Composer festlegen kann:

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role=roles/composer.admin

Fügen Sie dem Cloud Build-Dienstkonto die Rolle composer.worker hinzu, damit der Cloud Build-Job den Datenworkflow in Cloud Composer auslösen kann:

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role=roles/composer.worker

Build- und Testpipeline erstellen

Die Schritte der Build- und Testpipeline werden in der YAML-Konfigurationsdatei konfiguriert. In dieser Anleitung verwenden Sie vorkonfigurierte Builder-Images für git, maven, gsutil und gcloud, um die Aufgaben in den einzelnen Build-Schritten auszuführen. Sie verwenden Substitutionen für Konfigurationsvariablen, um bei der Erstellung die Umgebungseinstellungen zu definieren. Der Speicherort des Quellcode-Repositorys wird durch Variablensubstitutionen sowie die Speicherorte der Cloud Storage-Buckets definiert. Diese Informationen werden vom Build benötigt, um die JAR-Datei, die Testdateien und die DAG-Definition bereitzustellen.

Senden Sie in Cloud Shell die Konfigurationsdatei für die Build-Pipeline, um die Pipeline in Cloud Build zu erstellen:
```
cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline
gcloud builds submit --config=build_deploy_test.yaml --substitutions=\
REPO_NAME=$SOURCE_CODE_REPO,\
_DATAFLOW_JAR_BUCKET=$DATAFLOW_JAR_BUCKET_TEST,\
_COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_TEST,\
_COMPOSER_REF_BUCKET=$REF_BUCKET_TEST,\
_COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\
_COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\
_COMPOSER_REGION=$COMPOSER_REGION,\
_COMPOSER_DAG_NAME_TEST=$COMPOSER_DAG_NAME_TEST
```
Mit diesem Befehl wird Cloud Build angewiesen, einen Build mit den folgenden Schritten auszuführen:
1. Erstellen und Bereitstellen einer selbstausführenden JAR-WordCount-Datei.
  1. Überprüfen des Quellcodes.
  2. Kompilieren des WordCount-Beam-Quellcodes in eine selbstausführende JAR-Datei.
  3. Speichern der JAR-Datei in Cloud Storage, wo sie von Cloud Composer zur Ausführung des WordCount-Verarbeitungsjobs abgerufen werden kann.
2. Bereitstellen und Einrichten des Datenverarbeitungsworkflows in Cloud Composer.
  1. Ausführen des Einheitentests für den vom Workflow-DAG verwendeten Code mit benutzerdefinierten Operatoren.
  2. Bereitstellen der Testeingabedatei und der Testreferenzdatei in Cloud Storage. Die Testeingabedatei ist die Eingabe für den WordCount-Verarbeitungsjob. Die Testreferenzdatei wird als Referenz verwendet, um die Ausgabe des WordCount-Verarbeitungsjobs zu überprüfen.
  3. Festlegen der Cloud Composer-Variablen, damit sie auf die neu erstellte JAR-Datei verweisen.
  4. Bereitstellen der Workflow-DAG-Definition in der Cloud Composer-Umgebung.
3. Ausführen des Datenverarbeitungsworkflows in der Testumgebung zum Auslösen des Testverarbeitungsworkflows.

Build- und Testpipeline überprüfen

Überprüfen Sie nach dem Senden der Build-Datei die Build-Schritte.

Rufen Sie in der Google Cloud Console die Seite Build-Verlauf auf, um eine Liste aller bisherigen und aktuell ausgeführten Builds zu sehen.

Zur Seite "Build-Verlauf"
Klicken Sie auf den Build, der gerade ausgeführt wird.
Prüfen Sie auf der Seite Build-Details, ob die Build-Schritte mit den zuvor beschriebenen Schritten übereinstimmen.

Auf der Seite Build-Details wird im Feld Status des Builds Build successful angegeben, wenn der Build fertiggestellt ist.

Prüfen Sie in Cloud Shell, ob die JAR-WordCount-Beispieldatei in den richtigen Bucket kopiert wurde:

gsutil ls gs://$DATAFLOW_JAR_BUCKET_TEST/dataflow_deployment*.jar

Die Ausgabe sieht etwa so aus:

gs://…-composer-dataflow-source-test/dataflow_deployment_e88be61e-50a6-4aa0-beac-38d75871757e.jar

Rufen Sie die URL zur Cloud Composer-Weboberfläche auf. Notieren Sie sich die URL, da sie im nächsten Schritt verwendet wird.

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.airflowUri)"

Wechseln Sie mit der URL aus dem vorangegangenen Schritt zur Cloud Composer-UI und überprüfen Sie, ob der DAG erfolgreich ausgeführt wurde. Wenn in der Spalte Ausführungen keine Informationen angezeigt werden, warten Sie einige Minuten und laden Sie die Seite noch einmal.
1. Halten Sie den Mauszeiger über den hellgrünen Kreis unter Ausführungen und prüfen Sie, ob der Datenverarbeitungs-Workflow DAG test_word_count bereitgestellt wurde und sich im Ausführungsmodus befindet, und stellen Sie sicher, dass dort Wird ausgeführt steht.
2. Klicken Sie auf den hellgrünen Kreis und anschließend auf der Seite DAG-Ausführungen auf DAG-ID: test_word_count, um sich den ausgeführten Datenverarbeitungsworkflow als Diagramm anzeigen zu lassen.
3. Laden Sie die Seite Graphansicht noch einmal, um den Status der aktuellen DAG-Ausführung zu aktualisieren. In der Regel dauert es drei bis fünf Minuten, bis der Workflow abgeschlossen ist. Halten Sie den Mauszeiger über die einzelnen Aufgaben, um zu prüfen, ob die DAG-Ausführung erfolgreich abgeschlossen wurde. In diesem Fall wird als Kurzinfo Status: Erfolgreich angegeben. Die vorletzte Aufgabe mit dem Namen do_comparison ist der Integrationstest, mit dem die Prozessausgabe anhand der Referenzdatei geprüft wird.
Nach Abschluss des Integrationstests veröffentlicht die letzte Aufgabe mit dem Namen publish_test_complete eine Nachricht im Pub/Sub-Thema integration-test-complete-topic, was zum Auslösen der Produktions-Build-Pipeline verwendet wird.
1. Um zu prüfen, ob die veröffentlichte Nachricht den richtigen Verweis auf die neueste JAR-Datei enthält, können Sie die Nachricht aus dem Standard-Pub/Sub-Abo integration-test-complete-topic-sub abrufen.
2. Öffnen Sie in der Google Cloud Console die Seite Abos.
  
  Zur Seite „Abos“
3. Klicken Sie auf integration-test-complete-topic-sub, wählen Sie den Tab Nachricht aus und klicken Sie auf Pull.
4. Die Ausgabe sollte in etwa so aussehen:

Produktionspipeline erstellen

Wenn der Testverarbeitungsworkflow erfolgreich ausgeführt wird, können Sie die aktuelle Version des Workflows zur Produktion hochstufen. Es gibt verschiedene Möglichkeiten, den Workflow für die Produktion bereitzustellen:

Manuell.
Automatische Auslösung, wenn alle Tests in der Test- oder Staging-Umgebung erfolgreich abgeschlossen wurden.
Automatische Auslösung durch einen geplanten Job.

In dieser Anleitung lösen Sie automatisch den Produktions-Build aus, wenn alle Tests in der Testumgebung bestanden wurden. Weitere Informationen zu automatisierten Ansätzen finden Sie unter Release-Engineering.

Bevor Sie den automatisierten Ansatz implementieren, prüfen Sie den Build der Produktionsbereitstellung, indem Sie eine manuelle Bereitstellung für die Produktion ausführen. Der Produktionsbereitstellungs-Build umfasst folgende Schritte:

Kopieren der JAR-WordCount-Datei aus dem Test-Bucket in den Produktions-Bucket.
Festlegen der Cloud Composer-Variablen für den Produktionsworkflow, sodass sie auf die neu heraufgestufte JAR-Datei verweisen.
Bereitstellen der DAG-Definition für den Produktionsworkflow in der Cloud Composer-Umgebung und Ausführen des Workflows.

Variablensubstitutionen definieren den Namen der neuesten JAR-Datei, die mit den vom Produktionsverarbeitungsworkflow verwendeten Cloud Storage-Buckets für die Produktion bereitgestellt wird. Führen Sie die folgenden Schritte aus, um die Cloud Build-Pipeline zu erstellen, die den Airflow-Workflow für die Produktion bereitstellt:

Lesen Sie in Cloud Shell den Dateinamen der neuesten JAR-Datei, indem Sie die Cloud Composer-Variable für den JAR-Dateinamen ausgeben lassen:

export DATAFLOW_JAR_FILE_LATEST=$(gcloud composer environments run $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION variables get -- \
    dataflow_jar_file_test 2>&1 | grep -i '.jar')

Verwenden Sie die Konfigurationsdatei für die Build-Pipeline, deploy_prod.yaml,, um die Pipeline in Cloud Build zu erstellen:

cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline
gcloud builds submit --config=deploy_prod.yaml --substitutions=\
REPO_NAME=$SOURCE_CODE_REPO,\
_DATAFLOW_JAR_BUCKET_TEST=$DATAFLOW_JAR_BUCKET_TEST,\
_DATAFLOW_JAR_FILE_LATEST=$DATAFLOW_JAR_FILE_LATEST,\
_DATAFLOW_JAR_BUCKET_PROD=$DATAFLOW_JAR_BUCKET_PROD,\
_COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_PROD,\
_COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\
_COMPOSER_REGION=$COMPOSER_REGION,\
_COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\
_COMPOSER_DAG_NAME_PROD=$COMPOSER_DAG_NAME_PROD

Von der Produktionspipeline erstellten Datenverarbeitungsworkflow prüfen

Rufen Sie die URL für Ihre Cloud Composer-UI ab:

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.airflowUri)"

Wechseln Sie zu der im vorangegangenen Schritt abgerufenen URL, um zu prüfen, ob der Workflow-DAG zur Produktionsdatenverarbeitung bereitgestellt wurde. In diesem Fall wird in der Liste der DAGs der DAG prod_word_count angezeigt.
1. Klicken Sie auf der Seite DAGs in der Zeile prod_word_count auf DAG auslösen.
Klicken Sie auf das Airflow-Logo oder aktualisieren Sie die Seite, um den DAG-Ausführungsstatus zu aktualisieren. Ein hellgrüner Kreis in der Spalte Ausführungen gibt an, dass der DAG derzeit ausgeführt wird. Halten Sie den Mauszeiger auf den Kreis, um die Kurzinfo mit dem Text Aktiv zu sehen.
Halten Sie den Mauszeiger nach erfolgreicher Ausführung über den dunkelgrünen Kreis unter der Spalte DAG runs (DAG-Ausführungen) und prüfen Sie, ob Erfolgreich angezeigt wird.

Listen Sie in Cloud Shell die Ergebnisdateien im Cloud Storage-Bucket auf:

gsutil ls gs://$RESULT_BUCKET_PROD

Die Ausgabe sieht etwa so aus:

gs://…-composer-result-prod/output-00000-of-00003
gs://…-composer-result-prod/output-00001-of-00003
gs://…-composer-result-prod/output-00002-of-00003

Cloud Build-Trigger erstellen

In diesem Abschnitt erstellen Sie die Cloud Build-Trigger, die die Quellcodeänderungen mit dem Test-Build-Prozess und zwischen der Testpipeline und der Produktions-Build-Pipeline verknüpfen.

Pipeline-Trigger eines Test-Build konfigurieren

Sie richten einen Cloud Build-Trigger ein, der einen neuen Build auslöst, wenn Änderungen per Push an den Master-Branch des Quell-Repositorys übertragen werden.

Rufen Sie in der Google Cloud Console die Seite Build-Trigger auf.

Zur Seite "Build-Trigger"
Klicken Sie auf Trigger erstellen.
Führen Sie die folgenden Schritte aus, um die Triggereinstellungen zu konfigurieren:
- Geben Sie im Feld Name trigger-build-in-test-environment ein.
- Wählen Sie im Drop-down-Menü Region die Option global (nicht regional) aus.
- Wählen Sie für Ereignis die Option Per Push zu Zweig übertragen aus.
- Wählen Sie für Quelle die Option data-pipeline-source aus.
- Geben Sie im Feld Zweig-Name master ein.
- Klicken Sie unter Konfiguration auf Cloud Build-Konfigurationsdatei (YAML oder JSON).
- Klicken Sie unter Speicherort auf Repository.
- Geben Sie für den Speicherort der Cloud Build-Konfigurationsdatei build-pipeline/build_deploy_test.yaml ein.

Führen Sie in Cloud Shell den folgenden Befehl aus, um alle für den Build erforderlichen Substitutionsvariablen abzurufen. Notieren Sie sich diese Werte, da sie in einem späteren Schritt benötigt werden.

echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET}
_COMPOSER_DAG_NAME_TEST : ${COMPOSER_DAG_NAME_TEST}
_COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME}
_COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_TEST}
_COMPOSER_REF_BUCKET : ${REF_BUCKET_TEST}
_COMPOSER_REGION : ${COMPOSER_REGION}
_DATAFLOW_JAR_BUCKET : ${DATAFLOW_JAR_BUCKET_TEST}"

Hinweis: Für den folgenden Schritt wird das Name/Wert-Paar der Ausgabe verwendet.

Ersetzen Sie auf der Seite Triggereinstellungen unter Erweitert, Substitutionsvariablen die Variablen durch Werte aus Ihrer Umgebung, die Sie im vorherigen Schritt erhalten haben. Fügen Sie nacheinander die folgenden Einträge hinzu und klicken Sie für jedes Name/Wert-Paar auf + Element hinzufügen.
- _COMPOSER_DAG_BUCKET
- _COMPOSER_DAG_NAME_TEST
- _COMPOSER_ENV_NAME
- _COMPOSER_INPUT_BUCKET
- _COMPOSER_REF_BUCKET
- _COMPOSER_REGION
- _DATAFLOW_JAR_BUCKET
Klicken Sie auf Erstellen.

Pipeline-Trigger eines Build für die Produktion konfigurieren

Sie richten einen Cloud Build-Trigger ein, der einen Produktions-Build auslöst, wenn die Tests in der Testumgebung bestanden wurden und eine Nachricht im Pub/Sub-Thema tests-complete veröffentlicht wird. Dieser Trigger enthält einen Genehmigungsschritt, bei dem der Build manuell genehmigt werden muss, bevor die Produktionspipeline ausgeführt wird.

Rufen Sie in der Google Cloud Console die Seite Build-Trigger auf.

Zur Seite "Build-Trigger"
Klicken Sie auf Trigger erstellen.
Führen Sie die folgenden Schritte aus, um die Triggereinstellungen zu konfigurieren:
- Geben Sie im Feld Name trigger-build-in-prod-environment ein.
- Wählen Sie im Drop-down-Menü Region die Option global (nicht regional) aus.
- Klicken Sie unter Ereignis auf Pub/Sub-Nachricht.
- Wählen Sie als Abo integration-test-complete-topic aus.
- Wählen Sie für Quelle die Option data-pipeline-source aus.
- Wählen Sie für Überarbeitung die Option Zweig aus.
- Geben Sie im Feld Zweig-Name master ein.
- Klicken Sie unter Konfiguration auf Cloud Build-Konfigurationsdatei (YAML oder JSON).
- Klicken Sie unter Speicherort auf Repository.
- Geben Sie für den Speicherort der Cloud Build-Konfigurationsdatei build-pipeline/deploy_prod.yaml ein.

echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET}
_COMPOSER_DAG_NAME_PROD : ${COMPOSER_DAG_NAME_PROD}
_COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME}
_COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_PROD}
_COMPOSER_REGION : ${COMPOSER_REGION}
_DATAFLOW_JAR_BUCKET_PROD : ${DATAFLOW_JAR_BUCKET_PROD}
_DATAFLOW_JAR_BUCKET_TEST : ${DATAFLOW_JAR_BUCKET_TEST}"

Hinweis: Für den folgenden Schritt wird das Name/Wert-Paar der Ausgabe verwendet.

Ersetzen Sie auf der Seite Triggereinstellungen unter Erweitert, Substitutionsvariablen die Variablen durch Werte aus Ihrer Umgebung, die Sie im vorherigen Schritt erhalten haben. Fügen Sie nacheinander die folgenden Einträge hinzu und klicken Sie für jedes Name/Wert-Paar auf + Element hinzufügen.
- _COMPOSER_DAG_BUCKET
- _COMPOSER_DAG_NAME_PROD
- _COMPOSER_ENV_NAME
- _COMPOSER_INPUT_BUCKET
- _COMPOSER_REGION
- _DATAFLOW_JAR_BUCKET_PROD
- _DATAFLOW_JAR_BUCKET_TEST
- _DATAFLOW_JAR_FILE_LATEST = $(body.message.data)
Aktivieren Sie für Genehmigung die Option Genehmigung vor der Ausführung des Builds erforderlich.
Klicken Sie auf Erstellen.

Trigger testen

Fügen Sie ein neues Wort zur Testeingabedatei hinzu und nehmen Sie die entsprechende Anpassung an der Testreferenzdatei vor, um den Trigger zu testen. Überprüfen Sie, ob die Build-Pipeline per Commit und Push an Cloud Source Repositories ausgelöst wird und der Datenverarbeitungsworkflow mit den aktualisierten Testdateien ordnungsgemäß ausgeführt wird.

Fügen Sie in Cloud Shell am Ende der Testdatei ein Testwort hinzu:

echo "testword" >>  ~/$SOURCE_CODE_REPO/workflow-dag/support-files/input.txt

Aktualisieren Sie die Referenzdatei für Testergebnisse, ref.txt, um sie mit den Änderungen in der Testeingabedatei abzugleichen:
```
echo "testword: 1" >>  ~/$SOURCE_CODE_REPO/workflow-dag/support-files/ref.txt
```

Führen Sie für die Änderungen einen Commit und Push an Cloud Source Repositories durch:

cd ~/$SOURCE_CODE_REPO
git add .
git commit -m 'change in test files'
git push google master

Öffnen Sie in der Google Cloud Console die Seite Verlauf.

ZUR SEITE "VERLAUF"
Überprüfen Sie, ob für den derzeit ausgeführten Build in der Spalte Ref der Wert master angezeigt wird, um zu bestätigen, dass ein neuer Test-Build durch den vorherigen Push zum Master-Zweig ausgelöst wird.

Rufen Sie in Cloud Shell die URL für die Cloud Composer-Weboberfläche ab:

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION --format="get(config.airflowUri)"

Wechseln Sie nach Fertigstellung des Builds zur URL aus dem vorangegangenen Befehl, um zu prüfen, ob der DAG test_word_count ausgeführt wird.

Warten Sie, bis die DAG-Ausführung beendet ist. Dies ist daran zu erkennen, dass der hellgrüne Kreis in der Spalte DAG Runs (DAG-Ausführungen) nicht mehr sichtbar ist. In der Regel dauert es drei bis fünf Minuten, bis der Vorgang abgeschlossen ist.

Laden Sie in Cloud Shell die Testergebnisdateien herunter:

mkdir ~/result-download
cd ~/result-download
gsutil cp gs://$RESULT_BUCKET_TEST/output* .

Überprüfen Sie, ob das neu hinzugefügte Wort in einer der Ergebnisdateien enthalten ist:
```
grep testword output*
```
Die Ausgabe sieht etwa so aus:
```
output-00000-of-00003:testword: 1
```
Öffnen Sie in der Google Cloud Console die Seite Verlauf.

Zur Seite "Verlauf"
Prüfen Sie, ob ein neuer Produktions-Build durch den Abschluss des Integrationstests ausgelöst wurde und ob der Build auf die Genehmigung wartet.
Klicken Sie auf das Kästchen neben dem Build, dann auf Genehmigen und dann im Bestätigungsfeld auf Genehmigen, um die Produktions-Build-Pipeline auszuführen.
Wechseln Sie nach Abschluss des Builds zur URL vom vorherigen Befehl und lösen Sie den DAG prod_word_count manuell aus, um die Produktionspipeline auszuführen.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Einzelne Ressourcen löschen

Wenn Sie das für diese Anleitung verwendete Projekt behalten möchten, führen Sie die folgenden Schritte aus, um die in dieser Anleitung erstellten Ressourcen zu löschen.

Führen Sie die folgenden Schritte aus, um den Cloud Build-Trigger zu löschen:
1. Öffnen Sie in der Google Cloud Console die Seite Trigger.
  
  Zur Seite "Trigger"
2. Klicken Sie neben dem erstellten Trigger auf das Dreipunkt-Menü und anschließend auf Löschen.

Löschen Sie in Cloud Shell die Cloud Composer-Umgebung:

gcloud -q composer environments delete $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION

Löschen Sie die Cloud Storage-Buckets und die zugehörigen Dateien:

gsutil -m rm -r gs://$DATAFLOW_JAR_BUCKET_TEST \
    gs://$INPUT_BUCKET_TEST \
    gs://$REF_BUCKET_TEST \
    gs://$RESULT_BUCKET_TEST \
    gs://$DATAFLOW_STAGING_BUCKET_TEST \
    gs://$DATAFLOW_JAR_BUCKET_PROD \
    gs://$INPUT_BUCKET_PROD \
    gs://$RESULT_BUCKET_PROD \
    gs://$DATAFLOW_STAGING_BUCKET_PROD

Führen Sie die folgenden Befehle in Cloud Shell aus, um das Pub/Sub-Thema und Standardabo zu löschen:

gcloud pubsub topics delete integration-test-complete-topic
gcloud pubsub subscriptions delete integration-test-complete-topic-sub

Löschen Sie das Repository:

gcloud -q source repos delete $SOURCE_CODE_REPO

Löschen Sie die von Ihnen erstellten Dateien und Ordner:

rm -rf ~/ci-cd-for-data-processing-workflow
rm -rf ~/$SOURCE_CODE_REPO
rm -rf ~/result-download

Weitere Informationen

Mehr über kontinuierliche Bereitstellung im GitOps-Stil mit Cloud Build erfahren
Mehr über die Automatisierung der Infrastruktur mit Cloud Composer erfahren
Mehr über gängige Dataflow-Anwendungsfallmuster erfahren
Mehr über Release-Engineering erfahren
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center