GitOpsは、次なる画期的な技術として軌道に乗っており、人気が高まっているため、短い期間で企業へ普及しています。この記事では、GitOpsが企業全体に採用されるのを妨げている３つの最大の技術的ハードルについて考えていきます。

ソフトウェアデリバリーツールやプロセスの変化は、クラウド、コンテナ、マイクロサービスの台頭により、過去10年間で飛躍的に拡大しました。このようなITの変化の中で、新しい技術の導入パターンは不変のものです。新しい技術は、個人の貢献者から受け入れが始まり、チームレベルで受け入れられるようになり、最終的には全社的な導入に至ります。

その代表的な例が、ソース管理（またはバージョン管理）とクラウドコンピューティングです。20年間、開発者はコードをフォルダーやドライブに保存するのが一般的でした。ソースコード管理は、まず最先端に身を置く個人が導入し、その個人がチームに導入した後、企業組織が注目し、全社的にソースコード管理の標準化を始めました。

同様に、クラウドコンピューティングについても、最初は開発者がIT運用チームの対応の遅さへの不満から、より速く動かすために導入を始めました。その後、各チームがプロジェクト単位でクラウドを採用するようになり、今では実質的に全組織がクラウド専門のチームを持つようになりました。

GitOpsも同じような経過をたどるでしょう。この画期的な技術は、すぐにでも企業に広く導入されるだろうと私は考えています。

GitOpsの簡単な紹介

GitOpsは、クラウドネイティブなアプリケーションのデプロイをシンプルにしたい企業向けのアプローチです。ファイアウォールルールの追加、VPCの定義、UIバグの修正など、全てソース管理という中心面から行う必要があります。

より技術的なレベルでは、GitOps は、クラウドネイティブアプリケーションの継続的デリバリーを実現するためのフレームワークやプラクティスのセットです。GitOpsは宣言的な構文を使用し、信頼できる唯一のソースとしてGitを活用してインフラとアプリケーションのデプロイを自動化し、DevOpsのベストプラクティスを考慮してKubernetesのデプロイにセキュリティーと信頼性と一貫性をもたらすものです。

GitOpsという概念は５年ほど前からあり、IT業界ではかなり長い期間存在していますが、パラダイムからFluxやArgoCDのようなツールの代名詞となるような概念に進化してきました。GitOpsが新興技術の採用曲線のどこに位置するかというと、かなり長い間、チームレベルで留まっています。

エンタープライズGitOpsの課題

GitOpsがクラウドコンピューティングのような真のエンタープライズサービスになることを阻んでいるのは何でしょうか？エンタープライズGitOpsにはたくさんの課題がありますが、GitOpsが企業規模で採用されるのを阻んでいる最大の技術的ハードルは次の３つだと考えています。

1. スケール管理 
2. ガバナンスの強化 
3. 信頼性不足 

これらの課題を詳しく見ていきましょう。そして、企業組織がGitOpsを大規模に導入するための解決策をいくつか紹介します。

エンタープライズGitOpsのためのスケール管理 

GitOps ツールを１クラスターにデプロイして、少人数のチームで変更を反映させることは、実はとても簡単です。その導入のしやすさが、GitOpsがこれほどまでに普及している理由の一つです。しかし、何百ものクラスターと何千人もの開発者を相手にGitOpsのアプローチを大規模実装することは、非常に困難です。GitOpsを大規模に実行するのは簡単なことではありませんし、ほとんどのGitOpsツールは、Kubernetesで動作するコンテナの中に全てがあるという「魔法の世界」に生きています。企業では、GitOpsはKuberetes外のサービスとともに存在し、さまざまなプラットフォームでスケールできるようにしなければなりません。

GitOpsをエンタープライズ向けに拡張する方法 

簡単に言えば、GitOpsはもう孤島では存在できないのです。20年前に机の下に置いてあったソース管理サーバーのように、オーダーメイドのGitOpsパターンを実行することはもはや続けられません。GitOpsは、CI/CDパイプラインとネイティブに統合された、第一級のエンタープライズサービスになる必要があります。企業は、GitOpsを大規模に管理する必要があります。GitOpsサービスは、パイプラインでデプロイされたサービス、特にKubernetesの領域外に存在するクラウドサービスと共存できる必要があるのです。

エンタープライズGitOpsのためのガバナンスの強化

どのような自動化ツールでも、ガバナンスは課題です。変更を大規模に複製する能力を手に入れると、その大きな力には大きな責任が伴います。残念ながら、ほとんどの自家製のGitOps実装やオープンソースのソリューションには、ガバナンス機能があまり組み込まれていません。GitOpsによる変更で新たなセキュリティー脆弱性が生じないようにすることが重要であり、GitOpsアプローチの導入を検討している企業は、ポリシーベースのガバナンスの導入を検討する必要があります。エンタープライズグレードのGitOpsは、変更管理とセキュリティーを避けて通ることはできません。

エンタープライズGitOpsでガバナンスを解決する

シェアードサービスのジレンマは、今日の企業ITが直面する最大の問題の一つです。簡単に言えば、シェアードサービスチームは、セキュリティーと信頼性を犠牲にせずに可能な限り開発者に権限を与えたいと考えています。このジレンマを解決する現代的な方法は、Policy as Codeによるポリシーベースのガバナンスを実装することです。現代のガバナンスの標準は、CNCF が支援するプロジェクトであるOpen Policy Agent （OPA）です。ポリシーベースのガバナンスは、あらゆるソフトウェアデリバリープロセスにネイティブに組み込まれる必要があるもので、単に後付けのものであってはならないのです。

エンタープライズGitOpsへの信頼性の不足

これから行う変更が、顧客に悪影響を与えないという信頼性はあるのでしょうか？この根本的な疑問があるからこそ、HarnessではAI/MLの力を借りてデプロイの健全性を自動検証するcontinuous verificationという概念を発明したのです。信頼性の不足は、リリースが遅れる一番の理由であり、チームが深夜や週末にリリース作業を行う理由でもあります。GitOpsは素晴らしい新しい枠組みですが、DevOpsエンジニアの生活に多くの労苦をもたらす根本的な信頼性の問題を解決するものではありません。

エンタープライズ向けGitOpsに信頼を持たせる

ポリシーベースのガバナンスは、セキュリティー、テスト、および変更管理のポリシーを確実に実施することができますが、変更が顧客体験に影響を与えないことを動的に確認できるのは、継続的検証だけです。レガシーなリリース戦略と手動検証によるGitOpsは、真のGitOpsではありません。モノリスをコンテナに入れて、マイクロサービスのように振る舞っているようなものです。

HarnessでGitOpsをエンタープライズ向けに拡張する

GitOpsは昨今のDevOpsの中でも、最もエキサイティングなトレンドの一つです。コンテナベースのcontinuous integrationとcontinuous deliveryのための信頼できる唯一の情報源として、GitOpsは開発チームが速度を上げ、システムの信頼性を向上できるようにします。

GitOpsは、真のエンタープライズサービスとして扱われ、導入される段階にまで達しています。GitOpsとCI/CDの統合、ポリシーベースの統合ガバナンス、継続的な検証は、エンタープライズGitOpsの３つの基本要件です。

Harnessは、Cloud Native Computing Foundation（CNCF）発のオープンソースArgo CDプロジェクトをベースに、Continuous Delivery & GitOps-as-a-Serviceを提供し、開発者が好む軽快なデプロイと、エンタープライズクラスのセキュリティー、ガバナンス、スケーラビリティを実現します。

GitOpsの旅路のどの段階にいても、初期の調査段階にいる人から熟練したプロフェッショナルまで、このブログがあなたのお役に立てれば幸いです。HarnessによるGitOps-as-a-Serviceの実践をご覧になりたい方は、デモをリクエストして、私たちがどのように課題に取り組んでいるのかをご覧ください。

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