GNU/Linux >> Linux の 問題 >  >> Linux

Quay.ioを使用してコンテナレジストリの負荷を軽減する方法

この投稿では、Quay.ioを使用してコンテナ画像をホストする方法と、画像に対する不要なリクエストを制限することでコンテナレジストリに過度の負担をかけないようにする方法を紹介します。私はBuildah、Skopeo、Quay.ioを使用していますが、イメージプルを制限するためのヒントは、使用する可能性のあるすべてのコンテナレジストリで機能します。

2020年11月下旬、Docker Hubは、匿名で、または無料のDocker Hub としてプルできるコンテナイメージの数を制限または制限し始めました。 ユーザー。 匿名の場合 ユーザーの場合、6時間でプルできるコンテナイメージは100個のみです。無料のDockerHubユーザーの場合、6時間で200個のコンテナイメージをプルできます。

BuildahやPodmanなど、作業中のコンテナツールの機能テストを実行する場合、この制限は通常問題にはなりません。たとえば、Containerfileを使用してコンテナイメージを構築し、特定のコマンドを実行した後の動作を確認するために結果のコンテナをテストする場合、通常、FROM Containerfile内の1回の命令。後でコンテナを最初から再構築する場合は、通常、すでにプルダウンされているコンテナイメージを再利用するため、カウンターにぶつかることはありません。このシナリオでは、スロットルは痛みを引き起こしませんが、それは常に私の心の奥底にあります。

DockerHubインタラクションの初期削減

ただし、DockerHubでスロットルに遭遇した場所は見つかりました。私の同僚であり、コンテナエンジンのQEリードの1人であるEdは、非常に優れた回避策を作成しました。まず、少し背景。数か月前、Edは、Podmanがすでに作成したキャッシュを再利用することで、Buildah継続的インテグレーション(CI)テストで使用するコンテナーイメージをフェッチする回数を減らしました。これ以前は、BuildahCIは貧しいalpineを悪用していました docker.io/libraryのDockerHubにあるコンテナイメージ fedoraとともに、終わりはありません 、busybox 、および他のいくつかのさまざまなコンテナイメージがあり、それらを何度も引っ張っています。 Edが作成したこのプリフェッチスキームは、テストを高速化するだけでなく、DockerHubで使用していた帯域幅を減らすこともできました。

これらの変更にもかかわらず、Buildah CIは11月に1日に数回失敗し始め、次のエラーが発生しました:プルレートの制限に達しました 。レート制限に達したのは、CIテストが毎日実行された回数によるものでした。プリフェッチにより、Buildah CIがイメージをプルするために必要な回数が減りましたが、CIはDockerHubのスロットルで実行されていました。

[次もお読みください:内部で使用するためのシンプルなパーソナル/プライベートLinuxコンテナイメージレジストリを実装する方法]

スロットルの解決

Edが提供したソリューションは、Buildahの柔軟性とGitHubのContainersリポジトリにあるコンテナツールを利用しています。まず、Edはquay.ioに無料のアカウントを作成し、そこに画像をコピーして公開しました。 Edはquay.ioを選びました。これは、コンテナ画像をたくさん保存する場所であり、便利だからです。それでも、ローカルコンテナイメージリポジトリまたは他社のリポジトリである可能性があります。

ボーナスとして、quay.ioはDockerHubのように抑制されません。

Skopeoを使用して初期画像をコピーする

プロジェクトにalpineが必要だとします。 およびcentos:8 画像。まず、quay.ioに myquayaccountnameという名前の無料アカウントを作成します。 。 Skopeoがインストールされているホストで、次のコマンドを実行します。

skopeo login -u myquayaccountname quay.io
skopeo copy --all docker://docker.io/library/alpine:latest docker://quay.io/myquayaccountname/alpine:latest

次に、alpine:latestを置き換えて繰り返します centos:8を使用 、など、必要なすべての画像について。

quay.ioを構成する

画像は現在quay.ioにありますが、デフォルトでは非公開になっています。それらを公開するには、quay.io Web UIに再度ログインし、各画像名をクリックします。これにより、画像の詳細を表示する新しいページに移動します。左側のナビゲーションバーの下部にある歯車のアイコンをクリックして、公開を見つけます。 ボタンを押して押します。 OKを確認する必要があります 次に、ピンクの鍵のアイコンが表示されているすべての画像に対して繰り返します。

私たちの場合、Edが最初に行ったのは、使用するコンテナーイメージをDocker Hubからプルし、彼が作成したquay.ioのlibpodコンテナーイメージリポジトリに配置することでした。

ミラーリング用にregistries.confを構成します

これらの画像を移動することで、スロットルの問題を解決しました。ただし、CIがquay.io/libpodからプルするように、これらの画像への数千とは言わないまでも数百のテストの参照を変更するという問題が発生しました。 docker.io/libraryではなく 。この必要な変更は、コンテナツールが提供する柔軟性の完璧なショーケースでした。 Edは、すべてのテストをグローバルに変更するのではなく、構成を比較的小さな変更でこれに対処しました。

これがエドが作り上げたものです。 Buildahがコンテナーイメージを検索する場合、docker.ioからプルするだけでハードコードされることはありません。代わりに、/ etc / containers / repositorys.confを読み取り、Buildahがプルするコンテナーイメージリポジトリを決定します。

Edは、quay.io/libpodのようにそのファイルを変更しただけです。 テストがdocker.io/libraryを探しに行くたびに連絡されます 。上記の例を使用して、次の行を/etc/containers/registries.confに追加します。 キャッシュを使用するすべてのシステム:

toml
[[registry]]
prefix=" docker.io/library"
location=" quay.io/myquayaccountname"

以降のすべてのpodman pull alpine コマンドはミラーからフェッチします。 EdがPodmanに対して行った変更は、このプルリクエストで確認できます。

Buildahが使用するコンテナー/イメージプロジェクトのミラーリング機能をさらに強調するために、コンテナーイメージのミラーを設定して、別のレジストリから古い名前でプルできるようにすることができます。ミラーリングは元々、切断された環境をサポートするために追加されました。 OpenShiftなどのソフトウェアを実行しているインターネット接続のない環境では、ローカル以外のレジストリーからイメージをプルできないことが多いため、ユーザーはソフトウェアを変更せずに内部レジストリーでイメージをミラーリングできます。

これは、containers-registries.confからの詳細情報を含むスニペットです。 container/imageの一部であるファイル プロジェクト:

$ man containers-registries.conf

   Remapping and mirroring registries
       The user-specified image reference is, primarily, a "logical" image  name,  always
       used for naming the image.  By default, the image reference also directly specifies
       the registry and repository to use, but the following options can be used to  redi‐
       rect  the  underlying  accesses to different registry servers or locations (e.g., to
       support configurations with no access to the  internet  without  having  to  change
       Dockerfiles, or to add redundancy).

警告 :この手順では、コンテナイメージの1回限りのコピーを実行します。キャッシュされたイメージは、docker.ioにプッシュされたセキュリティ修正を魔法のように取得しません。 (バイナリの削除やその他の重大な変更などのランダムな破壊行為も検出されません。開始しないでください。)

今後の作業

注意点を考えると、イメージのメンテナンスはあなた次第です。Skopeoコマンドを追加して、イメージをテスト手順の最初にコピーすることを検討してください。もう1つの考えられる回避策は、Google Cloud Registry(GCR)などのパブリックミラーを有効にするか、場合によってはregistries.confをさらに改良することです。 複数のミラーを設定するファイル。さらに良いことに、これはskopeo-syncコマンドに最適です。CLIが優れており、さまざまな構成オプションを提供するYAMLファイルで使用できるためです。

[コンテナを使い始めますか?この無料コースをチェックしてください。コンテナ化されたアプリケーションのデプロイ:技術的な概要。 ]

まとめ

配置されたDockerHubのスロットルを解決するにはさまざまな方法がありますが、Edが使用した方法は迅速で痛みがなく、CIをすばやくオンラインに戻しました。余裕ができたので、より完全なソリューションに取り組むことができます。

この変更により、Buildahテストが制限を超えて実行されなくなり、Docker Hubからスロットルがヒットすることがなくなり、スロットルの問題が解決されます。


Linux
  1. Container-diffを使用してコンテナイメージを分析および比較する方法

  2. ホストファイルを使用してサイトをテストする方法

  3. cPanelを使用してドメインのPHPバージョンを変更するにはどうすればよいですか?

  1. Linux端末の色を変更する方法

  2. Linuxコンテナレジストリを管理する方法

  3. パーソナルFTPリポジトリを使用してサイトをバックアップする方法

  1. コマンドラインでデータをクリーンアップする方法

  2. LCNバックアップユーティリティを使用してWebサイトをバックアップおよび復元する方法

  3. ヘルムチャートをAzureContainerRegistryに保存する方法