BazelCon 2022 מגיע בין 16 ל-17 בנובמבר לניו יורק באינטרנט.
הירשמו עוד היום!

התאמת כללי "בינל" לביצוע מרחוק

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

דף זה משתמש בטרמינולוגיה הבאה כשהוא מתייחס לסוגי סביבה או פלטפורמות שונים:

  • פלטפורמת מארח - היכן ב-Bazel פועלת.
  • פלטפורמת ביצוע – היכן פועלים פעולות Bazel.
  • פלטפורמת יעד – שבה פלט ה-build (ופעולות מסוימות) פועל.

סקירה

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

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

  • סביבות ביצוע מגוונות. הגדרות build מקומיות לא תמיד מתאימות לסביבות ביצוע מרחוק.

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

הפעלת כלים של build באמצעות כללי 'כלים'

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

ב-Bazel הוגדרו כללי בדיקה ובדיקה עבור Scala, Rust, ו-Go,{101. }וכללי פיצ'ר חדשים מתנהלים עכשיו בשפות אחרות ובכלים אחרים, כמו באש. אם לא קיים כלל 'כלי כלים' עבור הכלי שבו משתמש הכלל שלכם, מומלץ ליצור כלל מסוג 'כלי כלים'.

ניהול יחסי תלות מרומזים

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

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

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

ניהול קבצים בינאריים תלויים בפלטפורמה

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

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

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

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

ניהול כללי WORKSPACE בסגנון הגדרה

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

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

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

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

  • סנכרון לכלי עבודה מקומיים או לחפצים מקומיים. סמלי קישורים לכלים או לספריות המותקנים בפלטפורמת המארח שנוצרו באמצעות כללי WORKSPACE יגרמו לכשל ב-build לפלטפורמת ההפעלה מרחוק, כי Bazel לא יוכל לאתר אותם. במקום זאת, יש ליצור קישורים סימבוליים באמצעות פעולות build רגילות, כדי שניתן יהיה לגשת לכלים ולספריות הסימבוליסטיים מהעץ runfiles של Bazel. אין להשתמש ב-repository_ctx.symlink לקישור קובצי יעד מחוץ לספריית ה-repo החיצונית.

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

כדי לזהות התנהגות לא מזיקה, אפשר להשתמש ביומן הכללים של Workspace.

אם תלות חיצונית מבצעת פעולות ספציפיות שתלויות בפלטפורמה המארחת, יש לפצל את הפעולות האלה בין WORKSPACE וליצור כללים באופן הבא:

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

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

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

לדוגמה, הכללים של TensorFlow עבורcuda ו-python , WORKSPACE כללים מייצרים את הערכים הבאיםBUILD files הנתונים. להפעלה מקומית, נעשה שימוש בקבצים שהופקו על ידי בדיקת סביבת המארח. להפעלה מרחוק, הצהרת תנאי עם משתנה סביבה מאפשרת לכלל להשתמש בקבצים שנבדקים בתוך המאגר.

קובצי ה-BUILD מצהירים על genrules שיכולים לפעול הן באופן מקומי והן באופן מרוחק, ולבצע את העיבוד הנדרש קודם לכן דרך repository_ctx.symlink, כמוצג כאן.