「Kubernetes Native」なCI/CDとは何か――クラウドネイティブ時代に至る歴史、主要ツール、パイプラインとフローの在り方：Cloud Nativeチートシート（5）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Kubernetesの利用を前提とした「Kubernetes Native」なCI/CDについて踏み込んで説明します。

[山田真也, 正野勇嗣, 岡本隆史，株式会社NTTデータ]

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回紹介するのは、CI/CD（継続的インテグレーション／継続的デリバリー）です。中でもKubernetes（以下、k8s）の利用を前提とした「Kubernetes Native」なCI/CDについて踏み込んで説明します。

　多種多様なCI/CDツールが存在する中、どういった軸で理解すればいいか分からない方もいることでしょう。以降、CI/CDに関する歴史と背景を踏まえ、CI/CDに具備すべき機能がどういったものかをツールの比較と動向も交えて解説します。

歴史と背景〜Kubernetes NativeなCI/CDに至るまで〜

　CI/CDの進化の歴史と背景を以下の4ステップで紹介します（図1）。CIとCD、アプリケーション（AP）層と基盤層に分けてCI/CDを理解していきましょう。

1. CIからCI/CDへ
2. 基盤層：オンプレからクラウド、コンテナ（そしてk8s）へ
3. AP層：モノリスからマイクロサービスへ
4. CIOpsからGitOpsへ

図1　CI/CDの進化の歴史

1.CIからCI/CDへ

　読者の皆さんは、今や当たり前になったCI/CDやDevOpsというキーワードをどのように捉えていらっしゃるでしょうか。「Jenkins」（Hudson）が出てきた当初、CIはコンパイルやテストが中心でしたが、デプロイの重要性が徐々に増してきました。すると、実態に合わせる形でCIではなく「CI/CD」というようになってきました。

	内容	コマンド
CI	・コンパイル ・テスト ・パッケージ	「Apache Maven」によるコマンド例 ・mvn compile ・mvn test ・mvn package
CD	・デプロイ	CLIによるデプロイ例 ・ftp（ファイル配置） ・curl（「Apache Tomcat」へのデプロイ）

　また、この頃の特徴的な進化はパイプライン機能でしょう。パイプライン機能は、Aジョブ→Bジョブ→Cジョブのようなビルドやデプロイの一連の流れを定義する機能です。バッチ機能の開発に携わったことがある方なら、ジョブネットを想像してもいいでしょう。

　パイプライン機能が登場する以前、CIが出始めのJenkins 1.xの頃は、JenkinsのMavenジョブを数珠つなぎで頑張ってつないできた時代がありました。パイプラインが普及し便利になったなと感じます。

2.基盤層：オンプレからクラウド、コンテナ（そしてk8s）へ

　オンプレミスの時代は、仮にCI/CDやDevOpsにより全自動化を目指そうとした場合に、以下のさまざまな層（レイヤー）を意識する必要がありました。

• AP：Javaのwarファイルをデプロイ
• ミドルウェア：Tomcatや「Oracle WebLogic」といったアプリケーションサーバ、「MySQL」「Oracle Database」などのRDBMSの設定
• OS:ファイルシステムへの設定ファイルなどの配置

　仮想化やクラウド化が進展し、これらAP／ミドルウェア／OSの設定はコンテナやクラウドリソースに代替されるようになりました。つまり、CI/CDツールが直接意識するのはコンテナやクラウドリソースに集約され、1段抽象化されたレイヤーでの管理が可能になります。

　さらにはk8s、つまりコンテナオーケストレーションが出てくると、これらコンテナやクラウドリソースはk8sのマニフェストに代替されます。つまり、CI/CDツールが直接意識するのはマニフェストに集約され、さらに1段階抽象化されたレイヤーでの管理が可能になります。

　もちろん、「全てがマニフェストによる管理になる」とまでは言い切れませんが、より抽象化、集約化されたレイヤーにおいてテキストベースで管理することが可能となります。また、IaC（Infrastructure as Code、システムリソースのコード化）の実現が容易となります。

図2　集約化、抽象化された管理

3.AP層：モノリスからマイクロサービスへ

　DX（デジタルトランスフォーメーション）の時代においては、高頻度でのサービスのリリース要求が高まっています。下支えする技術として、クラウドやアジャイル、マイクロサービスといったものが挙げられます。アプリケーションの単位はモノリスの時代より小さくなり、より柔軟なリリースが可能となります。

　具体的には、リリースの範囲が小さなマイクロサービスの範囲に限定され、昨今当たり前となってきているCI/CDにまつわるさまざまなベストプラクティスが適用しやすくなっています。

• A/Bテスト
• Blue/Greenデプロイ
• カナリアリリース

　一方で、アプリケーションがサイロ化しやすくなり、個別のマイクロサービスの障害がシステム全体の障害につながったり、システム全体の動きが見えづらくなったりします。さらにはシステムの挙動が複雑化するので、品質確保のためのテストについてもこれまで以上の工夫が必要となります。

• システム全体の障害の防止：サーキットブレーカー
• 品質確保：カオスエンジニアリング、Contract Tests
• 見える化：分散トレーシング、ロギング

4.CIOpsからGitOpsへ

　最近は「GitOps」という概念も出てきており、CD領域に「ソフトウェア開発の技法」が取り込まれてきています。

　これまで、CIツールがビルドからデプロイまで一括して実施してきました（「CIOps」と呼びます）。一方で、GitOpsでは、デプロイをCDツールに任せ、CIツールはビルド部分に専念します。

図3　CIOpsとGitOpsの違い

　k8sでGitOpsを実現する際のポイント、特徴として、下記4点が挙げられます。いずれもソフトウェア開発でよく使われる技法です。

• 委譲
• 宣言的プログラミング
• Single Source of Truth（イベントリスナ）
• DRY

　なお、少し軸がずれますが「ChatOps」という、開発者のフロントにチャットツールを置くような考え方も出てきており、CI/CDやDevOpsの世界は極めて多様な進化を遂げています。

　以降、上記4点について、それぞれ解説します。

・委譲

　GitOpsでは、CDツールに処理を委譲するので、セキュリティ面と複雑性の回避の観点でメリットがあります。

　まず、セキュリティ面です。CIOpsの世界では、Jenkinsや「CircleCI」など、1つのCIツールを利用して回帰試験〜ビルド〜デプロイまで行います。このように利用している方は多いのではないでしょうか。しかしながら、このようなCI/CDスタイルでは、CIツールに環境にデプロイ（k8sのAPIを実行）するための権限、クレデンシャルを設定する必要があり、セキュリティ面でのリスクが生じてしまいます。GitOpsでは、k8sクラスタ上にCDツールが配備されるので、クレデンシャルがクラスタ内で管理でき、セキュリティのリスクをなくすことができます。

　次に、複雑性の回避です。CIOpsでは、さまざまな環境にデプロイが必要になってくると、CIツールの設定が複雑になり、メンテナンスが大変になると思います。GitOpsでは、さまざまな環境にデプロイが必要になっても、各環境内にあるCDツールに対して同一Gitリポジトリを監視するだけでいいので、複雑性も増加しにくくなります。

・宣言的プログラミング

　k8sの最大の価値は、挙動の定義ではなく状態（ToBe）の定義が可能な点です。デプロイや障害からの復旧などを全て挙動として定義していたら、状態に応じた挙動の定義（if/elseのような分岐）が必要になり、設定が非常に複雑になります。

　状態（ToBe）を「宣言的」にマニフェストファイルで定義することで、最終的にあるべき状態の定義に全集中できます。また、マニフェストファイルをそのままGitリポジトリで管理できるので、Gitとも高い親和性があります。

・Single Source of Truth（イベントリスナ）

　自動構築されたサーバに対して個別に暫定対処し、その後、戻し忘れた経験はないでしょうか。いわゆる「Configuration Drift（構成の逸脱）」という状態です。この状態を避けるためには、構成をユーザーに勝手に変更させないImmutable Infrastructureを徹底することが重要です。

　Immutable Infrastructureを実践するには、k8sのマニフェストをGitリポジトリで管理してGitリポジトリに保存されたマニフェストを「Single Source of Truth（唯一の信頼できる情報源）」とし、デプロイされた状態を常にGitリポジトリと同期させた状態に保ちます。

　「ArgoCD」「Flux2」といったツールはSingle source of Truthやイベントリスナによるソースと環境の同期の思想がビルトインされており、ユーザーが意識せずにImmutable Infrastructureを実践できるようになっています

・DRY（Don't Repeat Yourself）

　同じような定義をコピー＆ペーストで複製して変更のたびに複製した設定ファイル全てに修正が入ると、生産性が下がるばかりか品質を保証するのが難しくなります。例えば、開発環境と商用環境のマニフェストファイルを別々に管理すると、一方のファイルを更新した際にもう一方のファイルに修正点を反映する必要があるなど、管理が煩雑になります。

　DRYは、「同じ内容の記述は、共通化などによって、複数持たない」という思想で実践することにより、CI/CDをシンプルに保つことができます。

　連載第2回で紹介した「Kustomize」などのツールはDRYの思想がビルトインされており、ユーザーが強く意識せずともDRYの恩恵を受けることができます。

CI/CDツールの比較

　前節の内容を踏まえ、代表的なツールを比較します（図4）。