קובצי אימג' מותאמים אישית של קונטיינרים ל-Dataflow מאפשרים לכם לארוז יחסי תלות של צד שלישי, ספריות פרטיות וקבצים בינאריים של זמן ריצה ישירות בסביבת העובד. התקנה מראש של הדרישות האלה עוזרת לקצר את זמן ההפעלה של ה-worker, ומבטיחה ביצוע עקבי בצינורות עיבוד הנתונים של Apache Beam.
דרישות
קובץ אימג' של קונטיינר בהתאמה אישית ל-Dataflow צריך לעמוד בדרישות הבאות:
- מערכת Apache Beam SDK והרכיבים התלויים הנדרשים מותקנים. מומלץ להתחיל עם תמונת ברירת מחדל של Apache Beam SDK. למידע נוסף, ראו בחירת קובץ אימג' בסיסי במסמך הזה.
- הסקריפט
/opt/apache/beam/bootחייב לפעול כשלב האחרון במהלך הפעלת הקונטיינר. הסקריפט הזה מאתחל את סביבת ה-worker ומתחיל את תהליך ה-worker של ה-SDK. הסקריפט הזה הוא ברירת המחדל שלENTRYPOINTבתמונות של Apache Beam SDK. עם זאת, אם אתם משתמשים בתמונת בסיס אחרת או אם אתם משנים את ברירת המחדל שלENTRYPOINT, אתם צריכים להריץ את הסקריפט באופן מפורש. למידע נוסף, ראו שינוי נקודת הכניסה של מאגר במסמך הזה. - קובץ האימג' של הקונטיינר צריך לתמוך בארכיטקטורה של מכונות ה-VM של העובדים עבור משימת Dataflow. אם אתם מתכננים להשתמש בקונטיינר בהתאמה אישית במכונות וירטואליות (VM) של ARM, מומלץ ליצור אימג' מרובה ארכיטקטורות. מידע נוסף זמין במאמר בנושא יצירת תמונת קונטיינר מרובת ארכיטקטורות.
לפני שמתחילים
מוודאים שגרסת ה-Apache Beam SDK שמותקנת תומכת ב-Portable Runner ובגרסת השפה שלכם. למידע נוסף, קראו את המאמר התקנת Apache Beam SDK.
כדי לבדוק את קובץ האימג' של הקונטיינר באופן מקומי, צריך להתקין את Docker. מידע נוסף זמין במאמר בנושא קבלת Docker.
יוצרים מאגר Artifact Registry. מציינים את הפורמט של קובץ האימג' של Docker. צריכה להיות לכם לפחות גישת כתיבה ל-Artifact Registry במאגר.
כדי ליצור מאגר חדש, מריצים את הפקודה
gcloud artifacts repositories create:gcloud artifacts repositories create REPOSITORY \ --repository-format=docker \ --location=REGION \ --asyncמחליפים את מה שכתוב בשדות הבאים:
- REPOSITORY: שם למאגר. שמות המאגרים צריכים להיות ייחודיים לכל מיקום בפרויקט.
- REGION: האזור שבו רוצים לפרוס את משימת Dataflow. בוחרים אזור ב-Dataflow שקרוב למקום שבו מריצים את הפקודות. הערך חייב להיות שם אזור תקין. מידע נוסף על אזורים ומיקומים זמין במאמר מיקומים ב-Dataflow.
בדוגמה הזו נעשה שימוש בדגל
--async. הפקודה חוזרת מיד, בלי להמתין לסיום הפעולה.כדי להגדיר את Docker לאימות בקשות ל-Artifact Registry, מריצים את הפקודה
gcloud auth configure-docker:gcloud auth configure-docker REGION-docker.pkg.devהפקודה מעדכנת את ההגדרות של Docker. עכשיו אפשר להתחבר ל-Artifact Registry בפרויקט Google Cloud כדי להעביר תמונות.
בחירת תמונת בסיס
מומלץ להתחיל עם קובץ אימג' של Apache Beam SDK כקובץ האימג' של קונטיינר הבסיס. התמונות האלה מתפרסמות כחלק מהגרסאות של Apache Beam ב-Docker Hub.
שימוש בתמונת בסיס של Apache Beam
כדי להשתמש בתמונה של Apache Beam SDK כבסיס לתמונה, מציינים את תמונת הקונטיינר בהוראה FROM ואז מוסיפים את ההתאמות האישיות שלכם.
Java
בדוגמה הזו נעשה שימוש ב-Java 8 עם Apache Beam SDK בגרסה 2.77.0.
FROM apache/beam_java8_sdk:2.77.0
# Make your customizations here, for example:
ENV FOO=/bar
COPY path/to/myfile ./
גרסת סביבת זמן הריצה של הקונטיינר בהתאמה אישית צריכה להתאים לסביבת זמן הריצה שבה תשתמשו כדי להפעיל את צינור עיבוד הנתונים. לדוגמה, אם מפעילים את צינור עיבוד הנתונים מסביבת Java 11 מקומית, בשורה FROM צריך לציין סביבת Java 11:
apache/beam_java11_sdk:....
Python
בדוגמה הזו משתמשים ב-Python 3.10 עם Apache Beam SDK בגרסה 2.77.0.
FROM apache/beam_python3.10_sdk:2.77.0
# Make your customizations here, for example:
ENV FOO=/bar
COPY path/to/myfile ./
גרסת זמן הריצה של מאגר התגים המותאם אישית צריכה להיות זהה לזמן הריצה שבו תשתמשו כדי להפעיל את צינור עיבוד הנתונים. לדוגמה, אם תפעילו את צינור עיבוד הנתונים מסביבת Python 3.10 מקומית, בשורה FROM צריך לציין סביבת Python 3.10:
apache/beam_python3.10_sdk:....
המשך
בדוגמה הזו משתמשים ב-Go עם Apache Beam SDK בגרסה 2.77.0.
FROM apache/beam_go_sdk:2.77.0
# Make your customizations here, for example:
ENV FOO=/bar
COPY path/to/myfile ./
שימוש בתמונת בסיס מותאמת אישית
אם אתם רוצים להשתמש בקובץ אימג' בסיסי אחר, או שאתם צריכים לשנות היבט כלשהו של קובצי האימג' של Apache Beam שמוגדרים כברירת מחדל (כמו גרסת מערכת ההפעלה או תיקונים), השתמשו בתהליך בנייה בכמה שלבים. מעתיקים את פריטי המידע הנדרשים מקובץ אימג' בסיסי של Apache Beam שמוגדר כברירת מחדל.
מגדירים את ENTRYPOINT להפעלה של הסקריפט /opt/apache/beam/boot, שמאפשר לאתחל את סביבת העובד ולהתחיל את תהליך העובד של ה-SDK. אם לא מגדירים את נקודת הכניסה הזו, עובדי Dataflow לא מתחילים לפעול כמו שצריך.
בדוגמה הבאה מוצג קובץ Dockerfile שמעתיק קבצים מ-Apache Beam SDK:
Java
FROM openjdk:8
# Copy files from official SDK image, including script/dependencies.
COPY --from=apache/beam_java8_sdk:2.77.0 /opt/apache/beam /opt/apache/beam
# Set the entrypoint to Apache Beam SDK launcher.
ENTRYPOINT ["/opt/apache/beam/boot"]
Python
FROM python:3.10-slim
# Install SDK.
RUN pip install --no-cache-dir apache-beam[gcp]==2.77.0
# Verify that the image does not have conflicting dependencies.
RUN pip check
# Copy files from official SDK image, including script/dependencies.
COPY --from=apache/beam_python3.10_sdk:2.77.0 /opt/apache/beam /opt/apache/beam
# Set the entrypoint to Apache Beam SDK launcher.
ENTRYPOINT ["/opt/apache/beam/boot"]
בדוגמה הזו אנחנו מניחים שיחסי התלות הנדרשים (במקרה הזה, Python 3.10 ו-pip) הותקנו בתמונת הבסיס הקיימת. התקנת ה-SDK של Apache Beam ב-image מבטיחה של-image יהיו יחסי התלות הנדרשים ב-SDK, ומקצרת את זמן ההפעלה של ה-worker.
חשוב: גרסת ה-SDK שצוינה בהוראות RUN ו-COPY צריכה להיות זהה לגרסה ששימשה להפעלת צינור העיבוד.
המשך
FROM golang:latest
# Copy files from official SDK image, including script/dependencies.
COPY --from=apache/beam_go_sdk:2.77.0 /opt/apache/beam /opt/apache/beam
# Set the entrypoint to Apache Beam SDK launcher.
ENTRYPOINT ["/opt/apache/beam/boot"]
שינוי נקודת הכניסה של הקונטיינר
אם המאגר מריץ סקריפט בהתאמה אישית במהלך ההפעלה, הסקריפט צריך להסתיים בהרצה של /opt/apache/beam/boot. ארגומנטים שמועברים על ידי Dataflow במהלך הפעלת הקונטיינר צריכים לעבור לסקריפט ברירת המחדל של האתחול. בדוגמה הבאה מוצג סקריפט לטעינה בזמן ההפעלה בהתאמה אישית שקורא לסקריפט האתחול שמוגדר כברירת מחדל:
#!/bin/bash
echo "This is my custom script"
# ...
# Pass command arguments to the default boot script.
/opt/apache/beam/boot "$@"
בקובץ ה-Docker, מגדירים את ENTRYPOINT כך שיקרא לסקריפט:
Java
FROM apache/beam_java8_sdk:2.77.0
COPY script.sh path/to/my/script.sh
ENTRYPOINT [ "path/to/my/script.sh" ]
Python
FROM apache/beam_python3.10_sdk:2.77.0
COPY script.sh path/to/my/script.sh
ENTRYPOINT [ "path/to/my/script.sh" ]
המשך
FROM apache/beam_go_sdk:2.77.0
COPY script.sh path/to/my/script.sh
ENTRYPOINT [ "path/to/my/script.sh" ]
יצירה של קובץ האימג' והעלאה שלו
אתם יכולים להשתמש ב-Cloud Build או ב-Docker כדי ליצור את קובץ האימג' של הקונטיינר ולהעביר אותו למאגר Artifact Registry.
Cloud Build
כדי ליצור את הקובץ ולהעביר אותו בדחיפה למאגר ב-Artifact Registry, מריצים את הפקודה gcloud builds submit:
gcloud builds submit --tag REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/dataflow/IMAGE:TAG .
Docker
docker build . --tag REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/dataflow/IMAGE:TAGdocker push REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/dataflow/IMAGE:TAG
מחליפים את מה שכתוב בשדות הבאים:
-
REGION: האזור שבו תפרסו את משימת Dataflow. הערך של המשתנהREGIONחייב להיות שם אזור תקין. -
PROJECT_ID: שם הפרויקט או שם המשתמש. -
REPOSITORY: שם מאגר התמונות. -
IMAGE: שם התמונה. -
TAG: תג התמונה. תמיד צריך לציין תג או SHA של מאגר עם גרסה. אל תשתמשו בתג:latestאו בתג שניתן לשינוי.
התקנה מראש של יחסי תלות ב-Python
הקטע הזה רלוונטי לצינורות Python.
כשמפעילים משימת Dataflow ב-Python, אפשר לציין יחסי תלות נוספים באמצעות האפשרות --requirements_file או --extra_packages בזמן הריצה. מידע נוסף זמין במאמר ניהול יחסי תלות של צינור עיבוד נתונים ב-Python.
יחסי תלות נוספים מותקנים בכל מארז של Dataflow worker. כשהעבודה מתחילה לראשונה ובמהלך התאמה אוטומטית לעומס, התקנת התלות מובילה לעיתים קרובות לשימוש גבוה במעבד ולתקופת אתחול ארוכה בכל עובדי Dataflow החדשים שהופעלו.
כדי להימנע מהתקנות חוזרות של יחסי תלות, אתם יכולים ליצור מראש קובץ אימג' של קונטיינר Python SDK בהתאמה אישית עם יחסי התלות המותקנים מראש. אפשר לבצע את השלב הזה בזמן הבנייה באמצעות Dockerfile, או בזמן הריצה כששולחים את העבודה.
ה-workers יוצרים סביבת Python וירטואלית חדשה כשהם מפעילים את הקונטיינר. לכן, צריך להתקין את יחסי התלות בסביבת ברירת המחדל (הגלובלית) של Python במקום ליצור סביבה וירטואלית. אם אתם מפעילים סביבה וירטואלית בקובץ האימג' של הקונטיינר, יכול להיות שהסביבה הזו לא תופעל כשהמשימה תתחיל. מידע נוסף זמין במאמר בנושא בעיות נפוצות.
התקנה מראש באמצעות קובץ Docker
כדי להוסיף תלויות נוספות ישירות לקונטיינר מותאם אישית של Python, משתמשים בפקודות הבאות:
FROM apache/beam_python3.10_sdk:2.77.0
COPY requirements.txt .
# Pre-install Python dependencies. For reproducibile builds,
# supply all of the dependencies and their versions in a requirements.txt file.
RUN pip install -r requirements.txt
# You can also install individual dependencies.
RUN pip install lxml
# Pre-install other dependencies.
RUN apt-get update \
&& apt-get dist-upgrade \
&& apt-get install -y --no-install-recommends ffmpeg
שולחים את העבודה עם האפשרויות של צינור הנתונים --sdk_container_image ו---sdk_location.
האפשרות --sdk_location מונעת את ההורדה של ה-SDK כשמפעילים את העבודה.
ערכת ה-SDK מאוחזרת ישירות מקובץ אימג' של קונטיינר.
בדוגמה הבאה מריצים את צינור העיבוד לדוגמה wordcount:
python -m apache_beam.examples.wordcount \
--input=INPUT_FILE \
--output=OUTPUT_FILE \
--project=PROJECT_ID \
--region=REGION \
--temp_location=TEMP_LOCATION \
--runner=DataflowRunner \
--experiments=use_runner_v2 \
--sdk_container_image=IMAGE_URI
--sdk_location=containerמחליפים את מה שכתוב בשדות הבאים:
- INPUT_FILE: קובץ קלט לפייפליין
- OUTPUT_FILE: נתיב לכתיבת הפלט
- PROJECT_ID: מזהה הפרויקט ב- Google Cloud
- REGION: האזור שבו פורסים את משימת Dataflow.
- TEMP_LOCATION: הנתיב ב-Cloud Storage שבו Dataflow יאחסן קובצי משימות זמניים
- IMAGE_URI: ה-URI של קובץ האימג' של הקונטיינר בהתאמה אישית
בנייה מראש של קובץ אימג' של קונטיינר כששולחים את המשימה
כשיוצרים מראש קובץ אימג' של קונטיינר, אפשר להתקין מראש את יחסי התלות של הצינור לפני הפעלת המשימה. אין צורך ליצור קובץ אימג' של קונטיינר בהתאמה אישית.
כדי ליצור מראש קונטיינר עם יחסי תלות נוספים של Python כששולחים משימה, משתמשים באפשרויות הבאות של צינור עיבוד הנתונים:
--prebuild_sdk_container_engine=[cloud_build | local_docker]. כשהדגל הזה מוגדר, Apache Beam יוצר קונטיינר בהתאמה אישית ומתקין את כל יחסי התלות שצוינו באפשרויות--requirements_fileו---extra_packages. הסימון הבוליאני הזה תומך בערכים הבאים:-
cloud_build. משתמשים ב-Cloud Build כדי ליצור את הקונטיינר. צריך להפעיל את Cloud Build API בפרויקט. -
local_docker. משתמשים בהתקנה המקומית של Docker כדי ליצור את הקונטיינר.
-
--docker_registry_push_url=IMAGE_PATH. מחליפים אתIMAGE_PATHבתיקייה של Artifact Registry.
--sdk_location=container. האפשרות הזו מונעת מהעובדים להוריד את ה-SDK כשהעבודה מתחילה. במקום זאת, ה-SDK מאוחזר ישירות מקובץ האימג' של הקונטיינר.
בדוגמה הבאה נעשה שימוש ב-Cloud Build כדי ליצור מראש את קובץ האימג':
python -m apache_beam.examples.wordcount \
--input=INPUT_FILE \
--output=OUTPUT_FILE \
--project=PROJECT_ID \
--region=REGION \
--temp_location=TEMP_LOCATION \
--runner=DataflowRunner \
--disk_size_gb=DISK_SIZE_GB \
--experiments=use_runner_v2 \
--requirements_file=./requirements.txt \
--prebuild_sdk_container_engine=cloud_build \
--docker_registry_push_url=IMAGE_PATH \
--sdk_location=containerכדי להשתמש בתכונה הזו, צריך להתקין את Apache Beam SDK ל-Python בגרסה 2.25.0 ואילך.
בתהליך העבודה של טרום-בנייה של קובץ אימג' של קונטיינר SDK, נעשה שימוש בקובץ האימג' שמועבר באמצעות אפשרות הצינור --sdk_container_image כקובץ האימג' הבסיסי. אם האפשרות לא מוגדרת, ברירת המחדל היא שימוש בתמונה של Apache Beam כתמונת הבסיס.
אפשר לעשות שימוש חוזר בקובץ אימג' של קונטיינר של Python SDK שנבנתה מראש בעבודה אחרת עם אותן תלויות ואותה גרסת SDK.
כדי להשתמש שוב בקובץ האימג', מעבירים את כתובת ה-URL של קובץ האימג' של הקונטיינר שנבנה מראש למשימה השנייה באמצעות האפשרות --sdk_container_image של צינור עיבוד הנתונים. מסירים את אפשרויות התלות --requirements_file, --extra_packages ו---setup_file.
אם אתם לא מתכננים להשתמש בתמונה שוב, מומלץ למחוק אותה אחרי שהעבודה מסתיימת. אפשר למחוק את קובץ האימג' באמצעות ה-CLI של gcloud או בדפים של Artifact Registry במסוף Google Cloud .
אם קובץ האימג' מאוחסן ב-Artifact Registry, משתמשים בפקודה artifacts docker images delete:
gcloud artifacts docker images delete IMAGE --delete-tagsבעיות נפוצות
אם למשימה יש יחסי תלות נוספים של Python מ-PyPi mirror פרטי, ואי אפשר למשוך אותם באמצעות משימה מרחוק של Cloud Build, נסו להשתמש באפשרות של Docker מקומי או ליצור את הקונטיינר באמצעות קובץ Docker.
אם משימת Cloud Build נכשלת עם השגיאה
docker exit code 137, נגמר הזיכרון הפנוי (OOM) של משימת ה-build, כנראה בגלל גודל יחסי התלות שמותקנים. כדי להשתמש במכונה מסוג גדול יותר של Cloud Build, מעבירים את--cloud_build_machine_type=machine_type, כאשר machine_type הוא אחת מהאפשרויות הבאות:n1-highcpu-8n1-highcpu-32e2-highcpu-8e2-highcpu-32
כברירת מחדל, Cloud Build משתמש במכונה מסוג
e2-medium.ב-Apache Beam מגרסה 2.44.0 ואילך, ה-workers יוצרים סביבה וירטואלית כשהם מפעילים קונטיינר בהתאמה אישית. אם הקונטיינר יוצר סביבה וירטואלית משלו כדי להתקין יחסי תלות, יחסי התלות האלה נמחקים. התנהגות כזו עלולה לגרום לשגיאות כמו:
ModuleNotFoundError: No module named '<dependency name>'כדי להימנע מהבעיה הזו, צריך להתקין את התלויות בסביבת ברירת המחדל (הגלובלית) של Python. כפתרון עקיף, אפשר להשבית את ההתנהגות הזו ב-Beam 2.48.0 ובגרסאות מתקדמות יותר על ידי הגדרת משתנה הסביבה הבא בקובץ אימג' של קונטיינר:
ENV RUN_PYTHON_SDK_IN_DEFAULT_ENVIRONMENT=1
המאמרים הבאים
- למידע נוסף על כתיבת קובצי Docker, ראו שיטות מומלצות לכתיבת קובצי Docker.
- איך מריצים משימת Dataflow בקונטיינר בהתאמה אישית