השקה באמצעות Cloud Deploy

1. מטרות

במדריך הזה תיצרו שלושה אשכולות GKE בשמות preview, ‏ canary ו-prod. לאחר מכן תיצרו יעד Cloud Deploy שמתאים לכל אשכול, ופייפליין Cloud Deploy שיגדיר את רצף השלבים לביצוע פריסה ביעדים האלה.

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

המדריך הזה מחולק לשלבים הבאים:

• הכנת סביבת העבודה
• הגדרת יעדים ב-Cloud Deploy
• הגדרת פייפליין ב-Cloud Deploy
• יצירת גרסה
• קידום פריסה
• אישור גרסה לסביבת ייצור

הגדרת סביבה בקצב עצמי

1. נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

• שם הפרויקט הוא השם המוצג של הפרויקט הזה למשתתפים. זו מחרוזת של תווים שלא נמצאת בשימוש ב-Google APIs, ואפשר לעדכן אותה בכל שלב.
• מזהה הפרויקט חייב להיות ייחודי לכל הפרויקטים ב-Google Cloud, והוא קבוע (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית. בדרך כלל לא צריך להתייחס אליה. ברוב סדנאות ה-Codelab, צריך להפנות למזהה הפרויקט (ובדרך כלל הוא מזוהה כ-PROJECT_ID), אז אם לא מוצא חן בעיניכם, אפשר ליצור מזהה אקראי אחר, או לנסות מזהה משלכם ולבדוק אם הוא זמין. אחרי שהפרויקט נוצר, הוא 'קפוא'.
• יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. במאמרי העזרה מפורט מידע נוסף על שלושת הערכים האלה.

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

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את מיקום ברירת המחדל כפי שהוא, ללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

2. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API. העלות של התרגול הזה לא אמורה להיות גבוהה, ואולי אפילו לא תצטרכו לשלם בכלל. כדי לכבות את המשאבים ולא לחייב אתכם מעבר למה שמוסבר במדריך הזה, צריך לפעול לפי ההוראות לניקוי שמופיעות בסוף ה-Codelab. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.

2. הגדרת הפלטפורמה

הכנת סביבת העבודה

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

1. הגדרת ברירות מחדל של gcloud config

gcloud config set project <your project>

gcloud config set deploy/region us-central1

2. Clone Repo

git clone https://github.com/gushob21/software-delivery-workshop

cd software-delivery-workshop/labs/cloud-deploy/

cloudshell workspace .

rm -rf deploy && mkdir deploy

3. הגדרה של משתני סביבה

export PROJECT_ID=$(gcloud config get-value project)

export PROJECT_NUMBER=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")

4. הפעלת ממשקי API

gcloud services enable \

cloudresourcemanager.googleapis.com \

    `container.googleapis.com \`

    `cloudbuild.googleapis.com \`

    `containerregistry.googleapis.com \`

    `secretmanager.googleapis.com \`

    `clouddeploy.googleapis.com` 

5. יצירת אשכולות GKE

    `gcloud container clusters create preview \`
   

--zone=us-central1-a --async

    `gcloud container clusters create canary \`

--zone=us-central1-b --async

    `gcloud container clusters create prod \`

--zone=us-central1-c

הגדרת יעדים ב-Cloud Deploy

1. יוצרים קובץ בספריית הפריסה בשם preview.yaml באמצעות הפקודה הבאה ב-Cloud Shell:

cat <<EOF >deploy/preview.yaml

apiVersion: deploy.cloud.google.com/v1beta1

kind: Target

metadata:

name: preview

annotations: {}

labels: {}

description: Target for preview environment

gke:

cluster: projects/$PROJECT_ID/locations/us-central1-a/clusters/preview

EOF

    As you noticed, the "kind" tag is "Target". It allows us to add some metadata to the target, a description and finally the GKE cluster where the deployment is supposed to happen for this target.

2. כדי ליצור קובץ בשם canary.yaml בספריית הפריסה, מריצים את הפקודה הבאה ב-Cloud Shell:

cat <<EOF >deploy/canary.yaml

apiVersion: deploy.cloud.google.com/v1beta1

kind: Target

metadata:

name: canary

annotations: {}

labels: {}

description: Target for canary environment

gke:

cluster: projects/$PROJECT_ID/locations/us-central1-b/clusters/canary

EOF

3. יוצרים קובץ בספריית הפריסה בשם prod.yaml באמצעות הפקודה הבאה ב-Cloud Shell:

cat <<EOF >deploy/prod.yaml

apiVersion: deploy.cloud.google.com/v1beta1

kind: Target

metadata:

name: prod

annotations: {}

labels: {}

description: Target for prod environment

requireApproval: true

gke:

cluster: projects/$PROJECT_ID/locations/us-central1-c/clusters/prod

EOF

שימו לב לתג requireApproval שהערך שלו מוגדר כ-true. הפעולה הזו לא תאפשר קידום של היעד לסביבת הייצור עד שהאישור יינתן. כדי לאשר פריסה, צריך תפקיד עם הרשאה roles/clouddeploy.approver.

4. יצירת יעדי הפריסה

        `gcloud config set deploy/region us-central1` 
   

gcloud beta deploy apply --file deploy/preview.yaml

gcloud beta deploy apply --file deploy/canary.yaml

gcloud beta deploy apply --file deploy/prod.yaml

3. יצירת אפליקציה

במסגרת יצירת אפליקציה חדשה, בדרך כלל מגדירים את צינור ה-CICD לביצוע גרסאות build אוטומטיות, בדיקות שילוב ופריסות. השלבים הבאים נחשבים לחלק מתהליך ההגדרה של אפליקציה חדשה. לכל אפליקציה חדשה תוגדר פייפליין Deployment (פריסה).

הגדרת צינור עיבוד נתונים ב-Cloud Deploy

1. כדי ליצור קובץ בשם pipeline.yaml בספריית הפריסה, מריצים את הפקודה הבאה ב-Cloud Shell:

cat <<EOF >>deploy/pipeline.yaml

apiVersion: deploy.cloud.google.com/v1beta1

kind: DeliveryPipeline

metadata:

name: sample-app

labels:

`app: sample-app`

description: delivery pipeline

serialPipeline:

stages:

- targetId: preview

`profiles:`

`- preview`

- targetId: canary

`profiles:`

`- canary`

- targetId: prod

`profiles:`

`- prod`

EOF

    As you noticed, the "kind" tag is "DeliveryPipeline". It lets you define the metadata for the pipeline, a description and an order of deployment into various targets via serialPipeline tag.

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

‫targetId מציין את היעד הספציפי שבו יש להשתמש בשלב הזה של פייפליין העברת הנתונים. הערך הוא הנכס metadata.name מהגדרת היעד.

‫profiles היא רשימה של אפס שמות פרופילים או יותר של Skaffold, מתוך skaffold.yaml. כשיוצרים את הגרסה, Cloud Deploy משתמש בפרופיל עם הפקודה skaffold render.

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

gcloud beta deploy apply --file deploy/pipeline.yaml

4. שלב הפיתוח

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

1. יצירה ואחסון של האפליקציה באמצעות skaffold

skaffold build \

--file-output=artifacts.json \

--default-repo gcr.io/$PROJECT_ID \

--push=true

5. שלב ההשקה

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

יצירת גרסה

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

export REL_TIMESTAMP=$(date '+%Y%m%d-%H%M%S')

gcloud beta deploy releases create \

sample-app-release-${REL_TIMESTAMP} \

--delivery-pipeline=sample-app \

--description="Release demo" \

--build-artifacts=artifacts.json \

--annotations="release-id=rel-${REL_TIMESTAMP}"

בדיקת הגרסה

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

2. עוברים אל Cloud Deploy במסוף Google Cloud.
3. לוחצים על sample-app (אפליקציה לדוגמה).

במסך הזה יוצג ייצוג גרפי של צינור המכירות.

4. מוודאים שיש מסגרת ירוקה בצד ימין של תיבת התצוגה המקדימה, שמשמעותה שהגרסה נפרסה בסביבה הזו.
5. אפשר לעיין בפרטים נוספים על הגרסה על ידי לחיצה על שם הגרסה בקטע Release Details (פרטי הגרסה) בחלק התחתון של המסך.
6. כדי לוודא שהאפליקציה נפרסה בהצלחה, מריצים את הפקודה הבאה ב-Cloud Shell:

gcloud container clusters get-credentials preview --zone us-central1-a && kubectl port-forward --namespace default $(kubectl get pod --namespace default --selector="app=cloud-deploy-tutorial" --output jsonpath='{.items[0].metadata.name}') 8080:8080

7. לוחצים על סמל התצוגה המקדימה של האתר בפינה השמאלית העליונה של המסך.
8. בוחרים באפשרות 'תצוגה מקדימה ביציאה 8080'.

תועברו לדף חדש שבו מוצגת ההודעה Hello World!‎.

9. כדי להפסיק את העברת הפורטים, משתמשים ב-ctrl+c בטרמינל.

קידום של גרסה

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

gcloud beta deploy releases promote \

--release=sample-app-release-${REL_TIMESTAMP} \

--delivery-pipeline=sample-app \

--quiet

בדיקת המבצע להשקת הגרסה

1. נכנסים לצינור (pipeline) של אפליקציית הדוגמה במסוף Google Cloud
2. מוודאים שמופיע קו מתאר ירוק בצד ימין של תיבת Canary, שמשמעותו היא שהגרסה נפרסה בסביבה הזו.
3. כדי לוודא שהאפליקציה נפרסה בצורה נכונה, יוצרים מנהרה לאפליקציה

gcloud container clusters get-credentials canary --zone us-central1-b && kubectl port-forward --namespace default $(kubectl get pod --namespace default --selector="app=cloud-deploy-tutorial" --output jsonpath='{.items[0].metadata.name}') 8080:8080

4. לוחצים על סמל התצוגה המקדימה של האתר בפינה השמאלית העליונה של המסך.
5. בוחרים באפשרות 'תצוגה מקדימה ביציאה 8080'.

תועברו לדף חדש שבו מוצגת ההודעה Hello World!‎.

6. כדי להפסיק את העברת הפורטים, משתמשים ב-ctrl+c בטרמינל.

אישור גרסה לסביבת הייצור

זוכרים שכשיצרנו את יעד הייצור באמצעות prod.yaml, הגדרנו את התג requireApproval כ-true? הפעולה הזו תגרום לכך שיהיה צורך באישור לקידום ל-prod.

1. מקדמים את גרסה איטרטיבית לקהל מצומצם (canary release) למסלול לסביבת הייצור באמצעות הפקודה הבאה

gcloud beta deploy releases promote \

--release=sample-app-release-${REL_TIMESTAMP} \

--delivery-pipeline=sample-app \

--quiet

2. נכנסים לצינור (pipeline) של אפליקציית הדוגמה במסוף Google Cloud
3. שימו לב לסימן הצהוב עם הכיתוב '1 בהמתנה'.

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

4. לוחצים על הלחצן 'בדיקה' שמתחת להודעה הצהובה.
5. במסך הבא, לוחצים שוב על 'בדיקה' כדי לגשת למסך האישור של הסביבה הפרודקטיבית.
6. אפשר גם לבדוק את ההבדלים במניפסט כדי לראות את השינויים. במקרה הזה, קובץ חדש לגמרי.
7. לוחצים על הלחצן 'אישור'.
8. חוזרים אל דף צינור העברת הנתונים של האפליקציה לדוגמה, שבו תוכלו לראות את ההתקדמות של העברת הגרסה לסביבת הייצור.

בדיקת הגרסה לסביבת הייצור

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

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

gcloud container clusters get-credentials prod --zone us-central1-c && kubectl port-forward --namespace default $(kubectl get pod --namespace default --selector="app=cloud-deploy-tutorial" --output jsonpath='{.items[0].metadata.name}') 8080:8080

2. לוחצים על סמל התצוגה המקדימה של האתר בפינה השמאלית העליונה של המסך.
3. בוחרים באפשרות 'תצוגה מקדימה ביציאה 8080'.

תועברו לדף חדש שבו מוצגת ההודעה Hello World!‎.

4. כדי להפסיק את העברת הפורטים, משתמשים ב-ctrl+c בטרמינל.