成功する GitOps モデルを開発するための 3 つのステップ

翻訳者 |崔英鋒

校正 |孫淑娟 梁策

この記事では、コンテナ化とマイクロサービスに基づくクラウドネイティブ ソリューションを開発する組織に GitOps がどのように最適に役立つかについて説明します。

GitOps とは何ですか? また、組織にとってなぜ重要ですか?

GitOps は、バージョン管理、コードレビュー、CI/CD パイプラインなど、多くのチームがすでに使用しているのと同じ DevOps ベストプラクティスを使用して、インフラストラクチャとアプリケーションを自動化および管理するためのモデルです。 DevOps を実装する過程で、ソフトウェア開発ライフサイクルを自動化する方法が見つかりましたが、インフラストラクチャのインストールと展開では依然として手動処理が必要です。 GitOps を使用すると、チームはインフラストラクチャ構成プロセスを自動化できます。これは、インフラストラクチャをコードとして記述し (IaC)、Git リポジトリでコードをバージョン管理し、クラウド配信に基づいて継続的なデプロイメントを実行する機能によって可能になります。

企業は、生産性とソフトウェア品質を向上させる大きな可能性を秘めていることから GitOps を採用しており、コンテナ化とマイクロサービスに基づくクラウドネイティブ ソリューションを開発する組織にも最適です。

GitOps は開発者とオペレーターの日常業務をどのように改善するのでしょうか?

GitOps によってもたらされたインフラストラクチャ自動化の成長により、アプリケーション開発者にとってより「セルフサービス」なアプローチを開発する機会が生まれます。熟練した開発者は、クラウド リソースをネゴシエートするのではなく、インフラストラクチャをコードとして使用してクラウド リソース要件を宣言できます。これはインフラストラクチャの望ましい状態となり、一元的に保存され、コードで宣言された要件と実行環境の実際の状態との間の不変の参照ポイントとして使用できます。

セルフサービス アプローチにより、開発者の負担が軽減されます。これにより、開発者の生産性が向上し、イノベーションに集中してアプリケーションをより早く市場に投入できるようになります。さらに、開発者と運用スタッフがリソースを交渉する必要がある場合に発生する可能性のある泥沼を回避できます。

一方、運用の自動化が進むと、運用チームに必要な人員が減り、パイプラインにおける運用の役割が軽視されるという誤解がよくあります。私たちの見解はまさにその逆です。 GitOps や社内開発プラットフォームなどの最新のアプローチは、Ops (プラットフォーム チーム) がスキルを向上させ、組織にさらなる価値を生み出すための刺激的な機会を提供すると考えています。 GitOps を高度なレベルで導入しているクラウドネイティブ ソフトウェア開発組織では、成長を続けるプラットフォーム チームがすべてを機能させていることに気付くかもしれません。

プラットフォーム チームが実際に使用するテクノロジは異なる場合があります。場合によっては、これは単なるクローズド PaaS ソリューションになることもあります。場合によっては、さまざまなツールを組み合わせて、組織のニーズに合ったカスタム プラットフォームを作成することもできます。これにより、インフラストラクチャのリソースとアーキテクチャに対する影響力と制御が強化され、「ガードレール」を作成して、クラウドネイティブ アプリケーションの展開に対するシンプルで効率的かつ標準化されたアプローチを適用できるようになります。

GitOps は、開発者と運用チーム間のコラボレーションを改善し、生産性を高め、デプロイメントの頻度を増やすのに役立ちます。開発者が基盤となるインフラストラクチャを理解しなくても機能を提供できるようにすることで、開発者エクスペリエンスが向上します。同時に、コードのレビューと承認を通じて運用を管理します。これらの改善により、チームはより迅速かつ安全にリリースを行い、市場での地位を維持できるようになります。

GitOps を実装するために必ず実行する必要がある 3 つのステップは何ですか?

ワークフロー全体の標準化や一貫性など、社内で導入した GitOps モデルのメリットを最大限に生かしたい場合は、以下の点を考慮する必要があります。

すべてはコードだ

• IaC を宣言します。
• IaC 開発には Git リポジトリを使用します。
• アプリケーション コード ライフサイクルの一部であるプラクティスをインフラストラクチャ コードにも複製します。
• Docker や Kubernetes などのテクノロジーを使用して、環境、バージョン、構成、依存関係をコードとして定義し、実行時に確実に適用されるようにします。
• セキュリティ、ポリシー、コンプライアンス、インフラストラクチャを超えたすべての操作など、コードとして定義できるものすべてに GitOps モデルを徐々に拡張します。

図1: すべてがコードである

宣言型コードは読みやすさと保守性を向上させます。 CloudFormation、Terraform、Pulumi、Crossplane は、インフラストラクチャ構成を定義するために使用できる宣言型言語の一部です。

すべてがコードとして定義されると、Git リポジトリを使用して開発し、バージョン管理、コラボレーション、監査などを探索できます。

レビュープロセス

正しい Git プロセスには以下が含まれます。

• メイン ブランチは通常、dev、test、stage、prod などの環境と、その環境で実行されているステータスを表します。
• 開発者がコードを変更する必要がある場合、メイン ブランチから新しいブランチを作成します。
• 変更の準備ができたら、開発者はプル リクエストを作成します。これは運用チームによる検証と承認のためにレビューされる必要があります。セキュリティとコンプライアンスの専門家もこのフェーズに関与し、環境の状態を適切に検証することができます。
• 承認されると、コードはマスター ブランチにマージされ、テスト環境または本番環境に配信できます。

このワークフローを使用すると、誰がどのような変更を行ったかを追跡し、環境に正しいバージョンのコードがあることを確認できます。

図2: GitOpsワークフロー

機能ブランチを備えた Git ワークフロー システムのプル リクエスト機能をすでに使用している場合は、GitOps による新しいプロセスに多額の投資をする必要はありません。さらに、インフラストラクチャ (およびその他の操作) もコードとして定義されるため、同じコード レビュー プラクティスを実装できるようになります。

ビルドとデプロイメントのプロセスを分離する（CI と CD）

• CI プロセスは、アプリケーション コードを構築し、それをコンテナー イメージにパッケージ化する役割を担います。
• CD プロセスは、リポジトリ コードに記述されているように、最終状態をシステムの望ましい状態に合わせる自動アクションを実行します。

最終的に、GitOps は CI と CD を 2 つの別々のプロセスとして扱います。CI は開発プロセスであり、CD は運用プロセスです。

これらのプロセスを分離するために使用される一般的な GitOps アプローチは、別の Git リポジトリを仲介者として導入することです。このリポジトリには環境に関する情報が含まれており、コミットごとにデプロイメント プロセスがトリガーされます。パイプラインとオーケストレーション ツールの間には、オペレーターと呼ばれる別のコンポーネントが存在します。オペレーターは、環境リポジトリ内のターゲット状態とデプロイされたインフラストラクチャ内の実際の状態を継続的に比較し、変更を検出した場合は、インフラストラクチャを環境リポジトリに合わせて変更します。さらに、イメージ レジストリを監視して、展開するイメージの新しいバージョンを識別します。この方法では、CI プロセスは基盤となるインフラストラクチャ (Kubernetes クラスターなど) に一切影響を与えません。

図3: プルベースのGitOpsデプロイメント

ビルド パイプラインをデプロイメント パイプラインから分離することは、誤った構成に対する強力な保護となり、セキュリティとコンプライアンスの向上に役立ちます。

結論は

運用モデルとしての GitOps は、多くのチームが使い慣れている DevOps プラクティスを使用します。 GitOps を使用すると、インフラストラクチャ構成プロセスを自動化し、インフラストラクチャ構成の変更に関する唯一の信頼できる情報源として Git を使用できます。したがって、成功する GitOps モデルを作成するには、環境を宣言的に定義する必要があります。

チーム内にプル リクエスト ワークフローも導入しておくとよいでしょう。インフラストラクチャ コードを共同作業して運用上の変更を作成するには、プル リクエストを送信する必要があります。その後、上級 DevOps エンジニアとセキュリティ専門家がプル リクエストをレビューして変更を検証し、問題がなければマスター ブランチにマージします。

GitOps を完全に実装するには、パラメータを設定し、デプロイメント定義の基盤となる環境とコードを構成するための CI/CD 自動化が必要です。

最後に、会社内には支援的な組織文化がなければなりません。私たちの経験では、GitOps アプローチは、開発者がセルフサービスのインフラストラクチャ リソース自動化の成長から恩恵を受け、プラットフォーム エンジニアが組織内でより影響力のある役割を果たすことができる構造に自然につながります。これは、チーム全員の団結と充実感を高める、双方にメリットのあるアプローチとなります。

翻訳者について

51CTO コミュニティ エディターの Cui Yingfeng 氏は、1970 年代生まれで 10 年以上の職務経験を持つプログラマーです。長年にわたり、Java 開発、アーキテクチャ設計、コンテナ化などの関連業務に従事。彼は Java に精通しており、Maven、Jenkins、その他の DevOps 関連ツール チェーンの使用に熟練しており、コンテナ化ソリューションの計画、設計、実装に優れています。

原題:成功する GitOps モデルを開発するための 3 つのステップ、著者: Marija Naumovska