GitOps: プルメソッドとプッシュメソッドの比較

ノート。 翻訳。: Kubernetes コミュニティでは、私たちが個人的に見てきたように、GitOps と呼ばれるトレンドが明らかに人気を集めています。 訪問 KubeCon Europe 2019。この用語は比較的最近のものです 造語 Weaveworks の責任者である Alexis Richardson によるもので、運用上の問題を解決するために開発者によく知られているツール (主に Git であるため、その名前が付けられています) を使用することを意味します。 特に、構成を Git に保存し、変更をクラスターに自動的にロールアウトすることによる Kubernetes の操作について説明します。 Matthias Jg は、この記事でこの展開に対する XNUMX つのアプローチについて説明します。

昨年 (実際、これは正式には 2017 年 XNUMX 月に起こりました - おおよその翻訳) Kubernetes にアプリケーションをデプロイするための新しいアプローチがあります。 これは GitOps と呼ばれ、デプロイメントのバージョンが Git リポジトリの安全な環境で追跡されるという基本的な考え方に基づいています。

このアプローチの主な利点は次のとおりです。:

1. 導入のバージョン管理と変更履歴。 クラスター全体の状態は Git リポジトリに保存され、デプロイメントはコミットによってのみ更新されます。 さらに、コミット履歴を使用してすべての変更を追跡できます。
2. 使い慣れた Git コマンドを使用したロールバック。 単純 git reset デプロイメントの変更をリセットできます。 過去の状態はいつでも利用可能です。
3. すぐに使えるアクセス制御。 通常、Git システムには機密データが多数含まれているため、ほとんどの企業はその保護に特別な注意を払っています。 したがって、この保護は展開を伴う操作にも適用されます。
4. 導入のポリシー。 ほとんどの Git システムは、ブランチごとのポリシーをネイティブにサポートしています。たとえば、マスターを更新できるのはプル リクエストのみであり、変更は別のチーム メンバーがレビューして承認する必要があります。 アクセス制御と同様に、同じポリシーが展開の更新にも適用されます。

ご覧のとおり、GitOps 手法には多くの利点があります。 過去 XNUMX 年間で、XNUMX つのアプローチが特に人気を集めました。 XNUMX つはプッシュ ベースであり、もう XNUMX つはプル ベースです。 これらについて説明する前に、まず典型的な Kubernetes デプロイメントがどのようなものかを見てみましょう。

導入方法

近年、Kubernetes ではデプロイのためのさまざまな方法とツールが確立されています。

1. ネイティブの Kubernetes/KusTOMize テンプレートに基づく。 これは、Kubernetes にアプリケーションをデプロイする最も簡単な方法です。 開発者は基本的な YAML ファイルを作成し、それらを適用します。 同じテンプレートを絶えず書き直す必要をなくすために、KusTOMize が開発されました (Kubernetes テンプレートをモジュールに変換します)。 ノート。 翻訳。: KusTOMize は kubectl に統合されました。 Kubernetes 1.14のリリース.
2. ヘルムチャート。 Helm チャートを使用すると、テンプレート、初期コンテナ、サイドカーなどのセットを作成できます。これらは、テンプレート ベースのアプローチよりも柔軟なカスタマイズ オプションを使用してアプリケーションをデプロイするために使用されます。 この方法は、テンプレート化された YAML ファイルに基づいています。 Helm はそれらにさまざまなパラメーターを入力して、それらをクラスターにデプロイして更新とロールバックを可能にするクラスター コンポーネントである Tiller に送信します。 重要なことは、Helm は基本的に必要な値をテンプレートに挿入し、従来のアプローチと同じ方法でそれらを適用するだけであるということです。 (すべての仕組みとその使用方法について詳しくは、 ヘルムさんの記事 — 約翻訳）。 幅広いタスクをカバーするさまざまな既製の Helm チャートが用意されています。
3. 代替ツール。 代替ツールはたくさんあります。 これらに共通しているのは、一部のテンプレート ファイルを Kubernetes で読み取り可能な YAML ファイルに変換して使用することです。

私たちの仕事では、重要なツールには Helm チャートを常に使用し (これにより、作業がはるかに簡単になるようにすでに準備が整っているため)、独自のアプリケーションをデプロイするために「純粋な」Kubernetes YAML ファイルを使用します。

プル＆プッシュ

最近のブログ投稿の XNUMX つで、このツールを紹介しました ウィーブフラックスこれにより、テンプレートを Git リポジトリにコミットし、コンテナーをコミットまたはプッシュするたびにデプロイメントを更新できます。 私の経験上、このツールはプル型アプローチを推進する上で主要なツールの XNUMX つであるため、頻繁に参照します。 詳しい使い方を知りたい方はこちら 記事リンク.

NB！ GitOps を使用する利点はどちらのアプローチでも同じです。

プルベースのアプローチ

プル アプローチは、すべての変更がクラスター内から適用されるという事実に基づいています。 クラスター内には、関連する Git および Docker レジストリ リポジトリを定期的にチェックするオペレーターがいます。 それらに変更が発生すると、クラスターの状態が内部で更新されます。 外部クライアントがクラスター管理者権限にアクセスできないため、このプロセスは一般に非常に安全であると考えられています。

長所：

1. 外部クライアントにはクラスターに変更を加える権限はなく、すべての更新は内部からロールアウトされます。
2. 一部のツールでは、Helm チャートの更新を同期し、クラスターにリンクすることもできます。
3. Docker レジストリをスキャンして新しいバージョンを確認できます。 新しいイメージが利用可能な場合、Git リポジトリとデプロイメントは新しいバージョンに更新されます。
4. プル ツールは、異なる Git リポジトリと権限を持つ異なる名前空間に分散できます。 これによりマルチテナントモデルが利用可能となります。 たとえば、チーム A はネームスペース A を使用し、チーム B はネームスペース B を使用し、インフラストラクチャ チームはグローバル スペースを使用する可能性があります。
5. 一般に、ツールは非常に軽量です。
6. オペレーターなどのツールと組み合わせる ビットナミの封印された秘密、シークレットは暗号化されて Git リポジトリに保存され、クラスター内で取得できます。
7. デプロイメントはクラスター内で行われるため、CD パイプラインへの接続はありません。

コンズ:

1. Helm チャートからのデプロイメント シークレットの管理は、通常のデプロイメント シークレットよりも困難です。これは、まずシールされたシークレットの形式でデプロイメント シークレットを生成し、次に内部オペレーターによって復号化され、その後初めてプル ツールで使用できるようになるためです。 その後、既にデプロイされたシークレットの値を使用して Helm でリリースを実行できます。 最も簡単な方法は、デプロイメントに使用されるすべての Helm 値を含むシークレットを作成し、それを復号化して Git にコミットすることです。
2. プル型のアプローチを取ると、プル型のツールに縛られることになります。 これにより、クラスター内の展開プロセスをカスタマイズする機能が制限されます。 たとえば、KusTOMize は、最終テンプレートが Git にコミットされる前に実行する必要があるため、複雑になります。 スタンドアロン ツールを使用できないと言っているわけではありませんが、展開プロセスに統合するのはより困難です。

プッシュベースのアプローチ

プッシュ アプローチでは、Git リポジトリへのコミット後、または以前の CI パイプラインが成功した場合に、外部システム (主に CD パイプライン) がクラスターへのデプロイメントを開始します。 このアプローチでは、システムはクラスターにアクセスできます。

プロたち:

1. セキュリティは、Git リポジトリとビルド パイプラインによって決まります。
2. Helm チャートのデプロイがより簡単になり、Helm プラグインがサポートされます。
3. シークレットはパイプラインで使用でき、(ユーザーの設定に応じて) Git に暗号化して保存することもできるため、管理が容易になります。
4. どのタイプでも使用できるため、特定のツールに関連するものはありません。
5. コンテナーのバージョンの更新は、ビルド パイプラインによって開始できます。

コンズ:

1. クラスターのアクセス データはビルド システム内にあります。
2. デプロイメントコンテナーの更新は、プルプロセスを使用するとさらに簡単になります。
3. CD システムへの依存度が高い。必要なパイプラインがもともと Gitlab Runner 用に書かれている可能性があるため、チームは Azure DevOps または Jenkins に移行することを決定し、多数のビルド パイプラインを移行する必要があります。

結果: 押すか引くか?

通常のことですが、それぞれのアプローチには長所と短所があります。 タスクによっては、あるタスクを使用すると達成しやすく、別のタスクを使用するとより困難になる場合があります。 最初は手動でデプロイメントを行っていましたが、Weave Flux に関する記事をいくつか見つけた後、すべてのプロジェクトに GitOps プロセスを実装することにしました。 基本的なテンプレートの場合はこれは簡単でしたが、Helm チャートでは困難に遭遇し始めました。 当時、Weave Flux は Helm Chart Operator の初歩的なバージョンしか提供していませんでしたが、現在でも手動でシークレットを作成して適用する必要があるため、一部のタスクはより困難になっています。 クラスターの資格情報にはクラスターの外部からアクセスできないため、プル アプローチの方がはるかに安全であると主張することもでき、安全性が非常に高くなるため、追加の努力をする価値があります。

少し考えた結果、そうではないという予想外の結論に達しました。 最大限の保護が必要なコンポーネントについて話す場合、このリストにはシークレット ストレージ、CI/CD システム、Git リポジトリが含まれます。 内部の情報は非常に脆弱であり、最大限の保護が必要です。 さらに、誰かが Git リポジトリに侵入し、そこにコードをプッシュできる場合、必要なものは何でも (プルまたはプッシュで) デプロイし、クラスターのシステムに侵入できます。 したがって、保護する必要がある最も重要なコンポーネントは、クラスターの資格情報ではなく、Git リポジトリと CI/CD システムです。 このようなタイプのシステムに対して適切に構成されたポリシーとセキュリティ制御があり、クラスターの資格情報がシークレットとしてパイプラインにのみ抽出される場合、プル アプローチによって追加されたセキュリティは当初考えられていたほど価値がない可能性があります。

したがって、プル アプローチの方が労働集約的であり、セキュリティ上の利点が得られない場合は、プッシュ アプローチのみを使用するのが論理的ではないでしょうか。 しかし、プッシュ アプローチでは CD システムに縛られすぎるため、将来の移行を容易にするためにはプッシュ アプローチを行わないほうがよいのではないかと主張する人もいるかもしれません。

私の意見では (いつものように)、特定のケースに最も適したものを使用するか、組み合わせて使用​​する必要があります。 個人的には、私は両方のアプローチを使用しています。主に独自のサービスを含むプルベースのデプロイメントには Weave Flux を、もう XNUMX つは Helm とプラグインを使用したプッシュ アプローチです。これにより、Helm チャートをクラスターに簡単に適用でき、シークレットをシームレスに作成できます。 常に多くのニュアンスがあり、特定のアプリケーションに依存するため、すべてのケースに適した単一のソリューションは存在しないと思います。 そうは言っても、私は GitOps を強くお勧めします。これにより、作業が大幅に楽になり、セキュリティが向上します。

このトピックに関する私の経験が、お客様の展開タイプにどの方法がより適しているかを判断するのに役立つことを願っています。また、ご意見をお待ちしております。

PS 翻訳者からのメモ

プル モデルの欠点は、レンダリングされたマニフェストを Git に入れるのが難しいことですが、プル モデルの CD パイプラインがロールアウトとは別に存在し、本質的にカテゴリ パイプラインになるという欠点はありません。 継続適用。 したがって、すべての展開からステータスを収集し、できれば CD システムを参照して、何らかの方法でログ/ステータスへのアクセスを提供するには、さらに多くの努力が必要になります。

この意味で、プッシュ モデルでは、パイプラインの存続​​期間をロールアウトの存続期間と同じにすることができるため、少なくともある程度のロールアウトの保証を提供できます。

私たちは両方のモデルを試しましたが、記事の著者と同じ結論に達しました。

1. プル モデルは、多数のクラスター上のシステム コンポーネントの更新を整理するのに適しています (「. アドオンオペレーターに関する記事).
2. GitLab CI に基づくプッシュ モデルは、Helm チャートを使用したアプリケーションのロールアウトに適しています。 同時に、パイプライン内のデプロイメントのロールアウトは、ツールを使用して監視されます。 ワーフ。 ところで、私たちのこのプロジェクトに関連して、KubeCon Europe'19 のスタンドで DevOps エンジニアの差し迫った問題について議論したとき、常に「GitOps」の言葉が聞こえてきました。

翻訳者からの PPS

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

• «Kubernetes のヒントとテクニック: クラスター内で実行されているリソースを Helm 2 管理に転送する";
• «Kubernetes リソースを監視するための kubedog ライブラリの紹介";
• «Kubernetes の拡張と補足 (概要とビデオ レポート)";
• «GitLab CI でカスタム ワークフローを作成するためのヒント'。

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

GitOps を使用していますか?

• はい、プルアプローチです

• はい、押してください

• はい、引く+押す

• はい、何か別のこと

• ノー

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

出所： habr.com