チュートリアル: Azure Arc 対応 Kubernetes クラスターを使用して GitOps で CI/CD を実装する

[アーティクル]
05/08/2023

重要

このチュートリアルでは、Flux v1 による GitOps を使用します。 Azure Arc 対応 Kubernetes と Azure Kubernetes Service (AKS) クラスターに対して、Flux v2 による GitOps を使用できるようになりました。Flux v2 による GitOps の使用に関するチュートリアルに進んでください。できるだけ早く Flux v2 に移行することをお勧めします。

2024 年 1 月 1 日より前に作成された Flux v1 ベースのクラスター構成リソースのサポートは、2025 年 5 月 24 日に終了します。 2024 年 1 月 1 日から、新しい Flux v1 ベースのクラスター構成リソースを作成することはできません。

このチュートリアルでは、Azure Arc 対応 Kubernetes クラスターで GitOps を使用して CI/CD ソリューションを設定します。サンプルの Azure Vote アプリを使用して、次のことを行います。

Azure Arc 対応 Kubernetes クラスターを作成する。
アプリケーションおよび GitOps リポジトリを Azure Repos に接続する。
CI/CD パイプラインをインポートする。
Azure Container Registry (ACR) を Azure DevOps および Kubernetes に接続する。
環境変数グループを作成する。
dev および stage 環境をデプロイする。
アプリケーション環境をテストする。

Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。

Azure Cloud Shell

Azure では、ブラウザーを介して使用できる対話型のシェル環境、Azure Cloud Shell がホストされています。 Cloud Shell で Bash または PowerShell を使用して、Azure サービスを操作できます。ローカル環境に何もインストールしなくても、Cloud Shell にプレインストールされているコマンドを使用して、この記事のコードを実行できます。

Azure Cloud Shell を開始するには、以下のようにします。

オプション	例とリンク
コードまたはコマンドブロックの右上隅にある [使ってみる] を選択します。 [使ってみる] を選択しても、コードまたはコマンドは Cloud Shell に自動的にはコピーされません。
https://shell.azure.com に移動するか、[Cloud Shell を起動する] ボタンを選択して、ブラウザーで Cloud Shell を開きます。
Azure portal の右上にあるメニューバーの [Cloud Shell] ボタンを選択します。

Azure Cloud Shell を使用するには、以下のようにします。

Cloud Shell を開始します。
コードブロック (またはコマンドブロック) の [コピー] ボタンを選択し、コードまたはコマンドをコピーします。
Windows と Linux では Ctrl+Shift+V キーを選択し、macOS では Cmd+Shift+V キーを選択して、コードまたはコマンドを Cloud Shell セッションに貼り付けます。
Enter キーを選択して、コードまたはコマンドを実行します。

開始する前に

このチュートリアルでは、Azure DevOps、Azure Repos および Pipelines、Azure CLI について理解していることを前提としています。

Azure DevOps Services にサインインします。
前のチュートリアルを完了し、CI/CD 環境用に GitOps をデプロイする方法を学習します。
この機能の利点とアーキテクチャについて理解します。
以下が用意されていることを確認します。
- arc-cicd-cluster という名前の接続済みの Azure Arc 対応 Kubernetes クラスター。
- AKS 統合または非 AKS クラスター認証を使用して接続された Azure Container Registry (ACR)。
- Azure Repos および Azure Pipelines に対する "ビルド管理者" および "プロジェクト管理者" アクセス許可。
次の Azure Arc 対応 Kubernetes CLI 拡張機能 (バージョン 1.0.0 以上) をインストールします。
```
az extension add --name connectedk8s
az extension add --name k8s-configuration
```
- これらの拡張機能を最新バージョンに更新するには、次のコマンドを実行します。
```
az extension update --name connectedk8s
az extension update --name k8s-configuration
```

アプリケーションおよび GitOps リポジトリを Azure Repos にインポートする

アプリケーションリポジトリと GitOps リポジトリを Azure Repos にインポートします。このチュートリアルでは、次のサンプルリポジトリを使用します。

arc-cicd-demo-src アプリケーションリポジトリ
- URL: https://github.com/Azure/arc-cicd-demo-src
- GitOps を使用してデプロイするサンプルの Azure Vote アプリが含まれています。
arc-cicd-demo-gitops GitOps リポジトリ
- URL: https://github.com/Azure/arc-cicd-demo-gitops
- Azure Vote アプリを格納するクラスターリソースのベースとして機能します。

Git リポジトリのインポートの詳細を確認してください。

Note

アプリケーションリポジトリと GitOps リポジトリ用に 2 つの異なるリポジトリをインポートして使用すると、セキュリティとシンプルさを向上させることができます。アプリケーションおよび GitOps リポジトリのアクセス許可と可視性は、個別に調整できます。たとえば、クラスター管理者は、クラスターの望ましい状態に関連する変更をアプリケーションコードで検出できない場合があります。逆に、アプリケーション開発者は、各環境の固有のパラメーターを把握する必要がありません。そのパラメーターを網羅する一連のテスト値で十分な場合があります。

GitOps リポジトリを接続する

アプリを継続的にデプロイするには、GitOps を使用してアプリケーションリポジトリをクラスターに接続します。 arc-cicd-demo-gitops GitOps リポジトリには、arc-cicd-cluster クラスターでアプリを稼働させるための基本的なリソースが含まれています。

最初の GitOps リポジトリには、デプロイ環境に対応する dev および stage 名前空間を作成するマニフェストのみが含まれています。

作成した GitOps 接続により、自動的に以下のことが行われます。

マニフェストディレクトリ内でマニフェストを同期します。
クラスターの状態を更新します。

この CI/CD ワークフローでは、アプリをデプロイするための追加のマニフェストがマニフェストディレクトリに取り込まれます。

Azure Repos で、新しくインポートした arc-cicd-demo-gitops リポジトリに対する新しい GitOps 接続を作成します。

az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

Flux ではベースパスとして arc-cicd-cluster/manifests ディレクトリ "のみ" が使用されることを確認します。このパスは、次の operator パラメーターを使用して定義します。

--git-path=arc-cicd-cluster/manifests

Note

HTTPS 接続文字列を使用していて、接続の問題が発生した場合は、URL でユーザー名のプレフィックスを省略してください。たとえば、https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops では、alice@ を削除してください。その代わり、--https-user ではユーザーを指定します (例: --https-user alice)。
Azure portal でデプロイの状態を確認します。
- 成功した場合は、dev と stage 両方の名前空間がクラスター内に作成されます。

CI/CD パイプラインをインポートする

GitOps 接続の同期が完了したので、マニフェストを作成する CI/CD パイプラインをインポートする必要があります。

このアプリケーションリポジトリには、PR、CI、CD に使用するパイプラインを含む .pipeline フォルダーが含まれています。サンプルリポジトリで提供されている 3 つのパイプラインをインポートし、名前を変更します。

パイプラインファイルの名前	説明
`.pipelines/az-vote-pr-pipeline.yaml`	arc-cicd-demo-src PR という名前のアプリケーション PR パイプライン
`.pipelines/az-vote-ci-pipeline.yaml`	arc-cicd-demo-src CI という名前のアプリケーション CI パイプライン
`.pipelines/az-vote-cd-pipeline.yaml`	arc-cicd-demo-src CD という名前のアプリケーション CD パイプライン

ACR を接続する

Docker イメージを格納および取得するために、パイプラインとクラスターの両方で ACR を利用します。

ACR を Azure DevOps に接続する

CI プロセスの間、アプリケーションコンテナーをレジストリにデプロイします。まず、Azure サービス接続を作成します。

Azure DevOps では、プロジェクト設定ページから [サービス接続] ページを開きます。 TFS では、上部のメニューバーの設定アイコンから [サービス] ページを開きます。
[+ 新しいサービス接続] を選択し、必要なサービス接続の種類を選択します。
そのサービス接続のパラメーターを入力します。このチュートリアルでは、次を使用します。
- サービス接続に arc-demo-acr という名前を付けます。
- リソースグループとして myResourceGroup を選択します。
[すべてのパイプラインへのアクセス許可を与える] を選択します。
- このオプションにより、サービス接続に対して YAML パイプラインファイルが承認されます。
[OK] を選択して接続を作成します。

ACR を Kubernetes に接続する

Kubernetes クラスターが ACR からイメージをプルできるようにします。非公開の場合は、認証が必要になります。

ACR を既存の AKS クラスターに接続する

次のコマンドを使用して、既存の ACR と既存の AKS クラスターを統合します。

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

イメージのプルシークレットを作成する

非 AKS およびローカルクラスターを ACR に接続するには、イメージのプルシークレットを作成します。 Kubernetes では、イメージのプルシークレットを使用して、レジストリの認証に必要な情報を格納します。

次の kubectl コマンドを使用して、イメージのプルシークレットを作成します。 dev と stage 両方の名前空間に対して繰り返します。

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

各ポッドで imagePullSecret を設定する必要をなくすために、dev および stage 名前空間でサービスアカウントに imagePullSecret を追加することを検討してください。詳細については、Kubernetes のチュートリアルを参照してください。

環境変数グループを作成する

アプリリポジトリの変数グループ

az-vote-app-dev という名前の変数グループを作成します。次の値を設定します。

変数	値
AZ_ACR_NAME	(自分の ACR インスタンス。例: azurearctest.azurecr.io)
AZURE_SUBSCRIPTION	(自分の Azure サービス接続。このチュートリアルで既に出てきた arc-demo-acr になります)
AZURE_VOTE_IMAGE_REPO	Azure Vote アプリリポジトリの完全なパス (例: azurearctest.azurecr.io/azvote)
ENVIRONMENT_NAME	Dev
MANIFESTS_BRANCH	`master`
MANIFESTS_FOLDER	`azure-vote-manifests`
MANIFESTS_REPO	`arc-cicd-demo-gitops`
ORGANIZATION_NAME	Azure DevOps 組織の名前
PROJECT_NAME	Azure DevOps の GitOps プロジェクトの名前
REPO_URL	GitOps リポジトリの完全な URL
SRC_FOLDER	`azure-vote`
TARGET_CLUSTER	`arc-cicd-cluster`
TARGET_NAMESPACE	`dev`

環境変数グループをステージする

az-vote-app-dev 変数グループを複製します。
その名前を az-vote-app-stage に変更します。
対応する変数に次の値を設定します。

変数	値
ENVIRONMENT_NAME	段階
TARGET_NAMESPACE	`stage`

これで、dev および stage 環境にデプロイする準備ができました。

ビルドサービスにさらにアクセス許可を付与する

CD パイプラインは、実行中のビルドのセキュリティトークンを使用して、GitOps リポジトリに対する認証を行います。パイプラインで新しいブランチを作成したり、変更をプッシュしたり、pull request を作成したりするには、さらに多くのアクセス許可が必要です。

Azure DevOps プロジェクトのメインページから Project settings にアクセスします。
[Repositories] を選択します。
[<GitOps Repo Name>] を選択します。
[Security] を選択します。
<Project Name> Build Service (<Organization Name>) に対して Contribute、Contribute to pull requests、Create branch を許可します。

詳細については、次を参照してください。

開発環境を初めてデプロイする

CI および CD パイプラインが作成されたら、CI パイプラインを実行して、初めてアプリをデプロイします。

CI パイプライン

CI パイプラインの初回実行中、サービス接続名の読み取りでリソース承認エラーが発生する場合があります。

アクセスされている変数が AZURE_SUBSCRIPTION であることを確認します。
使用を承認します。
パイプラインを再実行してください。

CI パイプライン:

アプリケーションの変更が、デプロイに対する自動品質チェックすべてに合格したことを確認します。
PR パイプラインで完了できなかった追加の検証を実行します。
- GitOps に固有のパイプラインでは、CD パイプラインによってデプロイされるコミットの成果物も発行されます。
Docker イメージが変更され、新しいイメージがプッシュされたことを確認します。

CD パイプライン

最初の CD パイプラインの実行中に、パイプラインに GitOps リポジトリへのアクセス権を付与するように求められます。パイプラインにリソースへのアクセス許可が必要であることを示すメッセージが表示されたら、[表示] を選択します。次に、[許可] を選択して、パイプラインの現在および将来の実行に GitOps リポジトリを使用するためのアクセス許可を付与します。

CI パイプラインの実行が成功すると、デプロイプロセスを完了するために CD パイプラインがトリガーされます。各環境に段階的にデプロイします。

ヒント

CD パイプラインが自動的にトリガーされない場合:

その名前が .pipelines/az-vote-cd-pipeline.yaml のブランチトリガーと一致することを確認します。
- これは、arc-cicd-demo-src CI である必要があります。
CI パイプラインを再実行します。

GitOps リポジトリに対するテンプレートとマニフェストの変更が生成されると、CD パイプラインによってコミットが作成、プッシュされ、承認を得るために PR が作成されます。

Create PR タスクの出力に示されている PR リンクを開きます。
GitOps リポジトリに対する変更を確認します。次のような結果が表示されます。
- 高レベルの Helm テンプレートの変更。
- 望ましい状態への基本的な変更を示す低レベルの Kubernetes マニフェスト。 Flux により、これらのマニフェストがデプロイされます。
すべて問題がなければ、PR を承認して完了します。
数分後、Flux によって変更が取得され、デプロイが開始されます。
kubectl を使用してポートをローカルに転送し、次を使用して、アプリが正しく動作することを確認します。

kubectl port-forward -n dev svc/azure-vote-front 8080:80
ブラウザーで Azure Vote アプリ (http://localhost:8080/) を表示します。
お気に入りに投票し、アプリに変更を加える準備をします。

環境の承認を設定する

アプリのデプロイ時には、コードまたはテンプレートを変更できるだけでなく、意図せずにクラスターを正常でない状態にする場合もあります。

開発環境でデプロイ後に中断が明らかになる場合は、環境の承認を使用して、その後の環境に進まないようにしてください。

Azure DevOps プロジェクトで、保護する必要のある環境に移動します。
リソースの [承認とチェック] に移動します。
［作成］ を選択します
承認者とオプションのメッセージを指定します。
もう一度 [作成] を選択し、手動による承認チェックの追加を完了します。

詳細については、承認とチェックの定義に関するチュートリアルを参照してください。

次に CD パイプラインが実行されると、そのパイプラインは GitOps PR の作成後に一時停止します。変更が正常に同期され、基本的な機能が渡されることを確認します。変更が次の環境に流れるように、パイプラインからのチェックを承認します。

アプリケーションの変更を行う

このベースラインセットのテンプレートやマニフェストがクラスターの状態を表している場合、アプリに小さな変更を加えます。

arc-cicd-demo-src リポジトリにある azure-vote/src/azure-vote-front/config_file.cfg ファイルを編集します。
"猫と犬" では十分な票数が得られないため、票数を増やすために "タブとスペース" に変更します。
新しいブランチで変更をコミットして、それをプッシュし、pull request を作成します。
- これは、CI/CD ライフサイクルを開始する典型的な開発者フローです。

PR 検証パイプライン

この PR パイプラインは、誤った変更に対する防御の最前線となります。通常のアプリケーションコードの品質チェックには、リンティングとスタティック分析が含まれます。また、GitOps の観点から、結果として得られるインフラストラクチャをデプロイするために同じ品質を保証する必要があります。

アプリケーションの Dockerfile と Helm チャートでは、アプリケーションと同じようにリンティングを使用できます。

リンティング時に検出されるエラーは、次のように多岐にわたります。

形式が正しくない YAML ファイル
ベストプラクティスの提案 (アプリケーションの CPU やメモリの上限の設定など)

注意

実際のアプリケーションで Helm のリンティングを最大限に利用するには、実際の環境で使用されているものとほぼ同じ値に置き換える必要があります。

パイプラインの実行中に検出されたエラーは、実行のテスト結果セクションに表示されます。ここでは、次の操作を実行できます。

エラーの種類に関する有用な統計情報を追跡します。
それらが検出された最初のコミットを検出します。
エラーの原因となったコードセクションへのトレーススタイルリンクをスタックします。

パイプライン実行が完了すると、アプリケーションコードとそれをデプロイするテンプレートの品質を保証したことになります。これで、PR を承認して完了できるようになりました。 CD パイプラインをトリガーする前に、この CI は再度実行され、テンプレートとマニフェストが再生成されます。

ヒント

実際の環境では、PR が品質チェックに必ず合格するように忘れずにブランチポリシーを設定してください。詳細については、ブランチポリシーの設定に関する記事を参照してください。

CD プロセスの承認

CI パイプラインの実行が成功すると、デプロイプロセスを完了するために CD パイプラインがトリガーされます。 CD パイプラインを初めて実行したときと同様に、各環境に段階的にデプロイします。今回、このパイプラインでは、各デプロイ環境を承認する必要があります。

dev 環境へのデプロイを承認します。
GitOps リポジトリに対するテンプレートとマニフェストの変更が生成されると、CD パイプラインによってコミットが作成、プッシュされ、承認を得るために PR が作成されます。
タスクに示された PR リンクを開きます。
GitOps リポジトリに対する変更を確認します。次のような結果が表示されます。
- 高レベルの Helm テンプレートの変更。
- 望ましい状態への基本的な変更を示す低レベルの Kubernetes マニフェスト。
すべて問題がなければ、PR を承認して完了します。
デプロイが完了するまで待ちます。
基本のスモークテストとして、アプリケーションページに移動し、投票アプリにタブとスペースが表示されていることを確認します。
- kubectl を使用してポートをローカルに転送し、kubectl port-forward -n dev svc/azure-vote-front 8080:80 を使用して、アプリが正しく動作することを確認します。
- ブラウザーで Azure Vote アプリ (http://localhost:8080/ ) を表示し、投票の選択肢がタブとスペースに変更されていることを確認します。
stage 環境に対して手順 1 から 7 を繰り返します。

これでデプロイは完了しました。これにより、CI/CD ワークフローが終了します。

リソースをクリーンアップする

このアプリケーションを引き続き使用する予定がなければ、次の手順でリソースをすべて削除します。

Azure Arc GitOps 構成の接続を削除します。

az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

dev 名前空間を削除します。
- kubectl delete namespace dev
stage 名前空間を削除します。
- kubectl delete namespace stage

次のステップ

このチュートリアルでは、アプリケーション開発からデプロイまでの DevOps を実装する完全な CI/CD ワークフローを設定しました。アプリを変更すると、自動的に検証とデプロイがトリガーされ、手動の承認によって制御されます。

Azure Arc 対応 Kubernetes での GitOps と構成の詳細については、概念に関する記事に進んでください。

GitOps を使用した CI/CD ワークフロー - Azure Arc 対応 Kubernetes