פריסת האפליקציה

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

לפני שמתחילים

בקטע הזה מתוארים הדברים שצריך להכין לפני שפורסים את האפליקציה באמצעות Cloud Deploy.

  • מוודאים שלחשבון השירות להרצת התהליך יש את התפקידים וההרשאות הנדרשים ב-IAM.

  • יצירת צינור העברת נתונים ויעדים.

    אפשר לפרוס באמצעות Cloud Deploy אל Google Kubernetes Engine,‏ Cloud Run,‏ GKE attached clusters ויעדים מותאמים אישית. הגדרת היעד משתנה בהתאם למיקום הפריסה.

  • יש לכם קובצי אימג' של קונטיינרים ומניפסטים.

    כדי לפרוס, צריך קובץ אימג' אחד או יותר של קונטיינר, ומניפסטים של Kubernetes (לפריסה ב-GKE) או קובצי YAML של שירות (לפריסה ב-Cloud Run).

    כדי ליצור את התמונות ולמקם אותן, צריך פייפליין של אינטגרציה רציפה (CI) או תהליך אחר. כלי ה-CI יכול להיות Cloud Build,‏ Jenkins או כל כלי אחר שיוצר תמונות קונטיינר שאפשר לספק לצינור העברת נתונים של Cloud Deploy.

  • יש לכם קובץ הגדרות skaffold.yaml.

    ‫Cloud Deploy קורא ל-skaffold render כדי לעבד את המניפסטים של Kubernetes באמצעות הקובץ הזה, וקורא ל-skaffold apply כדי לפרוס אותם ליעד. כדי לעשות את זה, Skaffold צריך לפחות skaffold.yaml מינימלי. יש שתי דרכים לקבל אותו:

    • אפשר ליצור אחד משלך.

      שימו לב: השורה הראשונה בקובץ skaffold.yaml צריכה להכיל הפניה ל-apiVersion שנתמך על ידי Skaffold, כמו בדוגמה הזו:

      `apiVersion: skaffold/v4beta7`

    • ליצור אותו בשבילכם.

      אם עדיין אין לכם קובץ skaffold.yaml, אתם יכולים לבקש מ-Cloud Deploy ליצור אותו בשבילכם. הקובץ הזה מתאים להצטרפות, ללמידה או להדגמה של Cloud Deploy, ולא לשימוש בעומסי עבודה בסביבת ייצור.

    פרטים נוספים מופיעים במאמר בנושא שימוש ב-Skaffold עם Cloud Deploy. בנוסף, במאמר ניהול מניפסטים ב-Cloud Deploy יש פרטים נוספים על שימוש ב-Skaffold וב-Cloud Deploy עם כלי ניהול מניפסטים, כמו Helm,‏ Kustomize ו-kpt.

הגדרת Cloud Deploy לסביבת זמן הריצה הרצויה

אפשר לפרוס את האפליקציה באמצעות Cloud Deploy בכל אחת מסביבות זמן הריצה הבאות:

הפעלת צינור אספקה כדי ליצור גרסה

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

  1. מריצים את תהליך האינטגרציה הרציפה (CI) הרגיל ויוצרים את הארטיפקט או הארטיפקטים שניתן לפרוס.

  2. מפעילים את צינור עיבוד הנתונים לפיתוח רציף על ידי קריאה ל-Cloud Deploy כדי ליצור גרסת הפצה.

    מריצים את הפקודה הבאה מהספרייה שמכילה את קובץ ההגדרות של Skaffold:

    gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION

    הפקודה הזו יוצרת קובץ tar של כל התוכן בספרייה ובכל ספריות המשנה, ולכן לא מומלץ להריץ אותה מהספרייה הראשית או מהספרייה הבסיסית. מריצים את הפקודה מהספרייה שמכילה את קובץ ההגדרות של Skaffold, או כוללים את האפשרות --source= שמתוארת בהמשך.

    בפקודה הזו…

    ‫RELEASE_NAME הוא השם שרוצים לתת לגרסה הזו. השם חייב להיות ייחודי בין כל הגרסאות של צינור ההפצה הזה.

    אפשר לציין שמות דינמיים של גרסאות על ידי הוספת '$DATE' או '$TIME' או שניהם. לדוגמה, אם מפעילים את הפקודה הזו בשעה 15:07 (שעון UTC), הערך של 'rel-$TIME' יהיה rel-1507. ‫'$DATE' ו-'$TIME' צריכים להיות בגרשיים בודדים, והשעה היא שעת UTC במחשב שבו מפעילים את הפקודה.

    ‫PIPELINE_NAME הוא השם של צינור העברת הנתונים (pipeline) של הפריסה שינהל את הפריסה של הגרסה הזו בתהליך ההתקדמות של יעדי הפריסה. השם הזה צריך להיות זהה לשם שמופיע בשדה name בהגדרת צינור הנתונים.

    ‫REGION הוא שם האזור שבו אתם יוצרים את הגרסה, למשל us-central1. זהו שדה חובה.

הפקודה הזו מעלה קובץ tar שמכיל את ההגדרות לקטגוריה ב-Cloud Storage ויוצרת את הגרסה. בנוסף, Cloud Deploy יוצר באופן אוטומטי פריסה ומפריס את התמונה ליעד הראשון שמוגדר בצינור העברת התוכן.

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

  • --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

    אוסף של החלפות של שם תמונה בנתיב מלא של תמונה.

  • --build-artifacts=<path/file>

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

שתי האפשרויות האלה בלעדיות.

אפשר גם לכלול אחד מהדגלים הבאים כדי ש-Cloud Deploy ייצור עבורכם קובץ skaffold.yaml:

  • --from-k8s-manifest=K8S_MANIFEST

    ההגדרה שנוצרת ב-Skaffold מבוססת על מניפסט Kubernetes שמעבירים לדגל הזה. שימוש בדגל הזה עם הדגל --skaffold-file או עם הדגל --source יוצר שגיאה. פרטים נוספים מופיעים במאמר בנושא יצירת skaffold.yaml.

  • --from-run-manifest=RUN_MANIFEST

    ההגדרה שנוצרת ב-Skaffold מבוססת על קובץ ה-YAML של שירות Cloud Run שמעבירים לדגל הזה. שימוש בדגל הזה עם הדגל --skaffold-file או עם הדגל --source יוצר שגיאה. פרטים נוספים מופיעים במאמר בנושא יצירת skaffold.yaml.

שתי האפשרויות האלה בלעדיות.

אפשר גם לכלול קובץ .gcloudignore אם יש בספרייה קבצים שלא רוצים לכלול בקובץ ה-tar.

יצירת גרסה במסוף Google Cloud

אפשר להשתמש במסוף Google Cloud כדי ליצור גרסה להפצה לצורך צינור העברה. האפשרות הזו שימושית לניסיון של Cloud Deploy, אבל היא לא מתאימה לעומסי עבודה בסביבת ייצור.

ההליך הבא מניח שכבר יצרתם צינור להעברת נתונים ויעד אחד או יותר. (אפשר גם להשתמש במסוף Google Cloud כדי ליצור צינור להעברת נתונים).

  1. בדף פרטים של צינור העברת נתונים, לוחצים על יצירת פריט תוכן בצינור העברת נתונים ספציפי.

    פרטים על צינור העברת התוכן, כולל הכפתור ליצירת פריט תוכן

  2. בשדה Choose a container (בחירת מאגר), מדביקים או מקלידים את הנתיב לתמונת מאגר התגים שרוצים לפרוס. אפשר גם להשתמש במאגר התגים שמופיע בשדה הזה כברירת מחדל לצורך הערכה.

    אפשר גם ללחוץ על Select (בחירה) כדי לבחור קובץ אימג' של קונטיינר מ-Artifact Registry.

  3. מזינים שם ייחודי לגרסה בשדה שם הגרסה, או משתמשים בשם ברירת המחדל שמופיע.

  4. נותנים שם להשקה בשדה Rollout name (שם ההשקה) או משתמשים בשם ברירת המחדל שמופיע.

    השם הזה משמש להשקה של הגרסה הזו ליעד הראשון. כשמגדירים יעדים נוספים, אפשר לתת שם להשקה בתיבת הדו-שיח קידום או בפקודה gcloud deploy releases promote.

  5. אם רוצים, מוסיפים תיאור לגרסה הזו בשדה Description.

  6. בקטע Deployment details (פרטי הפריסה), מזינים שם לפריסת GKE או לשירות Cloud Run, או משתמשים בשם ברירת המחדל שמופיע.

    ב-GKE, ‏ Cloud Deploy יוצר בשבילכם את המניפסט. ב-Cloud Run, ‏ Cloud Deploy יוצר את הגדרת השירות, שמשמשת ליצירת השירות.

  7. לוחצים על יצירה.

    תיבת הדו-שיח ליצירת גרסה

‫Cloud Deploy משתמש במניפסט שנוצר או בהגדרת השירות של Cloud Run, ובקובץ skaffold.yaml שנוצר, כדי ליצור את הגרסה.

שינוי הזמן הקצוב לתפוגת הפריסה

בפריסות ב-GKE ובאשכולות שמצורפים ל-GKE, יש שלושה פסק זמן נפרדים שמשפיעים על משך הזמן שהמערכת ממתינה עד ש-Kubernetes ידווח על פריסה יציבה:

  • ל-Cloud Build יש הגבלת זמן של שעה אחת על פעולות ש-Cloud Build מבצע עבור Cloud Deploy.

    אפשר לשנות את הזמן הקצוב לתפוגה בהגדרות של סביבת ההפעלה.

  • ל-Skaffold יש פסק זמן לבדיקת תקינות (deploy.statusCheckDeadlineSeconds), שהוא משך הזמן בשניות להמתנה עד שהפריסות יתייצבו.

    ברירת המחדל היא 600 שניות (10 דקות). כדי להשתמש בערך הזמן הקצוב לתפוגה הזה, צריך להגדיר את deploy.statusCheck ל-true. כברירת מחדל, זה המצב. אם statusCheck הוא false, לא מתבצעת בדיקת סטטוס, וההשקה מסומנת כהצלחה אחרי ש-kubectl apply מסתיים בהצלחה.

  • במשאבי Kubernetes של kind: Deployment, יש Deployment.spec.progressDeadlineSeconds, שהוא משך הזמן ש-Kubernetes מחכה עד שפריסת ה-Deployment תדווח כיציבה.

    ההגדרה הזו של הזמן הקצוב לתפוגה רלוונטית רק למשאבי Deployment. כך פועלים שני פרקי הזמן הקצובים הראשונים:

    • אם Deployment.spec.progressDeadlineSeconds ב-Kubernetes לא מוגדר, אז זמן קצוב לתפוגה של בדיקת התקינות של Skaffold הוא זמן קצוב לתפוגה שיהיה בתוקף, בין אם זה זמן קצוב לתפוגה שמוגדר כברירת מחדל ובין אם הוא מוגדר באופן מפורש.

    • אם הערך של Deployment.spec.progressDeadlineSeconds ב-Kubernetes מוגדר, Skaffold מתעלם מהזמן הקצוב לתפוגה של בדיקת התקינות שלו, והזמן הקצוב לתפוגה שחל הוא הזמן הקצוב לתפוגה של ההתקדמות ב-Kubernetes. עם זאת, אם הזמן הקצוב לתפוגה ב-Kubernetes מוגדר במפורש ל-600 (10 דקות), ‏ Skaffold מניח שזו ברירת המחדל (לא מוגדר) ומתעלם ממנו, והזמן הקצוב לתפוגה ב-Skaffold נמצא בשימוש (אם הוא מוגדר).

    • אם לא מוגדר זמן קצוב לתפוגה, הזמן הקצוב לתפוגה שייכנס לתוקף הוא ברירת המחדל של Skaffold,‏ 600 (10 דקות).

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

    אם Skaffold (או Cloud Build) מגיע לזמן קצוב לתפוגה, הפריסה של GKE ממשיכה לפעול. ב-Cloud Deploy מוצג כשל, אבל יכול להיות שהפריסה תצליח או תיכשל באשכול GKE.

כדי לשנות את הזמן הקצוב לתפוגה של יציבות הפריסה:

  1. מוודאים שהערך של deploy.statusCheck מוגדר כ-true ב-skaffold.yaml.

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

  2. ב-skaffold.yaml, מגדירים את statusCheckDeadlineSeconds למספר השניות שרוצים להמתין.

    deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...

    ברירת המחדל היא 600 (10 דקות). ‫Skaffold ממתין למשך הזמן הזה לפריסה יציבה. אם חורגים מהזמן הזה לפני שהפריסה יציבה, הפריסה נכשלת.

  3. אפשר גם להוסיף tolerateFailuresUntilDeadline: true אחרי statusCheckDeadlineSeconds.

    ההגדרה הזו אומרת ל-Skaffold לא לצאת אם פריסה אחת נכשלת, אלא לסבול כשלים עד שתוקף statusCheckDeadlineSeconds יפוג. ההגדרה הזו יכולה לעזור במצבים שבהם יש לכם משאבים שאולי יצטרכו יותר זמן (עד למועד האחרון של בדיקת הסטטוס) כדי להגיע למצב יציב.

    לדוגמה, אם אתם משתמשים ב-Istio או ב-Cloud Service Mesh, יכול להיות שפריסה תיכשל ותקבלו הודעה דומה לזו:

    error iptables validation failed; workload is not ready for Istio.
When using Istio CNI, this can occur if a pod is scheduled before the node is ready.

  4. במניפסט של Kubernetes, עבור משאבים מסוג kind: Deployment, מגדירים את Deployment.spec.progressDeadlineSeconds לאותו ערך שהגדרתם עבור statusCheckDeadlineSeconds.

המאמרים הבאים