GitOps は DevOps の次なる大きな目玉か?

Git は、プル リクエストとコード レビューのワークフローを可能にする、ソフトウェア開発のためのミッション クリティカルなツールです。プル リクエストは、コードベースに入ってくる変更の可視性を高め、変更の伝達、議論、およびレビューを促します。

プル リクエストは、共同ソフトウェア開発において極めて重要な機能であり、ソフトウェアの構築方法を一変させました。プル リクエストは、以前は不透明だったプロセスに透明性と可測性をもたらします。Git のプル リクエストによって、ソフトウェア開発における DevOps プロセスが進化しました。変化に躊躇しがちなシステム管理者も、アジャイルや DevOps などの新しいソフトウェア開発手法を採用しています。

手作業でのシステム管理にはずさんな歴史があります。これまで、システム管理者は物理的なサーバー ラック内のマシンに接続してプロビジョニングするか、クラウド プロビジョニング API を介して手動でハードウェアを管理していました。手動によるプロビジョニング プロセスに加えて、手動による大量の構成作業がつきものでした。管理者は、命令型のスクリプトと構成のカスタム コレクションを保持し、それらを継ぎ合わせて、さまざまな場所に置いていました。これらのスクリプトはいつ壊れたり、失われたりするかわかりません。こうしたカスタムのツール チェーンは定期的に文書化または共有されていなかったため、共同作業は困難でした。

DevOps の動きは、このようなシステム管理の原始的な沼地から生まれました。DevOps は、ソフトウェア エンジニアリングから最高のアイデアを借りて、システム管理に適用しました。これにより、継ぎ合わせのツールがバージョン管理されたコードになりました。

IaC は DevOps の最大の啓示の 1 つです。以前、システム管理者は、カスタムの命令型スクリプトを使用してシステムを構成することを好んでいました。命令型ソフトウェアは、次のような一連の手順に従って、目的の状態を実現します。

命令型ソフトウェアはエラーを起こしやすく、イベントのシーケンスを変更することで簡単に壊れます。現代のソフトウェア開発は、命令型から脱却し、宣言型ソフトウェア パターンに向かう傾向にあります。

宣言型ソフトウェアは、一連のコマンドではなく、期待される状態の宣言に従います。命令型と宣言型の devops ステートメントの比較を次に示します。

命令型のステートメントは、次のとおりです。

1. このマシンにオペレーティング システムをインストールする
2. これらの依存関係をインストールする
3. この URL からコードをダウンロードする
4. コードをこのディレクトリに移動する
5. この作業を他の 3 台のマシンで 3 回行う

宣言型バージョンでは、単に次のとおりです。4 台のマシンに、この URL のソフトウェアをインストールして、このディレクトリにインストールする。

GitOps のメリットの多くは、アジャイルなフィーチャー ブランチのソフトウェア開発ワークフローと同じです。1 つ目の大きなメリットは、一般的なツールを使用するため、導入が容易なことです。Git はバージョン管理システムのデファクト スタンダードであり、ほとんどの開発者やソフトウェア チームにとって一般的なソフトウェア開発ツールです。これにより、Git に精通している開発者が部門横断的に貢献者になり、GitOps に参加しやすくなります。

バージョン管理システムを使用すると、チームがシステム設定に対するすべての変更を追跡できます。これにより、何かが壊れたり、予期せぬ動作が発生したりする場合に、「信頼できる情報源」と貴重な監査証跡となります。チームは GitOps の履歴を確認して、リグレッションがいつ導入されたかを確認できます。さらに、この監査証跡は、コンプライアンスまたはセキュリティ監査の参照として使用できます。GitOps の履歴は、暗号化証明書などが変更または更新された時の証拠として使用できます。

GitOps は、中央リポジトリを中心とした組織のインフラストラクチャのニーズに透明性と明快さをもたらします。すべてのシステム設定を中央リポジトリに格納することで、チーム メンバーの貢献力を拡大できます。Bitbucket などのホスト型 Git サービスを介したプル リクエストには、コード レビューやディスカッション解説用の豊富なツールがあります。これにより、パッシブな通信ループが構築され、エンジニアリング チーム全員がインフラストラクチャの変更を観察および監視できます。

GitOps は DevOps チームの生産性を大幅に向上させることができます。GitOps は、新しいインフラストラクチャ構成を迅速に試すことができます。新しい変更が期待どおりに動作しない場合、Git 履歴を使用して変更内容を既知の正常な状態に戻すことができます。これは、使い慣れた「元に戻す」機能を複雑なインフラストラクチャで使用できるため、非常に便利です。

GitOps の手順は、基盤となるオーケストレーション システムによって実行されます。GitOps 自体は、依存性のないベスト プラクティス パターンです。今日人気のある GitOps ソリューションの多くは、主に Kubernetes をオーケストレーション システムとして使用しています。これに代わって、Terraform の直接操作をサポートするいくつかの GitOps ツール セットが発売される予定です。

完全な GitOps インストールを実現するには、パイプライン プラットフォームが必須です。Jenkins、Bitbucket Pipelines、または CircleCI は、GitOps を補完する一般的なパイプライン ツールの一部です。パイプラインは自動化を行い、Git のプル リクエストとオーケストレーション システムの間のギャップを埋めます。パイプライン フックが設定され、プル リクエストからトリガーされると、オーケストレーション ピースに対してコマンドが実行されます。

GitOps で特に導入される新しいパターンまたはコンポーネントに GitOps の「オペレーター」があります。これは、パイプラインとオーケストレーション システムの間に位置するメカニズムです。プル リクエストによってパイプラインが開始され、オペレーターがトリガーされます。オペレーターは、リポジトリの状態とオーケストレーションの開始を調べ、同期します。オペレーターは GitOps の魔法のようなコンポーネントです。

パフォーマンスのボトルネックまたはトラフィックの急増が見つかり、ロード バランサーが期待どおりに動作していないことに気付いたとします。インフラストラクチャの構成を保持する GitOps リポジトリを調べて、ロード バランサーを設定してデプロイする特定のファイルを見つけます。このファイルは、オンラインの Git ホスティング サイトでレビューできます。レビューして討議した結果、ロード バランサーの構成値の一部が最適ではなく、調整が必要であることが判明しました。

チーム メンバーが、ロード バランサーの値を最適化する新しいプル リクエストをオープンします。プル リクエストは 2 人目のチーム メンバーによってレビューおよび承認され、リポジトリにマージされます。マージによって GitOps パイプラインが開始され、GitOps オペレーターがトリガーされます。オペレーターは、ロード バランサーの構成が変更されたことを認識します。オペレーターは、これがチームのクラスタで公開されている内容に一致しないことをシステム オーケストレーション ツールで確認します。

オペレーターは、オーケストレーション システムにロード バランサー構成の更新を通知します。後はオーケストレーターが処理し、新しく構成したロード バランサーを自動的にデプロイします。その後チームは新しく更新されたライブ システムを監視して、正常な状態に戻ることを確認します。これが理想的な GitOps シナリオです。GitOps ユーティリティのデモンストレーションのために、さらに詳しく説明しましょう。

ロード バランサーを調整して値を最適化するのではなく、思い切ってまったく新しいタイプのロード バランサーをデプロイすることを決定したとします。現在のロード バランサーに根本的な欠陥があると感じ、別のオプションを試そうと考えたのです。ワークフローは値の微調整と同じです。まったく新しいロード バランサー構成を導入し、古い構成を削除するプル リクエストを作成します。それが承認され、パイプラインを通じてデプロイされます。

ところが、この新しいタイプのロード バランサーはクラスタ内の他のサービスと互換性がないことに気付きました。新しいロード バランサーにより、重大なトラフィック障害が発生し、ユーザー操作が停止します。幸いなことに、完全な GitOps パイプラインがあるため、ロード バランサーの変更をすばやく元に戻すことができます。リポジトリを古い既知の機能的ロード バランサーに戻すプル リクエストをもう一度作成します。これも GitOps パイプラインによって記録され、自動的にデプロイされます。これにより、インフラストラクチャが迅速に改善され、チームの信頼性が向上します。

GitOps は、最新のクラウド インフラストラクチャを管理するための非常に強力なワークフロー パターンです。主に Kubernetes クラスタ管理に焦点を当てていますが、DevOps コミュニティでは GitOps ソリューションを他の非 Kubernetes システムに適用して公開しています。GitOps は、コミュニケーション、可視性、安定性、システムの信頼性の向上など、エンジニアリング チームに多くのメリットをもたらします。GitOps エクスペリエンスの主要な要件の 1 つは、Bitbucket のような最新のホスト型 Git プラットフォームです。