モノリポジトリの話題は何度も議論されており、通常、非常に活発な論争を引き起こしています。 作成することで Git から Docker イメージへのアプリケーション コードの構築 (その後、Kubernetes への配信) のプロセスを改善するために設計されたオープン ソース ツールであるため、どの選択が最適であるかについてはあまり考えていません。 私たちにとって、さまざまな意見の支持者に必要なものをすべて提供することが第一です（もちろん、常識に反しない場合に限ります）。
werf の最近のモノリポジトリのサポートは、この良い例です。 しかしその前に、このサポートが一般的に werf の使用にどのように関連しているのか、そして Docker レジストリがそれとどのような関係があるのかを理解しましょう。
問題
そんな状況を想像してみましょう。 同社には独立したプロジェクトに取り組んでいる多くの開発チームがあります。 ほとんどのアプリケーションは Kubernetes 上で実行されるため、コンテナ化されます。 コンテナやイメージを保存するにはレジストリ（レジストリ）が必要です。 このようなレジストリとして、同社は単一のアカウントで Docker Hub を使用しています。 COMPANY。 ほとんどのソース コード ストレージ システムと同様に、 Docker Hub ではネストされたリポジトリ階層が許可されません、 そのような COMPANY/PROJECT/IMAGE。 その場合…プロジェクトごとに個別のアカウントを作成せずに、この制限付きで非モノリシック アプリケーションをレジストリに保存するにはどうすればよいでしょうか?
おそらく、ここで説明されている状況は直接知っている人もいるでしょうが、一般的なアプリケーション ストレージの整理の問題を考えてみましょう。 上記の例と Docker Hub を参照する必要はありません。
ソリューション
アプリケーションの場合 モノリシック、XNUMX つのイメージで提供される場合、質問はなく、単にイメージをプロジェクトのコンテナー レジストリに保存します。
アプリケーションが複数のコンポーネントとして表示される場合、 マイクロサービス、その場合は、特定のアプローチが必要です。 XNUMX つのイメージで構成される典型的な Web アプリケーションの例: frontend и backend - 可能なオプションは次のとおりです。
- イメージを別のネストされたリポジトリに保存します。
- すべてを XNUMX つのリポジトリに保存し、タグ内のイメージ名を次のように考慮します。
NB: 実際には、別のリポジトリに保存するという別のオプションもあります。 PROJECT-frontend и PROJECT-backend、ただし、サポート、組織、ユーザー間の権利の分配が複雑であるため、考慮しません。
ワーフサポート
当初、werf はネストされたリポジトリに限定していましたが、幸いなことに、ほとんどのレジストリがこの機能をサポートしています。 バージョンから開始 、レジストリに関する作業を追加しました。 ネストはサポートされていません、Docker Hub もその XNUMX つです。 その時点から、ユーザーはアプリケーション イメージを保存する方法を選択できます。
オプションで実装可能 --images-repo-mode=multirepo|monorepo （デフォルト multirepo、つまりネストされたリポジトリ内のストレージ）。 これは、イメージをレジストリに保存するパターンを定義します。 基本的なコマンドを使用するときに目的のモードを選択するだけで十分で、その他はすべて変更されません。
ほとんどのワーフオプションを設定できるため 環境変数, CI / CD システムでは、ストレージ モードは通常、プロジェクト全体に対してグローバルに簡単に設定できます。 例えば、 GitLabの場合 プロジェクト設定に環境変数を追加するだけです。 設定 -> CI / CD -> 変数: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
イメージの公開とアプリケーションのロールアウトについて話す場合は、これらのプロセスについては、関連するドキュメントの記事で詳しく読むことができます。 и ) の場合、モードのみが画像を操作できるテンプレートを決定します。
悪魔の詳細
新しいストレージ方法を追加する場合の違いと主な困難は、レジストリのクリーンアップのプロセスにあります。 (werf でサポートされているパージ機能については、を参照してください。 ).
クリーニングの際、werf は、Kubernetes クラスターで使用されるイメージと、ユーザーが構成したポリシーを考慮します。 ポリシーは、タグを戦略に分割することに基づいています。 現在サポートされている戦略:
- タグ、ブランチ、コミットなどの Git プリミティブによってリンクされた 3 つの戦略。
- 任意のカスタムタグの 1 つの戦略。
画像を公開するときにタグ戦略に関する情報を最終画像のラベルに保存します。 意味自体はいわゆる メタタグ - 一部のポリシーを適用するために必要です。 たとえば、Git リポジトリからブランチまたはタグを削除する場合、関連するブランチまたはタグを削除するのが論理的です。 未使用 レジストリからのイメージ。これは当社のポリシーの一部でカバーされています。
XNUMX つのリポジトリに保存される場合 (monorepo)、イメージ タグには、メタ タグに加えて、イメージの名前も保存できます。 PROJECT:frontend-META-TAG。 これらを分離するために、特定の区切り記号は導入せず、公開時に最終画像のラベルに必要な値を追加するだけで済みました。
NB: werf ソース コードに記述されているすべての内容を確認することに興味がある場合は、次の点から開始できます。 .
この記事では、タグ付け戦略、ラベルへのデータの保存、出版プロセス全体など、私たちのアプローチの問題点と正当化にはこれ以上注意を払いません。これらすべては、Dmitry Stolyarov による最近のレポートで詳細に説明されています。'。
要約する
ネストされていないレジストリのサポートの欠如は、私たちや私たちが知っている werf ユーザーにとって障害要因ではありませんでした。結局のところ、いつでも別のイメージ レジストリを作成する (または Google Cloud の条件付きコンテナ レジストリに切り替える) ことができます。ただし、より広範な DevOps コミュニティでツールをより便利にするためには、このような制限を取り除くのが論理的であると考えられました。 これを実装する際、コンテナ レジストリのクリーンアップ メカニズムを再構築するという主な困難に直面しました。 すべての準備が整ったので、誰かにとっては簡単になったことを実感できてうれしいです。私たち (プロジェクトの主な開発者として) は、この機能をさらにサポートするのに目立った困難はありません。
他のイノベーションについても間もなくお知らせしますので、ぜひお立ち寄りください。 !
PS
私たちのブログもお読みください:
- «";
- «'。
出所： habr.com
