すべてのチームは、プロセスを合理化し、迅速に提供し、環境を安定させるための銀色の銃弾を探しています。近年非常に採用が増えているアプローチの1つがGitOpsです。この言葉は、また別の流行のDevOps用語に見えるかもしれませんが、チームがインフラやデプロイメントを管理する方法に革新的な変化をもたらすものです。
この記事では、GitOps、その内容、そして従来のDevOpsソリューションとはどのように異なるかを讨论します。
GitOpsとは?
GitOpsは、Gitベースのワークフローをインフラの自動化とアプリケーションのデプロイメントに使用するフレームワークです。その核心では、開発者がソフトウェアの変更を管理するために使用する同じ原則と実践を運用に適用しています。簡単に言えば、GitOpsはGitリポジトリが唯一の真実の源であり、変更や修正はプルリクエストを通じて行い、自動化システムがこれらの変更を対象環境に適用する実践です。
GitOpsの主要な原則
GitOpsの主な特徴は以下の通りです：
Gitが真実の源
インフラ、設定、アプリケーションのデプロイメントを含むすべてをGitリポジトリに保存しなければなりません。これにより、すべてをコントロールできます。クラスタはGitリポジトリから設定、デプロイメント設定、環境管理ツールを読み取り、適用します。ツールは変更を追跡し、リポジトリに変更が検出されると、自動的にこの変更を適用します。
宣言的インフラ
すべてのものの宣言された状態をYAMLまたはJSONを使用して定義する必要があります。その状態はツールによって実際の状態と比較され、宣言された状態と一致するようにするためにできる限りのことが行われます。
自動化とCI/CD
Gitリポジトリに加えられた変更は自動的に操作を実行するべきです。たとえば、Jenkins、ArgoCD、またはFluxなどが新しい構成やアプリケーションのバージョンを自動的に展開してシステムがリポジトリの状態と一致するようにします。この頭字語の「CD」の部分が特に重要であり、変更は継続的に表示され、可能な限り迅速に行われるべきです。
セルフヒーリングと継続的調整
GitOpsツールには通常、システムを監視し、見たものがリポジトリに格納されているものと一致しているかどうかを判断する方法があります。何か異なる点が見つかった場合、ツールは環境を「ヒーリング」して、リポジトリに記載されている内容に変更します。
DevOpsからGitOpsへの移行
GitOpsの具体的な内容やそれがDevOpsとどのように矛盾するかに踏み込む前に、クラシックなDevOpsの貢献を理解することが重要です。DevOpsは、開発と運用チームを管理し、協力を促進し、テスト、展開、およびインフラのプロビジョニングなどの自動化プロセスを最適化する方法を指します。
一般に、DevOps手順には、Jenkins、Kubernetes、Docker、Ansibleなどのツールを adopt して、ソフトウェア開発ライフサイクル内で継続的インテグレーションおよび継続的デリバリー（CI/CD）プロセスを develop し、ソフトウェアのデリバリースピードを向上させるものです。
GitOpsはどこにフィットするのか？
GitOpsはこれらのDevOps進化原理に基づいていますが、より構造化された方法で。GitのアプローチをDay 2オペレーションにより高度に統合します。従来のDevOps技術を使用している間、異なる複数のチームが同時にインフラストラクチャとアプリケーションコードに取り組む可能性が高く、リスクにつながる可能性があります。これらすべての活動はGitの下で行われ、インフラストラクチャも含め、どんな小さな変更であっても等しくバージョン管理されます。
GitOpsワークフローの導入による利点
安全性とコンプライアンスの向上
バージョン管理されたGitリポジトリをインフラストラクチャとアプリケーションに interact し、変更を行う唯一の方法として持つことの利点之一は、検証可能な監査トレールを生成することです。
開発者体験の向上
開発者は、Gitなどのすでに慣れ親しんでいるツールを使用してインフラ管理を行うことができます。開発者がインフラ管理に同じツールを使用することを許可することで、GitOpsは余計なツールの必要性を排除し、GitOpsワークフローの導入を容易にします。
迅速なロールバックと災害復旧
多くの伝統的なDevOpsパイプラインの課題の1つは、変更のロールバックが脆弱であることです。GitOpsを使用すると、リポジトリの以前のバージョンをチェックアウトしてシステム全体を以前の状態にロールバックすることができます。これにより、災害シナリオでの復旧時間を大幅に短縮することができます。
環境間の統一性と一貫性
Gitは真実の源であり、Git内のものは開発ブランチからプロダクションブランチまでシステムの状態を反映するべきです。もはや「私のマシンでは動作する」と言う必要はありません。「It works on my machine.」異なる環境での異なる設定は、手動で変更を行う際の典型的なデプロイメントの問題です。
拡張性
GitOpsは伝統的な設定管理ソリューションよりもさらに拡張可能です。宣言的であるという概念を導入し、命令的ではなくなります。環境を1ヶ所で変更する代わりに、GitOpsでは環境を一度記述します。その後、ツールが環境が正しいまま維持され、すべてのシステムでその記述に合ったマシンを構築します。
GitOpsがDevOpsの実践をどのように変えるか
GitOpsはDevOpsのCI/CDツールおよびプロセスにおいて、完全に新しい左寄せのシフトです。以下は、いくつかの先進的な伝統的なDevOpsソリューションが現在GitOpsを導入しているか、将来GitOpsの実践を取り入れる計画である例です:
1. インフラストラクチャ・アズ・コード
DevOpsがインフラストラクチャを作成し、管理し、さらにこれらの手続きを自動化できるすることは必須です。DevOpsのマスターはTerraformやCloudFormationなどのツールを使用するかもしれませんが、別の専門家は同じスクリプトを実行して完全に異なる環境を作成することができます。ここでインフラストラクチャ・アズ・コードが登場します。これは、すべてのIaC設定をGitに保存することを主に意味します。このシステムでは、すべてが自動化され、さらに重要な的是、継続的にチェックされます。
2. CI/CDパイプライン
伝統的なDevOpsのワークロードでは、CI/CDパイプラインがコードのテスト、ビルド、デプロイを自動化します。しかし、GitOpsでは、CI/CDパイプラインもインフラストラクチャの変更をデプロイするために使用されます。ArgoCDやFluxなどのツールは、従来のCI/CDパイプラインを強化し、Gitリポジトリを監視し、変更がプッシュされるたびに環境を自動的に更新することで、開発者にとってさらに多くのことを行い、サイクルを速めます。
3. 監視と可視化
GitOpsは監視と可視化に焦点を当てており、それにより信頼性が高いです。GitOpsで使用されるツールは、ライブ環境を連続的に監視し、Gitで定義された状態と比較します。したがって、システムが定義された状態から逸脱した場合、自動的にロールバックします。自動ロールバックは問題のある環境を迅速に復旧し、ダウンタイムを最小限に抑え、システムの信頼性を高めます。
結論
結論として、GitOpsは単なる流行語ではなく、従来のDevOps実践を変革できる強力なアプローチです。インフラとデプロイメントをコードとして扱うことで、GitOpsは手動操作の必要性を排除し、すべての環境で望ましい状態を確保します。
DevOpsのCI/CDサービスを現代化することを考えるチームにとって、GitOpsワークフローの採用は、望む結果をより効率的かつ信頼性高く達成する方法です。ArgoCDやFluxなどのツールを使用することで、GitOpsは明るい未来を持ち、将来のDevOpsの風景の主要な一部になることができます。
Source:
https://dzone.com/articles/an-introduction-to-gitops