Diese Seite wurde von der Cloud Translation API übersetzt.

Schritt 6: Deployment ausführen

Auf dieser Seite wird der sechste Schritt zum Bereitstellen von Cortex Framework Data Foundation, dem Kern von Cortex Framework, beschrieben. In diesem Schritt führen Sie die Bereitstellung von Cortex Framework Data Foundation aus.

Build-Prozess

Nachdem Sie die Datei config.json wie in Schritt 5: Bereitstellung konfigurieren beschrieben konfiguriert haben, folgen Sie dieser Anleitung, um den Prozess zu erstellen.

Führen Sie den folgenden Befehl aus, um sich im geklonten Repository zu positionieren:
```
cd cortex-data-foundation
```
Führen Sie den Build-Befehl mit dem Ziel-Log-Bucket aus:
```
 gcloud builds submit \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET,\
 _BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/SERVICE_ACCOUNT@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Ersetzen Sie Folgendes:
- LOGS_BUCKET durch den Bucket-Namen für die Speicherung von Logs. Das Cloud Build-Dienstkonto muss Zugriff haben, um sie hier zu schreiben.
- SOURCE_PROJECT durch das Quellprojekt.
- SERVICE_ACCOUNT durch die Dienstkonto-ID.
Folgen Sie dem Haupt-Build-Prozess, indem Sie sich die Logs im Terminal oder in der Cloud Build-Konsole ansehen, sofern Sie über ausreichende Berechtigungen verfügen. Weitere Informationen finden Sie in den folgenden Bildern.

Abbildung 1. Beispiel für die Anzeige des Fortschritts von Logs im Terminal

Abbildung 2: Beispiel für das Anzeigen des Log-Fortschritts in der Konsole.
Sie können die untergeordneten Build-Schritte, die über die Cloud Build-Konsole ausgelöst wurden, oder in den aus den Schritten erstellten Logs nachverfolgen. Die folgenden Bilder dienen als Referenz.

Abbildung 3: Beispiel für das Tracking von Build-Schritten in der Console

Abbildung 4. Beispiel für das Tracking von untergeordneten Build-Schritten in den Logs.
Probleme mit einzelnen Builds ermitteln Korrigieren Sie gegebenenfalls Fehler. Es wird empfohlen, den generierten SQL-Code in BigQuery einzufügen, um die Fehler zu identifizieren und zu korrigieren. Die meisten Fehler beziehen sich auf Felder, die ausgewählt, aber nicht in der replizierten Quelle vorhanden sind. Die BigQuery-Benutzeroberfläche hilft Ihnen, diese zu identifizieren und auszukommentieren.

Abbildung 5. Beispiel für das Identifizieren von Problemen anhand von Cloud Build-Logs.

Dateien in den Cloud Composer-DAG-Bucket (Airflow) verschieben

Wenn Sie sich für das Generieren von Integrations- oder CDC-Dateien entschieden haben und eine Instanz von Cloud Composer (Airflow) haben, können Sie die Dateien mit dem folgenden Befehl in den endgültigen Bucket verschieben:

  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/dags/ gs://COMPOSER_DAG_BUCKET/
  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/data/ gs://COMPOSER_DAG_BUCKET/

Ersetzen Sie Folgendes:

OUTPUT_BUCKET durch den Ausgabe-Bucket.
COMPOSER_DAG_BUCKET mit dem Cloud Composer-Bucket (Airflow-DAG).

Anpassen und auf das Upgrade vorbereiten

Viele Enterprise-Kunden haben bestimmte Anpassungen ihrer Systeme, z. B. zusätzliche Dokumente in einem Ablauf oder bestimmte Arten von Datensätzen. Sie sind kundenspezifisch und werden von funktionalen Analysten konfiguriert, wenn der Bedarf entsteht.

In Cortex werden ## CORTEX-CUSTOMER-Tags im Code verwendet, um Stellen zu kennzeichnen, an denen solche Anpassungen wahrscheinlich erforderlich sind. Verwenden Sie den Befehl grep -R CORTEX-CUSTOMER, um alle ## CORTEX-CUSTOMER-Kommentare zu prüfen, die Sie anpassen sollten.

Zusätzlich zu den CORTEX-CUSTOMER-Tags müssen Sie möglicherweise die folgenden Elemente weiter anpassen. Dazu müssen Sie alle diese Änderungen mit einem eindeutigen Tag im Code in Ihr eigenes geforktes oder geklontes Repository übertragen:

Geschäftsregeln hinzufügen
Andere Datasets hinzufügen und mit vorhandenen Ansichten oder Tabellen zusammenführen
Die bereitgestellten Vorlagen werden wiederverwendet, um zusätzliche APIs aufzurufen.
Bereitstellungsskripts ändern.
Weitere Data Mesh-Konzepte anwenden
Anpassen einiger Tabellen oder APIs, um zusätzliche Felder aufzunehmen, die nicht im Standard enthalten sind.

Verwenden Sie eine CI/CD-Pipeline, die für Ihre Organisation geeignet ist, um diese Verbesserungen zu testen und Ihre Gesamtlösung in einem zuverlässigen und stabilen Zustand zu halten. Eine Pipeline kann die cloudbuild.yaml-Skripts verwenden, um die End-to-End-Bereitstellung regelmäßig oder basierend auf Git-Vorgängen auszulösen. Dies hängt vom ausgewählten Repository ab. Builds lassen sich automatisieren.

Mit der Datei config.json können Sie verschiedene Gruppen von Projekten und Datasets für Entwicklungs-, Staging- und Produktionsumgebungen definieren. Verwenden Sie automatisierte Tests mit Ihren eigenen Beispieldaten, um sicherzustellen, dass die Modelle immer das liefern, was Sie erwarten.

Wenn Sie Ihre eigenen Änderungen in Ihrem Fork oder Klon eines Repositorys sichtbar kennzeichnen und einige Bereitstellungs- und Testautomatisierungen vornehmen, können Sie Upgrades durchführen.

Support

Wenn Sie Probleme mit diesen Modellen oder Deployern haben oder Funktionsanfragen dazu stellen möchten, erstellen Sie ein Problem im Repository Cortex Framework Data Foundation. Um die erforderlichen Informationen zu sammeln, führen Sie support.sh im geklonten Verzeichnis aus. Dieses Skript führt Sie durch eine Reihe von Schritten zur Fehlerbehebung.

Wenn Sie Anfragen zum Cortex Framework haben oder Probleme auftreten, rufen Sie auf der Übersichtsseite den Supportbereich auf.

Looker Blocks und Dashboards

Nutzen Sie die verfügbaren Looker-Blöcke und ‑Dashboards. Dabei handelt es sich im Wesentlichen um wiederverwendbare Datenmodelle für gängige Analysemuster und Datenquellen für Cortex Framework. Weitere Informationen finden Sie unter Looker-Blöcke und ‑Dashboards – Übersicht.