יצירת צינור עיבוד נתונים של CI/CD באמצעות Azure Pipelines ו-Cloud Run

במדריך הזה נסביר איך להשתמש ב-Azure Pipelines, ב-Cloud Run וב-Container Registry כדי ליצור פייפליין של אינטגרציה רציפה (CI) ופריסה רציפה (CD) לאפליקציית אינטרנט של ASP.NET MVC Core.

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

ארכיטקטורה של צינורות העיבוד של Azure Build ו-Release באינטראקציה עם צינורות העיבוד של Google Cloud Production ו-Development.

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

המדריך הזה מיועד למפתחים ולמהנדסי DevOps. ההנחה היא שיש לכם ידע בסיסי ב-‎ .NET,‏ Azure Pipelines,‏ Cloud Run ו-git. כדי להשלים את המדריך הזה, צריך הרשאת אדמין לחשבון Azure DevOps.

מטרות

  • חיבור של Artifact Registry ל-Azure Pipelines לפרסום תמונות Docker.
  • הכנת אפליקציה לדוגמה ב-‎.NET לפריסה ב-Cloud Run.
  • הגדרת אימות בין Azure Pipelines לבין Google Cloud.
  • אפשר להשתמש בניהול הגרסאות של Azure Pipelines כדי לתזמן פריסות של Cloud Run.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

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

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

כדאי לעיין בדף התמחור של Azure DevOps כדי לבדוק אם יש עמלות שחלות על השימוש ב-Azure DevOps.

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

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

  1. יוצרים Google Cloud פרויקט לפיתוח. במדריך הזה נתייחס לפרויקט הזה כפרויקט הפיתוח.
  2. יוצרים פרויקט Google Cloud לסביבת ייצור. במדריך הזה, הפרויקט הזה נקרא פרויקט הייצור.

  3. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  4. ודאו שיש לכם חשבון Azure DevOps ושיש לכם הרשאת אדמין בו. אם עדיין אין לכם חשבון ב-Azure DevOps, אתם יכולים להירשם בדף הבית של Azure DevOps.

יצירת פרויקט ב-Azure DevOps

אתם משתמשים ב-Azure DevOps כדי לנהל את קוד המקור, להריץ בנייה ובדיקות ולתזמן את הפריסה ב-Cloud Run. כדי להתחיל, יוצרים פרויקט בחשבון Azure DevOps.

  1. עוברים לדף הבית של Azure DevOps ‏(https://dev.azure.com/YOUR_AZURE_DEVOPS_ACCOUNT_NAME).
  2. לוחצים על פרויקט חדש.
  3. מזינים שם לפרויקט, למשל CloudDemo.
  4. מגדירים את Visibility (חשיפה) למצב Private (פרטי) ואז לוחצים על Create project (יצירת פרויקט).
  5. אחרי שיוצרים את הפרויקט, בתפריט שמימין לוחצים על Repos (מאגרי מידע).
  6. לוחצים על Import (ייבוא) כדי ליצור הסתעפות של מאגר dotnet-docs-samples מ-GitHub, ואז מגדירים את הערכים הבאים:
    • סוג המאגר: Git
    • כתובת ה-URL של השיבוט: https://github.com/GoogleCloudPlatform/dotnet-docs-samples.git

  7. לוחצים על Import.

    בסיום תהליך הייבוא, קוד המקור של מאגר dotnet-docs-samples מוצג.

חיבור של Azure Pipelines ל-Artifact Registry

כדי להגדיר אינטגרציה רציפה (CI) של האפליקציה CloudDemo, צריך לקשר את Azure Pipelines ל-Artifact Registry. החיבור הזה מאפשר ל-Azure Pipelines לפרסם קובצי אימג' של קונטיינרים ב-Artifact Registry.

הגדרת חשבון שירות לפרסום תמונות

יוצרים Google Cloud חשבון שירות בפרויקט הייצור:

  1. במסוף Google Cloud , עוברים לפרויקט הייצור.

  2. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

  3. מאתחלים את משתני הסביבה הבאים:

    DEV_PROJECT_ID=DEV_PROJECT_ID
PROD_PROJECT_ID=PROD_PROJECT_ID

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

    • ‫DEV_PROJECT_ID: מזהה הפרויקט של פרויקט הפיתוח
    • ‫PROD_PROJECT_ID: מזהה הפרויקט של פרויקט הייצור

  4. מפעילים את Artifact Registry API בפרויקט הייצור:

    gcloud services enable artifactregistry.googleapis.com \
    --project=$PROD_PROJECT_ID

  5. יוצרים מאגר Artifact Registry לאחסון קובצי אימג' של Docker:

    gcloud artifacts repositories create docker  \
    --project=$PROD_PROJECT_ID \
    --repository-format=docker \
    --location REGION

    מחליפים את REGION באזור של מאגר Artifact Registry, לדוגמה us-central1.

  6. יוצרים חשבון שירות ש-Azure Pipelines משתמש בו כדי לפרסם תמונות Docker:

    gcloud iam service-accounts create azure-pipelines-publisher \
    --display-name="Azure Pipelines Publisher" \
    --project=$PROD_PROJECT_ID

  7. מקצים לחשבון השירות את התפקיד Artifact Registry Writer ‏(roles/artifactregistry.writer) כדי לאפשר ל-Azure Pipelines לבצע push ל-Artifact Registry:

    AZURE_PIPELINES_PUBLISHER=azure-pipelines-publisher@$PROD_PROJECT_ID.iam.gserviceaccount.com

gcloud projects add-iam-policy-binding $PROD_PROJECT_ID \
    --member serviceAccount:$AZURE_PIPELINES_PUBLISHER \
    --role roles/artifactregistry.writer \
    --project=$PROD_PROJECT_ID

  8. יוצרים מפתח לחשבון השירות:

    gcloud iam service-accounts keys create azure-pipelines-publisher.json \
    --iam-account $AZURE_PIPELINES_PUBLISHER \
    --project=$PROD_PROJECT_ID

tr -d '\n' < azure-pipelines-publisher.json > azure-pipelines-publisher-oneline.json

  9. צופים בתוכן של קובץ המפתח של חשבון השירות:

    echo $(<azure-pipelines-publisher-oneline.json)

    תצטרכו את המפתח של חשבון השירות באחד מהשלבים הבאים.

יצירת חיבור שירות ל-Artifact Registry

ב-Azure Pipelines, יוצרים חיבור שירות חדש ל-Artifact Registry:

  1. בתפריט DevOps של Azure, בוחרים באפשרות Project settings (הגדרות הפרויקט), ואז בוחרים באפשרות Pipelines (צינורות) > Service connections (חיבורי שירות).
  2. לוחצים על יצירת קישור לשירות.
  3. מהרשימה, בוחרים באפשרות Docker Registry ולוחצים על Next (הבא).

  4. בתיבת הדו-שיח, מזינים ערכים בשדות הבאים:

    • סוג המרשם: אחרים

    • מאגר Docker: https://REGION-docker.pkg.dev/PROD_PROJECT_ID/docker/

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

      • ‫REGION: האזור של מאגר Artifact Registry
      • ‫PROD_PROJECT_ID: השם של פרויקט הייצור

    • מזהה Docker: _json_key

    • סיסמה: מדביקים את התוכן של azure-pipelines-publisher-oneline.json.

    • שם חיבור השירות: gcr-tutorial

  5. לוחצים על שמירה כדי ליצור את הקישור.

בנייה רציפה

עכשיו אפשר להשתמש ב-Azure Pipelines כדי להגדיר אינטגרציה רציפה (CI). לכל קומיט שמועבר בדחיפה למאגר Git, ‏ Azure Pipelines בונה את הקוד ואורז את תוצרי הבנייה במאגר Docker. הקונטיינר מתפרסם ב-Artifact Registry.

המאגר כבר מכיל את קובץ ה-Dockerfile הבא:

#
# Copyright 2020 Google LLC
#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
# 
#   http://www.apache.org/licenses/LICENSE-2.0
# 
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied.  See the License for the
# specific language governing permissions and limitations
# under the License.
#

FROM mcr.microsoft.com/dotnet/aspnet:6.0
EXPOSE 8080

#------------------------------------------------------------------------------
# Copy publishing artifacts.
#------------------------------------------------------------------------------

WORKDIR /app
COPY CloudDemo.MvcCore/bin/Release/net6.0/publish/ /app/

ENV ASPNETCORE_URLS=http://0.0.0.0:8080

#------------------------------------------------------------------------------
# Run application in Kestrel.
#------------------------------------------------------------------------------

ENTRYPOINT ["dotnet", "CloudDemo.MvcCore.dll"]

עכשיו יוצרים צינור חדש שמשתמש בתחביר YAML:

  1. באמצעות Visual Studio או לקוח git של שורת פקודה, משכפלים את ה-repository החדש של Git.
  2. בשורש המאגר, יוצרים קובץ בשם azure-pipelines.yml.

  3. מעתיקים את הקוד הבא לקובץ:

    resources:
- repo: self
  fetchDepth: 1
pool:
  vmImage: ubuntu-22.04
trigger:
- master
variables:
  TargetFramework: 'net6.0'
  BuildConfiguration: 'Release'
  DockerImageName: 'PROD_PROJECT_ID/docker/CloudDemo'
steps:
- task: DotNetCoreCLI@2
  displayName: Publish
  inputs:
    projects: 'applications/clouddemo/netcore/CloudDemo.MvcCore.sln'
    publishWebProjects: false
    command: publish
    arguments: '--configuration $(BuildConfiguration) --framework=$(TargetFramework)'
    zipAfterPublish: false
    modifyOutputPath: false
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
- task: Docker@2
  displayName: 'Login to Container Registry'
  inputs:
    command: login
    containerRegistry: 'gcr-tutorial'
- task: Docker@2
  displayName: 'Build and push image'
  inputs:
    Dockerfile: 'applications/clouddemo/netcore/Dockerfile'
    command: buildAndPush
    repository: '$(DockerImageName)'

    מחליפים את PROJECT_ID בשם של פרויקט הייצור ושומרים את הקובץ.

    מכיוון ש-Cloud Run היא סביבה מבוססת-Linux, צינור הנתונים משתמש בסוכני build מבוססי-Linux.

  4. שומרים את השינויים ודוחפים אותם אל Azure Pipelines.

    Visual Studio

    1. פותחים את Team Explorer ולוחצים על סמל דף הבית.
    2. לוחצים על שינויים.
    3. מזינים הודעת קומיט כמו Add pipeline definition.
    4. לוחצים על Commit All and Push (ביצוע Commit של הכול והעלאה).

    שורת הפקודה

    1. העברת כל הקבצים ששונו אל אזור ההכנה:

      git add -A

    2. שומרים את השינויים במאגר המקומי:

      git commit -m "Add pipeline definition"

    3. שולחים את השינויים ל-Azure DevOps:

      git push

  5. בתפריט Azure DevOps, בוחרים באפשרות Pipelines ואז לוחצים על Create Pipeline.

  6. בוחרים באפשרות Azure Repos Git.

  7. בוחרים את המאגר.

  8. בדף Review your pipeline YAML (בדיקת קובץ ה-YAML של צינור הנתונים), לוחצים על Run (הפעלה).

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

  9. כדי לוודא שהתמונה פורסמה ב-Artifact Registry, עוברים לפרויקט הייצור במסוף Google Cloud , בוחרים באפשרות Artifact Registry > docker ואז לוחצים על CloudDemo.

    מוצגת תמונה אחת והתג שלה. התג תואם למזהה המספרי של ה-Build שהופעל ב-Azure Pipelines.

פריסה רציפה

מערכת Azure Pipelines בונה את הקוד שלכם באופן אוטומטי ומפרסמת תמונות Docker לכל פעולת commit, כך שאתם יכולים להתפנות לפריסה.

בניגוד למערכות אחרות של אינטגרציה רציפה (CI), ב-Azure Pipelines יש הבחנה בין בנייה לפריסה, והיא מספקת קבוצה מיוחדת של כלים שנקראת Release Management לכל המשימות שקשורות לפריסה.

הכלי Azure Pipelines Release Management מבוסס על המושגים הבאים:

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

מגדירים את צינור ההפצה כך שיופעל בכל פעם שנוצרת גרסה חדשה. הצינור מורכב משני שלבים: פיתוח וייצור. בכל שלב, פייפליין הגרסה משתמש בקובץ אימג' של Docker שנוצר על ידי פייפליין הבנייה, ואז הפייפליין פורס אותו ב-Cloud Run.

צינור ה-build שהגדרתם קודם מתייג כל קובץ אימג' של Docker עם מזהה ה-build לפני שהוא מפרסם אותו ב-Artifact Registry. לכן, בצינור ההפצה, משתמשים במשתנה $BUILD_BUILDID כדי לזהות את קובץ אימג' של Docker הנכון לפריסה.

הגדרת Cloud Run

‫Cloud Run היא סביבה מנוהלת ללא שרת (serverless), כך שלא צריך להקצות תשתית. כדי לשמור על אבטחת הפריסות שלכם ב-Cloud Run, אתם צריכים להגדיר IAM.

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

זהויות שפועלות כחשבונות שירות בפריסה של Cloud Run.

כל אחת מהזהויות האלה מיושמת כחשבון שירות ומשמשת למטרה ספציפית, כפי שמתואר בטבלה הבאה.

חשבון שירות בשימוש על ידי מטרה תפקידים נדרשים
Azure Pipelines Publisher פיתוח צינור עיבוד נתונים פרסום קובצי אימג' של Docker ב-Artifact Registry roles/artifactregistry.writer (פרויקט ייצור בלבד)
Azure Pipelines Deployer צינור עיבוד נתונים להפצה התחלת פריסות של Cloud Run roles/run.admin
הפעלת שירות CloudDemo roles/iam.serviceAccountUser
סוכן שירות של Cloud Run Cloud Run שליפת קובצי אימג' של Docker מ-Artifact Registry roles/artifactregistry.reader (פרויקט ייצור בלבד)
מריץ CloudDemo (חשבון שירות של זמן ריצה) שירות CloudDemo גישה למשאבים ב- Google Cloud ללא

יצרתם והגדרתם את חשבון השירות של Azure Pipelines Publisher. בקטעים הבאים נסביר איך ליצור ולהגדיר את שאר חשבונות השירות.

הגדרת חשבון השירות של Cloud Run

  1. פותחים את Cloud Shell.

  2. מאתחלים את משתני הסביבה הבאים:

    DEV_PROJECT_ID=DEV_PROJECT_ID
PROD_PROJECT_ID=PROD_PROJECT_ID

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

    • ‫DEV_PROJECT_ID: מזהה הפרויקט של פרויקט הפיתוח
    • ‫PROD_PROJECT_ID: מזהה הפרויקט של פרויקט הייצור

  3. מפעילים את Cloud Run API ואת Compute Engine API בפרויקטים של הפיתוח ושל המוצר:

    gcloud services enable run.googleapis.com --project=$DEV_PROJECT_ID
gcloud services enable run.googleapis.com --project=$PROD_PROJECT_ID

    הפעלת ממשקי ה-API האלה גורמת ליצירת חשבונות של סוכני שירות Cloud Run בפרויקטים שלכם.

  4. נותנים לשני חשבונות סוכני השירות של Cloud Run גישה ל-Artifact Registry בפרויקט הייצור שבו מאוחסנים קובצי האימג' של Docker:

    DEV_PROJECT_NUMBER=$(gcloud projects describe $DEV_PROJECT_ID \
    --format='value(projectNumber)')
PROD_PROJECT_NUMBER=$(gcloud projects describe $PROD_PROJECT_ID \
    --format='value(projectNumber)')

gcloud projects add-iam-policy-binding $PROD_PROJECT_ID \
    --member=serviceAccount:service-$DEV_PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com \
    --role roles/artifactregistry.reader

gcloud projects add-iam-policy-binding $PROD_PROJECT_ID \
    --member=serviceAccount:service-$PROD_PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com \
    --role roles/artifactregistry.reader

הגדרת חשבון ההרצה של CloudDemo

עכשיו אפשר להגדיר את חשבון ההרצה CloudDemo, שהוא חשבון שירות מותאם אישית של זמן ריצה לשירות CloudDemo:

  • יוצרים חשבון שירות בשם CloudDemo-runner:

    gcloud iam service-accounts create clouddemo-runner \
    --display-name="CloudDemo Runner" \
    --project=$DEV_PROJECT_ID

gcloud iam service-accounts create clouddemo-runner \
    --display-name="CloudDemo Runner" \
    --project=$PROD_PROJECT_ID

DEV_CLOUDDEMO_RUNNER=clouddemo-runner@$DEV_PROJECT_ID.iam.gserviceaccount.com

PROD_CLOUDDEMO_RUNNER=clouddemo-runner@$PROD_PROJECT_ID.iam.gserviceaccount.com

הגדרת חשבון הפריסה של Azure Pipelines

לבסוף, יוצרים ומגדירים את חשבון הפריסה של Azure Pipelines, שצינור הפריסה של Azure משתמש בו כדי לפרוס ב-Cloud Run.

  1. יוצרים חשבון שירות בשם azure-pipelines-deployer:

    gcloud iam service-accounts create azure-pipelines-deployer \
    --display-name="Azure Pipelines Deployer" \
    --project=$PROD_PROJECT_ID

AZURE_PIPELINES_DEPLOYER=azure-pipelines-deployer@$PROD_PROJECT_ID.iam.gserviceaccount.com

  2. מקצים תפקידי IAM נדרשים כדי לפרוס שירותים או עדכונים חדשים של Cloud Run בפרויקט הפיתוח:

    gcloud projects add-iam-policy-binding $DEV_PROJECT_ID \
    --member serviceAccount:$AZURE_PIPELINES_DEPLOYER \
    --role roles/run.admin

gcloud iam service-accounts add-iam-policy-binding \
    $DEV_CLOUDDEMO_RUNNER \
    --member=serviceAccount:$AZURE_PIPELINES_DEPLOYER \
    --role="roles/iam.serviceAccountUser" \
    --project=$DEV_PROJECT_ID

  3. מקצים את אותה קבוצת תפקידים לפרויקט הייצור:

    gcloud projects add-iam-policy-binding $PROD_PROJECT_ID \
    --member serviceAccount:$AZURE_PIPELINES_DEPLOYER \
    --role roles/run.admin

gcloud iam service-accounts add-iam-policy-binding \
    $PROD_CLOUDDEMO_RUNNER \
    --member=serviceAccount:$AZURE_PIPELINES_DEPLOYER \
    --role="roles/iam.serviceAccountUser" \
    --project=$PROD_PROJECT_ID

  4. יוצרים מפתח לחשבון השירות:

    gcloud iam service-accounts keys create azure-pipelines-deployer.json \
    --iam-account=$AZURE_PIPELINES_DEPLOYER \
    --project=$PROD_PROJECT_ID

cat azure-pipelines-deployer.json | base64 -w 0

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

הגדרת צינור עיבוד הנתונים להפצה

עכשיו אפשר לחזור אל Azure Pipelines כדי להפוך את הפריסה לאוטומטית. הפריסה כוללת את השלבים הבאים:

  • פריסה בסביבת הפיתוח.
  • בקשת אישור ידני לפני הפעלת פריסה בסביבת הייצור.
  • פריסה בסביבת הייצור.

יצירת הגדרת גרסה

קודם כל, יוצרים הגדרת גרסה:

  1. בתפריט Azure DevOps, בוחרים באפשרות Pipelines > Releases.
  2. לוחצים על New pipeline (צינור חדש).
  3. ברשימת התבניות, בוחרים באפשרות Empty job (משימה ריקה).
  4. כשמתבקשים להזין שם לשלב, מזינים Development.
  5. בחלק העליון של המסך, נותנים שם לצינור CloudDemo.
  6. בתרשים של צינור הנתונים, לצד Artifacts (פריטי מידע), לוחצים על Add (הוספה).
  7. לוחצים על Build (בנייה) ומוסיפים את ההגדרות הבאות:
    • סוג המקור: Build
    • מקור (צינור עיבוד נתונים לבנייה): בוחרים את הגדרת הבנייה (אמורה להיות רק אפשרות אחת)
    • גרסת ברירת המחדל: האחרונה
    • כינוי המקור: build
  8. לוחצים על הוספה.
  9. בתיבה Artifact (ארטיפקט), לוחצים על Continuous deployment trigger (הסמל של חץ ברק) כדי להוסיף טריגר לפריסה.
  10. בקטע Continuous deployment trigger (טריגר לפריסה רציפה), מעבירים את המתג למצב Enabled (מופעל).
  11. לוחצים על Save.

  12. אם רוצים, כותבים תגובה ומאשרים בלחיצה על אישור.

    צינור העיבוד ייראה כך:

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

פריסה בפרויקט הפיתוח

אחרי שיוצרים את הגדרת הגרסה, אפשר להגדיר את הפריסה של Cloud Run בפרויקט הפיתוח.

  1. בתפריט, עוברים לכרטיסייה משימות.
  2. לוחצים על Agent job (משימת סוכן).
  3. מגדירים את Agent specification לערך ubuntu-22.04.
  4. לצד Agent job, לוחצים על Add a task to agent job כדי להוסיף שלב לשלב.
  5. בוחרים את המשימה Command line (שורת פקודה) ולוחצים על Add (הוספה).

  6. לוחצים על המשימה שנוספה ומגדירים את ההגדרות הבאות:

    1. שם לתצוגה: Deploy image to development project

    2. סקריפט:

      gcloud auth activate-service-account \
    --quiet \
    --key-file <(echo $(ServiceAccountKey) | base64 -d) && \
gcloud run deploy clouddemo \
    --quiet \
    --service-account=clouddemo-runner@$(CloudRun.ProjectId.Development).iam.gserviceaccount.com \
    --allow-unauthenticated \
    --image=$(CloudRun.Region)-docker.pkg.dev/$(ContainerRegistry.ProjectId)/docker/clouddemo:$BUILD_BUILDID \
    --platform=managed \
    --region=$(CloudRun.Region) \
    --project=$(CloudRun.ProjectId.Development)

      הפקודה הזו מקבלת מפתח של חשבון שירות ממשתנה סביבה, ואז משתמשת ב-CLI של gcloud כדי לפרוס את האפליקציה ב-Cloud Run. ה-CLI של gcloud זמין כברירת מחדל בסוכני Azure Pipelines.

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

    שם ערך Secret
    ServiceAccountKey נוצר מפתח לחשבון השירות azure-pipelines-deployer לפני זמן מה. כן
    ContainerRegistry.ProjectId מזהה הפרויקט של פרויקט הייצור.
    CloudRun.Region האזור שבחרתם קודם לפריסת משאבי Artifact Registry.
    CloudRun.ProjectId.Development מזהה הפרויקט של פרויקט הפיתוח.
    CloudRun.ProjectId.Production מזהה הפרויקט של פרויקט הייצור.

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

  9. אם רוצים, כותבים תגובה ומאשרים בלחיצה על אישור.

פריסה באשכול הייצור

לבסוף, מגדירים את הפריסה בפרויקט הייצור:

  1. בתפריט, עוברים לכרטיסייה Pipeline.
  2. בתיבה 'שלבים', בוחרים באפשרות הוספה > שלב חדש.
  3. ברשימת התבניות, בוחרים באפשרות Empty job (משימה ריקה).
  4. כשמתבקשים להזין שם לשלב, מזינים Production.
  5. לוחצים על סמל הברק של השלב החדש שנוצר.

  6. מגדירים את ההגדרות הבאות:

    1. Select trigger (בחירת טריגר): After stage (אחרי שלב)
    2. שלבים: פיתוח
    3. אישורים לפני פריסה: (מופעל)
    4. גורמים מאשרים: בוחרים את שם המשתמש.

    צינור העיבוד יציג תצוגה שדומה לזו שבהמשך.

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

  7. עוברים לכרטיסייה משימות.

  8. מעבירים את העכבר מעל הכרטיסייה משימות ובוחרים באפשרות משימות > הפקה.

  9. לוחצים על Agent job (משימת סוכן).

  10. מגדירים את Agent specification לערך ubuntu-22.04.

  11. לוחצים על הוספת משימה לעבודת הסוכן כדי להוסיף שלב לשלב.

  12. בוחרים את המשימה שורת פקודה ולוחצים על Add (הוספה).

  13. לוחצים על המשימה שנוספה ומגדירים את ההגדרות הבאות:

    1. שם לתצוגה: Deploy image to production project

    2. סקריפט:

      gcloud auth activate-service-account \
    --quiet \
    --key-file <(echo $(ServiceAccountKey) | base64 -d) && \
gcloud run deploy clouddemo \
    --quiet \
    --service-account=clouddemo-runner@$(CloudRun.ProjectId.Production).iam.gserviceaccount.com \
    --allow-unauthenticated \
    --image=$(CloudRun.Region)-docker.pkg.dev/$(ContainerRegistry.ProjectId)/docker/clouddemo:$BUILD_BUILDID \
    --platform=managed \
    --region=$(CloudRun.Region) \
    --project=$(CloudRun.ProjectId.Production)

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

  15. אם רוצים, כותבים תגובה ומאשרים בלחיצה על אישור.

הרצת צינור עיבוד הנתונים

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

  1. במחשב המקומי, פותחים את הקובץ applications\clouddemo\netcore\CloudDemo.MvcCore\Views\Home\Index.cshtml ממאגר Git ששיבטתם קודם.
  2. הערך של ViewBag.Title השתנה מ-Home Page ל-Home Page Cloud Run.

  3. שומרים את השינויים ודוחפים אותם אל Azure Pipelines.

    Visual Studio

    1. פותחים את Team Explorer ולוחצים על סמל דף הבית.
    2. לוחצים על שינויים.
    3. מזינים הודעת קומיט כמו Change site title.
    4. לוחצים על Commit All and Push (ביצוע Commit של הכול והעלאה).

    שורת הפקודה

    1. העברת כל הקבצים ששונו אל אזור ההכנה:

      git add -A

    2. שומרים את השינויים במאגר המקומי:

      git commit -m "Change site title"

    3. שליחת השינויים אל Azure Pipelines:

      git push

  4. בתפריט Azure DevOps, בוחרים באפשרות Pipelines (צינורות). מופעל build.

  5. אחרי שהבנייה מסתיימת, בוחרים באפשרות Pipelines (צינורות) > Releases (גרסאות). A מתחיל תהליך פרסום.

  6. לוחצים על Release-1 כדי לפתוח את דף הפרטים, ומחכים שהסטטוס של שלב הפיתוח ישתנה להצלחה.

  7. במסוף Google Cloud , עוברים לפרויקט הפיתוח.

  8. בתפריט, בוחרים באפשרות Compute > Cloud Run.

    השירות clouddemo נפרס בהצלחה.

    סטטוס הפריסה ב-Cloud Run.

  9. כדי לראות פרטים נוספים, לוחצים על clouddemo.

    מוצגת כתובת URL שמעידה על כך ש-Cloud Run הקצה את השירות.

  10. פותחים את כתובת ה-URL בכרטיסייה חדשה בדפדפן כדי לוודא שאפליקציית CloudDemo נפרסה ושהיא משתמשת בכותרת המותאמת אישית.

  11. ב-Azure Pipelines, לוחצים על Approve (לצד השלב Production) כדי לקדם את הפריסה לסביבת הייצור.

  12. (אופציונלי) כותבים תגובה.

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

  14. במסוף Google Cloud , עוברים לפרויקט הייצור.

  15. בתפריט, בוחרים באפשרות Compute > Cloud Run.

    השירות clouddemo נפרס בפרויקט הייצור.

  16. כדי לראות פרטים נוספים, לוחצים על clouddemo.

    מוצגת כתובת URL שמעידה על כך ש-Cloud Run הקצה את השירות.

  17. פותחים את כתובת ה-URL בכרטיסייה חדשה בדפדפן כדי לוודא שאפליקציית CloudDemo נפרסה בסביבת הייצור ושהיא משתמשת בכותרת המותאמת אישית.

הסרת המשאבים

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

מחיקת הפרויקט ב-Azure Pipelines

כדי למחוק את פרויקט Azure Pipelines, אפשר לעיין במסמכי Azure DevOps Services. מחיקת הפרויקט ב-Azure Pipelines תגרום לאובדן של כל השינויים בקוד המקור.

מחיקת הפרויקטים Google Cloud של הפיתוח והייצור

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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