יצירת סביבות של Managed Service for Apache Airflow

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

בדף הזה מוסבר איך ליצור סביבת Airflow מנוהלת.

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

שלב 1. יצירה או בחירה של חשבון שירות בסביבה

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

חשבון השירות של הסביבה שלכם הוא לא חשבון משתמש. חשבון שירות הוא סוג מיוחד של חשבון, שאפליקציה או מכונה וירטואלית (VM) משתמשות בו, ולא אדם.

אי אפשר לשנות את חשבון השירות של הסביבה בשלב מאוחר יותר.

אם עדיין אין לכם בפרויקט חשבון שירות לסביבות Managed Airflow, אתם צריכים ליצור אותו.

במאמר יצירת סביבות (Terraform) יש דוגמה מורחבת ליצירת חשבון שירות לסביבה ב-Terraform.

כדי ליצור חשבון שירות חדש לסביבה שלכם:

  1. יוצרים חשבון שירות חדש כמו שמתואר במסמכי ניהול הזהויות והרשאות הגישה.

  2. מקצים לו תפקיד, כמו שמתואר במסמכי התיעוד של ניהול הזהויות והרשאות הגישה (IAM). התפקיד הנדרש הוא Composer Worker ‏ (composer.worker).

  3. כדי לגשת למשאבים אחרים בפרויקט Google Cloud , צריך לתת לחשבון השירות הזה הרשאות נוספות לגשת למשאבים האלה. ברוב המקרים, התפקיד Composer Worker ‏ (composer.worker) מספק את קבוצת ההרשאות הנדרשת הזו. מוסיפים הרשאות נוספות לחשבון השירות הזה רק כשצריך כדי להפעיל את ה-DAG.

שלב 2. הגדרה בסיסית

בשלב הזה נוצרת סביבת Managed Airflow עם פרמטרים שמוגדרים כברירת מחדל במיקום שצוין.

המסוף

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

    כניסה לדף Create environment

  2. בשדה Name, מזינים שם לסביבה.

    השם צריך להתחיל באות קטנה, להמשיך בעד 62 אותיות קטנות, מספרים או מקפים, ולא להסתיים במקף. שם הסביבה משמש ליצירת רכיבי משנה של הסביבה, ולכן צריך לספק שם שתקף גם כשם של קטגוריה ב-Cloud Storage. רשימת ההגבלות מופיעה במאמר הנחיות למתן שמות לקטגוריות.

  3. בתפריט הנפתח מיקום, בוחרים מיקום לסביבה.

    מיקום הוא האזור שבו הסביבה נמצאת.

  4. בתפריט הנפתח גרסת תמונה, בוחרים Managed Airflow image עם הגרסה הנדרשת של Airflow.

  5. בתפריט הנפתח Service account, בוחרים חשבון שירות לסביבה שלכם.

    אם עדיין אין לכם חשבון שירות לסביבה, תוכלו לעיין במאמר יצירה או בחירה של חשבון שירות לסביבה.

gcloud 

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

מחליפים את:

  • ‫ENVIRONMENT_NAME בשם הסביבה.

    השם צריך להתחיל באות קטנה, להמשיך בעד 62 אותיות קטנות, מספרים או מקפים, ולא להסתיים במקף. שם הסביבה משמש ליצירת רכיבי משנה של הסביבה, ולכן צריך לספק שם שתקף גם כשם של קטגוריה ב-Cloud Storage. רשימת ההגבלות מופיעה במאמר הנחיות למתן שמות לקטגוריות.

  • ‫LOCATION עם האזור של הסביבה.

    מיקום הוא האזור שבו הסביבה נמצאת.

  • ‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.

  • IMAGE_VERSION בשם של קובץ אימג' של Managed Airflow.

דוגמה:

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

API

יוצרים בקשת API של environments.create. מציינים את ההגדרה במשאב Environment.

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

מחליפים את:

  • ‫PROJECT_ID במזהה הפרויקט (Project ID).

  • ‫LOCATION עם האזור של הסביבה.

    מיקום הוא האזור שבו הסביבה נמצאת.

  • ENVIRONMENT_NAME בשם הסביבה.

    השם צריך להתחיל באות קטנה, להמשיך בעד 62 אותיות קטנות, מספרים או מקפים, ולא להסתיים במקף. שם הסביבה משמש ליצירת רכיבי משנה של הסביבה, ולכן צריך לספק שם שתקף גם כשם של קטגוריה ב-Cloud Storage. רשימת ההגבלות מופיעה במאמר הנחיות למתן שמות לקטגוריות.

  • IMAGE_VERSION בשם של קובץ אימג' של Managed Airflow.

  • ‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.

דוגמה:

// 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.11.1-build.6"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

כדי ליצור סביבה עם פרמטרים שמוגדרים כברירת מחדל במיקום שצוין, מוסיפים את בלוק המשאבים הבא להגדרות Terraform ומריצים את הפקודה terraform apply.

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"
    }
  }
}

מחליפים את:

  • ‫ENVIRONMENT_NAME בשם הסביבה.

    השם צריך להתחיל באות קטנה, להמשיך בעד 62 אותיות קטנות, מספרים או מקפים, ולא להסתיים במקף. שם הסביבה משמש ליצירת רכיבי משנה של הסביבה, ולכן צריך לספק שם שתקף גם כשם של קטגוריה ב-Cloud Storage. רשימת ההגבלות מופיעה במאמר הנחיות למתן שמות לקטגוריות.

  • ‫LOCATION עם האזור של הסביבה.

    מיקום הוא האזור שבו הסביבה נמצאת.

  • IMAGE_VERSION בשם של קובץ אימג' של Managed Airflow.

  • ‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.

דוגמה:

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

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

שלב 3. (אופציונלי) הגדרת פרמטרים של קנה מידה וביצועים של הסביבה

כדי לציין את הגדרות הביצועים וההתאמה של הסביבה, בוחרים את גודל הסביבה ואת הגדרות עומסי העבודה.

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

הפרמטרים הבאים קובעים את קנה המידה והביצועים:

  • גודל הסביבה. הגדרת פרמטרים של ביצועים בתשתית של Managed Airflow, כולל מסד הנתונים של Airflow. כדאי לבחור גודל סביבה גדול יותר אם רוצים להריץ מספר גדול של DAG ומשימות עם ביצועים טובים יותר של התשתית. לדוגמה, ככל שהסביבה גדולה יותר, כך היא יכולה לעבד יותר רשומות ביומן של משימות Airflow עם עיכוב מינימלי.

  • הגדרת עומסי עבודה. שליטה בהיקף ובביצועים של רכיבי Airflow שפועלים באשכול GKE של הסביבה.

    • מתזמן Airflow. מנתח קבצים של הגדרות DAG, מתזמן הפעלות של DAG על סמך מרווח התזמון ומכניס משימות לתור לביצוע על ידי עובדי Airflow.

      בסביבה שלכם יכולים לפעול כמה מתזמני Airflow בו-זמנית. כדי לשפר את הביצועים והאמינות, מומלץ להשתמש בכמה מתזמנים כדי לחלק את העומס בין כמה מופעים של מתזמן.

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

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

      מידע נוסף על הגדרת מספר מתזמנים זמין במאמרי העזרה של Airflow.

    • ‫Airflow triggerer. עוקב באופן אסינכרוני אחרי כל המשימות שנדחו בסביבה שלכם. אם יש לכם לפחות מופע אחד של מפעיל בסביבה שלכם (או לפחות שניים בסביבות עמידות במיוחד), אתם יכולים להשתמש באופרטורים שניתן לדחות ב-DAG שלכם.

      ב-Managed Airflow (דור 3), מפעיל Airflow מופעל כברירת מחדל. אם רוצים ליצור סביבה בלי מפעיל, מגדירים את מספר המפעילים לאפס.

    • מעבד DAG של Airflow. מעבד קובצי DAG והופך אותם לאובייקטים של DAG. ב-Managed Airflow (דור 3), החלק הזה של המתזמן פועל כרכיב סביבה נפרד.

    • שרת האינטרנט של Airflow. מריץ את ממשק האינטרנט של Airflow שבו אפשר לעקוב אחרי ה-DAG, לנהל אותו ולהמחיש אותו.

    • Airflow workers. להריץ משימות שמתוזמנות על ידי Airflow schedulers. מספר העובדים המינימלי והמקסימלי בסביבה משתנה באופן דינמי בהתאם למספר המשימות בתור.

המסוף

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

כדי לבחור את הגדרות הביצועים והקנה מידה של הסביבה, בדף Create environment (יצירת סביבה):

  • כדי להשתמש בערכים מוגדרים מראש, בקטע Environment resources (משאבי סביבה), לוחצים על Small (קטן), Medium (בינוני), Large (גדול) או Extra Large (גדול במיוחד).

  • כדי לציין ערכים מותאמים אישית לפרמטרים של קנה המידה והביצועים:

    1. בקטע משאבי סביבה, לוחצים על התאמה אישית.

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

    3. בקטע Triggerer, משתמשים בשדה Number of triggerers כדי להזין את מספר ה-triggerers בסביבה שלכם.

      אם אתם לא רוצים להשתמש באופרטורים שניתן לדחות ב-DAG, אתם יכולים להגדיר את מספר הטריגרים לאפס.

      אם הגדרתם לפחות טריגר אחד לסביבה, תוכלו להשתמש בשדות CPU וזיכרון כדי להגדיר הקצאת משאבים לטריגרים.

    4. בקטע DAG processor (מעבד DAG), מציינים את מספר מעבדי ה-DAG בסביבה ואת כמות המעבדים, הזיכרון והאחסון לכל מעבד DAG.

      בסביבות עם חוסן גבוה נדרשים לפחות שני מעבדי DAG.

    5. בקטע Web server (שרת אינטרנט), מציינים את מספר המעבדים (CPU), הזיכרון ונפח האחסון של שרת האינטרנט.

    6. בקטע Worker, מציינים:

      • המספר המינימלי והמקסימלי של עובדים להגבלות של התאמה אוטומטית לעומס בסביבה שלכם.
      • הקצאת המעבד (CPU), הזיכרון והאחסון לעובדים

    7. בקטע Core infrastructure, ברשימה הנפתחת Environment size, בוחרים את גודל הסביבה.

gcloud

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

  • ‫--environment-size מציין את גודל הסביבה.
  • ‫--scheduler-count מציין את מספר המתזמנים.
  • ‫--scheduler-cpu מציין את מספר המעבדים לתזמון של Airflow.
  • ‫--scheduler-memory מציין את כמות הזיכרון עבור מתזמן Airflow.

  • --scheduler-storage מציין את כמות שטח הדיסק עבור מתזמן Airflow.

  • ‫--triggerer-count מציין את מספר הטריגרים של Airflow בסביבה שלכם. ערך ברירת המחדל של הדגל הזה הוא 0. צריך להשתמש בטריגרים אם רוצים להשתמש באופרטורים שניתנים לדחייה ב-DAG.

    • בסביבות רגילות של עמידות, משתמשים בערך בין 0 ל-10.
    • בסביבות עם חוסן גבוה, משתמשים בערך 0 או בערך בין 2 ל-10.

  • ‫--triggerer-cpu מציין את מספר המעבדים (CPU) של Airflow triggerer, ביחידות vCPU. הערכים המותרים: 0.5, ‏ 0.75, ‏ 1. ערך ברירת המחדל הוא 0.5.

  • ‫--triggerer-memory מציין את כמות הזיכרון לטריגר של Airflow, ב-GB. ערך ברירת המחדל הוא 0.5.

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

    לדוגמה, אם מגדירים את הדגל --triggerer-cpu לערך 1, הערך המינימלי של --triggerer-memory הוא 1 והערך המקסימלי הוא 6.5.

  • ‫--dag-processor-count מציין את מספר המעבדים של DAG בסביבה שלכם.

    בסביבות עם חוסן גבוה נדרשים לפחות שני מעבדי DAG.

  • ‫--dag-processor-cpu מציין את מספר המעבדים של מעבד ה-DAG.

  • ‫--dag-processor-memory מציין את כמות הזיכרון למעבד DAG.

  • ‫--dag-processor-storage מציין את נפח האחסון במעבד של ה-DAG.

  • ‫--web-server-cpu מציין את מספר המעבדים לשרת האינטרנט של Airflow.

  • ‫--web-server-memory מציין את נפח הזיכרון של שרת האינטרנט של Airflow.

  • ‫--web-server-storage מציין את נפח שטח הדיסק לשרת האינטרנט של Airflow.

  • ‫--worker-cpu מציין את מספר המעבדים של עובד Airflow.

  • ‫--worker-memory מציין את נפח הזיכרון של עובד Airflow.

  • ‫--worker-storage מציין את כמות שטח הדיסק לעובד של Airflow.

  • ‫--min-workers מציין את המספר המינימלי של עובדי Airflow. מספר העובדים שהאשכול בסביבה שלכם מריץ לפחות.

  • ‫--max-workers מציין את המספר המקסימלי של עובדי Airflow. המספר המקסימלי של עובדים באשכול של הסביבה.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --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

מחליפים את:

  • ‫ENVIRONMENT_SIZE עם small, medium, large, extra-large.
  • SCHEDULER_COUNT עם מספר הכלי לתזמון פגישות.
  • ‫SCHEDULER_CPU עם מספר המעבדים למתזמן, ביחידות vCPU.
  • ‫SCHEDULER_MEMORY עם נפח הזיכרון של מתזמן.
  • ‫SCHEDULER_STORAGE עם גודל הדיסק של מתזמן.
  • TRIGGERER_COUNT עם מספר הטריגרים.
  • ‫TRIGGERER_CPU עם מספר המעבדים של הגורם המפעיל, ביחידות vCPU.

  • ‫TRIGGERER_MEMORY עם נפח הזיכרון של הגורם המפעיל, ב-GB.

  • ‫DAG_PROCESSOR_COUNT עם מספר המעבדים של DAG.

  • ‫DAG_PROCESSOR_CPU עם מספר המעבדים של מעבד ה-DAG.

  • ‫DAG_PROCESSOR_MEMORY עם נפח הזיכרון של מעבד ה-DAG.

  • ‫DAG_PROCESSOR_STORAGE עם נפח האחסון בדיסק למעבד DAG.

  • ‫WEB_SERVER_CPU עם מספר המעבדים של שרת האינטרנט, ביחידות vCPU.

  • ‫WEB_SERVER_MEMORY עם נפח הזיכרון של שרת האינטרנט.

  • ‫WEB_SERVER_STORAGE עם נפח הזיכרון של שרת האינטרנט.

  • ‫WORKER_CPU עם מספר המעבדים של העובד, ביחידות vCPU.

  • ‫WORKER_MEMORY עם נפח הזיכרון של העובד.

  • ‫WORKER_STORAGE מחליפים בגודל הדיסק של העובד.

  • ‫WORKERS_MIN עם המספר המינימלי של עובדי Airflow שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של עובדים יכול להתמודד עם העומס.

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

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --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

כשיוצרים סביבה, במשאב Environment (סביבה) > EnvironmentConfig (הגדרת סביבה) > WorkloadsConfig (הגדרת עומסי עבודה), מציינים את הפרמטרים של קנה המידה והביצועים של הסביבה.

{
  "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"
    }
  }
}

מחליפים את:

  • ‫SCHEDULER_CPU עם מספר המעבדים למתזמן, ביחידות vCPU.
  • ‫SCHEDULER_MEMORY עם נפח הזיכרון של מתזמן, ב-GB.
  • ‫SCHEDULER_STORAGE עם גודל הדיסק של מתזמן, ב-GB.

  • SCHEDULER_COUNT עם מספר הכלי לתזמון פגישות.

  • TRIGGERER_COUNT עם מספר הטריגרים. ערך ברירת המחדל הוא 0. צריך להשתמש בטריגרים אם רוצים להשתמש באופרטורים שניתנים לדחייה ב-DAG.

    • בסביבות רגילות של עמידות, משתמשים בערך בין 0 ל-10.
    • בסביבות עם חוסן גבוה, משתמשים בערך 0 או בערך בין 2 ל-10.

    אם משתמשים לפחות בטריגר אחד, צריך לציין גם את הפרמטרים TRIGGERER_CPU ו-TRIGGERER_MEMORY:

  • ‫TRIGGERER_CPU מציין את מספר המעבדים של מפעיל, ביחידות של מעבד וירטואלי. הערכים המותרים: 0.5, ‏ 0.75, ‏ 1.

  • ‫TRIGGERER_MEMORY מגדיר את נפח הזיכרון של מפעיל. הזיכרון המינימלי שנדרש שווה למספר המעבדים שהוקצו לטריגרים. הערך המקסימלי המותר שווה למספר המעבדים של הגורם המפעיל כפול 6.5.

    לדוגמה, אם מגדירים את TRIGGERER_CPU ל-1, הערך המינימלי של TRIGGERER_MEMORY הוא 1 והערך המקסימלי הוא 6.5.

  • ‫DAG_PROCESSOR_COUNT עם מספר המעבדים של DAG.

    בסביבות עם חוסן גבוה נדרשים לפחות שני מעבדי DAG.

  • ‫DAG_PROCESSOR_CPU עם מספר המעבדים של מעבד ה-DAG, ביחידות vCPU.

  • ‫DAG_PROCESSOR_MEMORY עם נפח הזיכרון של מעבד ה-DAG, ב-GB.

  • ‫DAG_PROCESSOR_STORAGE עם נפח האחסון של מעבד ה-DAG, ב-GB.

  • ‫WEB_SERVER_CPU עם מספר המעבדים של שרת האינטרנט, ביחידות vCPU.

  • ‫WEB_SERVER_MEMORY עם נפח הזיכרון של שרת האינטרנט, ב-GB.

  • ‫WEB_SERVER_STORAGE עם גודל הדיסק של שרת האינטרנט, ב-GB.

  • ‫WORKER_CPU עם מספר המעבדים של העובד, ביחידות vCPU.

  • ‫WORKER_MEMORY עם נפח הזיכרון של העובד, ב-GB.

  • ‫WORKER_STORAGE עם גודל הדיסק של העובד, ב-GB.

  • ‫WORKERS_MIN עם המספר המינימלי של עובדי Airflow שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של עובדים יכול להתמודד עם העומס.

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

  • ‫ENVIRONMENT_SIZE עם גודל הסביבה: ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM, ENVIRONMENT_SIZE_LARGE, ENVIRONMENT_SIZE_EXTRA_LARGE.

דוגמה:

// 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

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

  • בבלוק config:

    • השדה environment_size קובע את גודל הסביבה.

  • בבלוק workloads_config:

    • בשדה scheduler.cpu מציינים את מספר המעבדים לתזמון של Airflow.
    • בשדה scheduler.memory_gb מצוין נפח הזיכרון של מתזמן Airflow.
    • בשדה scheduler.storage_gb מציינים את כמות שטח הדיסק עבור מתזמן.
    • בשדה scheduler.count מצוין מספר המתזמנים בסביבה שלכם.
    • בשדה triggerer.cpu מציינים את מספר המעבדים של Airflow Triggerer.
    • בשדה triggerer.memory_gb מציינים את נפח הזיכרון של Airflow triggerer.

    • בשדה triggerer.count מצוין מספר הטריגרים בסביבה שלכם.

    • בשדה dag_processor.cpu מצוין מספר המעבדים של מעבד DAG.

    • בשדה dag_processor.memory_gb מציינים את כמות הזיכרון למעבד DAG.

    • בשדה dag_processor.storage_gb מצוין נפח האחסון בדיסק למעבד DAG.

    • בשדה dag_processor.count מצוין מספר המעבדים של DAG.

      בסביבות עם חוסן גבוה נדרשים לפחות שני מעבדי DAG.

    • בשדה web_server.cpu מציינים את מספר המעבדים של שרת האינטרנט של Airflow.

    • בשדה web_server.memory_gb מצוין נפח הזיכרון של שרת האינטרנט של Airflow.

    • בשדה web_server.storage_gb מציינים את נפח הדיסק שמוקצה לשרת האינטרנט של Airflow.

    • בשדה worker.cpu מציינים את מספר המעבדים (CPU) של עובד Airflow.

    • בשדה worker.memory_gb מציינים את נפח הזיכרון של עובד Airflow.

    • בשדה worker.storage_gb מצוין נפח שטח הדיסק של Airflow worker.

    • השדה worker.min_count מציין את המספר המינימלי של העובדים בסביבה שלכם.

    • השדה worker.max_count מציין את המספר המקסימלי של עובדים בסביבה שלכם.

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"
    }
  }
}

מחליפים את:

  • ‫ENVIRONMENT_NAME בשם הסביבה.
  • ‫LOCATION עם האזור שבו הסביבה ממוקמת.
  • ‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.
  • ‫SCHEDULER_CPU עם מספר המעבדים למתזמן, ביחידות vCPU.
  • ‫SCHEDULER_MEMORY עם נפח הזיכרון של מתזמן, ב-GB.
  • ‫SCHEDULER_STORAGE עם גודל הדיסק של מתזמן, ב-GB.
  • SCHEDULER_COUNT עם מספר הכלי לתזמון פגישות.
  • TRIGGERER_COUNT עם מספר הטריגרים.
  • ‫TRIGGERER_CPU עם מספר המעבדים של הגורם המפעיל, ביחידות vCPU.

  • ‫TRIGGERER_MEMORY עם נפח הזיכרון של הגורם המפעיל, ב-GB.

  • ‫DAG_PROCESSOR_CPU עם מספר המעבדים של מעבד ה-DAG, ביחידות vCPU.

  • ‫DAG_PROCESSOR_MEMORY עם נפח הזיכרון של מעבד ה-DAG, ב-GB.

  • ‫DAG_PROCESSOR_STORAGE עם נפח האחסון של מעבד ה-DAG, ב-GB.

  • ‫DAG_PROCESSOR_COUNT עם מספר המעבדים של DAG.

  • ‫WEB_SERVER_CPU עם מספר המעבדים של שרת האינטרנט, ביחידות vCPU.

  • ‫WEB_SERVER_MEMORY עם נפח הזיכרון של שרת האינטרנט, ב-GB.

  • ‫WEB_SERVER_STORAGE עם גודל הדיסק של שרת האינטרנט, ב-GB.

  • ‫WORKER_CPU עם מספר המעבדים של העובד, ביחידות vCPU.

  • ‫WORKER_MEMORY עם נפח הזיכרון של העובד, ב-GB.

  • ‫WORKER_STORAGE עם גודל הדיסק של העובד, ב-GB.

  • ‫WORKERS_MIN עם המספר המינימלי של עובדי Airflow שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של עובדים יכול להתמודד עם העומס.

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

  • ‫ENVIRONMENT_SIZE עם גודל הסביבה: ENVIRONMENT_SIZE_SMALL, ENVIRONMENT_SIZE_MEDIUM, ENVIRONMENT_SIZE_LARGE, ENVIRONMENT_SIZE_EXTRA_LARGE.

דוגמה:

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
"
    }

  }
}

שלב 4. (אופציונלי) הפעלת מצב חוסן גבוה

חוסן גבוה (זמינות גבוהה) סביבות Managed Airflow הן סביבות שמשתמשות במנגנוני יתירות ויתירות כשל מובנים, שמפחיתים את הרגישות של הסביבה לכשלים אזוריים ולהפסקות שנגרמות מנקודת כשל בודדת.

ב-Managed Airflow (דור 3), סביבות עמידות במיוחד זמינות החל מגרסאות Airflow‏ composer-3-airflow-2.10.2-build.13 ו-composer-3-airflow-2.9.3-build.20.

סביבה עמידה במיוחד היא סביבה רב-אזורית שפועלת לפחות בשני אזורים מתוך אזור שנבחר. הרכיבים הבאים פועלים באזורים נפרדים:

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

המסוף

בדף Create environment:

  1. בקטע Resilience mode (מצב חוסן), בוחרים באפשרות High resilience (חוסן גבוה).

  2. בקטע Environment resources, בוחרים פרמטרים של שינוי גודל לסביבה עם חוסן גבוה. בסביבות עם חוסן גבוה נדרשים בדיוק שני מתזמנים, אפס או בין שניים לעשרה מפעילים ולפחות שני עובדים:

    1. לוחצים על התאמה אישית.

    2. ברשימה הנפתחת Number of schedulers (מספר המתזמנים), בוחרים באפשרות 2.

    3. בתפריט הנפתח מספר המפעילים, בוחרים באפשרות 0 או בערך בין 2 ל-10. מגדירים את הקצאת המעבד והזיכרון לטריגרים.

    4. בתפריט הנפתח מספר העובדים המינימלי, בוחרים באפשרות 2 או יותר, בהתאם למספר העובדים הנדרש.

  3. בקטע Network configuration (הגדרת הרשת):

    1. בקטע Networking type, בוחרים באפשרות Private IP environment.

    2. אם צריך, מציינים פרמטרים אחרים של רשת.

gcloud

כשיוצרים סביבה, הארגומנט --enable-high-resilience מאפשר את מצב החוסן הגבוה.

מגדירים את הארגומנטים הבאים:

  • --enable-high-resilience
  • ‫--enable-private-environment, ופרמטרים אחרים של רשת לסביבת IP פרטית, אם נדרש
  • --scheduler-count עד 2

  • ‫--triggerer-count עד 0 או ערך בין 2 ל-10. אם משתמשים בטריגרים, צריך להשתמש גם בדגלים --triggerer-cpu and‎--triggerer-memory` כדי ליצור את הסביבה.

    מידע נוסף על הדגלים --triggerer-count, --triggerer-cpu ו---triggerer-memory זמין במאמר הגדרת פרמטרים של ביצועים וקנה מידה של הסביבה.

  • ‫--min-workers עד 2 או יותר

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --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

כשיוצרים סביבה, במשאב Environment > EnvironmentConfig, מפעילים את מצב העמידות הגבוהה.

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

  }
}

דוגמה:


// 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

כשיוצרים סביבה, השדה resilience_mode בבלוק config מאפשר להפעיל את מצב החוסן הגבוה.

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

  config {

    resilience_mode = "HIGH_RESILIENCE"

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

דוגמה:

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
"
    }
  }
}

שלב 5. (אופציונלי) מציינים אזור למסד הנתונים של הסביבה

כשיוצרים סביבת חוסן רגילה, אפשר לציין אזור מועדף ב-Cloud SQL.

המסוף

בדף Create environment:

  1. בקטע Advanced configuration (הגדרה מתקדמת), מרחיבים את הפריט Show advanced configuration (הצגת הגדרה מתקדמת).

  2. ברשימה Airflow database zone, בוחרים את אזור Cloud SQL המועדף.

gcloud

כשיוצרים סביבה, הארגומנט --cloud-sql-preferred-zone מציין אזור מועדף של Cloud SQL.

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

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SQL_ZONE: אזור מועדף ב-Cloud SQL. האזור הזה צריך להיות ממוקם באזור שבו נמצאת הסביבה.

דוגמה:

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

API

DatabaseConfig של Environment >, מציינים את האזור המועדף של Cloud SQL.

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

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SQL_ZONE: אזור מועדף ב-Cloud SQL. האזור הזה צריך להיות ממוקם באזור שבו נמצאת הסביבה.

דוגמה:


// 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

כשיוצרים סביבה, השדה zone בבלוק database_config מציין את האזור המועדף ב-Cloud SQL.

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"
    }
  }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SQL_ZONE: אזור מועדף ב-Cloud SQL. האזור הזה צריך להיות ממוקם באזור שבו נמצאת הסביבה.

שלב 6. (אופציונלי) הגדרת הרשת של הסביבה

אפשר להגדיר את הרשת של Managed Airflow (דור 3) בדרכים הבאות:

המסוף

  1. מוודאים שהגדרת הרשת מתאימה לסוג הסביבה שרוצים ליצור.

  2. בקטע Network configuration, מרחיבים את הפריט Show network configuration.

  3. אם רוצים לחבר את הסביבה לרשת VPC, בשדה Network attachment (חיבור לרשת), בוחרים חיבור לרשת. אפשר גם ליצור קובץ מצורף חדש לרשת. מידע נוסף זמין במאמר חיבור סביבה לרשת VPC.

  4. אם רוצים ליצור סביבת IP פרטי, בקטע Networking type (סוג הרשת), בוחרים באפשרות Private IP environment (סביבת IP פרטי).

  5. אם רוצים להוסיף תגי רשת, אפשר לקרוא מידע נוסף במאמר בנושא הוספת תגי רשת.

gcloud

מוודאים שהגדרת הרשת מתאימה לסוג הסביבה שרוצים ליצור.

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

  • ‫--enable-private-environment מאפשרת סביבת IP פרטית.

  • ‫--network מציין את מזהה רשת ה-VPC.

  • ‫--subnetwork מציין את מזהה רשת המשנה של ה-VPC.

דוגמה (סביבת IP פרטית עם רשת VPC מקושרת)

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

מחליפים את:

  • ‫NETWORK_ID במזהה רשת ה-VPC.

  • ‫SUBNETWORK_ID עם מזהה רשת המשנה של ה-VPC.

שלב 7. (אופציונלי) הוספת תגים של רשתות

תגים של רשת מוחלים על כל מכונות ה-VM של הצמתים באשכול של הסביבה. התגים משמשים לזיהוי מקורות או יעדים תקפים עבור חומות אש ברשת. כל תג ברשימה צריך להיות תואם ל-RFC 1035.

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

המסוף

בדף Create environment:

  1. מאתרים את הקטע Network configuration (הגדרת רשת).
  2. בשדה Network tags (תגי רשת), מזינים את תגי הרשת של הסביבה.

gcloud

כשיוצרים סביבה, הארגומנטים הבאים שולטים בתגי הרשת:

  • ‫--tags מציין רשימה מופרדת בפסיקים של תגי רשת שמוחלים על כל מכונות ה-VM של הצמתים.
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --service-account "SERVICE_ACCOUNT" \
    --tags TAGS

מחליפים את:

  • ‫TAGS עם רשימה מופרדת בפסיקים של תגי רשת.

דוגמה:

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

API

כשיוצרים סביבה, במשאב Environment > EnvironmentConfig, מציינים תגי רשת לסביבה.

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

מחליפים את:

  • ‫TAG עם תג רשת.

דוגמה:

// 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

כשיוצרים סביבה, השדות הבאים מגדירים את תגי הרשת של הסביבה:

  • השדה tags בבלוק node_config מציין רשימה של תגי רשת שמופרדים בפסיקים ומוחלים על כל המכונות הווירטואליות של הצמתים.
resource "google_composer_environment" "example" {
  provider = google-beta
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

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

מחליפים את:

  • ‫TAGS עם רשימה מופרדת בפסיקים של תגי רשת.

דוגמה:

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
"
    }
  }
}

שלב 8. (אופציונלי) הגדרת גישה לרשת של שרת אינטרנט

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

אי אפשר להגדיר את טווחי כתובות ה-IP המותרים באמצעות כתובות IP פרטיות.

המסוף

בדף Create environment:

  1. בקטע Network configuration, מרחיבים את הפריט Show network configuration.

  2. בקטע Web server network access control (בקרת גישה לרשת של שרת אינטרנט):

    • כדי לספק גישה לשרת האינטרנט של Airflow מכל כתובות ה-IP, בוחרים באפשרות Allow access from all IP addresses.

    • כדי להגביל את הגישה רק לטווחים ספציפיים של כתובות IP, בוחרים באפשרות Allow access only from specific IP addresses. בשדה טווח כתובות IP, מציינים טווח כתובות IP בסימון CIDR. בשדה Description, מציינים תיאור אופציונלי לטווח הזה. אם רוצים לציין יותר מטווח אחד, לוחצים על הוספת טווח כתובות IP.

    • כדי לחסום את הגישה לכל כתובות ה-IP, בוחרים באפשרות Allow access only from specific IP addresses ולוחצים על Delete item לצד הרשומה הריקה של טווח כתובות ה-IP.

gcloud

כשיוצרים סביבה, הארגומנטים הבאים שולטים ברמת הגישה לשרת האינטרנט:

  • --web-server-allow-all מאפשר גישה ל-Airflow מכל כתובות ה-IP. זו האפשרות שמוגדרת כברירת המחדל.

  • ‫--web-server-allow-ip מגביל את הגישה רק לטווחים ספציפיים של כתובות IP של מקורות. כדי לציין כמה טווחים של כתובות IP, משתמשים בארגומנט הזה כמה פעמים.

  • --web-server-deny-all אוסר גישה לכל כתובות ה-IP.

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

מחליפים את:

  • ‫WS_IP_RANGE עם טווח כתובות ה-IP בסימון CIDR שיכולות לגשת לממשק המשתמש של Airflow.
  • WS_RANGE_DESCRIPTION עם תיאור של טווח כתובות ה-IP.

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --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

כשיוצרים סביבה, במשאב Environment > EnvironmentConfig, מציינים את פרמטרי הגישה לשרת האינטרנט.

  • כדי לספק גישה לשרת האינטרנט של Airflow מכל כתובות ה-IP, משמיטים את webServerNetworkAccessControl.

  • כדי להגביל את הגישה רק לטווחים ספציפיים של כתובות IP, מציינים טווח אחד או יותר ב-allowedIpRanges.

  • כדי לאסור גישה לכל כתובות ה-IP, מוסיפים allowedIpRanges ויוצרים רשימה ריקה. אל תציינו בו טווחי כתובות IP.

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

מחליפים את:

  • ‫WS_IP_RANGE עם טווח כתובות ה-IP בסימון CIDR שיכולות לגשת לממשק המשתמש של Airflow.
  • WS_RANGE_DESCRIPTION עם תיאור של טווח כתובות ה-IP.

דוגמה:


// 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

כשיוצרים סביבה, הבלוק allowed_ip_range בבלוק web_server_network_access_control מכיל טווחי כתובות IP שיכולים לגשת לשרת האינטרנט.

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"
    }
  }
}

מחליפים את:

  • ‫WS_IP_RANGE עם טווח כתובות ה-IP בסימון CIDR שיכולות לגשת לממשק המשתמש של Airflow.
  • WS_RANGE_DESCRIPTION עם תיאור של טווח כתובות ה-IP.

דוגמה:

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
"
    }

}

שלב 9. (אופציונלי) מציינים משתני סביבה ושינויים בהגדרות של Airflow

כשיוצרים סביבה, אפשר להגדיר שינויים בהגדרות של Airflow ומשתני סביבה. לחלופין, אפשר לעשות את זה מאוחר יותר, אחרי שיוצרים את הסביבה.

חלק מאפשרויות ההגדרה של Airflow חסומות ואי אפשר לבטל את החסימה שלהן.

רשימת אפשרויות ההגדרה הזמינות של Airflow מופיעה במאמר Configuration reference for Airflow 2 (הפניה להגדרות של Airflow 2) ובמאמר Airflow 1.10.* (הפניה להגדרות של Airflow 1.10.*).

כדי לציין שינויים בהגדרות של Airflow ומשתני סביבה:

המסוף

בדף Create environment:

  1. בקטע משתני סביבה, לוחצים על הוספת משתנה סביבה.

  2. מזינים את השם והערך של משתנה הסביבה.

  3. בקטע Airflow configuration overrides, לוחצים על Add Airflow configuration override.

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

    לדוגמה:

    קטע מפתח ערך
    webserver dag_orientation TB

gcloud

כשיוצרים סביבה, הארגומנטים הבאים שולטים במשתני הסביבה ובשינויים בהגדרות של Airflow:

  • ‫--env-variables מציין רשימה של משתני סביבה שמופרדים בפסיקים.

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

  • ‫--airflow-configs מציין רשימה מופרדת בפסיקים של מפתחות וערכים לביטול הגדרות של Airflow.

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

מחליפים את:

  • ‫ENV_VARS עם רשימה של זוגות NAME=VALUE מופרדים בפסיקים של משתני סביבה.
  • ‫CONFIG_OVERRIDES עם רשימה של זוגות SECTION-KEY=VALUE מופרדים בפסיקים לביטול הגדרות. מפרידים את השם של קטע ההגדרה באמצעות הסמל - ואחריו שם המפתח. לדוגמה: core-dags_are_paused_at_creation.

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --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

כשיוצרים סביבה, במשאב Environment > EnvironmentConfig, מציינים משתני סביבה ושינויים בהגדרות של Airflow.

{
  "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"
    }
  }
}

מחליפים את:

  • ‫SECTION עם הקטע בקובץ התצורה שבו נמצאת אפשרות התצורה של Airflow.
  • ‫KEY בשם של אפשרות ההגדרה של Airflow.
  • ‫OVERRIDE_VALUE עם ערך של אפשרות ההגדרה של Airflow.
  • ‫VAR_NAME בשם של משתנה הסביבה.
  • VAR_VALUE בערך של משתנה הסביבה.

דוגמה:

// 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

כשיוצרים סביבה, הבלוקים הבאים שולטים במשתני הסביבה ובשינויים בהגדרות של Airflow:

  • ‫env_variables block in the software_config block specifies environment variables.

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

  • הבלוק airflow_config_overrides בבלוק software_config מציין שינויים בהגדרות של Airflow.

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"
    }

  }
}

מחליפים את:

  • ‫SECTION עם הקטע בקובץ התצורה שבו נמצאת אפשרות התצורה של Airflow.
  • ‫KEY בשם של אפשרות ההגדרה של Airflow.
  • ‫OVERRIDE_VALUE עם ערך של אפשרות ההגדרה של Airflow.
  • ‫VAR_NAME בשם של משתנה הסביבה.
  • VAR_VALUE בערך של משתנה הסביבה.

דוגמה:

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
"
    }
  }
}

שלב 10. (אופציונלי) מציינים חלונות זמן לתחזוקה

חלונות התחזוקה שמוגדרים כברירת מחדל ב-Managed Airflow (דור 3) מוגדרים באופן הבא:

  • כל השעות הן באזור הזמן המקומי של האזור שבו נמצאת הסביבה שלכם, אבל בלי להתחשב בשעון הקיץ.
  • בימים שלישי, רביעי, חמישי ושישי, חלונות הזמן לתחזוקה הם מ-00:00:00 עד 02:00:00.
  • בשבת, בראשון ובשני, חלונות הזמן לתחזוקה הם מ-00:00:00 עד 04:00:00.

כדי לציין חלונות זמן מותאמים אישית לתחזוקה בסביבה שלכם:

המסוף

בדף יצירת סביבה

  1. מחפשים את הקטע חלונות זמן לתחזוקה.

  2. בתפריט הנפתח Timezone, בוחרים את אזור הזמן של חלונות התחזוקה.

  3. מגדירים את שעת ההתחלה, הימים והמשך כך ש:

    • לפחות 12 שעות מוקצות בשבוע אחד.

    • אפשר להשתמש בכמה חלונות זמן, אבל משך כל חלון זמן צריך להיות לפחות 4 שעות.

    לדוגמה, תקופה של 4 שעות בכל יום שני, רביעי ושישי מספקת את משך הזמן הנדרש.

gcloud

הארגומנטים הבאים מגדירים את הפרמטרים של חלונות התחזוקה:

  • ‫--maintenance-window-start מגדיר את שעת ההתחלה של חלון תחזוקה.
  • ‫--maintenance-window-end מגדיר את שעת הסיום של חלון זמן לתחזוקה.
  • ‫--maintenance-window-recurrence מגדיר את החזרה של חלון זמן לתחזוקה.
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.11.1-build.6 \
    --service-account "SERVICE_ACCOUNT" \
    --maintenance-window-start 'DATETIME_START' \
    --maintenance-window-end 'DATETIME_END' \
    --maintenance-window-recurrence 'MAINTENANCE_RECURRENCE'

מחליפים את:

  • ‫ENVIRONMENT_NAME בשם הסביבה.
  • ‫DATETIME_START עם תאריך ושעת ההתחלה בפורמט הקלט של תאריך ושעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין.
  • ‫DATETIME_END עם תאריך ושעת הסיום בפורמט הקלט של התאריך והשעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין. התאריך והשעה שצוינו חייבים להיות אחרי תאריך ההתחלה.

  • ‫MAINTENANCE_RECURRENCE עם RFC 5545 RRULE לחזרה על חלונות תחזוקה. ‫Managed Airflow תומך בשני פורמטים:

  • הפורמט FREQ=DAILY מציין חזרה יומית.

  • הפורמט FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA מציין חזרה על הפעולה בימים נבחרים בשבוע.

בדוגמה הבאה מוגדר חלון זמן לתחזוקה של 6 שעות בין 01:00 ל-07:00 (UTC) בימי רביעי, שבת וראשון. המערכת מתעלמת מהתאריך 1 בינואר 2023.

gcloud composer environments create example-environment \
  --location us-central1 \
  --image-version composer-3-airflow-2.11.1-build.6 \
  --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

כשיוצרים סביבה, במשאב Environment > EnvironmentConfig, מציינים את הפרמטרים של חלונות התחזוקה:

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

מחליפים את:

  • ‫DATETIME_START עם תאריך ושעת ההתחלה בפורמט הקלט של תאריך ושעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין.
  • ‫DATETIME_END עם תאריך ושעת הסיום בפורמט הקלט של התאריך והשעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין. התאריך והשעה שצוינו צריכים להיות אחרי תאריך ההתחלה.

  • ‫MAINTENANCE_RECURRENCE עם RRULE של RFC 5545 לחלונות תחזוקה חוזרים. ‫Managed Airflow תומך בשני פורמטים:

  • הפורמט FREQ=DAILY מציין חזרה יומית.

  • הפורמט FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA מציין חזרה על הפעולה בימים נבחרים בשבוע.

בדוגמה הבאה מוגדר חלון זמן לתחזוקה של 6 שעות בין 01:00 ל-07:00 (UTC) בימי רביעי, שבת וראשון. המערכת מתעלמת מהתאריך 1 בינואר 2023.

דוגמה:

// 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

הבלוק maintenance_window מציין את חלונות הזמן לתחזוקה של הסביבה:

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"
    }
  }
}

מחליפים את:

  • ‫DATETIME_START עם תאריך ושעת ההתחלה בפורמט הקלט של תאריך ושעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין.
  • ‫DATETIME_END עם תאריך ושעת הסיום בפורמט הקלט של התאריך והשעה. המערכת משתמשת רק בשעה שצוינה ביום, ומתעלמת מהתאריך שצוין. התאריך והשעה שצוינו צריכים להיות אחרי תאריך ההתחלה.

  • ‫MAINTENANCE_RECURRENCE עם RRULE של RFC 5545 לחלונות תחזוקה חוזרים. ‫Managed Airflow תומך בשני פורמטים:

    • הפורמט FREQ=DAILY מציין חזרה יומית.
    • הפורמט FREQ=WEEKLY;BYDAY=SU,MO,TU,WE,TH,FR,SA מציין חזרה על הפעולה בימים נבחרים בשבוע.

בדוגמה הבאה מוגדר חלון זמן לתחזוקה של 6 שעות בין 01:00 ל-07:00 (UTC) בימי רביעי, שבת וראשון. המערכת מתעלמת מהתאריך 1 בינואר 2023.

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"
    }
  }
}

שלב 11. (אופציונלי) שילוב של שושלת נתונים

Data Lineage היא תכונה ב-Knowledge Catalog שמאפשרת לעקוב אחרי תנועת הנתונים.

שילוב של מעקב אחר מקורות נתונים זמין בכל הגרסאות של Managed Airflow (דור 3).

שילוב של מעקב אחר מקורות נתונים מופעל באופן אוטומטי בסביבת Managed Airflow חדשה אם מתקיימים התנאים הבאים:

  • ‫Data Lineage API מופעל בפרויקט. מידע נוסף זמין במאמר בנושא הפעלת Data Lineage API במסמכי התיעוד של Knowledge Catalog.

  • לא מוגדר Lineage Backend מותאם אישית ב-Airflow.

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

המסוף

כדי להשבית את השילוב של מעקב אחר מקורות נתונים, בדף Create environment, מבצעים את הפעולות הבאות:

  1. בקטע Advanced configuration (הגדרה מתקדמת), מרחיבים את האפשרות Show advanced configuration (הצגת הגדרה מתקדמת).

  2. בתפריט Knowledge Catalog Lineage integration, בוחרים באפשרות Disable integration with Knowledge Catalog Lineage.

gcloud

כשיוצרים סביבה, הארגומנט --disable-cloud-data-lineage-integration משבית את השילוב של מעקב אחר מקורות הנתונים.

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

מחליפים את:

  • ‫ENVIRONMENT_NAME בשם הסביבה.
  • ‫LOCATION עם האזור שבו הסביבה ממוקמת.

דוגמה:

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

שלב 12. (אופציונלי) הגדרת הצפנת נתונים (CMEK)

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

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

שלב 13. (אופציונלי) שימוש בקטגוריה של סביבה מותאמת אישית

כשיוצרים סביבה, מערכת Managed Airflow יוצרת באופן אוטומטי bucket בשביל הסביבה.

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

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

שלב 14. (אופציונלי) הגדרת שמירת נתונים במסד הנתונים

אם מפעילים שמירת נתונים במסד הנתונים בסביבה, מערכת Managed Airflow מסירה באופן תקופתי ממסד הנתונים של Airflow רשומות שקשורות להרצות של DAG ולסשנים של משתמשים שהן ישנות יותר מתקופת הזמן שצוינה. המידע על ההרצה האחרונה של DAG תמיד נשמר.

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

שלב 15. (אופציונלי) ציון תוויות לסביבה

אתם יכולים להקצות תוויות לסביבות כדי לפרק את עלויות החיוב לפי התוויות האלה.

המסוף

בדף Create environment, בקטע Labels:

  1. לוחצים על הוספת תווית.

  2. בשדות Key ו-Value מציינים זוגות של מפתח וערך לתוויות הסביבה.

gcloud

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

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

מחליפים את:

  • ‫LABELS עם רשימה של צמדי KEY=VALUE מופרדים בפסיקים של תוויות סביבה.

דוגמה:

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

API

כשיוצרים סביבה, צריך לציין תוויות לסביבה במשאב Environment.

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

מחליפים את:

  • ‫LABEL_KEY עם מפתח של תווית הסביבה.
  • ‫LABEL_VALUE עם ערך של תווית הסביבה.

דוגמה:


// 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

כשיוצרים סביבה, מציינים תוויות בבלוק labels (מחוץ לבלוק config).

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

  labels = {
    LABEL_KEY = "LABEL_VALUE"
  }

}

מחליפים את:

  • ‫LABEL_KEY עם מפתח של תווית הסביבה.
  • ‫LABEL_VALUE עם ערך של תווית הסביבה.

דוגמה:

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

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

}

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