🥇GitOps とは何ですか? | プロホスター

ノート。翻訳。: 最近の出版後材料 GitOps のプルおよびプッシュメソッドについては、このモデル全般に関心が寄せられていましたが、このトピックに関するロシア語の出版物はほとんどありませんでした (ハブレに関する出版物はまったくありませんでした)。したがって、ほぼ XNUMX 年前ではありますが、別の記事の翻訳を皆さんにご提供できることをうれしく思います。 — Weaveworks 社の代表であり、その代表が「GitOps」という用語を生み出しました。本文では、アプローチの本質と既存のアプローチとの主な違いについて説明します。

XNUMX年前に私たちは出版しました GitOps の概要。当時、私たちは Weaveworks チームが完全に Kubernetes に基づいた SaaS を立ち上げ、クラウドネイティブ環境での展開、管理、監視のための一連の規範的なベストプラクティスを開発した方法を共有しました。

その記事は人気があることが判明した。他の人たちは GitOps について話し始め、GitOps のための新しいツールを公開し始めました。 git push, の開発, 秘密, 関数, 継続的インテグレーション等々。弊社ホームページに掲載されました多数出版物と GitOps のユースケース。しかし、まだ疑問を持っている人もいます。このモデルは従来のモデルとどのように異なりますか? コードとしてのインフラストラクチャ継続的デリバリー (連続配送）？ Kubernetes を使用する必要がありますか?

私たちはすぐに、次のような新しい説明が必要であることに気づきました。

多数の例とストーリー。
GitOps の具体的な定義。
従来の継続的デリバリーとの比較。

この記事では、これらすべてのトピックを取り上げてみました。 GitOps の最新の紹介と、開発者および CI/CD の観点を提供します。このモデルは一般化することができますが、主に Kubernetes に焦点を当てます。

GitOps について

アリスを想像してみてください。彼女は、忙しすぎて契約の詳細を自分で理解することができない人々に、健康保険、自動車保険、住宅保険、旅行保険を提供する Family Insurance を経営しています。彼女のビジネスは、アリスがデータサイエンティストとして銀行で働いていたときにサイドプロジェクトとして始まりました。ある日、彼女は高度なコンピュータアルゴリズムを使用すれば、より効果的にデータを分析し、保険パッケージを策定できることに気づきました。投資家がこのプロジェクトに資金を提供し、現在彼女の会社は年間 20 万ドル以上の収益を上げ、急速に成長しています。現在、さまざまな役職で 180 名の従業員が働いています。これには、Web サイト、データベースの開発、保守、顧客ベースの分析を行うテクノロジーチームが含まれます。 60 人からなるチームは、同社のテクニカルディレクターであるボブが率いています。

ボブのチームは実稼働システムをクラウドに展開します。コアアプリケーションは GKE 上で実行され、Google Cloud 上の Kubernetes を利用します。さらに、彼らは仕事でさまざまなデータや分析ツールを使用します。

Family Insurance は、コンテナーの使用を開始したわけではありませんでしたが、Docker の熱意に巻き込まれました。同社はすぐに、GKE を使用すると、新しい機能をテストするためのクラスタのデプロイが簡単になることに気づきました。 CI と Quay 用の Jenkins はコンテナレジストリを整理するために追加され、新しいコンテナと構成を GKE にプッシュするスクリプトが Jenkins 用に作成されました。

しばらく時間が経過しました。アリスとボブは、自分たちが選択したアプローチのパフォーマンスと、それがビジネスに及ぼす影響に失望しました。コンテナの導入によって、チームが期待していたほど生産性は向上しませんでした。場合によってはデプロイメントが中断されることもありましたが、コードの変更が原因かどうかは不明でした。また、構成の変更を追跡するのが難しいことも判明しました。多くの場合、新しいクラスターを作成してそこにアプリケーションを移動する必要がありました。これは、システムの混乱を解消する最も簡単な方法だったからです。アリスは、アプリケーションが開発されるにつれて状況が悪化するのではないかと心配していました (さらに、機械学習に基づいた新しいプロジェクトが準備されていました)。ボブは作業のほとんどを自動化していましたが、パイプラインが依然として不安定で、適切に拡張できず、定期的に手動介入が必要である理由を理解していませんでした。

次に、GitOps について学びました。この決定は、まさに彼らが自信を持って前進するために必要なものであることが判明しました。

アリスとボブは、Git、DevOps、およびコードワークフローとしてのインフラストラクチャについて何年も聞いてきました。 GitOps のユニークな点は、Kubernetes のコンテキストでこれらのアイデアを実装するための、決定的かつ規範的な一連のベストプラクティスを提供することです。このテーマ繰り返し上がった、を含むウィーブワークスのブログ.

Family Insurance は GitOps を導入することを決定しました。同社は現在、Kubernetes と互換性のある自動運用モデルを構築し、 スピード とともに 安定性なぜなら彼ら：

誰も気が狂うことなく、チームの生産性が XNUMX 倍になったことを発見しました。
スクリプトの提供を停止しました。代わりに、新機能に焦点を当て、エンジニアリング手法を改善できるようになりました。たとえば、カナリアロールアウトの導入やテストの改善などです。
導入プロセスが改善され、めったに失敗しないようになりました。
部分的な障害が発生した後、手動介入なしで展開を復元する機会が得られました。
中古で購入したо配送システムに対するさらなる信頼。アリスとボブは、チームを並行して作業するマイクロサービスチームに分割できることを発見しました。
各グループの努力を通じて毎日プロジェクトに 30 ～ 50 の変更を加え、新しい技術を試すことができます。
新しい開発者をプロジェクトに引き付けるのは簡単で、開発者は数時間以内にプルリクエストを使用して本番環境に更新をロールアウトする機会を得ることができます。
SOC2の枠組み内で監査に簡単に合格 (サービスプロバイダーが安全なデータ管理の要件に準拠するため。たとえば、続きを読む) ここで — 約翻訳）.

何が起こったのか？

GitOps には次の XNUMX つの要素があります。

Kubernetes とクラウドネイティブの運用モデル。コンテナー化されたクラスターとアプリケーションをデプロイ、管理、監視するための一連のベストプラクティスを提供します。エレガントなフォルムの定義 XNUMX つのスライドからルイス・ファセイラ:
開発者中心のアプリケーション管理環境を構築するためのパス。 Git ワークフローを運用と開発の両方に適用します。これは Git プッシュだけに関するものではなく、CI/CD および UI/UX ツールのセット全体の整理に関するものであることに注意してください。

Git について一言

バージョン管理システムと Git ベースのワークフローに慣れていない場合は、それらについて学ぶことを強くお勧めします。ブランチとプルリクエストの操作は、最初は黒魔術のように思えるかもしれませんが、そのメリットは努力する価値があります。ここ良い記事はじめに。

Kubernetes の仕組み

私たちの物語では、アリスとボブは、しばらく Kubernetes を使用した後、GitOps に目を向けました。実際、GitOps は Kubernetes と密接に関係しており、Kubernetes に基づくインフラストラクチャとアプリケーションの運用モデルです。

Kubernetes はユーザーに何を提供しますか?

以下に主な機能をいくつか示します。

Kubernetes モデルでは、すべてを宣言形式で記述できます。
Kubernetes API サーバーはこの宣言を入力として受け取り、クラスターを宣言に記述されている状態にしようと継続的に試みます。
宣言は、さまざまなワークロード (「アプリケーション」) を記述および管理するのに十分です。
その結果、次のような理由でアプリケーションとクラスターに変更が発生します。
- コンテナイメージの変更。
- 宣言的な仕様の変更。
- 環境内のエラー - コンテナのクラッシュなど。

Kubernetes の優れたコンバージェンス機能

管理者が構成を変更すると、Kubernetes オーケストレーターは、クラスターの状態が以下である限り、その変更をクラスターに適用します。 新しい構成には近づきません。このモデルはあらゆる Kubernetes リソースで機能し、カスタムリソース定義 (CRD) を使用して拡張できます。したがって、Kubernetes デプロイメントには次のような素晴らしい特性があります。

オートメーション: Kubernetes アップデートは、変更を適切かつタイムリーに適用するプロセスを自動化するメカニズムを提供します。
収束: Kubernetes は成功するまで更新を試行し続けます。
べき等性: 収束を繰り返し適用すると、同じ結果が得られます。
決定論: リソースが十分な場合、更新されたクラスターの状態は望ましい状態のみに依存します。

GitOps の仕組み

Kubernetes については、GitOps がどのように機能するかを説明できるほど学習しました。

Family Insurance のマイクロサービスチームに戻りましょう。彼らは普段何をしなければならないのでしょうか？以下のリストを見てください (その中に奇妙または見慣れない項目がある場合は、批判を控えて、お付き合いください)。これらは、Jenkins ベースのワークフローの単なる例です。他のツールを使用する場合は、他にも多くのプロセスがあります。

重要なことは、各更新が構成ファイルと Git リポジトリへの変更で終了することがわかります。 Git に対するこれらの変更により、「GitOps オペレーター」がクラスターを更新します。

1.作業プロセス: "Jenkins ビルド - マスターブランチ'。
タスクリスト：

Jenkins はタグ付けされた画像を Quay にプッシュします。
Jenkins は、構成チャートと Helm チャートをマスターストレージバケットにプッシュします。
クラウド機能は、構成とチャートをマスターストレージバケットからマスター Git リポジトリにコピーします。
GitOps オペレーターはクラスターを更新します。

2. Jenkins ビルド - リリースまたはホットフィックスブランチ:

Jenkins はタグなしの画像を Quay にプッシュします。
Jenkins は、構成チャートと Helm チャートをステージングストレージバケットにプッシュします。
クラウド機能は、構成とチャートをステージングストレージバケットからステージング Git リポジトリにコピーします。
GitOps オペレーターはクラスターを更新します。

3. Jenkins ビルド - 開発または機能ブランチ:

Jenkins はタグなしの画像を Quay にプッシュします。
Jenkins は、構成チャートと Helm チャートを開発ストレージバケットにプッシュします。
クラウド機能は、構成とチャートを開発ストレージバケットから開発 Git リポジトリにコピーします。
GitOps オペレーターはクラスターを更新します。

4. 新しいクライアントの追加:

マネージャーまたは管理者 (LCM/ops) は Gradle を呼び出して、最初にネットワークロードバランサー (NLB) を展開して構成します。
LCM/ops は、新しい構成をコミットして、更新用のデプロイメントを準備します。
GitOps オペレーターはクラスターを更新します。

GitOps の簡単な説明

各環境の宣言仕様を使用して、システム全体の望ましい状態を記述します (このストーリーでは、Bob のチームは Git でシステム構成全体を定義します)。
- Git リポジトリは、システム全体の望ましい状態に関する唯一の信頼できる情報源です。
- 望ましい状態へのすべての変更は、Git のコミットを通じて行われます。
- 必要なクラスターパラメーターはすべて、クラスター自体でも監視できます。このようにして、それらが一致する (収束する) かどうかを判断できます。 収束する) または異なる (発散、 発散する) 望ましい状態と観察された状態。
望ましい状態と観察された状態が異なる場合は、次のようになります。
- 遅かれ早かれターゲットと観測された状態を自動的に同期させる収束メカニズムがあります。クラスター内では、Kubernetes がこれを行います。
- プロセスはすぐに開始され、「変更がコミットされました」というアラートが表示されます。
- 設定可能な一定の時間が経過すると、状態が異なる場合に「diff」アラートを送信できます。
このようにして、Git 内のすべてのコミットにより、クラスターに対する検証可能かつ冪等の更新が行われます。
- ロールバックとは、以前に望ましい状態に収束することです。
収束は最終的です。その発生は次のように示されます。
- 一定期間、差分アラートがありません。
- 「収束」アラート (Webhook、Git ライトバックイベントなど)。

ダイバージェンスとは何ですか?

もう一度繰り返してみましょう: 必要なすべてのクラスタープロパティがクラスター自体で監視可能である必要があります.

相違の例をいくつか示します。

Git のブランチのマージによる構成ファイルの変更。
GUI クライアントによって行われた Git コミットによる構成ファイルの変更。
Git での PR による望ましい状態への複数の変更、その後のコンテナーイメージのビルドと構成の変更。
エラー、「不正な動作」を引き起こすリソースの競合、または元の状態からの単純なランダムな逸脱によるクラスターの状態の変化。

収束のメカニズムは何ですか?

いくつかの例：

コンテナーとクラスターの場合、収束メカニズムは Kubernetes によって提供されます。
同じメカニズムを使用して、Kubernetes ベースのアプリケーションと設計 (Istio や Kubeflow など) を管理できます。
Kubernetes、イメージリポジトリ、Git 間の運用上の相互作用を管理するメカニズム。 GitOps オペレーター Weave Fluxの一部ですウィーブクラウド.
ベースマシンの場合、収束メカニズムは宣言的かつ自律的である必要があります。私たち自身の経験から言えますが、テラフォームこの定義に最も近いものですが、それでも人間による制御が必要です。この意味で、GitOps はコードとしてのインフラストラクチャの伝統を拡張します。

GitOps は、Git と Kubernetes の優れたコンバージェンスエンジンを組み合わせて、活用モデルを提供します。

GitOps を使用すると、次のことが可能になります。 記述および観察できるシステムのみを自動化および制御できます。.

GitOps は、クラウドネイティブスタック全体 (Terraform など) を対象としています。

GitOps は単なる Kubernetes ではありません。システム全体を宣言的に駆動し、コンバージェンスを使用したいと考えています。システム全体とは、Kubernetes で動作する環境のコレクション (たとえば、「開発クラスター 1」、「実稼働」など) を意味します。各環境には、マシン、クラスター、アプリケーションに加え、データ、モニタリングを提供する外部サービスのインターフェイスが含まれます。など

この場合、ブートストラップ問題にとって Terraform がいかに重要であるかに注目してください。 Kubernetes はどこかにデプロイする必要がありますが、Terraform を使用すると、同じ GitOps ワークフローを適用して、Kubernetes とアプリケーションの基盤となる制御層を作成できることになります。これは役立つベストプラクティスです。

GitOps の概念を Kubernetes 上のレイヤーに適用することに重点が置かれています。現時点では、Istio、Helm、Ksonnet、OpenFaaS、Kubeflow 用の GitOps タイプのソリューションのほか、たとえば Pulumi 用のソリューションがあり、クラウドネイティブ用のアプリケーションを開発するためのレイヤーを作成します。

Kubernetes CI/CD: GitOps と他のアプローチの比較

前述したように、GitOps には次の XNUMX つの要素があります。

上で説明した Kubernetes とクラウドネイティブのオペレーティングモデル。
開発者中心のアプリケーション管理環境へのパス。

多くの人にとって、GitOps は主に Git プッシュに基づくワークフローです。私たちも彼のことが好きです。しかし、それだけではありません。次に、CI/CD パイプラインを見てみましょう。

GitOps により Kubernetes の継続的デプロイ (CD) が可能になります

GitOps は、個別の「デプロイメント管理システム」の必要性を排除する継続的デプロイメントメカニズムを提供します。 Kubernetes がすべての作業を行います。

アプリケーションを更新するには、Git での更新が必要です。これは、望ましい状態へのトランザクション更新です。その後、更新された説明に基づいて、Kubernetes 自体によってクラスター内で「デプロイ」が行われます。
Kubernetes の動作の性質上、これらの更新は集中的です。これにより、すべての更新がアトミックである継続的な展開のメカニズムが提供されます。
注意：ウィーブクラウドは、Git と Kubernetes を統合し、クラスターの望ましい状態と現在の状態を調整して CD を実行できるようにする GitOps オペレーターを提供します。

kubectl とスクリプトなし

クラスターの更新に Kubectl を使用することは避け、特にスクリプトを使用して kubectl コマンドをグループ化することは避けてください。代わりに、GitOps パイプラインを使用すると、ユーザーは Git 経由で Kubernetes クラスターを更新できます。

利点は次のとおりです。

右。一連の更新を適用、統合し、最終的に検証することで、アトミックなデプロイの目標に近づくことができます。対照的に、スクリプトを使用しても、収束の保証はありません (これについては以下で詳しく説明します)。
セキュリティ. 引用 Kelsey Hightower: 「Kubernetes クラスターへのアクセスは、自動化ツールと、デバッグまたは保守を担当する管理者に制限してください。」こちらも参照私の出版物安全性と技術仕様への準拠について、また Homebrew のハッキングに関する記事不用意に書かれた Jenkins スクリプトから資格情報を盗むことによって。
ユーザー体験。 Kubectl は、非常に複雑な Kubernetes オブジェクトモデルの仕組みを公開します。理想的には、ユーザーはより高い抽象レベルでシステムと対話する必要があります。ここで私は再びケルシーに言及し、視聴することをお勧めしますそのような履歴書.

CIとCDの違い

GitOps は既存の CI/CD モデルを改善します。

最新の CI サーバーはオーケストレーションツールです。特に、これは CI パイプラインを調整するためのツールです。これらには、ビルド、テスト、トランクへのマージなどが含まれます。CI サーバーは、複雑な複数ステップのパイプラインの管理を自動化します。よくある誘惑は、Kubernetes 更新のセットをスクリプト化し、それをパイプラインの一部として実行して変更をクラスターにプッシュすることです。実際、これは多くの専門家が行っていることです。ただし、これは最適ではありません。その理由は次のとおりです。

更新をトランクにプッシュするには CI を使用する必要があり、Kubernetes クラスターはそれらの更新に基づいて自体を変更して、CD を内部で管理する必要があります。私たちはそれをそう呼んでいます CD用プルモデルCI プッシュモデルとは異なります。 CDは一部です ランタイムオーケストレーション.

CI サーバーが Kubernetes の直接更新を介して CD を実行すべきではない理由

Kubernetes への直接更新を一連の CI ジョブとして調整するために CI サーバーを使用しないでください。これが私たちが話しているアンチパターンですすでに言ったあなたのブログで。

アリスとボブの話に戻りましょう。

彼らはどのような問題に直面しましたか? ボブの CI サーバーは変更をクラスターに適用しますが、そのプロセス中にクラッシュした場合、ボブはクラスターがどのような状態にある (またはあるべきである) のか、またそれを修正する方法がわかりません。成功した場合も同様です。

Bob のチームが新しいイメージを構築し、そのイメージをデプロイするためにデプロイメントにパッチを適用したと仮定します (すべて CI パイプラインから)。

イメージが正常にビルドされてもパイプラインが失敗した場合、チームは次のことを解決する必要があります。

アップデートは展開されましたか?
新しいビルドを起動するのでしょうか? これにより、同じ不変イメージの XNUMX つのビルドが存在する可能性など、不必要な副作用が発生する可能性がありますか?
ビルドを実行する前に次のアップデートを待ったほうがよいでしょうか?
正確に何が間違っていたのでしょうか? どのステップを繰り返す必要がありますか (また、どのステップを繰り返しても安全ですか)?

Git ベースのワークフローを確立しても、Bob のチームがこれらの問題に遭遇しないという保証はありません。コミットプッシュ、タグ、その他のパラメータで間違いを犯す可能性は依然としてあります。ただし、このアプローチは依然として、明示的な全か無かのアプローチにはるかに近いものです。

要約すると、CI サーバーが CD を処理すべきではない理由は次のとおりです。

更新スクリプトは常に決定的であるとは限りません。間違いを犯しやすいのです。
CI サーバーは宣言型クラスターモデルに収束しません。
冪等性を保証するのは困難です。ユーザーはシステムの詳細なセマンティクスを理解する必要があります。
部分的な障害から回復することはより困難です。

Helm に関する注意: Helm を使用する場合は、Helm を次のような GitOps オペレーターと組み合わせることをお勧めします。フラックスヘルム。これは確実に収束するのに役立ちます。 Helm 自体は決定論的でも原子的でもありません。

Kubernetes の継続的デリバリーを実装する最良の方法としての GitOps

アリスとボブのチームは GitOps を実装し、ソフトウェア製品の操作がはるかに簡単になり、高いパフォーマンスと安定性を維持できることに気づきました。彼らの新しいアプローチがどのようなものかを示す図でこの記事を終えましょう。ここでは主にアプリケーションとサービスについて話しますが、GitOps を使用してプラットフォーム全体を管理できることに注意してください。

Kubernetesのオペレーティングモデル

次の図を見てください。これは、Git とコンテナーイメージリポジトリを、次の XNUMX つの調整されたライフサイクルの共有リソースとして提供します。

Git に対してファイルを読み書きし、コンテナーイメージのリポジトリを更新できる継続的統合パイプライン。
デプロイメントと管理および可観測性を組み合わせたランタイム GitOps パイプライン。 Git に対してファイルの読み取りと書き込みを行い、コンテナーイメージをダウンロードできます。

主な発見は何ですか?

関心事の分離注：両方のパイプラインは、Git またはイメージリポジトリを更新することによってのみ通信できることに注意してください。言い換えれば、CI とランタイム環境の間にはファイアウォールがあります。私たちはこれを「不変ファイアウォール」と呼んでいます。 (不変ファイアウォール)、すべてのリポジトリ更新により新しいバージョンが作成されるためです。このトピックの詳細については、スライド 72 ～ 87 を参照してください。このプレゼンテーション.
任意の CI および Git サーバーを使用できます: GitOps はあらゆるコンポーネントで動作します。お気に入りの CI および Git サーバー、イメージリポジトリ、テストスイートを引き続き使用できます。市場にある他のほとんどすべての継続的デリバリーツールには、独自の CI/Git サーバーまたはイメージリポジトリが必要です。これは、クラウドネイティブの開発における制限要因になる可能性があります。 GitOps を使用すると、使い慣れたツールを使用できます。
統合ツールとしてのイベント: Git 内のデータが更新されるとすぐに、Weave Flux (または Weave Cloud オペレーター) がランタイムに通知します。 Kubernetes が変更セットを受け入れるたびに、Git が更新されます。これにより、以下に示すように、GitOps のワークフローを整理するためのシンプルな統合モデルが提供されます。

まとめ

GitOps は、最新の CI/CD ツールに必要な強力な更新保証を提供します。

オートメーション;
収束;
べき等性。
決定主義。

これは、クラウドネイティブ開発者に運用モデルを提供するため、重要です。

システムを管理および監視するための従来のツールは、ランブック内で運用する運用チームに関連付けられています。 (一連の日常的な手順と操作 - おおよその翻訳)、特定の展開に関連付けられています。
クラウドネイティブ管理では、開発チームが迅速に対応できるように、可観測性ツールはデプロイメントの結果を測定する最良の方法です。

さまざまなクラウドに分散した多数のクラスターと、独自のチームと展開計画を持つ多数のサービスを想像してください。 GitOps は、この豊富なすべてを管理するためのスケール不変モデルを提供します。

翻訳者からの追伸

私たちのブログもお読みください:

登録ユーザーのみがアンケートに参加できます。ログインお願いします。

これら XNUMX つの翻訳が Habré に掲載される前に、GitOps についてご存知でしたか?

はい、すべて知っていました
表面的にだけ
ノー

35 人のユーザーが投票しました。 10名のユーザーが棄権した。

出所： habr.com

GitOps とは何ですか?