# KT#009-hokaguchi GitOpsやるやで

###### tags:`kubernetes` `GitOps`

## はじめに
ここ数週間忙しすぎて死んでた。なんなら今も死んでる。すまんやで。
CI/CDの記述があるけどGitOpsの説明に必要な最低限の説明しかしてないっす。すまんやで。

## ソフトウェアエンジニアリング三種の神器
ソフトウェアエンジニアリングというのは、ソフトウェアの開発・運用・保守に工学的手法を適用すること。こいつらを使うと、Developer Experienceが向上し、業務改善・アプリ開発により専念できるようになる。

### CI/CDのパイプラインって
以前陳建一が色々説明してくれたので割愛。要は信頼ある成果物をデプロイしていこうぜって話。CI/CDすることで、「品質の保証」「リリース速度の向上」「成果物の適切な管理」が可能になるっぽい。

実際コンテナ環境をCI/CDを導入して構成すると、以下のような感じになったりする。


一応これでGitの操作をベースにビルド・デプロイできるようになったけど、これでGitOpsが完成したわけじゃない。てなわけでGitOpsの説明をしていく。

## GitOpsやぞコラ
### 目的
そもそもGitOpsの目的ってのが、CI(継続的インテグレーション)とCD(継続的デリバリ)を実現した上で、
- 権限情報の公開範囲を最小化
- CI/CDに承認機構を追加

がしたいっぽい。そのために前提として、
- すべての操作にGitを介して行う
- インフラ構成をDeclarativeに定義する
- アプリのリポジトリとインフラ定義のリポジトリを分ける
- CDツールはプライベートなネットワーク空間に配置する

といった対応が必要になる。

### 実装例
さっきのCI/CDをGitOpsにした図は以下。


何が変わったか分かった？一応3つ変わった点がある。少し下に変わったところを書くやで。
<br><br><br><br><br><br><br><br><br><br><br><br>

はい、じゃあ変更点かきまーす。
- クラスタ内のCDツールがリポジトリを監視
- リポジトリが2つ存在
- CIツールとCDツールが独立


といった感じすね。この変更点3つについてもう少し詳しく書きまっせ。

### 1. クラスタ内のCDツールによるリポジトリ監視
さっきの図であったように、CDツールはクラスタ内に存在している。こいつがクラスタの状態を把握している形になる。ほんでCDツールはConfigリポジトリの変更を検知し、クラスタに適用する。いわばConfigリポジトリとCDツールは同期処理をしている感じ。
このようにすることで得られる効果は以下。
- k8sを操作できる強力な権限を外部に払い出す必要がなくなる
- Gitリポジトリの状態とクラスタの状態が同期することで、Gitのソースコードをベースに変更の評価が可能になる
- GitのRevert操作で切り戻しが可能になる

正直外口はGit弱者なのでそんな上手く使いこなせてないけど、そんな感じ。

### 2. リポジトリが2つ存在
GitOpsでは2種類のリポジトリが存在している。
- Appリポジトリ
アプリのソースコードを格納。CIの対象
- Configリポジトリ
インフラ定義情報を格納。CDの対象となり、CDツールに監視させる

実際には、アプリのソースコードを作成してpushしたあとに、インフラ定義をつくってpushする必要がある。
こうすることで、以下のような効果を得られる。
- アプリ開発と環境へのリリースを分割できる
- ConfigリポジトリのPRのマージ権限を制限することで、Git上でリリースにおける承認手続きを実現できる

### 3. CIツールとCDツールが独立している
CIツールはDockerイメージをビルドとかプッシュできるといった、よくある要件持ってればいいので基本なんでもOK。ただCDツールは、上記2つを満たせるようなものを使う必要がある。主な要件として、
- デプロイ
Configリポジトリの変更を検知して環境へのデプロイを自動化できる。Configリポジトリのリソース削除にも追随できる。
- ステップバック
リリース後のステップバックを行うことができる
- 承認
デプロイのパイプライン中に、管理者による承認を組み込むことができる。
- 操作性
GUI上でデプロイパイプラインを作成できる

がある。外口が知っている中で上記を満たすようなCDツールは、ArgoCD、GoCD、Jenkins Xかな。他はすまんが知らん。ただ、GoCDとJenkins Xはリソース削除に未対応。あと、ArgoCDは日本での利用ケースが多いらしく、困ったらググれる。なのでArgoCDが今のとこ使いやすいかな。

## まとめ
GitOpsのルールとして、
- すべての手続きはGit操作で実施
- リポジトリはアプリのソースを持つAppリポジトリと環境の設定ファイルを管理するConfigリポジトリ2つで構成される
- Appリポジトリ: CIツールでビルド・テスト
- COnfigリポジトリ: CDツールに変更を検知させ、デプロイ
- GitOpsではCI・CDツールは別々に検討する
- CDツールはk8sだったらクラスタ内にGitOps対応のものを使う
- CIツールは基本的になんでもOK

GitOpsを使うメリットとして、
- 強力な権限を外部に公開しなくていい
- デプロイタイミングの調整、承認手続きを踏むことができる
- デプロイまで自動実施しない
- GitのPRを用いた承認手続きが可能
- 環境構成をGit上のコードで管理可能
- 構成の可視化
- バージョン管理
- Git Revertによる切り戻し

逆にデメリットとして、
- CIOpsに比べてデプロイ速度が低下
- Appリポジトリ変更後にConfigリポジトリの変更が必要に
- 開発環境など変更によるリスクが少ない環境に対するデプロイについては無駄な作業が増えることも