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

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

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

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

כלי ה-CLI של Composer Local Development מייעל את הפיתוח של Apache Airflow DAG ל-Managed Airflow, על ידי הפעלת סביבת Airflow באופן מקומי. סביבת Airflow המקומית הזו משתמשת באימג' build של Airflow שמשמש גרסה ספציפית של 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.
    • ‫Airflow 3.2.2 נתמך החל מ-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 לפיתוח מקומי ו-DAGs, מופעלות מהחשבון שבו אתם משתמשים ב-CLI של gcloud. לדוגמה, אם DAG בסביבת Airflow המקומית קורא את התוכן של קטגוריה של Cloud Storage, לחשבון הזה צריכות להיות הרשאות גישה לקטגוריה. זה שונה מסביבות Managed Airflow, שבהן חשבון השירות של הסביבה מבצע את הקריאות.

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

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

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. כדי לחקות את דימון (daemon) של Docker, צריך להפעיל את wrapper שקע שירות הפועל ברקע של 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 מקומית באמצעות קובץ אימג' של גרסת Airflow

כדי לראות רשימה של קובצי אימג' זמינים ל-build של 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 בשם של קובץ האימג' של Airflow build.
  • ‫PROJECT_ID במזהה הפרויקט (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 Local Development מפעיל מחדש את קונטיינר 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

הרצת פקודה ב-CLI של Airflow

אתם יכולים להריץ פקודות 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 המקומית.

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

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

כדי להגדיר משתני סביבה, עורכים את הקובץ 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 עם הכלי Composer Local Development CLI ולעבור בין קובצי האימג'. הגישה הזו שונה משדרוג סביבת 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 עם כלים ושירותים אחרים.

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

מחיקה בכוח של גרף האחסון המקומי באמצעות הרשאות root ברמת המארח:

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. מריצים את הפקודה הבאה ב-PowerShell כדי לעצור את המכונה של Podman ואת המכונה הווירטואלית של WSL 2:

    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

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