מערכת Kf משתמשת ב-buildpacks כדי להפוך את קוד המקור של אפליקציה לקובץ אימג' שניתן להפעלה. Cloud Native Buildpacks משתמשים בגרסה האחרונה של Buildpack API v3, וחברות כמו VMware ו-Heroku מוסיפות באופן פעיל תמיכה בגרסה 3 ל-buildpacks קיימים.
Kf תומך ב-Buildpacks שתואמים לגרסאות V2 ו-V3 של מפרט Buildpack API.
השוואה בין חבילות Buildpack בגרסה 2 ובגרסה 3
| חבילות Buildpack בגרסה 2 | חבילות Buildpack V3 | |
|---|---|---|
| שמות חלופיים | Cloud Foundry Buildpacks | Cloud Native Buildpacks (CNB), קובצי אימג' של Builder |
| סטטוס | הוחלף | היחס הנוכחי |
| בעלות | Cloud Foundry | Buildpacks.io |
| מקבץ | משותף על ידי ה-builder וסביבת זמן הריצה | אפשרות שונה לזמן הבנייה ולזמן הריצה |
| פיתוח מקומי | לא אפשרי | כן, עם pack CLI |
| חבילות Buildpack בהתאמה אישית | זמין בזמן ריצה | התכונה צריכה להיות מובנית בכלי ליצירת אתרים |
מחזור החיים של Buildpack
| שלב | Cloud Foundry | Kf עם Buildpacks V2 | Kf עם Buildpacks V3 |
|---|---|---|---|
| מיקום המקור | שירות BITS | רישום קונטיינרים | רישום קונטיינרים |
| מיקום ה-buildpack | BOSH/HTTP | HTTP | רישום קונטיינרים |
| מיקום המקבץ | BOSH | רישום קונטיינרים | רישום קונטיינרים |
| תוצאה | טיפה (קובץ בינארי של אפליקציה ללא מחסנית) | תמונה (טיפה על ערימה) | תמונה |
| זמן ריצה | טיפה מודבקת על ערימה ומופעלת | הפעלת התמונה שנוצרה | הפעלת התמונה שנוצרה |
Kf תמיד יוצרת תמונה מלאה שניתנת להרצה כתוצאה מתהליך ה-build שלה. לעומת זאת, ב-Cloud Foundry נוצרים חלקים של תמונה שניתנת להפעלה בזמן הבנייה, והשאר מתווסף בזמן הריצה.
Kf בחרה לפעול לפי המודל של יצירת תמונה מלאה תמיד, מהסיבות הבאות:
- אפשר לייצא תמונות, להריץ אותן באופן מקומי ולבדוק אותן באופן סטטי
- אבטחה וביקורת טובות יותר באמצעות כלים כמו אישור בינארי
- פריסות האפליקציות ניתנות לשחזור
Kf ו-Buildpacks
Kf מאחסן את הרשימה הגלובלית של חבילות buildpack וערימות ב-config-defaults ConfigMap ב-kf Namespace.
כל מרחב משקף את חבילות ה-buildpack האלה בשדה הסטטוס שלו.
כדי לראות את ההגדרות המלאות של מרחב שנקרא buildpack-docs, אפשר להריץ את הפקודה הבאה:
$ kf space buildpack-docs
Getting Space buildpack-docs
API Version: kf.dev/v1alpha1
Kind: Space
Metadata:
Creation Timestamp: 2020-02-14T15:09:52Z
Name: buildpack-docs
Self Link: /apis/kf.dev/v1alpha1/spaces/buildpack-docs
UID: 0cf1e196-4f3c-11ea-91a4-42010a80008d
Status:
Build Config:
Buildpacks V2:
- Name: staticfile_buildpack
URL: https://github.com/cloudfoundry/staticfile-buildpack
Disabled: false
- Name: java_buildpack
URL: https://github.com/cloudfoundry/java-buildpack
Disabled: false
Stacks V2:
- Image: cloudfoundry/cflinuxfs3
Name: cflinuxfs3
Stacks V3:
- Build Image: cloudfoundry/cnb:cflinuxfs3
Description: A large Cloud Foundry stack based on Ubuntu 18.04
Name: org.cloudfoundry.stacks.cflinuxfs3
Run Image: cloudfoundry/run:full-cnb
בקטע Build Config יש שלושה שדות שחשוב לבדוק:
- Buildpacks V2 מכיל רשימה של חבילות buildpack שתואמות לגרסה 2, לפי הסדר שבו הן יופעלו
- Stacks V2 מציין את ה-stacks שאפשר לבחור כדי להפעיל buildpack build מגרסה 2
- Stacks V3 מציין את ה-stacks שאפשר לבחור כדי להפעיל buildpack build של V3
אפשר גם להציג את הערימות ברשימה באמצעות kf stacks:
$ kf stacks
Getting stacks in Space: buildpack-docs
Version Name Build Image Run Image Description
V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3
V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04
קובצי אימג' של build בגרסה 3 כבר כוללים buildpacks מובנים, ולכן צריך להשתמש בפקודה kf buildpacks כדי לקבל את הרשימה:
$ kf buildpacks
Getting buildpacks in Space: buildpack-docs
Buildpacks for V2 stacks:
Name Position URL
staticfile_buildpack 0 https://github.com/cloudfoundry/staticfile-buildpack
java_buildpack 1 https://github.com/cloudfoundry/java-buildpack
V3 Stack: org.cloudfoundry.stacks.cflinuxfs3:
Name Position Version Latest
org.cloudfoundry.jdbc 0 v1.0.179 true
org.cloudfoundry.jmx 1 v1.0.180 true
org.cloudfoundry.go 2 v0.0.2 true
org.cloudfoundry.tomcat 3 v1.1.102 true
org.cloudfoundry.distzip 4 v1.0.171 true
org.cloudfoundry.springboot 5 v1.1.2 true
...
התאמה אישית של V3 Buildpacks
אתם יכולים להתאים אישית את חבילות ה-buildpack שזמינות למפתחים שלכם על ידי יצירת תמונת builder משלכם עם חבילות ה-buildpack שהם צריכים לקבל גישה אליהן. אפשר גם להשתמש בתמונות שנוצרו על ידי יוצרים אחרים.
שימוש בתמונה של כלי בנייה של צד שלישי
רשימה של חבילות CNB שפורסמו זמינה מ-Buildpack CLI pack. בזמן כתיבת המאמר הזה, הפלט של pack suggest-stacks הוא:
$ pack suggest-stacks
Stacks maintained by the community:
Stack ID: heroku-18
Description: The official Heroku stack based on Ubuntu 18.04
Maintainer: Heroku
Build Image: heroku/pack:18-build
Run Image: heroku/pack:18
Stack ID: io.buildpacks.stacks.bionic
Description: A minimal Cloud Foundry stack based on Ubuntu 18.04
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:base-cnb
Run Image: cloudfoundry/run:base-cnb
Stack ID: org.cloudfoundry.stacks.cflinuxfs3
Description: A large Cloud Foundry stack based on Ubuntu 18.04
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:full-cnb
Run Image: cloudfoundry/run:full-cnb
Stack ID: org.cloudfoundry.stacks.tiny
Description: A tiny Cloud Foundry stack based on Ubuntu 18.04, similar to distroless
Maintainer: Cloud Foundry
Build Image: cloudfoundry/build:tiny-cnb
Run Image: cloudfoundry/run:tiny-cnb
כדי לשנות את Kf כך שישתמש במערך שפורסם על ידי Heroku, עורכים את config-defaults ConfigMap ב-kf Namespace.
מוסיפים רשומה למפתח spaceStacksV3 כמו בדוגמה הבאה:
$ kubectl edit configmap config-defaults -n kf
spaceStacksV3: |
- name: org.cloudfoundry.stacks.cflinuxfs3
description: A large Cloud Foundry stack based on Ubuntu 18.04
buildImage: cloudfoundry/cnb:cflinuxfs3
runImage: cloudfoundry/run:full-cnb
- name: heroku-18
description: The official Heroku stack based on Ubuntu 18.04
buildImage: heroku/pack:18-build
runImage: heroku/pack:18
לאחר מכן, מריצים שוב את הפקודה stacks:
$ kf stacks
Getting stacks in Space: buildpack-docs
Version Name Build Image Run Image Description
V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3
V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04
V3 heroku-18 heroku/pack:18-build heroku/pack:18 The official Heroku stack based on Ubuntu 18.04
יצירת תמונת builder משלכם
משתמשים ב-Buildpack CLI pack כדי ליצור קובץ אימג' משלכם ל-builder. אתם יכולים לפעול לפי ההוראות במאמר packעבודה עם קובצי builder באמצעות create-builder כדי ליצור קובץ builder משלכם. אחרי שיוצרים את קובץ האימג', מעבירים אותו בדחיפה ל-Container Registry ומוסיפים אותו ל-config-defaults ConfigMap.
הגדרת מחסנית ברירת מחדל
לאפליקציות יוקצה מחסנית ברירת מחדל אם לא צוינה מחסנית במניפסט שלהן. הסטאק שמוגדר כברירת מחדל הוא הראשון ברשימת הסטאקים בגרסה 2 או בגרסה 3. אלא אם משנים את הערכים, נבחרת חבילת V2 לצורך תאימות ל-Cloud Foundry.
כדי להגדיר את Kf כך שישתמש במערך V3 במקום במערך V2, צריך להגדיר את השדה spaceDefaultToV3Stack ב-ConfigMap config-defaults במרחב השמות kf לערך "true":
$ kubectl edit configmap config-defaults -n kf
spaceDefaultToV3Stack: "true"
אפשר גם לשנות את האפשרות הזו לכל מרחב בנפרד על ידי שינוי ההגדרה של השדה spec.buildConfig.defaultToV3Stack ל-true או ל-false. אם לא מוגדר ערך, המערכת משתמשת בערך מ-config-defaults ConfigMap.
הערך config-defaults של spaceDefaultToV3Stack |
המרחב spec.buildConfig.defaultToV3Stack |
ערימת ברירת מחדל |
|---|---|---|
| unset | unset | V2 |
"false" |
unset | V2 |
"true" |
unset | V3 |
| כל | false |
V2 |
| כל | true |
V3 |