コンテナ画像の「スマート」クリーニングの問題とその解決策

この記事では、Kubernetesに配信されるクラウドネイティブアプリケーション用の最新のCI / CDパイプラインの現実において、コンテナレジストリ（Docker Registryとその類似物）に蓄積されるイメージのクリーニングの問題について説明します。画像の関連性と、その結果として生じるクリーニングの自動化、スペースの節約、およびチームのニーズへの対応における困難さの主な基準が示されています。最後に、特定のオープンソースプロジェクトの例を使用して、これらの問題をどのように克服できるかを説明します。

前書き

コンテナレジストリ内のイメージの数は急速に増加し、より多くのストレージスペースを占有する可能性があるため、コストが大幅に増加します。レジストリで占有されるスペースの許容可能な増加を制御、制限、または維持するために、次のことが受け入れられます。

1. 画像には固定数のタグを使用します。
2. 何らかの方法で画像をクリーンアップします。

最初の制限は、小規模なチームに有効な場合があります。開発者は（十分な永久的なタグを持っている場合はlatest、main、test、borisなど）、レジストリのサイズは膨潤しないとクリーニングについて考えないように長い時間がかかることがあります。結局のところ、すべての無関係な画像がほつれ、掃除のための作業が残っていないだけです（すべては通常のゴミ収集機によって行われます）。



ただし、このアプローチは開発を厳しく制限し、今日のCI / CDプロジェクトに適用できることはめったにありません。自動化は開発の不可欠な部分になりましたこれにより、新しい機能をテスト、展開、およびユーザーにはるかに迅速に提供できます。たとえば、すべてのプロジェクトで、CIパイプラインはコミットごとに自動的に作成されます。イメージを構築してテストし、デバッグと残りのチェックのためにさまざまなKubernetes回路にロールアウトします。すべてがうまくいけば、変更はエンドユーザーに届きます。そして、これは長い間ロケット科学ではありませんが、多くの人にとって日常生活です-あなたがこの記事を読んでいるので、おそらくあなたにとってです。



バグが排除され、新しい機能が並行して開発され、リリースは1日に数回実行できるため、開発プロセスにはかなりの数のコミットが伴うことは明らかです。つまり、レジストリに多数のイメージがあります。..。その結果、効果的なレジストリクリーニングを組織化する問題が深刻になります。無関係な画像の削除。



しかし、画像が関連しているかどうかをどのように判断できますか？

画像の関連性の基準

ほとんどの場合、主な基準は次のとおりです



。1。最初の（すべての中で最も明白で最も重要な）画像は、現在Kubernetesで使用されている画像です。これらのイメージを削除すると、制作に深刻なダウンタイムコストが発生する可能性があり（たとえば、レプリケーション中にイメージが必要になる場合があります）、いずれかの回路のデバッグに従事するチームの労力が無効になります。（このため、Kubernetesクラスターにそのような画像がないことを監視する特別なPrometheusエクスポーターも作成しました。）



2。2番目（あまり明白ではありませんが、非常に重要であり、操作に関連しています）-深刻な場合にロールバックする必要がある画像問題現在のバージョンでは。たとえば、Helmの場合、これらはリリースの保存バージョンで使用されるイメージです。 （ちなみに、ヘルムのデフォルトの制限は256本の改訂版ですが、ほとんど誰もが本当に保存する必要がないように？バージョンの数が多い。）結局、このため、特に、我々はバージョンを保存し、あとでできるように、使用、すなわち必要に応じて、「ロールバック」します。



3. 3番目-開発者のニーズ：現在の作業に関連するすべての画像。たとえば、PRを検討している場合、最後のコミットと、たとえば前のコミットに対応するイメージを残すことは理にかなっています。これにより、開発者は任意のタスクにすばやく戻り、最新の変更を処理できます。



4.4番目-その画像アプリケーションのバージョンに対応します。最終製品はv1.0.0、20.04.01、sierraなどです。



注意：ここで定義されている基準は、さまざまな企業の数十の開発チームとのやり取りの経験に基づいて策定されました。ただし、もちろん、開発プロセスの詳細や使用するインフラストラクチャ（たとえば、Kubernetesは使用されない）によっては、これらの基準が異なる場合があります。

適格性と既存のソリューション

一般的なコンテナレジストリサービスは、原則として、独自のイメージクリーニングポリシーを提供します。これらのサービスでは、タグがレジストリから削除される条件を定義できます。ただし、これらの条件は、名前、作成時間、タグの数などのパラメーターによって制限されます*。



*特定のコンテナレジストリの実装によって異なります。次のソリューションを検討しました：Azure CR、Docker Hub、ECR、GCR、GitHubパッケージ、GitLab Container Registry、Harbour Registry、JFrog Artifactory、Quay.io- 2020年9月現在。



このパラメータのセットは、4番目の基準、つまりバージョンに一致する画像を選択するのに十分です。ただし、他のすべての基準については、期待と財務能力に応じて、何らかの妥協案（より厳しい、または逆に、控えめな方針）を選択する必要があります。



たとえば、開発者のニーズに関連する3番目の基準は、チーム内のプロセスを整理することで解決できます。つまり、画像の特定の命名、特別な許可リストと内部合意の維持です。しかし、最終的にはそれでも自動化する必要があります。また、既製のソリューションの可能性が十分でない場合は、独自のことを行う必要があります。



状況は最初の2つの基準と似ています。外部システム（アプリケーションがデプロイされているシステム（この場合はKubernetes）からデータを受信しないと満たすことができません）。

Gitのワークフローの図

Gitで次のような作業を行っているとします。







図の頭の付いたアイコンは、現在任意のユーザー（エンドユーザー、テスター、マネージャーなど）のKubernetesに展開されている、または開発者がデバッグに使用しているコンテナーイメージを示します。および同様の目標。



パージポリシーで、指定したタグ名の画像のみを保持（削除ではなく）できる場合はどうなりますか？







明らかに、このシナリオは誰も喜ばないでしょう。



ポリシーで、特定の時間間隔/最近のコミット数の間、画像を削除できないようにした場合、何が変わりますか？







結果ははるかに良くなりましたが、それでも理想からはほど遠いです。結局のところ、バグをデバッグするためにレジストリにイメージを必要とする（またはK8にデプロイする）開発者がまだいます...



市場の現在の状況を要約すると、コンテナレジストリで利用可能な機能は、クリーニング時に十分な柔軟性を提供しません。主な理由は、可能性がないことです。外の世界と対話します。この柔軟性を必要とするチームは、Docker Registry API（または対応する実装のネイティブAPI）を使用して、「外部」でイメージの削除を個別に実装することを余儀なくされていることがわかりました。



ただし、さまざまなレジストリを使用するさまざまなチームの画像クリーニングを自動化するユニバーサルソリューションを探していました...

ユニバーサルイメージクリーニングへの道

この必要性はどこから来るのですか？事実、私たちは独立した開発者グループではなく、一度に多くの開発者にサービスを提供し、CI / CDの問題を包括的に解決するのに役立つチームです。そして、このための主な技術ツールは、オープンソースのwerfユーティリティです。その特徴は、単一の機能を実行するのではなく、組み立てから展開までのすべての段階で継続的な配信プロセスを伴うことです。



レジストリへのイメージの公開*（ビルド直後）は、このようなユーティリティの明らかな機能です。そして、画像は保管のためにそこに置かれるので、保管が無制限でない場合は、その後のクリーニングに責任を負う必要があります。指定されたすべての基準を満たし、これでどのように成功を収めたかについて、さらに説明します。



*レジストリ自体は異なる場合がありますが（Docker Registry、GitLab Container Registry、Harbourなど）、ユーザーは同じ問題に直面します。この場合のユニバーサルソリューションは、レジストリの実装に依存しません。レジストリ自体の外部で実行され、すべての人に同じ動作を提供します。



実装の例としてwerfを使用しているという事実にもかかわらず、使用されているアプローチが、同様の問題に直面している他のチームに役立つことを願っています。



だから、私たちは外部を取り上げましたコンテナのレジストリにすでに組み込まれている機能の代わりに、イメージをクリーニングするためのメカニズムの実装。最初のステップは、Docker Registry APIを使用して、タグの数と作成時間（上記）によってすべて同じプリミティブポリシーを作成することでした。デプロイされたインフラストラクチャで使用されるイメージに基づいて、許可リストがこれらに追加されました。Kubernetes。後者の場合、Kubernetes APIを介してデプロイされたすべてのリソースを調べ、値のリストを取得するだけで十分でしたimage。



このささいな解決策は、最も重大な問題（基準＃1）を解決しましたが、それは洗浄メカニズムを改善するための私たちの旅の始まりにすぎませんでした。次の（そしてはるかに興味深い）ステップは、公開された画像をGitの履歴に関連付けるという決定でした。

タグ付けスキーム

まず、最終的な画像にクリーニングに必要な情報を保存する必要があるアプローチを選択し、タグ付けスキームに基づいてプロセスを構築しました。画像を公開する場合、ユーザは、特定のタグ付けオプションを選択し（git-branch、git-commitまたはgit-tag）および対応する値を使用します。CIシステムでは、これらの値は環境変数に基づいて自動的に設定されていました。基本的に、最終的な画像は特定のGitプリミティブに関連付けられ、クリーニングに必要なデータをラベルに保存します。



このアプローチにより、Gitを唯一の真実の源として使用できるようにする一連のポリシーが作成されました。

• Gitでブランチ/タグを削除すると、レジストリ内の関連する画像も自動的に削除されました。
• Gitタグとコミットに関連付けられた画像の数は、選択したスキームで使用されるタグの数と、関連付けられたコミットが作成された時間によって制御できます。

一般的に、結果として得られた実装は私たちのニーズを満たしていましたが、すぐに新しい課題が私たちを待っていました。事実、Gitプリミティブにタグ付けスキームを使用しているときに、いくつかの欠点が発生しました。（説明はこの記事の範囲外であるため、誰でもここで詳細を読むことができます。）したがって、タグ付け（コンテンツベースのタグ付け）へのより効率的なアプローチに移行することを決定した後、画像クリーニングの実装を修正する必要がありました。

新しいアルゴリズム

どうして？コンテンツベースとしてタグ付けされている場合、各タグはGitでの複数のコミットに対応できます。イメージをクリーンアップするときに、新しいタグがレジストリに追加されたコミットだけに依存することはできなくなりました。



新しいクリーニングアルゴリズムでは、タグ付けスキームから離れて、メタイメージ上にプロセスを構築することが決定されました。メタイメージには、それぞれ次のものが多数格納されています。

• パブリケーションが実行されたコミット（イメージがコンテナレジストリで追加、変更、または同じままであるかどうかは関係ありません）。
• 構築されたイメージに対応する内部識別子。

つまり、公開されたタグはGitのコミットにリンクされていました。

最終構成と一般的なアルゴリズム

クリーンアップを構成するときに、ユーザーは実際の画像の選択を実行するポリシーにアクセスできるようになりました。このような各ポリシーは次のように定義されています。

• 複数の参照、つまり クロール中に使用されるGitタグまたはGitブランチ。
• セットからの各参照に必要な画像の制限。

説明のために、これがデフォルトのポリシー構成がどのように見え始めたかです。

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

この構成には、次のルールに準拠する3つのポリシーが含まれています。

1. 最後の10個のGitタグの画像を保存します（タグが作成された日付まで）。
2. 先週公開された2つ以下の画像を保存し、先週アクティビティがあった10以下のブランチを保存します。
3. 各ブランチのための10枚の画像を保存しmain、stagingそしてproduction。

最終的なアルゴリズムは、次の手順になります。

• コンテナレジストリからマニフェストを取得する。
• Kubernetesで使用されている画像を除外する理由 K8s APIをポーリングすることにより、すでにそれらを事前に選択しています。
• 指定されたポリシーに従ってGit履歴をスキャンし、画像を除外します。
• 残りの画像を削除します。

図に戻ると、werfで何が起こるかを次に示します。







ただし、werfを使用しない場合でも、（画像にタグを付けるための推奨されるアプローチに従って）ある実装または別の実装で、画像の高度なクリーニングに対する同様のアプローチを他のシステムにも適用できます。 /ユーティリティ。これを行うには、発生する問題について覚えて、最もスムーズな方法でソリューションを構築できるようにする機会をスタック内で見つけるだけで十分です。私たちが旅した道が、あなたの特定のケースを新しい詳細や考えで見るのに役立つことを願っています。

結論

• 遅かれ早かれ、ほとんどのチームはレジストリオーバーフローの問題に直面します。
• 解決策を探すときは、まず、画像の関連性の基準を決定する必要があります。
• 人気のコンテナレジストリサービスが提供するツールは、「外の世界」、つまりKubernetesで使用される画像とチームワークフローの詳細を考慮しない非常に簡単なクリーンアップを可能にします。
• 柔軟で効率的なアルゴリズムは、CI / CDプロセスを理解している必要があり、Dockerイメージデータだけで動作するわけではありません。

PS

私たちのブログも読んでください：

• «コレクターwerfでのコンテンツベースのタグ付け：なぜ、どのように機能するのですか？";
• " werfでの3方向マージ：Helmを使用してKubernetesに展開"ステロイドで";
• " werfでのモノレポとマルチレポのサポートとDockerレジストリはそれと何の関係がありますか";
• « werf 1.1: ».