English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Dockerfileは、イメージを構築するためのテキストファイルで、構築に必要な各種コマンドと説明が含まれています。
ここでは、Dockerfile ファイルを実行してイメージをカスタマイズする方法について説明します。具体的な Dockerfile ファイル内の指令の詳細は、次のセクションで説明します。ここでは、ビルドの流れを知るだけで十分です。
1、以下で nginx イメージのカスタマイズ(ビルドされたイメージには /usr/share/nginx/html/index.html ファイル)
空のディレクトリに、Dockerfile という名前のファイルを作成し、その中に以下の内容を追加します:
FROM nginx RUN echo 'これはローカルでビルドされたnginxイメージです' > /usr/share/nginx/html/index.html
2、FROM と RUN 指令の役割
FROM:カスタマイズされたイメージは、FROM イメージに基づいています。ここでは nginx はカスタマイズする必要があるベースイメージです。後続の操作は nginx に基づいて行われます。
RUN:後続のコマンドラインコマンドを実行するために使用されます。以下の2つの形式があります:
shell フォーマット:
RUN <コマンドラインコマンド> # <コマンドラインコマンド> は、ターミナルで操作する shell コマンドに等しいです。
exec フォーマット:
RUN ["実行ファイル", "パラメータ1", "パラメータ2"] # 例: # RUN ["./test.php", "dev", "offline"] は RUN ./test.php dev offline
注意:Dockerfile のコマンドが一度実行されると、docker 上に新しいレイヤーが作成されます。したがって、意味のないレイヤーが多すぎると、イメージが大きくなります。例えば:
FROM centos RUN yum install wget RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" RUN tar -xvf redis.tar.gz 上記の実行では、以下を生成します 3 レイヤーイメージ。以下の形式に簡略化できます: FROM centos RUN yum install wget \ && wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \ && tar -xvf redis.tar.gz
上記のように、&& シンボルでコマンドを結合すると、実行後は 1 レイヤーイメージ。
Dockerfile ファイルが保存されているディレクトリで、ビルドアクションを実行します。
以下の例では、ディレクトリ下の Dockerfile を使って nginx:v3(イメージ名:イメージタグ)。
注:最後の . は今回の実行のコンテキストパスを表しており、次の節で説明します。
$ docker build -t nginx:v3 .
上記のように表示された場合、構築が成功したことを示しています。
前節で、最後の . はコンテキストパスであると述べました。では、コンテキストパスとは何ですか?
$ docker build -t nginx:v3 .
コンテキストパスは、Docker がイメージを構築する際に、時には本機のファイル(例えばコピー)を使用したい場合、docker build コマンドがこのパスを知ると、そのパスのすべての内容をパッケージ化します。
解析:Docker の実行モードは C/S。私たちの本機は C、Docker エンジンは S です。実際の構築プロセスは Docker エンジンで完了しますので、この時点では私たちの本機のファイルを使用することができません。これは、私たちの本機の指定されたディレクトリのファイルを一括でパッケージ化して Docker エンジンに提供する必要があります。
最後のパラメータが指定されていない場合、デフォルトのコンテキストパスは Dockerfile がある場所です。
注意:コンテキストパスに無用のファイルを置かないでください。なぜなら、それらは Docker エンジンに一括で送信され、ファイルが多いとプロセスが遅くなる可能性があります。
コピー命令、コンテキストディレクトリからファイルまたはディレクトリをコンテナ内の指定されたパスにコピーします。
フォーマット:
COPY [--chown=<user>:<group>] <ソースパス1>... <ターゲットパス> COPY [--chown=<user>:<group>] ["<ソースパス1>",... "<ターゲットパス>"]
[--chown=<user>:<group>]:オプションのパラメータ、ユーザーがコピーするコンテナ内のファイルの所有者およびグループを変更できます。
<ソースパス>:ソースファイルまたはソースディレクトリ、ここにはワイルドカード表現が使用できますが、ワイルドカードのルールは Go の filepath.Match ルールに従う必要があります。例えば:
COPY hom* /mydir/ COPY hom?.txt /mydir/
<ターゲットパス>:コンテナ内の指定されたパス、このパスは事前に作成する必要はありません。パスが存在しない場合、自動的に作成されます。
ADD 指令と COPY の使用形式は一致しており(同様の要件の場合、公式では COPY の使用を推奨しています)。機能も似ていますが、以下の点で異なります:
ADD の利点:<ソースファイル> が tar 圧縮ファイルの場合、圧縮形式は gzip、bzip です。2 xz の場合も、自動的に <ターゲットパス> にコピーおよび解凍されます。
ADD の欠点:解凍せずに tar 圧縮ファイルをコピーすることができません。イメージ構築キャッシュが無効化され、イメージ構築が比較的遅くなる可能性があります。使用するかどうかは、自動的に解凍する必要があるかどうかによって決定できます。
RUNコマンドに似ているが、実行されるタイミングが異なる、プログラムを実行するための命令です:
CMDはdocker runの際に実行されます。
RUNはdocker buildの際に実行されます。
役割:コンテナの起動時にデフォルトで実行するプログラムを指定します。プログラムが終了すると、コンテナも終了します。CMD命令で指定されたプログラムはdocker runコマンドライン引数で指定されたプログラムに覆されます。
注意:Dockerfile内に複数のCMD命令が存在する場合、最後のもののみ有効です。
フォーマット:
CMD <shell コマンド> CMD ["<実行可能ファイルまたはコマンド>","<param1>","<param2>",...] CMD ["<param1>","<param2>",...] # この書き方はENTRYPOINT命令で指定されたプログラムにデフォルトの引数を提供するためのものです
第二种形式を使用することをお勧めします。実行プロセスが明確です。第一种形式は実際には実行中にも自動的に第二种形式に変換され、デフォルトの実行可能ファイルはshです。
CMDコマンドに似ているが、docker runのコマンドライン引数で指定されたコマンドに覆されず、これらのコマンドライン引数はENTRYPOINTコマンドで指定されたプログラムに引数として渡されます。
ただし、docker runを実行する際に --entrypointオプションは、CMD命令で指定されたプログラムをオーバーライドします。
利点:docker runを実行する際に、ENTRYPOINTを実行するために必要な引数を指定できます。
注意:Dockerfile内に複数のENTRYPOINT命令が存在する場合、最後のもののみ有効です。
フォーマット:
ENTRYPOINT ["<executeable>","<param1>","<param2>",...]
CMDコマンドと組み合わせて使用できます:CMDは変数が使用される場合にのみ使用されますが、ここではCMDはENTRYPOINTに引数を渡すために使用されています。以下の例について説明します。
例:
仮にDockerfileを通じてnginx:testイメージが構築されていると仮定します:
FROM nginx ENTRYPOINT ["nginx", "-c"] # 定数 CMD ["/etc/nginx/nginx.conf"] # 引数変換
1、引数を渡さないで実行
$ docker run nginx:test
コンテナ内ではデフォルトで以下のコマンドが実行され、メインプロセスが起動します。
nginx -c /etc/nginx/nginx.conf
2、引数を渡して実行
$ docker run nginx:test -c /etc/nginx/new.conf
コンテナ内ではデフォルトで以下のコマンドが実行され、メインプロセスが起動します(/etc/nginx/new.conf:仮にコンテナ内にこのファイルがあると仮定します)
nginx -c /etc/nginx/new.conf
環境変数を設定し、環境変数を定義すると、以降のコマンドでこの環境変数を使用できます。
フォーマット:
ENV <key> <value> ENV <key1>=<value1> <key2>=<value2>...
以下の例では NODE_VERSION = 7.2.0 、以降のコマンドでは $NODE_VERSION を参照できます:
ENV NODE_VERSION 7.2.0 RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \ && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc"
構築パラメータは、ENVの作用と同じです。ただし、作用域が異なります。ARGで設定された環境変数は、Dockerfile内でのみ有効です。つまり、docker buildのプロセス中のみ有効で、構築されたイメージ内にはこの環境変数が存在しません。
docker build コマンドの構築コマンドで使用できます。 --build-arg <パラメータ名>=<値> でオーバーライドできます。
フォーマット:
ARG <パラメータ名>[=<デフォルト値>]
匿名データボリュームを定義します。コンテナの起動時にデータボリュームをマウントしなかった場合、自動的に匿名ボリュームにマウントされます。
作用:
重要なデータがコンテナの再起動で失われるのを防ぎます。これは非常に致命的です。
コンテナが常に大きくなるのを防ぎます。
フォーマット:
VOLUME ["<パス1>", "<パス2>"...] VOLUME <パス>
コンテナの起動 docker run の際に、以下のように -v パラメータでマウントポイントを変更します。
ただポートを宣言するだけです。
作用:
イメージのユーザーがこのイメージのサービスのデーモンポートを理解しやすく、マッピングの設定を簡単にするために使用されます。
ランダムなポートマッピングを使用して実行中、つまり docker run -P 時、自動的にランダムにEXPOSEされたポートがマッピングされます。
フォーマット:
EXPOSE <ポート1> [<ポート>2>...]
作業ディレクトリを指定します。WORKDIRで指定された作業ディレクトリは、イメージ構築の各レイヤーに存在します。(WORKDIRで指定された作業ディレクトリは、事前に作成されている必要があります。)
docker build イメージ構築プロセスの間、各 RUN コマンドは新しいレイヤーとして作成されます。WORKDIRで作成されたディレクトリのみが常に存在します。
フォーマット:
WORKDIR <作業ディレクトリパス>
次のコマンドの実行ユーザーやユーザーグループを指定するためのものです。ここでは、次のコマンドの実行ユーザーを切り替えるだけで、ユーザーやユーザーグループは事前に存在している必要があります。
フォーマット:
USER <ユーザー名>[:<ユーザーグループ>]
特定のプログラムやコマンドを使用してdockerコンテナのサービスの運行状態を監視するために使用されます。
フォーマット:
HEALTHCHECK [オプション] CMD <コマンド>:コンテナの健康状態を確認するコマンドを設定します HEALTHCHECK NONE:ベースイメージに健康チェックコマンドがある場合、この行を使用するとその健康チェックコマンドを無効にできます HEALTHCHECK [オプション] CMD <コマンド> : このCMDの後ろに続くコマンドの使用方法については、CMDの使用法を参照してください。
ビルドコマンドの遅延実行を目的としています。簡単に言えば、DockerfileでONBUILD指定されたコマンドは、今回のイメージ構築プロセスでは実行されません(イメージがtestの場合を仮定)-build)。新しいDockerfileが前のビルドで構築されたイメージFROM testを使用した場合-build、これは新しいイメージを実行するDockerfileのビルド時にtestを実行します-buildのDockerfileでONBUILD指定されたコマンド。
フォーマット:
ONBUILD <他の指示>