פריסת תהליך עבודה ממאגר Git באמצעות Cloud Build

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

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

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

ההוראות האלה מניחות שיש לכם את התפקיד 'עריכה' ב-Cloud Build (roles/cloudbuild.builds.editor) ב Google Cloud פרויקט, כדי שתוכלו ליצור טריגרים. צריך גם תהליך עבודה במאגר מקור כמו GitHub או Bitbucket.

המסוף

  1. מפעילים את Cloud Build API ואת Workflows API.

    הפעלת ממשקי ה-API

  2. מקצים לחשבון השירות של Cloud Build את התפקיד 'אדמין של Workflows' (roles/workflows.admin):

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM

    2. בוחרים את הפרויקט הרצוי.

    3. בשורה של חשבון השירות של Cloud Build ‏(PROJECT_NUMBER@cloudbuild.gserviceaccount.com), לוחצים על עריכת חשבון משתמש.

    4. לוחצים על הוספת תפקיד נוסף.

    5. ברשימה תפקיד, בוחרים בתפקיד Workflows Admin.

    6. לוחצים על Save.

  3. מקצים את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לחשבון השירות של Cloud Build. אם הפעלתם את Compute Engine API, חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine הוא PROJECT_NUMBER-compute@developer.gserviceaccount.com.

    1. נכנסים לדף Service Accounts במסוף Google Cloud .

      לדף Service accounts

    2. בוחרים את הפרויקט הרצוי.

    3. לוחצים על כתובת האימייל של חשבון השירות של Compute Engine שמוגדר כברירת מחדל (PROJECT_NUMBER-compute@developer.gserviceaccount.com).

    4. לוחצים על הכרטיסייה Permissions.

    5. לוחצים על הלחצן Grant access.

    6. כדי להוסיף חשבון משתמש חדש, מזינים את כתובת האימייל של חשבון השירות (SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com).

    7. ברשימה Select a role בוחרים בתפקיד Service Accounts > Service Account User.

    8. לוחצים על Save.

gcloud

  1. מפעילים את Cloud Build API ואת Workflows API.

    gcloud services enable cloudbuild.googleapis.com \
  workflows.googleapis.com

  2. מקצים לחשבון השירות של Cloud Build את התפקיד 'אדמין של Workflows' (roles/workflows.admin):

    PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/workflows.admin

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

  3. מקצים את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לחשבון השירות של Cloud Build. אם הפעלתם את Compute Engine API, חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine הוא PROJECT_NUMBER-compute@developer.gserviceaccount.com.

    gcloud iam service-accounts add-iam-policy-binding \
  $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/iam.serviceAccountUser

התחברות למאגר המקור

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

כדי להתחבר ל-GitHub או ל-Bitbucket:

  1. במסוף Google Cloud , נכנסים לדף Triggers של Cloud Build:

    כניסה לדף Triggers

  2. אם צריך, בוחרים את הפרויקט ולוחצים על Open (פתיחה).

  3. ברשימה אזור, בוחרים את האזור שבו רוצים ליצור את הטריגר.

  4. לוחצים על קישור מאגר.

  5. בוחרים את מאגר המקור שבו שמרתם את קוד המקור.

    לדוגמה: GitHub (אפליקציית GitHub של Cloud Build)

  6. לוחצים על Continue.

  7. מאמתים את עצמכם למאגר המקור באמצעות שם המשתמש והסיסמה.

    אם אתם נכנסים ל-GitHub, תתבקשו לאשר לאפליקציית Google Cloud Build GitHub לגשת לחשבון שלכם ב-GitHub כדי להמשיך.

  8. ברשימת המאגרים הזמינים, בוחרים את המאגר הרצוי ולוחצים על אישור.

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

  9. קוראים את כתב הוויתור ומסמנים את תיבת הסימון שלידו כדי לציין שאתם מסכימים לתנאים.

  10. לוחצים על Connect.

  11. כדי להמשיך ליצור טריגר לפיתוח גרסת build כדי לבצע אוטומציה של גרסאות build לקוד המקור במאגר, לוחצים על Create a trigger. אחרת, לוחצים על סיום.

יצירת קובץ תצורה של Cloud Build

קובץ תצורת build מגדיר את השדות שנדרשים כשמשתמשים בטריגר לפיתוח גרסת Build כדי להתחיל build. יוצרים את קובץ ההגדרות בתיקיית השורש של הפרויקט וכותבים אותו בפורמט YAML או JSON.

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

steps:
# Deploy the test workflow with the commit sha
- id: 'deploy-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--source', 'gitops/workflow.yaml']

# Run the test workflow and capture the output
- id: 'run-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'gcloud workflows run $_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA > /workspace/testoutput.log']

# Delete the test workflow
- id: 'delete-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'delete', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--quiet']

# Check the test output
- id: 'check-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['gitops/test-$BRANCH_NAME.sh']

# Deploy the workflow
- id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME', '--source', 'gitops/workflow.yaml']

המשתנים $BRANCH_NAME ו-$SHORT_SHA substitution variables מאוכלסים על ידי Cloud Build כש-build מופעל ממאגר Git. הם מייצגים את שם הענף ואת שבעת התווים הראשונים של מזהה הקומיט שמשויך ל-build, בהתאמה.

המשתנה $_WORKFLOW_NAME מאפשר לעשות שימוש חוזר בקובץ הגדרה עם ערכים שונים של משתנים. אפשר לציין את הערך שלו כשיוצרים את טריגר לפיתוח גרסת Build.

מידע נוסף זמין במאמר בנושא יצירת קובץ הגדרות build.

יצירת טריגר לפיתוח גרסת Build

אפשר ליצור טריגר לפיתוח גרסת Build ב-Cloud Build כדי לבצע אוטומציה של הפריסה של תהליך העבודה.

כדי ליצור טריגר לפיתוח גרסת Build לקובץ התצורה שבקטע הקודם:

  1. במסוף Google Cloud , נכנסים לדף Triggers של Cloud Build:

    כניסה לדף Triggers

  2. לוחצים על Create trigger (יצירת ביטוי להפעלה).

  3. בשדה שם, מזינים שם לטריגר.

  4. בקטע Event (אירוע), בוחרים את האירוע שיפעיל את הטריגר.

    לדוגמה: Push to a branch

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

    לדוגמה: GoogleCloudPlatform/workflows-demos (מאגר) ו-^main$|^staging$ (תואם לענפים main ו-staging)

  6. מרחיבים את הקטע Show included and ignored files filters (הצגת מסננים של קבצים שנכללים וקבצים שהמערכת מתעלמת מהם) ומציינים את זרימת העבודה כקובץ שנכלל, כדי שכשיהיו שינויים בה, יופעל build.

    לדוגמה: gitops/workflow.yaml

  7. בקטע Configuration (הגדרה), בוחרים באפשרות Cloud Build configuration file (YAML or JSON) (קובץ הגדרה של Cloud Build‏ (YAML או JSON)) בתור הסוג, ובאפשרות Repository (מאגר) בתור המיקום.

  8. בשדה Cloud Build configuration file location (המיקום של קובץ תצורת ה-build של Cloud), מציינים את המיקום של הקובץ.

    לדוגמה: gitops/cloudbuild.yaml

  9. אופציונלי: כדי להוסיף משתנה חלופי, לוחצים על הוספת משתנה ומציינים שילוב של מפתח וערך.

    לדוגמה: _WORKFLOW_NAME (משתנה) ו-workflows-gitops (ערך)

  10. כדי לשמור את טריגר לפיתוח גרסת Build, לוחצים על יצירה.

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

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

בדיקת טריגר לפיתוח גרסת Build

אפשר לבדוק את טריגר לפיתוח גרסת Build ואת קובץ תצורה מהקטעים הקודמים.

  1. בענף staging של מאגר Git, עורכים את workflow.yaml ומשנים את Hello World ל-Bye World:

    main:
  steps:
    - init:
        assign:
          - message: "Hello World"
    - returnResult:
        return: ${message}

  2. שומרים ודוחפים את השינוי להסתעפות staging.

    git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push

    הטריגר של Cloud Build מופעל ומתחיל build.

  3. כדי לוודא שהבנייה הצליחה, במסוף Google Cloud עוברים לדף Build history:

    כניסה לדף Build history

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

  4. כדי לוודא שתהליך העבודה של סביבת הבדיקה הועבר לפריסה, במסוף Google Cloud עוברים לדף Workflows:

    כניסה לדף Workflows

    אמור להופיע תהליך עבודה בשם workflows-gitops-staging.

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

    git checkout main
git merge staging
git push

    שימו לב: מכיוון ש-test-main.sh מצפה ל-Hello World בפלט של תהליך העבודה, הבנייה תיכשל:

    RESULT_EXPECTED="result: '\"Hello World\"'"
RESULT_ACTUAL=$(grep "result: " $FILE)
if [[ $RESULT_EXPECTED == $RESULT_ACTUAL ]]; then
  echo "Result test passed"
else
  echo "Result test failed. Expected: $RESULT_EXPECTED Actual: $RESULT_ACTUAL"; exit 1;
fi

  6. כדי לפרוס בהצלחה תהליך עבודה של ייצור, בענף staging, עורכים שוב את workflow.yaml ומשנים את המחרוזת בחזרה ל-Hello World.

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

  8. כדי לוודא שפריסת תהליך העבודה של הייצור בוצעה, במסוף Google Cloud נכנסים לדף Workflows:

    כניסה לדף Workflows

    אמור להופיע תהליך עבודה בשם workflows-gitops-main.

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