チュートリアル: GitOps (Flux v2) を使用して CI/CD を実装する
このチュートリアルでは、GitOps (Flux v2) と Azure Arc 対応 Kubernetes クラスターまたは Azure Kubernetes Service (AKS) クラスターを使って、CI/CD ソリューションを設定します。 サンプルの Azure Vote アプリを使用して、次のことを行います。
- Azure Arc 対応 Kubernetes または AKS クラスターを作成する。
- アプリケーションおよび GitOps リポジトリを Azure Repos または GitHub に接続する。
- Azure Pipelines または GitHub のいずれかで CI/CD フローを実装する。
- Azure Container Registry を 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 キーを選択して、コードまたはコマンドを実行します。
前提条件
前のチュートリアルを完了し、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] ページで、[f
GitOps
] タブで構成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 パイプライン ファイルが承認されます。
- [OK] を選択して接続を作成します。
PR サービス接続を構成する
CD パイプラインでは、GitOps リポジトリの PR を操作します。 これを行うには、サービス接続が必要です。 この接続を構成するには、以下の手順を実行します。
- Azure DevOps では、プロジェクト設定ページから [サービス接続] ページを開きます。 TFS では、上部のメニュー バーの設定アイコンから [サービス] ページを開きます。
- [+ 新しいサービス接続] を選択して、
Generic
型を選択します。 - そのサービス接続のパラメーターを入力します。 このチュートリアルでは、次を使用します。
- サーバー URL
https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
- [ユーザー名] と [パスワード] は空白のままにします。
- サービス接続に azdo-pr-connection という名前を指定します。
- サーバー URL
- [すべてのパイプラインへのアクセス許可を与える] を選択します。
- このオプションにより、サービス接続に対して YAML パイプライン ファイルが承認されます。
- [OK] を選択して接続を作成します。
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 という名前の変数グループを作成します。 次の値を設定します。
変数 | Value |
---|---|
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 リポジトリに対する認証を行います。 パイプラインで新しいブランチを作成したり、変更をプッシュしたり、pull request を作成したりするには、さらに多くのアクセス許可が必要です。
- Azure DevOps プロジェクトのメイン ページから
Project settings
にアクセスします。 - [
Repos/Repositories
] を選択します。 - [
Security
] を選択します。 <Project Name> Build Service (<Organization Name>)
とProject Collection Build Service (<Organization Name>)
に対して( 検索フィールドが 表示されない場合は、検索フィールドに入力)、Contribute
、Contribute to pull requests
およびCreate branch
を許可します。- [https://resources.azure.com](
Pipelines/Settings
) に移動します Protect access to repositories in YAML pipelines
オプションをスイッチオフにする
詳細については、次を参照してください。
開発環境を初めてデプロイする
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 のコミットの状態を監視します。
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 を承認して完了できるようになりました。 CD パイプラインをトリガーする前に、この CI は再度実行され、テンプレートとマニフェストが再生成されます。
ヒント
実際の環境では、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 を使用してアプリケーション リポジトリをクラスターに接続します。 arc-cicd-demo-gitops GitOps リポジトリには、arc-cicd-cluster クラスターでアプリを稼働させるための基本的なリソースが含まれています。
最初の 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 リポジトリ シークレットを作成する
Secret | 値 |
---|---|
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 コミットの状態を監視します。
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 と構成の詳細については、概念に関する記事に進んでください。