Datenqualitätsregeln als Code mit Terraform verwalten

In dieser Anleitung wird erläutert, wie Sie Dataplex-Datenqualitätsregeln als Code mit Terraform, Cloud Build und GitHub verwalten.

Es gibt viele verschiedene Optionen für Datenqualitätsregeln, um die Qualität Ihrer Daten zu definieren und zu messen. Wenn Sie den Prozess der Bereitstellung von Datenqualitätsregeln im Rahmen Ihrer umfassenderen Infrastrukturverwaltungsstrategie automatisieren, sorgen Sie dafür, dass Ihre Daten konsistent und vorhersehbar den Regeln unterliegen, die Sie ihnen zuweisen.

Wenn Sie verschiedene Versionen eines Datasets für mehrere Umgebungen haben, z. B. dev- und prod-Umgebungen, bietet Terraform eine zuverlässige Möglichkeit, umgebungsspezifischen Versionen von Datasets Regeln für die Datenqualität zuzuweisen.

Die Versionsverwaltung ist außerdem eine wichtige Best Practice bei DevOps. Wenn Sie Ihre Datenqualitätsregeln als Code verwalten, erhalten Sie Versionen der Datenqualitätsregeln, die in Ihrem GitHub-Verlauf verfügbar sind. Terraform kann seinen Status auch in Cloud Storage speichern, wo auch ältere Versionen der Statusdatei gespeichert werden können.

Weitere Informationen zu Terraform und Cloud Build finden Sie in der Übersicht zu Terraform in Google Cloud und Cloud Build.

Architektur

Das folgende Architekturdiagramm zeigt, wie in dieser Anleitung Cloud Build zum Verwalten von Terraform-Ausführungen verwendet wird. Dabei werden die GitHub-Branches dev und prod zur Darstellung der tatsächlichen Umgebungen verwendet.

Infrastruktur mit Entwicklungs- und Produktumgebungen

Der Prozess beginnt, wenn Sie Terraform-Code an den dev- oder prod-Branch per Push übertragen. In diesem Szenario wird Cloud Build ausgelöst und wendet anschließend Terraform-Manifeste an, um den gewünschten Status in der jeweiligen Umgebung zu erreichen. Wenn Sie Terraform-Code dagegen in einen anderen Branch per Push übertragen, z. B. in einen Feature-Branch, wird mit Cloud Build terraform plan ausgeführt. Es wird aber nichts auf eine Umgebung angewendet.

Im Idealfall müssen Entwickler oder Operatoren Infrastrukturvorschläge an nicht geschützte Branches richten und diese dann über Pull-Anfragen senden. Die später in dieser Anleitung beschriebene Cloud Build GitHub-Anwendung löst automatisch die Build-Jobs aus und verknüpft die terraform plan-Berichte mit diesen Pull-Anfragen. So können Sie mögliche Änderungen mit Mitarbeitern diskutieren und überprüfen und Folge-Commits hinzufügen, bevor die Änderungen im Basis-Branch zusammengeführt werden.

Wenn es keine Bedenken gibt, müssen Sie zuerst die Änderungen im dev-Branch zusammenführen. Diese Zusammenführung löst eine Infrastrukturbereitstellung in der dev-Umgebung aus, sodass Sie diese Umgebung testen können. Nachdem Sie die Bereitstellung zufriedenstellend getestet haben, müssen Sie den dev-Branch mit dem prod-Branch zusammenführen, um die Installation der Infrastruktur in der Produktionsumgebung auszulösen.

Lernziele

  • GitHub-Repository einrichten
  • Terraform so konfigurieren, dass der Status in einem Cloud Storage-Bucket gespeichert wird
  • Berechtigungen für Cloud Build-Dienstkonto erteilen
  • Verbinden Sie Cloud Build mit dem GitHub-Repository.
  • Dataplex-Datenqualitätsregeln erstellen
  • Umgebungskonfiguration in einem Feature-Branch ändern und testen
  • Änderungen an der Entwicklungsumgebung übernehmen
  • Änderungen an der Produktionsumgebung übernehmen

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.

Vorbereitung

  1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

  2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  6. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  7. Rufen Sie in Cloud Shell die ID des soeben ausgewählten Projekts ab: 
    gcloud config get-value project
    Wenn dieser Befehl keine Projekt-ID zurückgibt, konfigurieren Sie Cloud Shell so, dass Ihr Projekt verwendet wird. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID. 
    gcloud config set project PROJECT_ID
  8. Aktivieren Sie die erforderlichen APIs: 
    gcloud services enable bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.googleapis.com
    Dieser Schritt kann einige Minuten dauern.
  9. Wenn Sie Git noch nie über Cloud Shell verwendet haben, konfigurieren Sie es mit Ihrem Namen und Ihrer E-Mail-Adresse: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    Git verwendet diese Informationen, um Sie als Ersteller der Commits zu identifizieren, die Sie in Cloud Shell erstellen.

GitHub-Repository einrichten

In dieser Anleitung verwenden Sie ein einziges Git-Repository zur Definition der Cloudinfrastruktur. Sie orchestrieren diese Infrastruktur, indem Sie unterschiedliche Branches haben, die unterschiedlichen Umgebungen entsprechen:

  • Der dev-Branch enthält die neuesten Änderungen, die auf die Entwicklungsumgebung angewendet werden.
  • Der prod-Branch enthält die neuesten Änderungen, die auf die Produktionsumgebung angewendet werden.

Mit dieser Infrastruktur können Sie jederzeit auf das Repository verweisen, um zu erfahren, welche Konfiguration in den einzelnen Umgebungen erwartet wird, und um neue Änderungen vorzuschlagen, die zuerst in der dev-Umgebung zusammengeführt werden. Anschließend übernehmen Sie die Änderungen. Dazu führen Sie den dev-Branch mit dem nachfolgenden prod-Branch zusammen.

Zuerst verzweigen Sie das Repository terraform-google-dataplex-auto-data-quality.

  1. Rufen Sie in GitHub https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git auf.

  2. Klicken Sie auf Fork.

    Jetzt haben Sie eine Kopie des Repositorys terraform-google-dataplex-auto-data-quality mit Quelldateien.

  3. Klonen Sie in Cloud Shell dieses verzweigte Repository und ersetzen Sie YOUR_GITHUB_USERNAME durch Ihren GitHub-Nutzernamen:

    cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
cd ~/terraform-google-dataplex-auto-data-quality

  4. Erstellen Sie dev- und prod-Zweige:

    git checkout -b prod
git checkout -b dev

Der Code in diesem Repository ist folgendermaßen aufgebaut:

  • Der environments/-Ordner enthält Unterordner, die Umgebungen wie dev und prod darstellen. Diese bieten eine logische Trennung zwischen Arbeitslasten in verschiedenen Reife-, Entwicklungs- bzw. Produktionsphasen.

  • Der Ordner modules/ enthält Inline-Terraform-Module. Diese Module stellen logische Gruppierungen verwandter Ressourcen dar und werden zur gemeinsamen Nutzung von Code in verschiedenen Umgebungen verwendet. Das Modul modules/deploy/ stellt hier eine Vorlage für eine Bereitstellung dar und wird für verschiedene Bereitstellungsumgebungen wiederverwendet.

  • Innerhalb von modules/deploy/:

    • Der Ordner rule/ enthält yaml-Dateien mit Datenqualitätsregeln. Eine Datei steht für eine Reihe von Datenqualitätsregeln für eine Tabelle. Diese Datei wird in den Umgebungen dev und prod verwendet.

    • Der Ordner schemas/ enthält das Tabellenschema für die BigQuery-Tabelle, die in dieser Infrastruktur bereitgestellt wird.

    • Die Datei bigquery.tf enthält die Konfiguration für BigQuery-Tabellen, die in dieser Bereitstellung erstellt wurden.

    • Die Datei dataplex.tf enthält einen Dataplex-Datenscan für die Datenqualität. Diese Datei wird in Verbindung mit rules_file_parsing.tf verwendet, um Datenqualitätsregeln aus einer yaml-Datei in die Umgebung zu lesen.

  • Die Datei cloudbuild.yaml ist eine Build-Konfigurationsdatei, die Anweisungen für Cloud Build enthält, z. B. zum Ausführen von Aufgaben basierend auf einer Reihe von Schritten. Diese Datei gibt eine bedingte Ausführung abhängig von dem Branch an, von dem Cloud Build den Code abruft. Beispiel:

    • Für die dev- und prod-Branches werden folgende Schritte ausgeführt:

      1. terraform init
      2. terraform plan
      3. terraform apply

    • Für alle anderen Branches werden folgende Schritte ausgeführt:

      1. terraform init für alle environments-Unterordner
      2. terraform plan für alle environments-Unterordner

Damit die vorgeschlagenen Änderungen für jede Umgebung geeignet sind, werden terraform init und terraform plan für alle Umgebungen ausgeführt. Bevor Sie die Pull-Anfrage zusammenführen, können Sie die Pläne überprüfen, um beispielsweise sicherzustellen, dass kein Zugriff auf eine nicht autorisierte Entität gewährt wird.

Terraform zum Speichern des Status in Cloud Storage-Buckets konfigurieren

Standardmäßig speichert Terraform state lokal in einer Datei mit dem Namen terraform.tfstate. Diese Standardkonfiguration kann die Verwendung von Terraform für Teams erschweren, insbesondere wenn viele Nutzer Terraform gleichzeitig ausführen und jede Maschine ein eigenes Verständnis der aktuellen Infrastruktur hat.

Zur Vermeidung solcher Probleme wird in diesem Bereich ein Remotestatus konfiguriert, der auf einen Cloud Storage-Bucket verweist. Der Remotestatus ist ein Feature der Back-Ends und wird in dieser Anleitung in der Datei backend.tf konfiguriert.

# Copyright 2024 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate-dev"
  }
}

In jeder der Umgebungen dev und prod ist eine separate backend.tf-Datei vorhanden. Es gilt als Best Practice, für jede Umgebung einen anderen Cloud Storage-Bucket zu verwenden.

In den folgenden Schritten erstellen Sie zwei Cloud Storage-Buckets für dev und prod und ändern einige Dateien, sodass sie auf Ihre neuen Buckets und Ihr Google Cloud-Projekt verweisen.

  1. Erstellen Sie in Cloud Shell die beiden Cloud Storage-Buckets:

    DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
gcloud storage buckets create ${DEV_BUCKET}

PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
gcloud storage buckets create ${PROD_BUCKET}

  2. Aktivieren Sie die Objektversionsverwaltung, um den Verlauf Ihrer Bereitstellungen zu speichern:

    gcloud storage buckets update ${DEV_BUCKET} --versioning
gcloud storage buckets update ${PROD_BUCKET} --versioning

    Durch das Aktivieren der Objektversionsverwaltung werden die Speicherkosten erhöht. Dies können Sie umgehen, indem Sie die Verwaltung des Objektlebenszyklus so konfigurieren, dass alte Statusversionen gelöscht werden.

  3. Ersetzen Sie den Platzhalter PROJECT_ID durch die Projekt-ID in den Dateien main.tf und backend.tf in jeder Umgebung:

    cd ~/terraform-google-dataplex-auto-data-quality
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf

    Unter OS X oder macOS müssen Sie möglicherweise zwei Anführungszeichen ("") nach sed -i einfügen:

    cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
sed -i "" s/PROJECT_ID/PROJECT_ID/g environments/*/backend.tf

  4. Prüfen Sie, ob alle Dateien aktualisiert wurden:

    git status

    Sie erhalten folgende Ausgabe:

    On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/main.tf
       modified:   environments/prod/backend.tf
       modified:   environments/prod/main.tf
no changes added to commit (use "git add" and/or "git commit -a")

  5. Führen Sie einen Commit durch und übertragen Sie die Änderungen:

    git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

    Abhängig von Ihrer GitHub-Konfiguration müssen Sie sich authentifizieren, um die vorherigen Änderungen vorzunehmen.

Berechtigungen für Cloud Build-Dienstkonto erteilen

Damit das Cloud Build-Dienstkonto Terraform-Skripts zur Verwaltung von Google Cloud-Ressourcen ausführen darf, müssen Sie ihm den entsprechenden Zugriff auf Ihr Projekt gewähren. Der Einfachheit halber wird in dieser Anleitung der Zugriff für den Projektbearbeiter gewährt. Wenn die Rolle des Projektbearbeiters jedoch über eine umfassende Berechtigung verfügt, müssen Sie in Produktionsumgebungen die Best Practices für die IT-Sicherheit Ihres Unternehmens befolgen. Dabei wird normalerweise Zugriff mit den geringsten Berechtigungen bereitgestellt.

  1. Rufen Sie in Cloud Shell die E-Mail für das Cloud Build-Dienstkonto Ihres Projekts ab:

    CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

  2. Gewähren Sie den erforderlichen Zugriff auf Ihr Cloud Build-Dienstkonto:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$CLOUDBUILD_SA --role roles/editor

Cloud Build direkt mit GitHub-Repository verbinden

In diesem Abschnitt wird beschrieben, wie Sie die Cloud Build GitHub-Anwendung installieren. Mit dieser Installation können Sie Ihr GitHub-Repository mit Ihrem Google Cloud-Projekt verbinden, sodass Cloud Build Ihre Terraform-Manifeste jedes Mal automatisch anwenden kann, wenn Sie einen neuen Zweig erstellen oder Code per Push an GitHub übertragen.

Die folgenden Schritte enthalten eine Anleitung zur Installation der Anwendung nur für das Repository terraform-google-dataplex-auto-data-quality. Sie können die Anwendung aber auch für weitere oder alle Repositories installieren.

  1. Rufen Sie im GitHub Marketplace die Seite der Cloud Build-Anwendung auf.

    • Wenn Sie zum ersten Mal eine Anwendung in GitHub konfigurieren, klicken Sie unten auf der Seite auf Mit Google Cloud Build einrichten. Klicken Sie dann auf Dieser App Zugriff auf Ihr GitHub-Konto gewähren.
    • Wenn Sie zum ersten Mal eine Anwendung in GitHub konfigurieren, klicken Sie auf Zugriff konfigurieren. Die Seite Anwendungen Ihres privaten Kontos wird geöffnet.

  2. Klicken Sie in der Cloud Build-Zeile auf Konfigurieren.

  3. Wählen Sie Nur Repositories auswählen und dann terraform-google-dataplex-auto-data-quality aus, um eine Verbindung zum Repository herzustellen.

  4. Klicken Sie auf Speichern oder Installieren. Das Schaltflächenlabel ändert sich je nach Workflow. Sie werden zu Google Cloud weitergeleitet, um die Installation fortzusetzen.

  5. Melden Sie sich mit Ihrem Google Cloud-Konto an. Autorisieren Sie die Cloud Build-Integration in GitHub, wenn Sie dazu aufgefordert werden.

  6. Wählen Sie auf der Seite Cloud Build Ihr Projekt aus. Ein Assistent wird angezeigt.

  7. Wählen Sie im Abschnitt Repository auswählen Ihr GitHub-Konto und das Repository terraform-google-dataplex-auto-data-quality aus.

  8. Wenn Sie mit den Nutzungsbedingungen einverstanden sind, klicken Sie das Kästchen an und dann auf Verbinden.

  9. Klicken Sie im Abschnitt Trigger erstellen auf Trigger erstellen:

    1. Fügen Sie einen Triggernamen hinzu, z. B. push-to-branch. Notieren Sie sich den Triggernamen, da Sie ihn später benötigen.
    2. Wählen Sie im Abschnitt Ereignis die Option Push zu Zweig aus.
    3. Wählen Sie im Abschnitt Quelle im Feld Zweig die Option .* aus.
    4. Klicken Sie auf Erstellen.

Die GitHub-Anwendung "Cloud Build" ist jetzt konfiguriert und Ihr GitHub-Repository ist mit Ihrem Google Cloud-Projekt verknüpft. Ab jetzt lösen Änderungen am GitHub-Repository Cloud Build-Ausführungen aus, die die Ergebnisse mithilfe von GitHub-Prüfungen an GitHub zurückmelden.

Umgebungskonfiguration in einem neuen Feature-Branch ändern

Inzwischen haben Sie den größten Teil Ihrer Umgebung konfiguriert. Jetzt ist es an der Zeit, einige Codeänderungen in Ihrer lokalen Umgebung vorzunehmen.

  1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

    https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

  2. Achten Sie darauf, dass Sie sich im dev-Zweig befinden.

  3. Um die Datei zur Bearbeitung zu öffnen, rufen Sie die Datei modules/deploy/dataplex.tf auf.

  4. Ändern Sie in Zeile 19 das Label the_environment in environment.

  5. Fügen Sie unten auf der Seite eine Commit-Nachricht hinzu, z. B. "modifying label" (Label ändern), und wählen Sie Create a new branch for this commit and start apu request (Neuen Branch für diesen Commit erstellen und Pull-Anfrage starten) aus.

  6. Klicken Sie auf Änderungen vorschlagen.

  7. Klicken Sie auf der folgenden Seite auf Pull-Anfrage erstellen, um eine neue Pull-Anfrage mit Ihrer Änderung am dev-Zweig zu öffnen.

    Sobald Ihre Pull-Anfrage geöffnet ist, wird automatisch ein Cloud Build-Job initiiert.

  8. Klicken Sie auf Show all checks (Alle Prüfungen anzeigen) und warten Sie, bis die Prüfung grün wird. Führen Sie Ihre Pull-Anfrage noch nicht zusammen. Die Zusammenführung erfolgt in einem späteren Schritt der Anleitung.

  9. Klicken Sie für weitere Informationen auf Details. Hierzu gehört auch die Ausgabe des terraform plan unter dem Link View more details on Google Cloud Build.

Der Cloud Build-Job hat die in der cloudbuild.yaml-Datei definierte Pipeline ausgeführt. Wie bereits erwähnt, weist diese Pipeline abhängig vom abgerufenen Branch unterschiedliches Verhalten auf. Der Build prüft, ob die Variable $BRANCH_NAME mit einem Umgebungsordner übereinstimmt. Wenn ja, führt Cloud Build den terraform plan für diese Umgebung aus. Andernfalls führt Cloud Build terraform plan für alle Umgebungen aus, damit die vorgeschlagene Änderung auf jeden Fall für alle Umgebungen geeignet ist. Wenn einer dieser Pläne nicht ausgeführt werden kann, schlägt der Build fehl.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Ebenso wird der Befehl terraform apply für Umgebungs-Branches ausgeführt. In allen anderen Fällen wird er jedoch vollständig ignoriert. In diesem Bereich haben Sie eine Codeänderung an einen neuen Branch gesendet, es wurden also keine Infrastrukturbereitstellungen auf Ihr Google Cloud-Projekt angewendet.

- id: 'tf apply'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

Erfolg der Cloud Build-Ausführung vor dem Zusammenführen von Branches erzwingen

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass Zusammenführungen nur angewendet werden können, wenn die jeweiligen Cloud Build-Ausführungen erfolgreich sind:

  1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

    https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

  2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).

  3. Klicken Sie im linken Menü auf Branches.

  4. Klicken Sie unter Branch protection rules (Branch-Schutzregeln) auf Add rule (Regel hinzufügen).

  5. Geben Sie unter Branch-Namensmuster dev ein.

  6. Wählen Sie im Abschnitt Übereinstimmende Branches schützen die Option Statusprüfungen müssen vor dem Zusammenführen bestanden werden aus.

  7. Suchen Sie nach dem zuvor erstellten Cloud Build-Triggernamen.

  8. Klicken Sie auf Erstellen.

  9. Wiederholen Sie die Schritte 3 bis 7 und setzen Sie Branch-Namensmuster auf prod.

Diese Konfiguration ist wichtig, um die Branches dev und prod zu schützen. Commits müssen also zuerst per Push an einen anderen Branch übertragen werden. Erst dann können diese im geschützten Branch zusammengeführt werden. In dieser Anleitung erfordert die Schutzeinstellung, dass die Cloud Build-Ausführung erfolgreich ist, damit die Zusammenführung zulässig ist.

Änderungen an der Entwicklungsumgebung übernehmen

Sie haben eine Pull-Anfrage, die noch zusammengeführt werden muss. Jetzt wird der gewünschte Status auf Ihre dev-Umgebung angewandt.

  1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

    https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

  2. Klicken Sie unter Ihrem Repository-Namen auf Pull requests (Pull-Anfragen).

  3. Klicken Sie auf die Pull-Anfrage, die Sie eben erstellt haben.

  4. Klicken Sie auf Merge pull request (Pull-Anfrage zusammenführen) und dann auf Confirm merge (Zusammenführen bestätigen).

  5. Überprüfen Sie, ob ein neuer Cloud Build ausgelöst wurde:

    Zur Seite „Cloud Build“

  6. Öffnen Sie den Build und überprüfen Sie die Protokolle. Dort werden alle Ressourcen angezeigt, die Terraform erstellt und verwaltet.

Änderungen an der Produktionsumgebung übernehmen

Nachdem Sie Ihre Entwicklungsumgebung vollständig getestet haben, können Sie Ihren Code für Datenqualitätsregeln in die Produktion übernehmen.

  1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.

    https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality

  2. Klicken Sie unter Ihrem Repository-Namen auf Pull requests (Pull-Anfragen).

  3. Klicken Sie auf New pull request (Neue Pull-Anfrage).

  4. Wählen Sie für base repository (Basis-Repository) das soeben verzweigte Repository aus.

  5. Wählen Sie für Basis die Option prod aus Ihrem eigenen Basis-Repository aus. Wählen Sie für Vergleichen die Option dev aus.

  6. Klicken Sie auf Create pull request.

  7. Wählen Sie für title einen Titel wie Changing label name aus und klicken Sie auf Create pull request.

  8. Prüfen Sie die vorgeschlagenen Änderungen, einschließlich der terraform plan-Details von Cloud Build, und klicken Sie dann auf Merge pull request.

  9. Klicken Sie auf Confirm merge (Zusammenführen bestätigen).

  10. Öffnen Sie in der Google Cloud Console die Seite Build-Verlauf, um zu sehen, wie Ihre Änderungen in der Produktionsumgebung angewendet werden:

    Zur Seite „Cloud Build“

Sie haben die Datenqualitätsregeln konfiguriert, die mit Terraform und Cloud Build verwaltet werden.

Bereinigen

Nach Abschluss der Anleitung können Sie die von Ihnen in Google Cloud erstellten Ressourcen bereinigen, damit Ihnen diese nicht weiter in Rechnung gestellt werden.

Projekt löschen

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

GitHub-Repository löschen

Sie können verhindern, dass neue Pull-Anfragen an Ihr GitHub-Repository blockiert werden, indem Sie die Regeln für den Branch-Schutz löschen:

  1. Rufen Sie in GitHub die Hauptseite Ihres verzweigten Repositorys auf.
  2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).
  3. Klicken Sie im linken Menü auf Branches.
  4. Klicken Sie im Abschnitt Branch-Schutzregeln auf die Schaltfläche Löschen für die Zeilen dev und prod.

Optional können Sie die Cloud Build-Anwendung vollständig von GitHub deinstallieren:

  1. Rufen Sie in GitHub die Seite GitHub-Anwendungen auf.

  2. Klicken Sie im Tab Installierte GitHub-Anwendungen in der Zeile Cloud Build auf Konfigurieren. Klicken Sie dann im Abschnitt Gefahrenbereich in der Zeile Google Cloud Builder deinstallieren auf Deinstallieren.

    Oben auf der Seite wird die Meldung angezeigt: „Sie sind fertig. Ein Job wurde in die Warteschlange gestellt, um Google Cloud Build zu deinstallieren.“

  3. Klicken Sie auf dem Tab Autorisierte GitHub-Apps in der Zeile Google Cloud Build auf die Schaltfläche Widerrufen und dann auf Ich verstehe, Zugriff widerrufen.

Wenn Sie Ihr GitHub-Repository nicht behalten möchten:

  1. Wechseln Sie in GitHub zur Hauptseite des verzweigten Repositorys.
  2. Klicken Sie unter Ihrem Repository-Namen auf Settings (Einstellungen).
  3. Gehen Sie zu Gefahrbereich.
  4. Klicken Sie auf Dieses Repository löschen und folgen Sie den Schritten zur Bestätigung.

Nächste Schritte