Azure Pipelines と Compute Engine による CI/CD パイプラインの作成

Last reviewed 2023-03-09 UTC

このチュートリアルでは、Azure Pipelines、Compute Engine を使用して、ASP.NET MVC ウェブアプリケーション用の継続的インテグレーション/継続的デプロイ（CI/CD）パイプラインを作成する方法について説明します。このアプリケーションは Microsoft Internet Information Services を使用し、Windows Server で動作します。

CI / CD パイプラインは、テスト用と本番環境用の 2 種類の環境を使用します。

パイプラインの始めに、デベロッパーがサンプルコードベースへの変更を commit します。このアクションがトリガーとなり、パイプラインによってアプリケーションがビルドされ、zip ファイルとしてパッケージ化され、zip ファイルが Cloud Storage にアップロードされます。

次にパッケージは、ローリングアップデートを使用して開発環境に自動的にリリースされます。リリースのテストが完了したら、リリースマネージャーはリリースを昇格して本番環境にデプロイできます。

このチュートリアルは、デベロッパーと DevOps エンジニアを対象としています。また、.NET Framework、Windows Server、IIS、Azure Pipelines、Compute Engine に関する基本的な知識があることを前提としています。ここでは、Azure DevOps アカウントへの管理アクセス権限も必要となります。

目標

Compute Engine マネージドインスタンスグループを使用して、ローリングデプロイを実装します。
Azure Pipelines で CI / CD パイプラインを設定して、ビルド、作成、デプロイプロセスをオーケストレートします。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

Azure DevOps を使用した場合に適用される可能性がある費用については、Azure DevOps の料金ページをご覧ください。

始める前に

Identity and Access Management（IAM）の役割と権限を個別に付与できるようにするため、通常は開発環境と本番環境のワークロードに別個のプロジェクトを使用することをおすすめします。わかりやすくするために、このチュートリアルでは、開発環境、本番環境で 1 つのプロジェクトを使用します。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Enable the Compute Engine and Cloud Storage APIs.
Enable the APIs

Make sure that billing is enabled for your Google Cloud project.

Azure DevOps アカウントがあり、そのアカウントに対する管理者権限があることを確認します。Azure DevOps アカウントがまだない場合は、Azure DevOps ホームページで登録できます。

Azure DevOps プロジェクトを作成する

Azure DevOps を使用して、ソースコードの管理、ビルドとテストの実行、Compute Engine へのデプロイのオーケストレートを行います。はじめに、Azure DevOps アカウントでプロジェクトを作成します。

Azure DevOps ホームページ（https://dev.azure.com/YOUR_AZURE_DEVOPS_ACCOUNT_NAME）に移動します。
[New Project] をクリックします。
CloudDemo などのプロジェクト名を入力します。
[Visibility] を [Private] に設定してから、[Create] をクリックします。
プロジェクトを作成したら、左側のメニューで [Repos] をクリックします。
[Import] をクリックして GitHub から dotnet-docs-samples リポジトリを fork し、次の値を設定します。
- Repository type: Git
- Clone URL: https://github.com/GoogleCloudPlatform/dotnet-docs-samples.git
[Import] をクリックします。

インポート処理が完了すると、dotnet-docs-samples リポジトリのソースコードが表示されます。
メニューで、[Repos] > [ブランチ] をクリックします。
main ブランチの上にマウスを移動します。右側に [...] ボタンが表示されます。
[...] > [Set as default branch] をクリックします。

継続的にビルドする

この段階で Azure Pipelines を使用してビルドパイプラインを設定できます。commit によって Git リポジトリへの push を行うたびに、Azure Pipelines によってコードがビルドされ、zip ファイルにパッケージ化されて、生成されたパッケージが内部の Azure Pipelines ストレージに公開されます。

その後、Azure Pipelines ストレージからパッケージを使用して Compute Engine にデプロイするリリースパイプラインを構成します。

ビルド定義を作成する

Azure Pipeline で YAML 構文を使用する新しいビルド定義を作成します。

Visual Studio またはコマンドライン git クライアントを使用して、新しい Git リポジトリのクローンを作成します。
リポジトリのルートで、azure-pipelines.yml という名前のファイルを作成します。

次のコードをコピーしてファイルに貼り付けます。

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)'

変更を commit し、Azure Pipelines に push します。
Visual Studio
1. チームエクスプローラーを開き、[Home] アイコンをクリックします。
2. [変更] をクリックします。
3. 「Add pipeline definition」といった Commit メッセージを入力します。
4. [すべてをコミットしてプッシュ] をクリックします。
コマンドライン
1. 変更されたすべてのファイルをステージングします。
  git add -A
2. ローカルリポジトリへの変更を commit します。
  git commit -m "Add pipeline definition"
3. Azure DevOps への変更を push します。
  git push
Azure DevOps のメニューで、[Pipelines] を選択して、[Create Pipeline] をクリックします。
[Azure Reposs Git] を選択します。
リポジトリを選択します。
[Review your pipeline YAML] ページで、[Run] をクリックします。

新しいビルドがトリガーされます。ビルドが完了するまでに 2 分ほどかかる場合があります。ビルドが終了すると、内部の Azure Pipelines アーティファクトストレージ領域で、アプリケーションパッケージ CloudDemo.Mvc.zip を使用できます。アプリケーションパッケージには、このウェブアプリケーションのすべてのファイルが格納されています。

継続的デプロイ

これまでの手順で、commit するたびに Azure Pipelines が自動的にコードをビルドするようになりました。次は、デプロイ手順に進みます。

他の継続的インテグレーションシステムとは異なり、Azure Pipelines ではビルドとデプロイが区別され、デプロイ関連のすべてのタスクに、リリース管理というラベルが付けられた専用のツールセットが提供されます。

Azure Pipelines リリース管理は、次のコンセプトに基づいて構築されています。

リリースは、通常はビルドプロセスの結果からなる、アプリの特定のバージョンを形成するアーティファクト群である。
デプロイは、リリースを特定の環境に導入する過程である。
デプロイによって一連のタスクが実行される。タスクはジョブでグループ化できる。
ステージによってパイプラインを分割でき、ステージを使用することで、開発環境やテスト環境などの複数の環境へのデプロイをオーケストレートできる。

新しくビルドが完了すると、必ずリリースパイプラインがトリガーされるように設定します。パイプラインは次の 3 つのステージで構成されています。

最初のステージでは、パイプラインは Azure Pipelines アーティファクトストレージ領域からアプリケーションパッケージを取得し、Cloud Storage バケットに公開して、Compute Engine からパッケージにアクセスできるようにします。
第 2 ステージでは、パイプラインはローリングアップデートを使用して開発環境を更新します。
最終ステージでは、承認後、パイプラインはローリングアップデートを使用して本番環境を更新します。

ビルドアーティファクト用の Cloud Storage バケットを作成する

アプリケーションパッケージを保存するための Cloud Storage バケットを作成します。後で、新しい VM インスタンスがこのバケットからアプリケーションパッケージを自動的に pull できるように Compute Engine を構成します。

Google Cloud コンソールで、新しく作成されたプロジェクトに切り替えます。
Cloud Shell を開きます。

Cloud Shell に移動
時間を節約するには、プロジェクト ID のデフォルト値と Compute Engine ゾーンのデフォルト値を設定します。
```
gcloud config set project PROJECT_ID
gcloud config set compute/zone ZONE
```
PROJECT_ID を Google Cloud プロジェクトの ID に置き換え、ZONE をリソースの作成に使用するゾーンの名前に置き換えます。どのゾーンを選択するかわからない場合は、us-central1-a を使用します。

例:
```
gcloud config set project devops-test-project-12345
gcloud config set compute/zone us-central1-a
```
アプリケーションパッケージ用に新しい Cloud Storage バケットを作成します。
```
gsutil mb gs://$(gcloud config get-value core/project)-artifacts
```
すべてのビルドのアプリケーションパッケージを維持しない場合は、特定の期間を経過したファイルを削除するようにオブジェクトライフサイクルルールを構成することを検討してください。

Azure Pipelines 用のサービスアカウントを設定する

Azure Pipelines が Google Cloud プロジェクトにアクセスする際に使用できる Google Cloud サービスアカウントを作成します。

Azure Pipelines のサービスアカウントを作成します。

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

ストレージオブジェクト閲覧者（roles/storage.objectViewer）とストレージオブジェクト作成者（roles/storage.objectCreator）の IAM ロールを 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

Compute Engine 管理者（roles/compute.admin）のロールを azure-pipelines サービスアカウントに付与して、Azure Pipelines が VM インスタンスを管理できるようにします。
```
gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
    --member serviceAccount:$AZURE_PIPELINES_SERVICE_ACCOUNT \
    --role roles/compute.admin
```

サービスアカウントキーを生成します。

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 でデプロイが自動化されるようにステップを構成するには、あらかじめ開発環境を準備しておく必要があります。この準備には、ウェブサーバーの VM インスタンスを管理するマネージドインスタンスグループの作成が含まれます。また、HTTP ロードバランサの作成も含まれます。

Cloud Shell で、マネージドインスタンスグループのサービスアカウントを作成します。
```
DEV_SERVICE_ACCOUNT=$(gcloud iam service-accounts create clouddemo-dev --format "value(email)")
```
ストレージオブジェクト閲覧者 IAM ロール（roles/storage.objectViewer）をサービスアカウントに付与して、VM インスタンスが Cloud Storage からアプリケーションパッケージをダウンロードできるようにします。
```
gcloud projects add-iam-policy-binding $(gcloud config get-value core/project) \
    --member serviceAccount:$DEV_SERVICE_ACCOUNT \
    --role roles/storage.objectViewer
```

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

標準の 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

HTTP ヘルスチェックを作成します。アプリケーションには専用のヘルスチェックエンドポイントがないため、パス / を照会できます。
```
gcloud compute http-health-checks create clouddemo-dev-http \
    --check-interval=10s --unhealthy-threshold=10 \
    --request-path=/
```
初期インスタンステンプレートをベースとするマネージドインスタンスグループを作成します。説明をわかりやすくするために、次のコマンドはゾーンを対象とするマネージドインスタンスグループを作成します。ただし、同じ方法を使用して、リージョンを対象とするマネージドインスタンスグループを作成して複数のゾーンに VM インスタンスを配信することもできます。
```
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
```

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)

ロードバランサフロントエンドを作成します。

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

gclb-backend タグでアノテーションが設定されたインスタンスに HTTP リクエストを送信することを Google ロードバランサに許可するファイアウォールルールを作成します。このタグは、後続の手順でウェブサービスの VM インスタンスに適用します。
```
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
```

本番環境を構成する

本番環境を設定するには、開発環境を構成する手順と同様の手順を行う必要があります。

Cloud Shell で、HTTP ヘルスチェックを作成します。

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

前の手順で作成した初期インスタンステンプレートをベースとするマネージドインスタンスグループをさらに作成します。

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

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)

ロードバランサフロントエンドを作成します。

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

リリースパイプラインを構成する

新しいリリース定義を作成します。

Azure DevOps のメニューで、[Pipelines] > [Releases] の順に選択します。
[New pipeline] をクリックします。
テンプレートのリストから [Empty job] を選択します。
ステージの名前の入力を求められたら、「Publish」と入力します。
画面の上部で、リリースに clouddemo-ComputeEngine という名前を付けます。
パイプライン図で、[Artifacts] の横にある [Add] をクリックします。
[Build] を選択して、次の設定を追加します。
- Source: azure-pipelines.yml ファイルを含む Git リポジトリを選択します。
- Default version: Latest
- Source alias: CloudDemo.Web
[Add] をクリックします。
[Artifact] ボックスで [Continuous deployment trigger]（稲妻のアイコン）をクリックしてデプロイトリガーを追加します。
[Continuous deployment trigger] で、スイッチを [Enabled] に設定します。
[Save] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

パイプラインは次のようになります。

Azure Pipelines のパイプラインのスクリーンショット

Cloud Storage に公開する

リリース定義を作成したら、アプリケーションパッケージを Cloud Storage に公開する手順を追加できます。

Azure Pipelines で [Tasks] タブに切り替えます。
[Agent job] をクリックし、次の設定を構成します。
- エージェントプール: Azure Pipelines
- エージェントの仕様: ubuntu-latest
[Agent job] の横の [Add a task to agent job] をクリックします。
[bash] タスクを選択し、[Add] をクリックします。

新たに追加したタスクをクリックし、以下の設定を構成します。

Display name: Publish to Cloud Storage
タイプ: インライン

Script:

cat << "EOF" > CloudDemo.Mvc.deploy.ps1
    $ErrorActionPreference = "Stop"

    # Download application package from Cloud Storage
    gsutil 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)

gsutil cp $(System.ArtifactsDirectory)/CloudDemo.Web/CloudDemo.Web/CloudDemo.Mvc.zip gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).zip
gsutil cp CloudDemo.Mvc.deploy.ps1 gs://$(CloudDemo.ProjectId)-artifacts/CloudDemo.Mvc-$(Build.BuildId)-$(Release.ReleaseId).deploy.ps1

このスクリプトは次のことを行います。

IIS を構成する起動スクリプトを生成します。
環境変数からサービスアカウントキーを使用して Google Cloud に対する認証を行うように Google Cloud CLI を構成します。
アプリケーションパッケージと起動スクリプトを Cloud Storage にアップロードします。

[変数] タブに切り替えて、次の変数を追加します。

Name	Value	シークレット
`ServiceAccountKey`	前に `azure-pipelines-deployer` 用に作成されたサービスアカウントキー。	はい
`CloudDemo.ProjectId`	Google Cloud プロジェクトのプロジェクト ID。
`CloudDemo.Zone`	前の手順で `gcloud config set compute/zone` を実行したときに指定したゾーン（例: `us-central1-a`）

[保存] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

開発環境をデプロイする

これで、開発環境へのローリングデプロイを開始する手順を追加できるようになりました。

Azure Pipelines で [Pipeline] タブに切り替えます。
[Stages] ボックスで、[Add] > [New stage] の順に選択します。
テンプレートのリストから [Empty job] を選択します。
ステージの名前の入力を求められたら、「Dev」と入力します。
新たに作成したステージの稲妻のアイコンをクリックします。
次のように構成します。
- Select trigger: After stage
- Stages: Publish
[Tasks] タブにマウスを合わせ、[Tasks] > [Prod] の順に選択します。
[Agent job] をクリックし、次の設定を構成します。
- エージェントプール: Azure Pipelines
- エージェントの仕様: ubuntu-latest
[Agent job] の横の [Add a task to agent job] をクリックします。
[bash] タスクを選択し、[Add] をクリックします。

新たに追加したタスクをクリックし、以下の設定を構成します。

Display name: Rolling deploy
タイプ: インライン

Script:

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)

このスクリプトは次のことを行います。

環境変数からサービスアカウントキーを使用して Google Cloud に対する認証を行うように Google Cloud CLI を構成します。
前のステージで生成された起動スクリプトを使用する新しいインスタンステンプレートを作成します。
新しいインスタンステンプレートを使用するように、既存のインスタンスグループを更新します。このコマンドを実行しても、既存の VM はいずれも置換または更新されないことに注意してください。既存の VM に作用するのではなく、今後このインスタンスグループで作成される VM が新しいテンプレートから作成されるようになります。
既存のインスタンスグループで、ローリング方式で既存の VM が新しい VM に置き換えられるように、ローリングアップデートを開始します。

[保存] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

本番環境をデプロイする

最後に、本番環境へのデプロイを構成する必要があります。

Azure Pipelines で [Pipeline] タブに切り替えます。
[Stages] ボックスで、[Add] > [New stage] の順に選択します。
テンプレートのリストから [Empty job] を選択します。
ステージの名前の入力を求められたら、「Prod」と入力します。
新たに作成したステージの稲妻のアイコンをクリックします。
次のように構成します。
- Select trigger: After stage
- Stages: Dev
- Pre-deployment approvals: （有効）
- Approvers: 自分のユーザー名を選択します。
[Tasks] タブにマウスを合わせ、[Tasks] > [Prod] の順にクリックします。
[Agent job] をクリックし、次の設定を構成します。
- エージェントプール: Azure Pipelines
- エージェントの仕様: ubuntu-latest
[Agent job] の横の [Add a task to agent job] をクリックして、フェーズにステップを追加します。
[bash] タスクを選択し、[Add] をクリックします。

新たに追加したタスクをクリックし、以下の設定を構成します。

Display name: Rolling deploy
タイプ: インライン

Script:

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)

[保存] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

パイプラインを実行する

パイプライン全体の構成が済んだら、ソースコードを変更してパイプラインをテストできます。

ローカルのパソコンで、先ほどクローンを作成した Git リポジトリからファイル applications\clouddemo\net4\CloudDemo.Mvc\Views\Home\Index.cshtml を開きます。
ViewBag.Title の値を Home Page から This app runs on GKE に変更します。
変更を commit し、Azure Pipelines に push します。
Visual Studio
1. チームエクスプローラーを開き、[Home] アイコンをクリックします。
2. [変更] をクリックします。
3. 「Change site title」といった Commit メッセージを入力します。
4. [すべてをコミットしてプッシュ] をクリックします。
コマンドライン
1. 変更されたすべてのファイルをステージングします。
  git add -A
2. ローカルリポジトリへの変更を commit します。
  git commit -m "Change site title"
3. 変更を Azure Pipelines に push します。
  git push
Azure DevOps のメニューで [Pipelines] を選択します。

ビルドがトリガーされます。
ビルドが完了したら、[Pipelines] > [Releases] の順に選択します。リリースプロセスが開始されます。
[Release-1] をクリックして詳細ページを開き、Dev ステージのステータスが [Succeeded] に切り替わるのを待ちます。
Google Cloud コンソールで、[ネットワークサービス] > [ロードバランシング] > [clouddemo-dev] を選択します。

フロントエンドの IP アドレスをメモします。
新しいブラウザウィンドウを開き、次のアドレスに移動します。
```
http://IP_ADDRESS/clouddemo/
```
ここで、IP_ADDRESS はフロントエンドの IP アドレスです。

アプリケーションがデプロイされ、カスタムタイトルが使用されていることを確認します。

ロードバランサが利用可能になるまで数分かかるため、最初はエラーが表示される場合があります。
Azure Pipelines で、[Prod] ステージの下にある [Approve] ボタンをクリックして、本番環境へのデプロイをプロモートします。

ボタンが表示されない場合は、まず以前のリリースを承認または却下する必要があります。
必要に応じてコメントを入力し、[承認] をクリックして確定します。
Prod 環境のステータスが [成功] に切り替わるのを待ちます。
Google Cloud コンソールで、[ネットワークサービス] > [ロードバランシング] > [clouddemo-prod] を選択します。

フロントエンドの IP アドレスをメモします。
新しいブラウザウィンドウを開き、次のアドレスに移動します。
```
http://IP_ADDRESS/clouddemo/
```
ここで、IP_ADDRESS はフロントエンドの IP アドレスです。

アプリケーションがデプロイされ、カスタムタイトルが使用されていることを確認します。

クリーンアップ

このチュートリアルの完了後に請求が発生しないようにするには、作成したエンティティを削除します。

Azure Pipelines プロジェクトの削除

Azure Pipelines プロジェクトを削除するには、Azure DevOps Services のドキュメントをご覧ください。Azure Pipelines プロジェクトを削除すると、すべてのソースコードの変更が失われます。

Google Cloud の開発プロジェクトと本番環境プロジェクトを削除する

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

イメージ管理のベストプラクティスを確認する。
Compute Engine に可用性の高い SQL Server グループをデプロイする方法を学習する。
Google Cloud Platform での .NET についての説明を確認する。
Cloud Tools for Visual Studio をインストールする。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud Architecture Center をご覧ください。

Azure Pipelines と Compute Engine による CI/CD パイプラインの作成

目標

費用

始める前に

Azure DevOps プロジェクトを作成する

継続的にビルドする

ビルド定義を作成する

Visual Studio

コマンドライン

継続的デプロイ

ビルド アーティファクト用の Cloud Storage バケットを作成する

Azure Pipelines 用のサービス アカウントを設定する

開発環境を構成する

本番環境を構成する

リリース パイプラインを構成する

Cloud Storage に公開する

開発環境をデプロイする

本番環境をデプロイする

パイプラインを実行する

Visual Studio

コマンドライン

クリーンアップ

Azure Pipelines プロジェクトの削除

Google Cloud の開発プロジェクトと本番環境プロジェクトを削除する

次のステップ

ビルドアーティファクト用の Cloud Storage バケットを作成する

Azure Pipelines 用のサービスアカウントを設定する

リリースパイプラインを構成する