FIXER Tech Blog - Development

FIXER cloud.config Tech Blog

「Argo CD」を使ってAKSにGitOpsを導入する

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「[Argo CD]AKSにGitOpsを導入する」を再編集したものです。

　皆さんこんにちは、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ブランチを切る必要がなくなります（6月20日編集）。

pr環境

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

大変だったこと

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

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

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

最後に

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

藤野元規／FIXER
2022年度からFIXERに入社しました。好きな言語はTypeScriptのComposition APIです。フルスタックエンジニアを目指して、日々精進していきたいです（願望）

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER