GitOps ワークフローとは

GitOps は、インフラストラクチャとアプリケーションのライフサイクル全般を、信頼できる唯一の情報源である git リポジトリを通じて管理する、ソフトウェアの開発およびデプロイメントにおける先進的アプローチです。このワークフローでは、開発者がコード変更やインフラストラクチャ設定を git リポジトリにコミットすると、git リポジトリの状態に応じてアプリケーションやインフラストラクチャの変更を構築、テスト、デプロイする自動化された CI/CD パイプラインがトリガーされます。

運用担当者および管理者は、Git に保存された宣言型の設定ファイルを使って望ましいインフラストラクチャの状態を定義し、Argo CD などの継続的同期ツールを使用してライブ環境が git リポジトリと一致するようにします。これにより、コードとインフラストラクチャの両方でバージョン管理、コラボレーション、監査が可能となり、ひいては効率的で信頼性の高いソフトウェア提供とインフラストラクチャ管理につながります。

以前は手動で行われていたプロセスに自動化を導入することで、クラスタ設定とアプリケーションのデプロイを管理できるようになります。たとえば、GitOps は、マルチクラスタ Kubernetes 環境において Red Hat® OpenShift® Container Platform クラスタを管理するために役立ちます。

これらの機能により、パブリッククラウド、プライベートクラウド、さらにはオンプレミス環境間でワークロードを移行する際の一貫性、セキュリティ、コラボレーションの必要性など、マルチクラウド・アプローチに伴う課題を軽減することができます。

この記事では、GitOps ワークフローの基本を説明します。

GitOps では、git リポジトリがシステム設定とアプリケーション設定の信頼できる唯一の情報源です。環境のインフラストラクチャの宣言的記述で構成されており、Argo CD などの GitOps ツールが処理する自動プロセスと連携して動作します。この自動化によって、環境の実際の状態が記述された状態に一致します。Git 履歴には変更追跡機能があるため、リポジトリを使用してシステムの状態に対する変更のリストを表示することもできます。

さらに、インフラストラクチャと設定をコードとして保存すると、スプロールを軽減できます。クラスタとアプリケーションの設定をコードとして git リポジトリ内に保存することができます。 

IaC (Infrastructure as Code) は、手動のプロセスではなく、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います。

IaC を使用すると、インフラストラクチャ仕様を含む設定ファイルが作成されます。これにより、設定の編集や配信が容易になると同時に、常に同じ環境がプロビジョニングされるようにすることができます。IaC は、設定仕様を体系化および文書化することにより構成管理を支援し、構成が文書化されることなくアドホックに変更されないようにします。IaC へのアプローチには、宣言型と命令型の 2 つの方法があります。

宣言型アプローチは、必要なリソースや備えておくべきプロパティといった、システムの望ましい状態を定義するもので、構成は IaC ツールが行います。宣言型アプローチでは、システムオブジェクトの現在の状態に関するリストも保持されます。それに対して、命令型アプローチは、望ましい設定を実現するために必要な特定のコマンドを定義するものであり、それらのコマンドは正しい順序で実行される必要があります。

多くの IaC ツールは宣言型アプローチを使用しており、目的のインフラストラクチャを自動的にプロビジョニングします。望ましい状態に変更を加えると、宣言型の IaC ツールの場合、その変更はツールによって適用されます。命令型のツールの場合は、これらの変更の適用方法をユーザーが見極める必要があります。

IaC は、DevOps プラクティスと継続的インテグレーション/継続的デリバリー (CI/CD) の実装に重要な役割を果たします。IaC によって、開発者によるプロビジョニング作業の大部分が不要になり、開発者は、スクリプトを実行してインフラストラクチャを準備することができます。これにより、インフラストラクチャが利用可能になるまでアプリケーションのデプロイを待つことはなくなり、システム管理者が時間のかかる手作業のプロセスを管理することもなくなります。

CI/CD は、統合、テスト、提供、デプロイへと至るアプリケーションライフサイクル全体を通じて継続的な自動化と継続的な監視に依存しています。
IaC を使った DevOps アプローチを通じて開発チームと運用チームを連携させることで、エラー、手動のデプロイ、不整合が少なくなります。

GitOps は、インフラストラクチャ構成のバージョン管理システムとして Git を使用する IaC (Infrastructure as Code) における進化と見なすことができます。 

パイプラインは、コードのビルド、テスト、デプロイの過程でソフトウェア開発を推進するプロセスで、継続的インテグレーションおよび継続的デリバリー/デプロイメント (CI/CD) としても知られています。パイプラインを自動化することにより、ヒューマンエラーを最小限に抑え、ソフトウェアのリリース方法に関して一貫したプロセスを維持することが目的です。パイプラインで使用されるツールには、コードのコンパイル、ユニットテスト、コード分析、セキュリティ、バイナリー作成などがあります。コンテナ化された環境の場合、このパイプラインには、ハイブリッドクラウド全体にデプロイされるコンテナイメージへのコードのパッケージ化も含まれます。

CI/CD は DevOps 手法のバックボーンであり、ソフトウェアのデプロイにあたり開発者チームと IT 運用チームを 1 つのチームとして機能させます。カスタムアプリケーションは今や企業の差別化の鍵であり、コードをどれだけ迅速にリリースできるかが競争上の差別化要因になっています。

CI/CD パイプラインは通常、コードがリポジトリにプッシュされるなどの外部イベントによってトリガーされます。GitOps ワークフローでは、Git リポジトリの状態を修正するプルリクエストを使用して変更が行われます。

GitOps ワークフローを使用して新しいリリースをロールアウトするには、Git でプルリクエストを行います。それにより、クラスタの宣言された状態に変更が加えられます。GitOps パイプラインとオーケストレーション・システムの間に位置する GitOps オペレーターは、Git からコミットを取得して新しい状態の宣言をプルします。

変更が承認されてマージされると、ライブ・インフラストラクチャに自動的に適用されます。開発者は、標準のワークフローと (CI/CD) のプラクティスを引き続き使用できます。

Kubernetes でワークフローに GitOps を使用する場合、オペレーターはたいてい Kubernetes Operator になります。

Kubernetes Operator は、Kubernetes アプリケーションをパッケージ、デプロイ、管理する手段です。Kubernetes Operator は、Kubernetes API の機能を拡張したアプリケーション固有のコントローラーで、Kubernetes ユーザーに代わって複雑なアプリケーションのインスタンスを作成、設定、管理します。Kubernetes のリソースとコントローラーの基本コンセプトをベースに構築されていますが、ドメインまたはアプリケーション固有の知識を含み、管理対象のソフトウェアのライフサイクル全体を自動化します。

GitOps における Kubernetes Operator は、リポジトリ内の望ましい状態を、デプロイされたインフラストラクチャの実際の状態と比較します。そして、実際の状態とリポジトリ内に存在するものの間に違いが見られるたびに、インフラストラクチャを更新します。また、コンテナ・イメージ・リポジトリを監視し、同じ方法で更新を行って新しいイメージをデプロイすることもできます。

可観測性とは、システムやアプリケーションの出力、ログ、パフォーマンス指標を調べることにより、その状態を監視、測定、理解する能力を指します。先進的なソフトウェアシステムやクラウド・コンピューティングでは、アプリケーションやインフラストラクチャの信頼性、パフォーマンス、セキュリティを確保するために、可観測性がますます重要な役割を担うようになっています。

可観測性は、従来の監視システムを統合および拡張し、チームが問題の根本原因を特定できるようにします。可観測性によりステークホルダーは、アプリケーションやビジネスに関する質問に答えられるようになり、潜在的な問題についての予測や予想も可能になります。

可観測性のメリット

• 信頼性の向上：問題が拡大する前に検出し、解決することで、ダウンタイムを最小限に抑えてユーザーが利用できるシステムを維持できます。
• トラブルシューティングの効率化：システムの動作に関する深い知見を得ることで、問題の根本原因を素早く特定し、効率的に解決できます。
• パフォーマンスの最適化：システム内のボトルネックや十分に活用されていないリソースなど、最適化すべき領域を特定し、より効率的なリソース配分とパフォーマンスの向上を可能にします。
• データ駆動型の意思決定：最新のシステムパフォーマンスと動作情報を入手し、データ駆動型の意思決定と継続的な改善を可能にします。

Red Hat® OpenShift® Observability は、可観測性のツールとテクノロジーをつなぎ、統一された可観測性エクスペリエンスを実現することで、先進的なアーキテクチャの複雑性を解決します。このプラットフォームは、システムのさまざまなメトリクス、ログ、トレース、イベントをリアルタイムで可視化、監視、分析し、アプリケーションやエンドユーザーに影響が及ぶ前に問題を迅速にトラブルシューティングできるよう設計されています。

Red Hat OpenShift GitOps は、Argo CD インスタンスのインストールと設定を行う Operator です。インフラストラクチャの設定とアプリケーションのデプロイを管理し、これらの設定リポジトリを中心にデプロイプロセスを編成します。常にこのプロセスの中心となるリポジトリとして、ソースコードが含まれるアプリケーション・リポジトリとアプリケーションの望ましい状態を定義する環境設定リポジトリの少なくとも 2 つがあります。

クラスタリソースを維持するために、Red Hat OpenShift GitOps は、アプリケーションの継続的インテグレーションおよび継続的デプロイメント (CI/CD) の継続的デプロイメントの部分に対応するオープンソースツールである Argo CD を使用します。Argo CD は、git リポジトリで定義されているように、アプリケーションの状態の記述と設定を監視することにより、Red Hat OpenShift GitOps のコントローラーとして機能します。定義された状態と実際の状態を比較し、指定の記述から逸脱する設定をすべて報告します。

管理者は、これらの報告に基づいて、設定を定義された状態に再同期することができます。再同期は、手動で行うことも自動化することもできます。自動化の場合、設定は基本的に「自己修復」されます。

つまり、Red Hat OpenShift GitOps は、開発者がコードや設定の変更を git リポジトリにコミットすると、それが自動化された CI/CD パイプラインをトリガーするという最適な GitOps ワークフローを促進します。CI/CD パイプラインは、git リポジトリの状態に基づいてアプリケーションとインフラストラクチャの構築、テスト、デプロイを実行します。このとき、Red Hat OpenShift GitOps は、Git に保存された宣言型の設定ファイルを使って望ましいインフラストラクチャの状態を定義する Operator です。Argo CD は、実際の環境が git リポジトリで指定された状態と常に一致するようにします。このアプローチにより、コードとインフラストラクチャの両方でバージョン管理、コラボレーション、トレーサビリティが促進され、それがひいてはソフトウェア提供およびインフラストラクチャ管理の効率化と同時に、信頼性の向上につながります。

ここまで、GitOps ワークフローがどのようにシステムの安定性と信頼性を向上させ、同時に生産性と開発およびデプロイメントの速度を向上させるのかについて、概念的な理解を深めてきました。

次は、GitOps を実際に試してみましょう。