בדיקה של DAG ב-Airflow

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

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

בדיקת קובצי DAG באופן מקומי באמצעות כלי ה-CLI של Composer לפיתוח מקומי

כלי ה-CLI לפיתוח מקומי של Composer מייעל את הפיתוח של DAG ב-Apache Airflow עבור Managed Airflow (דור 2) על ידי הרצת סביבת Airflow באופן מקומי. בסביבת Airflow המקומית הזו נעשה שימוש בתמונה של גרסה ספציפית של Managed Airflow (דור 2).

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

בדיקה במהלך יצירת DAG

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

מומלץ להציב את ה-DAG בתיקייה data/test בסביבת הבדיקה.

יצירת ספריית בדיקה

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

gcloud storage cp BUCKET_NAME/dags \
  BUCKET_NAME/data/test --recursive

מחליפים את מה שכתוב בשדות הבאים:

  • BUCKET_NAME: השם של הקטגוריה שמשויכת לסביבת Managed Airflow.

דוגמה:

gcloud storage cp gs://us-central1-example-environment-a12bc345-bucket/dags \
  gs://us-central1-example-environment-a12bc345-bucket/data/test --recursive

מידע נוסף על העלאת DAGs זמין במאמר בנושא הוספה ועדכון של DAGs.

בדיקה של שגיאות תחביר

כדי לבדוק אם יש שגיאות תחביר ב-DAG שהעליתם לתיקייה /data/test, מזינים את הפקודה gcloud הבאה:

gcloud composer environments run \
  ENVIRONMENT_NAME \
  --location ENVIRONMENT_LOCATION \
  dags list -- --subdir /home/airflow/gcs/data/test

מחליפים את מה שכתוב בשדות הבאים:

  • ENVIRONMENT_NAME: שם הסביבה.
  • ENVIRONMENT_LOCATION: האזור שבו נמצאת הסביבה.

בדיקת שגיאות במשימות

כדי לבדוק אם יש שגיאות שקשורות למשימות ב-DAG שהעליתם לתיקייה /data/test, מריצים את הפקודה gcloud הבאה:

gcloud composer environments run \
  ENVIRONMENT_NAME \
  --location ENVIRONMENT_LOCATION \
  tasks test -- --subdir /home/airflow/gcs/data/test \
  DAG_ID TASK_ID \
  DAG_EXECUTION_DATE

מחליפים את מה שכתוב בשדות הבאים:

  • ENVIRONMENT_NAME: שם הסביבה.
  • ENVIRONMENT_LOCATION: האזור שבו נמצאת הסביבה.
  • DAG_ID: המזהה של ה-DAG.
  • TASK_ID: מזהה המשימה.
  • DAG_EXECUTION_DATE: תאריך ההפעלה של ה-DAG. התאריך הזה משמש למטרות יצירת תבניות. לא משנה איזה תאריך תציינו כאן, ה-DAG יפעל באופן מיידי.

דוגמה:

gcloud composer environments run \
  example-environment \
  --location us-central1 \
  tasks test -- --subdir /home/airflow/gcs/data/test \
  hello_world print_date 2021-04-22

עדכון ובדיקה של DAG שנפרס

כדי לבדוק עדכונים ל-DAG בסביבת הבדיקה:

  1. מעתיקים את ה-DAG שנפרס ורוצים לעדכן אל data/test.
  2. מעדכנים את ה-DAG.
  3. בודקים את ה-DAG.
    1. בודקים אם יש שגיאות תחביר.
    2. בודקים אם יש שגיאות שקשורות למשימה.
  4. מוודאים ש-DAG פועל בהצלחה.
  5. משביתים את ה-DAG בסביבת הבדיקה.
    1. עוברים לממשק המשתמש של Airflow > לדף DAGs.
    2. אם ה-DAG שאתם משנים פועל באופן קבוע, צריך להשבית אותו.
    3. כדי לזרז את הטיפול במשימות פתוחות, לוחצים על המשימה ואז על סימון שהמשימה בוצעה.
  6. פורסים את ה-DAG בסביבת הייצור.
    1. משביתים את ה-DAG בסביבת הייצור.
    2. מעלים את ה-DAG המעודכן לתיקייה dags/ בסביבת הייצור.

שאלות נפוצות לגבי בדיקת DAG

איך מבודדים הרצות של DAG בסביבות הייצור והבדיקה?

לדוגמה, ל-Airflow יש מאגר גלובלי של קוד מקור בתיקייה dags/ שמשותפת לכל ההרצות של DAG. רוצים לעדכן קוד מקור בסביבת ייצור או לבצע בדיקה בלי להפריע ל-DAGs שפועלים.

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

איך אפשר למנוע הפרעות ל-DAG כשמריצים בדיקות שילוב מענפים שונים ב-GitHub

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

מהי השיטה המומלצת לבדיקות שילוב עם Airflow?

מומלץ להשתמש בסביבה ייעודית לבדיקות שילוב עם Airflow. דרך אחת לסמן שהרצת ה-DAG הסתיימה בהצלחה היא לכתוב לקובץ בתיקייה ב-Cloud Storage ואז לבדוק את התוכן במקרים של בדיקות שילוב משלכם.

איך משתפים פעולה ביעילות עם תורמים אחרים ל-DAG?

לכל תורם יכולה להיות תיקיית משנה בתיקייה data/ לפיתוח.

מערכת Airflow לא מזהה באופן אוטומטי קובצי DAG שנוספו לתיקייה data/, וגם לא שרת האינטרנט שלה

משתמשים עם הרשאת כתיבה ב-DAG יכולים ליצור הפעלות ידניות של DAG באמצעות הפקודה gcloud composer environments run ופקודת המשנה test עם הדגל --subdir כדי לציין את ספריית הפיתוח של המשתמש.

לדוגמה:

gcloud composer environments run test-environment-name \
  tasks test -- dag-id task-id execution-date \
  --subdir /home/airflow/gcs/data/alice_dev

איך שומרים על סנכרון בין סביבות הפריסה והייצור?

כדי לנהל את הגישה:

כדי לפרוס מסביבת הפיתוח לסביבת הייצור:

  • מוודאים שההגדרות עקביות, למשל משתני סביבה וחבילות PyPI.

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

    לדוגמה:

    gcloud composer environments run test-environment-name \
      variables set -- DATA_ENDPOINT_KEY DATA_ENDPOINT_VALUE
    

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