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

Last reviewed 2023-03-09 UTC

במדריך הזה נסביר איך להשתמש ב-Azure Pipelines וב-Compute Engine כדי ליצור צינור עיבוד נתונים של אינטגרציה רציפה (CI) ופריסה רציפה (CD) לאפליקציית אינטרנט של ASP.NET MVC. האפליקציה משתמשת ב-Microsoft Internet Information Services (IIS) ופועלת ב-Windows Server.

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

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

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

המדריך הזה מיועד למפתחים ולמהנדסי DevOps. ההנחה היא שיש לכם ידע בסיסי ב-NET Framework, ב-Windows Server, ב-IIS, ב-Azure Pipelines וב-Compute Engine. בנוסף, כדי לבצע את ההדרכה, צריכה להיות לכם הרשאת אדמין בחשבון Azure DevOps.

מטרות

• משתמשים ב-Managed Instance Groups ב-Compute Engine כדי להטמיע פריסות מתגלגלות.
• מגדירים צינור עיבוד נתונים של CI/CD ב-Azure Pipelines כדי לתזמן את תהליכי הבנייה, היצירה והפריסה.

עלויות

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

• Compute Engine
• Cloud Load Balancing
• Cloud Storage

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

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

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

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

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

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

1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

   תפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
   הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

   כניסה לדף לבחירת הפרויקט

2. מפעילים את Compute Engine API ואת Cloud Storage API, אם הם עדיין לא מופעלים.

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

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

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

הערה: כדי לפעול לפי המדריך הזה, אפשר להשתמש בלקוח Git של שורת הפקודה או ב-Visual Studio. אם אתם משתמשים ב-Visual Studio, ודאו שהוא מחובר לחשבון שלכם ב-Azure DevOps.

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

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

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

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

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

8. בתפריט, לוחצים על Repos > Branches (מאגרי מידע > ענפים).

9. מעבירים את העכבר מעל הענף main. בצד שמאל יופיע הלחצן ....

10. לוחצים על ... > הגדרה כענף ברירת מחדל.

בנייה רציפה

עכשיו אפשר להשתמש ב-Azure Pipelines כדי להגדיר צינור עיבוד נתונים לבנייה. לכל קומיט שנשלח למאגר Git,‏ Azure Pipelines בונה את הקוד, אורז אותו לקובץ ZIP ומפרסם את החבילה שנוצרת באחסון הפנימי של Azure Pipelines.

בהמשך, מגדירים צינור עיבוד נתונים של גרסת הפצה שמשתמש בחבילות מאחסון Azure Pipelines ופורס אותן ב-Compute Engine.

יצירת הגדרת build

יוצרים הגדרת build חדשה ב-Azure Pipelines באמצעות תחביר YAML:

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

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

   resources:
   - repo: self
     fetchDepth: 1
   trigger:
   - main
   variables:
     artifactName: 'CloudDemo.Mvc'
   jobs:
   - job: Build
     displayName: Build application
     condition: succeeded()
     pool:
       vmImage: windows-latest
       demands:
       - msbuild
       - visualstudio
     variables:
       Solution: 'applications/clouddemo/net4/CloudDemo.Mvc.sln'
       BuildPlatform: 'Any CPU'
       BuildConfiguration: 'Release'
       ArtifactName: 'CloudDemo.Web'
     steps:
     - task: NuGetCommand@2
       displayName: 'NuGet restore'
       inputs:
         restoreSolution: '$(Solution)'
     - task: VSBuild@1
       displayName: 'Build solution'
       inputs:
         solution: '$(Solution)'
         msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"'
         platform: '$(BuildPlatform)'
         configuration: '$(BuildConfiguration)'
     - task: PublishBuildArtifacts@1
       displayName: 'Publish Artifact'
       inputs:
         PathtoPublish: '$(build.artifactstagingdirectory)/CloudDemo.Mvc.zip'
         ArtifactName: '$(ArtifactName)'

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 (הפעלה).

   מופעלת גרסת build חדשה. התהליך עשוי להימשך כ-2 דקות. בסיום הבנייה, חבילת האפליקציה CloudDemo.Mvc.zip, שמכילה את כל הקבצים של אפליקציית האינטרנט, זמינה באזור האחסון הפנימי של Azure Pipelines.

פריסה רציפה

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

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

התכונה 'ניהול גרסאות' ב-Azure Pipelines מבוססת על המושגים הבאים:

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

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

1. בשלב הראשון, הפייפליין לוקח את חבילת האפליקציה מאזור האחסון של הארטיפקטים ב-Azure Pipelines ומפרסם אותה בקטגוריה של Cloud Storage, כדי שמכונות של Compute Engine יוכלו לגשת לחבילה.
2. בשלב השני, הצינור מעדכן את סביבת הפיתוח באמצעות עדכון מתגלגל.
3. בשלב האחרון, אחרי האישור, הצינור מעדכן את סביבת הייצור באמצעות עדכון מתגלגל.

יצירת קטגוריה של Cloud Storage עבור ארטיפקטים של בנייה

יוצרים קטגוריה של Cloud Storage לאחסון חבילות של אפליקציות. בהמשך, מגדירים את Compute Engine כך שמכונות וירטואליות חדשות יוכלו לשלוף באופן אוטומטי חבילות של אפליקציות מהקטגוריה הזו.

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

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

   כניסה ל-Cloud Shell

3. כדי לחסוך זמן, כדאי להגדיר ערכי ברירת מחדל למזהה הפרויקט ולאזור Compute Engine:

   gcloud config set project PROJECT_ID
   gcloud config set compute/zone ZONE

   מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud , ואת ZONE בשם התחום (zone) שבו רוצים ליצור את המשאבים. אם אתם לא בטוחים באיזה אזור לבחור, השתמשו באפשרות us-central1-a.

   דוגמה:

   gcloud config set project devops-test-project-12345
   gcloud config set compute/zone us-central1-a

4. יוצרים קטגוריה חדשה של Cloud Storage לחבילות אפליקציות:

   gcloud storage buckets create gs://$(gcloud config get-value core/project)-artifacts
   

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

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

יוצרים Google Cloud חשבון שירות שאפשר להשתמש בו ב-Azure Pipelines כדי לגשת לפרויקט ב- Google Cloud .

1. יוצרים חשבון שירות ל-Azure Pipelines:

   AZURE_PIPELINES_SERVICE_ACCOUNT=$(gcloud iam service-accounts create azure-pipelines --format "value(email)")
   

2. מקצים את תפקידי ה-IAM 'צפייה באובייקט אחסון' (roles/storage.objectViewer) ו'יצירת אובייקטים של אחסון' (roles/storage.objectCreator) לחשבון השירות azure-pipelines כדי ש-Azure Pipelines יוכל להעלות חבילות של אפליקציות ל-Cloud Storage:

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/storage.objectViewer
   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/storage.objectCreator
   

3. מקצים לחשבון השירות azure-pipelines את התפקיד אדמין Compute ‏ (roles/compute.admin) כדי ש-Azure Pipelines יוכל לנהל מכונות וירטואליות:

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/compute.admin
   

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

   gcloud iam service-accounts keys create azure-pipelines-key.json \
     --iam-account=$AZURE_PIPELINES_SERVICE_ACCOUNT
   
   cat azure-pipelines-key.json | base64 -w 0;echo
   
   rm azure-pipelines-key.json
   

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

הגדרת סביבת הפיתוח

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

1. ב-Cloud Shell, יוצרים חשבון שירות לקבוצת מופעי מכונה מנוהלים:

   DEV_SERVICE_ACCOUNT=$(gcloud iam service-accounts create clouddemo-dev --format "value(email)")
   

2. מקצים לחשבון השירות את התפקיד 'צפייה באובייקט אחסון' ב-IAM (roles/storage.objectViewer) כדי שמופעי מכונות וירטואליות יוכלו להוריד חבילות של אפליקציות מ-Cloud Storage:

   gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
       --member serviceAccount:$DEV_SERVICE_ACCOUNT \
       --role roles/storage.objectViewer
   

3. נותנים לחשבון השירות azure-pipelines הרשאה להשתמש בחשבון השירות clouddemo-dev:

   gcloud iam service-accounts add-iam-policy-binding $DEV_SERVICE_ACCOUNT \
       --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
       --role roles/iam.serviceAccountUser
   

4. יוצרים תבנית של הגדרות מכונה שמשתמשת בקובץ אימג' רגיל של Windows Server 2019 Core. תשתמשו בתבנית הזו רק בהתחלה, כי כל בנייה תיצור תבנית חדשה.

   gcloud compute instance-templates create clouddemo-initial \
       --machine-type n1-standard-2 \
       --image-family windows-2019-core \
       --image-project windows-cloud \
       --service-account $DEV_SERVICE_ACCOUNT \
       --scopes https://www.googleapis.com/auth/devstorage.read_only \
       --tags gclb-backend
   

5. יצירת בדיקת תקינות של HTTP. מכיוון שלאפליקציה אין נקודת קצה ייעודית לבדיקת תקינות, אפשר לשלוח שאילתה לנתיב /.

   gcloud compute http-health-checks create clouddemo-dev-http \
       --check-interval=10s --unhealthy-threshold=10 \
       --request-path=/
   

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

   gcloud compute instance-groups managed create clouddemo-dev \
       --template=clouddemo-initial \
       --http-health-check=clouddemo-dev-http \
       --initial-delay=2m \
       --size=1 && \
   gcloud compute instance-groups set-named-ports clouddemo-dev --named-ports http:80
   

7. יוצרים שירות לקצה העורפי של מאזן עומסים שמשתמש בבדיקת תקינות HTTP ובקבוצת מופעי מכונה מנוהלים שיצרתם קודם:

   gcloud compute backend-services create clouddemo-dev-backend \
       --http-health-checks clouddemo-dev-http \
       --port-name http --protocol HTTP --global && \
   gcloud compute backend-services add-backend clouddemo-dev-backend \
       --instance-group clouddemo-dev --global \
       --instance-group-zone=$(gcloud config get-value compute/zone)
   

8. יוצרים קצה קדמי של מאזן עומסים:

   gcloud compute url-maps create clouddemo-dev --default-service clouddemo-dev-backend && \
   gcloud compute target-http-proxies create clouddemo-dev-proxy --url-map=clouddemo-dev && \
   gcloud compute forwarding-rules create clouddemo-dev-fw-rule --global --target-http-proxy clouddemo-dev-proxy --ports=80
   

9. יוצרים כלל חומת אש שמאפשר למאזן העומסים של Google לשלוח בקשות HTTP למכונות שסומנו בתג gclb-backend. בהמשך תפעילו את התג הזה על מכונות וירטואליות של שירותי אינטרנט.

   gcloud compute firewall-rules create gclb-backend --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gclb-backend --allow tcp:80
   

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

הגדרת סביבת הייצור דורשת רצף של שלבים שדומים לאלה של הגדרת סביבת הפיתוח.

1. ב-Cloud Shell, יוצרים בדיקת תקינות של HTTP:

   gcloud compute http-health-checks create clouddemo-prod-http \
       --check-interval=10s --unhealthy-threshold=10 \
       --request-path=/
   

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

   gcloud compute instance-groups managed create clouddemo-prod \
       --template=clouddemo-initial \
       --http-health-check=clouddemo-prod-http \
       --initial-delay=2m \
       --size=1 && \
   gcloud compute instance-groups set-named-ports clouddemo-prod --named-ports http:80
   

3. יוצרים שירות לקצה העורפי של מאזן עומסים שמשתמש בבדיקת תקינות HTTP ובקבוצת מופעי מכונה מנוהלים שיצרתם קודם:

   gcloud compute backend-services create clouddemo-prod-backend --http-health-checks clouddemo-prod-http --port-name http --protocol HTTP --global && \
   gcloud compute backend-services add-backend clouddemo-prod-backend --instance-group clouddemo-prod --global --instance-group-zone=$(gcloud config get-value compute/zone)
   

4. יוצרים קצה קדמי של מאזן עומסים:

   gcloud compute url-maps create clouddemo-prod --default-service clouddemo-prod-backend && \
   gcloud compute target-http-proxies create clouddemo-prod-proxy --url-map=clouddemo-prod && \
   gcloud compute forwarding-rules create clouddemo-prod-fw-rule --global --target-http-proxy clouddemo-prod-proxy --ports=80
   

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

יצירת הגדרה חדשה של גרסה:

1. בתפריט Azure DevOps, בוחרים באפשרות Pipelines (צינורות) > Releases (גרסאות).
2. לוחצים על New pipeline (צינור חדש).
3. ברשימת התבניות, בוחרים באפשרות Empty job (משימה ריקה).
4. כשמתבקשים להזין שם לשלב, מזינים Publish.
5. בחלק העליון של המסך, נותנים שם לגרסה clouddemo-ComputeEngine.
6. בתרשים של צינור הנתונים, ליד Artifacts (פריטי מידע), לוחצים על Add (הוספה).

7. בוחרים באפשרות Build (בנייה) ומוסיפים את ההגדרות הבאות:

   • מקור: בוחרים את מאגר ה-Git שמכיל את הקובץ azure-pipelines.yml.
   • גרסת ברירת מחדל: Latest
   • כינוי של המקור: CloudDemo.Web

8. לוחצים על הוספה.

9. בתיבה Artifact (ארטיפקט), לוחצים על Continuous deployment trigger (הסמל של חץ הברק) כדי להוסיף טריגר לפריסה.

10. בקטע Continuous deployment trigger (טריגר לפריסה רציפה), מעבירים את המתג למצב Enabled (מופעל).

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

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

עכשיו צינור הנתונים נראה כך:

פרסום ב-Cloud Storage

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

1. ב-Azure Pipelines, עוברים לכרטיסייה Tasks (משימות).
2. לוחצים על Agent job ומגדירים את ההגדרות הבאות:
   • מאגר סוכנים: Azure Pipelines
   • מפרט הסוכן: ubuntu-latest
3. לצד Agent job (משימה של סוכן), לוחצים על Add a task to agent job (הוספת משימה למשימה של סוכן) .
4. בוחרים את המשימה bash ולוחצים על הוספה.

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

   • שם לתצוגה: Publish to Cloud Storage
   • Type: inline

   • סקריפט:

     cat << "EOF" > CloudDemo.Mvc.deploy.ps1
         $ErrorActionPreference = "Stop"
     
         # Download application package from Cloud Storage
         gcloud storage cp gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).zip $env:TEMP\app.zip
     
         # Install IIS
         Enable-WindowsOptionalFeature -Online -FeatureName `
             NetFx4Extended-ASPNET45, `
             IIS-WebServerRole, `
             IIS-WebServer, `
             IIS-CommonHttpFeatures, `
             IIS-HttpErrors, `
             IIS-HttpRedirect, `
             IIS-ApplicationDevelopment, `
             IIS-HealthAndDiagnostics, `
             IIS-HttpLogging, `
             IIS-LoggingLibraries, `
             IIS-RequestMonitor, `
             IIS-HttpTracing, `
             IIS-Security, `
             IIS-RequestFiltering, `
             IIS-Performance, `
             IIS-WebServerManagementTools, `
             IIS-IIS6ManagementCompatibility, `
             IIS-Metabase, `
             IIS-DefaultDocument, `
             IIS-ApplicationInit, `
             IIS-NetFxExtensibility45, `
             IIS-ISAPIExtensions, `
             IIS-ISAPIFilter, `
             IIS-ASPNET45, `
             IIS-HttpCompressionStatic
     
         # Extract application package to wwwroot
         New-Item -ItemType directory -Path $env:TEMP\app
         Add-Type -AssemblyName System.IO.Compression.FileSystem
         [System.IO.Compression.ZipFile]::ExtractToDirectory("$env:TEMP\app.zip", "$env:TEMP\app")
         Remove-Item $env:TEMP\app.zip
         Move-Item -Path $(dir -recurse $env:TEMP\app\**\PackageTmp | % { $_.FullName }) -Destination c:\inetpub\wwwroot\app -force
     
         # Configure IIS web application pool and application
         Import-Module WebAdministration
         New-WebAppPool clouddemo-net4
         Set-ItemProperty IIS:\AppPools\clouddemo-net4 managedRuntimeVersion v4.0
         New-WebApplication -Name clouddemo -Site 'Default Web Site' -PhysicalPath c:\inetpub\wwwroot\app -ApplicationPool clouddemo-net4
     
         # Grant read/execute access to the application pool user
         &icacls C:\inetpub\wwwroot\app\ /grant "IIS AppPool\clouddemo-net4:(OI)(CI)(RX)"
     EOF
     
     gcloud auth activate-service-account \
         --quiet \
         --key-file <(echo $(ServiceAccountKey) | base64 -d)
     
     gcloud storage cp $(System.ArtifactsDirectory)/CloudDemo.Web/CloudDemo.Web/CloudDemo.Mvc.zip gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).zip
     gcloud storage cp CloudDemo.Mvc.deploy.ps1 gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1
     

   הסקריפט הזה מבצע את הפעולות הבאות:

   1. יוצר סקריפט לטעינה בזמן ההפעלה שמגדיר את IIS.
   2. מגדירה את Google Cloud CLI כך שישתמש במפתח של חשבון השירות מתוך משתנה הסביבה כדי לבצע אימות ל- Google Cloud.
   3. העלאה של חבילת האפליקציה וסקריפט לטעינה בזמן ההפעלה ל-Cloud Storage.

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

   שם	ערך	Secret
   ServiceAccountKey	נוצר מפתח לחשבון השירות azure-pipelines-deployer קודם לכן.	כן
   CloudDemo.ProjectId	מזהה הפרויקט של פרויקט Google Cloud .
   CloudDemo.Zone	האזור שציינתם קודם כשמריצים את gcloud config set compute/zone (לדוגמה, us-central1-a)

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

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

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

עכשיו אפשר להוסיף את השלבים להפעלת פריסה מתגלגלת לסביבת הפיתוח.

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

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

   • בחירת טריגר: After stage
   • שלבים: Publish

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

8. לוחצים על Agent job ומגדירים את ההגדרות הבאות:

   • מאגר סוכנים: Azure Pipelines
   • מפרט הסוכן: ubuntu-latest

9. לצד Agent job (משימה של סוכן), לוחצים על Add a task to agent job (הוספת משימה למשימה של סוכן) .

10. בוחרים את המשימה bash ולוחצים על הוספה.

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

    • שם לתצוגה: Rolling deploy
    • Type: inline

    • סקריפט:

      INSTANCE_TEMPLATE=clouddemo-$(Build.BuildId)-$(Release.ReleaseId)
      
      gcloud auth activate-service-account \
          --quiet \
          --key-file <(echo $(ServiceAccountKey) | base64 -d)
      
      gcloud compute instance-templates create $INSTANCE_TEMPLATE \
        --machine-type n1-standard-2 \
        --image-family windows-2019-core \
        --image-project windows-cloud \
        --service-account clouddemo-dev@$(CloudDemo.ProjectId).iam.gserviceaccount.com \
        --scopes https://www.googleapis.com/auth/devstorage.read_only \
        --tags gclb-backend \
        --metadata sysprep-specialize-script-url=gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1 \
        --project $(CloudDemo.ProjectId) \
      
      gcloud compute instance-groups managed set-instance-template clouddemo-dev \
        --template $INSTANCE_TEMPLATE \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      
      gcloud compute instance-groups managed rolling-action start-update clouddemo-dev \
        --version template=$INSTANCE_TEMPLATE \
        --type proactive \
        --max-unavailable 0 \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      

    הסקריפט הזה מבצע את הפעולות הבאות:

    1. מגדירה את Google Cloud CLI כך שישתמש במפתח של חשבון השירות מתוך משתנה הסביבה כדי לבצע אימות ל- Google Cloud.
    2. יוצר תבנית חדשה של הגדרות מכונה שמשתמשת בסקריפט ההפעלה שנוצר בשלב הקודם.
    3. מעדכן את קבוצת המופעים הקיימת כדי להשתמש בתבנית החדשה של המופע. הערה: הפקודה הזו עדיין לא גורמת להחלפה או לעדכון של אף אחת מהמכונות הווירטואליות הקיימות. במקום זאת, היא מוודאת שכל מכונה וירטואלית עתידית בקבוצת המופעים הזו תיצור מהתבנית החדשה.
    4. מתחילים עדכון מדורג, שגורם להחלפת המכונות הווירטואליות הקיימות במכונות וירטואליות חדשות בקבוצת המכונות הקיימת, באופן מדורג.

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

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

פריסת סביבת הייצור

לבסוף, צריך להגדיר את הפריסה בסביבת הייצור.

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

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

   • בחירת טריגר: After stage
   • שלבים: Dev
   • אישורים לפני פריסה: (מופעל)
   • גורמים מאשרים: בוחרים את שם המשתמש שלכם.

7. מעבירים את העכבר מעל הכרטיסייה משימות ולוחצים על משימות > Prod.

8. לוחצים על Agent job ומגדירים את ההגדרות הבאות:

   • מאגר סוכנים: Azure Pipelines
   • מפרט הסוכן: ubuntu-latest

9. לצד Agent job (משימה של סוכן), לוחצים על Add a task to agent job (הוספת משימה למשימה של סוכן) כדי להוסיף שלב לשלב.

10. בוחרים את המשימה bash ולוחצים על הוספה.

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

    • שם לתצוגה: Rolling deploy
    • Type: inline

    • סקריפט:

      INSTANCE_TEMPLATE=clouddemo-$(Build.BuildId)-$(Release.ReleaseId)
      
      gcloud auth activate-service-account \
          --quiet \
          --key-file <(echo $(ServiceAccountKey) | base64 -d)
      
      gcloud compute instance-templates create $INSTANCE_TEMPLATE \
        --machine-type n1-standard-2 \
        --image-family windows-2019-core \
        --image-project windows-cloud \
        --service-account clouddemo-prod@$(CloudDemo.ProjectId).iam.gserviceaccount.com \
        --scopes https://www.googleapis.com/auth/devstorage.read_only \
        --tags gclb-backend \
        --metadata sysprep-specialize-script-url=gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1 \
        --project $(CloudDemo.ProjectId) \
      
      gcloud compute instance-groups managed set-instance-template clouddemo-prod \
        --template $INSTANCE_TEMPLATE \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      
      gcloud compute instance-groups managed rolling-action start-update clouddemo-prod \
        --version template=$INSTANCE_TEMPLATE \
        --type proactive \
        --max-unavailable 0 \
        --project $(CloudDemo.ProjectId) \
        --zone $(CloudDemo.Zone)
      

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

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

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

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

1. במחשב המקומי, פותחים את הקובץ applications\clouddemo\net4\CloudDemo.Mvc\Views\Home\Index.cshtml ממאגר Git ששיבטתם קודם.
2. לשנות את הערך של ViewBag.Title מ-Home Page ל-This app runs on GKE.

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 (צינורות).

   הפעלתם בנייה.

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

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

7. במסוף Google Cloud , בוחרים באפשרות Network Services (שירותי רשת) > Load balancing (איזון עומסים) > clouddemo-dev.

   שימו לב לכתובת ה-IP של חזית האתר.

8. פותחים חלון חדש בדפדפן ועוברים לכתובת הבאה:

   http://IP_ADDRESS/clouddemo/
   

   כאשר IP_ADDRESS היא כתובת ה-IP של חזית האתר.

   שימו לב שהאפליקציה נפרסה ושהיא משתמשת בכותרת המותאמת אישית.

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

9. ב-Azure Pipelines, לוחצים על הלחצן אישור שנמצא מתחת לשלב Prod כדי להעביר את הפריסה לסביבת הייצור.

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

10. אם רוצים, כותבים תגובה ואז לוחצים על אישור כדי לאשר את הבקשה.

11. מחכים שהסטטוס של סביבת הייצור ישתנה להצלחה.

12. במסוף Google Cloud , בוחרים באפשרות Network Services > Load balancing > clouddemo-prod.

    שימו לב לכתובת ה-IP של חזית האתר.

13. פותחים חלון חדש בדפדפן ועוברים לכתובת הבאה:

    http://IP_ADDRESS/clouddemo/
    

    כאשר IP_ADDRESS היא כתובת ה-IP של חזית האתר.

    שימו לב שהאפליקציה נפרסה ושהיא משתמשת בכותרת המותאמת אישית.

הסרת המשאבים

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

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

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

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

זהירות: כשמוחקים פרויקט:

• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

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

   כניסה לדף Manage resources

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

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

• שיטות מומלצות לניהול תמונות
• איך פורסים קבוצת SQL Server עם זמינות גבוהה ב-Compute Engine
• מידע נוסף על .NET ב-Google Cloud Platform
• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.