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

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

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

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

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

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

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

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

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

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

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

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

  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. ברשימה הנפתחת Location, בוחרים מיקום לסביבה.

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

  4. ברשימה הנפתחת Image version, בוחרים תמונת Managed Airflow עם הגרסה הנדרשת של 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.20 \
    --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 במזהה הפרויקט.

  • ‫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.20"
    },
    "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.20"
    }
    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

שלב 3. (אופציונלי) הפעלת מצב פיתוח

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

בסביבות של מצב פיתוח יש את המגבלות הבאות:

המסוף

בדף Create environment:

  1. ב-Image version, בוחרים גרסה עם Airflow 3.
  2. בוחרים באפשרות מצב פיתוח.

gcloud

כשיוצרים סביבה, הארגומנט --enable-development-mode מפעיל את מצב הפיתוח:

gcloud beta composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-3 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-development-mode

API

כשיוצרים סביבה, במשאב Environment מגדירים את השדה mode לערך DEVELOPMENT:

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "mode": "DEVELOPMENT"
}

דוגמה:


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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
    "mode": "DEVELOPMENT"
}

Terraform

התכונה הזו עדיין לא נתמכת ב-Terraform.

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

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

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

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

הפרמטרים הבאים שולטים בהיקף ובביצועים:

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

    1. בקטע Environment resources, לוחצים על Custom.

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

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

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

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

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

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

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

    6. בקטע Worker, מציינים את הפרטים הבאים:

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

    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 מציין את מספר המעבדים של טריגר Airflow, ביחידות 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 מציין את מספר המעבדים (CPU) של עובד Airflow.

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

  • ‫--worker-storage מציין את כמות מקום בכונן עבור Airflow worker.

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

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-3-airflow-2.11.1-build.20 \
    --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 עם מספר המעבדים של worker, ביחידות vCPU.

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

  • ‫WORKER_STORAGE בגודל הדיסק של ה-worker.

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

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

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-3-airflow-2.11.1-build.20 \
    --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 מציין את מספר המעבדים (CPU) של הטריגר, ביחידות vCPU. ערכים מותרים: 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 עם גודל הדיסק של שרת האינטרנט, בגיגה-בייט.

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

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

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

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

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

  • ‫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.memory_gb מצוין נפח הזיכרון של טריגר Airflow.

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

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

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

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

    • השדה dag_processor.count מציין את מספר מעבדי ה-DAG.

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

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

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

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

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

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

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

    • בשדה worker.min_count מצוין המספר המינימלי של ה-workers בסביבה.

    • השדה 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 עם גודל הדיסק של שרת האינטרנט, בגיגה-בייט.

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

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

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

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

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

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

  }
}

שלב 5. (אופציונלי) הפעלת מצב עמידות גבוהה

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

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

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

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

המסוף

בדף Create environment:

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

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

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

    2. בתפריט הנפתח Number of schedulers, בוחרים באפשרות 2.

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

    4. ברשימה הנפתחת Minimum number of workers, בוחרים את הערך 2 או ערך גבוה יותר, בהתאם למספר ה-workers הנדרש.

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

    1. בסוג הרשת, בוחרים באפשרות סביבת IP פרטית.

    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.20 \
    --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
"
    }
  }
}

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

כשיוצרים סביבה עם עמידות סטנדרטית, אפשר לציין אזור מועדף של 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.20 \
    --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.20 \
    --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. האזור הזה חייב להיות באזור שבו נמצאת הסביבה.

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

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

המסוף

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

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

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

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

  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.20 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-private-environment \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \

מחליפים את:

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

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

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

תגי הרשת חלים על כל המכונות הווירטואליות של הצמתים באשכול של הסביבה. התגים משמשים לזיהוי מקורות או יעדים תקפים עבור חומות אש ברשת. כל תג ברשימה צריך להיות תואם ל-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.20 \
    --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.20 \
    --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
"
    }
  }
}

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

הפרמטרים של הגישה לשרת האינטרנט של 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, מציינים תיאור אופציונלי לטווח הזה. אם רוצים לציין יותר מטווח אחד, לוחצים על Add IP range.

    • כדי לחסום את הגישה לכל כתובות ה-IP, בוחרים באפשרות אפשר גישה רק מכתובות 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.20 \
    --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.20 \
    --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
"
    }

}

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

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

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

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

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

המסוף

בדף Create environment:

  1. בקטע Environment variables (משתני סביבה), לוחצים על Add environment variable (הוספת משתנה סביבה).

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

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

  4. מזינים את Section (קטע), Key (מפתח) ו-Value (ערך) כדי לשנות את אפשרות ההגדרה.

    לדוגמה:

    קטע מפתח ערך
    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.20 \
    --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.20 \
    --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

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

{
  "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 בבלוק software_config מציין משתני סביבה.

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

  • הבלוק 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
"
    }
  }
}

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

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

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

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

המסוף

בדף Create environment

  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.20 \
    --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 עם 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.

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

דוגמה:

// 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 עם 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.

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

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

שושלת נתונים היא תכונה של 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.20 \
    --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.20 \
    --service-account "
example-account@example-project.iam.gserviceaccount.com
" \
    --disable-cloud-data-lineage-integration

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

בדף 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.20 \
    --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.20 \
    --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"
  }

}

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