皆さんこんにちは、FIXER2年目の藤野です。今回は業務の一環としてArgo CDの採用を検討する機会がありましたので、そのきっかけとフローの構成案を備忘録として記事にしてみようと思います。

背景と問題点

今回Argo CDの導入を検討しているプロジェクトでは、フロント・バックエンドはGitベースで管理され、CI/CDが確立されていましたが、インフラ用のGitリポジトリでは、CI/CDが組み込まれていませんでした。

問題点

• Gitと実環境に差分が生じる
• 人為的ミスの発生
• デグレの発生

これらの問題点から、GitOpsを導入しようということになりました。

Argo CDとは？

Argo CDは、KubernetesマニフェストをGitOpsで管理するためのオープンソースCDツールです。​

メリット

• Argoが自動的にmanifestを更新するため、人為的ミスをなくすことができます。​​

• Web UIから変更前後の差分を確認できるため、可観測性が向上します。

• ACRやGitの変更を検知して、自動的に同期したり変更PRを出したりできるため、AKS上とインフラリポジトリとの差分をなくすことができます。

なぜArgo CDなのか？

• ArgoにはGitリポジトリのマニフェストのdiffを検知する機能があります。​また、diffを自動的に同期させるself-healing機能があります。「flux」というGitOpsがありますが、こちらにはその機能がありません。​

• 見やすいWeb GUIがあります。こちらも同じく、fluxにはありません。

構成図

ここからdev, st, pr環境のそれぞれの構成図と、そのフローにした理由を解説していきます。

dev環境

Argo CD Image Updaterを利用することで、インフラリポジトリのdevelopブランチにコミットされるたびに、自動的にAKS上に適用されるようにします。

コミットごとにPRを作成することもできますが、​マージするのが手間だしコミット履歴が汚れて嬉しくありません。従って、フローは以下のようにしました。

st環境

st環境ではpr環境と合わせる意味も含めて、まずdevelopへのPRを作成した後、それをマージすることでst環境に適応します。

GitHub Actionsと連携することでPRを作成できます。また、kustomizeを利用することで、dev, st, prの差分を管理でき、stagingブランチを切る必要がなくなります。（2023/06/20編集）

pr環境

pr環境ではmasterへマージするためのPRを毎回用意して、差分等をよく理解したうえで安全にデプロイします。

大変だったこと

Argo CDとACR間の認証を通すのが大変でした。趣旨とずれるので詳細は省きますが、最終的には以下のコマンドを使用することで解決できました。

az aks check-acr --name <ACR名> --resource-group <リソースグループ> --acr <ACR名>.azurecr.io

これで通るなんて誰も思わんやん、、、。

最後に

今回はArgo CDの導入事例を紹介しました。フローのみで内容が少し薄くなってしまいましたが、それぞれの実装方法とか、気が向いたらまた記事を書こうと思います。