GitOpsとは？メリットや課題などを紹介

GitOpsとは、デプロイや変更などはGitにコミットするのと同等にシンプルであるべしという哲学です。GitOpsについて、そしてHarnessがどのように支援できるかをご覧ください。

もしかして、お使いの検索エンジンで「GitOpsとは」と打ち込んでこのページにたどり着いたのでは。この記事では、GitOpsとは何か、GitOps によって組織が得られるメリットとは何か、そしてGitOpsを企業向けに展開する方法について説明します。それぞれヘッダー付きのセクションがあるので、特に興味がある項目があれば、該当するセクションに自由にジャンプしてください。

GitOpsは2017年にWeaveWorksが編み出した、デプロイや変更などはGitにコミットするのと同じくらいシンプルであるべきだという哲学を込めた用語です。ファイアウォールルールの追加、VPCの定義、UIバグの修正など、全てソースコントロールというコントロールプレーンから行われるべきです。なぜこのようなことをしたいのでしょうか？まずは、私たちが実際に経験した怖い話から始めましょう。そして、GitOpsでそれを解決する方法をずばり説明します。

なぜGitOpsなのか？

GitOps以前の人生

この記事の著者は、それほど遠くない過去に、あるeコマースアプリケーションのデプロイメントを担当していたことがあります。このプロセスには、デプロイメントパイプラインだけでなく、多くの手動プロセスや、社内のさまざまなサービスプロバイダーへの依頼が含まれていました。６週間ごとに新しい変更が導入され、ソフトウェア開発プロセスを含めると数カ月に及ぶプロセスになりました。アプリケーションのコードを少し変更したり、設定ファイルを修正したりといった簡単なことでも、大がかりな作業になっていました。トラブルの兆候があれば、ロールバックして、また６週間のテストサイクルを実施することが要求されました。

その６週間というのは、本番前の各環境にデプロイし、テストし、再テストするというものです。ファイアウォールの更新やサーバーリソースの追加など、コードベースの展開の範囲外の変更が必要な場合は、各環境で最低２週間、場合によってはそれ以上のリードアップが必要でした。また、複数の環境にまたがるインフラの変更も、６週間のサイクル一度で完了させることはできませんでした。

これは珍しい話ではなく、実際にはとてもよくあることです。企業がGitOpsを導入するのは、上に挙げたような問題があるからです。ソフトウェア開発とデプロイメントに対する、壊れやすく、再現性がなく、拡張性のないアプローチのために、変化のペースが遅くなっているのです。GitOpsは、クラウドネイティブアプリケーションのデプロイメントを簡素化したい企業向けのアプローチです。

GitOpsアプローチのメリット

信頼できる唯一の情報源

エンジニアの組織で働くことになった人は、おそらく複数の権威あるシステムを扱うことの悩みをよく理解していることでしょう。ファイアウォール用のシステム、DNS用のシステム、オンプレミスやクラウドのコンピュートプロビジョニング用のシステム、バージョン管理システム、そして最後にCI/CDパイプラインツールなどです。全てを文書化することに並外れた情熱を注ぐカルチャーを持つ組織でない限り、答えがどこにあるのかを知ることは、それを解析することと同じくらい重要な仕事です。

GitOpsを使えば、開発者はバージョン管理システムを、関心のある全ての設定に関する答えを探すための権威として持つことができます。

これにより、オンボーディングの合理化、開発者の体験の向上、そして生産時間を削る恐ろしい「コンテキストスイッチ」の回避に至るまで、さまざまなメリットが得られます。

バージョン管理

アプリケーションのあらゆる側面に加えられた変更は、一箇所に集められ、プルリクエストによって提案され、実装されるたびにバージョン管理されます。全てがコード化されているため、どのような変更もレビューすることができ、完全な紙の証跡があり、変更をロールバックすることができます。

インフラ管理の民主化

歴史的に、全てのシステムには、異なるゲートキーパーが存在します。ネットワークチーム、セキュリティーチーム、運用チームなどなど。GitOps以前の世界では、継続的デプロイメントの自動化を実現するには、少なくとも半ダースの異なるグループと、そのグループが作るあらゆるお役所仕事に翻弄されていました。 どのようなアップデートでも、システムのオーナーを巻き込む長いリクエストプロセスを経て、慎重に変更を文書化する必要がありました。

開発者がクラウドリソースをプロビジョニングすることは、企業のインフラ管理方法から初めて大きく逸脱したことでした。 そして、アイデアから実装までのループを閉じるために、Infrastructure as Code、そして最終的にはGitOpsが登場したのです。

標準化／使いやすさ／簡素化

変更管理とゲートキーパーは、本番環境と下位の環境とを確実に対応させるために行われてきました。アプリケーションや設定、インフラが何層にも重なっているため、新しい環境を立ち上げるには、多くの真の情報源を確認し、変更チケットを発行し、最終的には試行錯誤を繰り返すことがよくありました。

全てのインフラ、構成、コードがGitリポジトリー（または任意のVC）に定義されているため、新しい環境を構築したり、環境間で構成を移植したりすることは、何度も繰り返すようなプロジェクトではありません。

速度

組織では、ソフトウェアデリバリーの有効性を測定するためのメトリックの標準化が進んでおり、DORAメトリックは最も一般的なものの１つです。測定される主要なメトリックは、リードタイム、つまり実用的な用語では、コードのコミットからその変更が本番環境に到達するまでにかかる時間です。GitOpsのアプローチでは、継続的デリバリーのサイクルタイムを、新しい変更や機能をプッシュするために必要な最小限の時間に短縮します。

フィードバックループの短縮

速度は一石二鳥です。エンドユーザーに機能をより早く提供することは、それ自体で価値があります。それに加えて、開発チームが得る変更に対する迅速なフィードバックがあります。プルリクエストからユーザーフィードバックまでの時間が数カ月というのはよくあることです。開発チームが別のプロジェクトに移った後、長い時間をかけて再検討、改良、変更を加えることは、特に複数のイテレーションがある場合、より時間がかかり、効率的ではありません。

GitOpsとは？

GitOpsの基本はアプリケーションの全ての変更をマージリクエストで行うことであると述べましたが、このモデルが実際にどのようなものなのかを説明しましょう。

GitOpsの原則

システム全体が宣言的に記述される

GitOpsは、手段より目的を重視しています。Kubernetesは現在最も人気のあるプラットフォームで、全てのアプリケーションコンポーネントは記述であり、それらを構築することをどのように達成するかという指示ではありません。宣言的パラダイムでは、開発者は望む状態を記述し、彼らがやり取りするシステムは、記述された要件を満たす方法で、いつ、どのように、どこにアプリケーションを配置するかを決定します。

宣言型インフラストラクチャーと宣言型コンフィギュレーションの主な利点は、ソフトウェア開発チームが、デプロイメントやランタイムのロジスティクスではなく、まずアプリケーションに集中できるようにすることです。

システムの状態はバージョン管理で生きる

GitOpsでは、Gitリポジトリーがアプリケーションの望ましい状態に関する権威として機能します。全ての変更とロールバックは、Gitプルリクエスト、Gitリバート、バージョン管理システムを中心としたアクションを通じて行われます。

承認された変更を自動的に適用する

GitOpsでは、変更を適用するためのプロセスは、全てGitリポジトリーから行われます。featureブランチで作業した後、開発者はプルリクエストを提出し、適用可能なCIパイプラインが実行され、必要なプロセスが完全に満たされた時点で変更がマージされます。mainブランチを真の情報源としたマージ時には、デプロイメントプロセスはGitOpsオペレーターによってデプロイされたインフラストラクチャーで実行され、マージ後に追加のステップは必要ありません。

ドリフトコンソリデーション

GitOpsをめぐる話題の多くは、プッシュ型のものでした。変更が加えられると、それがクラスターに適用されます。その仕組みはともかく、開発者の変更がデプロイされることが中心となっています。GitOpsのもう半分はプルアクションで、アプリケーションは自己回復し、望ましい状態に合わせるために自らを修正します。

Kubernetesベースのインフラストラクチャーは、既に前述したように、失敗したアプリケーションインスタンス（ポッド）を再起動し、望ましい状態に合わせます。GitOpsは、この原則をアプリケーションのあらゆる側面にまで広げます。アプリケーション側から設定やデプロイされたイメージなどにズレを発見した場合、GitOpsオペレーターはソースコントロールを最終的な権威として扱い、実行中の状態をGit内の状態に合わせます。

エンタープライズ向けGitOps

Harnessでは最近、GitOpsソリューションのエコシステムに、独自のEnterprise GitOpsを追加しました。GitOpsを採用するお客様を見ていると、GitOpsの原則を大規模に実装するために、多くの課題があることに気づかされます。

環境を超えてリリースを促進する

複数の環境がある場合、テスト、QA、本番環境の間で避けられない差異に対して望ましい状態を記述することは、管理が困難な戦略、あるいは悪い状態になる可能性のある戦略を導入しない限り、ますます難しくなっています。この記事を書いている時点では、環境ごとのブランチを使うなど、いくつかの解決策に分かれています。しかし、これには多くの潜在的な問題があり、特にコードが正しい順序で全てのブランチに適切にマージされないという問題があります。

環境ごとのブランチという選択肢もありますが、多くの環境とアプリケーションにまたがっていくつのリポジトリを持つことになるのか、計算してみてください。この結果、企業は採用をためらったり、一部の環境でのみ採用したり、ばらばらな、あるいは悪い慣行を使って、技術的負債の形をとることになります。

HarnessでGit Opsを採用するにあたり、Argo CDを選びました。「アプリのアプリ」パターンを使用でき、この問題を大規模に処理する際の少なくとも一部分を解決できるからです。親アプリを使用することで、複数のアプリケーションにまたがる変更を連鎖的に行うことができ、参入障壁が低くなります。さらに、環境間でのデプロイのスケーリングを解決するために、「アプリケーションセット」のサポートが間もなく提供される予定です。

監査

GitOpsでは、Gitログが全ての変更に関する決定的な記録を提供します。しかし、監査証跡としては、変更を検索してビジネスや規制の意味と直接結びつけることが負担になることがあります。Gitは、全てのコミットが記録されますが、各コミットの意味を明らかにするには時間と労力がかかります。特に、技術者ではない人々にとってはそうです。

HarnessでのGitOpsはデプロイと変更の完全な監査ログを提供します。運用とビジネスレベルの分析を可能にするために、Gitコミットを掘り下げる必要はありません。Gitのプルリクエストやファイルをコードレベルまで検索することは、まだ選択肢としてありえますが、もはや必須の出発点ではありません。

GitOpsはSDLCの一端をカバーする

GitOpsアプローチ自体の限界はよく理解されているように、ソフトウェア開発のライフサイクルの多くの部分がカバーされていません。誰にでも使える効薬ではないのです。コードのコンパイル、ユニットテストの実行、統合テスト、セキュリティースキャンなど、GitOpsの継続的デプロイメントモデルに対応するためには、より多くのツールとプロセスが必要です。

Harnessプラットフォームは、継続的インテグレーションと継続的デプロイのライフサイクルの全てをカバーする全体的なソリューションの一部として、GitOpsを内蔵しています。GitOpsは、全てを即座にライブにプッシュするという考え方に従っているため、ここでは区別する必要があります。

GitOpsの機能に加えて、Harnessは、承認、制御された機能リリース、カナリア／ブルーグリーンロールアウト戦略、継続的検証など、プロセスに関わる完全なデリバリーパイプラインを提供します。また別の機会にお話ししますが、あらゆる流行のテクノロジー／哲学と同様に、その日のトレンドを全てのアプリケーションに適用すべきではありません。時には、GitOpsのようなアプローチだけでなく、検証を組み込んだ昔ながらの自動パイプラインが問題を解決できることもあります。

スケールアップ

多くのアプリケーションや環境には、規模に応じた一連の課題があります。Gitリポジトリーの数が急増すると、すぐに環境や設定を追跡することが難しくなります。中央集権に対する本当の意味での自律性は、すぐに現実的な問題となります。チームに自律性を持たせると、全社的な変更やポリシーの適用が負担となり、一方、設定を中央集権化すると大きなボトルネックになるというトレードオフが生じるからです。人材獲得競争が激化し、開発者中心のエクスペリエンスが求められる中、GitOpsを大規模に設定することが障害になる可能性があります。

GitOpsは開発者中心の分散型アプローチであるため、DevOpsチームの負担は、全てを未開拓の荒野に変えることなく、必要なツールを提供することです。SDLCの他の部分を提供するプラットフォームの利点と同様に、HarnessもGitOpsを管理するための画面を提供する一方で、開発チームには必要な自律性を提供します。

このプラットフォームが解決しようとするいくつかの重要な課題は、プロジェクトレベルのスペース、堅牢なRBAC、OPAを利用したポリシーの提供です。スペースの分割、適切なアクセス、そして最終的にコードとして記述されたポリシーによる統治を組み合わせることで、DevOpsチームは、チームがソフトウェアを構築する方法について過度にハンズオンしたり規範的になったりすることなく、日々の業務を完全に制御することができます。

GitOpsの採用

GitOpsを組織で採用しようとしている方、もっと学びたい方は、ウェビナーをご覧ください。GitOpsの導入方法、潜在的な落とし穴、そしてGitOpsを次のレベルへ拡張する方法について深く掘り下げています。

結論

GitOpsの旅路において、探索から熟練したプロフェッショナルまで、どのような状況であれ、お役に立てたなら幸いです。HarnessでGitOpsを実践しているところをご覧になりたい方は、ぜひ私たちに会いに来てください。

今すぐデモをご予約ください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。