Cloud Composer-Umgebungen erstellen

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Auf dieser Seite wird erläutert, wie Sie eine Cloud Composer-Umgebung erstellen.

Hinweise

Schritt 1: Dienstkonto für eine Umgebung erstellen oder auswählen

Wenn Sie eine Umgebung erstellen, geben Sie ein Dienstkonto an. Dieses Dienstkonto wird als Dienstkonto der Umgebung bezeichnet. Ihre Umgebung verwendet dieses Dienstkonto für die meisten Vorgänge.

Das Dienstkonto für Ihre Umgebung ist kein Nutzerkonto. Ein Dienstkonto ist ein spezieller Kontotyp, der nicht von einer Person, sondern von einer Anwendung oder einer VM-Instanz verwendet wird.

Sie können das Dienstkonto Ihrer Umgebung später nicht mehr ändern.

Wenn Sie noch kein Dienstkonto für Cloud Composer-Umgebungen in Ihrem Projekt haben, erstellen Sie es.

Ein ausführliches Beispiel zum Erstellen eines Dienstkontos für Ihre Umgebung in Terraform finden Sie unter Umgebungen erstellen (Terraform).

So erstellen Sie ein neues Dienstkonto für Ihre Umgebung:

  1. Erstellen Sie ein neues Dienstkonto, wie in der Dokumentation zu Identity and Access Management beschrieben.

  2. Weisen Sie ihm eine Rolle zu, wie in der Dokumentation zu Identity and Access Management beschrieben. Die erforderliche Rolle ist Composer-Worker (composer.worker).

  3. Wenn Sie auf andere Ressourcen in Ihrem Google Cloud -Projekt zugreifen möchten, müssen Sie diesem Dienstkonto zusätzliche Berechtigungen für den Zugriff auf diese Ressourcen erteilen. Die Rolle Composer-Worker (composer.worker) bietet in den meisten Fällen die erforderlichen Berechtigungen. Fügen Sie diesem Dienstkonto nur dann zusätzliche Berechtigungen hinzu, wenn dies für den Betrieb Ihrer DAGs erforderlich ist.

Schritt 2: Grundlegende Einrichtung

In diesem Schritt wird eine Cloud Composer-Umgebung mit Standardparametern am angegebenen Speicherort erstellt.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Umgebung erstellen auf.

    Zur Seite „Umgebung erstellen“

  2. Geben Sie im Feld Name einen Namen für die Umgebung ein.

    Der Name muss mit einem Kleinbuchstaben beginnen, gefolgt von bis zu 62 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Anhand des Umgebungsnamens werden Unterkomponenten für die Umgebung erstellt. Daher müssen Sie einen Namen angeben, der auch als Cloud Storage-Bucket-Name gültig ist. Eine Liste der Einschränkungen finden Sie in den Benennungsrichtlinien für Buckets.

  3. Wählen Sie in der Drop-down-Liste Speicherort einen Speicherort für Ihre Umgebung aus.

    Ein Standort ist die Region, in der sich die Umgebung befindet.

  4. Wählen Sie in der Drop-down-Liste Image-Version ein Cloud Composer-Image mit der erforderlichen Version von Airflow aus.

  5. Wählen Sie in der Drop-down-Liste Dienstkonto ein Dienstkonto für Ihre Umgebung aus.

    Wenn Sie noch kein Dienstkonto für Ihre Umgebung haben, lesen Sie den Abschnitt Dienstkonto für eine Umgebung erstellen oder auswählen.

gcloud

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version IMAGE_VERSION \
    --service-account "SERVICE_ACCOUNT"

Ersetzen Sie:

  • ENVIRONMENT_NAME durch den Namen der Umgebung.

    Der Name muss mit einem Kleinbuchstaben beginnen, gefolgt von bis zu 62 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Anhand des Umgebungsnamens werden Unterkomponenten für die Umgebung erstellt. Daher müssen Sie einen Namen angeben, der auch als Cloud Storage-Bucket-Name gültig ist. Eine Liste der Einschränkungen finden Sie in den Benennungsrichtlinien für Buckets.

  • LOCATION durch die Region für die Umgebung.

    Ein Standort ist die Region, in der sich die Umgebung befindet.

  • SERVICE_ACCOUNT durch das Dienstkonto für Ihre Umgebung.

  • IMAGE_VERSION durch den Namen eines Cloud Composer-Images.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
"

API

Erstellen Sie eine API-Anfrage environments.create. Geben Sie die Konfiguration in der Ressource Environment an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "imageVersion": "IMAGE_VERSION"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • PROJECT_ID durch die Projekt-ID.

  • LOCATION durch die Region für die Umgebung.

    Ein Standort ist die Region, in der sich die Umgebung befindet.

  • ENVIRONMENT_NAME durch den Namen der Umgebung.

    Der Name muss mit einem Kleinbuchstaben beginnen, gefolgt von bis zu 62 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Anhand des Umgebungsnamens werden Unterkomponenten für die Umgebung erstellt. Daher müssen Sie einen Namen angeben, der auch als Cloud Storage-Bucket-Name gültig ist. Eine Liste der Einschränkungen finden Sie in den Benennungsrichtlinien für Buckets.

  • IMAGE_VERSION durch den Namen eines Cloud Composer-Images.

  • SERVICE_ACCOUNT durch das Dienstkonto für Ihre Umgebung.

Beispiel:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "imageVersion": "composer-3-airflow-2.10.5-build.10"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Wenn Sie eine Umgebung mit Standardparametern an einem bestimmten Speicherort erstellen möchten, fügen Sie der Terraform-Konfiguration den folgenden Ressourcenblock hinzu und führen Sie terraform apply aus.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    software_config {
      image_version = "IMAGE_VERSION"
    }
    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • ENVIRONMENT_NAME durch den Namen der Umgebung.

    Der Name muss mit einem Kleinbuchstaben beginnen, gefolgt von bis zu 62 Kleinbuchstaben, Ziffern oder Bindestrichen. Das letzte Zeichen darf kein Bindestrich sein. Anhand des Umgebungsnamens werden Unterkomponenten für die Umgebung erstellt. Daher müssen Sie einen Namen angeben, der auch als Cloud Storage-Bucket-Name gültig ist. Eine Liste der Einschränkungen finden Sie in den Benennungsrichtlinien für Buckets.

  • LOCATION durch die Region für die Umgebung.

    Ein Standort ist die Region, in der sich die Umgebung befindet.

  • IMAGE_VERSION durch den Namen eines Cloud Composer-Images.

  • SERVICE_ACCOUNT durch das Dienstkonto für Ihre Umgebung.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    software_config {
      image_version = "composer-3-airflow-2.10.5-build.10"
    }
    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Schritt 3: Optional: Parameter für die Umgebungsskalierung und Leistung konfigurieren

Wählen Sie die Umgebungsgröße und die Arbeitslastkonfiguration aus, um die Skalierungs- und Leistungskonfiguration für Ihre Umgebung anzugeben.

Sie können alle Leistungs- und Skalierungsparameter ändern, nachdem Sie eine Umgebung erstellt haben.

Die folgenden Parameter steuern die Skalierung und Leistung:

  • Umgebungsgröße Steuert die Leistungsparameter der verwalteten Cloud Composer-Infrastruktur, die die Airflow-Datenbank enthält. Wenn Sie eine große Anzahl von DAGs und Aufgaben mit höherer Infrastrukturleistung ausführen möchten, sollten Sie für die Umgebungsgröße einen größeren Wert auswählen. Wenn Sie beispielsweise die Umgebungsgröße erhöhen, kann Ihre Umgebung eine größere Anzahl von Airflow-Aufgabenprotokolleinträgen mit minimaler Verzögerung verarbeiten.

  • Arbeitslastkonfiguration. Steuert die Skalierung und Leistung von Airflow-Komponenten, die in einem GKE-Cluster Ihrer Umgebung ausgeführt werden.

    • Der Airflow-Planer parst DAG-Dateien, plant DAG-Ausführungen anhand des Zeitplanintervalls und stellt Aufgaben zur Ausführung durch Airflow-Worker in die Warteschlange.

      In Ihrer Umgebung können mehrere Airflow-Planer gleichzeitig ausgeführt werden. Mit mehreren Planern lässt sich die Last auf verschiedene Planerinstanzen verteilen, um die Leistung und Zuverlässigkeit zu verbessern.

      Durch die Erhöhung der Anzahl der Planer wird die Airflow-Leistung nicht immer verbessert. Wenn Sie beispielsweise nur einen Planer haben, ist die Leistung möglicherweise besser als zwei. Dies kann passieren, wenn der zusätzliche Planer nicht verwendet wird und somit Ressourcen Ihrer Umgebung verbraucht, ohne dass dies Auswirkungen auf die Gesamtleistung hat. Die tatsächliche Leistung des Planers hängt von der Anzahl der Airflow-Worker, der Anzahl der in der Umgebung ausgeführten DAGs und Aufgaben sowie der Konfiguration von Airflow und der Umgebung ab.

      Wir empfehlen, mit zwei Planern zu beginnen und dann die Leistung Ihrer Umgebung zu überwachen. Wenn Sie die Anzahl der Planer ändern, können Sie Ihre Umgebung jederzeit wieder auf die ursprüngliche Anzahl von Planern skalieren.

      Weitere Informationen zur Konfiguration mehrerer Planer finden Sie in der Airflow-Dokumentation.

    • Airflow-Trigger Überwacht alle ausgesetzten Tasks in Ihrer Umgebung asynchron. Wenn Sie mindestens eine Triggerer-Instanz in Ihrer Umgebung haben (oder mindestens zwei in Umgebungen mit hoher Ausfallsicherheit), können Sie zurückstellbare Operatoren in Ihren DAGs verwenden.

      In Cloud Composer 3 ist der Airflow-Triggerer standardmäßig aktiviert. Wenn Sie eine Umgebung ohne Trigger erstellen möchten, legen Sie die Anzahl der Trigger auf null fest.

    • Airflow-DAG-Prozessor Verarbeitet DAG-Dateien und wandelt sie in DAG-Objekte um. In Cloud Composer 3 wird dieser Teil des Schedulers als separate Umgebungskomponente ausgeführt.

    • Der Airflow-Webserver führt die Airflow-Weboberfläche aus, auf der Sie Ihre DAGs überwachen, verwalten und visualisieren können.

    • Airflow-Worker führen Aufgaben aus, die von Airflow-Planern geplant werden. Die minimale und maximale Anzahl an Workern in Ihrer Umgebung ändert sich dynamisch, je nach Anzahl der Aufgaben in der Warteschlange.

Console

Sie können für Ihre Umgebung eine Voreinstellung auswählen. Wenn Sie eine Voreinstellung auswählen, werden die Skalierungs- und Leistungsparameter für diese Voreinstellung automatisch ausgewählt. Sie haben auch die Möglichkeit, eine benutzerdefinierte Voreinstellung auszuwählen und alle Skalierungs- und Leistungsparameter für Ihre Umgebung anzugeben.

So wählen Sie auf der Seite Umgebung erstellen die Skalierungs- und Leistungskonfiguration für Ihre Umgebung aus:

  • Klicken Sie im Bereich Umgebungsressourcen auf Klein, Mittel oder Groß, um vordefinierte Werte zu verwenden.

  • So geben Sie benutzerdefinierte Werte für die Skalierungs- und Leistungsparameter an:

    1. Klicken Sie im Bereich Umgebungsressourcen auf Benutzerdefiniert.

    2. Legen Sie im Abschnitt Planer die Anzahl der Planer fest, die Sie verwenden möchten, sowie die Ressourcenzuweisung für CPU, Arbeitsspeicher und Speicher.

    3. Geben Sie im Abschnitt Triggerer im Feld Anzahl der Triggerer die Anzahl der Triggerer in Ihrer Umgebung ein.

      Wenn Sie keine zurückstellbaren Operatoren in Ihren DAGs verwenden möchten, legen Sie die Anzahl der Trigger auf null fest.

      Wenn Sie mindestens einen Trigger für Ihre Umgebung festlegen, verwenden Sie die Felder CPU und Arbeitsspeicher, um die Ressourcenzuweisung für Ihre Trigger zu konfigurieren.

    4. Geben Sie im Abschnitt DAG-Prozessor die Anzahl der DAG-Prozessoren in Ihrer Umgebung sowie die Anzahl der CPUs, den Arbeitsspeicher und den Speicherplatz für jeden DAG-Prozessor an.

      Für hochverfügbare Umgebungen sind mindestens zwei DAG-Prozessoren erforderlich.

    5. Geben Sie im Bereich Webserver die Anzahl der CPUs, den Arbeitsspeicher und den Speicher für den Webserver an.

    6. Geben Sie im Bereich Worker Folgendes an:

      • Die Mindest- und Höchstanzahl der Worker für Autoscaling-Limits in Ihrer Umgebung.
      • Die CPU-, Arbeitsspeicher- und Speicherzuweisung für Ihre Worker
    7. Wählen Sie im Bereich Kerninfrastruktur in der Drop-down-Liste Umgebungsgröße die Umgebungsgröße aus.

gcloud

Beim Erstellen einer Umgebung steuern die folgenden Argumente die Skalierungs- und Leistungsparameter Ihrer Umgebung.

  • --environment-size gibt die Umgebungsgröße an.
  • --scheduler-count gibt die Anzahl der Planer an.
  • --scheduler-cpu gibt die Anzahl der CPUs für einen Airflow-Planer an.
  • --scheduler-memory gibt die Größe des Arbeitsspeichers für einen Airflow-Planer an.
  • --scheduler-storage gibt die Menge des Speicherplatzes für einen Airflow-Planer an.

  • --triggerer-count gibt die Anzahl der Airflow-Triggern in Ihrer Umgebung an. Der Standardwert für dieses Flag ist 0. Sie benötigen Trigger, wenn Sie zurückstellbare Operatoren in Ihren DAGs verwenden möchten.

    • Verwenden Sie für Standardumgebungen für die Ausfallsicherheit einen Wert zwischen 0 und 10.
    • Verwenden Sie für hochgradig resiliente Umgebungen 0 oder einen Wert zwischen 2 und 10.
  • --triggerer-cpu gibt die Anzahl der CPUs für einen Airflow-Triggerer in vCPU-Einheiten an. Zulässige Werte: 0.5, 0.75, 1. Der Standardwert ist 0.5

  • --triggerer-memory gibt die Größe des Arbeitsspeichers für einen Airflow-Triggerer in GB an. Der Standardwert ist 0.5.

    Der erforderliche Mindestspeicher entspricht der Anzahl der CPUs, die für die Trigger zugeordnet sind. Der maximal zulässige Wert entspricht der Anzahl der Trigger-CPUs multipliziert mit 6,5.

    Wenn Sie das Flag --triggerer-cpu beispielsweise auf 1 festlegen, ist der Mindestwert für --triggerer-memory 1 und der Höchstwert 6.5.

  • --dag-processor-count gibt die Anzahl der DAG-Prozessoren in der Umgebung an.

    Für hochverfügbare Umgebungen sind mindestens zwei DAG-Prozessoren erforderlich.

  • --dag-processor-cpu gibt die Anzahl der CPUs für den DAG-Prozessor an.

  • --dag-processor-memory gibt die Größe des Arbeitsspeichers für den DAG-Prozessor an.

  • --dag-processor-storage gibt den Speicherplatz für den DAG-Prozessor an.

  • --web-server-cpu gibt die Anzahl der CPUs für den Airflow-Webserver an.

  • --web-server-memory gibt die Größe des Arbeitsspeichers für den Airflow-Webserver an.

  • --web-server-storage gibt den Speicherplatz für den Airflow-Webserver an.

  • --worker-cpu gibt die Anzahl der CPUs für einen Airflow-Worker an.

  • --worker-memory gibt die Größe des Arbeitsspeichers für einen Airflow-Worker an.

  • --worker-storage gibt den Speicherplatz für einen Airflow-Worker an.

  • --min-workers gibt die Mindestanzahl an Airflow-Workern an. Der Cluster Ihrer Umgebung führt mindestens diese Anzahl an Workern aus.

  • --max-workers gibt die Höchstzahl an Airflow-Workern an. Der Cluster Ihrer Umgebung führt höchstens diese Anzahl an Workern aus.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --environment-size ENVIRONMENT_SIZE \
    --scheduler-count SCHEDULER_COUNT \
    --scheduler-cpu SCHEDULER_CPU \
    --scheduler-memory SCHEDULER_MEMORY \
    --scheduler-storage SCHEDULER_STORAGE \
    --triggerer-count TRIGGERER_COUNT \
    --triggerer-cpu TRIGGERER_CPU \
    --triggerer-memory TRIGGERER_MEMORY \
    --dag-processor-count DAG_PROCESSOR_COUNT \
    --dag-processor-cpu DAG_PROCESSOR_CPU \
    --dag-processor-memory DAG_PROCESSOR_MEMORY \
    --dag-processor-storage DAG_PROCESSOR_STORAGE \
    --web-server-cpu WEB_SERVER_CPU \
    --web-server-memory WEB_SERVER_MEMORY \
    --web-server-storage WEB_SERVER_STORAGE \
    --worker-cpu WORKER_CPU \
    --worker-memory WORKER_MEMORY \
    --worker-storage WORKER_STORAGE \
    --min-workers WORKERS_MIN \
    --max-workers WORKERS_MAX

Ersetzen Sie:

  • ENVIRONMENT_SIZE mit small, medium oder large.
  • SCHEDULER_COUNT durch die Anzahl der Planer.
  • SCHEDULER_CPU durch die Anzahl der CPUs für einen Planer in vCPU-Einheiten.
  • SCHEDULER_MEMORY durch die Größe des Arbeitsspeichers für einen Planer.
  • SCHEDULER_STORAGE durch die Laufwerksgröße für einen Planer.
  • TRIGGERER_COUNT durch die Anzahl der Trigger.
  • TRIGGERER_CPU durch die Anzahl der CPUs für einen Trigger in vCPU-Einheiten.
  • TRIGGERER_MEMORY durch die Größe des Arbeitsspeichers für einen Trigger in GB.

  • DAG_PROCESSOR_COUNT durch die Anzahl der DAG-Prozessoren.

  • DAG_PROCESSOR_CPU durch die Anzahl der CPUs für den DAG-Prozessor.

  • DAG_PROCESSOR_MEMORY durch die Größe des Arbeitsspeichers für den DAG-Prozessor.

  • DAG_PROCESSOR_STORAGE durch den Speicherplatz für den DAG-Prozessor.

  • WEB_SERVER_CPU durch die Anzahl der CPUs für den Webserver in vCPU-Einheiten.

  • WEB_SERVER_MEMORY durch die Größe des Arbeitsspeichers für den Webserver.

  • WEB_SERVER_STORAGE durch die Größe des Arbeitsspeichers für den Webserver.

  • WORKER_CPU durch die Anzahl der CPUs für einen Worker in vCPU-Einheiten.

  • WORKER_MEMORY durch die Größe des Arbeitsspeichers für einen Worker.

  • WORKER_STORAGE durch die Laufwerksgröße für einen Worker.

  • WORKERS_MIN durch die Mindestzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung unterschreitet diesen Wert nie, auch nicht, wenn eine niedrigere Anzahl von Workern die Last bewältigen kann.

  • WORKERS_MAX durch die Maximalzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung überschreitet diesen Wert nie, auch wenn eine höhere Anzahl an Workern zur Verarbeitung der Last erforderlich ist.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --environment-size small \
    --scheduler-count 1 \
    --scheduler-cpu 0.5 \
    --scheduler-memory 2.5GB \
    --scheduler-storage 2GB \
    --triggerer-count 1 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5GB \
    --dag-processor-count 1 \
    --dag-processor-cpu 0.5 \
    --dag-processor-memory 2GB \
    --dag-processor-storage 1GB \
    --web-server-cpu 1 \
    --web-server-memory 2.5GB \
    --web-server-storage 2GB \
    --worker-cpu 1 \
    --worker-memory 2GB \
    --worker-storage 2GB \
    --min-workers 2 \
    --max-workers 4

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig > WorkloadsConfig die Skalierungs- und Leistungsparameter der Umgebung an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": SCHEDULER_CPU,
        "memoryGb": SCHEDULER_MEMORY,
        "storageGb": SCHEDULER_STORAGE,
        "count": SCHEDULER_COUNT
      },
      "triggerer": {
        "count": TRIGGERER_COUNT,
        "cpu": TRIGGERER_CPU,
        "memoryGb": TRIGGERER_MEMORY
      },
      "dagProcessor": {
        "count": DAG_PROCESSOR_COUNT,
        "cpu": DAG_PROCESSOR_CPU,
        "memoryGb": DAG_PROCESSOR_MEMORY,
        "storageGb": DAG_PROCESSOR_STORAGE
      },
      "webServer": {
        "cpu": WEB_SERVER_CPU,
        "memoryGb": WEB_SERVER_MEMORY,
        "storageGb": WEB_SERVER_STORAGE
      },
      "worker": {
        "cpu": WORKER_CPU,
        "memoryGb": WORKER_MEMORY,
        "storageGb": WORKER_STORAGE,
        "minCount": WORKERS_MIN,
        "maxCount": WORKERS_MAX
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE",
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • SCHEDULER_CPU durch die Anzahl der CPUs für einen Planer in vCPU-Einheiten.
  • SCHEDULER_MEMORY durch die Größe des Arbeitsspeichers für einen Planer in GB.
  • SCHEDULER_STORAGE durch die Laufwerksgröße für einen Planer in GB.
  • SCHEDULER_COUNT durch die Anzahl der Planer.

  • TRIGGERER_COUNT durch die Anzahl der Trigger. Der Standardwert ist 0. Sie benötigen Trigger, wenn Sie zurückstellbare Operatoren in Ihren DAGs verwenden möchten.

    • Verwenden Sie für Standardumgebungen für die Ausfallsicherheit einen Wert zwischen 0 und 10.
    • Verwenden Sie für hochgradig resiliente Umgebungen 0 oder einen Wert zwischen 2 und 10.

    Wenn Sie mindestens einen Trigger verwenden, müssen Sie auch die Parameter TRIGGERER_CPU und TRIGGERER_MEMORY angeben:

  • TRIGGERER_CPU gibt die Anzahl der CPUs für einen Triggerer in vCPU-Einheiten an. Zulässige Werte: 0.5, 0.75, 1.

  • Mit TRIGGERER_MEMORY wird die Größe des Arbeitsspeichers für einen Triggerer konfiguriert. Der mindestens erforderliche Arbeitsspeicher entspricht der Anzahl der CPUs, die für die Trigger zugeordnet sind. Der maximal zulässige Wert entspricht der Anzahl der Trigger-CPUs multipliziert mit 6,5.

    Wenn Sie TRIGGERER_CPU beispielsweise auf 1 festlegen, ist der Mindestwert für TRIGGERER_MEMORY 1 und der Höchstwert 6.5.

  • DAG_PROCESSOR_COUNT durch die Anzahl der DAG-Prozessoren.

    Für hochverfügbare Umgebungen sind mindestens zwei DAG-Prozessoren erforderlich.

  • DAG_PROCESSOR_CPU durch die Anzahl der CPUs für den DAG-Prozessor in vCPU-Einheiten.

  • DAG_PROCESSOR_MEMORY durch die Größe des Arbeitsspeichers für den DAG-Prozessor in GB.

  • DAG_PROCESSOR_STORAGE durch den Speicherplatz für den DAG-Prozessor in GB.

  • WEB_SERVER_CPU durch die Anzahl der CPUs für den Webserver in vCPU-Einheiten.

  • WEB_SERVER_MEMORY durch die Größe des Arbeitsspeichers für den Webserver in GB.

  • WEB_SERVER_STORAGE durch die Laufwerksgröße für den Webserver in GB.

  • WORKER_CPU durch die Anzahl der CPUs für einen Worker in vCPU-Einheiten.

  • WORKER_MEMORY durch die Größe des Arbeitsspeichers für einen Worker in GB.

  • WORKER_STORAGE durch die Laufwerksgröße für einen Worker in GB.

  • WORKERS_MIN durch die Mindestzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung unterschreitet diesen Wert nie, auch nicht, wenn eine niedrigere Anzahl von Workern die Last bewältigen kann.

  • WORKERS_MAX durch die Maximalzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung überschreitet diesen Wert nie, auch wenn eine höhere Anzahl an Workern zur Verarbeitung der Last erforderlich ist.

  • ENVIRONMENT_SIZE durch die Umgebungsgröße, ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM oder ENVIRONMENT_SIZE_LARGE.

Beispiel:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "workloadsConfig": {
      "scheduler": {
        "cpu": 2.5,
        "memoryGb": 2.5,
        "storageGb": 2,
        "count": 1
      },
      "triggerer": {
        "cpu": 0.5,
        "memoryGb": 0.5,
        "count": 1
      },
      "dagProcessor": {
        "count": 1,
        "cpu": 0.5,
        "memoryGb": 2,
        "storageGb": 1
      },
      "webServer": {
        "cpu": 1,
        "memoryGb": 2.5,
        "storageGb": 2
      },
      "worker": {
        "cpu": 1,
        "memoryGb": 2,
        "storageGb": 2,
        "minCount": 2,
        "maxCount": 4
      }
    },
    "environmentSize": "ENVIRONMENT_SIZE_SMALL",
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Beim Erstellen einer Umgebung steuern die folgenden Argumente die Skalierungs- und Leistungsparameter Ihrer Umgebung.

  • Im Block config:

    • Das Feld environment_size steuert die Umgebungsgröße.
  • Im Block workloads_config:

    • Das scheduler.cpu-Feld gibt die Anzahl der CPUs für einen Airflow-Planer an.
    • Das scheduler.memory_gb-Feld gibt die Größe des Arbeitspeichers für einen Airflow-Planer an.
    • Das scheduler.storage_gb-Feld gibt die Größe des Speicherplatzes für einen Planer an.
    • Das Feld scheduler.count gibt die Anzahl der Planer in Ihrer Umgebung an.
    • Das Feld triggerer.cpu gibt die Anzahl der CPUs für einen Airflow-Triggerer an.
    • Das triggerer.memory_gb-Feld gibt die Größe des Arbeitspeichers für einen Airflow-Trigger an.
    • Das Feld triggerer.count gibt die Anzahl der Trigger in Ihrer Umgebung an.

    • Das Feld dag_processor.cpu gibt die Anzahl der CPUs für einen DAG-Prozessor an.

    • Das Feld dag_processor.memory_gb gibt die Größe des Arbeitsspeichers für einen DAG-Prozessor an.

    • Das Feld dag_processor.storage_gb gibt die Größe des Speicherplatzes für einen DAG-Prozessor an.

    • Das Feld dag_processor.count gibt die Anzahl der DAG-Prozessoren an.

      Für hochverfügbare Umgebungen sind mindestens zwei DAG-Prozessoren erforderlich.

    • Das Feld web_server.cpu gibt die Anzahl der CPUs für den Airflow-Webserver an.

    • Das web_server.memory_gb-Feld gibt die Größe des Arbeitspeichers für den Airflow-Webserver an.

    • Das Feld web_server.storage_gb gibt den Speicherplatz für den Airflow-Webserver an.

    • Das Feld worker.cpu gibt die Anzahl der CPUs für einen Airflow-Worker an.

    • Das Feld worker.memory_gb gibt die Größe des Arbeitspeichers für einen Airflow-Worker an.

    • Das Feld worker.storage_gb gibt die Größe des Speicherplatzes für einen Airflow-Worker an.

    • Das Feld worker.min_count gibt die Mindestanzahl an Workern in Ihrer Umgebung an.

    • Das Feld worker.max_count gibt die Höchstzahl an Workern in Ihrer Umgebung an.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    workloads_config {

      scheduler {
        cpu = SCHEDULER_CPU
        memory_gb = SCHEDULER_MEMORY
        storage_gb = SCHEDULER_STORAGE
        count = SCHEDULER_COUNT
      }
      triggerer {
        count = TRIGGERER_COUNT
        cpu = TRIGGERER_CPU
        memory_gb = TRIGGERER_MEMORY
      }
      dag_processor {
        cpu = DAG_PROCESSOR_CPU
        memory_gb = DAG_PROCESSOR_MEMORY
        storage_gb = DAG_PROCESSOR_STORAGE
        count = DAG_PROCESSOR_COUNT
      }
      web_server {
        cpu = WEB_SERVER_CPU
        memory_gb = WEB_SERVER_MEMORY
        storage_gb = WEB_SERVER_STORAGE
      }
      worker {
        cpu = WORKER_CPU
        memory_gb = WORKER_MEMORY
        storage_gb = WORKER_STORAGE
        min_count = WORKERS_MIN
        max_count = WORKERS_MAX
      }
    }

    environment_size = "ENVIRONMENT_SIZE"

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • ENVIRONMENT_NAME durch den Namen der Umgebung.
  • LOCATION durch die Region, in der sich die Umgebung befindet.
  • SERVICE_ACCOUNT durch das Dienstkonto für Ihre Umgebung.
  • SCHEDULER_CPU durch die Anzahl der CPUs für einen Planer in vCPU-Einheiten.
  • SCHEDULER_MEMORY durch die Größe des Arbeitsspeichers für einen Planer in GB.
  • SCHEDULER_STORAGE durch die Laufwerksgröße für einen Planer in GB.
  • SCHEDULER_COUNT durch die Anzahl der Planer.
  • TRIGGERER_COUNT durch die Anzahl der Trigger.
  • TRIGGERER_CPU durch die Anzahl der CPUs für einen Trigger in vCPU-Einheiten.
  • TRIGGERER_MEMORY durch die Größe des Arbeitsspeichers für einen Trigger in GB.

  • DAG_PROCESSOR_CPU durch die Anzahl der CPUs für den DAG-Prozessor in vCPU-Einheiten.

  • DAG_PROCESSOR_MEMORY durch die Größe des Arbeitsspeichers für den DAG-Prozessor in GB.

  • DAG_PROCESSOR_STORAGE durch den Speicherplatz für den DAG-Prozessor in GB.

  • DAG_PROCESSOR_COUNT durch die Anzahl der DAG-Prozessoren.

  • WEB_SERVER_CPU durch die Anzahl der CPUs für den Webserver in vCPU-Einheiten.

  • WEB_SERVER_MEMORY durch die Größe des Arbeitsspeichers für den Webserver in GB.

  • WEB_SERVER_STORAGE durch die Laufwerksgröße für den Webserver in GB.

  • WORKER_CPU durch die Anzahl der CPUs für einen Worker in vCPU-Einheiten.

  • WORKER_MEMORY durch die Größe des Arbeitsspeichers für einen Worker in GB.

  • WORKER_STORAGE durch die Laufwerksgröße für einen Worker in GB.

  • WORKERS_MIN durch die Mindestzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung unterschreitet diesen Wert nie, auch nicht, wenn eine niedrigere Anzahl von Workern die Last bewältigen kann.

  • WORKERS_MAX durch die Maximalzahl an Airflow-Workern, die Ihre Umgebung ausführen kann. Die Anzahl der Worker in Ihrer Umgebung überschreitet diesen Wert nie, auch wenn eine höhere Anzahl an Workern zur Verarbeitung der Last erforderlich ist.

  • ENVIRONMENT_SIZE durch die Umgebungsgröße, ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM oder ENVIRONMENT_SIZE_LARGE.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    workloads_config {

      scheduler {
        cpu = 2.5
        memory_gb = 2.5
        storage_gb = 2
        count = 1
      }
      triggerer {
        count = 1
        cpu = 0.5
        memory_gb = 0.5
      }
      dag_processor {
        cpu = 1
        memory_gb = 2
        storage_gb = 1
        count = 1
    }
      web_server {
        cpu = 1
        memory_gb = 2.5
        storage_gb = 2
      }
      worker {
        cpu = 1
        memory_gb = 2
        storage_gb = 2
        min_count = 2
        max_count = 4
      }
    }

    environment_size = "ENVIRONMENT_SIZE_SMALL"

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }

  }
}

Schritt 4: Optional: Modus für hohe Ausfallsicherheit aktivieren

Hoch resilient (hochverfügbar): Cloud Composer-Umgebungen, die integrierte Redundanz- und Failover-Mechanismen verwenden, die die Anfälligkeit der Umgebung für zonale Ausfälle und Ausfälle durch Single Points of Failure verringern.

Eine hochgradig resiliente Umgebung ist multizonal und wird in mindestens zwei Zonen einer ausgewählten Region ausgeführt. Die folgenden Komponenten werden in separaten Zonen ausgeführt:

Die Mindestanzahl der Worker ist auf zwei festgelegt und der Cluster Ihrer Umgebung verteilt Worker-Instanzen auf Zonen. Bei einem Zonenausfall werden betroffene Worker-Instanzen in einer anderen Zone neu geplant. Die Cloud SQL-Komponente einer hochverfügbaren Umgebung hat eine primäre Instanz und eine Standby-Instanz, die auf Zonen verteilt sind.

Console

Auf der Seite Umgebung erstellen:

  1. Wählen Sie im Abschnitt Resilience mode (Modus für hohe Ausfallsicherheit) die Option High resilience (Hohe Ausfallsicherheit) aus.

  2. Wählen Sie im Bereich Umgebungsressourcen Skalierungsparameter für eine hochverfügbare Umgebung aus. Für hochgradig resiliente Umgebungen sind genau zwei Scheduler, null oder zwischen zwei und zehn Triggern und mindestens zwei Worker erforderlich:

    1. Klicken Sie auf das Optionsfeld neben Custom (Benutzerdefiniert).

    2. Wählen Sie in der Drop-down-Liste Anzahl der Planer die Option 2 aus.

    3. Wählen Sie in der Drop-down-Liste Anzahl der Trigger die Option 0 oder einen Wert zwischen 2 und 10 aus. Konfigurieren Sie die CPU- und Arbeitsspeicherzuweisung für Ihre Trigger.

    4. Wählen Sie in der Drop-down-Liste Mindestanzahl von Workern je nach erforderlicher Anzahl von Workern 2 oder mehr aus.

  3. Im Abschnitt Netzwerkkonfiguration:

    1. Wählen Sie unter Netzwerktyp die Option Umgebung mit privater IP aus.

    2. Geben Sie bei Bedarf weitere Netzwerkparameter an.

gcloud

Wenn Sie eine Umgebung erstellen, aktiviert das Argument --enable-high-resilience den Modus mit hoher Resilienz.

Legen Sie die folgenden Argumente fest:

  • --enable-high-resilience
  • --enable-private-environment und andere Netzwerkparameter für eine Umgebung mit privaten IP-Adressen, falls erforderlich
  • --scheduler-count bis 2
  • --triggerer-count bis 0 oder ein Wert zwischen 2 und 10. Wenn Sie Triggerer verwenden, sind die Flags --triggerer-cpu and--triggerer-memory` auch für die Umgebungserstellung erforderlich.

    Weitere Informationen zu den Flags --triggerer-count, --triggerer-cpu und --triggerer-memory finden Sie unter Parameter für die Umgebungsskalierung und Leistung konfigurieren.

  • --min-workers bis 2 oder mehr

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-high-resilience \
    --enable-private-environment \
    --scheduler-count 2 \
    --triggerer-count 2 \
    --triggerer-cpu 0.5 \
    --triggerer-memory 0.5 \
    --min-workers 2

API

Aktivieren Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig den Modus für hohe Resilienz.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE",
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }

  }
}

Beispiel:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "resilience_mode": "HIGH_RESILIENCE",
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }

  }
}

Terraform

Wenn Sie eine Umgebung erstellen, wird mit dem Feld resilience_mode im Block config der Modus mit hoher Resilienz aktiviert.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    resilience_mode = "HIGH_RESILIENCE"

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    resilience_mode = "HIGH_RESILIENCE"

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Schritt 5: Optional: Zone für die Datenbank der Umgebung angeben

Sie können beim Erstellen einer Umgebung mit Standardresilienz eine bevorzugte Cloud SQL-Zone angeben.

Console

Auf der Seite Umgebung erstellen:

  1. Maximieren Sie im Bereich Erweiterte Konfiguration das Element Erweiterte Konfiguration anzeigen.

  2. Wählen Sie in der Liste Airflow-Datenbankzone eine bevorzugte Cloud SQL-Zone aus.

gcloud

Wenn Sie eine Umgebung erstellen, gibt das Argument --cloud-sql-preferred-zone eine bevorzugte Cloud SQL-Zone an.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --cloud-sql-preferred-zone SQL_ZONE

Ersetzen Sie Folgendes:

  • SQL_ZONE: bevorzugte Cloud SQL-Zone. Diese Zone muss sich in der Region befinden, in der sich die Umgebung befindet.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --cloud-sql-preferred-zone us-central1-a

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > DatabaseConfig die bevorzugte Cloud SQL-Zone an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "databaseConfig": {
      "zone": "SQL_ZONE"
    },
      "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie Folgendes:

  • SQL_ZONE: bevorzugte Cloud SQL-Zone. Diese Zone muss sich in der Region befinden, in der sich die Umgebung befindet.

Beispiel:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "databaseConfig": {
      "zone": "us-central1-a"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Wenn Sie eine Umgebung erstellen, gibt das Feld zone im Block database_config die bevorzugte Cloud SQL-Zone an.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    database_config {
      zone = "SQL_ZONE"
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie Folgendes:

  • SQL_ZONE: bevorzugte Cloud SQL-Zone. Diese Zone muss sich in der Region befinden, in der sich die Umgebung befindet.

Schritt 6: Optional: Netzwerk der Umgebung konfigurieren

Sie können das Netzwerk von Cloud Composer 3 auf folgende Arten konfigurieren:

Console

  1. Achten Sie darauf, dass Ihr Netzwerk für den Umgebungstyp konfiguriert ist, den Sie erstellen möchten.

  2. Maximieren Sie im Bereich Netzwerkkonfiguration das Element Netzwerkkonfiguration anzeigen.

  3. Wenn Sie Ihre Umgebung mit einem VPC-Netzwerk verbinden möchten, wählen Sie im Feld Netzwerk-Attachment ein Netzwerk-Attachment aus. Sie können auch einen neuen Netzwerkanhang erstellen. Weitere Informationen finden Sie unter Umgebung mit einem VPC-Netzwerk verbinden.

  4. Wenn Sie eine Umgebung mit privater IP erstellen möchten, wählen Sie im Bereich Netzwerktyp die Option Umgebung mit privater IP aus.

  5. Wenn Sie Netzwerktags hinzufügen möchten, finden Sie hier weitere Informationen.

gcloud

Achten Sie darauf, dass Ihr Netzwerk für den Umgebungstyp konfiguriert ist, den Sie erstellen möchten.

Wenn Sie eine Umgebung erstellen, steuern die folgenden Argumente die Netzwerkparameter. Wenn Sie einen Parameter weglassen, wird der Standardwert verwendet.

  • --enable-private-environment ermöglicht eine Umgebung mit privater IP.

  • --network gibt Ihre VPC-Netzwerk-ID an.

  • --subnetwork gibt Ihre VPC-Subnetzwerk-ID an.

Beispiel (private IP-Umgebung mit einem verbundenen VPC-Netzwerk)

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-private-environment \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \

Ersetzen Sie:

  • NETWORK_ID durch Ihre VPC-Netzwerk-ID.
  • SUBNETWORK_ID durch Ihre VPC-Subnetzwerk-ID.

Schritt 7: Optional: Netzwerk-Tags hinzufügen

Netzwerk-Tags werden auf alle Knoten-VMs im Cluster Ihrer Umgebung angewendet. Tags werden verwendet, um gültige Quellen oder Ziele für Netzwerkfirewalls zu bestimmen. Jedes Tag in der Liste muss RFC 1035 entsprechen.

Sie können beispielsweise Netzwerk-Tags hinzufügen, wenn Sie den Traffic für eine Umgebung mit privater IP-Adresse mit Firewallregeln einschränken möchten.

Console

Auf der Seite Umgebung erstellen:

  1. Suchen Sie den Abschnitt Netzwerkkonfiguration.
  2. Geben Sie im Feld Netzwerk-Tags Netzwerk-Tags für Ihre Umgebung ein.

gcloud

Beim Erstellen einer Umgebung steuern die folgenden Argumente die Netzwerk-Tags:

  • --tags gibt eine durch Kommas getrennte Liste von Netzwerk-Tags an, die auf alle Knoten-VMs angewendet werden.
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --tags TAGS

Ersetzen Sie:

  • TAGS durch eine durch Kommas getrennte Liste von Netzwerk-Tags ersetzen.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --tags group1,production

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig Netzwerk-Tags für Ihre Umgebung an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeConfig": {
      "tags": [
        "TAG"
      ],
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • TAG durch ein Netzwerk-Tag.

Beispiel:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeConfig": {
      "tags": [
        "group1",
        "production"
      ],
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Beim Erstellen einer Umgebung definieren die folgenden Felder Netzwerk-Tags für Ihre Umgebung:

  • Das Feld tags im Block node_config gibt eine durch Kommas getrennte Liste von Netzwerk-Tags an, die auf alle Knoten-VMs angewendet werden.
resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      tags = ["TAGS"]
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • TAGS durch eine durch Kommas getrennte Liste von Netzwerk-Tags ersetzen.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    node_config {
      tags = ["group1","production"]
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Schritt 8: Optional: Netzwerkzugriff für Webserver konfigurieren

Die Zugriffsparameter für den Airflow-Webserver hängen nicht vom Typ Ihrer Umgebung ab. Stattdessen können Sie den Webserverzugriff separat konfigurieren. Beispiel: In einer privaten IP-Umgebung kann die Airflow-UI weiterhin über das Internet zugänglich sein.

Sie können die zulässigen IP-Bereiche nicht mithilfe privater IP-Adressen konfigurieren.

Console

Auf der Seite Umgebung erstellen:

  1. Maximieren Sie im Bereich Netzwerkkonfiguration das Element Netzwerkkonfiguration anzeigen.

  2. Im Abschnitt Webserver-Netzwerkzugriffssteuerung:

    • Wählen Sie Zugriff über alle IP-Adressen zulassen aus, um den Zugriff auf den Airflow-Webserver über alle IP-Adressen zu ermöglichen.

    • Wenn Sie den Zugriff auf bestimmte IP-Bereiche beschränken möchten, wählen Sie Zugriff nur von bestimmten IP-Adressen zulassen aus. Geben Sie im Feld IP-Bereich einen IP-Bereich in der CIDR-Notation an. Geben Sie im Feld Beschreibung eine optionale Beschreibung für diesen Bereich an. Wenn Sie mehrere Bereiche angeben möchten, klicken Sie auf IP-Bereich hinzufügen.

    • Wenn Sie den Zugriff für alle IP-Adressen verbieten möchten, wählen Sie Zugriff nur von bestimmten IP-Adressen zulassen aus und klicken Sie neben dem leeren Bereichseintrag auf Element löschen.

gcloud

Beim Erstellen einer Umgebung steuern die folgenden Argumenten die Zugriffsebene des Webservers:

  • --web-server-allow-all bietet Zugriff auf Airflow von allen IP-Adressen aus. Dies ist die Standardoption.

  • --web-server-allow-ip beschränkt den Zugriff auf bestimmte Quell-IP-Bereiche. Wenn Sie mehrere IP-Bereiche angeben möchten, verwenden Sie dieses Argument mehrmals.

  • --web-server-deny-all verbietet den Zugriff für alle IP-Adressen.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --web-server-allow-ip ip_range=WS_IP_RANGE,description=WS_RANGE_DESCRIPTION

Ersetzen Sie:

  • WS_IP_RANGE durch den IP-Bereich (in CIDR-Notation), der auf die Airflow-UI zugreifen darf.
  • WS_RANGE_DESCRIPTION durch die Beschreibung des IP-Bereichs.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --web-server-allow-ip ip_range=192.0.2.0/24,description="office net 1" \
    --web-server-allow-ip ip_range=192.0.4.0/24,description="office net 3"

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig die Webserverzugriffsparameter an.

  • Wenn Sie Zugriff auf den Airflow-Webserver über alle IP-Adressen gewähren möchten, lassen Sie webServerNetworkAccessControl weg.

  • Wenn Sie den Zugriff auf bestimmte IP-Bereiche beschränken möchten, geben Sie einen oder mehrere Bereiche in allowedIpRanges an.

  • Wenn Sie den Zugriff für alle IP-Adressen verbieten möchten, fügen Sie allowedIpRanges hinzu und machen Sie daraus eine leere Liste. Geben Sie darin keine IP-Bereiche an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "WS_IP_RANGE",
          "description": "WS_RANGE_DESCRIPTION"
        }
      ]
    },
      "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • WS_IP_RANGE durch den IP-Bereich (in CIDR-Notation), der auf die Airflow-UI zugreifen darf.
  • WS_RANGE_DESCRIPTION durch die Beschreibung des IP-Bereichs.

Beispiel:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "webServerNetworkAccessControl": {
      "allowedIpRanges": [
        {
          "value": "192.0.2.0/24",
          "description": "office net 1"
        },
        {
          "value": "192.0.4.0/24",
          "description": "office net 3"
        }
      ]
    },
      "nodeConfig": {
        "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Beim Erstellen einer Umgebung enthält der Block allowed_ip_range im Block web_server_network_access_control IP-Bereiche, die auf den Webserver zugreifen können.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    web_server_network_access_control {

      allowed_ip_range {
        value = "WS_IP_RANGE"
        description = "WS_RANGE_DESCRIPTION"
      }
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • WS_IP_RANGE durch den IP-Bereich (in CIDR-Notation), der auf die Airflow-UI zugreifen darf.
  • WS_RANGE_DESCRIPTION durch die Beschreibung des IP-Bereichs.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    web_server_network_access_control {
      allowed_ip_range {
        value = "192.0.2.0/24"
        description = "office net 1"
      },
      allowed_ip_range {
        value = "192.0.4.0/24"
        description = "office net 3"
      }
    }

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }

}

Schritt 9: Optional: Airflow-Konfigurationsüberschreibungen und Umgebungsvariablen angeben

Sie können beim Erstellen einer Umgebung Airflow-Konfigurationsüberschreibungen und Umgebungsvariablen einrichten. Alternativ können Sie dies später tun, nachdem Ihre Umgebung erstellt wurde.

Einige Airflow-Konfigurationsoptionen sind gesperrt und können nicht überschrieben werden.

Eine Liste der verfügbaren Airflow-Konfigurationsoptionen finden Sie unter Konfigurationsreferenz für Airflow 2 und Airflow 1.10.*.

So geben Sie Airflow-Konfigurationsüberschreibungen und Umgebungsvariablen an:

Console

Auf der Seite Umgebung erstellen:

  1. Klicken Sie im Bereich Umgebungsvariablen auf Umgebungsvariable hinzufügen.

  2. Geben Sie den Namen und den Wert der Umgebungsvariablen ein.

  3. Klicken Sie im Bereich Airflow-Konfigurationsüberschreibungen auf Airflow Konfigurationsüberschreibung hinzufügen.

  4. Geben Sie den Bereich, den Schlüssel und den Wert für die Überschreibung der Konfigurationsoption ein.

    Beispiel:

    Bereich Schlüssel Wert
    webserver dag_orientation TB

gcloud

Beim Erstellen einer Umgebung steuern die folgenden Argumente die Umgebungsvariablen und die Airflow-Konfigurationsüberschreibungen:

  • --env-variables gibt eine durch Kommas getrennte Liste von Umgebungsvariablen an.

    Variablennamen können Groß- und Kleinbuchstaben, Ziffern und Unterstriche enthalten, dürfen jedoch nicht mit einer Ziffer beginnen.

  • --airflow-configs gibt eine durch Kommas getrennte Liste von Schlüsseln und Werten für Airflow-Konfigurationsüberschreibungen an.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --env-variables ENV_VARS \
    --airflow-configs CONFIG_OVERRIDES

Ersetzen Sie:

  • ENV_VARS durch eine Liste kommagetrennter NAME=VALUE-Paare für Umgebungsvariablen.
  • CONFIG_OVERRIDES durch eine Liste kommagetrennter SECTION-KEY=VALUE-Paare für Konfigurationsüberschreibungen. Trennen Sie den Namen des Konfigurationsbereichs durch ein --Symbol, gefolgt vom Schlüsselnamen. Beispiel: core-dags_are_paused_at_creation.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --env-variables SENDGRID_MAIL_FROM=user@example.com,SENDGRID_API_KEY=example-key \
    --airflow-configs core-dags_are_paused_at_creation=True,webserver-dag_orientation=TB

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig Umgebungsvariablen und Airflow-Konfigurationsüberschreibungen an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "SECTION-KEY": "OVERRIDE_VALUE"
      },
      "envVariables": {
        "VAR_NAME": "VAR_VALUE",
      }
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • SECTION durch den Bereich in der Konfigurationsdatei, in dem sich die Airflow-Konfigurationsoption befindet.
  • KEY durch den Namen der Airflow-Konfigurationsoption.
  • OVERRIDE_VALUE durch einen Wert der Airflow-Konfigurationsoption.
  • VAR_NAME durch den Namen der Umgebungsvariablen.
  • VAR_VALUE durch den Wert der Umgebungsvariablen.

Beispiel:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "core-dags_are_paused_at_creation": "True",
        "webserver-dag_orientation": "TB"
      },
      "envVariables": {
        "SENDGRID_MAIL_FROM": "user@example.com",
        "SENDGRID_API_KEY": "example-key"
      }
    },
    "nodeConfig": {
        "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

Beim Erstellen einer Umgebung steuern die folgenden Blöcke Umgebungsvariablen und Airflow-Konfigurationsüberschreibungen:

  • Der Block env_variables im Block software_config gibt Umgebungsvariablen an.

    Variablennamen können Groß- und Kleinbuchstaben, Ziffern und Unterstriche enthalten, dürfen jedoch nicht mit einer Ziffer beginnen.

  • Der Block airflow_config_overrides im Block software_config gibt Airflow-Konfigurationsüberschreibungen an.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    software_config {

      airflow_config_overrides = {
        SECTION-KEY = "OVERRIDE_VALUE"
      }

      env_variables = {
        VAR_NAME = "VAR_VALUE"
      }
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

Ersetzen Sie:

  • SECTION durch den Bereich in der Konfigurationsdatei, in dem sich die Airflow-Konfigurationsoption befindet.
  • KEY durch den Namen der Airflow-Konfigurationsoption.
  • OVERRIDE_VALUE durch einen Wert der Airflow-Konfigurationsoption.
  • VAR_NAME durch den Namen der Umgebungsvariablen.
  • VAR_VALUE durch den Wert der Umgebungsvariablen.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {

    software_config {

      airflow_config_overrides = {
        core-dags_are_paused_at_creation = "True"
        webserver-dag_orientation = "TB"
      }

      env_variables = {
        SENDGRID_MAIL_FROM = "user@example.com"
        SENDGRID_API_KEY = "example-key"
      }
    }

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Schritt 10: Optional: Wartungsfenster angeben

Standardmäßige Wartungsfenster in Cloud Composer 3 werden so definiert:

  • Alle Zeiten werden in der lokalen Zeitzone der Region angegeben, in der sich Ihre Umgebung befindet, wobei die Sommerzeit ignoriert wird.
  • Dienstag, Mittwoch, Donnerstag und Freitag sind Wartungsfenster von 00:00:00 bis 02:00:00 Uhr.
  • Samstags, sonntags und montags sind Wartungsfenster von 00:00:00 bis 04:00:00 Uhr.

So geben Sie benutzerdefinierte Wartungsfenster für Ihre Umgebung an:

Console

Auf der Seite Umgebung erstellen

  1. Suchen Sie den Bereich Wartungsfenster.

  2. Wählen Sie in der Drop-down-Liste Zeitzone eine Zeitzone für Wartungsfenster aus.

  3. Legen Sie Startzeit, Tage und Länge so fest, dass:

    • In einer Woche sind mindestens 12 Stunden vorgesehen.

    • Sie können mehrere Zeiträume verwenden, aber jeder Zeitraum muss mindestens 4 Stunden dauern.

    Zum Beispiel bietet ein Zeitraum von vier Stunden jeden Montag, Mittwoch und Freitag die erforderliche Zeitmenge.

gcloud

Mit den folgenden Argumenten werden die Wartungsfensterparameter definiert:

  • --maintenance-window-start legt den Beginn eines Wartungsfensters fest.
  • --maintenance-window-end legt das Ende eines Wartungsfensters fest.
  • --maintenance-window-recurrence legt die Wiederholung des Wartungsfensters fest.
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --maintenance-window-start 'DATETIME_START' \
    --maintenance-window-end 'DATETIME_END' \
    --maintenance-window-recurrence 'MAINTENANCE_RECURRENCE'

Ersetzen Sie:

  • ENVIRONMENT_NAME durch den Namen der Umgebung.
  • DATETIME_START durch das Startdatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert.
  • DATETIME_END durch das Enddatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert. Das angegebene Datum und die angegebene Uhrzeit müssen nach dem Startdatum liegen.
  • MAINTENANCE_RECURRENCE mit einer RFC 5545 RRULE für Wiederholungsversuche von Wartungsfenstern. Cloud Composer unterstützt zwei Formate:

  • Das Format FREQ=DAILY gibt eine tägliche Wiederholung an.

  • Das Format FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA gibt eine Wiederholung an ausgewählten Wochentagen an.

Im folgenden Beispiel wird ein Wartungsfenster von 6 Stunden zwischen 01:00 und 07:00 Uhr (UTC) an Mittwochen, Samstagen und Sonntagen angegeben. Das Datum 1. Januar 2023 wird ignoriert.

gcloud composer environments create example-environment \
  --location us-central1 \
  --image-version composer-3-airflow-2.10.5-build.10 \
  --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
  --maintenance-window-start '2023-01-01T01:00:00Z' \
  --maintenance-window-end '2023-01-01T07:00:00Z' \
  --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SU,WE,SA'

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung > EnvironmentConfig Wartungsfensterparameter an:

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "maintenanceWindow": {
        "startTime": "DATETIME_START",
        "endTime": "DATETIME_END",
        "recurrence": "MAINTENANCE_RECURRENCE"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • DATETIME_START durch das Startdatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert.
  • DATETIME_END durch das Enddatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert. Das angegebene Datum und die angegebene Uhrzeit müssen nach dem Startdatum liegen.
  • MAINTENANCE_RECURRENCE mit einer RFC 5545 RRULE für Wiederholungsversuche von Wartungsfenstern. Cloud Composer unterstützt zwei Formate:

  • Das Format FREQ=DAILY gibt eine tägliche Wiederholung an.

  • Das Format FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA gibt eine Wiederholung an ausgewählten Wochentagen an.

Im folgenden Beispiel wird ein Wartungsfenster von 6 Stunden zwischen 01:00 und 07:00 Uhr (UTC) an Mittwochen, Samstagen und Sonntagen angegeben. Das Datum 1. Januar 2023 wird ignoriert.

Beispiel:

// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "maintenanceWindow": {
        "startTime": "2023-01-01T01:00:00Z",
        "endTime": "2023-01-01T07:00:00Z",
        "recurrence": "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Terraform

Im Block maintenance_window werden die Wartungsfenster für Ihre Umgebung angegeben:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {
    maintenance_window {
      start_time = "DATETIME_START"
      end_time = "DATETIME_END"
      recurrence = "MAINTENANCE_RECURRENCE"
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

Ersetzen Sie:

  • DATETIME_START durch das Startdatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert.
  • DATETIME_END durch das Enddatum und die Uhrzeit im Eingabeformat Datum/Uhrzeit. Es wird nur die angegebene Uhrzeit verwendet. Das angegebene Datum wird ignoriert. Das angegebene Datum und die angegebene Uhrzeit müssen nach dem Startdatum liegen.
  • MAINTENANCE_RECURRENCE mit einer RFC 5545 RRULE für Wiederholungsversuche von Wartungsfenstern. Cloud Composer unterstützt zwei Formate:

    • Das Format FREQ=DAILY gibt eine tägliche Wiederholung an.
    • Das Format FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA gibt eine Wiederholung an ausgewählten Wochentagen an.

Im folgenden Beispiel wird ein Wartungsfenster von 6 Stunden zwischen 01:00 und 07:00 Uhr (UTC) an Mittwochen, Samstagen und Sonntagen angegeben. Das Datum 1. Januar 2023 wird ignoriert.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  config {
    maintenance_window {
      start_time = "2023-01-01T01:00:00Z"
      end_time = "2023-01-01T07:00:00Z"
      recurrence = "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    }
  }
}

Schritt 11: (Optional) Einbindung von Data Lineage

Die Datenherkunft ist eine Dataplex Universal Catalog-Funktion, mit der Sie die Datenbewegung verfolgen können.

Die Einbindung von Data Lineage ist in allen Versionen von Cloud Composer 3 verfügbar.

Die Einbindung von Data Lineage ist in einer neuen Cloud Composer-Umgebung automatisch aktiviert, wenn die folgenden Bedingungen erfüllt sind:

  • Die Data Lineage API ist in Ihrem Projekt aktiviert. Weitere Informationen finden Sie in der Dataplex Universal Catalog-Dokumentation unter Data Lineage API aktivieren.

  • In Airflow ist kein benutzerdefiniertes Lineage-Backend konfiguriert.

Sie können die Integration der Datenherkunft beim Erstellen einer Umgebung deaktivieren. Das ist beispielsweise der Fall, wenn Sie das automatische Verhalten überschreiben oder die Datenherkunft später aktivieren möchten, nachdem die Umgebung erstellt wurde.

Console

So deaktivieren Sie die Data Lineage-Integration auf der Seite Umgebung erstellen:

  1. Maximieren Sie im Bereich Erweiterte Konfiguration das Element Erweiterte Konfiguration anzeigen.

  2. Wählen Sie im Bereich Einbindung von Dataplex Data Lineage die Option Einbindung in Dataplex Data Lineage deaktivieren aus.

gcloud

Wenn Sie eine Umgebung erstellen, wird mit dem Argument --disable-cloud-data-lineage-integration die Integration der Datenherkunft deaktiviert.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --disable-cloud-data-lineage-integration

Ersetzen Sie:

  • ENVIRONMENT_NAME durch den Namen der Umgebung.
  • LOCATION durch die Region, in der sich die Umgebung befindet.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --disable-cloud-data-lineage-integration

Schritt 12: (Optional) Datenverschlüsselung (CMEK) konfigurieren

Standardmäßig werden Daten in Ihrer Umgebung mit einem von Google bereitgestellten Schlüssel verschlüsselt.

Folgen Sie der unter Vom Kunden verwaltete Verschlüsselungsschlüssel verwenden beschriebenen Anleitung, um vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) zum Verschlüsseln von Daten in Ihrer Umgebung zu verwenden.

Schritt 13: Optional: Bucket einer benutzerdefinierten Umgebung verwenden

Wenn Sie eine Umgebung erstellen, wird von Cloud Composer automatisch ein Bucket für Ihre Umgebung erstellt.

Alternativ können Sie einen benutzerdefinierten Cloud Storage-Bucket aus Ihrem Projekt angeben. In Ihrer Umgebung wird dieser Bucket auf dieselbe Weise wie der automatisch erstellte Bucket verwendet.

Wenn Sie einen benutzerdefinierten Umgebungs-Bucket verwenden möchten, folgen Sie der Anleitung unter Bucket einer benutzerdefinierten Umgebung verwenden.

Schritt 14: Optional: Datenbankaufbewahrung konfigurieren

Wenn Sie die Datenbankaufbewahrung in Ihrer Umgebung aktivieren, werden in Cloud Composer regelmäßig Datensätze zu DAG-Ausführungen und Nutzersitzungen, die älter als der angegebene Zeitraum sind, aus der Airflow-Datenbank entfernt. Die Informationen zur letzten DAG-Ausführung werden immer beibehalten.

Die Datenbankaufbewahrung ist standardmäßig aktiviert. Wenn Sie den Aufbewahrungszeitraum für eine neue Umgebung konfigurieren oder die Datenbankaufbewahrung deaktivieren möchten, folgen Sie der Anleitung unter Datenbankaufbewahrungsrichtlinie konfigurieren. Sie können die Aufbewahrung von Datenbanken auch später konfigurieren.

Schritt 15: Optional: Umgebungslabels angeben

Sie können Ihren Umgebungen Labels zuweisen, um die Abrechnungskosten basierend auf diesen Labels aufzuschlüsseln.

Console

Gehen Sie auf der Seite Umgebung erstellen im Bereich Labels so vor:

  1. Klicken Sie auf Label hinzufügen.

  2. Geben Sie in den Feldern Schlüssel und Wert Schlüssel/Wert-Paare für die Umgebungslabels an.

gcloud

Beim Erstellen einer Umgebung gibt das Argument --labels eine durch Kommas getrennte Liste von Schlüsseln und Werten mit Umgebungslabels an.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "SERVICE_ACCOUNT" \
    --labels LABELS

Ersetzen Sie:

  • LABELS durch eine Liste kommagetrennter KEY=VALUE-Paare für Umgebungslabels.

Beispiel:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.10.5-build.10 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --labels owner=engineering-team,env=production

API

Geben Sie beim Erstellen einer Umgebung in der Ressource Umgebung Labels für Ihre Umgebung an.

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "labels": {
    "LABEL_KEY": "LABEL_VALUE"
  }
}

Ersetzen Sie:

  • LABEL_KEY durch einen Schlüssel des Umgebungslabels.
  • LABEL_VALUE durch einen Wert des Umgebungslabels.

Beispiel:


// POST https://composer.googleapis.com/v1/{parent=projects/*/locations/*}/environments

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "labels": {
    "owner": "engineering-team",
    "env": "production"
  }
}

Terraform

Geben Sie beim Erstellen einer Umgebung Labels im Block labels (außerhalb des Blocks config) an.

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  labels = {
    LABEL_KEY = "LABEL_VALUE"
  }

}

Ersetzen Sie:

  • LABEL_KEY durch einen Schlüssel des Umgebungslabels.
  • LABEL_VALUE durch einen Wert des Umgebungslabels.

Beispiel:

resource "google_composer_environment" "example" {
  provider = google-beta
  name = "example-environment"
  region = "us-central1"

  labels = {
    owner = "engineering-team"
    env = "production"
  }

}

Nächste Schritte