docker-build - クラウドでオンライン

プログラム：

NAME

docker-build - PATH にあるソース コードから新しいイメージをビルドする

SYNOPSIS

ドッカー ビルド [--ビルド引数[=[]]][--cpu-shares[=0]][--cgroup-親[=CGROUP-親]]
[ - 助けて] [-f|- ファイル[=パス/Dockerfile]][--force-rm] [- 分離[=デフォルト]][-キャッシュなし]
[- 引く] [-q|- 静かな] [--rm[=true]][-t|- 鬼ごっこ[=[]]][-m|- メモリー[=MEMORY]]
[--メモリースワップ[=LIMIT]][--shm サイズ[=SHMサイズ]][--cpu-期間[=0]][--cpu クォータ[=0]]
[--cpuset-cpus[=CPUSET-CPUS]][--cpuset-mems[=CPUSET-MEMS]][--ulimit[=[]]] パス | URL | -

DESCRIPTION

これにより、指定されたディレクトリから Dockerfile が読み取られます。 パス. また、
現在のディレクトリで見つかった他のファイルとディレクトリを Docker デーモンに送信します。 の
このディレクトリの内容は 追加 Dockerfile 内にあるコマンド。

警告、内容によっては大量のデータが Docker デーモンに送信されます。
現在のディレクトリ。 ビルドは CLI ではなく Docker デーモンによって実行されるため、全体が
コンテキストをデーモンに転送する必要があります。 Docker CLI は、「ビルド コンテキストを送信しています」と報告します。
コンテキストがデーモンに送信されると、Docker デーモンに」というメッセージが表示されます。

tarball アーカイブまたは単一の Dockerfile への URL が指定されている場合、コンテキストは送信されません
クライアントから Docker デーモンへ。 この場合、Dockerfile のルートにある
アーカイブと残りのアーカイブは、ビルドのコンテキストとして使用されます。 Git の場合
リポジトリは URLの場合、リポジトリはローカルで複製されてから、
コンテキスト。

OPTIONS

-f, - ファイル=パス/Dockerfile
使用する Dockerfile へのパス。 パスが相対パスで、あなたが
ローカルディレクトリからビルドする場合、パスはそのディレクトリからの相対パスでなければなりません
ディレクトリ。 次のいずれかを指すリモート URL から構築している場合、
tarball または Git リポジトリの場合、パスはのルートからの相対パスである必要があります
リモート コンテキスト。 いずれの場合も、ファイルはビルド コンテキスト内にある必要があります。
デフォルトは ドッカーファイル.

--ビルド引数=変数
の名前と値 構築.

たとえば、次の値を渡したい場合 http_proxyには
--build-arg=http_proxy="http://some.proxy.url"

ユーザーはビルド時にこれらの値を渡します。 Docker は、 ビルド引数 として
Dockerfile を介して実行されるコマンドの環境コンテキスト RUN 命令
または、他の Dockerfile 命令での変数展開用。 これは意図したものではありません
シークレット値を渡すため。 ⟨/reference/builder/#arg⟩

--force-rm=true|false
ビルドが失敗した後でも、常に中間コンテナーを削除します。 デフォルトは
false.

- 分離="デフォルト"
分離は、コンテナーで使用される分離テクノロジーのタイプを指定します。

-キャッシュなし=true|false
イメージのビルド時にキャッシュを使用しないでください。 デフォルトは false.

- 助けて
使用状況ステートメントを印刷する

- 引く=true|false
常に新しいバージョンのイメージをプルしようとします。 デフォルトは false.

-q, - 静かな=true|false
ビルド出力を抑制し、成功時にイメージ ID を出力します。 デフォルトは false.

--rm=true|false
ビルドが成功したら、中間コンテナーを削除します。 デフォルトは true.

-t, - 鬼ごっこ=""
結果のイメージに適用されるリポジトリ名 (およびオプションでタグ付き)
成功例。

-m, - メモリー=MEMORY
メモリ制限

--メモリースワップ=LIMIT
メモリとスワップに等しい制限値。 と一緒に使用する必要があります -m (- メモリー） フラグ。 の
swap LIMIT 常により大きい必要があります -m (- メモリー） 価値。

の形式 LIMIT is [ ]。 単位は次のとおりです b (バイト)、 k (キロバイト)、 m
(メガバイト)、または g (ギガバイト)。 単位を指定しない場合は、 b 使用されている。 リミットを次のように設定します -1 〜へ
無制限のスワップを有効にします。

--shm サイズ=SHMサイズ
のサイズ / dev / shm。 フォーマットは . 数 よりも大きくなければなりません 0.
ユニットはオプションであり、 b (バイト)、 k (キロバイト)、 m (メガバイト)、または g (ギガバイト)。
単位を省略した場合、システムはバイトを使用します。
サイズを完全に省略すると、システムは 64m.

--cpu-shares=0
CPU シェア (相対的な重み)。

デフォルトでは、すべてのコンテナーが同じ割合の CPU サイクルを取得します。
CPU シェアは、デフォルト設定の 1024 に対する「相対的な重み」です。
このデフォルト値は次のように定義されています。

cat /sys/fs/cgroup/cpu/cpu.shares
1024

この比率は、コンテナの CPU シェアを調整することで変更できます
実行中の他のすべてのコンテナーの重み付けに対する重み付け。

比率をデフォルトの 1024 から変更するには、 --cpu-shares
重み付けを 2 以上に設定するためのフラグ。

コンテナの CPU シェア フラグ
{C0} CPU の 60% --cpu-shares=614 (614 は 60 の 1024% です)
{C1} CPU の 40% --cpu-shares=410 (410 は 40 の 1024% です)

この割合は、CPU を集中的に使用するプロセスが実行されている場合にのみ適用されます。
XNUMX つのコンテナー内のタスクがアイドル状態の場合、他のコンテナーはそのタスクを使用できます。
残りの CPU 時間。 実際に使用される CPU 時間は、
システムで実行されているコンテナーの数。

たとえば、XNUMX つのコンテナーを考えてみましょう。 --cpu-shares=1024 &
他のXNUMX人が持っている --cpu-shares=512. XNUMXつすべてのプロセスの場合
コンテナが CPU の 100% を使用しようとすると、最初のコンテナは
合計 CPU 時間の 50%。 でXNUMX番目のコンテナを追加すると --cpu-shares=1024,
最初のコンテナーは CPU の 33% しか取得しません。 残りのコンテナ
CPU の 16.5%、16.5%、および 33% を受け取ります。

コンテナ CPU シェア フラグ CPU 時間
{C0} 100% --cpu-shares=1024 33%
{C1} 50% --cpu-shares=512 16.5%
{C2} 50% --cpu-shares=512 16.5%
{C4} 100% --cpu-shares=1024 33%

マルチコア システムでは、CPU 時間のシェアが CPU 全体に分散されます。
コア。 コンテナーが CPU 時間の 100% 未満に制限されている場合でも、
個々の CPU コアを 100% 使用します。

たとえば、XNUMX つ以上のコアを持つシステムを考えてみましょう。 XNUMXつ始めると
コンテナ {C0} 　 --cpu-shares=512 XNUMX つのプロセスと別のコンテナを実行する
{C1} 　 --cpu-shares=1024 XNUMX つのプロセスを実行すると、次のような結果になる可能性があります。
CPU シェアの分割:

PID コンテナ CPU CPU シェア
100 {C0} 0 CPU100 の 0%
101 {C1} 1 CPU100 の 1%
102 {C1} 2 CPU100 の 2%

--cpu-期間=0
CPU CFS (完全公平スケジューラ) 期間を制限します。

コンテナーの CPU 使用率を制限します。 このフラグにより​​、カーネルは
指定した期間のコンテナーの CPU 使用率。

--cpu クォータ=0
CPU CFS (完全公平スケジューラ) クォータを制限します。

デフォルトでは、コンテナはフル CPU リソースで実行されます。 このフラグにより​​、カーネルは
コンテナーの CPU 使用率を指定したクォータに制限します。

--cpuset-cpus=CPUSET-CPUS
実行を許可する CPU (0 ～ 3、0,1、XNUMX)。

--cpuset-mems=CPUSET-MEMS
実行を許可するメモリ ノード (MEM) (0 ～ 3、0,1、XNUMX)。 にのみ有効
NUMA システム。

たとえば、システムに 0 つのメモリ ノード (3 ～ XNUMX) がある場合は、次を使用します。 --cpuset-mems=0,1 〜へ
Docker コンテナ内のプロセスが最初の XNUMX つのメモリのメモリのみを使用するようにする
ノード。

--cgroup-親=CGROUP-親
への道 cgroup その下にコンテナの cグループ 作成されます。

パスが絶対パスでない場合、パスは cgroup のパス
初期化プロセス。 cgroup がまだ存在しない場合は作成されます。

--ulimit= []
Ulimitオプション

詳細については ulimit
⟨https://docs.docker.com/reference/commandline/run/#setting-ulimits-in-a-container⟩

例

建物 an 画像 a ドッカーファイル 位置して 内部 　 現在 ディレクトリにジョブを開始します。

Docker イメージは、build コマンドと Dockerfile を使用して構築できます。

ドッカービルド。

ビルド プロセス中に、Docker は中間イメージを作成します。 それらを維持するために、あなたは
明示的に設定する必要があります --rm=false.

docker build --rm=false 。

関連する名前でサブディレクトリを作成し、Dockerfile を作成することをお勧めします。
そのディレクトリに。 たとえば、mongo というディレクトリには、Dockerfile が含まれている場合があります。
Docker MongoDB イメージを作成します。 同様に、httpd と呼ばれる別のディレクトリを使用して、
Apache Web サーバー イメージの Dockerfile を保存します。

イメージに必要なファイルをサブディレクトリに追加することもお勧めします。
これらのファイルは、 COPY or 追加 の指示 ドッカーファイル.

注: tar ファイルを含めると (良い方法です)、Docker は自動的に展開します。
内で指定された tar ファイルの内容 追加 指定への指示
ターゲット。

建物 an 画像 & 命名 それ 画像

作成するイメージに名前を付けることをお勧めします。 a-z0-9-_ のみであることに注意してください。
一貫性のために使用する必要があります。 厳密なルールはありませんが、
名前の考慮。

　 -t/- 鬼ごっこ フラグは、画像の名前を変更するために使用されます。 ここではいくつかの例を示します。

良い習慣ではありませんが、イメージ名は任意にすることができます:

docker build -t myimage 。

より良いアプローチは、完全修飾された意味のあるリポジトリ、名前、およびタグを提供することです
(このコンテキストのタグは、「:」の後の修飾子を意味します)。 この例では、
Fedora リポジトリ用の JBoss イメージをビルドし、バージョン 1.0 を指定します。

docker build -t fedora/jboss:1.0 。

次の例は、「whenry」ユーザー リポジトリ用で、Fedora と JBoss を使用して、
バージョン 2.1 :

docker build -t whenry/fedora-jboss:v2.1 。

バージョン タグを指定しない場合、Docker が割り当てます 最新の:

docker build -t whenry/fedora-jboss 。

画像を一覧表示すると、上の画像にタグが付きます 最新の.

複数のタグを画像に適用できます。 たとえば、次のように適用できます。 最新の にタグを付ける
新しくビルドされたイメージを作成し、特定のバージョンを参照する別のタグを追加します。 たとえば、
両方の画像にタグを付ける whenry/fedora-jboss:最新 & whenry/fedora-jboss:v2.1には、Live モジュールで提供された
次のとおりです。

docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 。

したがって、画像の名前変更は任意ですが、有用な規則を考慮する必要があります
これは消費者にとって理にかなっており、Docker コミュニティも考慮に入れる必要があります
コンベンション。

建物 an 画像 a URL

これにより、指定された GitHub リポジトリが URL から複製され、コンテキストとして使用されます。 の
Dockerfile はリポジトリのルートにある Dockerfile を使用します。 これは、
GitHub リポジトリは専用のリポジトリです。

docker ビルド github.com/scollier/purpletest

注: を介して任意の Git リポジトリを設定できます。 ギット：// スキーマ

建物 an 画像 a URL 〜へ a ターボールした コンテキスト

これにより、URL 自体が Docker デーモンに送信されます。 デーモンは tarball を取得します
アーカイブして解凍し、その内容をビルド コンテキストとして使用します。 の Dockerfile
アーカイブのルートと残りのアーカイブがビルドのコンテキストとして使用されます。
合格した場合 -f パス/Dockerfile オプションも同様に、システムはそのファイルを探します
tarball の内容の中にあります。

docker build -f dev/Dockerfile https://10.10.10.1/docker/context.tar.gz

注: サポートされている圧縮形式は、「xz」、「bzip2」、「gzip」、および「identity」です (no
圧縮）。

指定 分離 テクノロジー for コンテナ （ - 分離）

このオプションは、Windows 上で Docker コンテナーを実行している場合に役立ちます。
　 --isolation= オプションはコンテナの分離テクノロジーを設定します。 Linux では、唯一の
サポートされているのは、 デフォルト Linux 名前空間を使用するオプション。 Microsoft Windows では、次のことができます。
次の値を指定します。

· デフォルト: Docker デーモンによって指定された値を使用します。 --exec-opt 。 もし デーモン ありません
分離テクノロジを指定しないと、Microsoft Windows が使用します プロセス デフォルトとして
の値です。

· プロセス: 名前空間の分離のみ。

· ハイパーブ: Hyper-V ハイパーバイザーのパーティションベースの分離。

の指定 - 分離 値のないフラグは設定と同じです
--isolation="デフォルト".

歴史

2014 年 XNUMX 月、William Henry (whory at redhat dot com) によって最初に編集されました。
docker.comのソース資料と内部作業。 2014年XNUMX月、SvenDowideitによって更新されました
⟨[メール保護]⟩ 2015 年 XNUMX 月、Sally O'Malley が更新 ⟨[メール保護]⟩

onworks.net サービスを使用してオンラインで docker-build を使用する