Schritt 6: Bereitstellung ausführen

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

Build-Prozess

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

Führen Sie den folgenden Befehl aus, um sich im geklonten Repository zu befinden:
```
cd cortex-data-foundation
```
Führen Sie den Build-Befehl mit dem Ziel-Log-Bucket aus:
```
 gcloud builds submit \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET_NAME,_BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/CLOUD_BUILD_SA@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Ersetzen Sie Folgendes:
- LOGS_BUCKET_NAME durch den Bucket-Namen für die Logs-Speicherung. Das Cloud Build-Dienstkonto benötigt Zugriff, um sie hier zu schreiben.
- SOURCE_PROJECT durch das Quellprojekt.
- CLOUD_BUILD_SA durch die Cloud Build-Dienstkonto-ID, die in Schritt 4 der Bereitstellung erstellt wurde.
Folgen Sie dem Haupt-Build-Prozess, indem Sie die Logs im Terminal oder in der Cloud Build Console, ansehen, wenn Sie die entsprechenden Berechtigungen haben. Weitere Informationen finden Sie in den folgenden Bildern.

Abbildung 1. Beispiel für das Ansehen des Log-Fortschritts im Terminal.

Abbildung 2. Beispiel für das Ansehen des Log-Fortschritts in der Console.
Verfolgen Sie die untergeordneten Build-Schritte, die über die Cloud Build Console oder in den aus den Schritten erstellten Logs ausgelöst wurden. Weitere Informationen finden Sie in den folgenden Bildern.

Abbildung 3. Beispiel für das Verfolgen untergeordneter Build-Schritte in der Console.

Abbildung 4. Beispiel für das Verfolgen untergeordneter Build-Schritte in den Logs.
Ermitteln Sie alle Probleme mit einzelnen Builds. Korrigieren Sie gegebenenfalls Fehler. Es wird empfohlen, den generierten SQL-Code in BigQuery einzufügen, um die Fehler zu ermitteln und zu korrigieren. Die meisten Fehler beziehen sich auf Felder, die ausgewählt, aber in der replizierten Quelle nicht vorhanden sind. In der BigQuery-UI können Sie diese Felder ermitteln und auskommentieren.

Abbildung 5. Beispiel für das Ermitteln von Problemen über Cloud Build-Logs.

Dateien in den Managed Service for Apache Airflow (Airflow)-DAG-Bucket verschieben

Wenn Sie Integrations- oder CDC-Dateien generiert haben und eine Instanz von Managed Airflow (Airflow) verwenden, können Sie sie 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 Ausgabebucket.
COMPOSER_DAG_BUCKET durch den Managed Airflow (Airflow)-DAG-Bucket.

Anpassen und auf das Upgrade vorbereiten

Viele Unternehmenskunden haben spezifische Anpassungen an ihren Systemen, z. B. zusätzliche Dokumente in einem Ablauf oder bestimmte Arten von Datensätzen. Diese sind kundenspezifisch und werden von funktionalen Analysten konfiguriert, wenn die geschäftlichen Anforderungen dies erfordern.

Cortex verwendet ## CORTEX-CUSTOMER-Tags im Code, 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 Folgendes weiter anpassen, indem 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 wiederverwenden, um zusätzliche APIs aufzurufen.
Bereitstellungsskripts ändern.
Einige Tabellen oder bereitgestellte APIs anpassen, um zusätzliche Felder einzufügen, die nicht im Standard enthalten sind.

Verwenden Sie eine CI/CD-Pipeline, die für Ihr Unternehmen geeignet ist, um diese Verbesserungen zu testen und Ihre Gesamtlösung in einem zuverlässigen und robusten Zustand zu halten. Eine Pipeline kann die cloudbuild.yaml Skripts wiederverwenden, um die End-to-End-Bereitstellung regelmäßig oder basierend auf Git-Vorgängen auszulösen, je nach dem von Ihnen ausgewählten Repository, indem sie Builds automatisiert.

Verwenden Sie die Datei config.json, um verschiedene Gruppen von Projekten und Datasets für Entwicklungs-, Staging- und Produktionsumgebungen zu definieren. Verwenden Sie automatisierte Tests mit Ihren eigenen Beispieldaten, um sicherzustellen, dass die Modelle immer die erwarteten Ergebnisse liefern.

Wenn Sie Ihre eigenen Änderungen in Ihrem Fork oder Klon eines Repositorys sichtbar kennzeichnen und die Bereitstellung und das Testen automatisieren, können Sie Upgrades durchführen.

Support

Wenn Sie Probleme haben oder Funktionsanfragen zu diesen Modellen oder Bereitstellern haben, erstellen Sie ein Problem im Cortex Framework Data Foundation-Repository. Um die erforderlichen Informationen zu erfassen, führen Sie support.sh aus dem geklonten Verzeichnis aus. Dieses Skript führt Sie durch eine Reihe von Schritten zur Fehlerbehebung.

Bei Anfragen oder Problemen zu Cortex Framework rufen Sie den Supportbereich auf der Übersichtsseite auf.

Looker Blocks und Dashboards

Nutzen Sie die verfügbaren Looker Blocks und Dashboards. Dabei handelt es sich im Wesentlichen um wiederverwendbare Datenmodelle für gängige Analysemuster und Daten quellen für Cortex Framework. Weitere Informationen finden Sie unter Übersicht über Looker Blocks und Dashboards.