search

Docker ミラー

ビルドするすべてのコンテナは、Docker レジストリからプルするベースイメージから始まります。例：

FROM ubuntu:20.04

信頼性の高い安定したビルドを目指す場合、これは問題になります。

  • タグはイミュータブルではありません。ubuntu:20.04 は新しいマイナー Ubuntu 20.04 バージョンがリリースされると上書きされます。コンテナを支える実際の OS バージョンは、コンテナがビルドされたタイミング（およびベースイメージのプルのタイミング）によって異なります。これは問題のデバッグ時にも厄介です。同じ Dockerfile からローカルと本番環境で同時にコンテナをビルドしても、キャッシュにあるベースイメージによって大きく異なるコンテナになる場合があります。

  • イメージは削除される可能性があります。レジストリにイメージが残り続ける保証はまったくありません。例えば、Nvidia は古い nvidia/cuda ベースイメージを Docker Hub から積極的に削除しています。また、これはコンテナをゼロからビルドする場合（ビルドキャッシュにベースイメージがない場合）にのみ発生します。これにより、追跡が非常に困難なランダムなビルド失敗が発生します（例：新しい開発者がチームに加わったとき、または新しいビルドサーバーをプロビジョニングしたとき）。ベースイメージの更新以外に手段がなく、多くのものが壊れる可能性があるため、時間的プレッシャーの下ではやりたくない作業です。

  • ほとんどのイメージは Docker Hub でホストされており、有料プランでも積極的なレート制限があります。これはビルドサーバーで問題になる場合があります。Amazon ECR のようなプルスルーキャッシュを実行する代替レジストリは、Docker Hub のイメージのごく一部しか持っていません。

StableBuild の Docker ミラーは、Docker Hub へのイミュータブルなミラーを運営することでこれらの問題をすべて解決します。StableBuild 経由でプルするには、任意のイメージにレジストリドメインをプレフィックスとして付けるだけです。例：

FROM your-domain.dockermirror.stablebuild.com/ubuntu:20.04

その後、ubuntu:20.04 イメージを Docker Hub からプルし、キャッシュに保存します。同じタグを再度プルすると、キャッシュされたイメージを返すだけです。このイメージはイミュータブルになります。上書きされることも、削除されることもありません。このイメージのプルにレート制限もありません。

開発者が Apple Silicon（ARM）を使用していても、x86 マシンにデプロイするなど、複数のアーキテクチャをターゲットにする可能性があることを考慮して、イメージのすべての利用可能なアーキテクチャもキャッシュします。

以上です。ベースイメージが安定した信頼性の高いものになりました。🎉

hashtag
ヒントとコツ

hashtag
広すぎるタグを使わない

イメージはイミュータブルになるため、プルするイメージやタグを具体的に指定することが重要です。例えば、ubuntu:latest や ubuntu:20.04 ではなく、ubuntu:focal-20230801（2023年8月1日の Ubuntu 20.04 リリース）を使用してください。イメージを削除したい場合は、ダッシュボード > Docker mirror に移動し、「Cached tags」でタグを削除してください。次回プルするときに再取得されます。

タグの削除

hashtag
プライベートリポジトリ

プライベートリポジトリからのプルはサポートしていません。タグの上書きやイメージの削除はご自身で管理されることが多いためです。このユースケースにご興味がある場合は、support@stablebuild.comenvelope までご連絡ください。

hashtag
レジストリミラー

Dockerfile のタグを変更できない場合（例：顧客向けにコンテナをビルドしている場合）、StableBuild をレジストリミラーとして使用することもできます。これは Dockerfile のベースイメージに手動でプレフィックスを付けるのとまったく同じ動作をしますが、すべてのサーバーでミラーを設定する必要があります。

設定するには、Docker の設定ファイルに以下を追加してください（macOS では Docker > Settings > Docker Engine、Linux では /etc/docker/daemon.json を編集）：

Kaniko を使用してビルドする場合は、以下のフラグを追加してください：

hashtag
ハッシュへのピン留めについて

タグへのピン留めの代わりに、Dockerfile で SHA ハッシュにピン留めすることもできます。これにより常に同じイメージが返されます。例：

残念ながら、これには 2 つのデメリットがあります：

  • SHA ハッシュはアーキテクチャに依存します。上記のハッシュは x86 コンテナを返します。マルチアーキテクチャコンテナを持っている場合（例：開発者が Mac を使用し、x86 でデプロイする場合）、ハッシュを使用できません。

  • イメージは依然として Docker Hub から削除される可能性があり、ビルドが壊れます。

StableBuild は SHA ハッシュからのプルもサポートしていますが、ほとんどの場合、タグからプルする方が適切です。

hashtag
v1 マニフェストは完全にはキャッシュされない

ubuntu:trusty-20150320 などの非常に古いベースイメージは、Docker Hub に古いマニフェストバージョンで存在しています。このようなベースイメージからプルすると、次のメッセージが表示されます：

これらのベースイメージについては、メインマニフェストはキャッシュしますが、アーキテクチャ固有のものはキャッシュしません。また、これらのイメージのレイヤーもキャッシュしません。これらのベースイメージに依存している場合は、更新することをお勧めします。

hashtag
5GB を超えるレイヤー

5GB を超えるレイヤーはダウンロード中にはキャッシュされず、非同期でキャッシュされます。StableBuild に保存されるまで数分（またはそれ以上）かかる場合があります。レイヤーをフェッチする際に返される x-in-sb-cache ヘッダーで状況を確認できます。

前へOS パッケージレジストリ（Ubuntu、Debian、Alpine）次へPyPI ミラー

最終更新