ניהול השקות

פריסה ב-Cloud Deploy כוללת שלבים. שלב הוא קיבוץ מסודר ולוגי של משימות שצריך לבצע בהשקה.

כל שלב כולל משימות, שהן הפעולות שצריך לבצע בכל שלב (לדוגמה, deploy או verify). לכל משימה יכולות להיות אפס או יותר הרצות של משימות. הרצת משימה היא מופע של משימה. אם העבודה לא הופעלה, לא יהיו הפעלות של העבודה.

במאמר הזה מוסבר על שלבים, משימות והרצות של משימות, ואיך לנהל אותם.

המבנה של השקה

הפצה היא משאב של Cloud Deploy שמקשר הפצה ליעד.

שלבים

השקת תכונה מורכבת משלב אחד או יותר.

בשיטת פריסה רגילה יש רק שלב אחד: stable.

באסטרטגיית פריסה של קנרית, יש שלב נפרד לכל אחוז שהוגדר. לדוגמה, אם מגדירים קנרי שפורס 25%, אחר כך 50% ואז 100%, יהיו שלושה שלבים:

• canary-25
• canary-50
• stable

אלה השמות הרגילים של השלבים: canary-[PERCENTAGE] לשלבי קנרי, ו-stable לשלב של 100%. עם זאת, אם מגדירים קנרי אוטומטי בהתאמה אישית או קנרי בהתאמה אישית, אפשר לשלוט בשמות השלבים.

משימות והרצות של משימות

כל שלב בהשקה כולל משימה אחת או יותר.

אם אתם משתמשים באסטרטגיית פריסה רגילה ולא הפעלתם אימות פריסה, יש שלב אחד (stable).

בפריסה של קנרית, יהיה שלב לכל חלק של הקנרית (לדוגמה, canary-25, ‏ canary-50, ‏ stable), ולכל שלב יהיה ג'וב deploy. אם האימות מופעל, יש גם משימת verify לכל שלב.

הרצת משימה היא מופע של משימה. לדוגמה, אם מריצים משימה מסוג deploy והיא מסתיימת בהצלחה, לא תהיה הרצה נוספת של אותה משימה. אם הפעולה נכשלת, אפשר לנסות שוב להריץ אותה כמשימה אחרת.

דילוג על שלבים בפעם הראשונה

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

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

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

מדינות בהשקה

לפריסות, לשלבים, למשימות ולהרצות של משימות יש סטטוסים. בקטע הזה מתוארים המצבים של כל אחד מהם.

מצבי השקה

לפריסה יכול להיות אחד מהסטטוסים הבאים:

• APPROVAL_REJECTED

  ההשקה דרשה אישור, אבל האישור נדחה.

• CANCELLED

  מצב הסיום של השקות שבוטלו על ידי משתמש.

• CANCELLING

  משתמש ביטל את ההשקה, אבל הביטול עדיין לא הסתיים.

• HALTED

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

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

  • ביטול ההשקה של הבקר

  • ניסיון חוזר או התעלמות ממשימות שנכשלו בהשקות של צאצאים

• IN_PROGRESS

  הפעלת משימה נמצאת בתהליך עיבוד.

• FAILED

  העבודה נכשלה והמשתמש לא בחר באפשרות התעלמות מהכשל.

• PENDING

  ההשקה לא התחילה לעבד את הנתונים. המצב הזה משתנה ל-IN_PROGRESS או ל-CANCELED.

• PENDING_APPROVAL

  ההשקה דורשת אישור, אבל עדיין לא אושרה.

• PENDING_RELEASE

  ההשקה ממתינה לעיבוד של הגרסה.

• SUCCEEDED

  ההשקה הסתיימה ללא כשלים.

מצבי שלב

הסטטוס של שלב יכול להיות אחד מהבאים:

• PENDING

  השלב נמצא בהמתנה לסיום של שלב אחר בהשקה.

• IN_PROGRESS

  השלב התחיל.

• SUCCEEDED

  השלב הושלם בהצלחה.

• FAILED

  הייתה שגיאה בעבודה בשלב, והמשתמש לא בחר באפשרות התעלמות מהשגיאה.

• ABORTED

  שלב קודם נכשל.

• SKIPPED

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

מצבי משרות

לכל משימה יהיה אחד מהסטטוסים הבאים:

• ABORTED

  אם שלב נכשל, השלבים הבאים מבוטלים.

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

• DISABLED

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

• FAILED

  הפעלת המשימה הזו נכשלה, והמשתמש לא בחר באפשרות התעלמות מהכשל.

  המשתמש בחר לסיים את הרצת העבודה עבור העבודה הזו.

• IGNORED

  הפעלת משימה עבור המשימה הזו נכשלה, והמשתמש בחר להתעלם מהכשל.

• IN_PROGRESS

  כרגע מתבצעת הרצה של משימה עבור המשימה הזו.

• PENDING

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

• SKIPPED

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

• SUCCEEDED

  ההרצה של העבודה הסתיימה בהצלחה, והעבודה הבאה בשלב התחילה, או שהשלב הבא התחיל או מוכן להתחיל (יכול להיות שממתין לקלט מהמשתמש), או שההשקה הסתיימה.

מצבי הרצת משימות

• FAILED

  הפעלת המשימה נכשלה במהלך הביצוע.

• IN_PROGRESS

  ההרצה של המשימה התחילה, אבל עדיין לא הסתיימה.

• TERMINATED

  המשתמש סיים את הרצת העבודה.

• TERMINATING

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

• SUCCEEDED

  כשריצת משימה מסתיימת בהצלחה, בלי להיכשל או בלי שמשתמש יסיים אותה, היא עוברת למצב SUCCEEDED,

ניהול ההשקה

באמצעות Google Cloud המסוף או Google Cloud SDK, אתם יכולים לבצע את הפעולות הבאות בהפצה של Cloud Deploy:

• המשך ההשקה

• ביטול ההשקה

• הפסקת הפעלה של משימה

• התעלמות ממשרה

• ניסיון חוזר של משימה שנכשלה

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

קידום השקה

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

לדוגמה, אם הגדרתם יעד לביצוע פריסת קנרית פשוטה עם שלבים של 50% ו-stable (100%) בלבד, תצטרכו להעביר את הפריסה פעם אחת, מהשלב canary-50 לשלב stable (100%).

gcloud

gcloud deploy rollouts advance ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

כאשר:

‫ROLLOUT_NAME הוא השם של ההשקה הנוכחית שרוצים להעביר לשלב הבא.

‫RELEASE_NAME הוא שם הגרסה שההשקה הזו היא חלק ממנה.

‫PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.

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

מידע נוסף על הפקודה gcloud deploy rollouts advance זמין במאמר בנושא Google Cloud SDK.

המסוף

1. פותחים את הדף Delivery pipelines.

2. לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.

   בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

3. בכרטיסייה השקות, בקטע פרטים של צינור ההפצה, לוחצים על שם ההשקה.

   יוצג דף הפרטים של ההשקה.

   

   שימו לב שבדוגמה הזו, ההשקה כוללת שלב canary-50 ושלב stable. יכול להיות שההשקה שלכם תכלול יותר שלבים או שלבים שונים.

4. לוחצים על הפצה מתקדמת.

   ההשקה מתקדמת לשלב הבא.

ביטול השקה

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

• FAILED
• HALTED
• IN_PROGRESS
• PENDING
• PENDING_APPROVAL
• PENDING_RELEASE

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

כדי לבטל השקה:

gcloud

gcloud deploy rollouts cancel ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --region=REGION

כאשר:

‫ROLLOUT_NAME הוא השם של ההשקה הנוכחית שרוצים להעביר לשלב הבא.

‫RELEASE_NAME הוא שם הגרסה שההשקה הזו היא חלק ממנה.

‫PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.

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

מידע נוסף על הפקודה gcloud deploy rollouts cancel זמין במאמר בנושא Google Cloud SDK.

המסוף

1. פותחים את הדף Delivery pipelines.

2. לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.

   בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

3. בכרטיסייה השקות, בקטע פרטים של צינור ההפצה, לוחצים על שם ההשקה.

   יוצג דף הפרטים של ההשקה.

   

   שימו לב שבדוגמה הזו, ההשקה כוללת שלב canary-50 ושלב stable. יכול להיות שההשקה שלכם תכלול יותר שלבים או שלבים שונים.

4. לוחצים על ביטול ההשקה.

   ההשקה בוטלה.

סיום של הפעלת משימה

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

gcloud

gcloud deploy job-runs terminate JOB_RUN_ID \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --rollout=ROLLOUT_NAME \
                               --region=REGION

כאשר:

‫JOB_RUN_ID הוא ה-UUID של הפעלת העבודה שרוצים להפסיק. אפשר למצוא את מזהה ההרצה של המשימה במסוף Google Cloud , בדף ההשקה של Cloud Deploy:

אפשר גם לקבל את מזהה ההרצות של העבודות באמצעות הפקודה gcloud deploy rollouts describe.

‫RELEASE_NAME הוא שם הגרסה שהרצת העבודה הזו היא חלק ממנה.

‫PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.

‫ROLLOUT_NAME הוא השם של ההשקה שהרצת העבודה הזו היא חלק ממנה.

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

מידע נוסף על הפקודה gcloud deploy job-runs terminate זמין במאמר בנושא Google Cloud SDK.

המסוף

1. פותחים את הדף Delivery pipelines.

2. לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.

   בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

3. בכרטיסייה השקות, בקטע פרטים של צינור ההפצה, לוחצים על שם ההשקה.

   יוצג דף הפרטים של ההשקה.

   

   שימו לב שבדוגמה הזו, ההשקה כוללת שלב canary-50 ושלב stable. יכול להיות שההשקה שלכם תכלול יותר שלבים או שלבים שונים.

4. בקטע Phases, לוחצים על השלב שכולל את העבודה שרוצים להפסיק את ההרצה שלה.

5. בקטע Job runs (הרצות של משימות), בוחרים את ההרצה הספציפית של המשימה שרוצים להפסיק ולוחצים על Terminate (הפסקה).

   הפעלת העבודה מסתיימת, וסטטוס העבודה, כפי שמוצג בטבלה Phases, הוא Failure.

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

• משאירים את ההגדרה כמו שהיא ומתעלמים מההשקה שנכשלה
• ניסיון חוזר של העבודה
• מתעלמים מהעבודה וממשיכים לעבודה או לשלב הבא בהשקה

הערה: כשמשתמשים בפריסה מקבילה, אפשר להפסיק את הרצת המשימות רק בהשקות של רכיבי צאצא, ולא בהשקות של רכיבי בקרה.

התעלמות ממשרה

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

אם משימה נכשלת, השלב נכשל וההשקה נכשלת. עם זאת, אם מתעלמים מהכשל, אפשר להמשיך את הפריסה ואת השלב, ובסופו של דבר יכולים להיות SUCCEEDED מצבים.

gcloud

gcloud deploy rollouts ignore-job ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --job-id=JOB_ID \
                               --phase-id=PHASE_ID \
                               --region=REGION

כאשר:

‫ROLLOUT_NAME הוא השם של ההשקה שהרצת העבודה הזו היא חלק ממנה.

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

‫PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.

‫JOB_ID הוא השם של המשימה שרוצים להתעלם ממנה, למשל DEPLOY. אפשר למצוא את שם העבודה בטבלה Phases של ההשקה במסוף Google Cloud :

‫PHASE_ID הוא שם השלב שכולל את המשימה שרוצים להתעלם ממנה.

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

מידע נוסף על הפקודה gcloud deploy rollouts ignore-job זמין במאמר בנושא Google Cloud SDK.

המסוף

1. פותחים את הדף Delivery pipelines.

2. לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.

   בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

3. בכרטיסייה השקות, בקטע פרטים של צינור ההפצה, לוחצים על שם ההשקה.

   יוצג דף הפרטים של ההשקה.

4. בוחרים את העבודה שנכשלה שרוצים להתעלם ממנה.

5. לוחצים על הלחצן התעלמות מכשלים.

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

הערה: כשמשתמשים בפריסה מקבילה, אפשר להתעלם מעבודות רק בהשקות של צאצאים, ולא בהשקות של בקרי.

ניסיון חוזר של פעולה שנכשלה

אפשר לנסות שוב להריץ עבודה שנכשלה. העבודה יכולה להיכשל בגלל אחת מהסיבות הבאות:

• ההרצה של משימה נכשלה.

  לדוגמה, יכול להיות שהייתה בעיה בהרשאות.

• משתמש סיים הפעלה של משימה מהמשימה הזו.

  סיום של הרצת משימה מוביל למשימה שנכשלה, שאפשר לנסות להריץ שוב.

• בדיקת האימות נכשלה.

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

כדי לנסות שוב להריץ עבודה שנכשלה:

gcloud

gcloud deploy rollouts retry-job JOB_NAME \
                       --release=RELEASE_NAME \
                       --delivery-pipeline=PIPELINE_NAME \
                       --rollout=ROLLOUT_NAME \
                       --phase=PHASE_ID \
                       --region=REGION

כאשר:

‫JOB_NAME הוא שם העבודה שרוצים לנסות שוב. לדוגמה, אם מנסים שוב לאמת את העסק אחרי שהאימות נכשל, הערך יהיה verify.

‫RELEASE_NAME הוא שם הגרסה שהרצת העבודה הזו היא חלק ממנה.

‫PIPELINE_NAME הוא השם של צינור העברת הנתונים שבו אתם משתמשים כדי לנהל את הפריסה של הגרסה הזו.

‫ROLLOUT_NAME הוא השם של ההשקה שהרצת העבודה הזו היא חלק ממנה.

‫PHASE_ID הוא שם השלב שהעבודה הזו היא חלק ממנו. לדוגמה, canary-50 או stable.

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

מידע נוסף על הפקודה gcloud deploy rollouts retry-job זמין במאמר בנושא Google Cloud SDK.

המסוף

1. פותחים את הדף Delivery pipelines.

2. לוחצים על צינור עיבוד הנתונים שמופיע ברשימת צינורות עיבוד הנתונים להעברה.

   בדף הפרטים של צינור ההפצה מוצג ייצוג גרפי של ההתקדמות בצינור ההפצה.

3. בכרטיסייה Rollouts, בקטע Delivery pipeline details, לוחצים על השם של ההשקה.

   יוצג דף הפרטים של ההשקה.

4. בקטע Phases and Jobs, לוחצים על השלב שכולל את העבודה שמנסים להפעיל מחדש.

5. בוחרים את העבודה שרוצים לנסות שוב.

6. לוחצים על ניסיון חוזר ומאשרים.

   

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

הערה: כשמשתמשים בפריסה מקבילה, אפשר לנסות שוב להפעיל משימות רק בהפצות של רכיבי צאצא, ולא בהפצות של רכיבי בקרה.

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

• מידע נוסף על אסטרטגיות פריסה ב-Cloud Deploy

• במאמר ארכיטקטורת שירות Cloud Deploy מוסבר איך פריסות, שלבים, משימות והרצות של משימות משתלבים עם שאר הרכיבים של Cloud Deploy.