GitOpsビギナーガイド

簡単に言えば、GitOpsとは、バージョン管理やCI/CDなどのDevOpsプラクティスをインフラ管理に適用する手法のことです。GitOpsという名前はWeaveworks社による造語で、オープンソースのバージョン管理システムであるGitに由来するものです。チームはこれにより、ソフトウェア開発に使用するのと同じツールやオーケストレーションプロセスを使ってインフラを管理できます。

最新のソフトウェア開発を支えているのはスピードと拡張性であり、成熟したDevOps組織であれば、1日にコードを何百回も本番環境にデプロイすることもあります。DevOpsチームは、バージョン管理、コードレビュー、CI/CDパイプラインなどのベストプラクティスがもたらす自動化を活用することで、これを実現しています。しかし、ソフトウェア開発ライフサイクル(SDLC)はほぼ自動化されているものの、インフラ管理はいまだにその大部分を手動プロセスと専門チームに依存しています。これでは、継続的デプロイに必要なスピードと規模で、クラウドリソースをプロビジョニングしたり設定したりするのは困難です。

GitOpsは、インフラのプロビジョニングプロセスを自動化するのに役立ちます。GitOpsチームは、新しいコンポーネントが必要になるたびに手動で環境を構成するのではなく、コードとして保存された構成ファイルを使用し、機械で読み取り可能な定義ファイルを用いて環境の作成を自動化できます。これらの構成ファイルは、デプロイされるたびに同じインフラを生成し、IT環境全体の一貫性を確保します。

このブログ記事では、GitOpsの仕組みとGitOpsを使用すべき理由、そして適用方法について説明します。また、GitOpsの使用を開始する方法と、成功を収めるためのベストプラクティスもご紹介します。

GitOpsの基本

GitOpsは、Gitベースのソースコード管理システムを使用して、コードベースでインフラの構築を行います。これは、Infrastructure as Code(IaC)の進化形といえるものです。IaCは、アプリケーションコードの一部として扱われるスクリプトを使用して、テスト環境やデプロイ環境のプロビジョニングや設定を行うためのDevOpsの手法です。IaCプロセスは、インフラの構成パラメーターを定義するスクリプトを開発者が記述することから始まります。スクリプトは、宣言型または命令型のアプローチで記述することができます。ユーザーは基本的に、宣言型プログラミングでは必要なインフラリソースを指定し、命令型プログラミングではインフラリソースを作成する方法を指定します。

宣言型のアプローチでは、ユーザーはリソースのリストおよび必要なプロパティを指定することで、どのようなインフラを構築したいかを「宣言」する必要があります。IaCツールはそのスクリプトを読み取り、すべてのインフラコンポーネントをインストールして設定し、デプロイされたコードバージョンを管理します。命令型のアプローチでは、ユーザーはIaCツールに実行させたいコマンドのリストを指定して、インフラを段階的にプロビジョニングします。設定スクリプトは、バージョン管理をサポートするコードリポジトリに送信されるため、ファイルのレビュー、編集、コピー、共有が容易に行えます。誰かがファイルを編集すると、マージリクエストとコードレビューのワークフローで変更が検証されます。最終的に、IaCプラットフォームによって、開発者の指示どおりのインフラが作成および設定されます。

GitOpsは、基本的にすべてのインフラ設定のバージョン管理システムとしてGitを使用するIaCです。GitOpsワークフローは、次の3つの主要コンポーネントで構成されています。

• IaC：GitOpsでは、すべてがコードとして定義され、Gitに保存されます(信頼できる唯一の情報源)。
• マージリクエスト：コードの変更は、マージリクエストですべてのインフラの更新についてレビューされ、実装されます。
• CI/CD：GitOpsは、CI/CDを使用して、コード変更をテストし環境にデプロイします。GitOpsの自動化によって、手動での変更やエラーといった設定のずれは上書きされ、Gitで定義された望ましい環境の状態が維持できます。

GitOpsワークフローは、IaC、マージリクエスト、CI/CDの3つの要素で構成されています。

IaCと同様に、GitOpsでも開発者がシステムの望ましい状態を宣言的に記述する必要があります。設定ファイルとソースコードは、Gitリポジトリ(アプリのコードすべてを保持する分散型バージョン管理システム)に保存され、バージョン管理されます。このリポジトリは、そのプロジェクトのファイルに加えられたすべての変更を長期的に追跡し、インフラコンポーネントを作成、更新、削除するための制御システムです。

マージリクエストとは、すべてのインフラの更新のためにコード変更を実装する作業のことです。新しいリリースを展開するために、開発者はGitリポジトリ(例：git repo)内のシステムの状態を変更するリクエストを行います。アラートを受けたチームが変更をレビューし、最終的に承認または拒否します。変更が承認されると、マージによってコードがメインブランチにコミットされ、これが監査ログの役目を果たします。

変更が承認されマージされると、自動的に稼働中のインフラに適用されます。このように、開発者は普段使用しているGitOpsパイプラインをワークフローとCI/CDプラクティスにも使用できるのです。

GitOpsを使う理由とタイミング

GitOpsを使うと、インフラのプロビジョニングがより簡単に、より速く、より拡張性が高まります。

従来のインフラ管理では、インフラやクラウドインフラのリソースをプロビジョニングしようとするたびに、開発者はチケットを作成するか、ITOpsチームにメールでリクエストを送信しなければなりませんでした。ITOpsチームは、キュー内のすべてのリクエストを確認してログに記録し、ユーザーインターフェイスに手動でコマンドを入力して、リクエストされたリソースをそれぞれに手動で割り当てます。これには時間がかかりますが、管理対象のインフラが小規模でコンポーネントの入れ替わりも少なかった時代、多くの組織はこのプロセスで十分に機能していました。

今日のインフラは、はるかに動的なものとなっています。これは、デプロイを行うのに長い時間がかかっていたレガシーインフラ環境から、リソースのプロビジョニングと切り離しを数秒で行えるAPI駆動型のクラウド環境に移行したためです。今日、組織は毎週何千もの開発環境やマイクロサービスを立ち上げることもあるため、手動でインフラを管理するのは現実的ではありません。これでは、管理者は必要に応じてワークロードのキャパシティを調整するために毎日何千ものチケットを送信する必要があり、さらにリクエストの処理がすべて完了するまでの待機時間も長くなります。

GitOpsはこれよりもはるかに効率の高いソリューションで、インフラのプロビジョニングと設定を行うための手動プロセスを自動化することができます。開発者は、アプリケーションコード内にサービスレベル目標を宣言し、インフラを自動的に拡張することでそれらの目標を維持することができます。そのため、開発者が普段から馴染んでいる手法で、アプリケーション開発に使用しているのと同じバージョン管理システムを使ってインフラを管理できます。つまり、より迅速で予測可能なデプロイ、よりシームレスなコード管理、そして全体的な生産性の向上につながります。

GitOpsの主要なプラクティスと不変なインフラ

GitOpsの3つの主要プラクティスには、以下が挙げられます。

1. 宣言型設定：GitOpsは、宣言型記述を使用して、ターゲット環境のインフラまたはアプリケーションの望ましい状態を定義します。宣言型記述のコードは、システム全体の信頼できる唯一の情報源として、一元化されたGitリポジトリ(repo)に置かれます。
2. Gitワークフロー：あらゆる変更は、Gitに置かれたコードや設定ファイルに対して行われます。プルリクエストが承認されてマージされると、本番環境はリポジトリの新しい状態に自動的に同期されます。
3. 設定とデプロイの分離：変更は、プルベースのデプロイを使用してターゲット環境に適用されます。これにより、変更はメインプロジェクトから分離されます。

GitOpsの3つの重要なプラクティスには、宣言型設定、Gitワークフロー、設定とデプロイの分離が挙げられます。

不変なインフラの役割

GitOpsは、開発者が不変なインフラ(Immutable Infrastructure)で作業することを推奨しています。変更可能(Mutable)と不変(Immutable)は、2つの異なるタイプのインフラ環境です。変更可能なインフラは、プロビジョニング後でも、たとえば新しい仮想マシンを追加するなどの変更が行えます。一方、不変なインフラは、プロビジョニング後に変更することはできません。どちらの環境にも、メリットとデメリットが伴います。

変更可能なインフラでは、既存のサーバーを特定のアプリや開発ニーズに合わせてカスタマイズでき、開発者は新しいサーバーを構築する必要がありません。そのため、インフラが各ユーザーのニーズを満たすことができ、大きなメリットがもたらされます。

不変な環境では、より厳格になっています。インフラコンポーネントは特定の仕様に適合するように構築され、一度インフラがプロビジョニングされると、臨時の変更はできません。何らかの変更が必要であれば、新しい要件に基づいてまったく新しいインフラを構築する必要があります。このシステムには多くのデメリットがありますが、不変のインフラは設定のずれをなくし、技術的な問題の特定と解決を容易にし、開発から本番までのテストの一貫性を確保します。

GitOpsは不変なインフラのこの特性を活用して、デプロイ後の設定のずれやその他の変更のリスクを最小限に抑え、インフラの望ましい状態を維持できるようにします。不変なインフラを宣言型設定と組み合わせることで、インフラがクラッシュした場合に完全に復旧させることもできます。開発者はまた、別の形の不変なインフラを使用することも増えてきています。たとえば、Dockerコンテナは(少なくともベストプラクティスでは)不変です。

GitOpsとDevOpsの比較

GitOpsとDevOpsはどちらも、開発者エクスペリエンスを中心に設計されています。ツールやプラクティスには重複する部分がある一方で、両者には大きな違いもあります。

DevOpsとは、組織がより速いペースで製品を開発し、改善できるようにするための文化であり、プラクティスです。GitOpsは、インフラのプロビジョニングと管理のための手法であり、特定のツールであるGitを中心に設計されています。DevOpsは主に、開発チームと運用チーム間のコラボレーションを促進するために、組織の文化を変えることに重点を置いています。GitOpsは、バージョン管理やCI/CDなどのDevOpsのプラクティスをインフラ管理に適用するためのツールやフレームワークを提供します。

DevOpsとGitOpsにこのような違いはあっても、原則やプラクティスやツールを共有していることから、1つの組織内で容易に共存させることができます。なお、DevOpsを実践している組織がGitOpsを採用する必要はありませんが、GitOpsを採用しようとしている組織はDevOpsをすでに実践している可能性が高いことには注意が必要です。

GitOpsでのKubernetesの使用

Kubernetesなど最新のクラウドネイティブツールは宣言的に定義されるため、これがGitOpsの人気を押し上げています。宣言型システムであるKubernetesは、理想的なクラスター設定はどのような状態であるべきかを把握しており、システムの現在の状態を継続的に監視して、望ましい状態と比較しながら自動的に調整を行います。

この技法により、開発者はシステムの理想的な状態を定義し、GitでKubernetesの設定ファイルのバージョン管理を行えます。システム管理が容易になることはもちろん、デプロイで問題が発生した場合には以前のバージョンにロールバックすることも可能です。全体として、GitOpsは、Kubernetesとクラウドネイティブアプリケーションの開発、およびアプリケーションのデプロイの集約とエンドツーエンドの管理を向上させます。

GitOpsのメリットと課題

GitOpsには、以下のようなさまざまなメリットがあります。

• 慣れ親しんだツールとプラクティス：GitOpsでは、チームがアプリケーション開発ですでに使っているのと同じ数多くのツールやプラクティスを使用してITインフラを管理できます。Gitは大半の開発者にとって使い慣れたツールであり、バージョン管理やCI/CDはDevOpsで実践されています。
• 生産性の向上：GitOpsは開発エクスペリエンスを中心に構築されているため、開発者の作業には熟知しているツールやプロセスを使用でき、ワークフローに新しいツールを導入する必要はありません。同じ理由から、新しい開発者が慣れるのにも、数カ月ではなく数日で済みます。
• デプロイの迅速化と高頻度化：GitOpsのワークフローにより、チームは1日に複数回のリリース、瞬時のデプロイ、リアルタイムでの可視化が行えるため、問題が発生した場合にも変更をロールバックできます。つまり、市場投入までの時間を短縮できることになります。
• 追跡可能な変更：すべてがGitリポジトリで行われるため、システムへのあらゆる変更がGitログで追跡可能です。開発チームは、誰が変更を行ったのか、あるバージョンから次のバージョンにどのような変更が加えられたのかを簡単に確認できます。
• ロールバックの高速化：デプロイによって環境がダウンした場合、Gitを使用して以前のバージョンに簡単に戻すことができます。
• 知識の共有しやすさ：Gitリポジトリを使用すると、チームは簡単に情報を取得したり共有したりできます。たとえば、開発者がインフラの変遷を把握したい場合は、Gitリポジトリを複製して過去のコミットを確認するだけです。

GitOpsには、課題になりそうなこともいくつか考えられます。

• 一貫した標準の欠如：新しい技術プラクティスではありがちな話ですが、GitOpsも業界全体で同じように定義されているわけではありません。幸いなことに、GitOpsの基本原則をより明確に定義することを目指し、2020年11月にAmazon、Codefresh、GitHub、Weaveworksにより、CNCFオープンコミュニティプロジェクトとしてGitOpsワーキンググループが設立されました。
• 問題規模の拡大：企業のIT環境がモノリポジトリへと向かうなか、新しいアプリケーションによってデプロイリポジトリの数が増えると、それぞれに適切なアクセス権を設定し、必要なエージェントに同期させなければなりません。複雑な環境では、この作業に論外なほどの時間がかかる可能性があります。また、Gitリポジトリや設定ファイルの数が多くなると、環境内で発生している出来事を把握しにくくなります。
• 熟練した人材と支持者の不足：GitOpsはまだ比較的新しいテクノロジーであるため、GitOpsを実行、管理し、浸透させていくことができる熟練したエンジニアを見つけるのは難しいといえるでしょう。また、組織の多くはDevOpsを採用したばかりということを考えると、主流ではない手法を支持するよう上層部を説得することは非常に困難です。

GitOpsの導入

GitOpsはDevOpsのプラクティスとツールを使用するため、DevOps文化が成熟していることが、導入するうえでの前提条件となります。そうなっていれば、開発者はGitOpsのワークフローにすぐ慣れることができます。

もう1つの要件は、宣言的に管理できるインフラです。このような理由から、GitOpsはKubernetesクラスターやクラウドネイティブアプリ開発の管理によく採用されています。また、従来のITシステムを宣言的にモデリングできるAnsibleなど、他のインフラやデプロイパイプラインでもGitOpsを使用できます。

GitOpsワークフローを実装するためのツールも必要です。GitOpsツールは数多く提供されていますが、最も広く利用されているものとしてはFluxとArgoCDが挙げられます。

エコシステム全体に1回でGitOpsを実装しようとするのではなく、段階的なアプローチを取りましょう。ネットワーク構成管理、仮想マシンOS、その他のリソースから着手し、その望ましい状態を定義します。次に、Infrastructure as Codeを使用して現在の状態に変更を加え、Gitリポジトリを使ってリソースの状態の変化を追跡し、そこからCI/CDシステムで更新をデプロイします。エコシステム全体にGitOpsを確実に適用できるようになるまで、GitOpsワークフローの開発とプロセスの文書化を継続して、開発チームが活用できるようにしてください。

GitOps導入のベストプラクティス

GitOpsの原則とベストプラクティスをいくつかご紹介します。

• リポジトリよりもブランチを選択：リポジトリは、チームごとに1つに制限します。さらにリポジトリが必要な場合は、代わりにブランチを使用します。これにより、システム全体の概要を把握しやすくなり、時間の節約はもちろん、開発者相互のコード共有やフィードバックも容易になります。
• プッシュではなくプル：新しいコードを公開する際は、プッシュよりもプル(マージ)リクエストを使用することをおすすめします。プルリクエストには通常、特定の変更が行われた理由とその作業者に関する有用なサポート情報が含まれているため、トラブルシューティングやデバッグ作業に役立ちます。
• 自動化：エラーなしで正確に繰り返せるようにするためには、手動タスクの自動化が欠かせません。つまり、テスト済みでバグが取り除かれたスクリプトによって、すべてのアクションが実行される必要があります。
• 監視：システム(新機能を含む)とアプリケーションの状態を継続的に監視し、障害、ボトルネック、その他の異常がないか確認して、CI/CDシステムが自動応答をトリガーできるようにすることが重要です。こうしておけば、問題をより迅速に解決し、必要に応じて以前の状態に自動的にロールバックできます。

結論：GitOpsは最新のインフラに不可欠である

最新のインフラに求められるニーズを考えると、インフラの自動化は必須となっています。GitOpsは、開発者がすでに使っているツールやプラクティスを活用することで、簡単に開始できます。1つの小規模なパイロットプロジェクトから始めて、より復元力の高いインフラ構築への第一歩を踏み出しましょう。

このブログはこちらの英語ブログの翻訳です。