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

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

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

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

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

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

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

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

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

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

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

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

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

  3. אם בסביבה שלכם מוגדרות הגבלות על מיקום המשאבים, או אם אתם מתקינים חבילות 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. בתפריט הנפתח גרסת תמונה, בוחרים Managed Airflow image עם הגרסה הנדרשת של 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.iam.gserviceaccount.com
"

API

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

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

מחליפים את:

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

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

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

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

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

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

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

דוגמה:

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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "imageVersion": "composer-1.20.12-airflow-1.10.15"
    },
    "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-1.20.12-airflow-1.10.15"
    }
    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

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

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

המסוף

בדף Create environment:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    גודל הדיסק, ב-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.iam.gserviceaccount.com
" \
    --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.iam.gserviceaccount.com
"
    },
    "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 מציין את סוג המכונה של מכונות וירטואליות של צמתים. כשמציינים את השדה הזה, צריך לציין גם תחום (zone) של 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.iam.gserviceaccount.com
"
    }

    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 peerings). בהגדרה הזו, הסביבה שלכם משתמשת בקישור של רשתות VPC לקישוריות.

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

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

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

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

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

      • טווח IP משני ל-pods
      • טווח IP משני לשירותים

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

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

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

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

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

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

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

      • טווח IP משני ל-pods
      • טווח IP משני לשירותים

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

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

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

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

המסוף

כדי ליצור סביבת כתובות 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. בקטע Service IP Address Allocation (הקצאת כתובות IP לשירותים), מציינים את טווח כתובות ה-IP המשני לשירותים. אפשר להשתמש בטווח משני קיים ברשת ה-VPC או לציין טווח חדש בסימון CIDR.

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

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

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

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

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

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

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

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

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

  11. בקטע Web Server private IP (כתובת 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 מגדירים את הטווח המשני של ה-pods.

  • ‫--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.

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

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

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

  • הארגומנטים --enable-master-authorized-networks ו---master-authorized-networks מגדירים רשתות מורשות לסביבה שלכם.

  • ‫--enable-privately-used-public-ips מגדיר כתובות IP ציבוריות לשימוש פרטי בסביבה שלכם.

  • --enable-ip-masq-agent מפעיל את סוכן ה-IP Masquerade.

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

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

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

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

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

המסוף

בדף Create environment, בקטע הגדרת שרת אינטרנט:

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

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

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

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

}

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

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

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

רשימת אפשרויות ההגדרה הזמינות של Airflow מופיעה במאמר Configuration reference for Airflow 2 (הפניה להגדרות של Airflow 2) ובמאמר Airflow 1.10.* (הפניה להגדרות של 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.iam.gserviceaccount.com
" \
    --env-variables SENDGRID_MAIL_FROM=user@example.com,SENDGRID_API_KEY=example-key \
    --airflow-configs core-dags_are_paused_at_creation=True,webserver-dag_orientation=TB

API

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

{
  "name": "projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_NAME",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "SECTION-KEY": "OVERRIDE_VALUE"
      },
      "envVariables": {
        "VAR_NAME": "VAR_VALUE",
      }
    },
    "nodeConfig": {
      "serviceAccount": "SERVICE_ACCOUNT"
    }
  }
}

מחליפים את:

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

דוגמה:

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

{
  "name": "projects/example-project/locations/us-central1/environments/example-environment",
  "config": {
    "softwareConfig": {
      "airflowConfigOverrides": {
        "core-dags_are_paused_at_creation": "True",
        "webserver-dag_orientation": "TB"
      },
      "envVariables": {
        "SENDGRID_MAIL_FROM": "user@example.com",
        "SENDGRID_API_KEY": "example-key"
      }
    },
    "nodeConfig": {
        "serviceAccount": "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

Terraform

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

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

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

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

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

  config {

    software_config {

      airflow_config_overrides = {
        SECTION-KEY = "OVERRIDE_VALUE"
      }

      env_variables = {
        VAR_NAME = "VAR_VALUE"
      }
    }

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }

  }
}

מחליפים את:

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

דוגמה:

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

  config {

    software_config {

      airflow_config_overrides = {
        core-dags_are_paused_at_creation = "True"
        webserver-dag_orientation = "TB"
      }

      env_variables = {
        SENDGRID_MAIL_FROM = "user@example.com"
        SENDGRID_API_KEY = "example-key"
      }
    }

    node_config {
      service_account = "
example-account@example-project.iam.gserviceaccount.com
"
    }
  }
}

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

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

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

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

המסוף

בדף Create environment:

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

  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.iam.gserviceaccount.com
" \
  --maintenance-window-start '2023-01-01T01:00:00Z' \
  --maintenance-window-end '2023-01-01T07:00:00Z' \
  --maintenance-window-recurrence 'FREQ=WEEKLY;BYDAY=SU,WE,SA'

API

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

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

מחליפים את:

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

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

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

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

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

דוגמה:

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

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

Terraform

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

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

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

    node_config {
      service_account = "SERVICE_ACCOUNT"
    }
  }
}

מחליפים את:

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

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

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

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

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

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

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

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

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

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

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

המסוף

בדף Create environment:

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

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

}

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

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

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

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

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

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

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

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

  • גרסת Python

    אם בסביבה שלכם נעשה שימוש ב-Airflow 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.iam.gserviceaccount.com
" \
    --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.iam.gserviceaccount.com
"
    },
    "softwareConfig": {
        "pythonVersion": "3"
    }
  }
}

Terraform

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

  • השדה zone בבלוק node_config מציין אזור 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.iam.gserviceaccount.com
"
    }
    software_config {
      python_version = "3"
    }
  }
}

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

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

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