私たちのほとんどは、IT ブロゴスフィアやカンファレンスでまた新しい用語が登場したことに気づき、遅かれ早かれ同様の質問をします。 単なる流行語、「バズワード」、それとも本当に注目し、研究し、新たな地平を約束する価値のあるものでしょうか？」 この用語でも同じことが私に起こりました GitOps 少し前。 多くの既存の記事と会社の同僚の知識で武装 , これはどんな獣なのか、実際にどのような使い方ができるのかを考えてみました。
ところで、用語の斬新さについてですが、 GitOps 私たちの最近の調査では、調査対象者の半数以上がまだその原則に取り組み始めていないということも述べられています。
したがって、インフラストラクチャ管理の問題は新しいものではありません。 多くのクラウド プロバイダーは十数年にわたって一般の人々に利用可能であり、インフラストラクチャを担当するチームの作業をシンプルかつ簡単にするべきだったと思われます。 しかし、アプリケーション開発プロセス (自動化がこれまでにないレベルに達している) と比較すると、特にフォールト トレランス、柔軟性、拡張性、弾力性に対する今日の要件を考慮すると、インフラストラクチャ プロジェクトには依然として多くの手動タスクが含まれ、専門知識と専門知識が必要です。
クラウド サービスはこれらの要件をうまく満たしており、アプローチの開発に大きな推進力を与えたのもクラウド サービスでした。 IaC。 これは理解できます。 結局のところ、完全な仮想データ センターの構成が可能になりました。物理的なサーバー、ラック、ネットワーク コンポーネントはなく、スクリプトと構成ファイルを使用してインフラストラクチャ全体を記述することができます。
では、その違いは一体何なのでしょうか？ GitOps から IaC? この疑問から私は調査を始めました。 同僚と話し合った結果、次のような比較を思いつくことができました。
GitOps
IaC
すべてのコードは git リポジトリに保存されます
コードのバージョン管理はオプションです
宣言型コードの説明/冪等性
宣言的記述と命令的記述の両方が受け入れられます
変更はマージ リクエスト/プル リクエスト メカニズムを使用して有効になります。
同意、承認、協力は任意です
アップデートのロールアウトプロセスは自動化されています
更新プログラムのロールアウト プロセスは標準化されていません (自動、手動、ファイルのコピー、コマンド ラインの使用など)。
言い換えれば、 GitOps まさに原則の適用を通じて誕生しました IaC。 まず、インフラストラクチャと構成をアプリケーションと同じ方法で保存できるようになりました。 コードは保存しやすく、共有、比較、およびバージョン管理機能の使用も簡単です。 バージョン、ブランチ、履歴。 そしてこれらすべては、チーム全体がアクセスできる場所に公開されています。 したがって、バージョン管理システムの使用は完全に自然な展開となりました。 特に git が最も人気があります。
一方で、インフラ管理プロセスは自動化できるようになりました。 これがより速く、より確実に、より安価に実行できるようになりました。 さらに、CI/CD の原則はソフトウェア開発者の間ですでに知られており、普及していました。 すでに知られている知識とスキルを新しい分野に移して適用するだけで済みました。 ただし、これらの実践はコードとしてのインフラストラクチャの標準定義を超えていたため、この概念は GitOps.
好奇心 GitOpsもちろん、どのベンダーにも関連付けられた製品、プラグイン、またはプラットフォームではないという事実も含まれます。 これはむしろパラダイムであり、一連の原則であり、私たちがよく知っている別の用語である DevOps に似ています。
会社 私たちは、この新しい用語について、理論的定義と実践的定義という XNUMX つの定義を作成しました。 理論的なことから始めましょう。
GitOps は、バージョン管理、コラボレーション、オーケストレーション、CI/CD など、アプリケーション開発に使用される最良の DevOps 原則を採用し、それらをインフラストラクチャ管理の自動化の課題に適用する方法論です。
全工程 GitOps 既存のツールを使用して作業します。 すべてのインフラストラクチャ コードは、すでに使い慣れた Git リポジトリに保存され、変更は他のプログラム コードと同じ承認プロセスを経て、ロールアウト プロセスは自動化されているため、人的エラーを最小限に抑え、信頼性と再現性を高めることができます。
実践的な観点から説明すると、 GitOps 次のようにします。
この公式の主要なコンポーネントの XNUMX つとして、コードとしてのインフラストラクチャについてはすでに説明しました。 残りの参加者を紹介しましょう。
マージ リクエスト (別名プル リクエスト)。 プロセス用語では、MR はコード変更を適用してからブランチをマージする要求です。 しかし、私たちが使用するツールの観点から見ると、これは行われているすべての変更の全体像を把握する機会と言えます。特定の数のコミットから収集されたコードの差分だけでなく、コンテキスト、テスト結果、および最終的に期待される結果。 インフラストラクチャ コードについて話している場合、インフラストラクチャが正確にどのように変更されるか、新しいリソースがどれだけ追加または削除され、変更されるかに興味があります。 できれば、より便利で読みやすい形式でください。 クラウド プロバイダーにとって、この変更が財務的にどのような影響を与えるかを知っておくことは良いことです。
しかし、MR はコラボレーション、対話、コミュニケーションの手段でもあります。 抑制と均衡のシステムが機能する場所です。 簡単なコメントから正式な承認や承認まで。
最後のコンポーネントである CI/CD は、すでにご存知のとおり、インフラストラクチャの変更とテスト (単純な構文チェックからより複雑な静的コード分析まで) のプロセスを自動化することを可能にします。 また、その後のドリフト、つまりシステムの実際の状態と望ましい状態の間の差異の検出にも使用されます。 たとえば、許可されていない手動変更やシステム障害の結果として。
はい、その用語は GitOps まったく新しいものを紹介したり、車輪を再発明したりするのではなく、すでに蓄積された経験を新しい分野に適用するだけです。 しかし、ここが彼の強みです。
これが実際にどのように見えるかに突然興味を持った場合は、ぜひご覧ください。 ここでは、GitLab の使用方法を段階的に説明します。
-
GitOps の基本原則を実装する
-
クラウド インフラストラクチャの作成と変更 (Yandex Cloud の例を使用)
-
アクティブモニタリングを使用して、望ましい状態からのシステムドリフトを自動検出
https://bit.ly/34tRpwZ
出所： habr.com