k8sでのCI/CDの流れを図解してみた【GitOps vs CIOps】

はじめに

• GitOpsって？
  • Gitを用いたCI/CDの手法の一つ
  • Dockerイメージの変更のようなクラスタの操作を、Gitリポジトリを介して行うこと
  • 手動で「kubectl」コマンドを実行する必要がなくなる

クラスタ上にデプロイするアプリケーションを開発する際のフロー

• クラスタ上にデプロイするアプリケーションを開発する時、一般に下記のフローを踏みます
  1. アプリケーションのソースコードを変更
     • xxx.javaなど
  2. アプリケーションのテスト
  3. コンテナイメージのビルド
  4. コンテナイメージをコンテナレジストリにプッシュ
     • openshift-image-registryなど
  5. Deploymentなどのマニフェストに記載されたイメージのタグを修正
  6. 「kubectl apply」相当の処理を実行してクラスタに反映
     • OpenShiftの場合「oc apply」

GitOpsで必要なリポジトリ

• Gitリポジトリとして、「アプリケーション」と「マニフェスト」用のリポジトリを用意
• マニフェスト用リポジトリ
  • クラスタにデプロイする全てのマニフェストを保管
  • 保存されたマニフェストが自動的にクラスタに適用される
  • マニフェスト用リポジトリの状態＝クラスタの状態
• アプリケーション用リポジトリ
  • アプリケーションのソースコードを保管
  • ソースコードに変更があると、CIによって以下が行われる
    • テスト
    • コンテナイメージのビルド
    • 新しいタグの付与
    • コンテナレジストリへのpush

GitOpsの流れ

1. 開発者がアプリケーション用リポジトリに変更をコミット
2. アプリケーション用リポジトリは、自動的にCI(継続的インテグレーション)実行
3. アプリケーション用リポジトリは、マニフェスト用リポジトリに対してイメージタグを変更するPR(Pull Request)を自動で送信
4. 開発者がPRをapproveすると、マニフェスト用リポジトリにてマニフェストの変更がマージされる
5. OpenShift上で動作しているDeploy Agent(Argo CDなど)が、マニフェスト用リポジトリに保管されたマニフェストを取得
6. 取得したマニフェストを適用

コンテナイメージのビルドにおけるTips

• 「コンテナイメージのビルド」とは、「アプリケーションのビルド」を実行し必要なパッケージなどを内包したコンテナイメージを作成すること
• このときビルドした実行ファイルをコンテナイメージにCOPYやADDするのではなく、「アプリケーションのビルド」自体もDockerfile内に記述するべき
• 実行環境に依存した影響を受けづらくなる

CIOps

• GitOpsに類似した概念としてCIOpsがある
• GitOpsと同じところ
  • 「アプリケーション」と「マニフェスト」用のリポジトリを用意して、それぞれでCIを実施すること
• GitOpsと違うところ
  • 「マニフェスト」用リポジトリに保管されているマニフェストをクラスタにデプロイする部分
  • CIOpsの場合
    • クラスタ外にあるJenkinsなどのCIツールでデプロイ実行
    • 具体的には「マニフェスト」用リポジトリに対してマージされたタイミングでCIジョブをトリガーし、マニフェストをフェッチしたあと、それらのファイルをクラスタに適用
  • GitOpsの場合
    • クラスタ上にDeploy Agentを配置し、「マニフェスト」用リポジトリからのマニフェストの取得とクラスタに対する適用を実行

CIOpsよりGitOpsが推奨されている理由

• CIOpsの提唱元「Weaveworks」はCIOpsをアンチパターンとし、GitOpsが推奨されている
• 理由はツールに与えるクラスタ操作権限の範囲を狭められるから
  • CIOpsの場合
    • クラスタへのデプロイを行う際に、CIツールがkubectlコマンドなどを利用して外部からクラスタに対してマニフェストの適用をする
    • そのため、CIツールにクラスタに対する強い権限の認証情報を持たせる必要があり、セキュリティ上の欠陥になる恐れがある
  • GitOpsの場合
    • クラスタに対してDeploy Agentを起動し、「マニフェスト」用リポジトリからマニフェストをPullして適用する
    • そのため、Deploy Agentには「マニフェスト」用リポジトリに対するRead権限のみ与えれば良いので、セキュリティリスクを下げることができる
• 一方で複数のクラスタを一元的に管理する場合など、CIOpsの方が適している状況もある
  • メリデメを考えて採択する必要がある

比較ポイント	GitOps	CIOps
デプロイ実行責任者	クラスタ上の Deploy Agent	外部CIツール（例：Jenkins）
権限の範囲	リポジトリへの Read 権限	クラスタへの管理権限全般が必要
セキュリティ	最小権限構成が可能	高い権限を CI ツールに付与する必要あり
運用の柔軟性	マニフェストのシンク実行に依存	CI スクリプトで任意フローを実装しやすい

参考文献

• Kubernetes完全ガイド 第2版 (Top Gear)
• Kubernetesの知識地図 —— 現場での基礎から本番運用