GitOps とは

これまでに登場してきた考え方や手法から発展および誕生してきた多数の用語と同様、「GitOps」という用語に決定的な意味を定義するのは少々困難です。

GitOps は、Martin Fowler が 2006 年に総合的な概要を示した継続的インテグレーションの概念に端を発するワークフローで、その系譜はサイト信頼性エンジニアリング (SRE)、DevOps 文化、Infrastructure as Code (IaC) パターンにつながっています。GitOps の独自性は、大規模で高度な分散型のクラウドネイティブ・システムのデプロイと管理に効果的な経験と知識に基づく Infrastructure as Code の規範的スタイルであるという点です。つまり、インフラストラクチャをコードのように扱える git 中心のワークフローを実装できるのですが、それがGitOps という訳ではありません。

GitOps という用語は Weaveworks の CEO 兼創立者の Alexis Richardson 氏が生み出したもので、ここで取り上げる GitOps の定義も Alexis と Weaveworks の説明を直接流用しています。概念を説明するこの初回のブログ記事では、基本となる考え方を示しますが、手短な定義はしていません。この用語の説明は人によって異なります。

さまざまな説明を見たり聞いたりするうちに、以下の定義が GitOps の多数の説明の本質を捉えていると思うようになりました。

[GitOps] は、Git を宣言的インフラストラクチャおよびアプリケーションの一元化ソースとして使用して機能する

-- Weaveworks、「Guide To GitOps」

イミュータブルなアーキテクチャ、具体的には Kubernetes クラスタ管理を GitOps の属性であるという記述をよく見かけます。この説明はあまりに規範的で限定的であると思います。イミュータブルなアーキテクチャと Kubernetes は、可能ならばアプリケーションとサービスのデプロイ方法に取り入れるべきです。これで確かに GitOps ワークフローを効率的に実装しやすくなります。しかしここでは GitOps の要件ではなく、推奨事項や好みとして扱います。その理由を説明しましょう。

この図は代表的な GitOps ワークフローがどのようなものか、概念レベルで示しています。デリバリーパイプラインを自動化して、git リポジトリで変更が行われると、変更をインフラストラクチャにロールアウトします。

GitOps によって生産性とデプロイおよび開発の速度が向上することがわかっています。開発者は使い慣れているツールとワークフローを使用してデプロイを管理できるので、新しく加わった開発者もすぐにスピードを出せます。Git は従来開発者ツールでしたが、Git コミュニティの蓄積された知識と経験や、エコシステムの成熟度は、運用スタッフにとってもメリットになります。初心者が Git を手軽に使いやすくするような既存ツールはあふれるほどあります。

GitOps を使用すると、デプロイと運用が開発プロセスおよびツールと一体化され、組織内で一貫した作業を行う手段となります。

Git バージョン管理によってインフラストラクチャの状態が定義され、すべてのアクティビティについて便利な監査ログを完備しているので、GitOps ワークフローを実装すると安定性と信頼性が向上します。どのような変更がいつ起きたかを追跡できるので、コンプライアンスの順守に役立ちます。Git ツールは暗号機能とのセキュリティの保証を強化し、これらの変更と署名を追跡して発行元を証明します。障害が発生した場合、元に戻して容易に以前の状態にロールバックしたり、障害から復旧するために必要ならばシステムをリビルドできます。

Ansible による GitOps

前回は、Git 中心の Infrastructure as Code (IaC) デプロイワークフローを、Automation Webhook の機能によって Ansible Tower で作成する方法を見てきました。GitOps は IaC のより規範的なワークフローですが、概念としてはこの図のようになっています。

Red Hat Ansible Automation Platform を使用する際に、標準的な GitOps パイプラインとは異なる点がいくつかあります。

ここでは、Ansible Tower は GitOps の「エージェント」(Operator) の代わりとなり、所定のクラスタ上で実行され、Git から構成 (状態) を引き出します。 通常、これらは Flux や Eunomia といった Kubernetes Operator です。

Ansible Tower は Kubernetes クラスタ上で実行される Operator と連携して、プッシュ/プルのアプローチを実施します。Ansible Tower は Custom Resource (CR) を通じて構成を Operator にプッシュし、Operator はあらゆるコンテナイメージをレジストリからプルして、必要なあらゆるセットアップを処理します。この Operator は特定の Kubernetes アプリケーションまたはサービス向けに作成されたもので、GitOps パイプライン以外でも使えます。GitOps を使いやすくするためにクラスタのすべての構成と管理を行うために作られたものではありません。

Ansible には、GitOps ワークフローの原則を、パブリック/プライベートクラウド・サービスやネットワーク・インフラストラクチャなど、 Kubernetes 以外のシステムに適用する柔軟性も備わっています。そのインフラストラクチャ上で Operator「エージェント」を使用する必要がないからです。

Ansible を使用するメリット

GitOps パイプラインで使用できるツールは多数ありますが、Ansible には、これらのワークフローにとって最適で、Kubernetes やクラウドネイティブ・システム以外でも使用できるように拡張する、他にはないメリットがあります。

• Kubernetes 以外での GitOps：Kubernetes と同様に、Ansible は目標状態エンジンで、Ansible Role と Playbook によって、従来の IT システムを宣言的にモデリングできます。スクリプトの作成は不要です。k8s モジュールおよびその他多数のモジュールにより、Ansible ユーザーは Kubernetes 上、既存の IT インフラストラクチャ上、またはその両方で、アプリケーションを 1 つのシンプルな言語で管理できます。
• エージェントレス GitOps：Ansible を使用する場合、システムで目標状態を調整する特殊な GitOps Operator (エージェント) は不要です。
• 柔軟性と自由：ニーズに最適なツールを使用して、目的の機能に合うようにパイプラインを調整できる柔軟性と自由もあります。Ansible は IT 自動化の接着剤の役割としても優れています。
• 既存のスキルとエコシステム：その実績により信頼されている Ansible ツールを使用して、新規と既存の両方のプラットフォーム上でアプリケーションを自動化してオーケストレーションでき、チームはスキルを学習しなくても移行できます。

Ansible をこのドメインで使用するメリットは、これだけではありません。Ansible をクラウドネイティブの Kubernetes 環境で使用するメリットは多数あります。

まとめ

GitOps は、Git を宣言的インフラストラクチャおよびアプリケーションの一元化ソースとして使用して機能します。その概念の系譜はサイト信頼性エンジニアリング、DevOps 文化、Infrastructure as Code (IaC) パターンにつながるワークフローです。GitOps は、大規模で高度な分散型のクラウドネイティブ・システムのデプロイと管理に効果的な経験と知識に基づく、規範性の高い IaC のワークフローです。

Red Hat Ansible Automation Platform を使用して GitOps パイプラインを実装すると、独自のメリットが実現します。Automation Webhook 機能を Ansible Tower で活用すると、クラウドネイティブ・システムだけではなく、クラウドサービスやネットワークギアなどの IT インフラストラクチャを管理する、エージェントレス GitOps ワークフローを実装できます。Ansible を使用すると、既存の Ansible エコシステムを利用でき、目的の機能に最適なツールを使用する柔軟性と自由も手に入ります。

GitOps を Ansible で試してみて、組織に対するメリットと能力をご確認ください。