チュートリアル: GitOps (Flux v2) を使用して CI/CD を実装する

[アーティクル]
01/15/2025

このチュートリアルでは、GitOps (Flux v2) と Azure Arc 対応 Kubernetes クラスターまたは Azure Kubernetes Service (AKS) クラスターを使って、CI/CD ソリューションを設定します。サンプルの Azure Vote アプリを使用すると、次のことができます。

アプリケーションと GitOps リポジトリを Azure Devops (Azure Repos) または GitHub に接続する。
Azure Pipelines または GitHub のいずれかで CI/CD フローを実装する。
Azure Container Registry を Azure DevOps および Kubernetes に接続する。
環境変数グループまたはシークレットを作成する。
dev および stage 環境をデプロイする。
アプリケーション環境をテストする。

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

前提条件

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

Azure Container Registry を Kubernetes に接続する

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

Azure Container Registry を既存の AKS クラスターに接続する

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

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

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

非 AKS およびローカルクラスターを Azure Container Registry に接続するには、イメージのプルシークレットを作成します。 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 のチュートリアルを参照してください。

必要な CI/CD オーケストレーターに応じて、Azure DevOps または GitHub のいずれかの手順に進むことができます。

Azure DevOps を使用した CI/CD の実装

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

最初に次の手順を完了してください。

Azure DevOps Services にサインインします。
Azure Repos および Azure Pipelines に対する "ビルド管理者" および "プロジェクト管理者" のアクセス許可を持っていることを確認します。

アプリケーションおよび 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-srcを指定してリポジトリをインポートする
arc-cicd-demo-gitops GitOps リポジトリ
- URL: https://github.com/Azure/arc-cicd-demo-gitops
- Azure Vote アプリを格納するクラスターリソースのベースとして機能します。
- 名前arc-cicd-demo-gitopsを指定してリポジトリをインポートする

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 flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace flux-system \
   --resource-group myResourceGroup \
   -u 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 \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

ヒント

(Arc 対応クラスターではなく) AKS クラスターの場合は、-cluster-type managedClusters を使用してください。

Azure portal でデプロイの状態を確認します。
- 成功した場合は、dev と stage の両方の名前空間がクラスター内に作成されます。
- クラスターの [Azure portal] ページで、[fGitOps] タブで構成 cluster-config が作成されていることを確認することもできます。

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 パイプライン

Azure Container Registry を Azure DevOps に接続する

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

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

PR サービス接続を構成する

CD パイプラインは、GitOps リポジトリ内の pull request (PR) を操作します。これにはサービス接続が必要です。この接続を構成するには、以下の手順を実行します。

Azure DevOps では、プロジェクト設定ページから [サービス接続] ページを開きます。 TFS では、上部のメニューバーの設定アイコンから [サービス] ページを開きます。
[+ 新しいサービス接続] を選択して、Generic 型を選択します。
そのサービス接続のパラメーターを入力します。このチュートリアルでは、次を使用します。
- サーバー URL https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
- [ユーザー名] と [パスワード] は空白のままにします。
- サービス接続に azdo-pr-connection という名前を指定します。
[すべてのパイプラインへのアクセス許可を与える] を選択します。
- このオプションにより、サービス接続に対して YAML パイプラインファイルが承認されます。
[保存] を選択して接続を作成します。

GitOps コネクタをインストールする

GitOps コネクタリポジトリを Helm リポジトリに追加します。

   helm repo add gitops-connector https://azure.github.io/gitops-connector/

クラスターにコネクタをインストールします。

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=AZDO \
      --set ciCdOrchestratorType=AZDO \
      --set gitOpsOperatorType=FLUX \
      --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
      --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
      --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --set orchestratorPAT=<Azure Repos PAT token>

Note

Azure Repos PAT token のアクセス許可が Build: Read & execute と Code: Full になっている必要があります。

GitOps コネクタに通知を送信するように Flux を構成します。

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config 
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

インストールの詳細については、GitOps コネクタリポジトリを参照してください。

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

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

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

変数	値
`AZURE_SUBSCRIPTION`	(自分の Azure サービス接続。このチュートリアルで既に出てきた arc-demo-acr になります)
`AZ_ACR_NAME`	Azure ACR 名 (arc-demo-acr など)
`ENVIRONMENT_NAME`	Dev
`MANIFESTS_BRANCH`	`master`
`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`
`VOTE_APP_TITLE`	投票アプリケーション
`AKS_RESOURCE_GROUP`	AKS リソースグループ。自動テストに必要。
`AKS_NAME`	AKS 名。自動テストに必要。

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

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

変数値

ENVIRONMENT_NAME 段階

TARGET_NAMESPACE stage

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

環境を作成する

Azure DevOps プロジェクトで、Dev と Stage 環境を作成します。詳細については、「環境を作成してターゲットにする」を参照してください。

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

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

Azure DevOps で、プロジェクト設定 を開きます。
[リポジトリ]で、[Repos] を選択します。
[セキュリティ] を選択します。
<Project Name> Build Service (<Organization Name>) と Project Collection Build Service (<Organization Name>) を見つけ (表示されない場合は検索を使用)、[投稿]、[pull requests への参加]、[ブランチの作成] を許可します。
[パイプライン] で、[設定] を選択します。
[YAML パイプライン内のリポジトリへのアクセスを保護する] オプションをオフにします。

詳細については、「ビルドサービスにバージョン管理のアクセス許可を付与する」および「ビルドサービスアカウントのアクセス許可を管理する」を参照してください。

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

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 が作成されます。

パイプラインによって作成された、GitOps リポジトリへの PR を検索します。
GitOps リポジトリに対する変更を確認します。次のような結果が表示されます。
- 高レベルの Helm テンプレートの変更。
- 望ましい状態への基本的な変更を示す低レベルの Kubernetes マニフェスト。 Flux により、これらのマニフェストがデプロイされます。
すべて問題がなければ、PR を承認して完了します。
数分後、Flux によって変更が取得され、デプロイが開始されます。
[コミット履歴] タブで git commit の状態を監視します。succeeded になると、CD パイプラインによって自動テストが開始されます。
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 とメモリの制限の設定などのベストプラクティスの提案までにわたります。

Note

実際のアプリケーションで Helm リンティングから最大限のカバレッジを得るには、実際の環境で使用される値に近い値を代入します。

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

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

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

ヒント

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

CD プロセスの承認

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

dev 環境へのデプロイを承認します。
GitOps リポジトリに対するテンプレートとマニフェストの変更が生成されると、CD パイプラインによってコミットが作成、プッシュされ、承認を得るために 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 DevOps GitOps のフロー図に関するページを参照してください。

GitHub を使用して CI/CD を実装する

このチュートリアルでは、GitHub と GitHub Actions に関する知識があることを前提としています。

アプリケーションと GitOps リポジトリをフォークする

アプリケーションリポジトリおよび GitOps リポジトリをフォークします。このチュートリアルでは、次のサンプルリポジトリを使用します。

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 アプリを格納するクラスターリソースのベースとして機能します。

GitOps リポジトリを接続する

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

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

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

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

GitHub で、新しくフォークした arc-cicd-demo-gitops リポジトリに対する新しい GitOps 接続を作成します。

az k8s-configuration flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace cluster-config \
   --resource-group myResourceGroup \
   -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

Azure portal でデプロイの状態を確認します。
- 成功した場合は、dev と stage の両方の名前空間がクラスター内に作成されます。

GitOps コネクタをインストールする

GitOps コネクタリポジトリを Helm リポジトリに追加します。

   helm repo add gitops-connector https://azure.github.io/gitops-connector/

クラスターにコネクタをインストールします。

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=GITHUB \
      --set ciCdOrchestratorType=GITHUB \
      --set gitOpsOperatorType=FLUX \
      --set gitHubGitOpsRepoName=arc-cicd-demo-src \
      --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
      --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
      --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
      --set orchestratorPAT=<GitHub PAT token>

GitOps コネクタに通知を送信するように Flux を構成します。

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

インストールの詳細については、GitOps コネクタリポジトリを参照してください。

GitHub シークレットを作成する

次のステップは、GitHub リポジトリと環境シークレットを作成することです。

GitHub リポジトリシークレットを作成する

GitHub リポジトリのシークレットには次の値を使用します。

シークレット	値
`AZURE_CREDENTIALS`	形式 {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"} の Azure の資格情報
`AZ_ACR_NAME`	Azure ACR 名 (arc-demo-acr など)
`MANIFESTS_BRANCH`	`master`
`MANIFESTS_FOLDER`	`arc-cicd-cluster`
`MANIFESTS_REPO`	`https://github.com/your-organization/arc-cicd-demo-gitops`
`VOTE_APP_TITLE`	投票アプリケーション
`AKS_RESOURCE_GROUP`	AKS リソースグループ。自動テストに必要。
`AKS_NAME`	AKS 名。自動テストに必要。
`PAT`	GitOps リポジトリに対する PR へのアクセス許可を持つ GitHub PAT トークン

GitHub 環境シークレットを作成する

次のシークレットを使用して az-vote-app-dev 環境を作成します。

Secret	値
`ENVIRONMENT_NAME`	Dev
`TARGET_NAMESPACE`	`dev`

次のシークレットを使用して az-vote-app-stage 環境を作成します。

Secret	値
`ENVIRONMENT_NAME`	段階
`TARGET_NAMESPACE`	`stage`

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

CI/CD 開発ワークフロー

CI/CD 開発ワークフローを開始するには、ソースコードを変更します。アプリケーションリポジトリで、.azure-vote/src/azure-vote-front/config_file.cfg ファイル内の値を更新して、変更をリポジトリにプッシュします。

CI/CD 開発ワークフロー:

アプリケーションの変更が、デプロイに対する自動品質チェックすべてに合格したことを確認します。
PR パイプラインで完了できなかった追加の検証を実行します。
Docker イメージが変更され、新しいイメージがプッシュされたことを確認します。
次の CD ステージで使用される成果物 (Docker イメージタグ、マニフェストテンプレート、ユーティリティ) を発行します。
アプリケーションを開発環境にデプロイします。
- マニフェストを GitOps リポジトリに生成します。
- 承認のために GitOps リポジトリへの PR を作成します。

これらの手順が完了したら、次の手順を実行します。

パイプラインによって作成された、GitOps リポジトリへの PR を検索します。
GitOps リポジトリに対する変更を確認します。次のような結果が表示されます。
- 高レベルの Helm テンプレートの変更。
- 望ましい状態への基本的な変更を示す低レベルの Kubernetes マニフェスト。 Flux により、これらのマニフェストがデプロイされます。
すべて問題がなければ、PR を承認して完了します。
数分後、Flux によって変更が取得され、デプロイが開始されます。
[コミット履歴] タブで git commit の状態を監視します。succeeded になると、CD Stage ワークフローが開始されます。
kubectl を使用してポートをローカルに転送し、次を使用して、アプリが正しく動作することを確認します。
```
kubectl port-forward -n dev svc/azure-vote-front 8080:80
```
ブラウザーで Azure Vote アプリ (http://localhost:8080/) を表示します。
お気に入りに投票し、アプリに変更を加える準備をします。

CD ステージワークフロー

Flux によってアプリケーションが開発環境に正常にデプロイされ、GitOps コネクタを介して GitHub Actions に通知されると、CD ステージワークフローが自動的に開始されます。

CD ステージワークフロー:

開発環境に対してアプリケーションスモークテストを実行します
アプリケーションをステージング環境にデプロイします。
- マニフェストを GitOps リポジトリに生成します
- 承認のために GitOps リポジトリへの PR を作成します

ステージング環境へのマニフェスト PR がマージされ、Flux によってすべての変更が正常に適用されると、GitOps リポジトリの Git コミット状態が更新されます。これでデプロイは完了しました。

このチュートリアルで使用される CI/CD ワークフローに実装されているすべての手順と手法の詳細な概要については、GitHub GitOps のフロー図に関するページを参照してください。

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

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

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

az k8s-configuration flux delete \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --resource-group myResourceGroup \
      -t connectedClusters --yes

GitOps コネクタを削除します。

helm uninstall gitops-connector -n flux-system
kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system

次のステップ

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

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

概念: GitOps を使用した CD プロセス実装例: GitOps を使用した CI/CD フローの詳細

次の方法で共有

チュートリアル: GitOps (Flux v2) を使用して CI/CD を実装する

前提条件

Azure Container Registry を Kubernetes に接続する

Azure Container Registry を既存の AKS クラスターに接続する

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

Azure DevOps を使用した CI/CD の実装

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

GitOps リポジトリを接続する

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

Azure Container Registry を Azure DevOps に接続する

PR サービス接続を構成する

GitOps コネクタをインストールする

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

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

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

環境を作成する

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

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

CI パイプライン

CD パイプライン

環境の承認を設定する

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

PR 検証パイプライン

CD プロセスの承認

GitHub を使用して CI/CD を実装する

アプリケーションと GitOps リポジトリをフォークする

GitOps リポジトリを接続する

GitOps コネクタをインストールする

GitHub シークレットを作成する

GitHub リポジトリシークレットを作成する

GitHub 環境シークレットを作成する

CI/CD 開発ワークフロー

CD ステージワークフロー

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

チュートリアル: GitOps (Flux v2) を使用して CI/CD を実装する

前提条件

Azure Container Registry を Kubernetes に接続する

Azure Container Registry を既存の AKS クラスターに接続する

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

Azure DevOps を使用した CI/CD の実装

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

GitOps リポジトリを接続する

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

Azure Container Registry を Azure DevOps に接続する

PR サービス接続を構成する

GitOps コネクタをインストールする

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

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

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

環境を作成する

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

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

CI パイプライン

CD パイプライン

環境の承認を設定する

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

PR 検証パイプライン

CD プロセスの承認

GitHub を使用して CI/CD を実装する

アプリケーションと GitOps リポジトリをフォークする

GitOps リポジトリを接続する

GitOps コネクタをインストールする

GitHub シークレットを作成する

GitHub リポジトリ シークレットを作成する

GitHub 環境シークレットを作成する

CI/CD 開発ワークフロー

CD ステージ ワークフロー

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

次のステップ

フィードバック

その他のリソース

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

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

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

GitHub リポジトリシークレットを作成する

CD ステージワークフロー