「GitOps」を活用して、アプリケーションを効率的かつ自動的にデプロイする

はじめに

前回は「CI(継続的インテグレーション)」と「CD(継続的デリバリー)」、そして、それらを実行する「CI/CDパイプライン」について解説しました。今回は、CI/CDに続いて行う「デプロイ」について解説します。

リリースとデプロイの違い

最初に「デプロイ(Deploy)とは何か」をしっかり理解しておきましょう。デプロイとは「展開する」や「配備する」といった意味を持つ英単語です。ITの文脈ではアプリケーションをサーバーに展開し、実際に利用可能な状態にすることをデプロイと呼んでいます。

デプロイと似た用語に「リリース」もありますが、「アプリケーションをデプロイする」と「サービスをリリースする」には明確な違いがあります。デプロイは「サーバー上でアプリケーションが動く状態にすること」を指します。対してリリースは「エンドユーザーにサービスを解放すること」を指します。つまりデプロイが完了し、アプリケーションが起動していたとしても、リリースしない限りユーザーはサービスを利用できません。

具体的な作業を例に挙げると、デプロイは「docker pull」コマンドでコンテナイメージをダウンロードしたり、「docker run」コマンドでコンテナを起動したりといった作業などが該当します。一方のリリースは、ロードバランサーやDNSレコードの向き先を切り替え、デプロイしたアプリケーションにトラフィックをルーティングする作業などが該当します。

デプロイとリリースは同時に行われることも多いため、あえて区別する必要がない場合も多く、そのせいで混同している人もいるでしょう。しかし、この2つは意味合いが異なるため区別して考えられるようにしましょう。デリバリー、デプロイ、リリースの違いを下表にまとめました。

CIOpsとGitOps

それでは、実際のデプロイ作業について見ていきましょう。DevOpsにおいてデプロイに必要な設定情報はすべてコード化され、Gitにより管理されているのが基本です。そしてツールでこの設定を適用し、実際にデプロイを行うわけです。例えばコンテナオーケストレーションとしてKubernetesを採用している環境であれば、アプリケーションを動かすためのマニフェストを作成し、「kubectl apply」コマンドを実行してデプロイを行います。

このデプロイ作業には、大きく「Push型」と「Pull型」の2つのアプローチが存在します。

Push型のアプローチは、CIツールを使ってCI/CDパイプラインの延長上でデプロイを行います。コードの変更をトリガーとし、CI/CDのワークフローの最後に承認を挟んでデプロイが行われます(前回解説した通り、CI/CD(デリバリー)では自動的なデプロイまでは行わないため、デプロイ作業前に担当者の承認を挟むといったフローが一般的です)。この方式を特に「CIOps」と呼びます。下図は、典型的なCIOpsの流れを表したものです。見ての通り、非常にシンプルで直感的な構成になっています。

CIOpsの模式図

CIOpsはシンプルな反面、デメリットもあります。CI/CDパイプラインが強力な権限を持ちすぎてしまうという点、そしてCIとデプロイを分割できないという点です。

デプロイは本番サーバー上にアプリケーションを展開する作業です。そのため、CIOPsを行う際には本番環境を操作する権限をCI/CDパイプラインに持たせる必要があります。外部のツールにこうした権限を持たせるのは、それだけでセキュリティリスクとなる可能性があります。またCI/CDパイプライン内のジョブでは任意のコマンドを実行できるため、パイプラインの実装ミスによって本番に障害が起きるといった可能性も否定できません。

CIOpsでは、CIからデプロイまでを1つの流れとして実行します。つまりCIとデプロイを分割できないのです。これは、開発とデプロイを別の組織で行いたい場合に問題となります。具体的な例を挙げると、アプリケーションは協力会社が作成し、成果物はコンテナイメージをレジストリにpushする形で納品されます。そしてデプロイは別途、自社の都合の良いタイミングで行いたいというケースです。こういうケースでは、開発時に繰り返し行うCIと、最終的なデプロイが単一のパイプラインで構成されていると非常に扱いづらいものになってしまいます。

また、CIOpsはPush型であるため、いわば「投げっぱなし」のデプロイを行います。CIツールはデプロイコマンドを実行しますが、その結果やデプロイ後のアプリの状態については関与しないのです。

そこで最近注目されているのが、専用のデプロイエージェントを用いたPull型のデプロイです。その基本的な流れは下図のようになります。

GitOpsの模式図

こうしたデプロイ方式は「GitOps」と呼ばれています。GitOpsは、2017年に英Weaveworks社が提唱したデプロイ手法です。GitOpsではシステム全体のコンフィグが宣言的に記述され、すべてがGitの管理下に置かれます。そして、このGitリポジトリを唯一の信頼できるソースとして扱うことが名前の由来となっています。

GitOpsでは、デプロイのためのコンフィグをアプリケーションのコードとは別リポジトリに格納するのが一般的です。本番環境内に構築されたデプロイエージェントがこのリポジトリの変更を監視しており、変更がマージされると自動でデプロイを行います。これがPull型の所以です。CIOpsと異なり、外部のCIツールが本番環境にアクセスする必要がないため、CI/CDパイプラインに強い権限を持たせる必要がなくなります。

また、見ての通り、従来のCI/CDパイプラインとデプロイ処理は別のツールによって行われるため、責任分界点をはっきりさせることができます。さらにデプロイエージェントが本番環境内にいるため、デプロイ後のアプリケーションの状態までも管理できます。

まずDevOpsを始めるのであれば、最初はシンプルなCIOpsでも問題はないでしょう。しかしプロジェクトがスケールするに従い、CIとデプロイの分離が必要になるタイミングが必ず訪れます。こうした理由から、GitOpsが注目され始めているというわけです。

GitOpsを実現するツール

GitOpsワークフローを実現するためには、Gitリポジトリを監視し、デプロイを行うエージェントをセットアップする必要があります。こうしたGitOpsツールとしてメジャーなのが「Argo CD」と「Flux」です。

Argo CDは、それ自体がKubernetesクラスター内にデプロイされるアプリケーションです。デプロイしたいアプリケーションのソースとなるGitリポジトリとデプロイ先を登録することで、GitOps的なデプロイを可能にします。

Argo CDのアプリケーション登録画面の例。アプリケーション(ここではHelmチャートで提供されている)のソースとなるGitリポジトリと、デプロイ先のクラスターとNamespaceを設定すれば良い

実際にアプリケーションをデプロイさせた状態。ソースやバージョンをはじめ、アプリケーションとデプロイに関する様々な情報が表示される

Argo CD自体がクラスター内にいるため、アプリケーションを構成する様々なリソースの状態も管理できる。Push型のデプロイでは実現できない特徴の1つ

ドキュメントを見るとわかる通り、Argo CDはKubernetesクラスターにマニフェストを適用するだけで簡単に始めることができます。CLIのクライアントはもちろん、WebベースのGUIインターフェイスも備えているため、初めてでも使いやすいGitOpsツールと言えるでしょう。

FluxもArgo CDと同様に、Kubernetesクラスター上で動作するGitOpsツールです。もともとGitOpsの提唱元である英Weaveworks社が開発したという出自を持つため、GitOpsの本家本元と言っても良いツールです。Fluxには大きくバージョン1とバージョン2が存在し、現在ではゼロから再設計されたFlux v2が使われています。

おわりに

GitOpsを採用することで、クラスター内にアプリケーションを効率良く、自動的にデプロイできます。また従来のCIOpsによるデプロイとは異なり、システムの状態が宣言的に記述されたコードと一致することが保証されます。まずはこれらのツールを使い、GitOpsによるデプロイを体験してみると良いでしょう。