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

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

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

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

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

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

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

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

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

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

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

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

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

  3. אם בסביבה שלכם מוגדרות הגבלות על מיקום המשאבים, או אם מותקנים חבילות PyPI ממאגר Artifact Registry או ממאגר פרטי, צריך להעניק את התפקיד Service Account User (iam.serviceAccountUser) לחשבון השירות בניהול המשתמש שמריץ את הסביבה בעצמו (הגורם המורשה והמשאב הם אותו חשבון שירות).

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

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

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

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

המסוף

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

    כניסה לדף Create environment

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

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

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

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

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

  5. בקטע Node configuration, ברשימה הנפתחת 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-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
"

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-1.20.12-airflow-1.10.15"
    },
    "nodeConfig": {
      "serviceAccount": "
example-account@example-project.
"
    }
  }
}

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-1.20.12-airflow-1.10.15"
    }
    node_config {
      service_account = "
example-account@example-project.
"
    }
  }
}

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

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

המסוף

בדף Create environment:

  1. בקטע Node configuration:

    • מזינים את מספר הצמתים.

      מספר הצמתים הוא מספר הצמתים של Google Kubernetes Engine באשכול של הסביבה. כברירת מחדל, בסביבות יש 3 צמתים.

      אפשר לשנות את הערך הזה אחרי שיוצרים את הסביבה.

    • בוחרים את האפשרות Machine type לצמתים.

      סוג המכונה של הצמתים הוא סוג המכונה של Compute Engine שמשמש למכונות של האשכול. הפרמטר הזה קובע את מספר המעבדים ואת כמות הזיכרון של הסביבה. סוג ברירת המחדל של המכונה הוא n1-standard-1.

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

    • מזינים את גודל הדיסק.

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

      הגודל המינימלי הוא 30GB. גודל ברירת המחדל הוא 100GB. אי אפשר לשנות את הפרמטר הזה אחרי שיוצרים סביבה.

    • בוחרים את מספר המתזמנים.

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

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

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

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

  2. מרחיבים את הפריט Networking, Airflow config overrides, and additional features (רשת, ביטול הגדרות ברירת המחדל של Airflow ותכונות נוספות).

  3. בקטע Cloud SQL configuration (הגדרת Cloud SQL), בוחרים באפשרות Cloud SQL machine type (סוג המכונה של Cloud SQL).

    הפרמטר הזה קובע את סוג המכונה של מכונת Cloud SQL שמריצה את מסד הנתונים של Airflow. סוג המכונה שמוגדר כברירת מחדל ב-Cloud SQL הוא db-n1-standard-2.

  4. בקטע Web server configuration (הגדרת שרת האינטרנט), בוחרים באפשרות Web server machine type (סוג המכונה של שרת האינטרנט).

    הפרמטר הזה קובע את סוג המכונה של Compute Engine שמריצה את שרת האינטרנט של Airflow.

    סוג המכונה שמוגדר כברירת מחדל לשרת אינטרנט הוא composer-n1-webserver-2.

gcloud

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

  • ‫--node-count מציין את מספר הצמתים בסביבה.

    מספר הצמתים הוא מספר הצמתים של Google Kubernetes Engine באשכול של הסביבה. כברירת מחדל, בסביבות יש 3 צמתים.

    אפשר לשנות את הערך הזה אחרי שיוצרים את הסביבה.

  • --scheduler-count מציין את מספר המתזמנים בסביבה שלכם.

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

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

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

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

  • ‫--disk-size מציין את גודל הדיסק למכונות וירטואליות של סביבות.

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

    הגודל המינימלי הוא 30GB. גודל ברירת המחדל הוא 100GB. אי אפשר לשנות את הפרמטר הזה אחרי שיוצרים סביבה.

  • ‫--machine-type מציין את סוג המכונה של המכונות הווירטואליות של הצמתים.

    סוג המכונה של הצמתים הוא סוג המכונה של Compute Engine שמשמש למכונות של האשכול. הפרמטר הזה קובע את מספר המעבדים ואת כמות הזיכרון של הסביבה. סוג ברירת המחדל של המכונה הוא n1-standard-1.

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

  • ‫--cloud-sql-machine-type מציין את סוג המכונה של Cloud SQL.

    הפרמטר הזה קובע את סוג המכונה של מכונת Cloud SQL שמריצה את מסד הנתונים של Airflow. סוג המכונה שמוגדר כברירת מחדל ב-Cloud SQL הוא db-n1-standard-2.

  • ‫--web-server-machine-type מציין את סוג המכונה של מכונת שרת האינטרנט של Airflow.

    הפרמטר הזה קובע את סוג המכונה של מופע Compute Engine שמריץ את שרת האינטרנט של Airflow.

    סוג המכונה שמוגדר כברירת מחדל לשרת האינטרנט הוא composer-n1-webserver-2. 

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --service-account "SERVICE_ACCOUNT" \
    --zone NODE_ZONE \
    --node-count NODE_COUNT \
    --scheduler-count SCHEDULER_COUNT \
    --disk-size DISK_SIZE \
    --machine-type NODE_MACHINE_TYPE \
    --cloud-sql-machine-type SQL_MACHINE_TYPE \
    --web-server-machine-type WS_MACHINE_TYPE

מחליפים את:

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
" \
    --zone us-central1-a \
    --node-count 6 \
    --scheduler-count 1 \
    --disk-size 50 \
    --machine-type n1-standard-2 \
    --cloud-sql-machine-type db-n1-standard-2 \
    --web-server-machine-type composer-n1-webserver-2

API

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

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeCount": NODE_COUNT,
    "nodeConfig": {
      "machineType": "NODE_MACHINE_TYPE",
      "diskSizeGb": DISK_SIZE,
      "serviceAccount": "SERVICE_ACCOUNT"
    },
    "softwareConfig": {
      "schedulerCount": SCHEDULER_COUNT
    },
    "databaseConfig": {
      "machineType": "SQL_MACHINE_TYPE"
    },
    "webServerConfig": {
      "machineType": "WS_MACHINE_TYPE"
    }
  }
}

מחליפים את:

דוגמה:


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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeCount": 6,
    "nodeConfig": {
      "machineType": "projects/example-project/zones/us-central1-a/machineTypes/n1-standard-2",
      "diskSizeGb": 50,
      "serviceAccount": "
example-account@example-project.
"
    },
    "softwareConfig": {
      "schedulerCount": 1
    },
    "databaseConfig": {
      "machineType": "db-n1-standard-2"
    },
    "webServerConfig": {
      "machineType": "composer-n1-webserver-2"
    }
  }
}

Terraform

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

  • ‫node_count בבלוק node_config מציין את מספר הצמתים בסביבה.

    מספר הצמתים הוא מספר הצמתים של Google Kubernetes Engine באשכול של הסביבה. כברירת מחדל, בסביבות יש 3 צמתים.

    אפשר לשנות את הערך הזה אחרי שיוצרים את הסביבה.

  • ‫disk_size_gb בבלוק node_config מציין את גודל הדיסק של מכונות ה-VM בסביבה.

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

    הגודל המינימלי הוא 30GB. גודל ברירת המחדל הוא 100GB. אי אפשר לשנות את הפרמטר הזה אחרי שיוצרים סביבה.

  • השדה machine_type בבלוק node_config מציין את סוג המכונה של המכונות הווירטואליות של הצמתים. כשמציינים את השדה הזה, צריך גם לציין אזור ב-Compute Engine למכונות הווירטואליות של הסביבה בשדה zone.

    סוג המכונה של הצמתים הוא סוג המכונה של Compute Engine שמשמש למכונות של האשכול. הפרמטר הזה קובע את מספר המעבדים ואת כמות הזיכרון של הסביבה. סוג המכונה שמוגדר כברירת מחדל הוא n1-standard-1.

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

  • ‫machine_type בבלוק database_config מציין את סוג המכונה של מכונת Cloud SQL.

    הפרמטר הזה קובע את סוג המכונה של מכונת Cloud SQL שמריצה את מסד הנתונים של Airflow. סוג המכונה שמוגדר כברירת מחדל ב-Cloud SQL הוא db-n1-standard-2.

  • ‫machine_type בבלוק web_server_config מציין את סוג המכונה של מופע שרת האינטרנט של Airflow.

    הפרמטר הזה קובע את סוג המכונה של Compute Engine שמריצה את שרת האינטרנט של Airflow.

    סוג המכונה שמוגדר כברירת מחדל לשרת האינטרנט הוא composer-n1-webserver-2.

  • השדה scheduler_count בבלוק software_config מציין את מספר המתזמנים בסביבה שלכם. הסביבה שלכם צריכה להשתמש ב-Airflow 2.

resource "google_composer_environment" "example" {
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      node_count = NODE_COUNT
      disk_size_gb = DISK_SIZE
      machine_type = "NODE_MACHINE_TYPE"
      zone = "NODE_ZONE"
      service_account = "SERVICE_ACCOUNT"
    }

    software_config {
      scheduler_count = SCHEDULER_COUNT
    }

    database_config {
      machine_type = "SQL_MACHINE_TYPE"
    }

    web_server_config {
      machine_type = "WS_MACHINE_TYPE"
    }
  }
}

מחליפים את:

דוגמה:

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

  config {

    node_config {
      node_count = 4
      disk_size_gb = 100
      zone = "us-central1-a"
      machine_type = "n1-standard-2"
      service_account = "
example-account@example-project.
"
    }

    software_config {
      scheduler_count = 2
    }

    database_config {
      machine_type = "db-n1-standard-2"
    }

    web_server_config {
      machine_type = "composer-n1-webserver-2"
    }
  }
}

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

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

  • סביבת כתובת IP ציבורית. משתמשים בפרמטרים של ברירת המחדל של הרשת.

  • סביבת כתובת IP פרטית (קישורי VPC). בהגדרה הזו, הסביבה שלכם משתמשת בחיבורי VPC לצורך קישוריות.

    הגדרת סביבת כתובת IP פרטית:

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

    בסביבת כתובות IP פרטיות עם קישורים בין רשתות שכנות של VPC, צריך לדעת:

    • מזהה רשת ה-VPC שלכם
    • מזהה רשת המשנה של ה-VPC

    • שני טווחי כתובות IP משניים ברשת המשנה של ה-VPC:

      • טווח כתובות IP משני לפודים
      • טווח כתובות IP משני לשירותים

    • טווחי כתובות ה-IP של רכיבי הסביבה:

      • טווח כתובות ה-IP למישור הבקרה של GKE.
      • טווח כתובות ה-IP של שרת האינטרנט.
      • טווח כתובות ה-IP של המכונה ב-Cloud SQL.

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

    בסביבת VPC משותף, צריך לדעת:

    • מזהה רשת ה-VPC של הפרויקט המארח

    • מזהה רשת המשנה של ה-VPC בפרויקט המארח

    • שני טווחי כתובות IP משניות ברשת המשנה של ה-VPC בפרויקט המארח:

      • טווח כתובות IP משני לפודים
      • טווח כתובות IP משני לשירותים

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

  • כדי ליצור סביבת VPC SC, צריך ליצור גבולות גזרה לשירות ואז ליצור סביבות של כתובות IP פרטיות בתוך גבולות הגזרה האלה. פועלים לפי ההוראות במאמר הגדרת VPC Service Controls.

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

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

המסוף

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

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

  2. מרחיבים את הפריט Networking, Airflow config overrides, and additional features (רשת, ביטול הגדרות ברירת המחדל של Airflow ותכונות נוספות).

  3. בקטע Network configuration, מסמנים את התיבה Enable VPC-native (using alias-IP).

  4. ברשימה הנפתחת Network, בוחרים את מזהה רשת ה-VPC.

  5. ברשימה הנפתחת Subnetwork, בוחרים את המזהה של רשת המשנה של ה-VPC.

  6. בקטע Pod IP Address Allocation, מציינים את טווח כתובות ה-IP המשני של הפודים. אפשר להשתמש בטווח משני קיים ברשת ה-VPC, או לציין טווח חדש בסימון CIDR.

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

  8. בקטע Private IP, מסמנים את התיבה Enable private IP.

  9. בקטע GKE cluster master private IP, מציינים טווח כתובות IP למישור הבקרה של GKE:

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

    • כדי לציין טווח כתובות IP בהתאמה אישית, בוחרים באפשרות Custom IP range ומזינים טווח בסימון CIDR בשדה GKE cluster master private IP.

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

    • כדי לאפשר גישה לנקודת הקצה הציבורית מרשתות מורשות, מסמנים את התיבה Access master endpoint using its external IP address.

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

    • כדי להשבית את הגישה לנקודת הקצה הציבורית מרשתות מורשות, מבטלים את הסימון בתיבה Access master endpoint using its external IP address (גישה לנקודת הקצה הראשית באמצעות כתובת ה-IP החיצונית שלה).

      אם משתמשים באפשרות הזו, רמת הגישה למישור הבקרה מוגדרת ל-Public endpoint access disabled. הפעולה הזו מונעת גישה למישור הבקרה מכל מקום באינטרנט.

  11. בקטע Web Server private IP, מציינים טווח IP למכונה של שרת האינטרנט של Airflow.

  12. בקטע Cloud SQL private IP, מציינים טווח של כתובות IP למכונה של Cloud SQL.

gcloud

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

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

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

  • ‫--enable-ip-alias מפעילים את VPC Native באמצעות כתובות IP של כינוי.

    הפרמטר הזה נדרש כשמשתמשים ב---enable-private-environment או כשמגדירים טווחים משניים לפודים ולשירותים.

  • ‫--network הוא מזהה רשת ה-VPC.

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

  • ‫--cluster-secondary-range-name או --cluster-ipv4-cidr מגדירים את הטווח המשני של הפודים.

  • ‫--services-secondary-range-name או --services-ipv4-cidr כדי להגדיר את הטווח המשני לשירותים.

  • ‫--master-ipv4-cidr מציין טווח למישור הבקרה של GKE.

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

  • ‫--cloud-sql-ipv4-cidr מציין טווח למכונה של Cloud SQL.

  • ‫--enable-private-endpoint שולט ברמת הגישה למישור הבקרה של GKE. למישור הבקרה יש שתי נקודות קצה. נקודת קצה אחת היא פרטית, לשימוש על ידי צומתי אשכולות ומכונות וירטואליות. נקודת קצה אחרת היא ציבורית. אפשר לציין את רמת הגישה לנקודת הקצה הציבורית:

    • כדי לאפשר גישה לנקודת הקצה הציבורית מרשתות מורשות, משמיטים את הארגומנט --enable-private-endpoint.

      אם משתמשים באפשרות הזו, רמת הגישה למישור הבקרה מוגדרת ל-Public endpoint access enabled, authorized networks enabled. הגישה למישור הבקרה מוגבלת לרשתות מורשות. כברירת מחדל, לא מצוינות כתובות 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-1.20.12-airflow-1.10.15 \
    --service-account "SERVICE_ACCOUNT" \
    --enable-private-environment \
    --enable-ip-alias \
    --network NETWORK_ID \
    --subnetwork SUBNETWORK_ID \
    --cluster-ipv4-cidr PODS_RANGE \
    --services-ipv4-cidr SERVICES_RANGE \
    --master-ipv4-cidr CONTROL_PLANE_RANGE \
    --web-server-ipv4-cidr WEB_SERVER_RANGE \
    --cloud-sql-ipv4-cidr SQL_RANGE

מחליפים את:

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

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

  • PODS_RANGE עם הטווח המשני של תרמילים.

  • ‫SERVICES_RANGE עם הטווח המשני לשירותים.

  • ‫CONTROL_PLANE_RANGE עם הטווח המשני למישור הבקרה של GKE.

  • ‫WEB_SERVER_RANGE מחליפים בטווח המשני של מכונת שרת האינטרנט של Airflow.

  • ‫SQL_RANGE עם הטווח של מכונת Cloud SQL.

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

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

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

המסוף

בדף Create environment:

  1. מאתרים את הקטע Node configuration.
  2. בשדה Tags, מציינים תגי מכונה למכונות הווירטואליות של הצמתים.

gcloud

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

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

מחליפים את:

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

דוגמה:

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

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

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

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

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

המסוף

בדף Create environment, בקטע Web server configuration:

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

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

  • כדי לחסום את הגישה לכל כתובות ה-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-1.20.12-airflow-1.10.15 \
    --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-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
" \
    --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.
"
    }
  }
}

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

}

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

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

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

רשימת אפשרויות ההגדרה של Airflow מופיעה במאמרים הפניית הגדרה ל-Airflow 2 ו-Airflow 1.10.*‎.

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

המסוף

בדף Create environment:

  1. מרחיבים את הפריט Networking, Airflow config overrides, and additional features (רשת, ביטול הגדרות ברירת המחדל של Airflow ותכונות נוספות).

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

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

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

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

    לדוגמה:

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

gcloud

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

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

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

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

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --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-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
" \
    --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.
"
    }
  }
}

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

שלב 8. (אופציונלי) הגדרת חלונות זמן לתחזוקה

כברירת מחדל, בסביבות Managed Airflow (דור קודם, דור ראשון) לא מוגדרים חלונות זמן לתחזוקה אם יוצרים אותן באמצעות מסוףGoogle Cloud , ‏ API או Terraform. מומלץ לציין חלונות זמן לתחזוקה בסביבות חדשות וקיימות.

אם אתם יוצרים את הסביבה באמצעות ה-CLI של gcloud, חלונות הזמן לתחזוקה שמוגדרים כברירת מחדל הם בימי שישי, שבת וראשון בכל שבוע, בין השעות 00:00:00 ל-04:00:00 (לפי שעון גריניץ').

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

המסוף

בדף Create environment:

  1. מרחיבים את הפריט Networking, Airflow config overrides, and additional features.

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

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

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

gcloud

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

  • --maintenance-window-start מגדיר את שעת ההתחלה של חלון הזמן לתחזוקה.
  • --maintenance-window-end מגדיר את שעת הסיום של חלון הזמן לתחזוקה.
  • ‫--maintenance-window-recurrence מגדיר את החזרה של חלון הזמן לתחזוקה.
gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --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-1.20.12-airflow-1.10.15 \
  --service-account "
example-account@example-project.
" \
  --maintenance-window-start '2023-01-01T01:00:00Z' \
  --maintenance-window-end '2023-01-01T07:00:00Z' \
  --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SU,WE,SA'

API

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

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

מחליפים את:

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

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

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

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

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

דוגמה:

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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "maintenanceWindow": {
        "startTime": "2023-01-01T01:00:00Z",
        "endTime": "2023-01-01T07:00:00Z",
        "recurrence": "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

Terraform

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

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

  config {
    maintenance_window {
      start_time = "DATETIME_START"
      end_time = "DATETIME_END"
      recurrence = "MAINTENANCE_RECURRENCE"
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

מחליפים את:

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

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

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

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

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

  config {
    maintenance_window {
      start_time = "2023-01-01T01:00:00Z"
      end_time = "2023-01-01T07:00:00Z"
      recurrence = "FREQ=WEEKLY;BYDAY=SU,WE,SA"
    }
  }
}

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

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

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

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

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

המסוף

בדף Create environment:

  1. מרחיבים את הפריט Networking, Airflow config overrides, and additional features.

  2. בקטע תוויות, לוחצים על הוספת תווית.

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

gcloud

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

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

מחליפים את:

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

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
" \
    --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"
  }

}

שלב 11. (אופציונלי) הגדרת פרמטרים אחרים

פרמטרים נוספים:

  • האזור של צומתי הסביבה

    האזור ב-Compute Engine שבו פורסים את צומתי האשכול. בפרמטר הזה אפשר לבחור אזור ספציפי במיקום של הסביבה.

    כברירת מחדל, המערכת בוחרת אזור אקראי באופן אוטומטי.

  • היקפי ההרשאות של OAuth

    היקפי ההרשאות של OAuth הם קבוצה של היקפי הרשאות של Google API שיהיו זמינים בכל המכונות הווירטואליות של הצמתים. אם השדה ריק, ברירת המחדל היא https://www.googleapis.com/auth/cloud-platform.

    אם אתם מציינים היקפי הרשאות של OAuth בהתאמה אישית, צריך לכלול את https://www.googleapis.com/auth/cloud-platform ברשימת ההיקפים שצוינו.

  • גרסת Python

    אם בסביבה שלכם מותקנת גרסה 1.10.* ‎ של Airflow או גרסאות קודמות, אתם יכולים להגדיר שהסביבה תשתמש ב-Python 2. גרסת ברירת המחדל של Python היא Python 3. מידע נוסף על התמיכה ב-Python 2 ב-Managed Airflow זמין במאמר גרסאות Python נתמכות.

המסוף

בדף Create environment:

  1. בקטע Node configuration (הגדרת הצומת):

    • בתפריט הנפתח Zone, בוחרים את התחום של צמתי הסביבה.

      אי אפשר לשנות את האזור אחר כך.

    • בשדה OAuth Scopes (היקפי הרשאות של OAuth), מציינים את היקפי ההרשאות של OAuth למכונות וירטואליות של צמתים.

      אי אפשר לשנות את היקפי ההרשאות של OAuth בשלב מאוחר יותר.

      כדי לציין כמה היקפי הרשאות של OAuth, צריך לספק רשימה של ערכים שמופרדים בפסיקים. כוללים את https://www.googleapis.com/auth/cloud-platform ברשימת ההיקפים שצוינו.

    • בשדה Python version (גרסת Python), בוחרים את גרסת Python.

      לא תוכלו לשנות את גרסת Python בהמשך.

gcloud

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

  • ‫--zone מציין תחום (zone) ב-Compute Engine למכונות הווירטואליות של הסביבה.

  • --oauth-scopes מציין רשימה מופרדת בפסיקים של היקפי ההרשאות של OAuth. כוללים את https://www.googleapis.com/auth/cloud-platform ברשימת ההיקפים שצוינו.

  • ‫--python-version מציין את גרסת Python.

gcloud composer environments create ENVIRONMENT_NAME \
    --location LOCATION \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --service-account "SERVICE_ACCOUNT" \
    --zone ZONE \
    --oauth-scopes OAUTH_SCOPES \
    --python-version PYTHON_VERSION

מחליפים את:

  • ZONE בשם של אזור Compute Engine.
  • ‫OAUTH_SCOPES עם רשימה מופרדת בפסיקים של היקפי הרשאות של OAuth.
  • ‫PYTHON_VERSION עם גרסת Python‏ (3 או 2).

דוגמה:

gcloud composer environments create example-environment \
    --location us-central1 \
    --image-version composer-1.20.12-airflow-1.10.15 \
    --service-account "
example-account@example-project.
" \
    --zone us-central1-a \
    --oauth-scopes https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/bigquery  \
    --python-version 3

API

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

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "nodeConfig": {
      "location": "projects/PROJECT_ID/zones/ZONE",
      "oauthScopes": [
        "OAUTH_SCOPE"
      ],
      "serviceAccount": "SERVICE_ACCOUNT"
    },
    "softwareConfig": {
        "pythonVersion": "PYTHON_VERSION"
    }
  }
}

מחליפים את:

  • ZONE בשם של אזור Compute Engine.
  • ‫OAUTH_SCOPE עם היקף הרשאות OAuth. כדי לציין היקפים נוספים, מוסיפים את ההיקף https://www.googleapis.com/auth/cloud-platform ואחריו את פריטי ההיקף הנוספים.
  • ‫PYTHON_VERSION עם גרסת Python‏ (3 או 2).

דוגמה:

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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "nodeConfig": {
      "location": "projects/example-project/zones/us-central1-a",
      "oauthScopes": [
        "https://www.googleapis.com/auth/cloud-platform",
        "https://www.googleapis.com/auth/bigquery"
      ],
      "serviceAccount": "
example-account@example-project.
"
    },
    "softwareConfig": {
        "pythonVersion": "3"
    }
  }
}

Terraform

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

  • השדה zone בבלוק node_config מציין תחום (zone) של Compute Engine למכונות הווירטואליות של הסביבה.

  • השדה oauth_scopes בבלוק node_config מציין רשימה מופרדת בפסיקים של היקפי הרשאות OAuth.

  • השדה python_version בבלוק software_config מציין את גרסת Python.

resource "google_composer_environment" "example" {
  name = "ENVIRONMENT_NAME"
  region = "LOCATION"

  config {

    node_config {
      zone = "ZONE"
      oauth_scopes = "[OAUTH_SCOPES]"
      service_account = "SERVICE_ACCOUNT"
    }

    software_config {
      python_version = "PYTHON_VERSION"
    }
  }
}

מחליפים את:

  • ZONE בשם של אזור Compute Engine.
  • ‫OAUTH_SCOPES עם רשימה מופרדת בפסיקים של היקפי הרשאות של OAuth.
  • ‫PYTHON_VERSION עם גרסת Python‏ (3 או 2).

דוגמה:

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

  config {
    node_config {
      zone = "us-central1-a"
      oauth_scopes = "[https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/bigquery]"
      service_account = "
example-account@example-project.
"
    }
    software_config {
      python_version = "3"
    }
  }
}

שלב 12. (אופציונלי) אכיפת השימוש ב-API בגרסת בטא

אתם יכולים להגדיר במפורש שהסביבה תשתמש בגרסת הבטא של Cloud Composer API, גם אם אין בה תכונות בגרסת טרום-השקה (Preview). אם תעשו זאת, הסביבה תיווצר באמצעות נקודת הקצה של השירות v1beta1.

המסוף

בדף Create environment:

  1. מרחיבים את הפריט Networking, Airflow config overrides, and additional features (רשת, ביטול הגדרות ברירת המחדל של Airflow ותכונות נוספות).

  2. בקטע Beta API, מסמנים את התיבה Enforce the usage of Beta API.

gcloud

יוצרים את הסביבה באמצעות הפקודה gcloud beta composer.

API

יוצרים את הסביבה באמצעות נקודת הקצה של שירות v1beta1.

Terraform

כברירת מחדל, ספק Terraform ל-Managed Airflow משתמש ב-API בגרסת בטא.

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