השוואה בין V2 ל-V3 Buildpacks

Buildpack ממיר קוד מקור לקובץ הפעלה, ומשמש ליצירת קונטיינרים בצורה פשוטה, אמינה וניתנת לשחזור. ‫Kf תומך ב-buildpacks מגרסה 2 ומגרסה 3, וחשוב להבין את ההבדלים ביניהם.

חבילות Buildpack בגרסה 2

רוב האפליקציות של Cloud Foundry כבר משתמשות ב-buildpacks בגרסה 2. כשמשתמשים ב-buildpacks מגרסה 2 עם Kf, הקבצים הבינאריים של מחזור החיים וה-buildpacks מורדים ומוגדרים מכתובות ה-Git שלהם. לאחר מכן, Kf משתמש ב-CLI של lifecycle כדי להפעיל כל buildpack מול קוד המקור.

יתרונות

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

חסרונות

  • הגרסה הקודמת של buildpack הוחלפה בגרסה 3.
  • ביצועים ואמינות נמוכים יותר. צינור ה-build של Kf דורש יותר קלט/פלט בשביל חבילות buildpack מגרסה 2.
  • פחות משאבים קהילתיים.
  • ‫Kf תומך רק במאגרי git של OSS.

חבילות Buildpack בגרסה 3

‫V3 buildpacks הוא פרויקט של Cloud Native Computing Foundation‏ (CNCF) עם מפרט מוגדר היטב, CLI‏ (pack) וקהילה גדלה שמפתחת שפות ומסגרות שונות.ל- Google Cloud יש גם קבוצה משלו של Google Cloud's buildpacks.

ל-buildpacks בגרסה 3 יש שני קונטיינרים כלליים של OCI:

  • תמונת Builder
  • הרצת תמונה

תמונת Builder

קובץ האימג' של ה-builder משמש בזמן שקוד המקור שלכם עובר build לקונטיינר שאפשר להפעיל. בתמונה יש את הסקריפטים detect וכלי השירות האחרים שנדרשים כדי לקמפל קוד מקור.

הרצת תמונה

קובץ האימג' להרצה הוא קובץ הבסיס שעליו נבנה הקונטיינר. כלומר, זו תמונת הבסיס שתפעל כשהאפליקציה תופעל.

שכבות

‫Buildpacks בגרסה 3 משתמשים בשכבות כדי ליצור את הקונטיינר הסופי. לכל חבילת buildpack שנכללת ב-build יש אפשרות לשנות את מערכת הקבצים ואת משתני הסביבה של האפליקציה. הגישה הזו מאפשרת ליצור חבילות buildpack דקות וכלליות יותר.

‫Buildpacks מגרסה 3 מבוססים על קונטיינרים של OCI. לשם כך, צריך לאחסן את קובץ האימג' של V3 Builder במאגר קונטיינרים שלצינור ה-build של Kf יש גישה אליו. צינור ה-build משתמש בתמונת ה-builder כדי להחיל את הסקריפטים הבסיסיים ליצירת קוד המקור בקונטיינר שניתן להפעלה.

יתרונות

חסרונות

  • יכול להיות שיידרשו עדכונים בקוד או בתהליך. לדוגמה, ה-buildpack של Java דורש קוד מקור, בעוד שה-buildpack של V2 דורש קובץ jar.
  • ‫Buildpacks מגרסה V3 הם חדשים יותר, ויכול להיות שיידרש אימות נוסף (אם משתמשים ב-buildpacks שפותחו על ידי הקהילה).

מקבצי Kf

הצגת מקבצי התמונות

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

כדי לראות אילו חבילות ערוצים זמינות בחלל, קודם צריך לוודא שהחלל מטורגט:

kf target -s myspace

אחר כך אפשר להשתמש בפקודת המשנה kf stacks כדי להציג את רשימת ה-Stacks:

kf stacks

הפלט מציג גם את V2 וגם את V3 Stacks:

Getting stacks in Space: myspace
Version  Name                                Build Image                                                                                          Run Image
V2       cflinuxfs3                          cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5      cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V3       kf-v2-to-v3-shim                    gcr.io/kf-releases/v2-to-v3:v2.7.0                                                                   gcr.io/buildpacks/gcp/run:v1                                                                       This is a stack added by the integration tests to assert that v2->v3 shim works
V3       google                              gcr.io/buildpacks/builder:v1                                                                         gcr.io/buildpacks/gcp/run:v1                                                                       Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
V3       org.cloudfoundry.stacks.cflinuxfs3  cloudfoundry/cnb:cflinuxfs3@sha256:f96b6e3528185368dd6af1d9657527437cefdaa5fa135338462f68f9c9db3022  cloudfoundry/run:full-cnb@sha256:dbe17be507b1cc6ffae1e9edf02806fe0e28ffbbb89a6c7ef41f37b69156c3c2  A large Cloud Foundry stack based on Ubuntu 18.04

הגדרת מחסניות

אפשר לעדכן את הגדרות ה-Stack על ידי עריכה של kfsystem Custom Resource:

kubectl edit kfsystem kfsystem

בדוגמה הזו מוגדרים buildpacks של V3 Stack: Google Cloud 

spec:
  kf:
    config:
      spaceStacksV3:
      - name: google
        description: Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
        buildImage: gcr.io/buildpacks/builder:v1
        runImage: gcr.io/buildpacks/gcp/run:v1

עכשיו אפשר להעביר את ה-Stack החדש:

kf push myapp --stack google

בדוגמה הזו מוגדר ה-buildpack של Ruby V2, והגדרות ברירת המחדל של צינור ה-build מוגדרות לשימוש ב-V2 Stacks:

spec:
  kf:
    config:
      spaceDefaultToV3Stack: false
      spaceBuildpacksV2:
      - name: ruby_buildpack
        url: https://github.com/cloudfoundry/ruby-buildpack
      spaceStacksV2:
      - name: cflinuxfs3
        image: cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5

העברה מ-V2 ל-V3 Buildpack

‫Kf מספקת מחסנית V3 לבניית אפליקציות שנבנו באמצעות buildpacks רגילים של V2, באמצעות מחסנית בשם kf-v2-to-v3-shim. סט הכלים kf-v2-to-v3-shim נוצר בהתאם ל-standard V3 buildpacks API. עם כל גרסה של Kf נוצר אימג' של builder שמתוחזק על ידי Google, בהתאם לתהליך הסטנדרטי של buildpack. קובץ האימג' של ה-builder צובר רשימה של buildpacks בגרסה 3 שנוצרו באותו תהליך שבו משתמשים בפקודה kf wrap-v2-buildpack. תמונות ה-buildpack של V3 נוצרות באמצעות תמונות ה-buildpack הסטנדרטיות של V2. חשוב לציין שחבילות ה-buildpack של V3 לא מכילות את הקובץ הבינארי של חבילות ה-buildpack של V2 שאליהן יש הפניה. במקום זאת, מתבצעת הפניה לקובצי האימג' של V2 buildpack, והביטים מורדים בזמן ה-build של האפליקציה (על ידי הפעלת kf push).

בזמן ה-Build של האפליקציה, חבילת ה-Buildpack V2 מורדת ממאגר ה-Git המתאים. כשמריצים את זיהוי הגרסה השלישית, הוא מוקצה לסקריפט הזיהוי של גרסה 2 שהורד. עבור קבוצת ה-buildpack הראשונה שעוברת את הזיהוי, המערכת ממשיכה לשלב הבנייה, שבו מוקצית הרשאת ביצוע הבנייה לסקריפט הבנייה שהורד בגרסה 2.

יש תמיכה בחבילות buildpack הבאות מגרסה 2 במערך kf-v2-to-v3-shim:

Buildpack מאגר Git
java_buildpack https://github.com/cloudfoundry/java-buildpack
dotnet_core_buildpack https://github.com/cloudfoundry/dotnet-core-buildpack
nodejs_buildpack https://github.com/cloudfoundry/nodejs-buildpack
go_buildpack https://github.com/cloudfoundry/go-buildpack
python_buildpack https://github.com/cloudfoundry/python-buildpack
binary_buildpack https://github.com/cloudfoundry/binary-buildpack
nginx_buildpack https://github.com/cloudfoundry/nginx-buildpack

אפשרות 1: העברת אפליקציות שפותחו באמצעות buildpacks רגילים בגרסה 2

כדי ליצור אפליקציות באמצעות מחסנית kf-v2-to-v3-shim, משתמשים בפקודה הבאה:

kf push myapp --stack kf-v2-to-v3-shim

‫kf-v2-to-v3-shim Stack יזהה באופן אוטומטי את זמן הריצה באמצעות חבילות ה-buildpack העטופות מגרסה 2. תמונת האפליקציה שמתקבלת נוצרת באמצעות התקן V3 וצינור ה-build, אבל ה-builder של חבילת ה-buildpack המקבילה V2.

אפשרות 2: העברת אפליקציות שנוצרו באמצעות buildpacks מותאמים אישית מגרסה 2

ל-Kf יש כלי להעברת buildpack שיכול לקחת buildpack מגרסה 2 ולעטוף אותו ב-buildpack מגרסה 3. אחר כך אפשר להשתמש ב-buildpack העטוף בכל מקום שבו יש buildpacks בגרסה 3.

kf wrap-v2-buildpack gcr.io/your-project/v2-go-buildpack https://github.com/cloudfoundry/go-buildpack --publish

הפעולה הזו תיצור קובץ אימג' של buildpack בשם gcr.io/your-project/v2-go-buildpack. אחר כך אפשר להשתמש בו כדי ליצור כלי בנייה, לפי ההוראות במאמר יצירת כלי בנייה.

פקודת המשנה הזו משתמשת בשורות הפקודה הבאות באופן שקוף:

  • go
  • git
  • pack
  • unzip

מומלץ להשתמש ב-Cloud Shell Editor כדי לוודא שכל פקודת משנה זמינה בנתיב הנכון ושהיא הגרסה הנכונה.

בעיות מוכרות

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

  • מאגרי קונטיינרים פרטיים לקובצי אימג' של builder בגרסה 3.
  • שמירה במטמון בגרסה 3.
  • חבילות buildpack בגרסה 2 שדורשות פרטי כניסה ל-Git.