🥇werf におけるコンテナイメージの「スマート」クリーニングの問題とその解決策

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

導入

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

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

最初の制限は、小規模なチームでは許容できる場合があります。開発者が十分な永続タグを持っている場合 (latest, main, test, boris など）、レジストリのサイズが増大することはなく、長期間にわたってレジストリのクリーニングについて考える必要はありません。結局のところ、無関係な画像はすべて消去され、クリーニングする作業はまったく残されません (すべては通常のガベージコレクターによって行われます)。

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

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

しかし、画像が関連性があるかどうかはどうやって判断するのでしょうか?

画像の関連性の基準

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

1. 最初の (すべての中で最も明白で最も重要な) の画像は、 現在Kubernetesで使用されている。これらのイメージを削除すると、本番環境のダウンタイムに多大なコストが発生したり (たとえば、レプリケーションにイメージが必要になる場合があります)、チームのループのデバッグ作業が無効になったりする可能性があります。 (このため、特別なものも作りました) プロメテウスの輸出業者、Kubernetes クラスター内にそのようなイメージが存在しないことを追跡します)。

2. XNUMX 番目 (それほど明白ではありませんが、非常に重要であり、やはり搾取に関連します) - 画像 重大な問題が検出された場合のロールバックに必要 現在のバージョンでは。たとえば、Helm の場合、これらはリリースの保存されたバージョンで使用されるイメージです。 (ちなみに、Helm のデフォルトの制限は 256 リビジョンですが、実際に保存する必要がある人はほとんどいないでしょう。 そのような 多数のバージョン?..) 結局のところ、私たちは特に、後で使用できるようにバージョンを保存します。必要に応じて「ロールバック」します。

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

4. XNUMX 番目 - イメージ アプリケーションのバージョンに対応する、つまり最終製品: v1.0.0、20.04.01/XNUMX/XNUMX、sierra など。

注意: ここで定義された基準は、さまざまな企業の数十の開発チームと対話した経験に基づいて策定されました。ただし、当然ながら、開発プロセスの詳細や使用されるインフラストラクチャ (Kubernetes が使用されないなど) によって、これらの基準は異なる場合があります。

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

コンテナレジストリを使用する一般的なサービスは、通常、独自のイメージクリーンアップポリシーを提供しており、その中でタグをレジストリから削除する条件を定義できます。ただし、これらの条件は、名前、作成時刻、タグ*の数などのパラメータによって制限されます。

* 特定のコンテナーレジストリの実装に依存します。次のソリューションの可能性を検討しました: Azure CR、Docker Hub、ECR、GCR、GitHub Packages、GitLab Container Registry、Harbor Registry、JFrog Artifactory、Quay.io - 2020 年 XNUMX 月現在。

このパラメータのセットは、XNUMX 番目の基準、つまりバージョンに対応するイメージを選択するのに十分です。ただし、他のすべての基準については、期待と財務能力に応じて、ある種の妥協策 (より厳しい政策、または逆により寛大な政策) を選択する必要があります。

たとえば、開発者のニーズに関連する XNUMX 番目の基準は、イメージの特定の名前付け、特別な許可リストと内部合意の維持など、チーム内でプロセスを組織することで解決できます。しかし、最終的には依然として自動化する必要があります。また、既製のソリューションの機能が十分でない場合は、独自に何かを行う必要があります。

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

Git のワークフローの図解

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

図内の頭の付いたアイコンは、現在 Kubernetes にデプロイされているコンテナイメージ (エンドユーザー、テスター、マネージャーなど)、またはデバッグなどの目的で開発者によって使用されているコンテナイメージを示します。

クリーンアップポリシーでイメージの保持のみが許可される (削除されない) 場合はどうなりますか 指定されたタグ名によって?

明らかに、そのようなシナリオでは誰も幸せになれません。

ポリシーで画像を削除できないようにすると何が変わりますか? 指定された時間間隔 / 最後のコミット数に応じて?

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

現在の市場状況を要約すると、コンテナレジストリで利用できる機能は、クリーニング時に十分な柔軟性を提供できません。その主な理由は次のとおりです。 外の世界と対話する方法がない。このような柔軟性を必要とするチームは、Docker Registry API (または対応する実装のネイティブ API) を使用して、「外部から」イメージ削除を独自に実装する必要があることがわかりました。

しかし、私たちは、異なるレジストリを使用するさまざまなチームのイメージクリーンアップを自動化する汎用ソリューションを探していました。

ユニバーサルな画像クリーニングへの道

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

イメージを (ビルド直後に) レジストリ* に公開することは、このようなユーティリティの当然の機能です。また、画像は保存のためにそこに配置されるため、ストレージが無制限でない場合は、その後の画像のクリーニングは自分で行う必要があります。指定された基準をすべて満たし、どのようにしてこれに成功したかについては、さらに詳しく説明します。

* レジストリ自体は異なる場合がありますが (Docker レジストリ、GitLab Container Registry、Harbor など)、ユーザーは同じ問題に直面します。この場合の普遍的な解決策はレジストリの実装には依存しません。はレジストリ自体の外部で実行され、全員に同じ動作を提供します。

私たちは実装例として 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

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

最新 10 個の Git タグのイメージを保存します (タグの作成日順)。
先週のアクティビティが含まれるスレッドが 2 個以下であれば、先週に公開された画像は 10 個まで保存してください。
枝用の画像を 10 枚保存 main, staging и production.

最終的なアルゴリズムは次のステップに要約されます。

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

図に戻ると、werf では次のようなことが起こります。

ただし、werf を使用しない場合でも、高度なイメージクリーニングに対する同様のアプローチ (イメージのタグ付けに対する推奨アプローチに応じて) を他のシステム/ユーティリティに適用できます。これを行うには、発生する問題を記憶し、その解決策をできるだけスムーズに統合できる機会をスタック内で見つけるだけで十分です。私たちが歩んできた道が、あなたの特定のケースを新たな詳細と考えで見るのに役立つことを願っています。

まとめ

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

PS

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

出所： habr.com

werf におけるコンテナイメージの「スマート」クリーニングの問題とその解決策

導入