פתרון בעיות בהפעלה מרחוק ב-Bazel עם Dock Sandbox

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

דף זה מתאר כיצד לזהות ולפתור את הבעיות הנפוצות ביותר שמתעוררות בעת ההפעלה מרחוק באמצעות התכונה "ארגז חול של מעגן", אשר קובעת הגבלות על ה-build שווה לאלו של ההפעלה מרחוק. כך תוכלו לפתור את הבעיה ב-build ללא צורך בשירות ביצוע מרחוק.

התכונה 'ארגז חול של מעגן' מחקה את ההגבלות על ביצוע מרחוק, באופן הבא:

• ביצוע פעולות בנייה במאגרים מסוג 'כלים'. ניתן להשתמש באותם כלי קיבול של כלים כדי להפעיל את ה-build באופן מקומי ובאופן מרוחק באמצעות שירות התומך בביצוע מרחוק באמצעות קונטיינר.

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

• כל פעולה מתבצעת במאגר חדש. מאגר ייחודי וחדש נוצר לכל פעולת build שיוצרת.

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

ניתן לפתור את הבעיות האלה באמצעות אחת מהשיטות הבאות:

• פתרון בעיות במקור. בשיטה הזו, Bazel ופעולות הבנייה שלה פועלות באופן מקומי במחשב המקומי שלכם. תכונת ארגז החול של Docker מגבילה את ה-build על מאפשרת זו זהה לזו של ביצוע מרחוק. עם זאת, השיטה הזו לא תזהה כלים, מצבים ונתונים מקומיים שדלפו לתוך ה-build, וזה יגרום לבעיות בהפעלה מרחוק.

• פתרון בעיות במאגר של Dock. בשיטה זו, Bazel ופעולות הבנייה שלה פועלות בתוך קונטיינר של Dock, שמאפשר לך לזהות כלים, מדינות ונתונים שדלפו מהמחשב המקומי אל ה-build בנוסף להטלת הגבלות שווה לאלה המבוצעים מרחוק. שיטה זו מספקת תובנות לגבי ה-build גם אם חלקים מה-build נכשלים. שיטה זו היא ניסיונית ואינה נתמכת באופן רשמי.

דרישות מוקדמות

אם עדיין לא עשיתם זאת, יש לבצע את הפעולות הבאות לפני שמתחילים לפתור את הבעיה:

• התקנת Docker והגדרת ההרשאות הנדרשות להפעלתו.
• התקנת Bazel 0.14.1 ואילך. גרסאות קודמות אינן תומכות בתכונה 'ארגז חול' של Docker.
• יש להוסיף את הקובץ bazel-toolchains המוצמד לגרסת הגרסה האחרונה, לקובץ WORKSPACE של ה-build כפי שמתואר כאן.
• יש להוסיף סימונים לקובץ .bazelrc כדי להפעיל את התכונה. יוצרים את הקובץ בספריית השורש של פרויקט בזל, אם הוא לא קיים. הסימונים שבהמשך הם דוגמה לדוגמה. יש לעיין בקובץ העדכני .bazelrc במאגר bazel-toolchains ולהעתיק את ערכי הסימונים המוגדרים שם עבור התצורה docker-sandbox.

# Docker Sandbox Mode
build:docker-sandbox --host_javabase=<...>
build:docker-sandbox --javabase=<...>
build:docker-sandbox --crosstool_top=<...>
build:docker-sandbox --experimental_docker_image=<...>
build:docker-sandbox --spawn_strategy=docker --strategy=Javac=docker --genrule_strategy=docker
build:docker-sandbox --define=EXECUTOR=remote
build:docker-sandbox --experimental_docker_verbose
build:docker-sandbox --experimental_enable_docker_sandbox

הערה: הסימונים בקובץ .bazelrc שמוצג למעלה מוגדרים לפעול בתוך rbe-ubuntu16-04 container.

אם לכללים שלכם נדרשים כלים נוספים, יש לפעול לפי השלבים הבאים:

1. צור כלי עגינה מותאם אישית ל-Dock על ידי התקנת כלים באמצעות Dockerfile ובנייה של התמונה באופן מקומי.

2. החלף את הערך של הדגל --experimental_docker_image שלמעלה בשם התמונה של המאגר המותאם אישית שלך.

פתרון בעיות באופן מקורי

שיטה זו מבצעת את Bazel וכל פעולות ה-build שלה ישירות במחשב המקומי, וזו דרך אמינה לוודא אם ה-build יצליח כאשר יבוצע מרחוק.

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

שלב 1: הפעלת ה-build

1. הוסיפו את הסימון --config=docker-sandbox לפקודה Bazel שמבצעת את ה-build. למשל:

   bazel --bazelrc=.bazelrc build --config=docker-sandbox target
   

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

ייתכן שתיתקלו בשגיאה הבאה:

ERROR: 'docker' is an invalid value for docker spawn strategy.

אם כן, הרץ שוב את ה-build עם הסימון --experimental_docker_verbose. הסימון הזה מפעיל הודעות שגיאה עם דרגת מלל. שגיאה זו נגרמת בדרך כלל על ידי התקנה שגויה של אביזר עגינה, או שאין לך הרשאות לבצע אותה בחשבון המשתמש הנוכחי. מידע נוסף זמין בתיעוד של עגינה. אם הבעיות ממשיכות, דלג קדימה אל פתרון בעיות במכל של Docker.

שלב 2: פותרים בעיות שזוהו

לפניכם הבעיות הנפוצות ביותר והפתרונות העקיפים שלהן.

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

• קובץ, כלי, קובץ בינארי או משאב מפנה בנתיב מוחלט או שהמשתנה PATH חסר. עליך לוודא שכל הכלים הנדרשים מותקנים בתוך המאגר של 'כלי כלים' ולהשתמש בכללי ה-toolchain כדי להצהיר על יחסי תלות מסוימים שמצביעים אל המשאב החסר. מידע נוסף זמין במאמר הפעלת כלים לבניית גרסאות באמצעות כללי 'כלים'.

• הפעלה בינארית נכשלה. אחד מכללי ה-build מתייחס לבינארי שאינו תואם לסביבת הביצוע (המאגר של דוקר). ראה ניהול קבצים בינאריים תלויי-פלטפורמה למידע נוסף. אם לא מצליחים לפתור את הבעיה, יש לפנות אל [e-mail] לקבלת עזרה.

• קובץ מ-@local-jdk חסר או גורם לשגיאות. הקבצים הבינאריים של Java במכונה המקומית שלכם דולפים אל ה-build תוך אי-התאמה אליו. השתמש ב-java_toolchain בכללים וביעדים שלך במקום ב-@local_jdk. אם נדרשת לך עזרה נוספת, אפשר לפנות אל [e-mail].

• שגיאות אחרות. לקבלת עזרה, יש לפנות אל [e-mail].

פתרון בעיות במאגר ב-Dock

בשיטה הזו, Bazel פועלת בתוך מאגר מארח של Dock ארגז החול הולץ מאגר כלים חדש לגמרי לכל פעולת build, ורק פעולה אחת מתבצעת בכל מאגר כלים.

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

שלב 1: בניית המאגר

הערה: הפקודות הבאות מותאמות במיוחד לבסיס של debian:stretch. בבסיסים אחרים, יש לשנות אותם לפי הצורך.

1. יצירת Dockerfile שיוצרת את מאגר Docker ומתקינה את Bazel בקבוצה מינימלית של כלים לבניית:

   FROM debian:stretch
   
   RUN apt-get update && apt-get install -y apt-transport-https curl software-properties-common git gcc gnupg2 g++ openjdk-8-jdk-headless python-dev zip wget vim
   
   RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
   
   RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
   
   RUN apt-get update && apt-get install -y docker-ce
   
   RUN wget https://releases.bazel.build/<latest Bazel version>/release/bazel-<latest Bazel version>-installer-linux-x86_64.sh -O ./bazel-installer.sh && chmod 755 ./bazel-installer.sh
   
   RUN ./bazel-installer.sh
   

2. בניית המאגר בתור bazel_container:

   docker build -t bazel_container - < Dockerfile
   

שלב 2: הפעלת המאגר

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

docker run -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp:/tmp \
  -v your source code directory:/src \
  -w /src \
  bazel_container \
  /bin/bash

פקודה זו מפעילה את המאגר בתור הרמה הבסיסית (root), ממפה את שקע העגינה ותואמת את הספרייה /tmp. הפעולה הזו מאפשרת ל-Bazel להוביל מאגרי Docker אחרים ולהשתמש בספריות תחת /tmp כדי לשתף קבצים עם המאגרים האלה. קוד המקור שלך זמין ב-/src בתוך מאגר התגים.

הפקודה מתחילה במכוון ממאגר בסיס debian:stretch שמכיל בינאריים שאינם תואמים למאגר rbe-ubuntu16-04 המשמש כמאגר של 'כלים'. אם בינאריים מהסביבה המקומית דולפים למכל של 'כלים', הם יגרמו לשגיאות בנייה.

שלב 3: בודקים את המאגר

הרץ את הפקודות הבאות מתוך מאגר התגים של Dock כדי לבדוק אותה:

docker ps
bazel version

שלב 4: הפעלת ה-build

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

bazel --output_user_root=/tmp/bazel_docker_root --bazelrc=.bazelrc \ build --config=docker-sandbox target

שלב 5: פתרון בעיות שזוהו

תוכלו לפתור את הכשלים ב-build באופן הבא:

• אם ה-build ייכשל עם שגיאה 'שטח האחסון בדיסק', תוכל להגדיל את המגבלה הזו על ידי הפעלת מאגר המארח עם הסימון --memory=XX, כאשר XX הוא שטח הדיסק שהוקצה בג'יגה-בייט. זוהי תוצאה ניסיונית והיא עלולה לגרום להתנהגות בלתי צפויה.

• אם ה-build ייכשל במהלך הניתוח או שלבי הטעינה, אחד או יותר מכללי ה-build שצוינו בקובץ WORKSPACE לא תואמים להפעלה מרחוק. מידע נוסף על סיבות אפשריות ופתרונות עקיפים מפורטים בכללי ההתאמה ללוחות זמנים של ביצוע מרחוק.

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