סקירה כללית על Cloud Deploy

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

איך צינור Cloud Deploy פועל

צינור עיבוד הנתונים של Cloud Deploy מכיל את המידע הבא:

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

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

  • אופציונלי: תוויות והערות.

  • אפשר גם להגדיר את הגדרות היעד עצמן.

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

תהליך המסירה ב-Cloud Deploy

הקטע הבא מתאר תרחיש של פיתוח רציף (continuous delivery) ב-Cloud Deploy.

  1. מגדירים את צינור העברת התוכן בקובץ תצורה בפורמט YAML.

    קובץ ההגדרות הזה מגדיר את רצף הקידום שבו האפליקציה שלכם תופעל בסדרה של יעדים.

    צריך גם הגדרה ל-Skaffold, ש-Cloud Deploy צריך כדי לבצע פעולות של עיבוד ופריסה.

  2. מגדירים את היעדים בקובץ התצורה של צינור הנתונים או בקובץ או בקבצים נפרדים.

  3. רושמים את צינור עיבוד הנתונים בשירות Cloud Deploy.

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

  4. הפלט של תהליך ה-CI כולל קריאה ל-Cloud Deploy כדי להפעיל את צינור העברת הנתונים.

    הקריאה הזו יוצרת משאב release שמייצג את המניפסט שעבר עיבוד לכל יעד. כל יעד נוצר באמצעות מקור העיבוד שסופק, skaffold.yaml והפניות לקובצי אימג' ספציפיים של קונטיינרים לפריסה. בקריאה הראשונה הזו ליצירת גרסת הפצה,‏ Cloud Deploy יוצר באופן אוטומטי משאב rollout, שמשייך את גרסת ההפצה לסביבת היעד הראשונה. על סמך ההשקה הזו, האפליקציה שלכם נפרסת ליעד הראשון.

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

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

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

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

  6. המבצע ממשיך בכל היעדים ברצף המבצעים, והאחרון מביניהם הוא prod (או כל שם אחר שבו אתם משתמשים ליעד הסופי כדי להעביר את האפליקציה לייצור).

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

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

קידום

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

אישורים

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

כשנדרש אישור ליעד, Cloud Deploy יוצר הודעת Pub/Sub שאפשר להשתמש בה במערכת משולבת. לדוגמה, מערכת כרטוס יכולה להירשם להודעה כדי להפעיל תהליך עבודה של אישור.

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

התראות

‫Cloud Deploy מספק התראות Pub/Sub לאירועים הבאים:

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

ב-Cloud Deploy, המערכת משתמשת בנושא Pub/Sub כדי לשלוח את ההתראות האלה.

פרטים נוספים מופיעים במאמר בנושא שימוש בהתראות של Cloud Deploy.

רולבק

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

פרטים נוספים מופיעים במאמר בנושא חזרה מפריסה.

מידע על Skaffold ו-Cloud Deploy

‫Cloud Deploy משתמש ב-Skaffold לעיבוד, לפריסה ולאימות. בעזרת Skaffold, אפשר גם לקשר את לולאת הפיתוח המקומית לצינור אספקה רציפה (CD) של Cloud Deploy.

מידע נוסף על השילוב של Cloud Deploy עם Skaffold זמין במאמר סקירה כללית על Skaffold.

‫Cloud Deploy עם כלים אחרים Google Cloud

‫Cloud Deploy תומך כמעט בכל כלי במעלה הזרם בצינור CI/CD. כלומר, אתם יכולים להשתמש בכל סביבת פיתוח ומאגר המקורות של הקוד, בכל מערכת אינטגרציה רציפה (CI) ובכל מאגר ארטיפקטים.

בשלב הבא, Cloud Deploy פורס ב-Cloud Run וב-Google Kubernetes Engine, כולל אשכולות GKE שמצורפים.

אם השתמשתם בעיקר Google Cloud בכלים, התהליך שלכם ממקור הייצור ייראה כך:

  1. משתמשים ב-Cloud Code כדי ליצור את מקור האפליקציה.

    ‫Cloud Code מרחיב כמה סביבות פיתוח משולבות (IDE) פופולריות (VS Code, ‏ IntelliJ,‏ Cloud Shell) כדי להקל על פיתוח אפליקציות לפריסה ולהפעלה ב-Google Cloud.

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

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

  3. מפתחים את האפליקציה באמצעות Cloud Build.

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

  4. אחסון פריטי מידע ב-Artifact Registry.

    ‫Cloud Deploy מאחזר את קובץ האימג' של הקונטיינר או קובצי האימג' מ-Artifact Registry, שמאפשר לכם לאחסן באופן מרכזי ארטיפקטים ותלות.

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

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

  6. ניהול האפליקציה ב-GKE או ב-Cloud Run.

    ‫GKE היא סביבה מנוהלת שלGoogle Cloud להרצת אפליקציות בקונטיינרים ב-Kubernetes.

    באמצעות Cloud Run, אפשר להריץ קונטיינרים בסביבה ללא שרת.

    ‫GKE attached clusters מספק חוויה עקבית של פיתוח ותפעול בסביבות ענן ובסביבות מקומיות.

  7. מעקב אחר ביצועי האפליקציה באמצעות Google Cloud Observability.

    ‫Google Cloud Observability מציע מעקב ורישום ביומן משולבים עבור האפליקציה שלכם.

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