הפעלת DAG באמצעות Cloud Functions והודעות Pub/Sub

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

בדף הזה מוסבר איך ליצור ארכיטקטורת דחיפה מבוססת-אירועים על ידי הפעלה של DAG של Managed Airflow בתגובה לשינויים בנושא Pub/Sub. הדוגמאות במדריך הזה מדגימות איך לטפל במחזור המלא של ניהול Pub/Sub, כולל ניהול מינויים, כחלק מתהליך DAG. האפשרות הזו מתאימה לחלק מתרחישי השימוש הנפוצים שבהם צריך להפעיל DAG, אבל לא רוצים להגדיר הרשאות גישה נוספות.

לדוגמה, אפשר להשתמש בהודעות שנשלחות דרך Pub/Sub כפתרון אם לא רוצים לספק גישה ישירה לסביבת Managed Airflow מטעמי אבטחה. אפשר להגדיר פונקציית Cloud Run שיוצרת הודעות Pub/Sub ומפרסמת אותן בנושא Pub/Sub. אחר כך תוכלו ליצור DAG ששולף הודעות Pub/Sub ומטפל בהן.

בדוגמה הספציפית הזו, יוצרים פונקציית Cloud Run ופורסים שני DAG. ה-DAG הראשון שולף הודעות Pub/Sub ומפעיל את ה-DAG השני בהתאם לתוכן ההודעה ב-Pub/Sub.

המדריך הזה מתבסס על ההנחה שאתם מכירים את Python ואת מסוף Google Cloud .

מטרות

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי להימנע מחיובים נוספים אחרי שסיימתם את המדריך, תוכלו למחוק את המשאבים שיצרתם. פרטים נוספים מופיעים במאמר בנושא הסרת המשאבים.

לפני שמתחילים

במדריך הזה תצטרכו Google Cloud פרויקט. מגדירים את הפרויקט באופן הבא:

  1. במסוף Google Cloud , בוחרים פרויקט או יוצרים פרויקט:

    מעבר לדף לבחירת הפרויקט

  2. מוודאים שהחיוב מופעל בפרויקט. איך בודקים אם החיוב מופעל בפרויקט

  3. כדי ליצור את המשאבים הנדרשים, צריך לוודא שלמשתמש בפרויקט יש את התפקידים הבאים: Google Cloud

    • משתמש בחשבון שירות (roles/iam.serviceAccountUser)
    • עורך Pub/Sub (roles/pubsub.editor)
    • אדמין של סביבה ואובייקטים באחסון (roles/composer.environmentAndStorageObjectAdmin)
    • אדמין של פונקציות Cloud Run (roles/cloudfunctions.admin)
    • כלי לצפייה ביומנים (roles/logging.viewer)

  4. מוודאים שלחשבון השירות שמריץ את פונקציית Cloud Run יש הרשאות מספיקות בפרויקט כדי לגשת ל-Pub/Sub. כברירת מחדל, פונקציות Cloud Run משתמשות בחשבון השירות שמוגדר כברירת מחדל ב-App Engine. לחשבון השירות הזה יש תפקיד עריכה, עם הרשאות מספיקות לשימוש במדריך הזה.

הפעלת ממשקי API בפרויקט

המסוף

מפעילים את Managed Airflow API, את Cloud Run functions API ואת Pub/Sub API.

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

הפעלת ממשקי ה-API

gcloud

מפעילים את ממשקי ה-API של Managed Airflow, פונקציות Cloud Run ו-Pub/Sub:

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים 

gcloud services enable composer.googleapis.com cloudfunctions.googleapis.com pubsub.googleapis.com

Terraform

כדי להפעיל את Cloud Composer API בפרויקט, מוסיפים את הגדרות המשאבים הבאות לסקריפט Terraform:

resource "google_project_service" "composer_api" {
  project = "<PROJECT_ID>"
  service = "composer.googleapis.com"
  // Disabling Cloud Composer API might irreversibly break all other
  // environments in your project.
  // This parameter prevents automatic disabling
  // of the API when the resource is destroyed.
  // We recommend to disable the API only after all environments are deleted.
  disable_on_destroy = false
// this flag is introduced in 5.39.0 version of Terraform. If set to true it will
//prevent you from disabling composer_api through Terraform if any environment was
//there in the last 30 days
  check_if_service_has_usage_on_destroy = true
}

resource "google_project_service" "pubsub_api" {
  project = "<PROJECT_ID>"
  service = "pubsub.googleapis.com"
  disable_on_destroy = false
}

resource "google_project_service" "functions_api" {
  project = "<PROJECT_ID>"
  service = "cloudfunctions.googleapis.com"
  disable_on_destroy = false
}

מחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט. לדוגמה, example-project.

יצירת סביבת Managed Airflow

איך יוצרים סביבת Managed Airflow (דור 2)

במסגרת התהליך הזה, מקצים את התפקיד Cloud Composer v2 API Service Agent Extension (roles/composer.ServiceAgentV2Ext) לחשבון של סוכן השירות של Composer. ‫Managed Airflow משתמש בחשבון הזה כדי לבצע פעולות בפרויקט Google Cloud שלכם.

יוצרים נושא Pub/Sub

בדוגמה הזו מופעל DAG בתגובה להודעה שנשלחת לנושא Pub/Sub. יוצרים נושא Pub/Sub לשימוש בדוגמה הזו:

המסוף

  1. נכנסים לדף Pub/Sub Topics במסוף Google Cloud .

    מעבר אל Pub/Sub Topics

  2. לוחצים על יצירת נושא.

  3. בשדה Topic ID (מזהה הנושא), מזינים את הערך dag-topic-trigger כמזהה של הנושא.

  4. משאירים את ערכי ברירת המחדל בשאר האפשרויות.

  5. לוחצים על יצירת נושא.

gcloud

כדי ליצור נושא, מריצים את הפקודה gcloud pubsub topics create ב-Google Cloud CLI:

gcloud pubsub topics create dag-topic-trigger

Terraform

מוסיפים את הגדרות המשאבים הבאות לסקריפט Terraform:

resource "google_pubsub_topic" "trigger" {
  project                    = "<PROJECT_ID>"
  name                       = "dag-topic-trigger"
  message_retention_duration = "86600s"
}

מחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט. לדוגמה, example-project.

העלאת קובצי DAG

מעלים DAG לסביבה:

  1. שומרים את קובץ ה-DAG הבא במחשב המקומי.
  2. מחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט. לדוגמה, example-project.
  3. מעלים את קובץ ה-DAG הערוך לסביבה שלכם.
from __future__ import annotations

from datetime import datetime
import time

from airflow import DAG
from airflow import XComArg
from airflow.operators.python import PythonOperator
from airflow.operators.trigger_dagrun import TriggerDagRunOperator
from airflow.providers.google.cloud.operators.pubsub import (
    PubSubCreateSubscriptionOperator,
    PubSubPullOperator,
)

PROJECT_ID = "<PROJECT_ID>"
TOPIC_ID = "dag-topic-trigger"
SUBSCRIPTION = "trigger_dag_subscription"


def handle_messages(pulled_messages, context):
    dag_ids = list()
    for idx, m in enumerate(pulled_messages):
        data = m.message.data.decode("utf-8")
        print(f"message {idx} data is {data}")
        dag_ids.append(data)
    return dag_ids


# This DAG will run minutely and handle pub/sub messages by triggering target DAG
with DAG(
    "trigger_dag",
    start_date=datetime(2021, 1, 1),
    schedule_interval="* * * * *",
    max_active_runs=1,
    catchup=False,
) as trigger_dag:
    # If subscription exists, we will use it. If not - create new one
    subscribe_task = PubSubCreateSubscriptionOperator(
        task_id="subscribe_task",
        project_id=PROJECT_ID,
        topic=TOPIC_ID,
        subscription=SUBSCRIPTION,
    )

    subscription = subscribe_task.output

    # Proceed maximum 50 messages in callback function handle_messages
    # Here we acknowledge messages automatically. You can use PubSubHook.acknowledge to acknowledge in downstream tasks
    # https://airflow.apache.org/docs/apache-airflow-providers-google/stable/_api/airflow/providers/google/cloud/hooks/pubsub/index.html#airflow.providers.google.cloud.hooks.pubsub.PubSubHook.acknowledge
    pull_messages_operator = PubSubPullOperator(
        task_id="pull_messages_operator",
        project_id=PROJECT_ID,
        ack_messages=True,
        messages_callback=handle_messages,
        subscription=subscription,
        max_messages=50,
    )

    # Here we use Dynamic Task Mapping to trigger DAGs according to messages content
    # https://airflow.apache.org/docs/apache-airflow/2.3.0/concepts/dynamic-task-mapping.html
    trigger_target_dag = TriggerDagRunOperator.partial(task_id="trigger_target").expand(
        trigger_dag_id=XComArg(pull_messages_operator)
    )

    (subscribe_task >> pull_messages_operator >> trigger_target_dag)


def _some_heavy_task():
    print("Do some operation...")
    time.sleep(1)
    print("Done!")


# Simple target DAG
with DAG(
    "target_dag",
    start_date=datetime(2022, 1, 1),
    # Not scheduled, trigger only
    schedule_interval=None,
    catchup=False,
) as target_dag:
    some_heavy_task = PythonOperator(
        task_id="some_heavy_task", python_callable=_some_heavy_task
    )

    (some_heavy_task)

קוד לדוגמה מכיל שני DAG: ‏ trigger_dag ו-target_dag.

‫DAG‏ trigger_dag נרשם לנושא Pub/Sub, שולף הודעות Pub/Sub ומפעיל DAG אחר שצוין במזהה ה-DAG של נתוני ההודעה ב-Pub/Sub. בדוגמה הזו, trigger_dag מפעיל את target_dag DAG, שמוציא הודעות ליומני המשימות.

גרף ה-DAG‏ trigger_dag מכיל את המשימות הבאות:

  • ‫subscribe_task: הרשמה לנושא Pub/Sub.
  • ‫pull_messages_operator: קריאת נתוני הודעה ב-Pub/Sub באמצעות PubSubPullOperator.
  • ‫trigger_target_dag: הפעלה של DAG אחר (בדוגמה הזו, target_dag) בהתאם לנתונים בהודעות שנשלפו מנושא Pub/Sub.

‫target_dag ה-DAG מכיל רק משימה אחת: output_to_logs. המשימה הזו מדפיסה הודעות ביומן המשימות עם השהיה של שנייה אחת.

פריסה של פונקציית Cloud Run שמפרסמת הודעות בנושא Pub/Sub

בקטע הזה פורסים פונקציית Cloud Run שמפרסמת הודעות בנושא Pub/Sub.

יצירה של פונקציית Cloud Run וציון ההגדרה שלה

המסוף

  1. נכנסים לדף Cloud Run functions במסוף Google Cloud .

    כניסה לדף Cloud Run functions

  2. לוחצים על יצירת פונקציה.

  3. בשדה Environment (סביבה), בוחרים באפשרות 1st gen (דור ראשון).

  4. בשדה Function name, מזינים את שם הפונקציה: pubsub-publisher.

  5. בשדה Trigger type (סוג הטריגר), בוחרים באפשרות HTTP.

  6. בקטע אימות, בוחרים באפשרות הפעלת קריאות ללא אימות. האפשרות הזו מאפשרת למשתמשים לא מאומתים להפעיל פונקציית HTTP.

  7. לוחצים על 'שמירה'.

  8. לוחצים על הבא כדי לעבור לשלב קוד.

Terraform

מומלץ להשתמש במסוף בשלב הזה, כי אין דרך פשוטה לנהל את קוד המקור של הפונקציה מ-Terraform. Google Cloud

בדוגמה הזו מוסבר איך להעלות פונקציה של Cloud Run מקובץ ארכיון ZIP מקומי על ידי יצירת קטגוריה של Cloud Storage, אחסון הקובץ בקטגוריה הזו ואז שימוש בקובץ מהקטגוריה כמקור לפונקציה של Cloud Run. אם משתמשים בגישה הזו, Terraform לא מעדכן באופן אוטומטי את קוד המקור של הפונקציה, גם אם יוצרים קובץ ארכיון חדש. כדי להעלות מחדש את קוד הפונקציה, אפשר לשנות את שם הקובץ של הארכיון.

  1. מורידים את הקבצים pubsub_publisher.py ו-requirements.txt.
  2. בקובץ pubsub_publisher.py, מחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט. לדוגמה, example-project.
  3. יוצרים ארכיון ZIP בשם pubsub_function.zip עם הקובץ pbusub_publisner.py והקובץ requirements.txt.
  4. שומרים את קובץ ה-ZIP באחת מהספריות שבהן מאוחסן סקריפט Terraform.
  5. מוסיפים את הגדרות המשאבים הבאות לסקריפט Terraform ומחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט.
resource "google_storage_bucket" "cloud_function_bucket" {
  project        = <PROJECT_ID>
  name           = "<PROJECT_ID>-cloud-function-source-code"
  location       = "US"
  force_destroy  = true
  uniform_bucket_level_access = true
}

resource "google_storage_bucket_object" "cloud_function_source" {
  name   = "pubsub_function.zip"
  bucket = google_storage_bucket.cloud_function_bucket.name
  source = "./pubsub_function.zip"
}

resource "google_cloudfunctions_function" "pubsub_function" {
  project = <PROJECT_ID>
  name    = "pubsub-publisher"
  runtime = "python310"
  region  = "us-central1"

  available_memory_mb   = 128
  source_archive_bucket = google_storage_bucket.cloud_function_bucket.name
  source_archive_object = "pubsub_function.zip"
  timeout               = 60
  entry_point           = "pubsub_publisher"
  trigger_http          = true
}

ציון פרמטרים של קוד פונקציית Cloud Run

המסוף

  1. בשלב Code (קוד), בשדה Runtime (סביבת זמן ריצה), בוחרים את סביבת זמן הריצה של השפה שבה הפונקציה משתמשת. בדוגמה הזו, בוחרים באפשרות Python 3.10.

  2. בשדה Entry point מזינים את הערך pubsub_publisher. זה הקוד שמופעל כשפונקציית Cloud Run פועלת. הערך של הדגל הזה צריך להיות שם של פונקציה או שם מלא של מחלקה שקיימים בקוד המקור.

Terraform

דלג על שלב זה. הפרמטרים של פונקציית Cloud Run כבר מוגדרים במשאב google_cloudfunctions_function.

העלאת הקוד של פונקציית Cloud Run

המסוף

בשדה Source code, בוחרים את האפשרות המתאימה לאספקת קוד המקור של הפונקציה. במדריך הזה, מוסיפים את קוד הפונקציה באמצעות העורך המוטבע של פונקציות Cloud Run. אפשרות נוספת היא להעלות קובץ ZIP או להשתמש ב-Cloud Source Repositories.

  1. מכניסים את הקוד לדוגמה הבא לקובץ main.py.
  2. מחליפים את <PROJECT_ID> במזהה הפרויקט של הפרויקט. לדוגמה, example-project.
from google.cloud import pubsub_v1

project = "<PROJECT_ID>"
topic = "dag-topic-trigger"


def pubsub_publisher(request):
    """Publish message from HTTP request to Pub/Sub topic.
    Args:
        request (flask.Request): HTTP request object.
    Returns:
        The response text with message published into Pub/Sub topic
        Response object using
        `make_response <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>`.
    """
    request_json = request.get_json()
    print(request_json)
    if request.args and "message" in request.args:
        data_str = request.args.get("message")
    elif request_json and "message" in request_json:
        data_str = request_json["message"]
    else:
        return "Message content not found! Use 'message' key to specify"

    publisher = pubsub_v1.PublisherClient()
    # The `topic_path` method creates a fully qualified identifier
    # in the form `projects/{project_id}/topics/{topic_id}`
    topic_path = publisher.topic_path(project, topic)

    # The required data format is a bytestring
    data = data_str.encode("utf-8")
    # When you publish a message, the client returns a future.
    message_length = len(data_str)
    future = publisher.publish(topic_path, data, message_length=str(message_length))
    print(future.result())

    return f"Message {data} with message_length {message_length} published to {topic_path}."

Terraform

דלג על שלב זה. הפרמטרים של פונקציית Cloud Run כבר מוגדרים במשאב google_cloudfunctions_function.

ציון התלות של פונקציית Cloud Run

המסוף

מציינים את יחסי התלות של הפונקציה בקובץ המטא-נתונים requirements.txt:

requests-toolbelt==1.0.0
google-auth==2.38.0
google-cloud-pubsub==2.28.0

כשפורסים את הפונקציה, פונקציות Cloud Run מורידות ומתקינות את יחסי התלות שמוצהרים בקובץ requirements.txt, שורה אחת לכל חבילה. הקובץ הזה צריך להיות באותה ספרייה שבה נמצא הקובץ main.py שמכיל את קוד הפונקציה. פרטים נוספים זמינים במאמר בנושא קובצי דרישות במסמכי התיעוד של pip.

Terraform

דלג על שלב זה. התלות של פונקציית Cloud Run מוגדרת בקובץ requirements.txt בארכיון pubsub_function.zip.

פריסת פונקציית Cloud Run

המסוף

לוחצים על פריסה. בסיום הפריסה, הפונקציה מופיעה עם סימן וי ירוק בדף Cloud Run functions במסוףGoogle Cloud .

מוודאים שלחשבון השירות שמריץ את הפונקציה של Cloud Run יש מספיק הרשאות בפרויקט כדי לגשת ל-Pub/Sub.

Terraform

  1. מאתחלים את Terraform:

    terraform init

  2. בודקים את ההגדרות ומוודאים שהמשאבים שמערכת Terraform תיצור או תעדכן תואמים לציפיות שלכם:

    terraform plan

  3. כדי לבדוק אם ההגדרות תקינות, מריצים את הפקודה הבאה:

    terraform validate

  4. מריצים את הפקודה הבאה ומזינים yes בהודעה שמופיעה, כדי להחיל את הגדרות Terraform:

    terraform apply

ממתינים עד שב-Terraform תוצג ההודעה "Apply complete!‎".

במסוף Google Cloud , נכנסים למשאבים בממשק המשתמש כדי לוודא שהם נוצרו או עודכנו ב-Terraform.

בדיקה של פונקציית Cloud Run

כדי לוודא שהפונקציה מפרסמת הודעה בנושא ב-Pub/Sub ושה-DAG לדוגמה פועל כמצופה:

  1. בודקים שקבוצות ה-DAG פעילות:

    1. נכנסים לדף Environments במסוף Google Cloud .

      מעבר אל Environments

    2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details ייפתח.

    3. עוברים לכרטיסייה DAGs.

    4. בודקים את הערכים בעמודה State (מצב) עבור DAGs בשם trigger_dag ו-target_dag. שני ה-DAG צריכים להיות במצב Active.

  2. שליחה של הודעת בדיקה ב-Pub/Sub. אפשר לעשות את זה ב-Cloud Shell:

    1. נכנסים לדף Functions במסוף Google Cloud .

      כניסה לדף Cloud Run functions

    2. לוחצים על שם הפונקציה, pubsub-publisher.

    3. עוברים לכרטיסייה בדיקה.

    4. בקטע Configure triggering event (הגדרת אירוע הפעלה), מזינים את צמד המפתח-ערך הבא ב-JSON: ‏ {"message": "target_dag"}. אל תשנו את זוג הערכים של המפתח, כי ההודעה הזו תפעיל את ה-DAG של הבדיקה בהמשך.

    5. בקטע Test Command (פקודת בדיקה), לוחצים על Test in Cloud Shell (בדיקה ב-Cloud Shell).

    6. ב-Cloud Shell Terminal, מחכים עד שפקודה מופיעה באופן אוטומטי. מריצים את הפקודה על ידי לחיצה על Enter.

    7. אם מופיעה ההודעה Authorize Cloud Shell, לוחצים על Authorize.

    8. בודקים שהתוכן של ההודעה תואם להודעת Pub/Sub. בדוגמה הזו, הודעת הפלט חייבת להתחיל ב-Message b'target_dag' with message_length 10 published to כתגובה מהפונקציה.

  3. בודקים שהופעלה הפונקציה target_dag:

    1. ממתינים לפחות דקה עד להשלמת הפעלת DAG חדשה של trigger_dag.

    2. נכנסים לדף Environments במסוף Google Cloud .

      מעבר אל Environments

    3. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details ייפתח.

    4. עוברים לכרטיסייה DAGs.

    5. לוחצים על trigger_dag כדי לעבור לדף פרטי DAG. בכרטיסייה Runs (הפעלות) מוצגת רשימה של הפעלות DAG עבור ה-DAG‏ trigger_dag.

      ה-DAG הזה פועל כל דקה ומעבד את כל ההודעות ב-Pub/Sub שנשלחות מהפונקציה. אם לא נשלחו הודעות, המשימה trigger_target מסומנת כ-Skipped ביומני ההרצה של DAG. אם הופעלו DAG, המשימה trigger_target מסומנת כ-Success.

    6. מעיינים בכמה הרצות DAG אחרונות כדי לאתר הרצת DAG שבה כל שלוש המשימות (subscribe_task, pull_messages_operator ו-trigger_target) נמצאות בסטטוסים Success.

    7. חוזרים לכרטיסייה DAGs ובודקים שבעמודה Successful runs של ה-DAG target_dag מופיע ריצה אחת מוצלחת.

סיכום

במדריך הזה למדתם איך להשתמש בפונקציות Cloud Run כדי לפרסם הודעות בנושא Pub/Sub, ואיך לפרוס DAG שנרשם לנושא Pub/Sub, שולף הודעות Pub/Sub ומפעיל DAG אחר שצוין במזהה ה-DAG של נתוני ההודעה.

יש גם דרכים חלופיות ליצירה ולניהול של מינויים ל-Pub/Sub ולהפעלת DAG שלא נכללות במדריך הזה. לדוגמה, אתם יכולים להשתמש בפונקציות Cloud Run כדי להפעיל DAG של Airflow כשמתרחש אירוע ספציפי. כדאי לעיין במדריכים שלנו כדי לנסות את התכונות האחרות שלGoogle Cloud .

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, אתם יכולים למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים הספציפיים.

מחיקת הפרויקט

    כדי למחוק Google Cloud פרויקט:

    gcloud projects delete PROJECT_ID

מחיקת משאבים בודדים

אם אתם מתכננים להיעזר בכמה מדריכי לימוד או מדריכים למתחילים, מומלץ להשתמש שוב באותו פרויקט כדי לא לחרוג ממכסות הפרויקטים.

המסוף

  1. מחיקת סביבת Managed Airflow במהלך התהליך הזה, נמחק גם דלי האחסון של הסביבה.
  2. מחיקת נושא Pub/Sub, dag-topic-trigger.

  3. מחיקת פונקציית Cloud Run.

    1. במסוף Google Cloud , נכנסים לדף Cloud Run functions.

      כניסה לדף Cloud Run functions

    2. לוחצים על תיבת הסימון של הפונקציה שרוצים למחוק, pubsub-publisher.

    3. לוחצים על מחיקה ופועלים לפי ההוראות.

Terraform

  1. מוודאים שסקריפט Terraform לא מכיל רשומות של משאבים שעדיין נדרשים לפרויקט. לדוגמה, יכול להיות שתרצו להשאיר חלק מממשקי ה-API מופעלים ואת הרשאות ה-IAM עדיין מוקצות (אם הוספתם הגדרות כאלה לסקריפט Terraform).
  2. מריצים את terraform destroy.
  3. מוחקים ידנית את הקטגוריה של הסביבה. ‫Managed Airflow לא מוחק אותו באופן אוטומטי. אפשר לעשות את זה דרך מסוף Google Cloud או Google Cloud CLI.

המאמרים הבאים