במאמר הזה נסביר איך מתחילים להשתמש ב-Skaffold כחלק מ-Cloud Deploy, כולל:
- הגדרת Skaffold לשימוש עם צינור עיבוד נתונים לפריסה של Cloud Deploy
- שימוש ב-Skaffold וב-Cloud Deploy עם כלי רינדור של צד שלישי, כמו Helm ו-Kustomize
- אפשרות נוספת: שימוש ב-Skaffold לפיתוח מקומי
- אופציונלי: שימוש ב-Skaffold לאינטגרציה רציפה (CI) ולפיתוח רציף (CD)
למה כדאי להשתמש ב-Skaffold?
רוצים לדעת למה Cloud Deploy משתמש ב-Skaffold, ולמה צריך לנהל את ההגדרות של Skaffold? כדאי לקרוא בהמשך.
יש לי ניסיון ב-CI/CD, אבל אני לא משתמש ב-Skaffold כרגע
Skaffold הוא כלי שורת פקודה בקוד פתוח שמיועד לשיפור הפרודוקטיביות של מפתחים. הוא מתזמן פיתוח רציף, אינטגרציה רציפה (CI) ופיתוח רציף (CD).
Skaffold מספק הגדרה דקלרטיבית וניידת, באמצעות ארכיטקטורה שניתנת להרחבה, ומאפשר לכם להשתמש בכלים שונים לשלב העיבוד.
כשיוצרים גרסה, Cloud Deploy קורא ל-Skaffold כדי לעבד את המניפסטים. בזמן הפריסה, Cloud Deploy קורא שוב ל-Skaffold כדי להחיל את המניפסטים האלה ולפרוס את האפליקציה לכל יעד בהתקדמות. אחרי הפריסה, Skaffold מבצע בדיקות תקינות כדי לעקוב אחרי זמן הריצה של היעד ולוודא שהפריסה בוצעה בהצלחה.
Skaffold לפיתוח מתמשך
כשמשתמשים ב-Skaffold לפיתוח רציף, התמונות נוצרות, נבדקות ונפרסות באשכול (או ב-Minikube) כשמשנים את הקוד. Cloud Code ל-VS Code וCloud Code ל-IntelliJ הם תוספים לסביבות פיתוח משולבות (IDE) שמשלבים את Skaffold ב-Visual Studio Code ובסביבות פיתוח משולבות של JetBrains, כדי לאפשר פיתוח רציף.
Skaffold לפיתוח רציף
אפשר גם להשתמש ב-Skaffold לפיתוח רציף (continuous delivery), עם שלבים של בנייה, פריסה, עיבוד והחלה. Cloud Deploy משתמש ביכולות render ו-apply של Skaffold. כדי להשתמש ב-Cloud Deploy, צריך לפחות skaffold.yamlקובץ תצורה תקין.
באמצעות Skaffold, אפשר גם לבצע שילוב עם כלים לניהול מניפסטים של צד שלישי, כמו Helm ו-Kustomize.
שימוש ב-Skaffold בצורה הזו מאפשר לכם להשתמש בתכונות של הכלים האלה כדי לעבד מניפסטים. kubectl נשאר הפורס של קובצי המניפסט האלה.
אין לי ניסיון בפריסה ב-Kubernetes
באמצעות Skaffold, אפשר להגדיר קבוצה בסיסית של מניפסטים לכל הפריסות. לאחר מכן תוכלו להשתמש במנוע העיבוד של Skaffold, דרך Cloud Deploy, כדי לעבד ואז לפרוס כל מניפסט ספציפי לפריסה מאחד ממניפסטים הבסיסיים האלה.
מידע נוסף על ניהול מניפסטים, כולל דוגמאות לשימוש ב-Skaffold וב-Cloud Deploy עם כלים נפוצים ליצירת תבניות של מניפסטים, כמו Helm ו-Kustomize.
מה נדרש כדי להפעיל את Cloud Deploy?
כדי להשתמש בצינור העברת נתונים בסיסי של Cloud Deploy, קובץ ההגדרות skaffold.yaml צריך לכלול לפחות את ההגדרות הבאות:
פרטי הכותרת שנדרשים בכל ההגדרות של
skaffold.yaml:apiVersion: skaffold/v4beta7 kind: Configפסקה
manifests, ל-GKE, לאשכולות GKE מצורפים או ל-Cloud Run, שבה מפורטים כל מניפסטים הגולמיים של Kubernetes (אלא אם אתם משתמשים בכלי לניהול מניפסטים, כמו Helm או Kustomize).דוגמה לשימוש במניפסט גולמי של Kubernetes:
manifests: rawYaml: - deployment.yamlאם אתם מתכננים להשתמש בכלי עיבוד (כמו Helm או Kustomize) כדי לעבד מניפסטים, כדאי לעיין במאמרים הוספת תמיכה ב-Helm לקובץ skaffold.yaml והוספת תמיכה ב-Kustomize לקובץ skaffold.yaml כדי לקבל הנחיות להגדרת Skaffold לשימוש בכלים האלה.
דוגמאות ל-Helm ול-Kustomize מופיעות במאמר בנושא ניהול מניפסטים
פסקה
deploy, עםdeploy.kubectlלפריסה ב-GKE או באשכולות GKE מצורפים, אוdeploy.cloudrunלפריסה ב-Cloud Run.באשכולות GKE ובאשכולות GKE מצורפים:
deploy: kubectl: {}הפסקה deploy פורסת את מניפסטים האפליקציה שסופקו בפסקה manifests.
למטרות Cloud Run:
deploy: cloudrun: {}ה-stanza של הפריסה פורס את המניפסטים של האפליקציה שסופקו ב-stanza של המניפסטים.
אם אתם משתמשים ביעדים מותאמים אישית, ל-skaffold.yaml צריך להיות כותרת (apiVersion ו-kind:), בנוסף לפעולות מותאמות אישית שבהן ישתמש היעד המותאם אישית אם סוג היעד המותאם אישית לא מפנה כבר להגדרת Skaffold מרוחקת.
יצירת קובץ skaffold.yaml
Cloud Deploy משתמש ב-Skaffold לעיבוד ולפריסה של האפליקציות שלכם.
לכל מהדורה צריך לספק לפחות skaffold.yaml קובץ שמזהה את קובצי המניפסט שבהם יש להשתמש. בקטע הקודם מוסבר מה צריך לכלול בקובץ הזה.
יצירת skaffold.yaml באמצעות Cloud Deploy
אם אין לכם קובץ skaffold.yaml, אבל יש לכם מניפסט יחיד של Kubernetes או קובץ הגדרת שירות של Cloud Run, Cloud Deploy יכול ליצור בשבילכם קובץ skaffold.yaml.
אחרי שהגרסה תהיה מוכנה, קובץ ה-Skaffold שנוצר יהיה זמין בספריית הביניים של מקור Cloud Storage.
הפקודה הבאה כוללת את הדגל --from-k8s-manifest, שמעביר את מניפסט Kubernetes. Cloud Deploy משתמש במידע במניפסט כדי ליצור את skaffold.yaml, שמשמש לאחר מכן להפצה.
gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --from-k8s-manifest=MANIFEST --region=REGION
כדי ליצור את skaffold.yaml מקובץ YAML של שירות Cloud Run, משתמשים באותה פקודה, אבל עם --from-run-manifest במקום --from-k8s-manifest
שימוש באחד מהדגלים האלה עם הדגל --skaffold-file או עם הדגל --source יוצר שגיאה.
שימוש בקובץ skaffold.yaml שנוצר
הקובץ skaffold.yaml שנוצר מתאים להטמעה, ללמידה ולהדגמה של Cloud Deploy. אחרי שתכירו את Cloud Deploy, תוכלו להשתמש בתצורת Skaffold שמבדילה בין היעדים (באמצעות פרופילים של Skaffold) לעומסי עבודה בסביבת ייצור.
כשמשתמשים בקובץ skaffold.yaml שנוצר כנקודת התחלה ליצירת קובץ הגדרות Skaffold משלכם, חשוב להשתמש בקובץ בארכיון המקור של הרינדור, ולא בקובץ המעובד. אפשר להוריד את מקור הרכיב הגרפי מהכרטיסייה Artifacts בדף Release details.
ה-
skaffold.yamlשנוצר נכלל במקור העיבוד שמאוחסן בקטגוריה של Cloud Storage.כדי לראות את הקובץ הזה, צריך להוריד את קובץ ה-
.tar.gzולחלץ אותו.ה-
skaffold.yamlשעבר רינדור זמין בפריטי היעד.בקטע Target artifacts (פריטי מידע על היעד), לוחצים על View artifacts (הצגת פריטי מידע).

שימוש ב-Skaffold לפיתוח מקומי
אחד היתרונות של Skaffold הוא שאפשר להשתמש בו לפיתוח מקומי ול-CI/CD.
במצב dev, Skaffold עוקב אחרי קובצי המקור, וכשהוא מזהה שינוי, הוא בונה מחדש את התמונות, בודק מחדש ומבצע פריסה מחדש של הקונטיינרים לאשכול minikube (לדוגמה) במחשב המקומי.
כשמשתמשים ב-Skaffold בצורה הזו, אפשר להשתמש באותן פקודות באופן מקומי כמו בפריסה מרחוק.
אם אתם משתמשים ב-Skaffold לפיתוח מקומי, אתם יכולים להגדיר פרופילים נפרדים של Skaffold ליעדים שלכם, ופסקה של פריסת ברירת מחדל לפיתוח מקומי.
כשמפסיקים את מצב dev, Skaffold מנקה את הארטיפקטים שנפרסו מהאשכול.
שימוש ב-Skaffold ל-CI/CD
בנוסף לשימוש ב-Skaffold לבנייה ולפריסה מקומיות רציפות, אפשר להשתמש ב-Skaffold ל-CI/CD. Cloud Deploy משתמש בתכונות CI/CD ב-Skaffold כדי לעבד ולהחיל את המניפסטים ולפרוס את האפליקציה ליעדים שהגדרתם, בהינתן קובצי אימג' של קונטיינרים שנבנו באמצעות כלי CI כמו Cloud Build ומאגר אימג'ים כמו Artifact Registry.
עיבוד, פריסה והחלה
ב-Skaffold, תהליך העיבוד של המניפסט נפרד מהפריסה.
Cloud Deploy קורא ל-skaffold render כדי לעבד את המניפסטים, ול-skaffold apply כדי להחיל אותם על היעד.
ההפרדה הזו בין עיבוד לבין החלה מאפשרת לכם לתעד את המצב הדקלרטיבי המלא של האפליקציה בהגדרות, כך שאפשר להחיל אותו בצורה בטוחה וחוזרת (למשל, לצורך חזרה לגרסה קודמת). הטכניקה הזו גם מקלה על קבלת אישורים. מכיוון שקובצי המניפסט מעובדים לכל היעדים לפני הפריסה הראשונה, אפשר לראות את קובץ ה-YAML המעובד שיחול על כל יעד.
Cloud Deploy לא תומך בשימוש באמצעי פריסה אחרים כדי לפרוס את האפליקציה. עם זאת, אפשר להשתמש בכלים כמו Helm או Kustomize לעיבוד.
מידע נוסף על פריסה באמצעות Cloud Deploy עם kubectl ככלי הפריסה זמין במאמר ארכיטקטורת שירות Cloud Deploy.
מידע על פרופילי Skaffold
אפשר ליצור פרופילים נפרדים של Skaffold – שמזוהים ב-skaffold.yaml, בקטע profiles:.
כשמשתמשים בפרופילים של Skaffold עם Cloud Deploy, יכול להיות שתיצרו פרופילים נפרדים לכל היעדים או לחלק מהם. לדוגמה, פרופילים שונים ל-dev, ל-staging ול-prod.
לא צריך פרופילים כדי להשתמש ב-Skaffold ב-Cloud Deploy, אבל הם שימושיים להגדרת התאמות אישיות של מניפסטים בין היעדים, למשל באמצעות קובצי kustomization.yaml שונים של Kustomize לכל יעד.
הוספת תמיכה ב-Kustomize ל-skaffold.yaml
שילוב הגדרות Kustomize עם הגדרות Cloud Deploy או Skaffold כולל את הפעולות הבאות:
כוללים קובץ
kustomization.yamlבין קובצי ההגדרות.אפשר לאחסן את קובצי ההגדרות בספרייה מקומית או בקטגוריה של Cloud Storage.
בקובץ
skaffold.yaml, יוצרים ביתdeployלכל פרופיל.אפשר גם להשתמש ב-stanza
deployמחוץ לפרופילים מוגדרים, אם לא משתמשים בפרופילים או אם רוצים להגדיר פריסה כברירת מחדל שלא מקושרת לפרופיל.זוהי דוגמה לקובץ הגדרות של Skaffold שמציג קטעי
deployלכל פרופיל, ומשתמש באפליקציה לדוגמה פיקטיבית בשםmy-app:apiVersion: skaffold/v4beta7 kind: Config build: artifacts: - image: my-app-web-profiles context: my-app-web-profiles - image: my-app-application-profiles context: my-app-application-profiles googleCloudBuild: projectId: ${PROJECT_ID} profiles: - name: local manifests: kustomize: paths: - my-app-application-profiles/kubernetes/local - name: test manifests: kustomize: paths: - my-app-application-profiles/kubernetes/test - name: staging manifests: kustomize: paths: - my-app-application-profiles/kubernetes/staging - name: prod manifests: kustomize: paths: - my-app-application-profiles/kubernetes/prod deploy: kubectl: {}ההגדרה של Skaffold שמוצגת כאן כוללת פרופילים נפרדים ליעדים
test,stagingו-prod. מוצג גם פרופיל לפיתוח מקומי. בכל פרופיל יש קטעdeploy.kustomizeעם נתיב שמצביע על המיקום של ההתאמה האישית שבה רוצים להשתמש עבור היעד הזה.
הוספת תמיכה ב-Helm ל-skaffold.yaml
אפשר להשתמש ב-Helm כדי לעבד את המניפסטים. Cloud Deploy לא משתמש ב-Helm כדי לפרוס את האפליקציות, והוא תומך רק ב-kubectl ככלי פריסה.
כדי להשתמש ב-Helm, צריך את תרשים Helm או תרשימי Helm, ששמורים בכל מיקום שאפשר להפנות אליו מתוך skaffold.yaml. המיקום הזה יכול להיות במערכת קבצים, במאגר, אולי יחד עם skaffold.yaml, או במאגר של Open Container Initiative (OCI).
כדי להשתמש בתרשים Helm, מוסיפים קטע helm לקובץ skaffold.yaml.
apiVersion: skaffold/v4beta7
kind: Config
build:
artifacts:
- image: skaffold-helm-image
manifests:
helm:
releases:
- name: skaffold-helm-image
chartPath: charts
deploy:
kubectl: {}
skaffold.yaml ההפניה
מראה מה נדרש בפסקה helm הזו.
תכונות של Skaffold שלא נתמכות
אי אפשר להשתמש בתכונות הבאות של Skaffold ב-Cloud Deploy:
-
אי אפשר להשתמש ב-
--module=כדי לבחור מודולים ספציפיים ל-build,render,applyוכו'. יש תמיכה במודולים סטטיים. ב-Helm, יש אפשרות ליצור מרחב שמות אם הוא לא קיים.
המאמרים הבאים
באתר של Skaffold אפשר לקרוא על אופן הפעולה של הכלי ועל מה שהוא יכול לעשות בשבילכם.
תרגול שימוש ב-Cloud Deploy עם פרופילים של Kustomize ו-Skaffold.
איך Cloud Deploy בוחר את גרסאות הכלים לשימוש ואיך קובעים אילו גרסאות נמצאות בשימוש.
איך משתמשים בפרופילים של Skaffold עם כלים מתקדמים לניהול מניפסטים כמו Helm, Kustomize ו-kpt.