GitOps – インフラストラクチャ自動化のための DevOps

[[360000]]

GitOps はインフラストラクチャを自動的に管理する方法を提供します。これは、バージョン管理、コードレビュー、CI/CD パイプラインなど、多くのチームがすでに使用している DevOps のベストプラクティスを使用して実現されます。

企業は、生産性とソフトウェアの品質を向上させる大きな可能性を秘めていることから、DevOps を導入し始めています。その過程で、ソフトウェア開発ライフサイクルを自動化する方法を見つけました。ただし、インフラストラクチャのセットアップと展開に関しては、依然としてほとんどが手動のプロセスです。

GitOps を使用すると、チームはインフラストラクチャのプロビジョニング プロセスを自動化できます。これは、宣言ファイルを使用してインフラストラクチャをコードとして記述する機能 (IaC) によるものです。アプリケーション開発コードを保存するのと同じように、それらを Git リポジトリに保存できます。

GitOps はどのように機能しますか?

GitOps の概念はもともと、Kubernetes 管理会社である Weave workers によって提案されました。その結果、GitOps に関する議論は主に Kubernetes のコンテキストで行われるようになりました。コンテナ内で実行されるマイクロサービスへの移行により、オーケストレーション プラットフォームの必要性が生じました。コンテナベースのアプリケーションは複雑で、プロビジョニングや管理が困難になる場合があります。 GitOps は、DevOps の世界で実証済みの手法を適用することで、このプロセスを簡素化します。

今日、このアイデアは DevOps 愛好家の間で支持を集めており、 IaC コンセプトのアップグレードされたモデルを表しています。それは 3 つの主要なコンポーネントを中心に展開します。

1. インフラストラクチャ・アズ・コード
2. プルリクエスト
3. CI/CD

それぞれを個別に見てみましょう。

インフラストラクチャ・アズ・コード

IaC は、インフラストラクチャを宣言型ファイル (コードとして保存) として構成および管理する方法です。 IaC とバージョン管理チームを活用することで、すべての運用手順を最適化できます。

GitOps は IaC の宣言型モデルを中心に展開されます。そのため、Kubernetes は実装の優れた例となります。宣言型とは、構成がコマンドのセットではなく、望ましい状態のステートメントであることを意味します。たとえば、Kubernetes では、マニフェストでサービスに必要な Pod の数を定義できます。その後、システムは自動的に処理します。エンジニアがコマンド スクリプトを記述して、必要なコンテナ番号を取得する必要はありません。

宣言型モデルに準拠するクラウドネイティブ ソフトウェアはすべてコードと見なすことができます。当社では、宣言型ツールである AWS CloudFormation を使用して AWS インフラストラクチャを作成しています。つまり、インフラストラクチャ自体をコードとして扱うことができるということです。目的の状態をコードとして宣言します。システムは、この状態を実現するために自動的に変更を適用します。

そうは言っても、GitOps のメリットを享受するために宣言型モデルは必須ではありません。命令的に定義された環境で操作を実行することもできます。

プルリクエスト

GitOps コンセプトの背後にある主な考え方は、バージョン管理システムが唯一の真実のソースであるということです。当社では、アプリケーション コードの変更管理システムとして Git を使用しています。これをインフラストラクチャ コードにも使用できます。したがって、宣言ファイルのセット全体が 1 か所に集められ、共同作業が可能になります。これにより、変更を操作するために Git の重要な概念であるプル リクエストを使用できるようになります。

アプリケーション開発ワークフローでは、マスター ブランチをリリース ブランチとして使用します。開発者はマスター ブランチから機能ブランチを作成します。特定の機能またはストーリーを開発し、完了したらプル リクエストを作成してメイン ブランチにマージします。同じアプローチはインフラストラクチャ コードにも便利です。

プル リクエストを作成すると、コードがコードベースの別のブランチに統合される前に、コード レビュー プロセスを経ることができます。コードレビューにより、不良コードがテスト環境や本番環境に侵入するのを防ぎます。これはインフラストラクチャ コードにとってさらに重要です。コードレビューを通じて正式な承認を得ることは、監査とトラブルシューティングに役立ちます。

Git 組織

GitOps のデプロイメント プロセスには、アプリケーション リポジトリと環境構成リポジトリの少なくとも 2 つのリポジトリが必要です。最初のファイルには、アプリケーションのソース コードとデプロイメント マニフェストが含まれています。 2 番目には、各環境の宣言型仕様を使用して記述されたシステム全体の望ましい状態が含まれます。コード リポジトリでは、環境を開発、テスト、本番として記述できます。これらの環境には、その環境の特定のバージョンで実行できるアプリケーションとインフラストラクチャ サービスが含まれます。

インフラストラクチャの場合、マスター ブランチは環境を表すことができます。機能ブランチで変更を実装できます。次に、マスター ブランチからの変更をマージするためのプル リクエストを作成します。これにより、誰がどのような変更を行ったかについての透明性を維持しながら共同作業を行うことができます。すべての変更は Git でコミットされるため、問題の根本原因を追跡するのにも役立ちます。

GitOps は、GitHub、BitBucket、GitLab などの Git ベースのシステムで使用できます。いかなるツールやテクノロジーにも依存しません。

CI/CD

完全な GitOps 実装を実現するには、 CI/CD パイプラインが必要です。自動配信パイプラインを使用すると、Git リポジトリに変更が発生するたびに、指定された環境にインフラストラクチャの変更を配信できます。ここには、Git プル リクエストをオーケストレーション システムに接続するための配管があります。プル リクエストでパイプラインをトリガーすると、オーケストレーション システムがタスクを実行します。

GitOps のデプロイメント戦略には、プッシュ パイプラインとプル パイプラインの2 つの可能性があります。それらの違いは、デプロイメント環境が目的のインフラストラクチャに似ていることを確認する方法にあります。

プッシュパイプライン

多くの一般的な CI/CD ツールはこの戦略を使用しています。アプリケーションのソース コードとデプロイメント マニフェストをリポジトリに保存します。アプリケーション コードで新しい更新が発生すると、ビルド パイプラインがトリガーされます。パイプラインはコンテナ イメージを構築し、変更を環境にプッシュします。この戦略はあらゆる種類のインフラストラクチャをサポートするため、柔軟性が向上します。欠点は、CI/CD ツールが環境に書き込むことができるようになることです。

プッシュベースの GitOps デプロイメント

プルパイプ

コミュニティは、プル パイプライン アプローチが GitOps にとってより安全な方法であると考えています。このアプローチでは、演算子が導入されます。オペレーターは、パイプラインとオーケストレーション ツール間のコンポーネントです。環境リポジトリ内のターゲット状態と、デプロイされたインフラストラクチャ内の実際の状態を継続的に比較します。オペレーターが変更を検出すると、インフラストラクチャは環境リポジトリに合わせて変更されます。同様に、イメージ レジストリを監視して、展開するイメージの新しいバージョンを識別することもできます。これが GitOps を特別なものにしているのです。

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

GitOps では、環境リポジトリに変更があった場合にのみ環境の更新が行われます。実装されたインフラストラクチャが環境リポジトリで定義されていない方法で変更された場合、システムは行われた変更をすべて元に戻します。

ほとんどのアプリケーションでは、複数の環境が必要になる可能性があります。 GitOps を使用すると、環境のリポジトリに変更を加えることができる複数のパイプラインを作成できます。環境リポジトリ内の個別のブランチを使用して、より多くの環境を管理できます。オペレーターは、あるブランチの変更を本番環境にデプロイし、別のブランチの変更をテスト環境にデプロイすることで対応できます。

GitOps の利点は何ですか?

DevOpsのベストプラクティスを活用する

GitOps は、Git ワークフロー、IaC、CI/CD パイプライン、不変サーバー、トレース、可観測性に関する既存のベスト プラクティスに重点を置いたモデルであるため、Kubernetes のクラウド ネイティブ アプリケーション管理のより高度な状態を表しています。したがって、当社の既存のシステムと経験は、あなたに多くの助けを提供することができます。

継続的デプロイメント - 簡素化

継続的デプロイメントとは、より高速かつより頻繁にデプロイメントすることを意味します。システムの状態、ダウンタイムへの耐性、上流/下流の依存関係、その他多くの組織関連のプロセスや依存関係など、さまざまな考慮事項があるため、継続的なデプロイメントを適切に行うことは常に非常に困難でした。

GitOps を使用すると、すべてがバージョン管理システム内で行われるため、大量のツールを管理することなくこれを実行できます。デプロイメント オペレーターのおかげで、構造と自動化が提供されます。

これにより生産性も向上し、MTTD (平均展開時間) も短縮されます。自動化された継続的デプロイメントにより、チームは 1 日あたり 30 ～ 100 倍の変更を出荷できるようになり、平均的な本番環境のパフォーマンスが 2 ～ 3 倍向上します。

MTTR（平均修復時間）の短縮

MTTR は、DevOps チームが測定すべき重要な指標の 1 つです。マイクロサービス アーキテクチャでは、小さな問題でも修正が困難になる場合があります。 GitOps はすべての変更をバージョン管理システムに保存し、管理が自動化されるため、MTTR を大幅に短縮できます。環境がどのように変化したかを包括的に把握でき、エラー回復が非常に簡単になります。

簡素化されたKubernetes管理

開発者は、Kubernetes を完全に理解していなくても、Git などの使い慣れたツールを使用して、Kubernetes のアップグレードや機能をより簡単に操作できます。新しく組み込まれた開発者は、数か月ではなく数日で簡単に作業を開始し、活動できるようになります。

会社全体の標準化の向上

GitOps にはアプリケーション、ソフトウェア、Kubernetes に添付された変更をレンダリングするためのフレームワークがあるため、企業全体で透過的なエンドツーエンドのワークフローが実現します。 Git は操作を完全に複製することもできます。

GitOps の準備方法は?

• 堅固なコードレビューとテストのプロセスを確立するコードの変更を注意深く調べると、グローバル変数の追加などの明らかな操作が見つかる場合があります。誤ったコードがリリースされるのを防ぎます。その後、プル リクエストを介して検証済みのコードを送信できるため、開発者が変更を直接送信することを防ぐことができます。プル リクエストを確認してマージしたら、パイプラインをトリガーできます。これは、高いコード基準を維持し、システムの安定性を維持するための第一歩です。
• テスト、テスト、テスト。GitOps を統合するということは、リリースされたアプリケーションの徹底的なテストを必要とする高度な自動化を実現することを意味します。 GitOps を使用すると比較的簡単にロールバックできますが、適切なテストケースを含む適切なコードをリリースすると、プロセスの信頼性が高まります。
• GitOpsの監視に重点を置くことで、システム状態の改善、ロールアウト、ロールバックを追跡する繰り返し可能な運用プロセスが可能になります。注意深く監視することで、予期しないドリフトやシステム構成の変更を特定し、防止することができます。したがって、GitOps の使用を開始する前に、監視スキルを見直し、この変更に対応できるように強化してください。
• 文化を受け入れましょう。リリース時間が長い従来のプロセスの制限は、あなたの足かせになるだけです。 DevOps 文化を持つということは、チームが開発と運用のアクションの価値を理解するのに役立つベストプラクティスを適用することを意味します。同時に、全体的に安定したインフラストラクチャを構築し、アプリケーションをより迅速かつスムーズに実行し、システムを効率的に管理するために、連携して作業する必要があります。 DevOps 文化がなければ、GitOps のメリットを享受することはできません。

なぜ GitOps なのか?

GitOps は、クラウド インフラストラクチャを効率的に操作するのに役立つ優れたワークフロー パターンです。 GitOps は、調整、透明性、安定性、システムの耐久性の向上など、エンジニアリング チームにさまざまなメリットをもたらします。