CI/CDにおける潮流 - CIOpsからGitOpsへ

昨今、もはや当たり前とも言えるCI/CD(継続的インテグレーション/継続的デプロイ)は、Kubernetesの世界でも当然必要な技術です。さまざまなツールが登場し、「それぞれどういった位置付けなのかわからない」というかたも多いのではないでしょうか。

そこで今回は、CI/CDツールについてGitOpsやIaC(Infrastructure as Code)など、さまざまな側面から紹介することで、位置付けをより深く理解していただきます。なお、個別のCI/CD系のツールの使い方などの詳細については次回以降紹介します。

標準化の動き- CDF(Continuous Delivery Foundation)

さまざまなCI/CDツール出てくるなかで、ツールに応じた記法を覚えるのは非常に大変なことでしょう。2019年3月12日にCDF(Continuous Delivery Foundation)の設立が発表され、CI/CDの標準化の動きが出てきました。

CDFには以下の4ツールが名を連ねています。パイプラインやソースへのアクセスなどを標準化し、CI/CDのベストプラクティスを構築していくことを狙っています。

• Jenkins：言わずと知れたCI/CDツールの元祖
• Jenkins X：JenkinsをgitとKubernetesの取り扱いに特化させ、自動構築の範囲を大幅に広げたもの
• Tekton：KubernetesのCRD(Custom Resource Definition)として実装されたCDツール
• Spinnaker： Netflixが開発したマルチクラウドに対応したCDツール

どんなツールがあるか

CDF以外にどんなツールがあるかをざっくりと把握するため、ここでは数あるツールのなかから筆者が特に注目しているツールをご紹介しましょう。

なお、「CIに強いツール」「CDに強いツール」といった具合に、各ツールが主眼とする領域は異なります。一方で、住み分けや交通整理が明確に行われているわけではありません。したがって、ツール間で機能重複する面もあります。

Kubernetesに対応しているCDツールは、多数存在します。

• パブクラ系
  • AWS Codeシリーズ：AWSのCI/CDツール

    CodeCommit/CodeBuild/CodeDeploy/CodePipelineの機能に分かれる

  • Azure DevOps Services：AzureのCI/CDツール

    Azure Repos/Pipeline/Artifactsに加え、カンバンによるタスク管理を行うAzure Boardsや、探索的テストを行うAzure Test Plansがある

  • Cloud Build：GCPのCI/CDツール
• CIに軸足
  • Circle CI：Saas型のCI/CDツール
  • GitHub Actions：GitHub上のCI/CDツール
• CDに軸足
  • ArgoCD：Kubernetes前提の宣言的CDツール
  • FluxCD：Kubernetes前提のGitOps Operator

CIOpsからGitOpsへ(CIとCDの分離)

これまでのCI/CDの問題点を解消するため、「GitOps」と呼ばれる考え方が登場しました。従来からのCI/CDである「CIOps」と対比するかたちで、権限と管理対象の2軸で説明します。

CIOpsの特徴は、以下の通りです。

◆権限：CIサーバに強い権限
JenkinsやCircle CIにデプロイまで任せるCIOpsの場合、本番環境へのアクセスなど、CIサーバに強い権限を与える必要がありました。CIサーバは一開発者もアクセスするため、細やかな権限管理が必要となります。何より、CIとCDの境界が曖昧になりやすくなります。

◆管理対象：アプリケーションコード中心
アプリケーションコードはGitで管理されていますが、デプロイに関わるスクリプトや、KubernetesマニフェストなどがGitで管理されていないケースもあります。

一方、GitOpsの特徴は以下の通りです。

◆権限：CIとCDの分離
CIサーバに強い権限を与えることを避けるために、CIとCDを分離することがうたわれています。アプリケーションコードを管理するCIサーバにはCircle CIを、Kubernetesのマニフェストを管理するCDサーバにはArgoCDをといった具合です。

◆管理対象：Single Source of Truth
「Single Source of Truth」と呼ばれる発想で、全てのものはコードとして管理します。IaC(Infrastructure as Code)が普及してきたことも後押ししています。

IaCとの関係

IaCは、以下の3レイヤに大別されます。CI/CDもIaCの一つと捉えることができます。

• IaaSレイヤ（狭義のIaC)
  • インフラレイヤ構築の自動化を行う、狭義のIaCはこのレイヤを指します。プロビジョニングは主にこの領域を指します。
  • 時系列に沿って、さまざまなツールが登場しています。

    Puppet(2005) → Chef(2009) → Ansible(2012) → Terraform(2014)

• コンテナレイヤ
  • コンテナをどのように作っていくかに主眼を置いたものです。本連載のKubernetesそのものも、こちらに含まれます。
    • コンテナ(例：Docker)
    • コンテナオーケストレーション(例：Kubernetes/Docker Compose)
    • コンテナオーケストレーションのオーケストレーション(例：Helm)

      Chart(設定ファイル)を作成することで、Kubernetesのリソース群を作成できます。

CI/CDレイヤ

• IaCの進展については、Jenkinsをベースに捉えておくと理解しやすいでしょう。
  • Jenkins 1.xの時代までは設定ファイルを直接書くことはあっても、積極的に勧められていたわけではありません。
  • Jenkins 2.xからは「Jenkinsfile」が登場し、IaCの要素を備えてきました。

*　*　*

今回はCI/CDについて説明しました。IaCの考え方はCI/CDの領域にも浸透してきており、GitOpsの前提となっています。マニフェストをGitで管理し、CIとCDを分離するGitOpsを中心に理解しておくとよいでしょう。 個別のツールの利用法については次回以降紹介します。