こんにちは。シナジーマーケティングでインフラを担当しているチームです。
今回は、私たちが現在進行形で取り組んでいるKubernetesのデプロイツールを、長年利用してきた自前のGitLab CIからArgoCDへ移行している話についてご紹介します。
この記事では、
- なぜ移行する必要があったのか (背景と課題)
- ArgoCD導入のリアルな道のり (移行のハードル)
- ArgoCDを導入して何が変わったのか (メリット)
といった内容を、実際の運用経験を交えてお伝えします。GitHubへの移行を機にデプロイ方法を見直している方や、GitOpsに関心がある方の参考になれば幸いです。
これまでのデプロイと、見えてきた課題
これまで私たちのチームでは、セルフホスティングのGitLabサーバーをデプロイの起点としていました。開発環境から本番環境まで、すべてGitLab CIとkubectl applyを組み合わせた自前のスクリプトで運用してきたのです。
この構成は長年安定して稼働していましたが、全社的にソースコード管理をGitHubへ移行することになり、大きな課題が浮上しました。
課題: GitHub Actionsからどうやってセキュアにデプロイする?
従来の仕組みは、特定のIPアドレスからのアクセスのみを許可することでセキュリティを担保していました。しかし、GitHub Actionsに移行する場合、広範囲なIPアドレスを許可する必要があり、セキュリティリスクが高まります。
この課題を解決するため、私たちは新しいデプロイ方法を模索し始めました。
なぜArgoCDだったのか？
いくつかの選択肢を検討した結果、私たちはArgoCDの導入を決定しました。
採用の決め手は、Pull型のアーキテクチャです。 ArgoCDは、Kubernetesクラスタ内からGitHubリポジトリを監視し、変更を自らプル(Pull)してきます。これにより、GitHub Actionsから直接クラスタにアクセスする必要がなくなり、IPアドレス許可の問題を根本的に解決できました。
また、ArgoCDはGitOpsを体現するツールです。Gitリポジトリを唯一の信頼できる情報源(Single Source of Truth)とし、クラスタの状態を宣言的に管理できます。誰が・いつ・何を変更したのかがすべてGitの履歴に残るため、運用の一貫性と透明性が向上します。
リアルな移行の道のり
とはいえ、導入は決して平坦な道のりではありませんでした。
検討段階でも「ArgoCDは自作スクリプトに比べて機能が豊富な分、理解が必要」という認識があり、ArgoCDの概念や運用方法をチームで学ぶには、相応の学習コストがかかりました。
マニフェスト構成をどう扱うか
また、既存のマニフェストファイルの構成をどう扱うか、という課題もありました。ArgoCDではアプリケーション単位でリポジトリやパスを指定して管理するのが一般的です。そのため、「構成をArgoCDのベストプラクティスに合わせるか」「まずは既存の構成を活かすか」という判断が必要でした。
検討の結果、私たちは移行スピードと学習コストの軽減を優先し、既存構成を活かす方針を採用しました。ArgoCD Applicationの設定で環境ごとのパスを明示的に指定することで、構成を変えずに移行できるようにしたのです。
このアプローチにより、既存のマニフェストファイルを大きく修正することなく、最小限の影響でArgoCDを導入できました。実際に運用を始めてみると、完璧な構成設計よりも「まずは動く形で導入する」ことを優先する方が結果的にスムーズで、チーム全体の理解も早く進むことが分かりました。
ArgoCDの概念や挙動を体感しながら段階的に最適化していくことで、学びを得ながら実運用に即した形で改善を進められています。最初から完璧を目指さず、スモールスタートで始めることの重要性を改めて実感しています。
ArgoCDがもたらした変化
先日、無事にEKSのバージョンアップをArgoCDで完了し、そのメリットの大きさを実感しています。
可視性の向上
特に、Web UIによる「可視性」は圧倒的でした。
以前のGitLab CIでは、ジョブ単位の結果は確認できても、「どのアプリケーションがどういう状態なのか」「どこで同期が止まっているのか」を俯瞰して把握するのが難しいという課題がありました。この点について、移行を主導したインフラ担当のメンバーは次のように語っています。
「ArgoCDは全体が見えるのが一番大きい。GitLab CIだとジョブの成否はわかっても、クラスタ全体のアプリケーション状態を俯瞰して見ることができなかったんです。例えば、あるデプロイが原因で依存する別のサービスに影響が出ていても、ArgoCDの画面で一覧表示されていなければ気づけなかったと思います。実際にデプロイで問題が発生した際も、どのリソースに問題があるのか追跡がしやすかったですね。」
ArgoCDのUIは、Gitリポジトリの状態(あるべき姿)と実際のKubernetesクラスタの状態を常に比較し、その差分を明確に表示してくれます。これにより、トラブルシューティングの時間が大幅に短縮され、デプロイに対する心理的な安全性も大きく向上しました。
これからの展望
私たちのArgoCDへの移行はまだ道半ばです。まずは全てのアプリケーションをArgoCDの管理下に置くことが当面の目標です。
また、今回は慎重を期して手動同期にしましたが、将来的には自動同期の導入も検討していきたいと考えています。今後はチームで運用に慣れながら、最適な形を模索していくつもりです。
まとめ
GitHubへの移行をきっかけに始まったArgoCDの導入ですが、結果としてデプロイプロセスの可視性、安全性、信頼性を大きく向上させることができました。
特に以下の点で大きなメリットを実感しています。
- セキュリティの向上: Pull型アーキテクチャにより、IPアドレス許可の課題を解決
- 可視性の向上: クラスタ全体の状態を一目で把握でき、トラブルシューティングが容易に
- 運用の透明性: すべての変更がGit履歴に残り、誰が何をしたか明確に
学習コストや既存構成との兼ね合いなど、乗り越えるべきハードルはありましたが、それ以上に得られるメリットは大きいと感じています。もし同じような課題を抱えている方がいれば、ArgoCDは非常に有力な選択肢になるはずです。
この記事が、皆さんのDevOps改善のヒントになれば嬉しいです。
