Datenqualitätsregeln als Code mit Terraform verwalten

In dieser Anleitung wird erläutert, wie Sie Dataplex-Regeln für die Datenqualität mit Terraform, Cloud Build und GitHub als Code verwalten.

Es gibt viele verschiedene Optionen für Datenqualitätsregeln, mit denen Sie die Qualität Ihrer Daten definieren und messen können. Wenn Sie die Bereitstellung von Datenqualitätsregeln als Teil Ihrer umfassenden Infrastrukturverwaltungsstrategie automatisieren, sorgen Sie dafür, dass Ihre Daten konsistent und vorhersehbar den Regeln unterliegen, die Sie ihnen zuweisen.

Wenn Sie unterschiedliche Versionen eines Datensatzes für mehrere Umgebungen haben, z. B. für die Umgebungen dev und prod, bietet Terraform eine zuverlässige Möglichkeit, um Umgebungsspezifischen Versionen von Datensätzen Datenqualitätsregeln zuzuweisen.

Die Versionsverwaltung ist auch eine wichtige Best Practice für DevOps. Verwalten Datenqualitätsregeln, da der Code Ihnen Versionen Ihrer Datenqualität liefert die in Ihrem GitHub-Verlauf verfügbar sind. Terraform kann auch Speichern des Status in Cloud Storage, wo frühere Versionen des Statusdatei.

Weitere Informationen zu Terraform und Cloud Build finden Sie unter Übersicht über Terraform in Google Cloud und Cloud Build:

Architektur

Im folgenden Architekturdiagramm wird veranschaulicht, 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.

Ziele

  • GitHub-Repository einrichten
  • Terraform so konfigurieren, dass der Status in einem Cloud Storage-Bucket gespeichert wird
  • Berechtigungen für Cloud Build-Dienstkonto erteilen
  • Cloud Build mit GitHub-Repository verbinden
  • Dataplex-Datenqualitätsregeln einrichten.
  • Ändern Sie die Umgebungskonfiguration in einem Feature-Branch und testen Sie sie.
  • Ä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. 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.

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

    Go to project selector

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

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

    Go to project selector

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

  6. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  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, Ihr Projekt zu nutzen. 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, in Cloud Shell erstellen können.

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 die Zweige dev und prod:

    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 eine Vorlage für eine Bereitstellung und wird für eine andere Bereitstellung wiederverwendet. Umgebungen.

  • Innerhalb von modules/deploy/:

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

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

    • 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 zur Datenqualität. Diese Datei wird in Verbindung mit rules_file_parsing.tf, um Datenqualitätsregeln aus einer yaml-Datei zu lesen in die Umgebung gelangen.

  • 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

Um sicherzustellen, dass die vorgeschlagenen Änderungen für jede Umgebung geeignet sind, werden terraform init und terraform plan für alle Umgebungen ausgeführt. Vorher Pull-Anfrage zusammenführen, können Sie die Pläne überprüfen, um sicherzustellen, beispielsweise keinem nicht autorisierten Rechtssubjekt gewährt wird.

Terraform zum Speichern des Status in Cloud Storage-Buckets konfigurieren

Standardmäßig speichert Terraform den Status 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 jeder Computer 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 Remote-Status 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 dev und prod gibt es jeweils eine separate backend.tf-Datei Umgebungen. Es wird empfohlen, für jede Umgebung einen separaten Cloud Storage-Bucket zu verwenden.

In den folgenden Schritten erstellen Sie zwei Cloud Storage-Buckets für dev und prod und ändern einige Dateien so, dass 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 nach sed -i so zwei Anführungszeichen hinzufü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 erfahren Sie, wie Sie die Cloud Build-GitHub-App 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 Branch erstellen oder den 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

    • 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, in Ihrer lokalen Umgebung zu ändern.

  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. Wenn Sie die Datei zur Bearbeitung öffnen möchten, 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, Wählen Sie 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 Create pull request (Pull-Anfrage erstellen), um eine neue Pull-Anfrage mit Ihrer Änderung am Zweig dev 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 die Pull-Anfrage noch nicht zusammen. Das Zusammenführen 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.9.5'
  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.9.5'
  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 Cloud Build-Seite

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

Änderungen an der Produktionsumgebung übernehmen

Nachdem Sie Ihre Entwicklungsumgebung vollständig getestet haben, können Sie für die Datenqualitätsregeln an die Produktion übergeben.

  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 Pull-Anfrage erstellen.

  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 Cloud Build-Seite

Sie haben Datenqualitätsregeln konfiguriert, die mithilfe von Terraform und Cloud Build

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. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

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-Anwendungen in der Zeile Google Cloud Build auf Widerrufen und anschließend 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. Rufen Sie Danger Zone auf.
  4. Klicken Sie auf Dieses Repository löschen und folgen Sie den Schritten zur Bestätigung.

Nächste Schritte