GitOps とは
GitOps とは、インフラストラクチャとアプリケーションの構成を管理するための一連のプラクティスです。既存のプロセスを拡張し、アプリケーションのライフサイクルを改善することを目的とします。
GitOps は、信頼できる唯一の情報源として Git リポジトリを使用して、Infrastructure as Code (IaC) を提供します。IaC は、手動のプロセスではなくコードを使用して、インフラストラクチャの管理とプロビジョニングを行う手法です。IaC では、インフラストラクチャ仕様を記述した構成ファイルが作成され、毎回必ず同じ環境がプロビジョニングされます。IaC は、DevOps プラクティスと継続的インテグレーション/継続的デリバリー (CI/CD) の実装に重要な役割を果たします。
GitOps ではシステムの望ましい状態を宣言的に記述する必要があります。宣言型ツールを使用することで、すべての構成ファイルとソースコードを Git でバージョン管理できます。コードの変更はすべて追跡されるため、アップデートが容易になると同時に、ロールバックが必要になった場合のバージョン管理も可能です。
GitOps が提供するもの
- アプリケーション開発のための標準的なワークフロー
- 可視性と監査可能性の向上によるセキュリティの強化
- Git が提供する可視性とバージョン管理による信頼性の向上
- クラスタ、クラウド、オンプレミス環境にわたる一貫性
GitOps、DevOps、プラットフォーム・エンジニアリング
GitOps と DevOps は、原則と目標を一部共有しています。DevOps は文化的な変化に関するものであり、開発チームと運用チームが連携する方法を提供します。
一方 GitOps は、組織がコラボレーション、CI/CD、バージョン管理などの DevOps プラクティスを採用し、それらをインフラストラクチャの自動化とアプリケーションのデプロイメント、さらには内部開発者向けプラットフォーム (IDP) などのプラットフォーム・エンジニアリング・プラクティスに適用するためのツールとフレームワークを提供します。
プラットフォーム・エンジニアリングは、標準化されたツール、サービス、ワークフローを提供することで DevOps の実践範囲を広げ、開発チームがソフトウェア・ソリューションをより効率的に構築できるようにします。プラットフォーム・エンジニアリングは比較的新しい用語で、社内のサービスとリソースを組織化することで、開発チームがこうした基盤要素を直接管理することなくソリューションを構築できるようにする手法を指します。
プラットフォーム・エンジニアリングは、組織全体に DevOps を拡大する際の課題に対応するための、不可欠かつ補完的な要素として発展してきました。プラットフォーム・エンジニアリング・チームは、組織の内部開発者向けプラットフォーム (IDP) を構築および維持し、継続的に進化させ、顧客である開発者チームに提供することで、共用の再利用可能なツール、サービス、機能をもたらして価値を生み出します。プラットフォーム・エンジニアは、ソフトウェア・アプリケーションの構築および提供に必要な組織のインフラストラクチャとバックエンドサービスを、スムーズなアクセスを必要とする開発チームに届けます。GitOps の中核的な原則には、インフラストラクチャの定義とアプリケーション開発ライフサイクルについて信頼できる唯一の情報源を確立して、プラットフォーム・エンジニアリングを支援することも含まれます。これをプラットフォーム・エンジニアリング・プラクティスに組み込むことで、チーム間のスムーズな連携と調整を実現できます。
Red Hat のリソース
GitOps を活用するべき理由
GitOps はプロセスの変更であるため、導入にあたり、チームが適応するまでに時間がかかる場合があります。GitOps では、新たなレベルのコラボレーションとコミュニケーションが求められます。フィードバック文化の育成は、そのための有効な手段となりますが、課題の発生を完全に回避することはできません。
こうした課題はあるものの、GitOps は、DevOps 文化に投資する人々に約束された理念とアプローチを引き継ぎ、成果を実現するためのフレームワークを提供します。
GitOps は、開発者が慣れ親しんでいる Git ベースのワークフローを使用することで、アプリケーションの開発からデプロイ、アプリケーションのライフサイクル管理、インフラストラクチャの構成に至るまで、既存のプロセスを拡張します。開発者は使い慣れたコードリポジトリで作業を行うことができ、一方、運用チームはインフラストラクチャの管理に同じツールと手法を導入できます。アプリケーションのライフサイクルを通じたすべての変更は、Git リポジトリで追跡され、監査が可能です。
Git を使って変更を加えることができるため、開発者は運用チームによるリソースの割り当てや承認を待つことなく、自分のペースでコードを書くことができるようになります。
運用チームにとっては、変更が可視化されることで、問題の追跡と迅速な再現が可能になり、全体的なセキュリティの向上につながります。最新の監査証跡があれば、企業は不要な変更のリスクを低減させ、本番環境での稼働の前に修正することができます。
このように、開発から本番稼働に至るまでのコードの変更により、組織はビジネスや競争環境の変化に俊敏に対応できるようになります。
GitOps ツールにはどのようなものがあるか
GitOps フレームワークを構築するために組み合わせて使用できるツールは多数存在し、たとえば Git リポジトリ、Kubernetes、継続的インテグレーション/継続的デリバリー (CI/CD) ツール、構成管理ツールなどが挙げられます。適切なツールの組み合わせを選択するため、開発者は自身のニーズと、その解決に必要な機能を明確にする必要があります。以下に、検討すべきツールをいくつかご紹介します。
CI ツール
継続的インテグレーション (CI) とは、コード変更を共有ソースコードリポジトリに自動的かつ頻繁に取り込む手法のことです。更新が行われると、マージされたコード変更の信頼性を確保するために、自動テストの手順がトリガーされます。
Tekton：CI/CD システムを構築するための Kubernetes ネイティブなフレームワークです。このフレームワークは、プラットフォーム・エンジニアや開発者に、クラウドプロバイダーやオンプレミスシステムにまたがるビルド、テスト、デプロイに必要な柔軟性、ベストプラクティス、標準化機能を提供します。
Jenkins：Java をベースとするオープンソースの自動化サーバーです。最小限のセットアップで、プロジェクトの継続的なテスト、ビルド、デプロイを簡単に実行できるため、開発者による変更の統合が容易になります。また Jenkins エコシステムの拡張機能である Jenkins X は、クラウド上での CI/CD パイプラインの自動化を支援します。
CD ツール
継続的デリバリーまたは継続的デプロイメント (CD) は 2 つの部分からなるプロセスで、コード変更の統合、テスト、デリバリーを指します。継続的デリバリーでは、CI でのビルドおよびユニットテストと統合テストの自動化に続いて、検証済みコードのリポジトリへのリリースが自動化されます。継続的デプロイメントは継続的デリバリーを拡張したものであり、リポジトリから本番環境への開発者による変更のリリースを自動化し、顧客が使用できるようにするというものです。
Argo CD：Kubernetes 向けの宣言型継続的デリバリーツールです。このツールにより開発チームは、Kubernetes に関する高度な知識や Kubernetes システムへのフルアクセス権限がなくても、アプリケーションのデプロイや管理が可能になります。実行中のアプリケーションを監視することで、ArgoCD はアプリケーションが望ましい状態から逸脱するのを防止します。
Flux：Git リポジトリとクラスタの状態を常に同期させることで、Kubernetes クラスタへのデプロイを自動化する GitOps ツールです。Kubernetes API 拡張機能セットをベースに構築された Flux は、アプリケーションのデプロイとインフラストラクチャ管理をサポートします。
GitOps の開始方法
GitOps を始めるには、宣言的に管理できるインフラストラクチャが必要です。このため、GitOps は Kubernetes およびクラウドネイティブ・アプリケーション開発の運用モデルとして使用されることが多く、Kubernetes の継続的デプロイメントを可能にします。
ただし、Kubernetes を使用することは GitOps の要件ではありません。GitOps は、他のインフラストラクチャおよびデプロイメント・パイプラインにも適用できる手法です。GitOps を使用して、開発パイプラインの構築、アプリケーションのコーディング、構成の管理、Kubernetes クラスタのプロビジョニング、Kubernetes またはコンテナレジストリへのデプロイメントを行うことができます。
GitOps ワークフローとは
GitOps は、インフラストラクチャ構成のバージョン管理システムとして Git を使用する、IaC の進化形と捉えることができます。インフラストラクチャ管理に関して、IaC は多くの場合、システムの望ましい状態を定義してシステムの実際の状態を追跡する宣言型アプローチを取ります。
IaC と同様に、GitOps ではシステムの望ましい状態を宣言的に記述する必要があります。宣言型ツールを使用することで、すべての構成ファイルとソースコードを Git でバージョン管理できます。
CI/CD パイプラインは通常、コードがリポジトリにプッシュされるなどの外部イベントによってトリガーされます。GitOps ワークフローでは、Git リポジトリの状態を修正するプルリクエストを使用して変更が行われます。
GitOps ワークフローを使用して新しいリリースをロールアウトするには、Git でプルリクエストを行います。それにより、クラスタの宣言された状態に変更が加えられます。GitOps Operator がコミットをピックアップし、Git から新しい状態の宣言をプルします。
変更が承認されてマージされると、ライブ・インフラストラクチャに自動的に適用されます。開発者は標準的なワークフローと CI/CD プラクティスを引き続き使用できます。これは、GitOps エンジンが CD の責任を担い、独立して機能することも、CI でオーケストレーションされるソリューションの一部として機能することも可能なためです。
Kubernetes で GitOps を使用する場合、オペレーターは通常 Kubernetes Operator になります。オペレーターは、リポジトリ内の望ましい状態を、デプロイされたインフラストラクチャの実際の状態と比較します。そして、実際の状態とリポジトリ内の状態の間に違いが検出される都度、インフラストラクチャとアプリケーションを更新します。
GitOps においては、可観測性、つまりシステムが観察可能であることが重要な概念となります。GitOps の可観測性により、望ましい状態と観測された状態 (実際の状態) が同じであることを確認できます。ただし GitOps は、デプロイしたリソースの可観測性を提供しますが、一般的な監視ツールとしては機能しません。その代わりに、包括的なツールセットである Red Hat® OpenShift® Observability が、メトリクス、ログ、トレース、イベントを使用して、こうした制約の克服と、アプリケーション・システムと Git リポジトリ間のフィードバックループの確立をサポートします。このように GitOps と OpenShift Observability を組み合わせることで、監視、分析、トラブルシューティングを通じて、アプリケーション・システムに関する知見を得られます。
プルリクエストと Git のようなバージョン管理システムを使用すると、デプロイメントプロセスに可視性がもたらされます。これにより、システムに加えられた変更を表示および追跡し、監査証跡を提供し、何らかの問題が起きた場合には変更をロールバックすることが可能になります。
GitOps ワークフローは、システムの安定性と信頼性を向上させながら、生産性を高め、開発およびデプロイメントを加速させることができます。
Red Hat による GitOps の支援
Red Hat は、GitOps ワークフローをサポートする幅広い製品を提供しています。 Red Hat OpenShift は、管理者が GitOps の原則に沿って構成および管理できる統合アプリケーション・プラットフォームであり、Kubernetes クラスタと開発ライフサイクル全体にわたる一貫性を実現します。Red Hat OpenShift は、オンプレミスおよびパブリッククラウド・リソースに分散されたアプリケーションの管理を統合し、以下を実行します。
- クラスタの状態 (構成、監視、ストレージ) が似ていることを確認し、開発サイクルの早い段階でアプリケーションの制約を知らせる。
- クラスタを既知の状態から回復させることで、複数のクラスタにまたがるコードの変更をロールバックする。
- Git に提出された変更を複数の Red Hat OpenShift クラスタにロールアウトする。
- テンプレート化された構成をハイブリッドクラウド全体で関連付ける。
Red Hat OpenShift GitOps は、Git リポジトリ、継続的インテグレーション/継続的デリバリー (CI/CD) ツール、Kubernetes を統合するワークフローを提供し、品質を損なうことなく、より高速で安全かつスケーラブルなソフトウェア開発を実現する Operator です。OpenShift GitOps を使用すると、宣言型の Git 駆動型 CD ワークフローを構築して、アプリケーション開発プラットフォームに直接統合できます。従来、CI/CD ツールは Jenkins や Tekton のような単一のツールでしたが、この場合は 2 つのツールが併用されます。すなわち CI には Jenkins や Tekton が使用され、CD エンジンの役割は GitOps が担います。Red Hat は ArgoCD などのオープンソース・プロジェクトと協力し、GitOps のためのフレームワークを実装しています。Red Hat OpenShift GitOps の Operator をインストールし、既存の Red Hat OpenShift デプロイメント内で GitOps を管理するために、Argo を使用して新しいツールを開発できます。
OpenShift GitOps は、クラウドサービス、セルフマネージド、エッジ・コンピューティングで利用可能です。Red Hat OpenShift Service on AWS (ROSA)、Microsoft Azure Red Hat OpenShift (ARO)、Red Hat OpenShift Dedicated (OSD) のようなマネージド・クラウドサービスは、組織の運用効率の向上、イノベーションへの再注力、アプリケーションの迅速なビルド、デプロイ、スケーリングを支援します。
Red Hat OpenShift Virtualization Engine のような OpenShift のセルフマネージド・エディションは、仮想マシン (VM) のデプロイ、管理、スケーリングに必要な、Red Hat OpenShift の仮想化機能を提供します。OpenShift GitOps は VM の自動デプロイをサポートしており、OpenShift Virtualization Engine と連携して、ユーザーの仮想化ニーズに基づく VM の移行と管理を支援します。エッジでは、MicroShift の Red Hat ビルドにより Kubernetes の性能とスケーラビリティがもたらされ、アプリケーションを一度記述すればそれが必要とされる場所、つまりデータソースやエンドユーザーのすぐ近くで実行できるようになります。
Red Hat Advanced Cluster Management for Kubernetes は、Kubernetes クラスタのライフサイクルのマルチクラスタ管理を提供します。Red Hat Advanced Cluster Management は、サブスクリプションとチャネルのフレームワークを配置ルールとともに使用して、複数のクラスタにわたり、望ましい状態のモデルにアプリケーションを自動的に配置します。Advanced Cluster Management for Kubernetes では、 GitOps エンジンとして OpenShift GitOps が使用されます。またアプリケーションセット、Argo インスタンス、GitOps クラスタ構成の管理に役立つ機能に加えて、デプロイポリシーを支援する機能も搭載されています。
Red Hat Ansible Automation Platform® は、現在の状態に関係なく、システムを望ましい状態にする作業を行います。YAML で作成される Ansible Playbook は、システムの望ましい状態を記述したもので、通常はソース管理で保持されます。Ansible は GitOps のワークフローの一部として非常に有益なツールです。Argo と GitOps は Kubernetes にしか関与しないため、Kubernetes 以外の領域の自動化、特に命令型アクションには Ansible が使用されます。Red Hat Advanced Cluster Management、Red Hat OpenShift GitOps、Red Hat Ansible Automation Platform の統合により、DevOps チームは、CI/CD パイプラインを改善するために構成を大規模に管理および維持することができます。
Red Hat 公式ブログ
Red Hat のお客様、パートナー、およびコミュニティのエコシステムに関する最新の情報を入手しましょう。
