GitOps とは | DevOps を Kubernetes とその先へ拡張

プログラミングの分野では、過去 10 年間に多くの革命的な変化が起こりました。その 1 つは、開発チームと運用チームを共有ワークフローに統合し、継続的インテグレーションと継続的デリバリー (CI/CD) を実装する、DevOps に関する一連のプラクティスです。これにより、DevOps チームはコード ベースに継続的に増分更新を提供します。もう 1 つの変化は、モノリシック コードベースから、Kubernetes などのビジネス プラットフォームによって管理されるコンテナーで実行されるクラウドベースのマイクロサービスへの移行によって生じます。

クラスター化されたシステムやクラウドで実行されるコンテナベースのアプリケーションは、Kubernetes のようなプラットフォームを使用してオーケストレーションを行ったとしても、構成や管理が複雑で困難になる可能性があります。 GitOps は、DevOps と CI/CD の分野の技術を適用してこの管理タスクを簡素化することを目的とした新しい一連のプラクティスです。

GitOps の鍵となるのは、コードとしてのインフラストラクチャという考え方です。これは、DevOps がアプリケーションのプロビジョニングに使用するのと同じアプローチをインフラストラクチャのプロビジョニングに採用しています。したがって、アプリケーションだけでなく、基盤となるホストとネットワークも、バージョン管理システム内の他のコードと同じように扱うことができるファイルに記述され、実際のアプリケーションはこれらのファイルに記述されたアプリケーションとマージされます。

GitOps の用語では、バージョン管理システム内のコードは、アプリケーションが本番環境でどのように見えるかを示す唯一の真実のソースです。

GitOpsの定義

Weaveworks は、GitOps の概念を普及させるために最も尽力した企業です。 Weaveworks の役割については後ほど詳しく説明しますが、まずは同社の GitOps の定義を見てみましょう。これには 2 つの側面があります。

• Kubernetes やその他のクラウドネイティブ テクノロジーの運用モデルは、コンテナ化されたクラスターとアプリケーションの展開、管理、監視を統合する一連のベスト プラクティスを提供します。
• 開発者が管理するアプリケーション エクスペリエンスへの道。運用と開発の両方に対応するエンドツーエンドの CI/CD パイプラインと Git ワークフロー。

言い換えれば、GitOps は Kubernetes や同様のプラットフォームを管理するために特別に設計された一連のプラクティスですが、より多くの開発組織が DevOps プラクティスを採用し、コードをクラウドに移行するにつれて、より広範囲に適用することもできます。しかし、GitOps の秘密とそれが解決する問題を理解するには、そのコンポーネントについて説明する必要があります。

Gitの定義

GitOps の Git は、2005 年に Linus Torvalds によって開発された、非常に人気のある分散バージョン管理システムを指します。Git は、開発チームが単一のアプリケーション コードベースで共同作業し、本番環境にマージする前に変更したさまざまなコード ブランチを保存できるようにするツールです。 Git の重要な概念はプル リクエストです。プル リクエストでは、開発者が作業中のコードの一部をコードベース内の別のブランチに統合することを正式に要求します。

Git プル リクエストは、チーム メンバーが共同作業して話し合い、アプリケーションに新しいコードを追加するかどうかについて合意に達する機会を提供します。 Git はコードの古いバージョンも保存するため、何か問題が発生した場合に最後の正常なバージョンに簡単に戻ることができ、異なるバージョン間の変更をすばやく確認できます。 Git は、クラウドホスト型バージョン管理システムである GitHub の基盤として最もよく知られていますが、Git 自体は、企業の内部サーバーから個人のコンピューターまで、どこにでも導入できるオープンソース ソフトウェアです。

一般的に Git はコンピュータ プログラミング ツールと考えられていますが、実際には Git が何を行うのかは認識していないことに注意してください。 Git は、テキスト ファイルのコレクションを「リポジトリ」として扱います。これにより、作成者は共同作業の編集を追跡できるようになります。 GitOps コア コード ベースの大部分は実行可能コードではなく宣言型構成ファイルで構成されているため、これは重要です。

先に進む前に最後にもう 1 つ: 名前に「Git」が含まれていますが、GitOps では実際には Git を使用する必要はありません。 Subversion などの他のバージョン管理ソフトウェアにすでに投資している企業も、GitOps を実装できます。しかし、Git は CI/CD を実装するために DevOps で広く使用されているため、ほとんどの GitOps プロジェクトは最終的に Git を使用することになります。

CI/CD プロセスとは何ですか?

CI/CD を完全に理解することはこの記事の範囲を超えていますが、GitOps 運用の​​中核となる CI/CD について少し説明する必要があります。 CI/CD の継続的インテグレーション部分は、Git などのバージョン管理ライブラリによって実現されます。開発者は、数か月または数年ごとに巨大でモノリシックな新しいバージョンをリリースする代わりに、コードベースに継続的に小さな改善を加えることができます。継続的デプロイメントは、新しいコードを構築、テストし、本番環境にデプロイするパイプラインと呼ばれる自動化システムによって部分的に実現されます。

ここでも、コードについて話してきましたが、これは通常、C、Java、JavaScript などのプログラミング言語で記述された実行可能コードを思い起こさせます。しかし、GitOps では、管理する「コード」は主に構成ファイルで構成されます。これは単なる小さな詳細ではなく、GitOps の動作の核心です。前述したように、これらの構成ファイルは、システムがどのようになるべきかを説明する「唯一の真実のソース」です。それらは宣言的であり、ヒューリスティックではありません。つまり、構成ファイルでは、「10 台のサーバーを起動する」と記述する代わりに、「このシステムには 10 台のサーバーが含まれています」と記述するだけです。

GitOps 方程式の CI 部分により、開発者はこれらの構成ファイルを迅速に調整および改善できます。 CD の半分は、自動化されたソフトウェア エージェントが、アプリケーションのライブ バージョンが構成ファイルの説明を反映するように最善を尽くすときに発生します。これは、GitOps 言語の宣言型モデルに収束します。

GitOps と Kubernetes

前述したように、GitOps の概念はもともと Kubernetes アプリケーションの管理を中心に開発されました。 GitOps について今わかっていることを踏まえて、Weaveworks の GitOps に関する説明を見てみましょう。要約すると次のようになります。

1. 開発者が新しい機能の Git プル リクエストを発行します。

2. コードはレビューされ、承認され、メイン コード ベースにマージされます。

3. マージにより CI/CD パイプラインがトリガーされ、新しいコードが自動的にテストおよび再構築され、レジストリにデプロイされます。

4. ソフトウェア エージェントは更新を認識し、レジストリから新しいコードを取得し、構成リポジトリ内の構成ファイル (YAML で記述) を更新します。

5. Kubernetes クラスター内のソフトウェア エージェントは、構成ファイルに基づいてクラスターの古い状態を検出し、変更を抽出して、新しい機能を展開します。

Weaveworks と GitOps

明らかに、ステップ 4 と 5 が最も重要な部分です。 GitOps は、Git リポジトリ内の「真実のソース」を実際の Kubernetes アプリケーションと魔法のように同期するソフトウェア エージェントによって実現されます。前述したように、GitOps の用語では、動的なシステムを構成ファイルに記述された理想的なシステムに近づけるプロセスをコンバージェンスと呼びます。 (発散は、動的なシステムと理想的なシステムが同期していない場合に発生します。) 理想的には、自動化されたプロセスを通じて収束を実現できますが、自動化には限界があり、場合によっては人間の介入が必要になります。

ここではこのプロセスを一般的な言葉で説明しましたが、実際に Weaveworks のページを見ると、ここで言及している「ソフトウェア エージェント」は同社の Weave クラウド プラットフォームの一部であることがわかります。 「GitOps」という用語は、Weaveworks の CEO である Alexis Richardson 氏によって造られたもので、DevOps と CI/CD の世界にすでに浸かっている開発者にとって Weaveworks プラットフォームを魅力的なものにするための取り組みの一環です。

しかし、Weaveworks は GitOps の独占を主張したことはありません。それは特定の製品というよりも、哲学とベストプラクティスの集合です。 CI/CD ソリューションを提供する企業 CloudBees のブログ投稿で述べられているように、GitOps は、Amazon、Google、Microsoft などの大手クラウド ベンダーが提供するホスト型の独自の Kubernetes ソリューションに応えて開発された、ベンダーに依存しないオープンなモデルです。 CloudBees は、この分野の多くのプレーヤーと同様に、独自の GitOps ソリューションを提供しています。

GitOps と DevOps

アジャイル開発者向けにさまざまなツールを提供する企業である Atlassian には、GitOps の歴史と目的について詳細に説明したブログがあり、読む価値があります。彼らの見解では、GitOps は DevOps のアイデアの論理的な拡張を表しています。具体的には、GitOps は「コードとしてのインフラストラクチャ」という概念を改良したもので、それ自体は DevOps 環境から派生したアイデアです。 Atlassian の見解では、GitOps は、システム管理の問題を解決するために進化してきた、既存の DevOps テクノロジーと分散クラウドホスト型アプリケーションとの間の重大なギャップを埋めます。さまざまなクラウド プロバイダーによって提供される自動統合こそが、GitOps のユニークな点です。

GitOps は現在も Kubernetes に重点を置いていますが、より広範囲の分散型クラウドベースのアプリケーションに適用できることが明確になったと思います。オープンソース セキュリティ ベンダー WhiteSource のブログ投稿では、GitOps の利点について次のように概説しています。

• 可観測性: GitOps システムは、複雑なアプリケーションの監視、ログ記録、トレース、視覚化を提供するため、開発者は問題が発生した場所を確認できます。
• バージョン管理と変更管理: 明らかに、これは Git のようなバージョン管理システムを使用する主な利点です。欠陥のある更新は簡単にロールバックできます。
• 導入が簡単: GitOps は、多くの開発者がすでに持っている DevOps スキルに基づいて構築されます。
• 生産性: GitOps は、DevOps や CI/CD が他の領域にもたらしたのと同様に、生産性を向上させます。
• 監査: Git のおかげで、すべてのアクションを特定のコミットまで追跡できるため、エラーの原因を追跡しやすくなります。

Kubernetes を使用していない場合でも、遅かれ早かれ GitOps がワークフローの一部になります。

*元のリンク: https://www.infoworld.com/article/3566555/what-is-gitops-extending-devops-to-kubernetes-and-beyond.html​