Docker がネットワーク エグレスと無料ユーザー向けのプル数に関して導入した変更を考えると、これらの制限に達することなく開発ワークフローの一部として Docker を使用する最善の方法について質問があるというフィードバックをいただいています。 このブログ投稿では、エクスペリエンスを向上させるベストプラクティスについて説明し、これらの制限に達するリスクを軽減するDockerの賢明な消費と、ユースケースに応じて制限を増やす方法について説明します。
CI/CD パイプラインでこれらの制限にどのように対処するかに興味がある場合は、投稿「 CI/CD に Docker Hub を使用するためのベスト プラクティス」を参照してください。 Github Action を使用している場合は、 Docker Github Actions の投稿をご覧ください。
前提 条件
このチュートリアルを完了するには、次のものが必要です。
- 無料のドッカーアカウント
- 無料のDockerアカウントにサインアップ して、無料の無制限のパブリックリポジトリを受け取ることができます
- ローカルで実行されているドッカー
- ファイルの編集に使用する IDE またはテキスト エディター。 私はVSCodeをお勧めします
プル数の決定
Docker では、プル レート制限を Docker Hub へのマニフェスト要求の数として定義します。 Docker プルのレート制限は、イメージの所有者のアカウントの種類ではなく、イメージを要求しているユーザーのアカウントの種類に基づいています。 匿名 (認証されていない) ユーザーの場合、プル レートは個々の IP アドレスに基づいて制限されます。
コンテナー イメージ レイヤーに関して、お客様やコミュニティから質問が寄せられています。 プルレート制限の一部として画像レイヤーはカウントされません。 マニフェスト要求を制限しているため、現時点ではプルに関連するレイヤー (BLOB 要求) の数は無制限です
匿名ユーザーは、6 時間以内に最大 100 回のプルを実行できます。 これは、個々の開発者がプル制限に達することを心配することなく、ローカル開発マシンでイメージをビルドできるようにするのに十分な高い制限です。
6 時間のウィンドウごとに 100 回を超えるプルを実行する必要がある場合は、無料の Docker アカウント を作成して、6 時間のウィンドウあたり最大 200 回のプルを実行できます。 匿名の制限と比較してプルの量を 2 倍にします。
ビルドで発生するプルの数を把握するには、Docker ファイル内のコマンドの数 FROM を確認します。 イメージがローカル コンピューターにプルされると、後続のビルドでプルは発生しません。
たとえば、フロントエンドUI、RESTサービス、およびデータベースで構成されるアプリケーションがあるとします。 2つのドッカーファイルがあります。 1 つは UI の構築用、もう 1 つは REST サービスの構築用です。 次に、これらの画像を作成ファイル内のデータベースと結合します。 この作成ファイル内に、データベースイメージを含めます。
Awesome Compose リポジトリのreact-express-mongodbの例を使用して、このシナリオを見てみましょう。リポジトリのクローンを作成し、 awesome-compose お気に入りのエディターでフォルダーを開きます react-express-mongodb 。
$ git clone [email protected]:d ocker/awesome-compose.git
$ cd awesome-compose/react-express-mongodb
フロントエンドの折り目を展開し、Dockerfileを開きます。
1行目でわかるように、画像を使用しています node:lts-buster-slim 。 このイメージがまだローカルにない場合、ビルドを実行すると、このイメージは Docker Hub からプルされ、1 回のプルとしてカウントされます。
同様に、バックエンド フォルダーには、バックエンド イメージのビルドに使用される Dockerfile があります。 このファイルの1行目でも、画像を使用しています node:lts-buster-slim 。 繰り返しになりますが、このイメージを Docker Hub からまだプルしていない場合は、実行すると、Docker はこのイメージをプルし、 docker build, 1 回のプルとしてカウントします。
要約すると、アプリケーション イメージごとに同じ基本イメージ (node:lts-buster-slim) を使用しているため、そのイメージを 1 回プルするだけで、プルは 1 回だけ発生します。
画像についても mongo:4.2.0 同じことが言えます。 docker-compose up コマンドを実行すると、ローカルに存在しない場合は mongo イメージがプルされ、プル制限カウンターが 1 つ増えます。
したがって、上記の例では、ローカルにゼロの画像が存在すると、Hubへの2つのプルリクエストが発生します。 これをもう少し複雑なアーキテクチャに拡張し、ノードにも記述されたサービスがいくつかあるとしても、プルリクエストは2つしか発生しません。 1 つはノード イメージ用で、もう 1 つは mongodb イメージ用です。
それでは、以下のより高度なビルドシナリオを見てみましょう。
マルチステージ ビルドを使用する Dockerfile の例を次に示します。
1#構文=ドッカー/ドッカーファイル:1.1.7
2 ARG GO_VERSION=1.13.7-バスター
3
4 FROM golang:${GO_VERSION} AS golang
5
6 ゴランASビルドから
7 ....
8 から debian:buster AS foo
9 ....
10 ゼロから最終として
11 コピー --from=build /bin/foo /bin/foo
単にの数を数えること FROMはすべての状況で機能するわけではありませんが、それは良い一般的なプロキシです。 ローカルにしかないイメージを参照するコマンドがある場合 FROM 、ハブプルは発生しません。 マルチステージビルドでコマンドを使用して、同じDockerfileにある他のビルドステージを参照することもできます FROM 。
上記のDockerfileには、複数の FROM ステートメントがあり、そのうちの合計はマルチステージビルドで構成されています。 Hubから実際にプルされる内容は、ローカルキャッシュの状態、設定されているビルドターゲット、BuildKitを使用しているかどうかによって異なります。
BuildKit を使用していないシナリオを見ていきましょう。
4行目では、build引数を参照 GO_VERSION していることがわかります。
FROM golang:${GO_VERSION} AS golang
の値は GO_VERSION 、オプションを使用して --build-arg 値を渡したかどうかによって異なります。
たとえば、ローカルマシンに画像があると golang:1.13.7-buster します。 をオーバーライド GO_VERSION しない場合、プルは発生しません。 一方、に設定 1.15.2-buster し GO_VERSION 、このイメージをローカルにない場合は、Hubからのプルが発生します。
sをカウント FROMするときに覚えておくべきもう一つのポイントは、コマンドが FROM 画像を参照できることです scratch 。 イメージは scratch Hub 上のイメージではありませんが、Docker によって特別に扱われ、ハブから何もプルしませんが、空のイメージを作成するための開始点として使用されます。
次に、BuildKit を使用したイメージの構築を見てみましょう。 上記と同じサンプル Dockerfile を使用します。
ビルドを実行すると、ステージが開始され、 FROM scratch AS final 次のフローがトリガーされます。
FROM golang AS buildが開始されます- ステージをトリガーします
FROM golang:$(GO_VERSION} AS golang - ローカルに存在しない場合は、
golang:1.13.7-buster imageハブからプルします
このシナリオでは、行 8 は最終的なイメージで使用されないため、ビルドされず、 FROM debian:buster AS foo stage debian:buster イメージはハブからプルされません。これは FROM Dockerfile 内のステートメントですが、使用されず、発生するプルの数を計算するときにカウントする必要はありません。
無制限のプル
さまざまな基本イメージを含む大規模なプロジェクトで作業している場合、またはイメージをビルドして頻繁に削除する場合は、Docker Proアカウントまた は Dockerチームアカウント を購入するのが最善の方法です。
ProアカウントとTeamアカウントの両方で無制限のプルが提供されるため、レート制限の対象にはなりません。 また、これらのプランでは無制限のプライベートリポジトリを受け取ります。
結論
この記事では、Docker を使用してイメージをビルドするときにプルがどのようにカウントされるかについて説明しました。 まず、フロントエンド、バックエンド、データストアを持つ一般的なアプリケーションと、このシナリオが匿名ユーザーの 100 プル制限に達しない方法について説明しました。 次に、マルチステージ ビルドを使用するより高度な Dockerfile と、これがプル制限にどのように影響する可能性があるかについて説明しました。 認証されたアカウントの200プル制限に達するには十分ではありませんが。
詳細と一般的な質問については、 FAQをお読みください。 いつものように、Twitter(@docker)または直接私(@pmckee)でお気軽にお問い合わせください。
Docker の使用を開始するには、無料の Docker アカウントに サインアップして、 スタート ガイドをご覧ください。