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

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

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

次の一覧は、Kubernetes でホストされるマイクロサービスの CI/CD パイプラインの目標をまとめたものです。

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

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

前提条件

この例では、開発チームとコードベースに関するいくつかの前提条件を次に示します。

コードリポジトリは単一リポジトリであり、フォルダーがマイクロサービス別に整理されています。
チームのブランチ戦略は、トランクベース開発に基づいています。
チームは、リリースブランチを使用してリリースを管理します。マイクロサービスごとに個別のリリースが作成されます。
CI/CD プロセスでは、Azure Pipelines を使用して、マイクロサービスをビルド、テスト、および AKS にデプロイします。
すべてのマイクロサービスのコンテナーイメージは、1 つの共有Azure Container Registry インスタンスに格納され、マイクロサービスごとに個別のリポジトリが用意されています。 Container Registry Azure ABAC リポジトリのアクセス許可を使用して、各パイプライン ID のスコープを独自のリポジトリに設定するか、より強力な信頼境界が必要な場合は個別のレジストリを使用します。
チームは、Helm chart を使用して各マイクロサービスをパッケージ化します。
プッシュデプロイモデルが使用されます。Azure Pipelinesおよび関連付けられているエージェントは、AKS クラスターに直接接続してデプロイを実行します。

これらの想定によって、CI/CD パイプラインの特定の詳細の多くが設定されます。ただし、ここで説明する基本的なアプローチは、GitHub Actions、Jenkins、Docker Hubなど、他のプロセス、ツール、サービスに合わせて調整できます。

Alternatives

AKS で CI/CD 戦略を選択する場合は、次の一般的な代替手段を検討してください。

Helm をパッケージ管理およびデプロイツールとして使用する代わりに、 Kustomize (Kubernetes ネイティブ構成管理ツール) を使用して、アプリケーション構成をカスタマイズおよびパラメーター化するためのテンプレートなしの方法を導入できます。
Git リポジトリとパイプラインにAzure DevOpsを使用する代わりに、プライベート Git リポジトリとパブリック Git リポジトリにGitHub リポジトリを使用し、CI/CD パイプラインにGitHub Actionsできます。

GitHub Actionsは、AKS とスターターワークフローの統合を提供し、OpenID Connect (OIDC) をサポートして、Azureに対するセキュリティで保護されたシークレットレス認証を実現します。
プッシュデプロイモデルを使用する代わりに、 GitOps (プルデプロイモデル) を使用して Kubernetes 構成を大規模に管理することを検討してください。 Flux や Argo CD などのクラスター内 Kubernetes オペレーターは、Git リポジトリに格納されている構成に基づいてクラスターの状態を同期します。 GitOps を使用すると、パイプラインが直接クラスターにアクセスする必要がなくなり、攻撃対象領域が減少し、自己復旧機能とドリフト検出機能が提供されます。

Tip

プッシュベースのデプロイモデルとプルベース (GitOps) デプロイモデルを評価する場合は、ワークロードの要件を考慮してください。プッシュベースのデプロイでは、確定的な更新と直接パイプライン制御が提供されます。これは、安全なデプロイプラクティスに適しています。プルベース (GitOps) デプロイでは、整合性、監査可能性、自己復旧が提供されるため、クラスターがパイプラインからクラスターへの直接アクセスなしで目的の状態に対して調整する必要がある環境に最適です。

検証ビルド

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

機能ブランチワークフローの図。

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

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

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

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

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

コードをビルドする。
単体テストを実行する。
ソースコードで静的アプリケーションセキュリティテスト (SAST) を実行します。
ランタイムコンテナーイメージをビルドする。
イメージに対して脆弱性スキャンを実行する。

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

注

Azure DevOpsのサービスの 1 つであるAzure Reposでは、ブランチを保護するポリシーを定義できます。たとえば、ポリシーでは、メインにマージする前に、CI ビルドの成功と承認者からのサインオフが必要になる場合があります。

完全な CI/CD ビルド

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

ビルドパイプラインをトリガーするリリースブランチとリリースパイプラインを示す図。

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

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

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

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

モノレポでも、チームが個別にデプロイできるように、これらのタスクのスコープを個々のマイクロサービスに設定します。このプロセスには、PR の承認、リリースブランチの作成、運用クラスターへのデプロイの承認など、いくつかの手動手順が含まれています。ワークロードチームは、必要に応じてこれらの手順を自動化できます。

環境の分離

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

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

クラスター内で分離を強制するには、次の手順を実行します。

名前空間: Kubernetes 名前空間を使用して、環境 ( dev、 staging、 qaなど) を論理的に分離します。
ネットワークポリシー: Kubernetes ネットワークポリシーを適用して、名前空間間のポッド間通信を拒否します。
リソースクォータ: 名前空間ごとにリソースクォータを適用して、共有クラスターでノイズの多い近隣の問題を防ぎます。
Microsoft Entra ID統合: Microsoft Entra ID認証と Kubernetes RBAC とMicrosoft Entra IDを組み合わせて、各名前空間にアクセスできるMicrosoft Entraユーザーとグループを制御します。

認証と承認

マイクロサービスをデプロイするパイプラインと、それらのパイプラインがデプロイするワークロードの両方に、可能な限りシークレットレス認証を使用します。

パイプラインのワークロード ID フェデレーション: Azure Pipelinesの場合は、ワークロード ID フェデレーションサービス接続を使用して、有効期間の長いサービスプリンシパルシークレットを格納せずにAzureに対する認証を行います。 GitHub Actionsの場合は、同じシークレットレス認証を実現するように OIDC を構成します。
デプロイされたワークロードのMicrosoft Entra ワークロード ID : マニフェスト、Helm 値、または Kubernetes シークレットを介して資格情報を挿入するのではなく、Microsoft Entra ワークロード ID を使用するようにパイプラインがデプロイするマイクロサービスを構成します。ワークロード ID は Kubernetes サービスアカウントを Microsoft Entra ID とフェデレーションし、パイプラインでシークレットを管理することなく、ポッドがAzure サービス (Azure Key Vault、Container Registry、Azure SQL など) に対して認証できるようにします。

シークレットの管理

ソースコード、Dockerfile、Helm 値ファイル、またはパイプライン定義にシークレット (接続文字列、API キー、データベースパスワード) を直接埋め込むことはありません。その代わりに：

Key Vault にシークレットを格納します。
シークレットストア CSI ドライバーのKey Vault プロバイダーを使用して、ボリュームまたは環境変数としてポッドにシークレットを直接マウントします。この方法では、既定では暗号化されずに base64 でエンコードされた Kubernetes Secret オブジェクトからシークレットが保持されます。
パイプラインシークレットの場合は、Azure PipelinesまたはGitHub ActionsシークレットとのKey Vault統合を使用します。
論理的な削除と消去Key Vault保護を有効にして、偶発的または悪意のあるシークレットの削除から保護します。

Important

有効期間の長い資格情報 (クライアントシークレット、証明書、またはパスワード) は、パイプライン変数、環境変数、または Kubernetes シークレットに格納しないでください。代わりに、マネージド ID とフェデレーション資格情報を使用して、資格情報のローテーションの負担と攻撃対象領域を減らします。

ビルドプロセス

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

Docker でマルチステージビルドを使用すると、ビルド環境とランタイムイメージを 1 つの Dockerfile で定義できます。たとえば、次の Dockerfile は、.NET 10 アプリケーションをビルドします。

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base
USER app
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:10.0 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/build --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/publish

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

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

Important

.NET 8 以降、公式の Linux ベースの.NET コンテナーイメージには、appという非ルートユーザーが含まれています。 Dockerfile の USER app 命令は、最小特権の原則に従って、この非特権ユーザーとしてコンテナーを実行します。コンテナーイメージ ASP.NET Core、既定のリッスンポートも 80 から 8080 に変更されました。

テストランナーの構築

もう 1 つのおすすめできる方法は、コンテナー内で単体テストを実行することです。たとえば、次のコードは、テストランナーを構築する Dockerfile の一部を示しています。

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"]

開発者は、次の Dockerfile を使用してテストをローカルで実行できます。

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 ではなく、特定のバージョンタグを常にデプロイしてください。
Container Registry の名前空間を使用して、運用環境で承認されたイメージを、まだテスト中のイメージから分離します。運用環境にデプロイする準備ができるまで、イメージを運用名前空間に移動しないでください。このプラクティスとコンテナーイメージのセマンティックバージョン管理を組み合わせると、リリースが承認されていないバージョンを誤ってデプロイする可能性が低くなります。
コンテナーを特権のないユーザーとして実行して、最小特権の原則に従います。 Kubernetes では、ポッドセキュリティ標準とポッドセキュリティアドミッション (Kubernetes 1.25 の非推奨のポッドセキュリティポリシーに代わる) を使用して、コンテナーがルートとして実行されないようにするなどの制限を適用します。運用環境のワークロードには、 restricted プロファイルを使用します。
コンテナーイメージの攻撃対象領域を減らすには、最小限またはディストリビューションレスの基本イメージ (Alpine ベースのイメージ、linux ベースイメージまたはディストリビューションレスイメージAzure、.NETイメージなど) を使用します。
Premium レジストリの場合は、タグ付けされていないマニフェストを削除するように Container Registry アイテム保持ポリシーを構成します。タグを年齢または名前で消去するには、 acr purge を実行する Container Registry タスクをスケジュールします。アクティブなデプロイとロールバック計画が参照するイメージを保持します。

Helm チャート

Helm を使用してサービスの構築やデプロイを管理することを考慮してください。次の Helm 機能は、CI/CD パイプラインをサポートしています。

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

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

1 つのマイクロサービスに複数の Kubernetes 構成ファイルが必要な場合があります。サービスを更新するには、セレクター、ラベル、およびイメージタグを更新するために、これらのファイルをすべて編集する必要がある場合があります。 Helm は、これらのファイルを グラフ と呼ばれる 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:
  template:
    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 <release-name> oci://<registry>/<repository>/<package-chart-name> --version <desiredVersion> \
     --set image.tag=0.1.0 \
     --set image.repository=package \
     --set dockerregistry=$ACR_SERVER \
     --namespace backend

CI/CD パイプラインでは、Kubernetes にグラフを直接インストールできますが、グラフアーカイブ (.tgz ファイル) を作成し、コンテナーレジストリなどの Helm リポジトリにグラフをプッシュします。詳細については、「 Helm チャートのパッケージ化とデプロイ (HelmDeploy タスク)」を参照してください。

改訂

Helm グラフには、セマンティックバージョン管理を使用する必要があるバージョン番号が常に含まれます。チャートにはappVersionを追加することもできます。このフィールドは省略可能であり、グラフのバージョンに関連付ける必要はありません。一部のチームでは、グラフの更新とは別にアプリケーションのバージョン管理を行う必要がある場合があります。より簡単な方法は、1 つのバージョン番号を使用することです。そのため、グラフのバージョンとアプリケーションのバージョンの間には 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 コマンドを使用して、各リビジョンの変更原因フィールドを表示できます。前の例では、変更原因は Helm チャートパラメーターとして提供されています。

kubectl rollout history deployments/delivery-v010 -n backend

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

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

helm list -n backend

NAME              NAMESPACE   REVISION    UPDATED                                 STATUS      CHART               APP VERSION
delivery-v0.1.0   backend     1           2024-04-07 00:25:30.000000 +0000 UTC    deployed    delivery-v0.1.0     v0.1.0

Azure Pipelines

Azure Pipelines、Azure DevOpsのサービスには、ビルドパイプラインとリリースパイプラインという 2 種類のパイプラインがあります。ビルドパイプラインでは、CI プロセスが実行され、ビルド成果物が作成されます。 Kubernetes 上のマイクロサービスアーキテクチャの場合、これらの成果物は、各マイクロサービスを定義するコンテナーイメージと Helm chart です。リリースパイプラインは、マイクロサービスをクラスターにデプロイする CD プロセスを実行します。

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

Docker タスクを使用してテストランナーコンテナーをビルドします。
Docker タスクを使用して、テストランナーコンテナーに対してdocker runを呼び出してテストを実行します。
PublishTestResults タスクを使用してテスト結果を発行します。詳細については、「イメージのビルド」を参照してください。
ソースコードで SAST を実行します。
ローカル docker build と Docker タスクを使用するか、Container Registry ビルドと AzureCLI タスクを使用して、ランタイムコンテナーをビルドします。たとえば、Microsoft SBOM ツールを使用して、イメージのソフトウェア部品表 (SBOM) を生成し、イメージダイジェストに関連付けられたパイプライン成果物として発行するか、Container Registry のイメージにアタッチします。
コンテナーイメージの脆弱性スキャン (たとえば、コンテナーのMicrosoft Defenderや Trivy などのMicrosoft以外のツールを使用して) を実行して、イメージが公開される前に既知の脆弱性を検出します。
DockerまたはAzureCLI タスクを使用して、コンテナーイメージを Container Registry (または別のコンテナーレジストリ) にプッシュします。
変更できないダイジェストによってプッシュされたイメージに署名し、その整合性と信頼性を確保します。 Azure Pipelinesについては、表記署名のガイダンスに従ってください。
HelmDeploy タスクを使用して Helm チャートをパッケージ化します。
HelmDeploy タスクを使用して、Helm パッケージを Container Registry (または別の Helm リポジトリ) にプッシュします。

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

Helm チャートを開発/QA/ステージングの環境にデプロイします。 helm upgrade コマンドを --install フラグと共に使用して、最初のインストール以降のアップグレードをサポートできます。
承認者がデプロイを承認または却下するのを待機する。
リリース用にコンテナーイメージにタグを付け直します。
リリースタグをコンテナーレジストリにプッシュする。
運用環境クラスターに Helm chart をデプロイする。 ratify とAzure Policyを使用して、受付中にイメージ署名を検証し、イメージを信頼されたレジストリに制限するように許可イメージポリシーを個別に構成します。

注

個別のイメージプルシークレットを使用せずに AKS が Container Registry からイメージをプルできるようにするには、レジストリ全体の RBAC を使用するレジストリに対して AKS 間のContainer-Registry 統合を使用します。 ABAC 対応レジストリの場合、この統合はサポートされていません。代わりに、クラスターの kubelet マネージド ID に Container Registry Repository Reader ロールを割り当てます。

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

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

代替GitHub Actions

チームがソース管理にGitHubを使用している場合、GitHub Actionsは同等の CI/CD プラットフォームを提供します。前に説明したスターターワークフローと OIDC 認証に加えて、AKS を対象とする場合は、次のGitHub固有の機能を検討してください。

環境と保護規則。 GitHubプランとリポジトリの可視性でサポートされている場合は、必要なレビュー担当者、待機タイマー、デプロイブランチを含むGitHub環境を使用して承認ゲートを実装します。
コンテナーのスキャン。 Trivy 、Microsoft Defender for DevOps、または同様のツールに対して、GitHub Actionsマーケットプレースアクションを使用して、ワークフロー内でコンテナーイメージを直接スキャンします。

可観測性と監視

CI/CD パイプラインとランタイム環境全体で可観測性を実装します。

パイプラインの監視。 ビルド期間、テスト合格率、デプロイ頻度、および失敗率を追跡します。 Azure DevOpsでは、組み込みの分析が提供されます。 GitHub Actionsは、Microsoft以外のダッシュボードを使用できます。
ランタイムの監視。 Prometheus と Azure Managed Grafana Azure Monitorマネージドサービスを使用して、AKS クラスターの正常性とワークロードのメトリックを監視します。
アプリケーションテレメトリ。 分散トレース、要求ログ、依存関係の追跡のために、Azure Monitor Application Insights を使用してマイクロサービスをインストルメント化します。
アラート。 デプロイエラー、ポッドの再起動、高いエラー率、リソースの飽和に関するアラートを構成して、迅速なインシデント対応を可能にします。

Well-Architected Framework の配置

Kubernetes 上のマイクロサービス用に CI/CD パイプラインを設計する場合は、Azure Well-Architected Framework の柱を考慮してください。

柱	Considerations
信頼性	自動ロールバック戦略、デプロイに関する正常性プローブ、ブルーグリーンまたはカナリアリリース戦略、ポッドの中断予算。
Security	シークレットレス認証 (ワークロード ID、OIDC)、イメージ署名、サプライチェーンセキュリティ、最小特権 RBAC、ネットワークポリシー。
コストの最適化	ビルドエージェントの適切なサイズ設定、エフェメラルセルフホステッドランナーの使用、Container Registry イメージの保持ポリシーの実装、中断に耐え得る非運用ワークロードに対してのみスポットノードプールの使用。
オペレーショナルエクセレンス	宣言型デプロイ用の GitOps、コードとしてのインフラストラクチャ、コードとしてのパイプライン (YAML)、可観測性、Runbook の自動化。
パフォーマンス効率	並列パイプラインステージ、ビルドキャッシュ (Docker レイヤーキャッシュ、依存関係キャッシュ)、ポッドの水平自動スケーリング。

貢献者達

Microsoft では、この記事を保持しています。この記事を書いたのは、以下の寄稿者です。

主要著者:

Ray Kao |プリンシパルソリューションエンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-13