Azure Pipelines と Google Kubernetes Engine を使用した CI / CD パイプラインの作成

このチュートリアルでは、Azure Pipelines、Google Kubernetes Engine（GKE）、Container Registry を使用して継続的インテグレーション / 継続的デプロイ（CI / CD）パイプラインを作成する方法を説明します。ここでは ASP.NET Core を基にした ASP.NET MusicStore ウェブアプリを使用します。

次の図に示すように、CI / CD パイプラインは、開発用と本番環境用の 2 つの GKE クラスタを使用します。

デベロッパーとエンドユーザーがアプリケーションとやり取りする方法を示す CI / CD パイプラインの概念図

パイプラインの始めに、デベロッパーがサンプルコードベースへの変更を commit します。この操作がトリガーとなり、パイプラインによってリリースが作成され、開発クラスタにデプロイされます。その後リリース管理者がリリースをプロモートし、本番環境クラスタにデプロイします。

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

目標

Docker イメージを公開するために Container Registry を Azure Pipelines に接続する。
GKE にデプロイするための .NET Core サンプルアプリを準備する。
従来の認証を使用せずに GKE での認証を安全に実施する。
Azure Pipelines リリース管理を使用して GKE のデプロイをオーケストレートする。

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

GKE
Cloud Load Balancing
Cloud Storage（Container Registry 用）

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

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳しくは、クリーンアップをご覧ください。

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

始める前に

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

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

注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

[プロジェクトの選択] ページに移動

Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する。

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

Azure DevOps プロジェクトの作成

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

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

インポートプロセスが完了すると、MusicStore アプリのソースコードが表示されます。

継続的なビルド

この段階で Azure Pipelines を使用して継続的インテグレーションを設定できます。commit によって Git リポジトリへの push を行うたびに、Azure Pipelines によってコードがビルドされ、そのビルドのアーティファクトが Docker コンテナにパッケージ化されます。そのコンテナは Container Registry に公開されます。

デフォルトの分岐の設定

このチュートリアルは、MusicStore アプリのバージョン 2.1 でビルド、テストされています。同じバージョンを使用するには、Azure Pipelines が release/2.1 分岐をデフォルトの分岐として使用するように構成します。

Azure DevOps のメニューで、[Project settings] を選択します。
[Repos] > [Repositories] の順に選択します。
リポジトリのリストで、先ほどインポートした Git リポジトリを選択します。Azure DevOps プロジェクトと同じ名前になっているはずです。
[Branches] の横の矢印をクリックして分岐のリストを展開します。
[release/2.1] の分岐を選択します。分岐名の横に ... ボタンが表示されます。
[...] をクリックし、[Set as default branch] を選択します。

コードをビルドする

分岐を作成したら、ビルドの自動化を開始できます。MusicStore は ASP.NET Core アプリであるため、コードのビルドは 4 つのステップからなります。

依存関係をダウンロードしてインストールする。
コードをコンパイルする。
単体テストを実施する。
ビルド結果を公開する。

後で、GKE へのデプロイを行うためのステップを追加します。GKE は Linux ベースの環境であるため、ビルドプロセス全体を Linux ベースのビルドエージェントで実行するように設定します。

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

次のコードをファイルにコピーします。

resources:
- repo: self
  fetchDepth: 1
queue:
  name: Hosted Ubuntu 1604
trigger:
- release/2.1
variables:
  TargetFramework: 'netcoreapp2.1'
  RestoreBuildProjects: 'samples/**/*.csproj'
  TestProjects: 'test/MusicStore.Test/*.csproj'
  BuildConfiguration: 'Release'
  DockerImageName: 'PROJECT_ID/musicstore'
steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '$(RestoreBuildProjects)'
    feedsToUse: config
    nugetConfigPath: NuGet.config
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    projects: '$(RestoreBuildProjects)'
    arguments: '--configuration $(BuildConfiguration) --framework=$(TargetFramework)'
- task: DotNetCoreCLI@2
  displayName: Test
  inputs:
    command: test
    projects: '$(TestProjects)'
    arguments: '--configuration $(BuildConfiguration) --framework=$(TargetFramework)'
- task: DotNetCoreCLI@2
  displayName: Publish
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --framework=$(TargetFramework)'
    zipAfterPublish: false
    modifyOutputPath: false

PROJECT_ID をプロジェクトの名前に置き換え、ファイルを保存します。

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

Git リポジトリに commit した YAML ファイルに基づいてビルド定義が作成されます。

Docker イメージを公開する

MusicStore アプリを GKE にデプロイするには、アプリを Docker コンテナイメージとしてパッケージ化し、Container Registry で利用可能にする必要があります。このタスクには、本番環境プロジェクトでの Container Registry を使用します。

イメージを公開するためのサービスアカウントを設定する

コンテナイメージをビルドして公開できるよう Azure Pipelines を構成する前に、Container Registry で Azure Pipelines が認証されることを確認する必要があります。そのためには、本番環境プロジェクトで Google Cloud サービスアカウントを作成します。

Cloud Console で自分のプロジェクトに切り替えます。
Cloud Console で、Cloud Shell をアクティブにします。

Cloud Shell をアクティブにする
プロジェクト ID と Compute Engine ゾーンの各オプションを入力する時間を節約するために、次のコマンドを実行してデフォルトの構成値を設定します。
```
gcloud config set project PROJECT_ID
gcloud config set compute/zone ZONE
```
PROJECT_ID は、GCP プロジェクトの ID に置き換えます。ZONE は、リソースの作成に使用するゾーンの名前に置き換えます。選択するゾーンが不明な場合は、us-central1-a を使用します。

例:
```
gcloud config set project azure-pipelines-test-project-12345
gcloud config set compute/zone us-central1-a
```
このプロジェクト用に Container Registry API を有効にします。
```
gcloud services enable containerregistry.googleapis.com
```
Docker イメージを公開する際に使用する、Azure Pipelines のサービスアカウントを作成します。
```
gcloud iam service-accounts create azure-pipelines-publisher \
    --display-name "Azure Pipelines Publisher"
```

そのサービスアカウントにストレージ管理者の IAM 役割を割り当てます。

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

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \
    --member serviceAccount:$AZURE_PIPELINES_PUBLISHER \
    --role roles/storage.admin

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

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

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

Cloud Shell メニューで、[エディタを開く] をクリックします。
azure-pipelines-publisher-oneline.json というファイルを開きます。このファイルの内容が以下の手順で必要になります。

Azure Pipeline を Container Registry に接続する

サービスアカウントを作成したら、Azure Pipelines を Container Registry に接続できます。

Azure の [DevOps] メニューで、[Project settings] を選択してから、[Pipelines] > [Service connections] の順に選択します。
[New service connection] をクリックします。
リストから [Docker Registry] を選択し、[Next] をクリックします。
ダイアログの以下のフィールドに値を入力します。
- Registry type: Others
- Docker Registry: https://gcr.io/PROJECT_ID、PROJECT_ID はプロジェクト名に置き換えます（例: https://gcr.io/azure-pipelines-test-project-12345）。
- Docker ID: _json_key
- Password: azure-pipelines-publisher-oneline.json の内容を貼り付けます。
- Service connection name: gcr-tutorial
[Save] をクリックして接続を作成します。

Dockerfile の作成

これで、Azure Pipelines がコンテナイメージのビルドに使用する Dockerfile を作成できます。

リポジトリのルートで、Dockerfile という名前のファイルを作成します。

ファイルに次のコードをコピーし、ファイルを保存します。

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1
WORKDIR /app
COPY samples/MusicStore/bin/Release/netcoreapp2.1/publish /app/
COPY samples/MusicStore/config.json /app/

ENV ASPNETCORE_URLS=http://0.0.0.0:8080

ENTRYPOINT ["dotnet", "MusicStore.dll"]

Git ワークスペースのルートに deployment.yaml という名前の別のファイルを作成します。この段階ではこのファイルを空のままにしておきます。
変更を commit します。
Visual Studio
1. チームエクスプローラーを開き、左上の [ホーム] アイコンをクリックして [ホーム] ビューに切り替えます。
2. [変更] をクリックします。
3. 「Add Dockerfile and placeholder for the Kubernetes manifest」といった Commit メッセージを入力します。
4. [すべてをコミット] をクリックします。
コマンドライン
1. 変更されたすべてのファイルをステージングします。
```
git add -A
```
2. ローカルリポジトリへの変更を commit します。
```
git commit -m "Add Dockerfile and placeholder for the Kubernetes manifest"
```

Docker イメージをビルドするためのビルド定義を拡張する

必要なファイルをすべてチェックインしたら、ビルド定義を拡張できます。

azure-pipelines.yml ファイルを開きます。

このファイルに次のコードを付加してビルド定義を拡張します。

- task: CmdLine@1
  displayName: 'Lock image version in deployment.yaml'
  inputs:
    filename: /bin/bash
    arguments: '-c "awk ''{gsub(\"MUSICSTORE_IMAGE\", \"gcr.io/$(DockerImageName):$(Build.BuildId)\", $0); print}'' deployment.yaml > $(build.artifactstagingdirectory)/deployment.yaml"'
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
- task: Docker@0
  displayName: 'Build image'
  inputs:
    containerregistrytype: 'Container Registry'
    dockerRegistryConnection: 'gcr-tutorial'
    imageName: '$(DockerImageName):$(Build.BuildId)'
- task: Docker@0
  displayName: 'Publish image'
  inputs:
    containerregistrytype: 'Container Registry'
    dockerRegistryConnection: 'gcr-tutorial'
    action: 'Push an image'
    imageName: '$(DockerImageName):$(Build.BuildId)'

変更を commit し、Azure Pipelines に push します。
Visual Studio
1. チームエクスプローラーを開き、左上の [ホーム] アイコンをクリックして [ホーム] ビューに切り替えます。
2. [変更] をクリックします。
3. 「Extend build definition to build Docker image」といった Commit メッセージを入力します。
4. [すべてをコミットしてプッシュ] をクリックします。
コマンドライン
1. 変更されたすべてのファイルをステージングします。
```
git add -A
```
2. ローカルリポジトリへの変更を commit します。
```
git commit -m "Extend build definition to build Docker image"
```
3. Azure DevOps への変更を push します。
```
git push
```
Azure DevOps のメニューで [Pipelines] を選択します。

新しいビルドは自動的にトリガーされます。ビルドが完了するまで 2 分ほどかかります。ビルドの完了には 2 分ほどかかります。
イメージが Container Registry に公開されたことを確認するには、Cloud Console に切り替え、[Container Registry] > [Images] の順に選択し、[musicstore] をクリックします。

1 つのイメージと、そのイメージのタグが表示されます。このタグは、Azure Pipelines で実行されたビルドの数値 ID に対応しています。

継続的デプロイ

commit するたびに Azure Pipelines で自動的にコードのビルドと Docker イメージの公開が実施されるようになったら、デプロイするための操作に移行できます。

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

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

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

MusicStore のビルドプロセスによって生成されるメインアーティファクトは Docker イメージです。ただし、Docker イメージは Container Registry に公開されるため、Azure Pipelines の対象範囲に含まれません。そのため、Docker イメージをリリースの定義としては利用できません。

Kubernetes をデプロイするには、マニフェストも必要です。マニフェストは部品表（BOM）に似ています。マニフェストは Kubernetes によって作成、管理されるリソースを定義するだけでなく、使用する Docker イメージのバージョンも明示します。Kubernetes マニフェストは、Azure Pipelines リリース管理でリリースを定義するアーティファクトとして適しています。

Kubernetes のデプロイを構成する

Kubernetes で MusicStore を実行するには、以下のリソースが必要です。

Deployment。ビルドによって生成された Docker イメージを実行する単一のポッドを定義します。
NodePort サービス。このサービスによってロードバランサがポッドにアクセスできます。
Ingress。これにより、Cloud HTTP(S) ロードバランサを使用してアプリケーションが公共のインターネットに公開されます。

MusicStore アプリケーションでは、SQL Server またはローカルに保存された組み込みデータベースを使用できます。説明をわかりやすくするため、組み込みデータベースに依存するデフォルトの構成を使用します。ただし、次の 2 つの制限が存在します。

一度に実行できるポッドのコピーは 1 つだけです。複数のポッドを実行すると、ユーザーに表示されるデータがポッドごとに変わる可能性があります。
デプロイで永続ボリュームを使用するように変更しないと、ポッドを再起動するたびにすべてのデータ変更が失われます（この状況については、このチュートリアルでは取り上げません）。

上記の Kubernetes リソースを定義する手順は次のとおりです。

deployment.yaml を開いて次のコードを貼り付け、ファイルを保存します。

apiVersion: v1
kind: Service
metadata:
  name: musicstore
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: musicstore
  type: NodePort

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: musicstore
spec:
  backend:
    serviceName: musicstore
    servicePort: 80

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: musicstore
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: musicstore
    spec:
      containers:
      - name: musicstore
        image: MUSICSTORE_IMAGE
        ports:
          - containerPort: 8080
        livenessProbe:      # Used by deployment controller
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        readinessProbe:     # Used by Ingress/GCLB
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 3
          periodSeconds: 5
        resources:
          limits:
            memory: 1024Mi
          requests:
            memory: 768Mi

変更を commit し、Azure Pipelines に push します。
Visual Studio
1. チームエクスプローラーを開き、左上の [ホーム] アイコンをクリックして [ホーム] ビューに切り替えます。
2. [変更] をクリックします。
3. 「Add Kubernetes manifest」といった Commit メッセージを入力します。
4. [すべてをコミットしてプッシュ] をクリックします。
コマンドライン
1. 変更されたすべてのファイルをステージングします。
```
git add -A
```
2. ローカルリポジトリへの変更を commit します。
```
git commit -m "Add Kubernetes manifest"
```
3. Azure DevOps への変更を push します。
```
git push
```

開発環境と本番環境を設定する

Azure Pipelines リリース管理に戻る前に、GKE クラスタを作成する必要があります。

GKE クラスタを作成する

Cloud Shell インスタンスに戻ります。
プロジェクトの GKE API を有効にします。
```
gcloud services enable container.googleapis.com
```
次のコマンドを使用して開発クラスタを作成します。完了するまで数分かかることがあります。
```
gcloud container clusters create azure-pipelines-cicd-dev
```
次のコマンドを使用して本番環境クラスタを作成します。完了するまで数分かかることがあります。
```
gcloud container clusters create azure-pipelines-cicd-prod
```

開発クラスタに Azure Pipeline を接続する

Azure Pipelines を使用すると Container Registry などの外部 Docker レジストリに接続できますが、同様に、Azure Pipelines を使用して外部 Kubernetes クラスタを統合できます。

Google Cloud サービスアカウントを使用して Container Registry を認証することは可能ですが、Azure Pipeline での GKE による認証に Google Cloud サービスアカウントを使用することはできません。Azure Pipeline での GKE による認証には、Kubernetes サービスアカウントを使用する必要があります。

したがって、Azure Pipelines を開発クラスタに接続するには、まず Kubernetes サービスアカウントを作成する必要があります。

Cloud Shell で、開発クラスタに接続します。

gcloud container clusters get-credentials azure-pipelines-cicd-dev

Azure Pipeline 用の Kubernetes サービスアカウントを作成します。
```
kubectl create serviceaccount azure-pipelines-deploy
```
クラスタのロールバインディングを作成して、サービスアカウントに cluster-admin のロールを割り当てます。
```
kubectl create clusterrolebinding azure-pipelines-deploy --clusterrole=cluster-admin --serviceaccount=default:azure-pipelines-deploy
```
クラスタの IP アドレスを指定します。
```
gcloud container clusters describe azure-pipelines-cicd-dev --format=value$endpoint$
```
後でこのアドレスが必要になります。
Azure DevOps のメニューで、[Project settings] を選択し、[Pipelines]、[Service connections] の順に選択します。
[New service connection] をクリックします。
[Kubernetes] を選択して [Next] をクリックします。
以下の設定を構成します。

注: 以下の値を取得するには、Cloud Shell で kubectl コマンドを実行してから Azure のページに値をコピーする必要があります。
- Authentication method: サービスアカウント。
- Server URL: https://[PRIMARY_IP]/。[PRIMARY_IP] は前に確認した IP アドレスに置き換えます。
- Secret: Cloud Shell で次のコマンドを実行し、出力をコピーします。
```
kubectl get secret $(kubectl get serviceaccounts azure-pipelines-deploy -o custom-columns=":secrets[0].name") -o yaml
```
- Service connection name: azure-pipelines-cicd-dev。
[Save] をクリックします。

本番環境クラスタに Azure Pipeline を接続する

Azure Pipelines を本番環境クラスタに接続する場合も、同じ手順を使用できます。

Cloud Shell で、本番環境クラスタに接続します。

gcloud container clusters get-credentials azure-pipelines-cicd-prod

Azure Pipeline 用の Kubernetes サービスアカウントを作成します。
```
kubectl create serviceaccount azure-pipelines-deploy
```
クラスタのロールバインディングを作成して、サービスアカウントに cluster-admin のロールを割り当てます。
```
kubectl create clusterrolebinding azure-pipelines-deploy --clusterrole=cluster-admin --serviceaccount=default:azure-pipelines-deploy
```
クラスタの IP アドレスを指定します。
```
gcloud container clusters describe azure-pipelines-cicd-prod --format=value$endpoint$
```
後でこのアドレスが必要になります。
Azure DevOps のメニューで、[Project settings] を選択し、[Pipelines]、[Service connections] の順に選択します。
[New service connection] をクリックします。
[Kubernetes] を選択して [Next] をクリックします。
以下の設定を構成します。

注: 以下の値を取得するには、Cloud Shell で kubectl コマンドを実行してから Azure のページに値をコピーする必要があります。
- Authentication method: サービスアカウント。
- Server URL: https://[PRIMARY_IP]/。[PRIMARY_IP] は前に確認した IP アドレスに置き換えます。
- Secret: Cloud Shell で次のコマンドを実行し、出力をコピーします。
```
kubectl get secret $(kubectl get serviceaccounts azure-pipelines-deploy -o custom-columns=":secrets[0].name") -o yaml
```
- Service connection name: azure-pipelines-cicd-prod。
[Save] をクリックします。

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

GKE インフラストラクチャを設定したら、Azure Pipelines に戻ってデプロイを自動化します。デプロイには以下の操作が含まれます。

開発環境にデプロイする。
本番環境へのデプロイを開始する前に、手動承認をリクエストする。
本番環境にデプロイする。

リリース定義を作成する

最初に、新しいリリース定義を作成します。

Azure DevOps のメニューで、[Pipelines] > [Releases] の順に選択します。
[New pipeline] をクリックします。
テンプレートのリストから [Empty job] を選択します。
ステージの名前の入力を求められたら、「Dev」と入力します。
画面上部でリリースに MusicStore-KubernetesEngine という名前を付けます。
パイプライン図で、[Artifacts] の横にある [Add] をクリックします。
[Build] を選択して、次の設定を追加します。
- Source type: ビルド
- Source（build pipeline）: ビルド定義を選択します（選択肢は 1 つだけです）
- Default version: Latest
- Source Alias: manifest
[Add] をクリックします。
[Artifact] ボックスで [Continuous deployment trigger]（稲妻のアイコン）をクリックしてデプロイトリガーを追加します。
[Continuous deployment trigger] で、スイッチを [Enabled] に設定します。
[Save] をクリックします。
必要に応じてコメントを入力し、[Save] をクリックして確定します。

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

開発クラスタにデプロイする

リリース定義を作成したら、GKE 開発クラスタへのデプロイを構成できるようになります。

メニューで [Tasks] タブに切り替えます。
[Agent job] をクリックします。
エージェントの仕様を [ubuntu-18.04] に設定します。
[Agent job] の横の [Add a task to agent job] をクリックして、フェーズにステップを追加します。
[Deploy to Kubernetes] タスクを選択して、[Add] をクリックします。
新たに追加したタスクをクリックし、以下の設定を構成します。
- Display name: Deploy
- Action: デプロイ
- Kubernetes サービス接続: azure-pipelines-cicd-dev
- Namespace: default
- Strategy: なし
- Manifests: manifest/drop/deployment.yaml
[Save] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

本番環境クラスタにデプロイする

最後に GKE の本番環境クラスタへのデプロイを構成します。

メニューで [Pipeline] タブに切り替えます。
[Stages] ボックスで、[Add] > [New stage] の順に選択します。
テンプレートのリストから [Empty job] を選択します。
ステージの名前の入力を求められたら、「Production」と入力します。
新たに作成したステージの稲妻のアイコンをクリックします。
以下を構成します。
- Select trigger: After stage
- Stages: Dev
- Pre-deployment approvals: （有効）
- Approvers: 自分のユーザー名を選択します。
パイプラインは次のようになります。
[Tasks] タブに切り替えます。
[Tasks] タブにマウスカーソルを合わせ、[Tasks]、[Production] の順に選択します。
[Agent job] をクリックします。
エージェントの仕様を [ubuntu-18.04] に設定します。
[Add a task to agent job] をクリックして、フェーズにステップを追加します。
[Deploy to Kubernetes] タスクを選択して、[Add] をクリックします。
新たに追加したタスクをクリックし、以下の設定を構成します。
- Display name: Deploy
- Action: デプロイ
- Kubernetes service connection: azure-pipelines-cicd-prod
- Namespace: default
- Strategy: なし
- Manifests: manifest/drop/deployment.yaml
[Save] をクリックします。
必要に応じてコメントを入力し、[OK] をクリックして確定します。

パイプラインを実行する

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

ローカルのパソコンで、先ほどクローンを作成した Git リポジトリからファイル samples\MusicStore\config.json を開きます。
3 行目の SiteTitle 設定を ASP.NET MVC Music Store on Kubernetes Engine に変更します。
変更を commit し、Azure Pipelines に push します。
Visual Studio
1. チームエクスプローラーを開き、[Home] アイコンをクリックします。
2. [Changes] をクリックします。
3. 「Change site title」といった Commit メッセージを入力します。
4. [Commit All and Push] をクリックします。
コマンドライン
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] をクリックして詳細ページを開き、Development ステージのステータスが [Succeeded] に切り替わるのを待ちます。
Cloud Console で、[Kubernetes Engine] > [サービスと Ingress] の順に選択します。
azure-pipelines-cicd-dev クラスタの Ingress サービスを確認して、そのステータスが [OK] に切り替わるのを待ちます。これには数分かかることがあります。
同じ行の [エンドポイント] 列でリンクを開きます。ロードバランサが利用可能になるまで数分かかるため、最初はエラーが表示される場合があります。ページが開いたら、Music Store がデプロイ済みであり、カスタムタイトルが使用されていることを確認します。
Azure Pipelines で、[Prod] ステージの下にある [Approve] ボタンをクリックして、本番環境へのデプロイをプロモートします。

ボタンが表示されない場合は、まず以前のリリースを承認または却下する必要があります。
必要に応じてコメントを入力し、[承認] をクリックして確定します。
Prod 環境のステータスが [成功] に切り替わるのを待ちます。場合によっては、ブラウザのページを手動で更新する必要があります。
Cloud Console で、[サービス] ページを更新します。
azure-pipelines-cicd-prod クラスタの Ingress サービスを確認して、そのステータスが [OK] に切り替わるのを待ちます。これには数分かかることがあります。
同じ行の [エンドポイント] 列でリンクを開きます。ロードバランサが利用可能になるまで数分かかるため、この場合も最初はエラーが表示されることがあります。ページが開くと、この場合もカスタムタイトルが付いた Music Store アプリが表示されます。ただし、今回は本番環境クラスタで実行されます。

クリーンアップ

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

Azure Pipelines プロジェクトの削除

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

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

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

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

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

Cloud Console で [リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

Container Registry に対するアクセス制御を詳細に構成する。
Compute Engine に可用性の高い SQL Server グループをデプロイする方法を学習する。
Google Cloud Platform での .NET についての説明を確認する。
Cloud Tools for Visual Studio をインストールする。
Google Cloud のその他の機能を試す。チュートリアルをご覧ください。

Azure Pipelines と Google Kubernetes Engine を使用した CI / CD パイプラインの作成

目標

料金

始める前に

Azure DevOps プロジェクトの作成

継続的なビルド

デフォルトの分岐の設定

コードをビルドする

Visual Studio

コマンドライン

Docker イメージを公開する

イメージを公開するためのサービス アカウントを設定する

Azure Pipeline を Container Registry に接続する

Dockerfile の作成

Visual Studio

コマンドライン

Docker イメージをビルドするためのビルド定義を拡張する

Visual Studio

コマンドライン

継続的デプロイ

Kubernetes のデプロイを構成する

Visual Studio

コマンドライン

開発環境と本番環境を設定する

GKE クラスタを作成する

開発クラスタに Azure Pipeline を接続する

本番環境クラスタに Azure Pipeline を接続する

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

リリース定義を作成する

開発クラスタにデプロイする

本番環境クラスタにデプロイする

パイプラインを実行する

Visual Studio

コマンドライン

クリーンアップ

Azure Pipelines プロジェクトの削除

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

次のステップ

イメージを公開するためのサービスアカウントを設定する

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