Azure DevOps と Helm を使用した Kubernetes 上のマイクロサービス用 CI/CD パイプラインの構築

Azure Kubernetes Service (AKS)

Azure Container Registry

Azure DevOps

マイクロサービスアーキテクチャ対して信頼性の高い継続的インテグレーションと継続的デリバリープロセス (CI/CD) を作成することは、困難な場合があります。個々のチームは、他のチームを妨害したり、アプリケーション全体を不安定にしたりすることなく、サービスを迅速かつ確実にリリースできる必要があります。

この記事では、Azure Kubernetes Service (AKS) にマイクロサービスをデプロイするための CI/CD パイプラインの例を説明します。すべてのチームやプロジェクトはそれぞれ異なるので、この記事を一連の厳格な規則としては考えないでください。その代わり、独自の CI/CD プロセスを設計するための出発点になります。

Kubernetes ホスト型マイクロサービスの CI/CD パイプラインの目標は、次のようにまとめることができます。

チームは、サービスを個別に構築およびデプロイすることができます。
CI プロセスに合格したコード変更は、運用環境に似た環境に自動的にデプロイされます。
品質ゲートは、パイプラインの各段階で適用されます。
サービスの新しいバージョンは、以前のバージョンと並行してデプロイできます。

背景の詳細については、マイクロサービスアーキテクチャの CI/CD に関するページを参照してください。

前提条件

この例の目的として、開発チームとコードベースに関するいくつかの想定を次に示します。

コードリポジトリは単一リポジトリであり、フォルダーがマイクロサービス別に整理されています。
チームのブランチ戦略は、トランクベース開発に基づいています。
チームは、リリースブランチを使用してリリースを管理します。マイクロサービスごとに個別のリリースが作成されます。
CI/CD プロセスでは、Azure Pipelines を使用してマイクロサービスの AKS への構築、テスト、デプロイが行われます。
各マイクロサービスのコンテナーイメージは、Azure Container Registryに格納されます。
チームは、Helm chart を使用して各マイクロサービスをパッケージ化します。
プッシュデプロイモデルを使用します。このモデルでは、Azure Pipelines および関連するエージェントは、AKS クラスターに直接接続することでデプロイを実行します。

これらの想定によって、CI/CD パイプラインの特定の詳細の多くが設定されます。ただし、ここで説明する基本的な手法は、Jenkins や Docker Hub など、他のプロセス、ツール、サービスにも適用されます。

代替

次に、Azure Kubernetes Service を使用して CI/CD 戦略を選択する際に、お客様が使用する一般的な代替手段を示します。

パッケージ管理およびデプロイツールとして Helm を使用する代わりとしての Kustomize は、Kubernetes ネイティブの構成管理ツールであり、アプリケーション構成をカスタマイズおよびパラメーター化するためのテンプレートが不要の方法を導入しています。
Git リポジトリとパイプラインに Azure DevOps を使用する代わりとしての GitHub リポジトリは、プライベートおよびパブリックの Git リポジトリに使用できます。また、GitHub Actions は、CI/CD パイプラインに使用できます。
プッシュデプロイモデルを使用する代わりとしての大規模な Kubernetes 構成の管理は、GitOps (プルデプロイモデル) を使用して実行できます。このモデルでは、クラスター内の Kubernetes オペレーターが、Git リポジトリに格納されている構成に基づいてクラスターの状態を同期します。

検証ビルド

開発者は Delivery Service と呼ばれるマイクロサービスに取り組んでいるとします。新機能の開発中に、開発者は、機能ブランチにコードをチェックインします。慣例により、機能ブランチは feature/* と名付けられます。

CI/CD ワークフロー

ビルド定義ファイルには、次のように、ブランチ名とソースパスでフィルター処理するトリガーが含まれます。

trigger:
  batch: true
  branches:
    include:
    # for new release to production: release flow strategy
    - release/delivery/v*
    - refs/release/delivery/v*
    - master
    - feature/delivery/*
    - topic/delivery/*
  paths:
    include:
    - /src/shipping/delivery/

このアプローチを使用して、各チームは、専用のビルドパイプラインを持つことができます。 /src/shipping/delivery フォルダーにチェックインされているコードのみによって、Delivery Service のビルドがトリガーされます。フィルターに一致するブランチにコミットをプッシュすると、CI のビルドがトリガーされます。ワークフローのこの時点で、CI ビルドでは、いくつかの最小限のコードの検証が実行されます。

コードをビルドする。
単体テストを実行する。

ビルド時間を短くして、開発者がすばやくフィードバックを取得できるようにすることが目標です。開発者は、機能をマスターにマージする準備ができたら、PR を開きます。この操作は、いくつかの追加のチェックを実行する別の CI ビルドをトリガーします。

コードをビルドする。
単体テストを実行する。
ランタイムコンテナーイメージをビルドする。
イメージに対して脆弱性スキャンを実行する。

ビルドパイプラインの ci-delivery-full を示す図。

注意

Azure DevOps Repos では、ブランチを保護するためのポリシーを定義できます。たとえば、マスターにマージするには、CI ビルドの成功に加え、承認者のサインオフが必要であることをポリシーで要求できます。

完全な CI/CD ビルド

ある時点で、チームは、この Delivery サービスの新しいバージョンをデプロイする準備が整います。リリースマネージャーで、release/<microservice name>/<semver> という名前付けパターンを使用して、メインブランチからブランチを作成します。たとえば、「 release/delivery/v1.0.2 」のように入力します。

ビルドパイプラインの ci-delivery-full とリリースパイプラインの cd-delivery を示す図。

このブランチを作成すると、これまでのすべての手順に加え、以下を実行する完全な CI ビルドがトリガーされます。

Azure Container Registry にコンテナーイメージをプッシュする。イメージには、ブランチ名から取得されたバージョン番号がタグ付けされます。
helm package を実行して、サービス用の Helm chart をパッケージ化する。この chart にもバージョン番号がタグ付けされます。
Helm パッケージを Container Registry にプッシュする。

このビルドが成功したと仮定すると、Azure Pipelines のリリースパイプラインを使用するデプロイ (CD) プロセスがトリガーされます。パイプラインには次の手順が含まれています。

Helm chart を QA 環境にデプロイする。
パッケージが運用環境に移動される前に、承認者がサインオフする。「Release deployment control using approvals (承認を使用したリリースデプロイ制御)」をご覧ください。
Docker イメージに Azure Container Registry 内の運用名前空間のタグを付け直す。たとえば、現在のタグが myrepo.azurecr.io/delivery:v1.0.2 の場合、運用タグは myrepo.azurecr.io/prod/delivery:v1.0.2 になります。
Helm chart を運用環境にデプロイする。

単一リポジトリであっても、これらのタスクのスコープを個々のマイクロサービスに設定できるため、チームは短時間でデプロイすることができます。プロセスには、いくつか手動の手順があります。PR の承認、リリースブランチの作成、および運用クラスターへのデプロイの承認です。これらの手順は手動で行います。組織が望むのであれば、完全に自動化することもできます。

環境の分離

開発、スモークテスト、統合テスト、ロードテスト、最後に運用のための環境を含め、サービスをデプロイするための複数の環境が存在します。これらの環境には、あるレベルの分離が必要です。 Kubernetes では、物理的な分離と論理的な分離のどちらかを選択できます。物理的な分離は、個別のクラスターにデプロイすることを示します。論理的な分離では、先に説明したように、名前空間とポリシーを使用します。

開発/テスト環境のための個別のクラスターと共に、専用の運用クラスターを作成することをお勧めします。開発/テストクラスター内の環境を分離するには、論理的な分離を使用します。開発/テストクラスターにデプロイされたサービスには、ビジネスデータを保持するデータストアへのアクセス権を与えるべきではありません。

ビルドプロセス

可能であれば、ご自分のビルドプロセスを Docker コンテナーにパッケージ化します。この構成により、Docker を使用してご自分のコード成果物をビルドすることができ、各ビルドコンピューター上でビルド環境を構成する必要がなくなります。ビルドプロセスのコンテナー化により、新しいビルドエージェントを追加して CI パイプラインをスケールアウトすることが容易になります。また、チームの開発者はビルドコンテナーを実行するだけで、コードをビルドできます。

Docker 内でマルチステージビルドを使用すると、単一の Dockerfile 内にビルド環境とランタイムイメージを定義することができます。例として、.NET アプリケーションをビルドする Dockerfile を次に示します。

FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src/Fabrikam.Workflow.Service

COPY Fabrikam.Workflow.Service/Fabrikam.Workflow.Service.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.csproj

COPY Fabrikam.Workflow.Service/. .
RUN dotnet build Fabrikam.Workflow.Service.csproj -c release -o /app --no-restore

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM build AS publish
RUN dotnet publish Fabrikam.Workflow.Service.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Fabrikam.Workflow.Service.dll"]

この Dockerfile では、いくつかのビルドステージが定義されます。 base という名前のステージでは .NET ランタイムが使用されていますが、build という名前のステージでは完全な .NET SDK が使用されていることに注目してください。 build ステージは、.NET プロジェクトをビルドするために使用されます。しかし、最終的なランタイムコンテナーは base から作成されます。これは、ランタイムしか含まないので、完全な SDK イメージよりかなり小さくなっています。

テストランナーのビルド

もう 1 つのおすすめできる方法は、コンテナー内で単体テストを実行することです。たとえば、次に示すのは、テストランナーをビルドする Docker ファイルの一部です。

FROM build AS testrunner
WORKDIR /src/tests

COPY Fabrikam.Workflow.Service.Tests/*.csproj .
RUN dotnet restore Fabrikam.Workflow.Service.Tests.csproj

COPY Fabrikam.Workflow.Service.Tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

開発者は、この Docker ファイルを使用することで、テストをローカルで実行することができます。

docker build . -t delivery-test:1 --target=testrunner
docker run delivery-test:1

また、CI パイプラインでは、ビルド検証手順の一環としてテストが実行される必要があります。

このファイルでは Docker の RUN コマンドではなく、Docker の ENTRYPOINT コマンドが使用されていることに注目してください。

RUN コマンドを使用した場合は、イメージをビルドするたびにテストが実行されます。 ENTRYPOINT を使用することにより、テストはオプトインになります。 testrunner ステージを明示的にターゲットとした場合に限り、テストが実行されます。
テストの失敗により、Docker の build コマンドが失敗することはありません。このようにして、コンテナービルドの失敗をテストの失敗と区別することができます。
テストの結果は、マウントされたボリュームに保存できます。

コンテナーのベストプラクティス

コンテナーについて考慮すべきその他のベストプラクティスを次に示します。

クラスター (ポッドやサービスなど) にデプロイされるリソースのコンテナータグ、バージョン管理、および名前付けに関する組織規模の規則を定義します。これにより、デプロイに関する問題が診断しやすくなります。
開発とテストのサイクル中、CI/CD 処理は、多数のコンテナーイメージをビルドします。それらのイメージの一部のみがリリース候補になり、さらにそれらのリリース候補の一部のみが運用環境に昇格されます。明確なバージョン管理戦略を用意してください。それによって、どのバージョンが現在運用環境にデプロイされているかを把握し、必要な場合に前のバージョンにロールバックすることができます。
latest ではなく、特定のバージョンタグを常にデプロイしてください。
Azure Container Registry 内の名前空間を使用して、運用するために承認されたイメージを、まだテスト中であるイメージから分離します。運用環境にデプロイする準備ができるまで、イメージを運用名前空間に移動しないでください。このプラクティスとコンテナーイメージのセマンティックなバージョン管理を組み合わせると、リリースを承認されていないバージョンが誤ってデプロイされる可能性を低くすることができます。
コンテナーを特権のないユーザーとして実行して、最小特権の原則に従います。 Kubernetes では、コンテナーが "ルート" として実行されないように、ポッドセキュリティポリシーを作成することができます。

Helm チャート

Helm を使用してサービスの構築やデプロイを管理することを考慮してください。 CI/CD に役立つ Helm の機能のいくつかを次に示します。

多くの場合、単一のマイクロサービスは、複数の Kubernetes オブジェクトによって定義されます。 Helm を使用すると、これらのオブジェクトを 1 つの Helm chart にパッケージ化できます。
一連の kubectl コマンドではなく、1 つの Helm コマンドを使用して chart をデプロイできます。
グラフは明示的にバージョン管理されます。 Helm を使用して、バージョンのリリース、リリースの表示、および以前のバージョンへのロールバックを行います。以前のバージョンにロールバックする機能と共にセマンティックバージョニングを使用して、更新プログラムやリビジョンを追跡します。
Helm chart では、多数のファイルにわたる情報の複製 (ラベルやセレクターなど) を回避するためにテンプレートが使用されます。
Helm では、chart 間の依存関係を管理できます。
chart を Helm リポジトリ (Azure Container Registry など) に格納して、ビルドパイプラインに統合することができます。

Helm リポジトリとしての Container Registry の使用の詳細については、「アプリケーションのグラフに Helm リポジトリとして Azure Container Registry を使用する」を参照してください。

1 つのマイクロサービスに、複数の Kubernetes 構成ファイルが必要となる場合があります。サービスの更新は、セレクター、ラベル、およびイメージのタグを更新するためにこれらのファイルに手を加えることを意味する場合があります。 Helm では、これらが chart と呼ばれる 1 つのパッケージとして扱われ、変数を使用することで YAML ファイルを簡単に更新することができます。 Helm では、パラメーター化された YAML 構成ファイルを記述できるようにするために、(Go テンプレートに基づく) テンプレート言語が使用されます。

たとえば、デプロイを定義する YAML ファイルの一部を次に示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "package.fullname" . | replace "." "" }}
  labels:
    app.kubernetes.io/name: {{ include "package.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

...

  spec:
      containers:
      - name: &package-container_name fabrikam-package
        image: {{ .Values.dockerregistry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
        - name: LOG_LEVEL
          value: {{ .Values.log.level }}

デプロイ名、ラベル、およびコンテナー仕様のすべてで、テンプレートパラメーターが使用されていることがわかります。これらはデプロイ時に指定されます。たとえば、コマンドラインから次を実行します。

helm install $HELM_CHARTS/package/ \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend \
     --name package-v0.1.0

ご利用の CI/CD パイプラインで、直接、Kubernetes に chart をインストール可能であるとしても、chart アーカイブ (.tgz ファイル) を作成して、chart を Azure Container Registry などの Helm リポジトリにプッシュすることをお勧めします。詳細については、「Package Docker-based apps in Helm charts in Azure Pipelines」 (Azure パイプライン内で Docker ベースのアプリを Helm charts にパッケージ化する) を参照してください。

リビジョン

Helm chart には常にバージョン番号が用意されます。これにはセマンティックバージョニングが使用される必要があります。 chart には appVersion も用意されます。このフィールドはオプションであり、chart バージョンに関連付ける必要はありません。チームによっては、chart に対する更新プログラムとは別にアプリケーションバージョンを必要とする場合があります。しかし、よりシンプルな方法は、1 つのバージョン番号を使用することです。結果、chart バージョンとアプリケーションバージョンの間の関係は 1:1 になります。そうすれば、リリースごとに 1 つの chart を格納して、必要なリリースを簡単にデプロイすることができます。

helm install <package-chart-name> --version <desiredVersion>

もう 1 つ、次のようにデプロイテンプレート内に change-cause 注釈を指定することをお勧めします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "delivery.fullname" . | replace "." "" }}
  labels:
     ...
  annotations:
    kubernetes.io/change-cause: {{ .Values.reason }}

これにより、kubectl rollout history コマンドを使用して、リビジョンごとに change-cause フィールドを表示することができます。前の例では、change-cause は Helm chart のパラメーターとして指定されました。

kubectl rollout history deployments/delivery-v010 -n backend

deployment.extensions/delivery-v010
REVISION  CHANGE-CAUSE
1         Initial deployment

helm list コマンドを使用して、次のようにリビジョン履歴を表示することもできます。

helm list

NAME            REVISION    UPDATED                     STATUS        CHART            APP VERSION     NAMESPACE
delivery-v0.1.0 1           Sun Apr  7 00:25:30 2020    DEPLOYED      delivery-v0.1.0  v0.1.0          backend

Azure DevOps パイプライン

Azure Pipeline では、パイプラインはビルドパイプラインとリリースパイプラインに分割されます。ビルドパイプラインでは、CI プロセスが実行され、ビルド成果物が作成されます。 Kubernetes 上のマイクロサービスアーキテクチャの場合、これらの成果物は、各マイクロサービスを定義するコンテナーイメージと Helm chart です。リリースパイプラインでは、その CD プロセスが実行され、それによってマイクロサービスがクラスターにデプロイされます。

この記事で前述した CI フローに基づいて、ビルドパイプラインは次のタスクで構成される可能性があります。

Docker タスクを使用してテストランナーコンテナーをビルドします。
テストランナーコンテナーに対して docker run を呼び出すことによって、テストを実行します。これにより、 Docker タスクが使用されます。
PublishTestResults タスクを使用してテスト結果を発行します。「イメージのビルド」を参照してください。
ローカル Docker ビルドと Docker タスクを使用するか、Azure Container Registry ビルドと AzureCLI タスクを使用してランタイムコンテナーをビルドします。
DockerまたはAzureCLIタスクを使用して、コンテナーイメージを Azure Container Registry (または他のコンテナーレジストリ) にプッシュします。
HelmDeploy タスクを使用して Helm チャートをパッケージ化します。
HelmDeploy タスクを使用して、Helm パッケージを Azure Container Registry (またはその他の Helm リポジトリ) にプッシュします。

CI パイプラインからの出力は、実稼働可能なコンテナーイメージと、マイクロサービスの更新された Helm chart です。この時点では、リリースパイプラインに引き継ぐことができます。マイクロサービスごとに固有のリリースパイプラインが存在するようになります。リリースパイプラインは、成果物を発行した CI パイプラインにトリガーソースが設定されるように構成します。このパイプラインを使用すると、マイクロサービスごとに独立したデプロイを作成できます。リリースパイプラインは、次のステップを実行します。

Helm チャートを開発/QA/ステージングの環境にデプロイします。 helm upgrade コマンドは、最初のインストールとその後のアップグレードをサポートする --install フラグと共に使用できます。
承認者がデプロイを承認または却下するのを待機する。
コンテナーイメージにリリースのためのタグを付け直す
リリースタグをコンテナーレジストリにプッシュする。
運用環境クラスターに Helm chart をデプロイする。

リリースパイプラインの作成の詳細については、「Release pipelines, draft releases, and release options」 (リリースパイプライン、ドラフトリリース、およびリリースオプション) を参照してください。

次の図に、この記事で説明したエンドツーエンドの CI/CD プロセスを示します。

CD/CD パイプライン

次の方法で共有

Azure DevOps と Helm を使用した Kubernetes 上のマイクロサービス用 CI/CD パイプラインの構築

前提条件

代替

検証ビルド

完全な CI/CD ビルド

環境の分離

ビルドプロセス

テストランナーのビルド

コンテナーのベストプラクティス

Helm チャート

リビジョン

Azure DevOps パイプライン

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure DevOps と Helm を使用した Kubernetes 上のマイクロサービス用 CI/CD パイプラインの構築

前提条件

代替

検証ビルド

完全な CI/CD ビルド

環境の分離

ビルド プロセス

テスト ランナーのビルド

コンテナーのベスト プラクティス

Helm チャート

リビジョン

Azure DevOps パイプライン

次のステップ

関連リソース

フィードバック

その他のリソース

ビルドプロセス

テストランナーのビルド

コンテナーのベストプラクティス