Schritt 6: Bereitstellung ausführen

Auf dieser Seite wird der sechste Schritt zur Bereitstellung der Cortex Framework Data Foundation beschrieben, dem Kern des Cortex-Frameworks. 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.

  1. Führen Sie den folgenden Befehl aus, um sich im geklonten Repository zu positionieren:

    cd cortex-data-foundation

  2. Führen Sie den Build-Befehl mit dem Ziel-Log-Bucket aus:

    gcloud builds submit --project EXECUTION_PROJECT\
    --substitutions=_GCS_BUCKET=LOGS_BUCKET

    Ersetzen Sie Folgendes:

    • EXECUTION_PROJECT mit dem Ausführungsprojekt, wahrscheinlich dem Quellprojekt.
    • LOGS_BUCKET durch den Namen des Buckets für die Protokollspeicherung. Das Cloud Build-Dienstkonto benötigt Zugriff, um sie hier zu schreiben.

  3. Wenn Sie genügend Berechtigungen haben, können Sie den Build-Vorgang anhand der Logs im Terminal oder in der Cloud Build Console verfolgen. Weitere Informationen finden Sie in den folgenden Bildern.

    Protokolle werden verarbeitet

    Abbildung 1. Beispiel für die Anzeige des Protokollfortschritts im Terminal.

    Protokolle werden verarbeitet

    Abbildung 2 Beispiel für die Anzeige des Protokollfortschritts in der Console.

  4. Sie können die untergeordneten Build-Schritte verfolgen, die über die Cloud Build-Konsole oder in den durch die Schritte erstellten Protokollen ausgelöst werden. Weitere Informationen finden Sie in den folgenden Bildern.

    Tracking von untergeordneten Build-Schritten

    Abbildung 3. Beispiel für das Überwachen von untergeordneten Build-Schritten in der Console.

    Tracking von untergeordneten Build-Schritten

    Abbildung 4: Beispiel für das Überwachen von untergeordneten Buildschritten in den Protokollen.

  5. Identifizieren Sie Probleme mit einzelnen Builds. Korrigieren Sie gegebenenfalls Fehler. Wir empfehlen, die generierte SQL-Abfrage 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 dabei, diese zu identifizieren und zu kommentieren.

    Erkennen von Problemen

    Abbildung 5 Beispiel für die Identifizierung von Problemen anhand von Cloud Build-Protokollen.

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

Wenn Sie Integrations- oder CDC-Dateien generiert haben und eine Cloud Composer-Instanz (Airflow) haben, 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 Ausgabe-Bucket.
  • COMPOSER_DAG_BUCKET mit dem Cloud Composer-DAG-Bucket (Airflow) verknüpft.

Upgrade anpassen und vorbereiten

Viele Unternehmenskunden haben spezifische Anpassungen an ihren Systemen, z. B. zusätzliche Dokumente in einem Ablauf oder bestimmte Arten von Einträgen. Sie sind für jeden Kunden spezifisch und werden von funktionalen Analysten konfiguriert, wenn die Geschäftsanforderungen auftreten.

In Cortex werden ## CORTEX-CUSTOMER-Tags im Code verwendet, um Stellen anzugeben, 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 Ihrem eigenen geforkten oder geklonten Repository committen:

  • Geschäftsregeln hinzufügen
  • Andere Datasets hinzufügen und mit vorhandenen Ansichten oder Tabellen zusammenführen
  • Wiederverwendung der bereitgestellten Vorlagen zum Aufrufen zusätzlicher APIs
  • Bereitstellungsscripts ändern
  • Weitere Data Mesh-Konzepte anwenden
  • Einige Tabellen oder bereitgestellte APIs wurden angepasst, 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 robusten Zustand zu halten. In einer Pipeline können die cloudbuild.yaml-Scripts wiederverwendet werden, um die End-to-End-Bereitstellung regelmäßig oder basierend auf Git-Vorgängen auszulösen, je nachdem, welches Repository Sie verwenden. Dazu müssen Sie Builds automatisieren.

Mit der Datei config.json können Sie verschiedene Projekte und Datensätze für Entwicklungs-, Staging- und Produktionsumgebungen 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 Repositories gut sichtbar taggen und die Bereitstellung und Tests automatisieren, können Sie Upgrades ausführen.

Support

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

Wenn Sie Anfragen oder Probleme im Zusammenhang mit dem Cortex Framework haben, rufen Sie auf der Übersichtsseite den Abschnitt Support 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 das Cortex Framework. Weitere Informationen finden Sie unter Looker-Blöcke und ‑Dashboards – Übersicht.