こんにちは、かたいなかです。
最近、転職会議のCI/CD基盤をFluxベースのものからArgoCDベースのものに式年遷宮しました。今回の記事では、新しいArgoCDでのCI/CD基盤について、作り直しに至った経緯や改善点をご紹介します。
ArgoCD移行に至った経緯
転職会議では、以前の記事でも紹介したFluxというGitOpsのツールを使用してGitOpsを実現していました。
しかし、その後FluxからFlux2への移行が公式から推奨されるようになった後も、Flux2やArgoCD Image Updaterへの移行ができない状態が長く続いていました。
また、現行のフローでも以下のような大きな問題点を抱えていました。
- ロールバックできない問題
- チャットボットが老朽化
- Weave Cloudがサービス終了
以下でそれぞれ説明します。
ロールバックできない問題
ナイーブにFluxでGitOpsを実現していたため、ロールバックの際に問題が発生していました。
アプリケーションリポジトリをRevertしてできあがるイメージは、キャッシュを使ってビルドすると、以前ビルドしたものと全く同じものになってしまうことがあります。
このようなイメージをECRにプッシュしようとすると、すでにプッシュされているイメージと同じものだと判定されてしまい、実体はプッシュされず新しいタグのみ追加されます。
タグだけが更新されたイメージのプッシュ時刻は、すでにプッシュされているイメージのプッシュ時刻になっています。そのため、Fluxがイメージを新しいイメージと認識できず、ロールバックが行えない問題がたまに発生していました。
チャットボットが老朽化
転職会議では、本番デプロイやブランチデプロイをチャットボットで実現していました。EC2上にデプロイしていた時代からの実装が引き継がれており、チャットボットとしてのインタフェースを変えず、実装だけをECS向けやEKS向けに差し替えることでデプロイを実現してきました。
このような歴史が長いチャットボットのため、使っているライブラリが古くなったりして技術的負債となっていました。
Weave Cloudがサービス終了
とどめになったのが、Weave Cloudのサービス終了です。FluxのGUI代わりに活用していたのですが、2022/9/30にサービスを終了するとの連絡を受け取ってしまいました。
同じくWeave社が提供しているWeave GitOpsへの移行も考えたのですが、今回はGUIに定評があるArgoCDに移行することにしました。
ArgoCDによる新しいCI/CD基盤
前述のような問題を抱えていたため、ArgoCDを使用したCI/CD基盤を再構築することにしました。
以前のフローから大きく変わったのは以下のような点です。
- Pull Requestベースの本番デプロイ
- チャットボットの役割をGitHub Actionsと新チャットボットに分割
順番に見ていきます。
Pull Requestベースの本番デプロイ
以下の記事でも紹介されているように最近のArgoCD Image Updaterの機能を使うとGitHub Actionsを使ってPull Requestベースの本番デプロイを実現できます。
新しいイメージを作成すると、以下の画像のようなイメージ更新のためのPull Requestが自動作成されます。このPull Requestをマージすることで、本番環境にデプロイできるようにしています。
直接masterブランチにコミットさせるのと比較して、変更をロールバックするフローが改善されました。GitHubのGUIからのPull RequestのRevertにより簡単にロールバックを行うことができ、イメージのビルドを待つことなくすばやくロールバックが行なえます。
本番デプロイの具体的なフローは以下です。
なお、ステージング環境では本番環境とは異なり、イメージがビルドされたら新しいイメージを自動でデプロイするようにしています。
チャットボットの役割を整理してGithub Actionsと新チャットボットに分割
今までのチャットボットは、本番デプロイとブランチデプロイの2つの役割を持っていました。
本番デプロイは、チャットボットのコマンドを契機に本番にデプロイする機能です。ブランチデプロイは、Pull Requestのブランチからビルドしたイメージをステージング環境に一時的にデプロイすることで、他のマイクロサービスと結合して動作確認ができる機能です。
本番デプロイをPull Requestベースのフローに変更したため、本番デプロイ時のSlackへの通知等の機能はGitHub Actionsに移動し、新しいチャットボットはブランチデプロイのみ行うシンプルなものとして作り直しました。
ブランチデプロイのフローは以下です。処理の中で、ArgoCD Image Updaterがデプロイするイメージのルールを表す argocd-image-updater.argoproj.io/<image_name>.allow-tags というアノテーションの値を変更しています。また、ブランチデプロイの際に値を変更するため、ArgoCDの設定で当該アノテーションの差分を無視させるようにしています。
移行してよかったこと
EKS化してからの2年の間に体制変更があったため、EKS化したときのような転職会議専任のSREがいる体制ではなく、全社横断のインフラチームがEKS関連の運用を行っています。そんな中、ArgoCDのGUIがあることで視覚的にクラスタの中を理解できるため、 転職会議のインフラにまだあまり詳しくないインフラメンバーの学習コストが下がったように感じています。
また、チャットボットの古い実装に起因していた、ボットがたまに反応しなくなるなどの細かい問題も解決され、開発者にとってもよりストレスなく開発できるようになったと感じています。
改善したい点
ここまで良かったところのみ述べてきましたが、今回構築したCI/CD基盤にはまだまだ改善の余地があります。
Image UpdaterにWebhookで更新を開始する仕組みがない
Image UpdaterのロードマップではWebhookエンドポイントの実装予定があるのですが、現状ではまだ実装されていません。そのため、ブランチデプロイやステージング環境への新しいイメージの自動デプロイの際に数分の待ち時間が発生しています。Webhookエンドポイントがあれば、必要に応じてイメージの変更がキックできるため、この問題が解決できそうです。
https://github.com/argoproj-labs/argocd-image-updater#things-that-are-planned-roadmap
GitLabフローで作業がコンフリクトする
転職会議のKubernetesクラスタの管理にはGitOpsの考え方を採用し、developブランチがステージングクラスタに、masterブランチが本番クラスタに同期されています。
developブランチにマージした機能をmasterブランチにマージするフローでは、developブランチへの変更が他の人の変更と混ざってしまうことがあります。そうなるとmasterブランチへのマージ時に調整が必要になってしまいます。
GitHub Actions等でいい感じにcherry-pickができるようにし、機能ごとの独立したデプロイができるようにしていきたいです。
まとめ
リブセンスのインフラストラクチャグループでの行動指針の一つに「式年遷宮」があり、古い仕組みを新しい技術でより良い形で作り変えることを奨励しています。
式年遷宮で、Kubernetesエコシステムの成長とともに仕組みをより良いものにしていけるのはEKSでシステムを構築する醍醐味だなと感じました。
式年遷宮や日々の改善によってトイルやなるべく減らし、さらに大きな変更を伴う本質的な改善に本腰を入れて取り組みやすくなる、そんな良いループを回せていければと考えています。
