official images
1.0.0
Docker 公式イメージは、Docker Hub でホストされる厳選されたイメージです。主な教義は次のとおりです。
無料のオープンソース ソフトウェアに焦点を当てる
複数のアーキテクチャをサポート
Dockerfileベスト プラクティスを例示する
アップデートやセキュリティ修正のためにアクティブに再構築する
上流の推奨事項を遵守する
コンテナ環境に適した最小限の生活の質の動作を追加する
プログラムの概要については、Docker のドキュメントを参照してください。
基本的に、私たちはソフトウェアをどのように利用するかを上流側の推奨事項に従うよう努めています。多くのイメージは、関連する上流プロジェクトによって直接維持されていない場合、そのプロジェクトと協力して維持されます。さらに、Dockerfile から独自のイメージを作成または派生する際の参考となるよう、Dockerfile のベスト プラクティスを例示することを目指しています。
(イメージが存在するアップストリームの代表者で、参加したい場合は、以下の「メンテナンス」セクションを参照してください。)
一部のイメージは他のアーキテクチャ用に移植されており、その多くは (さまざまな程度で) 公式にサポートされています。
arm32v6 ): https://hub.docker.com/u/arm32v6/arm32v7 ): https://hub.docker.com/u/arm32v7/arm64v8 ): https://hub.docker.com/u/arm64v8/amd64 ): https://hub.docker.com/u/amd64/windows-amd64 ): https://hub.docker.com/u/winamd64/arm32v5 ): https://hub.docker.com/u/arm32v5/ppc64le ): https://hub.docker.com/u/ppc64le/s390x ): https://hub.docker.com/u/s390x/mips64le ): https://hub.docker.com/u/mips64le/riscv64 ): https://hub.docker.com/u/riscv64/i386 ): https://hub.docker.com/u/i386/ 2017 年 9 月 12 日の時点では、これらの他のアーキテクチャは、「マニフェスト リスト」 (OCI イメージ仕様では「インデックス」とも呼ばれます) を介してプレフィックスのないイメージの下に含まれています。たとえば、 docker run hello-world次のようになります。サポートされているすべてのプラットフォームでそのまま実行できます。
これらがどのように構築されるかについて興味がある場合は、https://doi-janky.infosiftr.net/job/multiarch/ にアクセスして、構築の足場を確認してください。
公式イメージにアーキテクチャを追加する際の推奨事項については、以下のマルチ アーキテクチャ セクションを参照してください。
はい！当社には専用の FAQ リポジトリがあり、その他のよくある質問 (プログラムと当社の実践の両方) を収集しています。
Docker 公式イメージ プロジェクトにご興味をお持ちいただきありがとうございます。私たちはこれらの手順をできるだけシンプルでわかりやすいものにするよう努めていますが、道に迷った場合は、チャンネル#docker-libraryの Libera.Chat IRC で、またはここで GitHub の問題を作成して、ためらうことなく私たちを探してください。
Docker Hub の公式リポジトリと、Docker ドキュメントの Dockerfile 作成のベスト プラクティスをよく理解してください。これらは、公式イメージ管理者によって実行されるレビュー プロセスの基礎となります。レビュー プロセスをよりスムーズに進めたい場合は、プル リクエストを送信する前に、 Dockerfileがそこに記載されているすべての点と以下に準拠していることを確認してください。
また、これらのイメージのハブの説明は、現在docker-library/docsリポジトリに個別に保存されており、その構造と貢献方法については、そのREADME.mdファイルで詳しく説明されています。ここで画像が承認されるまで、そこにも PR を送信する準備をしてください。
公式イメージは、Docker を初めて使用するユーザーのための学習ツールであるとともに、上級ユーザーが実稼働リリースを構築するための基本イメージを目的としているため、提案された各Dockerfileレビューして、品質と保守性の最低基準を満たしていることを確認します。その標準の一部は (主観のため) 定義するのが難しいですが、ここでは可能な限り定義し、必要に応じて「ベスト プラクティス」も遵守します。
保守者がレビュー中に使用できるチェックリストは、 NEW-IMAGE-CHECKLIST.mdにあります。
バージョンアップとセキュリティ修正にはタイムリーに対応する必要があります。
あなたが上流を代表せず、上流がイメージの保守に関心を持つようになった場合は、イメージ保守の責任を上流にスムーズに移行するための措置を講じる必要があります。
既存のリポジトリのメンテナシップを引き継ぐことに興味のあるアップストリームの場合、最初のステップは既存のリポジトリに参加することです。問題についてコメントすること、変更を提案すること、「イメージ コミュニティ」内で自分自身を知らせること (その「コミュニティ」が単なる現在のメンテナである場合でも) はすべて、移行が既存の寄稿者やユーザーにとって驚くべきものではないことを保証するために開始する重要な場所です。
既存のリポジトリを引き継ぐ場合は、移行中にレビュー プロセスが停止しないように、元のリポジトリの Git 履歴全体が上流で管理される新しいリポジトリに保持されていることを確認してください。これは、既存のリポジトリから新しいものをフォークすることで最も簡単に実現できますが、元のリポジトリから直接コミットをフェッチし、新しいリポジトリにプッシュすることによっても実現できます (例: git fetch https://github.com/jsmith/example.git master 、 git rebase FETCH_HEAD 、 git push -f )。 GitHub では、代替策として、git リポジトリの所有権を移動します。これは、どちらかのグループに他の所有者のリポジトリへの管理者アクセス権を付与しなくても実現できます。
同じDockerfile再ビルドすると、2 番目のビルドが数バージョン後に行われる場合でも、同じバージョンのイメージがパッケージ化される必要があります。または、 0.1.0としてタグ付けされたDockerfileの不注意による再ビルドが終了しないようにビルドが完全に失敗する場合もあります。 0.2.3を含むアップ。たとえば、 apt使用してイメージのメイン プログラムをインストールする場合は、必ず特定のバージョンに固定してください (例: ... apt-get install -y my-package=0.1.0 ... )。 aptによってインストールされた依存パッケージの場合、通常はバージョンに固定する必要はありません。
公式イメージは、非公式イメージから派生したり、非公式イメージに依存したりすることはできません (非イメージのscratchと、 .external-pinsに固定された意図的に制限された例外を許可します -- .external-pins/list.shも参照)。
すべての公式イメージは一貫したインターフェイスを提供する必要があります。初心者ユーザーは、 --entrypointについて学ぶことなく、 docker run official-image bash (またはsh ) を docker run できるはずです。また、上級ユーザーにとっては、実行するバイナリを指定せずにdocker run official-image --arg1 --arg2できるように、エントリポイントを利用すると便利です。
起動プロセスに引数が必要ない場合は、単にCMDを使用します。
CMD [ "irb" ]初期データベースの作成など、起動時に実行する必要がある初期化がある場合は、 CMDとともにENTRYPOINT使用します。
ENTRYPOINT [ "/docker-entrypoint.sh" ]
CMD [ "postgres" ] docker run official-image bash (またはsh ) も動作することを確認してください。最も簡単な方法は、予期されるコマンドをチェックし、それが別のコマンドである場合は、単にexec "$@"です (引数を適切にエスケープしたまま、渡されたものを実行します)。
#! /bin/sh
set -e
# this if will check if the first argument is a flag
# but only works if all arguments require a hyphenated flag
# -v; -SL; -f arg; etc will work, but not arg1 arg2
if [ " $# " -eq 0 ] || [ " ${1 # -} " != " $1 " ] ; then
set -- mongod " $@ "
fi
# check for the expected command
if [ " $1 " = ' mongod ' ] ; then
# init db stuff....
# use gosu (or su-exec) to drop to a non-root user
exec gosu mongod " $@ "
fi
# else default to run whatever the user wanted like "bash" or "sh"
exec " $@ "イメージにメインの実行可能ファイルとそのリンクされたライブラリのみが含まれている場合 (つまり、シェルがない場合)、実行できるのはそれだけであるため、実行可能ファイルをENTRYPOINTとして使用しても問題ありません。
ENTRYPOINT [ "fully-static-binary" ]
CMD [ "--help" ]これが適切かどうかを示す最も一般的な指標は、イメージDockerfile scratch ( FROM scratch ) で始まるかどうかです。
Dockerfile理解しやすく、読みやすくするように努めてください。簡潔にするために、複雑な初期化の詳細をスタンドアロン スクリプトに組み込み、 DockerfileにRUNコマンドを追加するだけでよい場合があります。ただし、これにより、結果のDockerfile過度に不透明になるため、そのようなDockerfileはレビューに合格する可能性が低くなります。代わりに、初期化用のすべてのコマンドを、適切なRUNまたはENVコマンドの組み合わせとしてDockerfileに入れることをお勧めします。良い例を見つけるには、現在の公式イメージを見てください。
執筆時点でのいくつかの例:
Docker ガイドラインに従って、結果として得られるイメージはコンテナーごとに 1 つの懸念事項のみにすることを強くお勧めします。これは主に、コンテナごとに 1 つのプロセスだけを意味するため、完全な init システムは必要ありません。 init のようなプロセスがコンテナーにとって役立つ状況は 2 つあります。 1つ目は信号処理です。起動されたプロセスが終了することでSIGTERM処理しない場合、コンテナ内では PID 1 であるため、プロセスは強制終了されません (docker docs の Foreground セクションの最後にある「注意」を参照)。 2 番目の状況は、ゾンビの刈り取りです。プロセスが子プロセスを生成し、それらを適切に取得しない場合、プロセス テーブルがいっぱいになり、システム全体が新しいプロセスを生成できなくなる可能性があります。これらの両方の懸念に対して、私たちは tini をお勧めします。これは信じられないほど小さく、外部依存性が最小限であり、これらの役割をそれぞれ果たし、刈り取りと信号転送の必要な部分のみを実行します。
必要に応じて、 CMDまたはENTRYPOINTで tini を必ず使用してください。
ディストリビューションが提供するパッケージ (例: apt-get install tini ) から tini をインストールするのが最善です。 tini がディストリビューションで利用できない場合、または古すぎる場合は、tini に追加するDockerfileのスニペットを次に示します。
# Install tini for signal processing and zombie killing
ENV TINI_VERSION v0.18.0
ENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7
RUN set -eux;
wget -O /usr/local/bin/tini "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini" ;
wget -O /usr/local/bin/tini.asc "https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc" ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$TINI_SIGN_KEY" ;
gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini;
command -v gpgconf && gpgconf --kill all || :;
rm -r "$GNUPGHOME" /usr/local/bin/tini.asc;
chmod +x /usr/local/bin/tini;
tini --versionこれは、悟りへの道において、経験が文書よりも優先される場所の 1 つですが、次のヒントが役立つかもしれません。
可能な限りCOPY / ADDは避けてください。ただし、必要な場合はできるだけ具体的にしてください (つまり、 COPY . /somewhereの代わりにCOPY one-file.sh /somewhere/ )。
その理由は、 COPY命令のキャッシュがファイルのmtime変更をキャッシュ バーストとみなしているためです。これにより、特に.git COPYする必要があるものの一部である場合など、 COPYのキャッシュ動作が予測不能になることがあります。
変更される可能性が低い行が、変更される可能性が高い行の前に来るようにしてください (各行は、後の行を想定せずに正常に実行されるイメージを生成する必要があることに注意してください)。
たとえば、ソフトウェアのバージョン番号を含む行 ( ENV MYSOFTWARE_VERSION 4.2 ) は、APT リポジトリ.listファイルを設定する行 ( RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.listの後に来る必要があります。 RUN echo 'deb http://example.com/mysoftware/debian some-suite main' > /etc/apt/sources.list.d/mysoftware.list )。
Dockerfileビルド中の傍受攻撃を軽減するために作成する必要があります。私たちの要件は、ソースの検証、作成者の検証、コンテンツの検証という 3 つの主な目的に重点を置いています。これらはそれぞれ次の方法で実現されます: 可能な場合は https を使用します。完全なフィンガープリントを含む PGP キーをDockerfileにインポートして署名を確認します。チェックサムをDockerfileに直接埋め込みます。可能な場合は 3 つすべてを使用する必要があります。署名が公開されていない場合は、https と埋め込みチェックサムのみを使用できます。サイトで https が利用できず、署名がない場合は、最後の手段として、埋め込みチェックサムのみを使用できます。
必要なアーティファクトのダウンロードに https の使用を推奨する目的は、ダウンロードが信頼できるソースから行われることを保証することであり、これにより傍受がさらに困難になります。
PGP 署名検証を推奨する目的は、許可されたユーザーのみが特定のアーティファクトを公開することを保証することです。 PGP キーをインポートするときは、可能な場合はkeys.openpgp.orgサービスを使用してください (そうでない場合はkeyserver.ubuntu.comを推奨します)。キーと検証に関する FAQ セクションも参照してください。
チェックサム検証を推奨する目的は、アーティファクトが期待どおりであることを検証することです。これにより、リモート コンテンツが変更されると Dockerfile も変更され、自然なdocker buildキャッシュ バストが提供されます。おまけに、バージョン管理が不十分なファイルに予期したよりも新しいアーティファクトを誤ってダウンロードすることも防止できます。
以下にいくつかの例を示します。
推奨: https 経由でダウンロード、PGP キーの完全なフィンガープリントのインポートとasc検証、埋め込みチェックサムの検証。
ENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)
RUN set -eux;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz" -o python.tar.xz;
curl -fL "https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc" -o python.tar.xz.asc;
export GNUPGHOME= "$(mktemp -d)" ;
# gpg: key F73C700D: public key "Larry Hastings <[email protected]>" imported
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D;
gpg --batch --verify python.tar.xz.asc python.tar.xz;
rm -r "$GNUPGHOME" python.tar.xz.asc;
echo "$PYTHON_DOWNLOAD_SHA512 *python.tar.xz" | sha512sum --strict --check;
# install代替:完全なキーのフィンガープリントが apt にインポートされ、パッケージがダウンロードおよびインストールされるときに署名とチェックサムがチェックされます。
RUN set -eux;
key= 'A4A9406876FCBD3C456770C88C718D3B5072E1F5' ;
export GNUPGHOME= "$(mktemp -d)" ;
gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ;
gpg --batch --armor --export "$key" > /etc/apt/trusted.gpg.d/mysql.gpg.asc;
gpgconf --kill all;
rm -rf "$GNUPGHOME" ;
apt-key list > /dev/null
RUN set -eux;
echo "deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}" > /etc/apt/sources.list.d/mysql.list;
apt-get update;
apt-get install -y mysql-community-client= "${MYSQL_VERSION}" mysql-community-server-core= "${MYSQL_VERSION}" ;
rm -rf /var/lib/apt/lists/*;
# ... (余談ですが、 rm -rf /var/lib/apt/lists/*はapt-get updateのほぼ逆です。これにより、層に最大 8MB の余分な APT パッケージ リスト データが含まれないようになります。適切なapt-get update使用を強制します。)
安全性の低い代替案:チェックサムをDockerfileに埋め込みます。
ENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)
RUN set -eux;
curl -fL -o ruby.tar.gz "https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz" ;
echo "$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz" | sha256sum --strict --check;
# install注: SHA1 または MD5 の使用は、どちらも一般に安全ではないと考えられているため、「最後の手段のチェックサム」として考慮する必要があります。
受け入れられません:検証なしで http 経由でファイルをダウンロードします。
RUN curl -fL "https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz" | tar ...
# install デフォルトでは、Docker コンテナは、ホワイトリストに登録された Linux 機能、コントロール グループ、およびデフォルトの Seccomp プロファイル (ホスト サポート付き 1.10 以降) の制限された権限で実行されます。コンテナ内で実行されるソフトウェアが正しく機能するには追加の権限が必要な場合があり、コンテナの実行をカスタマイズするためのコマンド ライン オプションが多数あります。参考として、 docker run Reference および Seccomp for Docker を参照してください。
追加の権限を必要とする公式リポジトリは、ソフトウェアが機能するために最小限のコマンド ライン オプションのセットを指定する必要がありますが、これにより移植性やセキュリティに重大な問題が発生する場合は拒否される可能性があります。一般に、 --privileged許可されませんが、 --cap-addと--deviceオプションの組み合わせは許容される場合があります。さらに、移植性やセキュリティの問題を引き起こすホスト ファイルシステムの場所 (X11 ソケットなど) が多数あるため、 --volume扱いにくい場合があります。
セキュリティ修正を構成するイメージ更新については、更新をできるだけ早くマージ、ビルド、リリースするために推奨されることがいくつかあります。
[email protected]に電子メールを送信して、事前情報とタイミングの見積もりを提供してください (これにより、今後の更新の時間を適切にスケジュールできます)。[security]を含めます (例: [security] Update FooBar to 1.2.5, 1.3.7, 2.0.1 )。各リポジトリでは、あらゆるタグに対して複数のアーキテクチャを指定できます。アーキテクチャが指定されていない場合、イメージはamd64 (別名 x86-64) 上の Linux でビルドされます。複数のまたは異なるアーキテクチャを指定するには、 Architecturesフィールドを使用します (カンマ区切りのリスト、空白は削除されます)。有効なアーキテクチャは、Bashbrew のoci-platform.goファイルにあります。
amd64arm32v6arm32v7arm64v8i386mips64leppc64leriscv64s390xwindows-amd64特定のタグのArchitectures 、そのFROMのタグのArchitecturesの厳密なサブセットである必要があります。
イメージには、複数のアーキテクチャに使用できるライブラリ ファイル内のエントリごとに 1 つのDockerfileが必要です。これは、サポートされている各アーキテクチャが同じFROM行を持つことを意味します (例: FROM debian:bookworm )。エントリごとに 1 つのDockerfileを使用するライブラリ ファイルの例については、 golang 、 docker 、 haproxy 、およびphpを参照し、 Dockerfileなどのそれぞれの git リポジトリを参照してください。
Dockerfile のさまざまな部分が 1 つのアーキテクチャまたは別のアーキテクチャでのみ発生する場合は、制御フロー (例: if / case ) をdpkg --print-architectureまたはapk -print-archとともに使用して、ユーザー空間アーキテクチャを検出します。より正確なツールをインストールできない場合にのみ、アーキテクチャの検出にuname使用してください。一部のアーキテクチャでは上流のソース パッケージからバイナリをビルドする必要があり、一部のアーキテクチャではバイナリ リリースをダウンロードするだけの例については golang を参照してください。
debianのような基本イメージの場合、アーキテクチャ固有のバイナリADDには、別のDockerfileとビルド コンテキストが必要になります。これは上記の有効な例外です。これらの画像は同じTags使用するため、同じエントリに存在する必要があります。 GitRepo 、 GitFetch 、 GitCommit 、およびDirectoryのアーキテクチャ固有のフィールドを使用します。これは、ハイフン ( - ) とフィールドで連結されたアーキテクチャです (例: arm32v7-GitCommit )。アーキテクチャ固有のフィールドを持たないアーキテクチャでは、デフォルトのフィールドが使用されます (たとえば、 arm32v7-Directoryがない場合はarm32v7にDirectoryが使用されることを意味します)。例については、ライブラリ内のdebianまたはubuntuファイルを参照してください。以下はhello-worldの例です。
Maintainers: Tianon Gravi <[email protected]> (@tianon),
Joseph Ferguson <[email protected]> (@yosifkit)
GitRepo: https://github.com/docker-library/hello-world.git
GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Tags: latest
Architectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x
# all the same commit; easy for us to generate this way since they could be different
amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
amd64-Directory: amd64/hello-world
arm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v5-Directory: arm32v5/hello-world
arm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm32v7-Directory: arm32v7/hello-world
arm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
arm64v8-Directory: arm64v8/hello-world
ppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
ppc64le-Directory: ppc64le/hello-world
s390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
s390x-Directory: s390x/hello-world
Tags: nanoserver
Architectures: windows-amd64
# if there is only one architecture, you can use the unprefixed fields
Directory: amd64/hello-world/nanoserver
# or use the prefixed versions
windows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87
Constraints: nanoserver
ライブラリ ファイルの形式の詳細については、命令形式のセクションを参照してください。
新しい公式イメージを提案することは、軽々しく行われるべきではありません。当社は、お客様のイメージを維持するための取り組みを期待し、要求しています (上記のとおり、特にタイムリーな更新を含む)。
ライブラリ定義ファイルは、 official-imagesリポジトリのlibrary/ディレクトリにあるプレーン テキスト ファイルです。各ライブラリ ファイルは、Docker Hub の説明に表示される、現在「サポートされている」イメージ タグのセットを制御します。ライブラリ ファイルから削除されたタグは Docker Hub からは削除されないため、古いバージョンは引き続き使用できますが、アップストリームまたは公式イメージのメンテナによって保守されません。ライブラリファイル内のタグは、そのライブラリファイルの更新を通じて、またはそのベースイメージが更新された結果としてのみ構築されます (つまり、 FROM debian:bookwormの構築時にdebian:bookwormからのイメージが再構築されます)。ベースに更新がある場合、ライブラリ ファイルにあるもののみが再構築されます。
このポリシーを考慮すると、バックフィルされたバージョン、リリース候補、継続的統合ビルドなど、いくつかのケースを明確にする価値があります。新しいリポジトリが提案される場合、最初のプル リクエストにサポートされていない古いバージョンを含め、承認後すぐに削除するという合意が得られるのが一般的です。これを、意図されていない包括的な歴史アーカイブと混同しないでください。 「サポートされる」という用語が少し拡張されるもう 1 つの一般的なケースは、リリース候補の場合です。リリース候補は実際には、短期間のリリースが予想されるものの命名規則にすぎないため、完全に受け入れられ、推奨されます。リリース候補とは異なり、コードのコミットまたは定期的なスケジュールに基づいて完全に自動化されたリリース サイクルを持つ継続的統合ビルドは適切ではありません。
新しいライブラリ/ファイルを作成する前に、既存のlibrary/ファイルの内容 (および履歴) を参照して、それらが時間の経過とともにどのように変化するかを把握することを強くお勧めします。これにより、一般的な規則を理解し、レビュー プロセスをさらに合理化することができます (つまり、難解な書式設定やタグの使用/命名ではなく、コンテンツに集中できるということです)。
定義ファイルのファイル名によって、Docker Hub 上に作成されるイメージ リポジトリの名前が決まります。たとえば、 library/ubuntuファイルはubuntuリポジトリにタグを作成します。
リポジトリのタグは、上流のバージョンまたはバリエーションを反映する必要があります。たとえば、Ubuntu 14.04 は Ubuntu Trusty Tahr としても知られていますが、多くの場合 (特に使用状況において) 単に Ubuntu Trusty と呼ばれるため、 ubuntu:14.04 (バージョン番号) とubuntu:trusty (バージョン名) が同じイメージ コンテンツの適切なエイリアスです。 Docker では、 latestタグは特殊なケースですが、これは少し誤った呼び名です。 latest実際には「デフォルト」タグです。 docker run xyz実行すると、Docker はそれをdocker run xyz:latestを意味すると解釈します。このような背景を考えると、他のタグには文字列latestが含まれることはありません。これは、ユーザーが実際に入力することを期待または推奨されていないためです (つまり、 xyz:latest実際には単にxyzとして使用されるべきです)。別の言い方をすると、「XYZ の最新の 2.2 シリーズ リリース」のエイリアスは、 xyz xyz:2.2-latest xyz:2.2にする必要があります。同様に、 xyz:latestの Alpine バリアントがある場合は、 xyz:alpine xyz:alpine-latest xyz:latest-alpineとしてエイリアス化する必要があります。
ユーザーが特定のシリーズの「最新」リリースを簡単に利用できるように、バージョン番号タグにエイリアスを付けることを強くお勧めします。たとえば、現在サポートされている XYZ ソフトウェア バージョン 2.3.7 および 2.2.4 の場合、推奨されるエイリアスはそれぞれTags: 2.3.7, 2.3, 2, latestおよびTags: 2.2.4, 2.2になります。この例では、ユーザーはxyz:2.2使用して 2.2 シリーズの最新のパッチ リリースを簡単に使用できます。また、より細かい粒度が必要な場合はxyz:2使用できます (Python は、これが最も明らかに便利な例です -- python:2とpython:3は大きく異なり、Python の各メジャー リリース トラックのlatestタグと考えることができます)。
上で説明したように、 latest実際には「デフォルト」であるため、ユーザーがどのバージョンを使用するかわからない場合、または気にしない場合、それがエイリアスであるイメージは、ユーザーが使用するソフトウェアのバージョンまたはバリエーションを反映する必要があります。 Ubuntu を例として使用すると、 ubuntu:latest最新の LTS リリースを指します。これは、大多数のユーザーが、Ubuntu が必要であることはわかっているが、バージョンが分からない、または気にしない場合に使用すべきものであるためです (特に、Ubuntu が今後リリースされることを考慮すると)。常に最も「安定した」リリースであり、十分にサポートされています）。
マニフェスト ファイル形式は正式には RFC 2822 に基づいているため、HTTP や電子メールなどの多くの一般的なインターネット プロトコル/形式の「ヘッダー」にすでに精通している人には馴染みのあるものであるはずです。
主な追加は、Debian が一般的に 2822 を使用する方法からインスピレーションを得たものです。つまり、 #で始まる行は無視され、「エントリ」は空白行で区切られます。
最初のエントリは、画像の「グローバル」メタデータです。グローバル エントリの唯一の必須フィールドはMaintainersで、その値はName <email> (@github)またはName (@github)の形式でカンマで区切られます。グローバル エントリで指定されたフィールドは、残りのエントリのデフォルトとなり、個別のエントリで上書きできます。
# this is a comment and will be ignored
Maintainers: John Smith <[email protected]> (@example-jsmith),
Anne Smith <[email protected]> (@example-asmith)
GitRepo: https://github.com/example/docker-example.git
GitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
# this is also a comment, and will also be ignored
Tags: 1.2.3, 1.2, 1, latest
Directory: 1
Tags: 2.0-rc1, 2.0-rc, 2-rc, rc
GitRepo: https://github.com/example/docker-example-rc.git
GitFetch: refs/heads/2.0-pre-release
GitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead
Directory: 2
File: Dockerfile-to-use
Bashbrew は、指定されたコミット ( GitCommit ) で Git リポジトリ ( GitRepo ) からコードをフェッチします。参照されているコミットが、関連付けられたGitRepoのmasterを取得しても利用できない場合は、必要なコミットを取得するためにどの参照を取得するかを Bashbrew に指示するために、 GitFetchの値を指定する必要があります。
ビルドされたイメージは<manifest-filename>:<tag>としてタグ付けされます (つまり、 Tags値が1.6, 1, latestのlibrary/golangはgolang:1.6 、 golang:1 、およびgolang:latestのタグを作成します)。
オプションで、 Directoryが存在する場合、Bashbrew はルートではなく指定されたサブディレクトリ内でDockerfileを検索します (また、 Directoryリポジトリのトップレベルではなくビルドの「コンテキスト」として使用されます)。 Fileが存在する場合は、 Dockerfileの代わりに指定されたファイル名が使用されます。
特定のアーキテクチャに対して異なるGitRepo 、 GitFetch 、 GitCommit 、またはDirectory指定する方法の詳細については、マルチ アーキテクチャのセクションを参照してください。
library/フォルダーに新しいファイルを作成します。その名前は、ハブ上のリポジトリの名前になります。Bashbrew ( bashbrew ) は、Docker 公式イメージのクローン作成、構築、タグ付け、およびプッシュを行うためのツールです。詳細については、Bashbrew READMEを参照してください。
