הפעלת סביבת 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 המקומית הזו משתמשת באימג' של Airflow build שמשמש גרסה ספציפית של Managed Airflow.

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

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

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

  • כלי ה-CLI של Composer לפיתוח מקומי תומך בגרסאות build של Airflow 3 באופן הבא:

    • גרסאות Airflow 3.3.1 ואילך נתמכות החל מ-composer-3-airflow-3.3.1-build.0.
    • גרסה 3.2.2 של Airflow נתמכת החל מ-composer-3-airflow-3.2.2-build.3.
    • אין תמיכה ב-Airflow 3.1.8.
    • גרסאות קודמות של Airflow 3 נתמכות החל מ-composer-3-airflow-3.1.0-build.8.

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

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

  • הכלי Composer Local Development CLI משתמש בפלט צבעוני. אפשר להשבית את הפלט הצבעוני באמצעות המשתנה 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 שמתבצעות על ידי כלי ה-CLI של Composer Local Development ו-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 מתקשר באמצעות קריאות רגילות ל-API של Docker. כדי לחקות את הדימון של Docker, צריך להפעיל את מעטפת השקע של שירות הפועל ברקע של Podman ברמת המשתמש.

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

    systemctl --user is-active podman.socket

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

    # 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 מקומית באמצעות קובץ אימג' של גרסת Airflow

כדי להציג רשימה של קובצי האימג' הזמינים של 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 בשם של קובץ האימג' של ה-build של 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-3-airflow-2.11.1-build.21 \
  example-local-environment

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

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

  • גרסת build ספציפית של 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

אתם יכולים להריץ פקודות Airflow CLI בסביבת 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 מאחסן פרמטרים של הגדרות אישיות לסביבת 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 המקומיות

כדי להציג את כל קובצי האימג' שמשמשים את כלי ה-CLI של Composer לפיתוח מקומי, מריצים את הפקודה:

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

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

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

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

בכלי ה-CLI של Composer לפיתוח מקומי אי אפשר לציין ספרייה אחרת לנתונים ולפלאגינים.

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

כדי להגדיר משתני סביבה, עורכים את הקובץ 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 המקומית.

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

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

לדוגמה, אחרי שפורסם build חדש של Airflow, אתם יכולים להעביר את הסביבה שלכם לשימוש בו, ולהשאיר את ההגדרות המקומיות הקיימות של סביבת 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 עם כלים ושירותים אחרים.

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

ממשק ה-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: צריך להשתמש ב-host.docker.internal:6379 במקום ב-localhost:6379 אם Redis פועל ביציאה 6379.
  • ‫PostgreSQL: צריך להשתמש ב-host.docker.internal:25432 במקום ב-localhost: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 ללא הרשאות בסיס להקצות באופן אוטומטי מרחבי שמות של משתמשים שחופפים למזהה המשתמש הראשי של הארגון (מה שגורם לשגיאות 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 מנהל את תהליך העבודה ללא הרשאות ברמת הבסיס (rootless) ולא עוקף את ההגדרות שלכם ל-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

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