To more strongly embrace the success and growing customer preference for OSS solutions, Cloud Composer is evolving to become Managed Service for Apache Airflow. This name change provides improved customer understanding of our portfolio while reinforcing our commitment to being the most open cloud ecosystem.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

מידע נוסף על סביבות זמין במאמר ארכיטקטורת הסביבה.
מידע נוסף על יצירת סביבה באמצעות Terraform זמין במאמר יצירת סביבות (Terraform).

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

הפעלת Cloud Composer API. לרשימה המלאה של השירותים שבהם נעשה שימוש ב-Managed Airflow
מפעילים את קבוצת השירות עם ממשקי ה-API שנדרשים על ידי Managed Airflow (דור 2).
הזמן המשוער ליצירת סביבה הוא 25 דקות.
אם יוצרים סביבה באמצעות Terraform, לחשבון השירות שבו משתמשים ב-Terraform צריך להיות תפקיד עם הרשאה מסוג composer.environments.create.

מידע נוסף על חשבון השירות של Terraform זמין במאמר חומר עזר בנושא הגדרת פלאגין שמתממשק עם שירותים חיצוניים של Google.

מידע נוסף על שימוש ב-Terraform ליצירת סביבת Managed Airflow זמין במסמכי התיעוד של Terraform.

מידע נוסף על פרמטרים נוספים זמין במאמר Terraform Argument Reference.
כתובת IP פרטית: יש דרישות ספציפיות לגבי רשת וחיבור עמיתים כדי ליצור סביבת כתובת IP פרטית. מידע נוסף זמין במאמר בנושא הגדרת כתובת IP פרטית.
VPC משותף: יש דרישות רשת ספציפיות לשימוש ב-VPC משותף עם Managed Airflow. מידע נוסף זמין במאמר בנושא הגדרת VPC משותף.
‫VPC SC: כדי לפרוס סביבות של Managed Airflow בתוך מתחם אבטחה היקפית, אפשר לעיין במאמר בנושא הגדרת VPC SC. כשמשתמשים ב-VPC Service Controls עם Managed Airflow, יש כמה מגבלות ידועות.
יכול להיות שתראו רשומות של מטא-נתונים של Compute Engine עבור אשכולות GKE ששייכים לסביבות בפרויקט. במהלך יצירה ושדרוג של אשכול GKE,‏ Google Kubernetes Engine מוסיף באופן אוטומטי רשומות של מטא-נתונים ברמת הפרויקט (google_compute_project_metadata) כדי לעקוב אחרי השימוש בטווח כתובות ה-IP המשני. אין לשנות או להסיר את הרשומות האלה. מערכת Google Kubernetes Engine מנהלת אותם באופן אוטומטי.

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

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

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

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

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

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

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

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

יוצרים חשבון שירות חדש כמו שמתואר במסמכי ניהול הזהויות והרשאות הגישה.
מקצים לו תפקיד, כמו שמתואר במסמכי התיעוד של ניהול הזהויות והרשאות הגישה (IAM). התפקיד הנדרש הוא Composer Worker ‏ (composer.worker).
אם בסביבה שלכם מוגדרות הגבלות על מיקום המשאבים, או אם אתם מתקינים חבילות PyPI ממאגר של Artifact Registry או ממאגר פרטי, צריך להעניק את התפקיד Service Account User (iam.serviceAccountUser) לחשבון השירות שמנוהל על ידי המשתמש שמריץ את הסביבה בעצמו (גם הגורם הראשי וגם המשאב הם אותו חשבון שירות).
כדי לגשת למשאבים אחרים בפרויקט Google Cloud , צריך לתת לחשבון השירות הזה הרשאות נוספות לגשת למשאבים האלה. ברוב המקרים, התפקיד Composer Worker ‏ (composer.worker) מספק את קבוצת ההרשאות הנדרשת הזו. מוסיפים הרשאות נוספות לחשבון השירות הזה רק כשצריך כדי להפעיל את ה-DAG.

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

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

המסוף

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

כניסה לדף Create environment
בשדה Name, מזינים שם לסביבה.

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

מיקום הוא האזור שבו הסביבה נמצאת.
בתפריט הנפתח גרסת תמונה, בוחרים Managed Airflow image עם הגרסה הנדרשת של Airflow.
בתפריט הנפתח 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-2.17.3-airflow-2.11.1 \
    --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-2.17.3-airflow-2.11.1"
    },
    "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-2.17.3-airflow-2.11.1"
    }
    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

שלב 3. מתן ההרשאות הנדרשות לחשבון השירות של Managed Airflow

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

התפקיד Cloud Composer v2 API Service Agent Extension מספק הרשאות נוספות לחשבון של סוכן שירות Managed Airflow. התפקיד הזה לא ניתן אוטומטית. צריך להעניק את ההרשאה באופן ידני.

המסוף

כשיוצרים סביבה בפרויקט, אם לסוכן השירות המנוהל של Airflow אין את ההרשאות הנדרשות בחשבון השירות של הסביבה, מופיע הקטע Grant required permissions to Cloud Composer service account.

מוסיפים את חשבון סוכן השירות של Managed Airflow בתור גורם חדש בחשבון השירות של הסביבה, ומקצים לו את התפקיד Cloud Composer v2 API Service Agent Extension.

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

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SERVICE_ACCOUNT \
    --member serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

מחליפים את:

‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.
PROJECT_NUMBER עם מספר הפרויקט.

דוגמה:

gcloud iam service-accounts add-iam-policy-binding \
    example-account@example-project.iam.gserviceaccount.com \
    --member serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

API

כדי להעניק את התפקיד, צריך לשנות את מדיניות ההרשאות הקיימת באמצעות התבנית של קריאה-שינוי-כתיבה:

קוראים את מדיניות ההרשאות הקיימת של חשבון השירות בסביבה.
משנים אותו כך שיכלול את התפקיד roles/composer.ServiceAgentV2Ext לסוכן השירות של Managed Airflow.
לכתוב מחדש את מדיניות ההרשאות הקיימת.

מידע נוסף מופיע במאמר שליטה בגישה באופן פרוגרמטי.

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

מחליפים את:

PROJECT_NUMBER עם מספר הפרויקט.

דוגמה:

{
  "role": "roles/composer.ServiceAgentV2Ext",
  "members": [
    "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
  ]
}

Terraform

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

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

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "SERVICE_ACCOUNT"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com"
}

מחליפים את:

‫SERVICE_ACCOUNT עם חשבון השירות של הסביבה.
PROJECT_NUMBER עם מספר הפרויקט.

דוגמה:

resource "google_service_account_iam_member" "custom_service_account" {
  provider = google-beta
  service_account_id = "example-account@example-project.iam.gserviceaccount.com"
  role = "roles/composer.ServiceAgentV2Ext"
  member = "serviceAccount:service-00000000000@cloudcomposer-accounts.iam.gserviceaccount.com"
}

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

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

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

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

גודל הסביבה. הגדרת פרמטרים של ביצועים בתשתית של Managed Airflow, כולל מסד הנתונים של Airflow. כדאי לבחור גודל סביבה גדול יותר אם רוצים להריץ מספר גדול של DAG ומשימות עם ביצועים טובים יותר של התשתית. לדוגמה, ככל שהסביבה גדולה יותר, כך היא יכולה לעבד יותר רשומות ביומן של משימות Airflow עם עיכוב מינימלי.
הגדרת עומסי עבודה. שליטה בהיקף ובביצועים של רכיבי Airflow שפועלים באשכול GKE של הסביבה.
- מתזמן Airflow. מנתח קבצים של הגדרות DAG, מתזמן הפעלות של DAG על סמך מרווח התזמון ומכניס משימות לתור לביצוע על ידי עובדי Airflow.
  
  בסביבה שלכם יכולים לפעול כמה מתזמני Airflow בו-זמנית. כדי לשפר את הביצועים והאמינות, מומלץ להשתמש בכמה מתזמנים כדי לחלק את העומס בין כמה מופעים של מתזמן.
  
  הגדלת מספר המתזמנים לא תמיד משפרת את הביצועים של Airflow. לדוגמה, יכול להיות ששימוש במתזמן אחד יניב ביצועים טובים יותר מאשר שימוש בשני מתזמנים. זה יכול לקרות כשלא נעשה שימוש במתזמן הנוסף, ולכן הוא צורך משאבים מהסביבה בלי לתרום לביצועים הכוללים. הביצועים בפועל של מתזמן העבודות תלויים במספר העובדים של Airflow, במספר ה-DAG והמשימות שפועלים בסביבה שלכם ובהגדרות של Airflow ושל הסביבה.
  
  מומלץ להתחיל עם שני מתזמנים ואז לעקוב אחרי הביצועים של הסביבה. אם משנים את מספר המתזמנים, תמיד אפשר להקטין את הסביבה בחזרה למספר המתזמנים המקורי.
  
  מידע נוסף על הגדרת מספר מתזמנים זמין במאמרי העזרה של Airflow.
- ‫Airflow triggerer. עוקב באופן אסינכרוני אחרי כל המשימות שנדחו בסביבה שלכם. אם יש לכם לפחות מופע אחד של מפעיל בסביבה שלכם (או לפחות שניים בסביבות עמידות במיוחד), אתם יכולים להשתמש באופרטורים שניתן לדחות ב-DAG שלכם.
  
  ב-Managed Airflow (דור 2), טריגר Airflow מושבת כברירת מחדל. אם רוצים ליצור סביבה עם מפעיל, צריך להגדיר את מספר המפעילים לאחד או יותר.
- שרת האינטרנט של Airflow. מריץ את ממשק האינטרנט של Airflow שבו אפשר לעקוב אחרי ה-DAG, לנהל אותו ולהמחיש אותו.
- Airflow workers. להריץ משימות שמתוזמנות על ידי Airflow schedulers. מספר העובדים המינימלי והמקסימלי בסביבה משתנה באופן דינמי בהתאם למספר המשימות בתור.

המסוף

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

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

כדי להשתמש בערכים שהוגדרו מראש, בקטע משאבי סביבה לוחצים על קטן, בינוני או גדול.
כדי לציין ערכים מותאמים אישית לפרמטרים של קנה המידה והביצועים:
1. בקטע משאבי סביבה, לוחצים על התאמה אישית.
2. בקטע Scheduler, מגדירים את מספר המתזמנים שרוצים להשתמש בהם ואת הקצאת המשאבים למעבד, לזיכרון ולאחסון שלהם.
3. בקטע Triggerer, משתמשים בשדה Number of triggerers כדי להזין את מספר ה-triggerers בסביבה שלכם.
  
  אם אתם לא רוצים להשתמש באופרטורים שניתן לדחות ב-DAG, אתם יכולים להגדיר את מספר הטריגרים לאפס. כברירת מחדל, ההפעלה מושבתת ב-Managed Airflow (דור 2).
  
  אם הגדרתם לפחות טריגר אחד לסביבה, תוכלו להשתמש בשדות 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.
‫--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-2.17.3-airflow-2.11.1 \
    --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 \
    --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.
SCHEDULER_COUNT עם מספר הכלי לתזמון פגישות.
‫SCHEDULER_CPU עם מספר המעבדים למתזמן, ביחידות vCPU.
‫SCHEDULER_MEMORY עם נפח הזיכרון של מתזמן.
‫SCHEDULER_STORAGE עם גודל הדיסק של מתזמן.
TRIGGERER_COUNT עם מספר הטריגרים.
‫TRIGGERER_CPU עם מספר המעבדים של הגורם המפעיל, ביחידות vCPU.
‫TRIGGERER_MEMORY עם נפח הזיכרון של הגורם המפעיל, ב-GB.
‫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-2.17.3-airflow-2.11.1 \
    --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 \
    --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
      },
      "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.
‫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.

דוגמה:

// 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
      },
      "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 מצוין מספר הטריגרים בסביבה שלכם.
- בשדה 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
      }
      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.
‫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.

דוגמה:

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. (אופציונלי) הפעלת מצב חוסן גבוה

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

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

שני מתזמני Airflow בדיוק
לפחות שני טריגרים (אם מספר הטריגרים לא מוגדר כ-0)
שני שרתי אינטרנט

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

המסוף

בדף Create environment:

בקטע Resilience mode (מצב חוסן), בוחרים באפשרות High resilience (חוסן גבוה).
בקטע Environment resources, בוחרים פרמטרים של שינוי גודל לסביבה עם חוסן גבוה. בסביבות עם חוסן גבוה נדרשים בדיוק שני מתזמנים, אפס או בין שניים לעשרה מפעילים ולפחות שני עובדים:
1. לוחצים על התאמה אישית.
2. ברשימה הנפתחת Number of schedulers (מספר המתזמנים), בוחרים באפשרות 2.
3. בתפריט הנפתח מספר המפעילים, בוחרים באפשרות 0 או בערך בין 2 ל-10. מגדירים את הקצאת המעבד והזיכרון לטריגרים.
4. בתפריט הנפתח מספר העובדים המינימלי, בוחרים באפשרות 2 או יותר, בהתאם למספר העובדים הנדרש.
בקטע 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-2.17.3-airflow-2.11.1 \
    --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:

בקטע Advanced configuration (הגדרה מתקדמת), מרחיבים את הפריט Show advanced configuration (הצגת הגדרה מתקדמת).
ברשימה Airflow database zone, בוחרים את אזור Cloud SQL המועדף.

gcloud

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --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-2.17.3-airflow-2.11.1 \
    --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. (אופציונלי) הגדרת הרשת של הסביבה

פרמטרים של רשת תלויים בסוג הסביבה שרוצים ליצור:

סביבת כתובת IP ציבורית. שימוש בפרמטרים של ברירת המחדל של הרשת.
סביבת IP פרטית (עם PSC). בהגדרה הזו, הסביבה שלכם משתמשת ב-Private Service Connect לקישוריות.

הגדרת סביבת כתובת IP פרטית:
1. מגדירים את הרשת של הפרויקט לסביבות עם כתובת IP פרטית.
2. מגדירים Private Service Connect כשיוצרים את הסביבה.
3. מציינים פרמטרים אחרים לסביבת ה-IP הפרטי, כמו שמתואר בהמשך הקטע הזה.
בסביבת IP פרטית עם PSC, צריך לדעת:
- מזהה רשת ה-VPC
- מזהה רשת המשנה של ה-VPC
- שני טווחי כתובות IP משניים בתת-הרשת של ה-VPC:
  - טווח IP משני ל-pods
  - טווח IP משני לשירותים
- טווחי כתובות ה-IP של רכיבי הסביבה:
  - טווח כתובות ה-IP של מישור הבקרה של GKE. טווח כתובות ה-IP של מישור הבקרה של GKE.
  - רשת משנה לחיבור Managed Airflow. טווח כתובות ה-IP של תת-הרשת של חיבור Managed Airflow.
סביבת IP פרטית (VPC peerings). בהגדרה הזו, הסביבה שלכם משתמשת בקישור של רשתות VPC לקישוריות.

הגדרת סביבת כתובת IP פרטית:
1. מגדירים את הרשת של הפרויקט לסביבות עם כתובת IP פרטית.
2. מציינים פרמטרים אחרים לסביבת ה-IP הפרטי, כמו שמתואר בהמשך הקטע הזה.
בסביבת כתובות IP פרטיות עם קישורים בין רשתות שכנות של VPC, צריך לדעת:
- מזהה רשת ה-VPC
- מזהה רשת המשנה של ה-VPC
- שני טווחי כתובות IP משניים בתת-הרשת של ה-VPC:
  - טווח IP משני ל-pods
  - טווח IP משני לשירותים
- טווחי כתובות ה-IP של רכיבי הסביבה:
  - טווח כתובות ה-IP למישור הבקרה של GKE.
  - טווח כתובות ה-IP עבור שיוך VPC לייצוא מרשת Managed Airflow הפנימית המנוהלת לרשת שנבחרה. רכיבי תשתית Managed Airflow משתמשים בכתובות IP מהטווח הזה.
  - טווח כתובות ה-IP של מכונת Cloud SQL.
בסביבת VPC משותף, צריך לבצע הגדרות נוספות של רשת בפרויקט המארח, ואז ליצור סביבת IP ציבורית או פרטית בפרויקט שירות. פועלים לפי ההוראות בדף הגדרת VPC משותף.

חשוב: אם יוצרים סביבה בפרויקט השירות באמצעותGoogle Cloud מסוף, לחשבון צריכה להיות ההרשאה compute.subnetworks.use בפרויקט המארח. אחרת, רשימת רשתות המשנה הזמינות לא תכלול רשתות משנה מפרויקט המארח. אם יוצרים סביבה באמצעות gcloud, API או Terraform, לא צריך לתת לחשבון את ההרשאה הנוספת הזו.

בסביבת VPC משותף, צריך לדעת:
- מזהה רשת ה-VPC של הפרויקט המארח
- מזהה רשת המשנה של ה-VPC בפרויקט המארח
- שני טווחי כתובות IP משניים בתת-הרשת של ה-VPC בפרויקט המארח:
  - טווח IP משני ל-pods
  - טווח IP משני לשירותים
כשיוצרים סביבת VPC משותפת עם כתובת IP ציבורית, עדיין צריך לציין את רשת ה-VPC של הפרויקט המארח, את רשת המשנה ואת טווחי כתובות ה-IP המשניות של הפודים והשירותים.
כדי ליצור סביבת VPC SC, צריך ליצור גבולות גזרה לשירות ואז ליצור סביבות עם כתובות IP פרטיות בתוך גבולות הגזרה האלה. פועלים לפי ההוראות במאמר הגדרת VPC Service Controls.
כדי ליצור סביבה עם שימוש מוגבל בנקודות קצה, צריך להגדיר מדיניות ארגונית של constraints/gcp.restrictEndpointUsage, ואז ליצור סביבה חדשה של Managed Airflow (דור 2). בסביבות עם כתובות IP פרטיות נדרשת הגדרה נוספת של הרשת. פועלים לפי ההוראות שמפורטות במאמר בנושא הגדרת סביבות באמצעות מדיניות שימוש מוגבלת בנקודות קצה.

אפשרויות נוספות לרשתות בסביבות:

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

המסוף

כדי ליצור סביבת כתובות IP פרטיות:

מוודאים שהגדרת הרשת מתאימה לסוג הסביבה שרוצים ליצור.
בקטע Network configuration, מרחיבים את הפריט Show network configuration.
ברשימה הנפתחת Network, בוחרים את מזהה רשת ה-VPC.
ברשימה הנפתחת Subnetwork (רשת משנה), בוחרים את מזהה רשת המשנה של ה-VPC.
בקטע Secondary IP range for pods, בוחרים או מציינים את טווח כתובות ה-IP המשני של הפודים. אפשר להשתמש בטווח משני קיים ברשת ה-VPC, או לבחור להשתמש בטווח שנוצר אוטומטית.
בקטע Secondary IP range for services, בוחרים או מציינים את טווח כתובות ה-IP המשני לשירותים. אפשר להשתמש בטווח משני קיים ברשת ה-VPC, או לבחור להשתמש בטווח שנוצר אוטומטית.
בקטע Networking type, בוחרים באפשרות Private IP environment כדי ליצור סביבת IP פרטית.
בקטע Composer connectivity (קישוריות של Composer), בוחרים את סוג הרשת עבור הסביבה ומציינים את טווחי כתובות ה-IP של רכיבי הסביבה:

בסביבה שמשתמשת ב-Private Service Connect:
1. בוחרים באפשרות Private Service Connect (חיבור לשירות פרטי) לסביבה שמשתמשת בPrivate Service Connect.
2. בקטע Composer connection subnetwork (רשת משנה לחיבור Composer), מציינים טווח כתובות IP לרשת המשנה של חיבור Managed Airflow. הכתובת של נקודת הקצה של PSC נבחרת מתוך הטווח הזה. אפשר לציין טווח מותאם אישית או לבחור להשתמש בברירת המחדל.
בסביבה שמשתמשת ב-VPC peerings:
1. בוחרים באפשרות VPC peerings (קישור בין רשתות VPC שכנות) לסביבה שמשתמשת בקישור בין רשתות VPC שכנות.
  
  הערה: בסביבות עם חיבורי VPC יש יותר מגבלות מאשר בסביבות עם PSC.
2. בקטע IP range for Composer tenant network (טווח כתובות IP לרשת של דייר Composer), מציינים טווח כתובות IP לרשת של Managed Airflow. ברשת הזו מתארח רכיב ה-SQL proxy של הסביבה. אפשר לציין טווח מותאם אישית או לבחור להשתמש בברירת המחדל.
3. בקטע IP range for Cloud SQL network, מציינים טווח כתובות IP למכונה של Cloud SQL. אפשר לציין טווח מותאם אישית או לבחור להשתמש בברירת המחדל.
  
  שימו לב: טווח 172.17.0.0/16 שמור ב-Cloud SQL.
בקטע IP range for GKE control plane network (טווח כתובות ה-IP לרשת של מישור הבקרה של GKE), מציינים טווח כתובות IP למישור הבקרה של GKE:
- כדי להשתמש בטווח ברירת המחדל של כתובות ה-IP לאזור שבו נמצאת הסביבה, בוחרים באפשרות טווח ברירת המחדל של כתובות ה-IP.
- כדי לציין טווח כתובות IP מותאם אישית, בוחרים באפשרות Custom IP range ומזינים טווח בסימון CIDR בשדה IP פרטי של מאסטר אשכול GKE.
בוחרים את רמת הגישה למישור הבקרה של GKE. למישור הבקרה יש שתי נקודות קצה. נקודת קצה אחת היא פרטית, לשימוש של צמתי אשכולות ומכונות וירטואליות. נקודת קצה אחרת היא ציבורית. אפשר לציין את רמת הגישה לנקודת הקצה הציבורית:
- כדי להפעיל גישה לנקודת הקצה הציבורית מרשתות מורשות, מסמנים את תיבת הסימון Access cluster control plane endpoint using its external IP address (גישה לנקודת הקצה של מישור הבקרה של האשכול באמצעות כתובת ה-IP החיצונית שלה).
  
  השימוש באפשרות הזו מגדיר את רמת הגישה למישור הבקרה ל'הגישה לנקודת קצה ציבורית מופעלת, רשתות מורשות מופעלות'. הגישה למישור הבקרה מוגבלת לרשתות מורשות. כברירת מחדל, לא מצוינות כתובות IP של מקורות. אפשר להוסיף רשתות מורשות לאשכול.
- כדי להשבית את הגישה לנקודת הקצה הציבורית מרשתות מורשות, מבטלים את הסימון בתיבה Access cluster control plane endpoint using its external IP address (גישה לנקודת הקצה של מישור הבקרה של האשכול באמצעות כתובת ה-IP החיצונית שלה).
  
  השימוש באפשרות הזו מגדיר את רמת הגישה למישור הבקרה כ"הגישה לנקודת קצה ציבורית מושבתת". הפעולה הזו מונעת גישה למישור הבקרה מכל מקום באינטרנט.

gcloud

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

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

‫--enable-private-environment מאפשרת סביבת IP פרטית.
‫--network מציין את מזהה רשת ה-VPC.
‫--subnetwork מציין את מזהה רשת המשנה של ה-VPC.
‫--cluster-secondary-range-name או --cluster-ipv4-cidr מגדירים את הטווח המשני של ה-pods.
‫--services-secondary-range-name או --services-ipv4-cidr כדי להגדיר את הטווח המשני לשירותים.
‫--master-ipv4-cidr מציין טווח למישור הבקרה של GKE.

‫(Environments with PSC) --connection-subnetwork specifies a range for the Managed Airflow connection subnetwork, which hosts the PSC endpoint.
(סביבות עם קישור בין רשתות VPC שכנות) --connection-type=VPC_PEERING מציין שסביבה חייבת להשתמש בקישור בין רשתות VPC שכנות.
(סביבות עם חיבורי VPC) --composer-network-ipv4-cidr מציין טווח לרשת הדיירים של Managed Airflow. ברשת הזו מתארח רכיב ה-SQL proxy של הסביבה שלכם.
‫(Environments with VPC peerings) --cloud-sql-ipv4-cidr specifies a range for the Cloud SQL instance.

‫--enable-private-endpoint שולט ברמת הגישה למישור הבקרה של GKE. למישור הבקרה יש שתי נקודות קצה. נקודת קצה אחת היא פרטית, לשימוש של צמתי אשכולות ומכונות וירטואליות. נקודת קצה אחרת היא ציבורית. אפשר לציין את רמת הגישה לנקודת הקצה הציבורית:
- כדי לאפשר גישה לנקודת הקצה הציבורית מרשתות מורשות, משמיטים את הארגומנט --enable-private-endpoint.
  
  השימוש באפשרות הזו מגדיר את רמת הגישה למישור הבקרה כ'גישה לנקודת קצה ציבורית מופעלת, רשתות מורשות מופעלות'. הגישה למישור הבקרה מוגבלת לרשתות מורשות. כברירת מחדל, לא מצוינות כתובות IP של מקורות. אפשר להוסיף רשתות מורשות לאשכול.
- כדי להשבית את הגישה לנקודת הקצה הציבורית מרשתות מורשות, מציינים את הארגומנט --enable-private-endpoint.
  
  השימוש באפשרות הזו מגדיר את רמת הגישה למישור הבקרה כ"הגישה לנקודת קצה ציבורית מושבתת". הפעולה הזו מונעת גישה למישור הבקרה מכל מקום באינטרנט.
הארגומנטים --enable-master-authorized-networks ו---master-authorized-networks מגדירים רשתות מורשות לסביבה שלכם.
‫--enable-privately-used-public-ips מגדיר כתובות IP ציבוריות לשימוש פרטי בסביבה שלכם.
--enable-ip-masq-agent מפעיל את סוכן ה-IP Masquerade.

דוגמה (סביבת IP פרטי )

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-private-environment \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \
    --cluster-ipv4-cidr PODS_RANGE \
    --services-ipv4-cidr SERVICES_RANGE \
    --master-ipv4-cidr CONTROL_PLANE_RANGE \
    --connection-subnetwork COMPOSER_PSC_RANGE \

מחליפים את:

‫NETWORK_ID במזהה רשת ה-VPC.
‫SUBNETWORK_ID עם מזהה רשת המשנה של ה-VPC.
‫PODS_RANGE עם הטווח המשני של הפודים.
‫SERVICES_RANGE עם הטווח המשני של שירותים.
CONTROL_PLANE_RANGE עם הטווח המשני למישור הבקרה של GKE.
‫COMPOSER_PSC_RANGE עם הטווח של רשת המשנה לחיבור Managed Airflow.

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

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

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

המסוף

בדף Create environment:

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

gcloud

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

‫--tags מציין רשימה מופרדת בפסיקים של תגי רשת שמוחלים על כל מכונות ה-VM של הצמתים.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --service-account "SERVICE_ACCOUNT" \
    --tags TAGS

מחליפים את:

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

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --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:

בקטע Network configuration, מרחיבים את הפריט Show network configuration.
בקטע 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-2.17.3-airflow-2.11.1 \
    --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-2.17.3-airflow-2.11.1 \
    --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:

בקטע משתני סביבה, לוחצים על הוספת משתנה סביבה.
מזינים את השם והערך של משתנה הסביבה.
בקטע Airflow configuration overrides, לוחצים על Add Airflow configuration override.
מזינים את הקטע, המפתח והערך של האפשרות לביטול ברירת המחדל של ההגדרה.

לדוגמה:

קטע מפתח ערך

webserver dag_orientation TB

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

gcloud

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

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

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --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-2.17.3-airflow-2.11.1 \
    --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
"
    }
  }
}

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

חלונות הזמן שמוגדרים כברירת מחדל לתחזוקה ב-Managed Airflow (דור 2) הם מ-00:00:00 עד 04:00:00 (GMT) בימי שישי, שבת וראשון בכל שבוע.

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

המסוף

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

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

gcloud

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

‫--maintenance-window-start מגדיר את שעת ההתחלה של חלון תחזוקה.
‫--maintenance-window-end מגדיר את שעת הסיום של חלון זמן לתחזוקה.
‫--maintenance-window-recurrence מגדיר את החזרה של חלון זמן לתחזוקה.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --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-2.17.3-airflow-2.11.1 \
  --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 מציין חזרה על הפעולה בימים נבחרים בשבוע.

דוגמה:

// 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 מציין חזרה על הפעולה בימים נבחרים בשבוע.

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. (אופציונלי) שילוב של שושלת נתונים

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

שילוב של מעקב אחר מקורות נתונים זמין בגרסאות 2.1.2 ואילך של Managed Airflow (דור 2) עם גרסאות 2.2.5 ואילך של Airflow.

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

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

שימו לב: אחרי שמפעילים את Data Lineage API, ‏Knowledge Catalog מתחיל באופן אוטומטי להטמיע נתונים עבור BigQuery,‏ Cloud Data Fusion ו-Managed Service for Apache Spark. זה קורה גם אם לא יוצרים סביבת Managed Airflow עם שילוב של שושלת נתונים.
אפשר להגדיר את הטמעת שושלת הנתונים כדי להפעיל או להשבית את ההטמעה האוטומטית של שושלת הנתונים ב-BigQuery או ב-Managed Service for Apache Spark. התכונה 'שליטה בהוספת נתוני שושלת' נמצאת בשלב ההשקה של גרסת טרום-השקה (Preview).
לא מוגדר Lineage Backend מותאם אישית ב-Airflow.

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

המסוף

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

בקטע Advanced configuration (הגדרה מתקדמת), מרחיבים את האפשרות Show advanced configuration (הצגת הגדרה מתקדמת).
בתפריט 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-2.17.3-airflow-2.11.1 \
    --service-account "SERVICE_ACCOUNT" \
    --disable-cloud-data-lineage-integration

מחליפים את:

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

דוגמה:

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

gcloud

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --service-account "SERVICE_ACCOUNT" \
    --labels LABELS

מחליפים את:

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

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.17.3-airflow-2.11.1 \
    --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"
  }

}

יצירת סביבות של Managed Service for Apache Airflow קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

המסוף

gcloud

API

Terraform

שלב 3. מתן ההרשאות הנדרשות לחשבון השירות של Managed Airflow

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

API

Terraform

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

המסוף

gcloud

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

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

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

המסוף

gcloud

API

Terraform

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

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