עדכון סביבות Managed Airflow

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

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

מידע על פעולות עדכון

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

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

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

חשוב: אל תשדרגו את אשכולות GKE של סביבות Managed Airflow לגרסאות חדשות יותר של GKE. משתמשים בגרסת GKE שהוגדרה מראש במהלך יצירת הסביבה ומסתמכים על שדרוגים אוטומטיים שמבוצעים על ידי שירות GKE.

איך עדכונים משפיעים על משימות Airflow שפועלות

זהירות: חלק מפעולות העדכון מפסיקות את כל המשימות שפועלות.

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

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

השינויים הבאים גורמים לסיום של משימת Airflow:

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

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

השינויים הבאים לא גורמים לסיום של משימת Airflow:

• יצירה, עדכון או מחיקה של DAG (לא פעולת עדכון).
• השהיה או ביטול השהיה של DAG (לא פעולת עדכון).
• שינוי משתני Airflow (לא פעולת עדכון).
• שינוי חיבורי Airflow (לא פעולת עדכון).
• הפעלה או השבתה של השילוב של Knowledge Catalog Data Lineage.
• שינוי הגודל של הסביבה.
• שינוי מספר המתזמנים.
• שינוי המעבד (CPU), הזיכרון או האחסון של מתזמני Airflow.
• שינוי מספר הטריגרים.
• שינוי המעבד (CPU), הזיכרון או האחסון של טריגרים של Airflow.
• שינוי המעבד (CPU), הזיכרון או האחסון של שרת האינטרנט של Airflow.
• הגדלה או הקטנה של המספר המינימלי של העובדים.
• הקטנת המספר המקסימלי של עובדי Airflow. לדוגמה, אם בסביבה מסוימת פועלים כרגע שני עובדים, והמקסימום הופחת לשלושה.
• שינוי חלונות זמן לתחזוקה.
• שינוי ההגדרות של תמונות המצב המתוזמנות.
• שינוי תוויות של סביבות.

עדכון באמצעות Terraform

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

מריצים את הפקודה terraform plan לפני terraform apply כדי לבדוק אם Terraform יוצר סביבה חדשה במקום לעדכן את הסביבה הקיימת.

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

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

  • לחשבון שלכם צריך להיות תפקיד שיכול להפעיל פעולות של עדכון סביבה.

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

• הפקודה gcloud composer environments update מסתיימת כשהפעולה מסתיימת. אפשר להשתמש בדגל --async כדי לא לחכות לסיום הפעולה.

עדכון סביבות

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

• שינוי אפשרויות ההגדרה של Airflow
• הגדרה של משתני סביבה
• התקנת יחסי תלות של Python

• התאמה לעומס (scale) של סביבות

הצגת פרטי הסביבה

המסוף

1. במסוף Google Cloud , עוברים לדף Environments.

   מעבר אל Environments

2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details ייפתח.

gcloud

מריצים את הפקודה הבאה gcloud:

gcloud composer environments describe ENVIRONMENT_NAME \
  --location LOCATION

מחליפים את:

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

API

יוצרים בקשת API של environments.get.

דוגמה:

GET https://composer.googleapis.com/v1/projects/example-project/
locations/us-central1/environments/example-environment

Terraform

מריצים את הפקודה terraform state show בשביל המשאב של הסביבה.

יכול להיות שהשם של משאב Terraform בסביבה שלכם יהיה שונה מהשם של הסביבה.

terraform state show google_composer_environment.RESOURCE_NAME

מחליפים את:

• ‫RESOURCE_NAME בשם המשאב של הסביבה.

ביטול שינויים בעדכון

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

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

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

במצב כזה, מומלץ לחזור על הפעולה.

משך פעולות העדכון או השדרוג

משך הזמן של פעולות עדכון ושדרוג מושפע מהגורמים הבאים:

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

  מומלץ לשמור רק קובצי DAG וקובצי פלאגין בתיקיות /dags ו-/plugins (בהתאמה) ולהסיר את כל הקבצים האחרים. יותר מדי נתונים בתיקיות /dags ו-/plugins עלולים להאט את האתחול של רכיבי Airflow, ובמקרים מסוימים יכול להיות שהאתחול לא יתאפשר.

  מומלץ לשמור פחות מ-30MB של נתונים בתיקיות /dags ו-/plugins, ובכל מקרה לא לחרוג מגודל נתונים של 100MB. מידע נוסף זמין במאמר בנושא טיפול במספר גדול של DAG ותוספים

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

שדרוג סוג המכונה לצמתים של GKE

אפשר לשדרג ידנית את סוג המכונה עבור אשכול GKE של הסביבה על ידי מחיקת default-pool קיים ויצירת default-pool חדש עם סוג המכונה הרצוי.

מומלץ לציין סוג מכונה מתאים לסוג המחשוב שמתבצע בסביבת Managed Airflow כשיוצרים סביבה.

אם אתם מריצים משימות שמבצעות חישובים עתירי משאבים, כדאי להשתמש ב-GKE Operators.

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

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

המסוף

כדי לשדרג את סוג המכונה:

1. במסוף Google Cloud , עוברים לדף Environments.

   מעבר אל Environments

2. ברשימת הסביבות, לוחצים על שם הסביבה. הדף Environment details ייפתח.

3. קבלת מידע על מאגר הצמתים שמוגדר כברירת מחדל:

   1. עוברים לכרטיסייה Environment configuration (הגדרת הסביבה).

   2. לוחצים על הקישור הצגת פרטי האשכול.

   3. בדף Clusters (אשכולות) בקטע Nodes (צמתים), לוחצים על default-pool (מאגר ברירת המחדל).

   4. בדף 'פרטי מאגר הצמתים' רושמים את כל הפרטים של default-pool. אתם משתמשים במידע הזה כדי ליצור מאגר צמתים חדש שמוגדר כברירת מחדל לסביבה שלכם.

4. כדי למחוק את default-pool:

   1. בדף Node pool details (פרטי מאגר הצמתים), לוחצים על חץ החזרה כדי לחזור לדף Clusters (אשכולות) של הסביבה.

   2. בקטע Node Pools (מאגרי צמתים), לוחצים על סמל האשפה של default-pool (מאגר ברירת המחדל). לוחצים על מחיקה כדי לאשר את הפעולה.

5. כדי ליצור את default-pool החדש:

   זהירות: צריך להשתמש באותו חשבון שירות שמריץ את סביבת Managed Airflow. אם אתם משתמשים בחשבון שירות בהתאמה אישית ומסתמכים על היקפי גישה, אתם צריכים להשתמש ב-CLI של gcloud כדי ליצור מאגר חדש עם היקפי גישה מתאימים. כדי לעשות זאת, פועלים לפי ההוראות בדף הוספה וניהול של מאגרי צמתים. מציינים את היקפי הגישה באמצעות הפרמטר --scopes.

   1. בדף Clusters (אשכולות), לוחצים על Add node pool (הוספת מאגר צמתים).

   2. בשדה Name (שם), מזינים default-pool. אתם צריכים להשתמש בשם default-pool כדי שתהליכי העבודה בסביבה שלכם יוכלו לפעול במאגר הזה.

   3. מזינים את ההגדרות של Size (גודל) ו-Nodes (צמתים).

   4. (רק לחשבונות שירות שמשמשים כברירת המחדל של Compute Engine) בקטע Access scopes (היקפי גישה), בוחרים באפשרות Allow full access to all Cloud APIs (מתן גישה מלאה לכל ממשקי Cloud API).

   5. לוחצים על Save.

6. אם שמתם לב שעומסי העבודה מחולקים בצורה לא אחידה, צמצמו את הפריסה של airflow-worker לאפס והגדילו אותה שוב.

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

• שדרוג סביבות
• שינוי אפשרויות ההגדרה של Airflow