はじめに
これはドリコム Advent Calendar 2020の24日目です。23日目は、taji さんによる「AdventCalendarかきおろしイラスト vol.2」です。
自己紹介と今回書くこと
こんにちは、enzaプラットフォーム事業本部でエンジニアをやっている安藤です。巷で話題のGitOpsについて「聞いたことあるけど、導入は検討していない」という状態だったのですが、今更ながらGitOpsが与えてくれる恩恵について知ることができたので、そのことについて書きたいと思います。
GitOpsはWeaveworks社が提唱し始めたCDの手法で、世に出てから数年経ちますが、日本ではそこまで普及していない印象がありますね。
ちなみに当時のWeaveworks社のブログはコチラ。 本稿が少しでもGitOpsについて知るキッカケになれば幸いです。
GitOpsってなに？
ざっくり言うと「インフラとアプリケーションの両方を含めたシステム全体をコード化して、Gitで管理しようぜ」って話です。
ちなみにインフラと言っても、Kubernetes上のリソースであることが大前提となっています。
どれくらい使われてるのさ
2020/06/29にGitLab社がTwitterでフォロワー向けに行ったアンケートではこんな結果が出たそうです。| 現在GitOpsを利用している | 23.8% |
| GitOpsの導入を計画している | 10.6% |
| GitOpsを聞いたことはあるが導入はしていない | 11.6% |
| まだGitOpsを検討していない | 54.0% |
ぐぬぅ…負けてはおれんぞ…。
GitOpsで得られる恩恵とはなんぞ
大きく分けて、以下の4つが挙げられると思います。- 生産性の向上
- 安定性の向上
- 信頼性の向上
- セキュリティ向上とCI/CDの分離
それぞれどういうことか、パッと調べてシャッと書いていきますね。
1. 生産性の向上
Gitに変更（git push）が加えられるとインフラに変更が反映され、Kubernetesクラスタの更新や機能を管理することが出来るようになります。デプロイや運用（ロールバックとか）をすべてGitを通して行うため、秘伝のタレ的なコマンドを実行する必要もなくなり、属人性が排除されます。
ほう、これはみんながHappyになれそうですね。 また、実際の本番環境の状態をGitのソースと比較し、一致しない場合にそれを検知・修正することも可能です。
2. 安定性の向上
GitOpsのワークフローを導入すると、外部で行われたKubernetesクラスタへの変更の監査ログを自動的に取得することができます。これにより「誰がいつ何を変更したのか」という監査証跡が残せるので、SOC 2に準拠したサービスの情報統制が実現可能です。 また、トラブルが起きた場合でもすぐに原因の追求が行えますし、何より復旧出来るようになりますね。 イケナイことしたらすぐバレちゃうんだな。
履歴が残るって正義。
3. 信頼性の向上
コマンドラインを用いないことがモットーなので、「あ…kubectl applyの向き先を間違えた…てへへ」という悲劇がなくなります。 ロールバックなどの運用もGitを通して行う（この場合はgit revert）ことが出来るようになり、安定した再現性のあるオペレーションが可能です。 また、システム全体がGit上のコードに記述されているので、障害発生後に復旧するための情報源が一つになり、平均修復時間 (MTTR) が短縮されます。
4. セキュリティ向上とCI/CDの分離
CI/CDツールを用いたデプロイは基本的にPush型ですが、GitOpsではPull型で行うようになります。Push型というのは、ツール内からkubectlを使用して変更をKubernetesクラスタにPushするようなデプロイのことを指しています。
多くのチームが採用しているんじゃないかと思いますが、これだとクラスタの外部に認証情報を公開することになるため、本番環境でのAttack vectorになってしまう可能性があります。 GitOpsでは、Pull型のデプロイにすることで、Kubernetesクラスタに変更を加えるための認証情報をCDが持つ必要がなくなり、セキュリティリスクを低減することが出来ます。 いつの時代も安全は第一ですよねぇ。 それと、本来は異なるはずなのにまとめられがちなCI/CDの役割が明瞭になります。
大体こんな感じ。
- CI
- Push型
- ビルドやテストだけをやる
- デプロイ環境への操作は行わない
- CD
- Pull型
- デプロイだけをやる
- 自身がデプロイする環境への操作のみを行う
つまりどういうワークフローなんだ
ツラツラと文章で説明してきてしまったので、ここは画像にしましょう。 環境やツールによって差はあるかと思いますが、大体はこんなもんだろうという気持ちと勢いで作っております。ご了承くださいm(_ _)m
変わるところは、まずマニフェストファイル群を置くGitOps用のリポジトリを用意して、CIツールからPRを作成します。
そして、そのPRをマージするとコードが更新され、CDツールが同期を行うことで、Kubernetesクラスタに反映させます。 この同期を行うCDの部分が肝ですね。
じゃあ実際にやるにはどうしたらいいのよ
GitOpsを実現するためにやるべきことはこんな具合だと思います。- 導入するツールを選ぶ
- Gitホスティングサービス
- CIツール
- CDツール <= GitOpsツールはココ！
- Kubernetesマニフェストのテンプレートエンジン
- Kubernetesマニフェストの作成
- CI/CDツールの設定
気になるGitOpsツールたち
今のところ、メジャーなのは以下の三つのようですね。
Argo CD（https://github.com/argoproj/argo-cd/）
- 良い感じのGUIがある！
- 手動でのSyncなどあらゆる操作がGUIから行える
- どのツールを選ぶにしても視覚的に確認したいので嬉しい
- 関連のドキュメントが見つかりやすい
- とりあえず公式っぽいのはこれ
- https://argoproj.github.io/argo-cd/
- デモページもあるので触って試せる
- 各種メトリクスはPrometheusを使って取得可能
- デモ用のGrafanaのダッシュボードまであるだと、、！
- https://grafana.apps.argoproj.io/
Flux CD（https://github.com/fluxcd/flux）
- GitOpsを提唱したWeaveworks社の謹製ツール
- 作りが非常にシンプルで軽量
- GUIもない
- チュートリアルも簡単で、すぐに動作確認が出来る！
- 関連のドキュメントもそこそこ見つかる
- とりあえず公式っぽいのはこれ
- https://docs.fluxcd.io/en/1.21.0/
- こちらもPrometheusでメトリクスが取れる
- なんとコンテナイメージの変更まで検知して、KubernetesのDeploymentに自動的に反映！
- どのイメージを対象にするかはtagで制御が可能
Jenkins X（https://github.com/jenkins-x/jx-cli）
- 前述の二つとは異なり、GitOpsに対応したCI/CDのパイプライン自体を構築することが出来る
- パイプラインだけでなく、GitリポジトリやらKubernetesクラスタやらまで作成することが可能
- もはや何でも出来そうだが、その分アーキテクチャが複雑で、導入の準備にも時間がかかりそう
- 提供されるGUIは必要最低限の簡素な感じ
- こっちも関連のドキュメントはそこそこある
- とりあえず公式っぽいのはこれ
- https://jenkins-x.io/docs/
- Helmなどの知識も必要になってくるので注意
個人的には、イケてるGUIでSyncされていく様をニヤニヤ眺めていたいので、Argo CDを使ってみたいなという気持ちがありますね。
みなさんのお気に入りはどれでしょう？ ちなみに、2019年11月にGitOps Engineを作って、Argo CDとFlux CDの共通化をしていこうよというアツいプロジェクトが発表されまして。
ふむ、世の中なにごともスムーズにはいかないものです。
今後のGitOpsがどうなっていくのかドキドキワクワクですね。
参考文献
まとめ
巷で話題のGitOpsについて、自分が知ったことを書かせて頂きました。ぜひ自分たちのプロジェクトにも導入してみたいなと思っています。 ということで俺、今期が終わったらGitOpsするんだ。
さいごに
明日は大トリ！中村 貴昭さんの記事です。 ドリコムでは一緒に働くメンバーを募集しています！
募集一覧はコチラを御覧ください！
