הפעלת סביבת Airflow מקומית באמצעות כלי CLI לפיתוח מקומי של Composer

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

בקטע הזה מוסבר איך ליצור, להגדיר ולהפעיל סביבת Airflow מקומית באמצעות כלי ה-CLI של Composer Local Development.

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

מידע על כלי ה-CLI לפיתוח מקומי של Composer

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

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

אתם יכולים להשתמש בסביבת Airflow המקומית הזו למטרות בדיקה ופיתוח, למשל כדי לבדוק קוד DAG חדש, חבילות PyPI או אפשרויות הגדרה של Airflow.

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

  • כלי ה-CLI לפיתוח מקומי של Composer יוצר סביבות Airflow מקומיות בספרייה שבה מריצים את הפקודה composer-dev create. כדי לגשת לסביבת Airflow המקומית שלכם מאוחר יותר, מריצים את פקודות הכלי בנתיב שבו יצרתם את הסביבה המקומית בהתחלה. כל הנתונים של הסביבה המקומית מאוחסנים בספריית משנה בנתיב שבו יצרתם את הסביבה המקומית: ./composer/<local_environment_name>.

  • במחשב צריך להיות מספיק מקום בכונן כדי לאחסן תמונות של Managed Airflow. כלי ה-CLI לפיתוח מקומי של Composer מאחסן קובץ אימג' אחד לכל גרסה מנוהלת של Airflow. לדוגמה, אם יש לכם שתי סביבות מקומיות של Airflow עם גרסאות שונות של Managed Airflow, כלי ה-CLI של Composer Local Development מאחסן שתי תמונות של Managed Airflow.

  • כלי ה-CLI לפיתוח מקומי של Composer משתמש בפלט צבעוני. אפשר להשבית את הפלט הצבעוני באמצעות המשתנה NO_COLOR=1: NO_COLOR=1 composer-dev <other commands>.

  • אם יש לכם רק סביבה מקומית אחת, אתם יכולים להשמיט את שם הסביבה המקומית מכל פקודות composer-dev, חוץ מהפקודה run-airflow-cmd.

  • מתקינים את יחסי התלות של כלי ה-CLI לפיתוח מקומי של Composer:

  • צריך להתקין את Docker ‏ (Linux/macOS/Windows) או את Podman ‏(Linux או Windows) במחשב ולהפעיל אותם.

    כדי לוודא ש-Docker או Podman פועלים, מריצים פקודה כלשהי ב-CLI של Docker או ב-CLI של Podman, כמו docker ps או podman ps. כל ההוראות חלות על Docker וגם על Podman, אלא אם צוין אחרת. אפשר להחליף כל פקודת Docker בפקודה מקבילה של Podman.

הגדרת פרטי הכניסה

אם עדיין לא עשיתם זאת, קבלת פרטי כניסה חדשים של משתמש חדש לשימוש ב-Application Default Credentials:

gcloud auth application-default login

מתחברים ל-CLI של gcloud באמצעות חשבון Google:

gcloud auth login

כל הקריאות ל-API שמתבצעות על ידי הכלי Composer Local Development CLI ו-DAGs מבוצעות מהחשבון שבו אתם משתמשים ב-CLI של gcloud. לדוגמה, אם DAG בסביבת Airflow המקומית קורא את התוכן של קטגוריה של Cloud Storage, לחשבון הזה צריכות להיות הרשאות גישה לקטגוריה. זה שונה מסביבות Managed Airflow, שבהן חשבון השירות של הסביבה מבצע את הקריאות.

התקנה של כלי ה-CLI לפיתוח מקומי של Composer

משכפלים את המאגר של Composer Local Development CLI:

git clone https://github.com/GoogleCloudPlatform/composer-local-dev.git

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

pip install .

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

‫(Podman) הגדרת Podman

אם אתם משתמשים ב-Podman, אתם צריכים לפעול לפי השלבים הבאים כדי להגדיר אותו:

Linux

  1. מפעילים את שקע שירות המשתמש של Podman.

    ממשק ה-CLI‏ composer-dev מתקשר באמצעות קריאות רגילות ל-Docker API. כדי לחקות את הדימון של Docker, צריך להפעיל את מעטפת השקע של שירות הפועל ברקע של Podman ברמת המשתמש.

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

    systemctl --user is-active podman.socket

    אם הפקודה מחזירה inactive או failed, מפעילים ומתחילים את השקע:

    # Enable and start Podman's user-level systemd socket
systemctl --user enable --now podman.socket

  2. מגדירים משתני סביבה ל-Podman.

    מוסיפים את הפקודה הבאה לקובץ התצורה של המעטפת (למשל .bashrc או .zshrc):

    export DOCKER_HOST="unix:///run/user/$UID/podman/podman.sock"

Windows

  1. מגדירים את WSL 2‏ (.wslconfig). לפני שמפעילים את מכונת Podman, מוודאים של-WSL 2 יש גבולות מוגדרים לזיכרון ול-swap. בלעדיו, פריסות של כמה קונטיינרים עלולות לגרום לעליות חדות בשימוש בזיכרון במהלך חילוץ התמונות. חשוב גם להגדיר מגבלה על מספר ההורדות בו-זמנית.

    משנים או יוצרים את הקובץ %USERPROFILE%\.wslconfig:

    [wsl2]
memory=4GB
swap=2GB

[registry]
max_concurrent_downloads = 2

  2. ב-PowerShell, מפעילים את מכונת Podman:

    podman machine init

  3. מפעילים את המכונה:

    podman machine start

אחרי שתבצעו את השלבים האלה, תוכלו לעבוד עם פקודות CLI של composer-dev. הכלי מזהה באופן אוטומטי את סביבת Podman ב-Windows ומתאים את מיפויי הארכיטקטורה.

יצירת סביבת Airflow מקומית עם קובץ אימג' של Managed Airflow

כדי להציג רשימה של קובצי האימג' הזמינים של Managed Airflow, מריצים את הפקודה:

composer-dev list-available-versions --include-past-releases --limit 10

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

composer-dev create \
  --from-image-version IMAGE_VERSION \
  LOCAL_ENVIRONMENT_NAME

פרמטרים אחרים:

composer-dev create LOCAL_ENVIRONMENT_NAME \
  --from-image-version IMAGE_VERSION \
  --project PROJECT_ID \
  --port WEB_SERVER_PORT \
  --dags-path LOCAL_DAGS_PATH \
  --plugins-path LOCAL_PLUGINS_PATH \
  --database DATABASE_ENGINE \
  --editable-dependencies EDITABLE_DEPENDENCY_PATH

מחליפים את:

  • ‫LOCAL_ENVIRONMENT_NAME בשם של סביבת Airflow המקומית.
  • IMAGE_VERSION בשם של קובץ האימג' של Managed Airflow.
  • ‫PROJECT_ID במזהה הפרויקט.
  • ‫WEB_SERVER_PORT עם היציאה ששרת האינטרנט של Airflow צריך להאזין לה.
  • ‫LOCAL_DAGS_PATH בנתיב לספרייה המקומית שבה נמצאים קובצי ה-DAG.
  • ‫LOCAL_PLUGINS_PATH בנתיב לספרייה מקומית שבה נמצאים קובצי הפלאגין.

  • DATABASE_ENGINE עם המנוע של מסד הנתונים שבו רוצים להשתמש. הערכים האפשריים הם postgresql (ברירת מחדל) ו-sqlite.

  • (Linux/macOS בלבד) EDITABLE_DEPENDENCY_PATH עם הנתיב לספרייה מקומית שמכילה חבילת Python להתקנה במצב שניתן לעריכה. הארגומנט הזה לא נתמך ב-Windows.

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

    כדי לציין כמה חבילות שניתנות לעריכה, חוזרים על האפשרות. דוגמה: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    התקנת החבילות באמצעות pip install -e מחילה באופן מיידי שינויים בחבילות האלה בתוך הפרויקט.

דוגמה:

composer-dev create \
  --from-image-version composer-2.17.14-airflow-2.11.1 \
  example-local-environment

יצירת סביבת Airflow מקומית מסביבת Managed Airflow

רק המידע הבא נלקח מסביבת Managed Airflow:

  • גרסאות של Managed Airflow ו-Airflow שמשמשות בסביבה שלכם.

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

  • רשימה עם הערות של שמות משתני הסביבה שמוגדרים בסביבה שלכם.

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

כדי ליצור סביבת Airflow מקומית מסביבת Managed Airflow קיימת:

composer-dev create LOCAL_ENVIRONMENT_NAME \
    --from-source-environment ENVIRONMENT_NAME \
    --location LOCATION \
    --project PROJECT_ID \
    --port WEB_SERVER_PORT \
    --dags-path LOCAL_DAGS_PATH \
    --plugins-path LOCAL_PLUGINS_PATH \
    --database DATABASE_ENGINE \
    --editable-dependencies EDITABLE_DEPENDENCY_PATH

מחליפים את:

  • LOCAL_ENVIRONMENT_NAME בשם של סביבת Airflow המקומית.
  • ‫ENVIRONMENT_NAME בשם של סביבת Managed Airflow.
  • LOCATION באזור שבו נמצאת סביבת Managed Airflow.
  • ‫PROJECT_ID במזהה הפרויקט.
  • ‫WEB_SERVER_PORT ביציאה לשרת האינטרנט המקומי של Airflow.
  • ‫LOCAL_DAGS_PATH בנתיב לספרייה מקומית שבה נמצאים ה-DAG.
  • ‫LOCAL_PLUGINS_PATH בנתיב לספרייה המקומית שבה נמצאים קובצי הפלאגינים.

  • DATABASE_ENGINE עם המנוע של מסד הנתונים שבו רוצים להשתמש. הערכים האפשריים הם postgresql (ברירת מחדל) ו-sqlite.

  • (Linux/macOS בלבד) EDITABLE_DEPENDENCY_PATH עם הנתיב לספרייה מקומית שמכילה חבילת Python להתקנה במצב שניתן לעריכה. הארגומנט הזה לא נתמך ב-Windows.

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

    כדי לציין כמה חבילות שניתנות לעריכה, חוזרים על האפשרות. דוגמה: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    התקנת החבילות באמצעות pip install -e מחילה באופן מיידי שינויים בחבילות האלה בתוך הפרויקט.

דוגמה:

composer-dev create example-local-environment \
  --from-source-environment example-environment \
  --location us-central1 \
  --project example-project \
  --port 8081 \
  --dags-path ./example_directory/dags \
  --plugins-path ./example_directory/plugins \
  --database postgresql \
  --editable-dependencies ./pkg1

הפעלת סביבת Airflow מקומית

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

composer-dev start LOCAL_ENVIRONMENT_NAME

מחליפים את:

  • LOCAL_ENVIRONMENT_NAME בשם של סביבת Airflow מקומית.

עצירה או הפעלה מחדש של סביבת Airflow מקומית

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

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

composer-dev restart LOCAL_ENVIRONMENT_NAME

מחליפים את:

  • LOCAL_ENVIRONMENT_NAME בשם של סביבת Airflow מקומית.

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

composer-dev stop LOCAL_ENVIRONMENT_NAME

הוספה ועדכון של DAG

קובצי DAG מאוחסנים בספרייה שציינתם בפרמטר --dags-path כשיצרתם את סביבת Airflow המקומית. כברירת מחדל, הספרייה הזו היא ./composer/<local_environment_name>/dags. אפשר לקבל את הספרייה שבה נעשה שימוש בסביבה באמצעות הפקודה describe.

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

הצגת יומנים של סביבת Airflow מקומית

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

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

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

כדי לעקוב אחרי זרם היומן, משמיטים את הארגומנט --max-lines:

composer-dev logs LOCAL_ENVIRONMENT_NAME

הרצת פקודת Airflow CLI

אתם יכולים להריץ פקודות CLI של Airflow בסביבת Airflow המקומית.

כדי להריץ פקודת Airflow CLI:

composer-dev run-airflow-cmd LOCAL_ENVIRONMENT_NAME \
  SUBCOMMAND SUBCOMMAND_ARGUMENTS

דוגמה:

composer-dev run-airflow-cmd example-local-environment dags list -o table

הגדרת סביבות Airflow מקומיות

כלי ה-CLI של Composer Local Development מאחסן פרמטרים של הגדרות לסביבת Airflow מקומית, כמו משתני סביבה ודרישות של חבילות PyPI בספרייה של הסביבה המקומית (./composer/<local_environment_name>).

ההגדרה חלה כשמפעילים סביבת Airflow מקומית. לדוגמה, אם תוסיפו דרישות סותרות לחבילת PyPI, כלי ה-CLI של Composer Local Development ידווח על שגיאות כשתפעילו את הסביבה המקומית.

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

קבלת רשימה וסטטוס של סביבות Airflow מקומיות

כדי להציג את כל סביבות Airflow המקומיות הזמינות ואת הסטטוס שלהן:

composer-dev list

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

composer-dev describe LOCAL_ENVIRONMENT_NAME

מחליפים את:

  • LOCAL_ENVIRONMENT_NAME בשם של סביבת Airflow המקומית.

רשימת תמונות שמשמשות סביבות Airflow מקומיות

כדי להציג רשימה של כל התמונות שבהן נעשה שימוש בכלי Composer Local Development CLI, מריצים את הפקודה:

docker images --filter=reference='*/cloud-airflow-releaser/*/*'

להתקין פלאגינים ולשנות נתונים

תוספים ונתונים לסביבת Airflow מקומית נלקחים מהספרייה של הסביבה המקומית: ./composer/<local_environment_name>/data ו-./composer/<local_environment_name>/plugins).

כדי לשנות את התוכן של הספריות /data ו-/plugins, מוסיפים או מסירים קבצים בספריות האלה. ‫Docker מעביר באופן אוטומטי את השינויים בקבצים לסביבת Airflow המקומית.

הכלי Composer Local Development CLI לא תומך בציון ספרייה אחרת לנתונים ולפלאגינים.

הגדרת משתני סביבה

כדי להגדיר משתני סביבה, עורכים את הקובץ variables.env בספריית הסביבה: ./composer/<local_environment_name>/variables.env.

הקובץ variables.env חייב להכיל הגדרות של צמדי מפתח/ערך, שורה אחת לכל משתנה סביבה. כדי לשנות את אפשרויות ההגדרה של Airflow, משתמשים בפורמט AIRFLOW__SECTION__KEY. מידע נוסף על משתני הסביבה הזמינים מופיע בחומר עזר בנושא הגדרות Airflow.

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

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

התקנה או הסרה של חבילות PyPI

כדי להתקין או להסיר חבילות PyPI, משנים את הקובץ requirements.txt בספריית הסביבה: ./composer/<local_environment_name>/requirements.txt.

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

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

מעבר לתמונה אחרת של Managed Airflow

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

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

כדי לשנות את האימג' של הסביבה שבה משתמשת סביבת Airflow המקומית:

  1. עורכים את קובץ התצורה של הסביבה המקומית: ./composer/<local_environment_name>/config.json.

  2. משנים את הערך של הפרמטר composer_image_version. כדי לראות את הערכים הזמינים, אפשר להציג רשימה של קובצי האימג' הזמינים.

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

מחיקה של סביבת Airflow מקומית

זהירות: חשוב לוודא ששמרתם את כל הנתונים הנדרשים מהסביבה, כמו יומנים והגדרות.

כדי למחוק סביבת Airflow מקומית, מריצים את הפקודה הבאה:

composer-dev remove LOCAL_ENVIRONMENT_NAME

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

מחיקת קובצי אימג' של Docker

כדי למחוק את כל התמונות שהורדו על ידי כלי ה-CLI של Composer Local Development, מריצים את הפקודה:

docker rmi $(docker images --filter=reference='*/cloud-airflow-releaser/*/*' -q)

הגדרות נוספות ופתרון בעיות

בקטע הזה מפורטים פתרונות לבעיות נפוצות ושלבים נוספים להגדרת האינטראקציה של כלי ה-CLI של Composer Local Development עם כלים ושירותים אחרים.

השלמת פקודות אוטומטיות ב-Shell

ב-CLI של composer-dev יש תמיכה בהשלמת פקודה אוטומטית במעטפות Bash,‏ Zsh ו-Fish. אתם יכולים להשתמש בהשלמת פקודה אוטומטית כדי לגלות פקודות משנה ואפשרויות זמינות בלי שתצטרכו לעיין בטקסט העזרה.

Zsh

יוצרים את סקריפט ההשלמה ומפעילים אותו ב-~/.zshrc:

_COMPOSER_DEV_COMPLETE=zsh_source composer-dev > ~/.composer-dev-complete.zsh

ואז מוסיפים אותו אל ~/.zshrc:

echo 'source ~/.composer-dev-complete.zsh' >> ~/.zshrc

Bash

יוצרים את סקריפט ההשלמה ומגדירים אותו כמקור ב-~/.bashrc:

_COMPOSER_DEV_COMPLETE=bash_source composer-dev > ~/.composer-dev-complete.bash

אחר כך מוסיפים אותו אל ~/.bashrc:

echo 'source ~/.composer-dev-complete.bash' >> ~/.bashrc

דגים

יוצרים את סקריפט ההשלמה ושומרים אותו בספריית ההשלמות של Fish:

_COMPOSER_DEV_COMPLETE=fish_source composer-dev > ~/.config/fish/completions/composer-dev.fish

אינטראקציה עם אשכולות Kubernetes

כברירת מחדל, הקובץ ~/.kube/config לא מותקן. כדי לציין את הנתיב לקובץ התצורה של Kubernetes, מייצאים את משתנה הסביבה KUBECONFIG לפני שמפעילים את הסביבה.

export KUBECONFIG=~/.kube/config

אינטראקציה עם שירותים אחרים במכונת המארח

הכתובת localhost בסביבת Managed Airflow מפנה לקונטיינר עצמו, ולא למחשב המארח, בגלל אופן הפעולה של הרשת בקונטיינרים של Docker או Podman. כדי להקל על השימוש, כלי ה-CLI של composer-dev מגדיר את הרשת של הקונטיינר כך שתהיה גישה למכונה דרך host.docker.internal הכינוי של הדומיין. דוגמאות:

  • ‫Redis: במקום localhost:6379, משתמשים ב-host.docker.internal:6379 אם Redis פועל ביציאה 6379.
  • ‫PostgreSQL: במקום localhost:25432, צריך להשתמש ב-host.docker.internal:25432 אם PostgreSQL פועל ביציאה 25432.
  • כל שירות אחר: לפי התבנית הבאה: host.docker.internal:<PORT>

אי אפשר להפעיל סביבה מקומית ב-macOS

אם התקנתם את חבילת composer-dev בספרייה ש-Docker לא יכול לגשת אליה, יכול להיות שהסביבה המקומית לא תופעל.

לדוגמה, אם Python מותקן בספרייה /opt, כמו במקרה של התקנה עם הגדרת ברירת המחדל של Homebrew ב-macOS, אז חבילת composer-dev מותקנת גם היא בספרייה /opt. מכיוון ש-Docker עומד בכללי ארגז החול של אפל, הספרייה /opt לא זמינה כברירת מחדל. בנוסף, אי אפשר להוסיף אותו דרך ממשק המשתמש (הגדרות > משאבים > שיתוף קבצים).

במקרה כזה, כלי ה-CLI של Composer Local Development יוצר הודעת שגיאה שדומה לדוגמה הבאה:

Failed to create container with an error: 400 Client Error for ...
Bad Request ("invalid mount config for type "bind": bind source path does not exist:
/opt/homebrew/lib/python3.9/site-packages/composer_local_dev/docker_files/entrypoint.sh

Possible reason is that composer-dev was installed in the path that is
not available to Docker. See...")

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

  • מתקינים את Python או את חבילת composer-dev בספרייה אחרת, כדי ש-Docker יוכל לגשת לחבילה.
  • עורכים ידנית את הקובץ ~/Library/Group\ Containers/group.com.docker/settings.json ומוסיפים את /opt ל-filesharingDirectories.

גישת משתמשים במאגר התגים לקבצים ולספריות שמועברים מהמארח

כברירת מחדל, הקונטיינר של סביבת Managed Airflow פועל בתור המשתמש airflow עם מזהה המשתמש 999. למשתמש צריכה להיות גישה לקבצים ולספריות שנטענו מהמארח, לדוגמה ~/.config/gcloud/application_default_credentials.json.

בעיות מוכרות:

  • google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found: יכולה להיווצר כשמריצים את הקונטיינר עם משתמש ברירת המחדל airflow (999) ובספריית המארח ~/.config/gcloud/ חסרה הרשאת הביצוע למשתמש.
  • [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json': יכול להיווצר כשמריצים את הקונטיינר עם משתמש ברירת המחדל airflow (999) ולקובץ המארח ~/.config/gcloud/application_default_credentials.json חסרה הרשאת קריאה למשתמש.

ב-Linux או ב-macOS, מומלץ להריץ את הקונטיינר כמשתמש המארח הנוכחי על ידי הוספת COMPOSER_CONTAINER_RUN_AS_HOST_USER=True אל composer/<LOCAL_ENVIRONMENT_NAME>/variables.env.התכונה הזו לא זמינה ב-Windows, ולכן יכול להיות שתצטרכו לעדכן את ההרשאות של הקבצים והספריות שמועברים אל המארח כדי לאפשר גישה למשתמש בתוך הקונטיינר.

‫(Podman) תיקון שגיאות הרשאה או שגיאות lchown למשתמשים ארגוניים

כדי למנוע מ-Podman ללא הרשאות root להקצות באופן אוטומטי מרחבי שמות של משתמשים שחופפים למזהה המשתמש העיקרי שלכם בארגון (מה שגורם לשגיאות lchown: invalid argument או שגיאות הרשאה), אתם צריכים להעביר ידנית את הטווחים המשניים שלכם מעל הבלוק של 4 מיליון.

  1. פותחים את /etc/subuid ואת /etc/subgid עם הרשאות בסיס (לדוגמה: sudo nano /etc/subuid).

  2. מעדכנים או מוסיפים את רשומת שם המשתמש כך שתיראה בדיוק כך:

    YOUR_USERNAME:4000000:3000000

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

    podman system migrate

‫(Podman) הסרת קבצים תקועים ושגיאות של דחיית הרשאה

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

מנקים בכוח את תרשים האחסון המקומי באמצעות הרשאות ברמת המארח:

podman rm -fa
podman volume rm --all --force
podman system migrate

‫(Podman) תיקון כשלים ב-DNS ("שם או שירות לא ידועים")

אם קובץ ה-Airflow שלכם יוצר psycopg2.OperationalError שבו מצוין שהוא לא יכול לתרגם או לפתור את שם המארח של קובץ מסד הנתונים (your-environment-name), סימן שהרשת הפנימית של גשר וירטואלי של Podman לא מסונכרנת.

מנקים את מצבי זמן הריצה ומאלצים את netavark ואת aardvark-dns ליצור מחדש טבלאות ניתוב נקיות.

podman rm -fa
podman network prune --force

rm -rf /run/user/$UID/containers/*
rm -rf /run/user/$UID/netavark/*
rm -rf COMPOSER_LOCAL_DEV_PATH/composer/*

podman system migrate

‫(Podman) בדיקת סטטוס המנוע

כדי לוודא ש-Podman מנהל את תהליך העבודה ללא הרשאות root ולא עוקף את ההגדרות שלכם ל-Docker של המערכת:

  1. אימות של קצה ה-DNS העורפי של הרשת:

    podman info | grep -A 3 -i "dns"

    הפלט צריך להכיל את backend: netavark ונתיב הפעלה תקין אל aardvark-dns.

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

    ps -ef | grep -i "postgres"

    בעמודה הימנית ביותר צריך להופיע מספר UID גבוה (למשל 4000069) שמתאים לטווח של מיפוי ה-subuid, כדי להוכיח שההפעלה מתבצעת ללא הרשאות root.

(Podman, Windows) פתרון שגיאות בצינור במהלך הפריסה

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

  1. עוצרים את המכונה של Podman ואת המכונה הווירטואלית של WSL 2 על ידי הפעלת הפקודה הבאה ב-PowerShell:

    podman machine stop
wsl --shutdown

  2. מבצעים שינויים בקובץ %USERPROFILE%\.wslconfig כדי להתאים את מגבלות הזיכרון וההחלפה. לעיון, אפשר לקרוא את החומר העזר בנושא הגדרות WSL.

  3. מפעילים את מכונת Podman באמצעות הפקודה:

    podman machine start

אם נתקלים בשגיאות, אפשר לנסות לאפס ידנית את הווירטואליזציה של Windows ואת מקבץ הרשת (network stack). כדי לעשות את זה, פותחים את PowerShell כאדמין ומריצים את הפקודה:

Restart-Service -Name vmms -Force
Restart-Service -Name hns -Force
wsl --shutdown

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