ארכיטקטורת שירות Cloud Deploy

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

התצוגה ברמה גבוהה

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

הקשרים בין רכיבי Cloud Deploy

כפי שמוצג בתרשים הזה, Cloud Deploy מקיים אינטראקציה עם המערכות הבאות:

  • מערכת ה-CI שלכם

    ‫Cloud Deploy תומך ברוב כלי ה-CI, כל עוד אחד מהפלט של תהליך ה-CI יכול להיות קריאה ל-API או ל-CLI של Cloud Deploy כדי ליצור גרסת הפצה.

  • Cloud Build

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

  • Skaffold

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

  • Cloud Storage

    ‫Cloud Deploy מאחסן את מקור העיבוד ואת המניפסטים המעובדים בקטגוריה של Cloud Storage.

  • ‫Google Cloud Observability ויומני ביקורת של Cloud.

    ‫Google Cloud Observability אוסף נתוני רישום ביומן ומאפשר גישה אליהם ב-Cloud Deploy.

    אפשר לעיין גם במאמר בנושא רישום ביומן הביקורת.

  • Pub/Sub

    ‫Cloud Deploy מפרסם הודעות בכמה נושאים ב-Pub/Sub. אפשר להשתמש בשירות הזה כדי לשלב עם זרימות עבודה חיצוניות, בדיקות ומערכות קשורות אחרות.

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

  • זמן הריצה של היעד

    ‫Cloud Deploy משתמש ב-skaffold apply, דרך Cloud Build, כדי לפרוס את האפליקציות בסביבת זמן הריצה של היעד (GKE,‏ Cloud Run או יעד מותאם אישית).

משאבים של Cloud Deploy

בתרשים הבא מוצגים המשאבים שמשמשים את Cloud Deploy להפצת האפליקציות, והקשרים ביניהם:

הקשר בין משאבים ב-Cloud Deploy

כפי שמוצג בתרשים הזה, הקשרים בין המשאבים הם כאלה:

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

  • בצינור העברת השינויים אפשר גם להפנות אל אוטומציות אחת או יותר, שמבצעות פעולות אוטומטיות במשאבי Cloud Deploy.

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

  • כל גרסה יכולה להניב אפס או יותר פריסות, ויכולה להפנות לאפס או יותר פריטים.

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

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

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

  • כל השקה משויכת ליעד אחד.

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

  • כל יעד משויך לאשכול GKE אחד או ליעד אחר של זמן ריצה עבור האפליקציה.

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

  • ארטיפקט הוא כל פלט מתהליך ה-CI (לדוגמה, קובץ אימג' של קונטיינר) שנפרס בסביבת זמן ריצה יעד כחלק מהשקה.

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

משאבים להשקה

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

  • שלבים

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

  • תעסוקה

    הפעולה הספציפית שצריך לבצע בהשקה, למשל deploy או verify. משימה היא הודעת משנה בהשקה.

  • JobRuns

    מופע של עבודה, למשל ניסיון לאימות. לכל משימה יכולים להיות אפס או יותר JobRuns. ‫JobRun הוא משאב צאצא של rollout.

אמצעי האוטומציה מכילים כללים לאוטומציה, שאפשר להפנות אליהם באמצעות אפס או יותר משאבי AutomationRun. ‫AutomationRuns הם מקרים של כללי אוטומציה שהופעלו, למשל מבצע אוטומטי מיעד אחד ליעד אחר. משאבי Automation ו-AutomationRun הם משאבי צאצאים ברמה זהה מתחת ל-delivery pipeline.

משאבים בנושא אוטומציה

איך הם משתלבים כדי להפיץ את הפריט

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

  1. מערכת ה-CI שלכם מפעילה צינור אספקה של Cloud Deploy.

    תהליך ה-CI קורא ל-Cloud Deploy באמצעות CLI או API כדי ליצור גרסה חדשה, ומעביר את תוצרי ה-build או הפניות לתמונות.

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

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

    1. שומרים מופע של צינור העברת הנתונים כחלק מהגרסה.

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

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

    2. מפעיל את Cloud Build, שמקבל את מקור העיבוד של Skaffold מ-Cloud Storage.

      ‫Cloud Deploy מאחסן את מקור העיבוד בקטגוריה של Cloud Storage שמוגדרת כברירת מחדל או כחלופית.

    3. ‫Calls skaffold diagnose (using the Skaffold version stored upon release creation) to generate a single effective manifest.

    4. מבצעים קריאה לפעולה render.

      אם משתמשים ביעדים מובנים, Cloud Deploy קורא ל-skaffold render כדי לעבד את המניפסט באמצעות התמונות או הארטיפקטים של ה-build שסופקו. ‫Cloud Deploy מחליף את שמות התמונות ב-spec.templates.spec.containers.image בנתיבי התמונות המלאים (כולל ערכי הגיבוב או התגים) שצוינו בפקודה gcloud deploy releases create או בקובץ של ארטיפקטים של בנייה שהפקודה מפנה אליו.

      אם משתמשים ביעד בהתאמה אישית,‏ Cloud Deploy קורא לפעולה render שמוגדרת עבור סוג היעד בהתאמה אישית.

      ‫Cloud Deploy מאחסן את המניפסט שעבר עיבוד בקטגוריה של Cloud Storage שמוגדרת כברירת מחדל או בקטגוריה חלופית.

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

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

    1. מפעיל ווֹקים לפני פריסה, אם צוינו כאלה.

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

    2. מבצעים קריאה לפעולה deploy.

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

      אם אתם משתמשים ביעד מותאם אישית,‏ Cloud Deploy יוצר באופן אוטומטי פריסה ליעד הראשון, ומפעיל את פעולת deploy שמוגדרת לסוג היעד המותאם אישית.

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

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

    3. שיחות skaffold verify, אם verify הוא true ליעד בצינור ההפצה config ואם האימות מצוין בהגדרת Skaffold.

    4. מפעיל ווים (hooks) אחרי פריסה, אם צוינו כאלה, אחרי verify, אם צוין verify. אחרת, קריאות ל-hooks אחרי פריסה מתבצעות אחרי deploy.

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

  4. כשמגיע הזמן להעביר את הגרסה ליעד הבא, Cloud Build מאחזר את מניפסט היעד הספציפי מ-Cloud Storage. אחר כך, Cloud Build מפעיל את skaffold apply כדי להחיל את המניפסט שעבר רינדור על זמן הריצה של היעד שצוין.

    אם נדרש אישור ליעד, אפשר לאשר או לדחות אותו באמצעות ה-CLI או המסוף.

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

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

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

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

    השילוב הזה ושילובים אחרים מתוארים בפירוט במאמר שילוב של Cloud Deploy עם מערכות חיצוניות.

  6. אתם יכולים לציין אוטומציה כדי לבצע באופן אוטומטי פעולות שונות בצינור העברת הנתונים. אפשר להפעיל אותם בזמן שנקבע להם. ‫An automationRun מייצג ביצוע של כלל אוטומטי.

  7. במהלך הפעולה של Cloud Deploy, השירות כותב יומנים של הפלטפורמה ויומני ביקורת אל Google Cloud Observability ויומני ביקורת של Cloud.

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

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