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 משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

מיקום הוא האזור שבו הסביבה נמצאת.
ברשימה הנפתחת Image version, בוחרים תמונת Managed Airflow עם הגרסה הנדרשת של 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.17-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 במזהה הפרויקט.
‫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.17-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.17-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 Service Agent. התפקיד הזה לא ניתן באופן אוטומטי. צריך לתת את ההרשאה באופן ידני.

המסוף

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

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

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

gcloud

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

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

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

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

אם אתם לא משתמשים ב-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 workers.
  
  בסביבה שלכם אפשר להריץ יותר ממתזמן Airflow אחד בו-זמנית. כדי לשפר את הביצועים והמהימנות, מומלץ להשתמש בכמה מתזמנים כדי לחלק את העומס בין כמה מופעים של מתזמן.
  
  הגדלת מספר המתזמנים לא תמיד משפרת את הביצועים של Airflow. לדוגמה, יכול להיות שמתזמן אחד יספק ביצועים טובים יותר משני מתזמנים. זה יכול לקרות כשלא משתמשים במתזמן הנוסף, ולכן הוא צורך משאבים מהסביבה בלי לתרום לביצועים הכוללים. הביצועים בפועל של המתזמן תלויים במספר ה-workers של Airflow, במספר ה-DAGs והמשימות שפועלים בסביבה, ובהגדרות של Airflow ושל הסביבה.
  
  מומלץ להתחיל עם שני מתזמנים ואז לעקוב אחרי הביצועים של הסביבה. אם תשנו את מספר המתזמנים, תמיד תוכלו להחזיר את הסביבה למספר המתזמנים המקורי.
  
  מידע נוסף על הגדרת כמה מתזמנים זמין במסמכי התיעוד של Airflow.
- טריגר של Airflow. מנטר באופן אסינכרוני את כל המשימות שנדחו בסביבה שלכם. אם יש לכם לפחות מופע אחד של טריגר בסביבה (או לפחות שניים בסביבות עם עמידות גבוהה), אתם יכולים להשתמש באופרטורים שניתנים לדחייה ב-DAG.
  
  ב-Managed Airflow (דור 2), טריגר Airflow מושבת כברירת מחדל. אם רוצים ליצור סביבה עם מפעיל, צריך להגדיר את מספר המפעילים לאחד או יותר.
- שרת אינטרנט של Airflow. מפעיל את ממשק האינטרנט של Airflow, שבו אפשר לעקוב אחרי ה-DAG, לנהל אותם ולהציג אותם באופן חזותי.
- עובדי Airflow. להריץ משימות שמתוזמנות על ידי מתזמני Airflow. מספר ה-workers המינימלי והמקסימלי בסביבה משתנה באופן דינמי בהתאם למספר המשימות בתור.

המסוף

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

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

כדי להשתמש בערכים שהוגדרו מראש, בקטע משאבי סביבה, לוחצים על קטן, בינוני או גדול.
כדי לציין ערכים מותאמים אישית לפרמטרים של קנה המידה והביצועים:
1. בקטע Environment resources, לוחצים על Custom.
2. בקטע Scheduler, מגדירים את מספר המתזמנים שרוצים להשתמש בהם, ואת הקצאת המשאבים למעבד, לזיכרון ולאחסון שלהם.
3. בקטע Triggerer, בשדה Number of triggerers מזינים את מספר הטריגרים בסביבה.
  
  אם אתם לא רוצים להשתמש באופרטורים שניתנים להשהיה ב-DAG, אתם יכולים להגדיר את מספר הטריגרים לאפס. כברירת מחדל, הטריגר מושבת ב-Managed Airflow (דור שני).
  
  אם הגדרתם לפחות טריגר אחד לסביבה, אתם יכולים להשתמש בשדות CPU ו-Memory כדי להגדיר את הקצאת המשאבים לטריגרים.
4. בקטע DAG processor, מציינים את מספר מעבדי ה-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 מציין את מספר המעבדים להפעלת 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.
‫--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. מספר העובדים שפועלים באשכול בסביבה שלכם.
‫--max-workers מציין את המספר המקסימלי של Airflow workers. באשכול של הסביבה שלכם פועל לכל היותר מספר ה-workers הזה.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.17-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 עם מספר המעבדים של ה-worker, ביחידות vCPU.
‫WORKER_MEMORY עם נפח הזיכרון של העובד.
‫WORKER_STORAGE מחליפים בגודל הדיסק של העובד.
‫WORKERS_MIN עם המספר המינימלי של Airflow workers שהסביבה יכולה להריץ. מספר ה-workers בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של workers יכול להתמודד עם העומס.
‫WORKERS_MAX במספר המקסימלי של Airflow workers שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם נדרש מספר גבוה יותר של עובדים כדי לטפל בעומס.

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-2.17.17-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 מציין את מספר המעבדים (CPU) של הטריגר, ביחידות vCPU. ערכים מותרים: 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 עם מספר המעבדים של ה-worker, ביחידות vCPU.
‫WORKER_MEMORY עם נפח הזיכרון של ה-worker, ב-GB.
‫WORKER_STORAGE עם גודל הדיסק של ה-worker, ב-GB.
‫WORKERS_MIN עם המספר המינימלי של עובדי Airflow שהסביבה יכולה להריץ. מספר ה-workers בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של workers יכול להתמודד עם העומס.
‫WORKERS_MAX במספר המקסימלי של Airflow workers שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם נדרש מספר גבוה יותר של עובדים כדי לטפל בעומס.
‫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.memory_gb מצוין נפח הזיכרון של טריגר Airflow.
- בשדה triggerer.count מצוין מספר הטריגרים בסביבה שלכם.
- בשדה web_server.cpu מציינים את מספר המעבדים לשרת האינטרנט של Airflow.
- בשדה web_server.memory_gb מצוין נפח הזיכרון של שרת האינטרנט של Airflow.
- בשדה web_server.storage_gb מצוין נפח האחסון בשרת האינטרנט של Airflow.
- השדה worker.cpu מציין את מספר המעבדים של Airflow worker.
- בשדה worker.memory_gb מצוין נפח הזיכרון של עובד Airflow.
- בשדה 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
      }
      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 עם מספר המעבדים של ה-worker, ביחידות vCPU.
‫WORKER_MEMORY עם נפח הזיכרון של ה-worker, ב-GB.
‫WORKER_STORAGE עם גודל הדיסק של ה-worker, ב-GB.
‫WORKERS_MIN עם המספר המינימלי של עובדי Airflow שהסביבה יכולה להריץ. מספר ה-workers בסביבה לא יעלה על המספר הזה, גם אם מספר נמוך יותר של workers יכול להתמודד עם העומס.
‫WORKERS_MAX במספר המקסימלי של Airflow workers שהסביבה יכולה להריץ. מספר העובדים בסביבה לא יעלה על המספר הזה, גם אם נדרש מספר גבוה יותר של עובדים כדי לטפל בעומס.
‫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)
שני שרתי אינטרנט

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

המסוף

בדף Create environment:

בקטע מצב עמידות, בוחרים באפשרות עמידות גבוהה.
בקטע Environment resources, בוחרים פרמטרים של קנה מידה לסביבה עם עמידות גבוהה. בסביבות עם עמידות גבוהה נדרשים בדיוק שני מתזמנים, אפס או בין שניים לעשרה טריגרים, ולפחות שני וורקרים:
1. לוחצים על התאמה אישית.
2. בתפריט הנפתח Number of schedulers, בוחרים באפשרות 2.
3. ברשימה הנפתחת מספר המפעילים, בוחרים באפשרות 0 או בערך בין 2 ל-10. מגדירים את הקצאת ה-CPU וה-Memory לטריגרים.
4. ברשימה הנפתחת Minimum number of workers, בוחרים את הערך 2 או ערך גבוה יותר, בהתאם למספר ה-workers הנדרש.
בקטע הגדרת רשת:
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.17-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.17-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.17-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 משני לפודים
  - טווח כתובות IP משני לשירותים
- טווחי כתובות ה-IP של רכיבי הסביבה:
  - טווח כתובות ה-IP של מישור הבקרה של GKE. טווח כתובות ה-IP של מישור הבקרה של GKE.
  - רשת משנה של חיבור Managed Airflow. טווח כתובות ה-IP של תת-הרשת של חיבור Managed Airflow.
סביבת כתובת IP פרטית (קישורי VPC). בהגדרה הזו, הסביבה שלכם משתמשת בחיבורי VPC לצורך קישוריות.

מגדירים את סביבת ה-IP הפרטי:
1. להגדיר את הרשת של הפרויקט לסביבות של כתובות IP פרטיות.
2. מציינים פרמטרים אחרים לסביבת ה-IP הפרטי, כמו שמתואר בהמשך הקטע הזה.
בסביבת כתובות IP פרטיות עם קישורים בין רשתות שכנות של VPC, צריך לדעת:
- מזהה רשת ה-VPC
- מזהה רשת המשנה של ה-VPC
- שני טווחי כתובות IP משניים ברשת המשנה של ה-VPC:
  - טווח כתובות IP משני לפודים
  - טווח כתובות IP משני לשירותים
- טווחי כתובות ה-IP של רכיבי הסביבה:
  - טווח כתובות ה-IP של מישור הבקרה של GKE.
  - טווח כתובות ה-IP של רשתות שכנות (peering) ב-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 משני לפודים
  - טווח IP משני לשירותים
כשיוצרים סביבת VPC משותפת עם כתובת IP ציבורית, עדיין צריך לציין את רשת ה-VPC, את רשת המשנה ואת טווחי ה-IP המשניים של הפרויקט המארח בשביל Pods ושירותים.
כדי ליצור סביבת VPC SC, צריך ליצור גבולות גזרה לשירות ואז ליצור סביבות של כתובות IP פרטיות בתוך גבולות הגזרה האלה. פועלים לפי ההוראות שמפורטות במאמר הגדרת VPC Service Controls.
כדי ליצור סביבה עם שימוש מוגבל בנקודות קצה, צריך להגדיר מדיניות ארגונית ב-constraints/gcp.restrictEndpointUsage, ואז ליצור סביבה חדשה של Managed Airflow (דור שני). בסביבות עם כתובת IP פרטית נדרשת הגדרה נוספת של הרשת. פועלים לפי ההוראות במאמר הגדרת סביבות עם מדיניות שימוש מוגבל בנקודות קצה.

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

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

המסוף

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

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

בסביבה שמשתמשת ב-Private Service Connect:
1. בוחרים באפשרות Private Service Connect לסביבה שמשתמשת ב-Private Service Connect.
2. בקטע Composer connection subnetwork, מציינים טווח כתובות IP לרשת המשנה של החיבור ל-Managed Airflow. הכתובת של נקודת הקצה של ה-PSC נבחרת מהטווח הזה. אתם יכולים לציין טווח בהתאמה אישית או להשתמש בטווח ברירת המחדל.
בסביבה שמשתמשת ב-VPC peerings:
1. בוחרים באפשרות VPC peerings לסביבה שמשתמשת בקישורי VPC שכנים.
  
  הערה: בסביבות עם קישורי VPC יש יותר מגבלות מאשר בסביבות עם PSC.
2. בקטע IP range for Composer tenant network, מציינים טווח כתובות IP לרשת של הדייר ב-Managed Airflow. הרשת הזו מארחת את רכיב ה-proxy של SQL בסביבה שלכם. אתם יכולים לציין טווח מותאם אישית או להשתמש בברירת המחדל.
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 באזור שבו נמצאת הסביבה, בוחרים באפשרות Default IP range.
- כדי לציין טווח כתובות IP בהתאמה אישית, בוחרים באפשרות Custom IP range ומזינים טווח בסימון CIDR בשדה GKE cluster master private IP.
בוחרים את רמת הגישה למישור הבקרה של GKE. למישור הבקרה יש שתי נקודות קצה. נקודת קצה אחת היא פרטית, לשימוש על ידי צומתי אשכולות ומכונות וירטואליות. נקודת קצה אחרת היא ציבורית. אתם יכולים לציין את רמת הגישה לנקודת הקצה הציבורית:
- כדי להפעיל גישה לנקודת הקצה הציבורית מרשתות מורשות, מסמנים את תיבת הסימון Access cluster control plane endpoint using its external IP address (גישה לנקודת הקצה של מישור הבקרה של האשכול באמצעות כתובת ה-IP החיצונית שלה).
  
  אם משתמשים באפשרות הזו, רמת הגישה למישור הבקרה מוגדרת ל-Public endpoint access enabled, authorized networks enabled. כך הגישה למישור הבקרה מוגבלת לרשתות מורשות. כברירת מחדל, לא מצוינות כתובות IP של מקורות. אפשר להוסיף רשתות מורשות לאשכול.
- כדי להשבית את הגישה לנקודת הקצה הציבורית מרשתות מורשות, מבטלים את הסימון בתיבה Access cluster control plane endpoint using its external IP address (גישה לנקודת הקצה של מישור הבקרה של האשכול באמצעות כתובת ה-IP החיצונית שלה).
  
  אם משתמשים באפשרות הזו, רמת הגישה למישור הבקרה מוגדרת כ-Public endpoint access disabled. הפעולה הזו מונעת גישה למישור הבקרה מכל מקום באינטרנט.

gcloud

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

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

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

‫(סביבות עם PSC) --connection-subnetwork מציין טווח לרשת המשנה של החיבור ל-Managed Airflow, שמארחת את נקודת הקצה של ה-PSC.
(סביבות עם קישור בין רשתות 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.
  
  אם משתמשים באפשרות הזו, רמת הגישה למישור הבקרה מוגדרת ל-Public endpoint access disabled. כך מונעים כל גישה מהאינטרנט למישור הבקרה.
הארגומנטים --enable-master-authorized-networks ו---master-authorized-networks מגדירים רשתות מורשות לסביבה שלכם.
--enable-privately-used-public-ips מגדיר כתובות IP ציבוריות בשימוש פרטי לסביבה שלכם.
--enable-ip-masq-agent מפעיל את סוכן הסתרת ה-IP.

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.17-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 עם הטווח המשני של Pods.
‫SERVICES_RANGE עם הטווח המשני של השירותים.
‫CONTROL_PLANE_RANGE עם הטווח המשני של מישור הבקרה של GKE.
‫COMPOSER_PSC_RANGE עם הטווח של רשת המשנה של חיבור Managed Airflow.

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

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

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

המסוף

בדף Create environment:

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

gcloud

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

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.17-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.17-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 range, מציינים טווח IP בסימון CIDR. בשדה Description, מציינים תיאור אופציונלי לטווח הזה. אם רוצים לציין יותר מטווח אחד, לוחצים על Add IP range.
- כדי לחסום את הגישה לכל כתובות ה-IP, בוחרים באפשרות Allow access only from specific IP addresses ולוחצים על Delete item ליד הרשומה הריקה של הטווח.

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.17-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.17-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 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.17-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.17-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 בבלוק 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 (דור 2) הם בימים שישי, שבת וראשון בכל שבוע, בין השעות 00:00:00 ל-04:00:00 (שעון גריניץ').

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

המסוף

בדף Create environment

מוצאים את הקטע חלונות זמן לתחזוקה.
בתפריט הנפתח 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.17-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 עם 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-2.17.17-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. (אופציונלי) שילוב של שושלת נתונים

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

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

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

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

אזהרה: אחרי שמפעילים את Data Lineage API, קטלוג Knowledge מתחיל להטמיע נתונים באופן אוטומטי בשביל BigQuery, ‏Cloud Data Fusion ו-Managed Service for Apache Spark. זה קורה גם אם לא יוצרים סביבת Managed Airflow עם שילוב של שושלת נתונים.
אפשר להגדיר את ההטמעה של שושלת הנתונים כדי להפעיל או להשבית את ההטמעה האוטומטית של שושלת הנתונים ב-BigQuery או ב-Managed Service for Apache Spark.
לא מוגדר 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.17-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.17-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 יוצר באופן אוטומטי קטגוריה לסביבה.

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

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

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

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

המסוף

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

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

gcloud

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-2.17.17-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.17-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