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

Last reviewed 2023-03-09 UTC

このチュートリアルでは、Azure PipelinesCompute 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 つのプロジェクトを使用します。

  1. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  2. Compute Engine and Cloud Storage API を有効にします。

    API を有効にする

  3. Google Cloud プロジェクトで課金が有効になっていることを確認します

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

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

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

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

    インポート処理が完了すると、dotnet-docs-samples リポジトリのソースコードが表示されます。

  8. メニューで、[Repos] > [ブランチ] をクリックします。

  9. main ブランチの上にマウスを移動します。右側に [...] ボタンが表示されます。

  10. [...] > [Set as default branch] をクリックします。

継続的にビルドする

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

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

ビルド定義を作成する

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

  1. Visual Studio またはコマンドライン git クライアントを使用して、新しい 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. 変更を 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
      
  5. Azure DevOps のメニューで、[Pipelines] を選択して、[Create Pipeline] をクリックします。

  6. [Azure Reposs Git] を選択します。

  7. リポジトリを選択します。

  8. [Review your pipeline YAML] ページで、[Run] をクリックします。

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

継続的デプロイ

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

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

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

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

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

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

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

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

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

    Cloud Shell に移動

  3. 時間を節約するには、プロジェクト 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
  4. アプリケーション パッケージ用に新しい Cloud Storage バケットを作成します。

    gsutil mb gs://$(gcloud config get-value core/project)-artifacts
    

    すべてのビルドのアプリケーション パッケージを維持しない場合は、特定の期間を経過したファイルを削除するようにオブジェクト ライフサイクル ルールを構成することを検討してください。

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

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

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

    AZURE_PIPELINES_SERVICE_ACCOUNT=$(gcloud iam service-accounts create azure-pipelines --format "value(email)")
    
  2. ストレージ オブジェクト閲覧者(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
    
  3. 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
    
  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 でデプロイが自動化されるようにステップを構成するには、あらかじめ開発環境を準備しておく必要があります。この準備には、ウェブサーバーの VM インスタンスを管理するマネージド インスタンス グループの作成が含まれます。また、HTTP ロードバランサの作成も含まれます。

  1. Cloud Shell で、マネージド インスタンス グループのサービス アカウントを作成します。

    DEV_SERVICE_ACCOUNT=$(gcloud iam service-accounts create clouddemo-dev --format "value(email)")
    
  2. ストレージ オブジェクト閲覧者 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
    
  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. 初期インスタンス テンプレートをベースとするマネージド インスタンス グループを作成します。説明をわかりやすくするために、次のコマンドはゾーンを対象とするマネージド インスタンス グループを作成します。ただし、同じ方法を使用して、リージョンを対象とするマネージド インスタンス グループを作成して複数のゾーンに 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
    
  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. 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
    

本番環境を構成する

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

  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] を選択して、次の設定を追加します。

    • Source: azure-pipelines.yml ファイルを含む Git リポジトリを選択します。
    • Default version: Latest
    • Source alias: CloudDemo.Web
  8. [Add] をクリックします。

  9. [Artifact] ボックスで [Continuous deployment trigger](稲妻のアイコン)をクリックしてデプロイ トリガーを追加します。

  10. [Continuous deployment trigger] で、スイッチを [Enabled] に設定します。

  11. [Save] をクリックします。

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

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

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

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] タスクを選択し、[Add] をクリックします。
  5. 新たに追加したタスクをクリックし、以下の設定を構成します。

    • 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
      

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

    1. IIS を構成する起動スクリプトを生成します。
    2. 環境変数からサービス アカウント キーを使用して Google Cloud に対する認証を行うように Google Cloud CLI を構成します。
    3. アプリケーション パッケージと起動スクリプトを Cloud Storage にアップロードします。
  6. [変数] タブに切り替えて、次の変数を追加します。

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

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

開発環境をデプロイする

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

  1. Azure Pipelines で [Pipeline] タブに切り替えます。
  2. [Stages] ボックスで、[Add] > [New stage] の順に選択します。
  3. テンプレートのリストから [Empty job] を選択します。
  4. ステージの名前の入力を求められたら、「Dev」と入力します。
  5. 新たに作成したステージの稲妻のアイコンをクリックします。
  6. 次のように構成します。

    • Select trigger: After stage
    • Stages: Publish
  7. [Tasks] タブにマウスを合わせ、[Tasks] > [Prod] の順に選択します。

  8. [Agent job] をクリックし、次の設定を構成します。

    • エージェント プール: Azure Pipelines
    • エージェントの仕様: ubuntu-latest
  9. [Agent job] の横の [Add a task to agent job] をクリックします。

  10. [bash] タスクを選択し、[Add] をクリックします。

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

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

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

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

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

本番環境をデプロイする

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

  1. Azure Pipelines で [Pipeline] タブに切り替えます。
  2. [Stages] ボックスで、[Add] > [New stage] の順に選択します。
  3. テンプレートのリストから [Empty job] を選択します。
  4. ステージの名前の入力を求められたら、「Prod」と入力します。
  5. 新たに作成したステージの稲妻のアイコンをクリックします。
  6. 次のように構成します。

    • Select trigger: After stage
    • Stages: Dev
    • Pre-deployment approvals: (有効)
    • Approvers: 自分のユーザー名を選択します。
  7. [Tasks] タブにマウスを合わせ、[Tasks] > [Prod] の順にクリックします。

  8. [Agent job] をクリックし、次の設定を構成します。

    • エージェント プール: Azure Pipelines
    • エージェントの仕様: ubuntu-latest
  9. [Agent job] の横の [Add a task to agent job] をクリックして、フェーズにステップを追加します。

  10. [bash] タスクを選択し、[Add] をクリックします。

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

    • 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)
      
  12. [保存] をクリックします。

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

パイプラインを実行する

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

  1. ローカルのパソコンで、先ほどクローンを作成した Git リポジトリからファイル applications\clouddemo\net4\CloudDemo.Mvc\Views\Home\Index.cshtml を開きます。
  2. ViewBag.Title の値を Home Page から This app runs on GKE に変更します。
  3. 変更を 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
      
  4. Azure DevOps のメニューで [Pipelines] を選択します。

    ビルドがトリガーされます。

  5. ビルドが完了したら、[Pipelines] > [Releases] の順に選択します。リリース プロセスが開始されます。

  6. [Release-1] をクリックして詳細ページを開き、Dev ステージのステータスが [Succeeded] に切り替わるのを待ちます。

  7. Google Cloud コンソールで、[ネットワーク サービス] > [ロード バランシング] > [clouddemo-dev] を選択します。

    フロントエンドの IP アドレスをメモします。

  8. 新しいブラウザ ウィンドウを開き、次のアドレスに移動します。

    http://IP_ADDRESS/clouddemo/
    

    ここで、IP_ADDRESS はフロントエンドの IP アドレスです。

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

    ロードバランサが利用可能になるまで数分かかるため、最初はエラーが表示される場合があります。

  9. Azure Pipelines で、[Prod] ステージの下にある [Approve] ボタンをクリックして、本番環境へのデプロイをプロモートします。

    ボタンが表示されない場合は、まず以前のリリースを承認または却下する必要があります。

  10. 必要に応じてコメントを入力し、[承認] をクリックして確定します。

  11. Prod 環境のステータスが [成功] に切り替わるのを待ちます。

  12. Google Cloud コンソールで、[ネットワーク サービス] > [ロード バランシング] > [clouddemo-prod] を選択します。

    フロントエンドの IP アドレスをメモします。

  13. 新しいブラウザ ウィンドウを開き、次のアドレスに移動します。

    http://IP_ADDRESS/clouddemo/
    

    ここで、IP_ADDRESS はフロントエンドの IP アドレスです。

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

クリーンアップ

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

Azure Pipelines プロジェクトの削除

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

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

  1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ