Moby: ビルド時間のみ-vオプション

私は同様の解決策を探しています。

問題

最近、私が働いている企業は、SSL検査を使用してZscalerプロキシを有効にしました。これは、証明書をインストールし、ビルド中にいくつかの環境変数を設定することを意味します。

一時的な解決策は、証明書と環境変数が設定された新しいDockerfileを作成することでした。 しかし、長期的に見ると、それは合理的ではないようです。

そのため、最初に考えたのはHTTPとHTTPSを使用した透過プロキシを設定することでしたが、ビルド中に証明書を渡す必要があります。

理想的なシナリオは、同じDockerfileを使用することです。ラップトップ、自宅、および企業でイメージを構築できます。

考えられる解決策

# Enterprise
$ docker build -v /etc/ssl:/etc/ssl -t myimage .

# Home
$ docker build -t myimage .

この機能の使用例は少し異なります。ASP.Net5パッケージマネージャーによってダウンロード/更新されるパッケージをキャッシュします。 パッケージマネージャーは独自のキャッシュフォルダーを管理するため、最終的にはビルド間で再利用できるフォルダーが必要になります。

すなわち：

docker build -v /home/dokku/cache/dnx/packages:/opt/dnx/packages -t "dokku/aspnettest" .

@yngndrwは、私にとっても問題ありません。つまり、コンテナにインストールされているため、実行時に必要のない追加のリソースをビルド時にマウントする必要があります。

FWIWこれらのページのどこかで、誰かが「同様のホストマシンでコンパイルの問題を解決してから、デプロイ可能なアーティファクトまたはexeをコンテナにインストールする」という言い換えをしているのを見ました。
私はそれがそれほど単純な人ではないのではないかと思います。 時々、/ usr / binにインストールする必要がありますが、いくつかの構成ファイルも編集する必要があります。 実行しているOS、調整する必要のあるカーネルパラメータ、変数またはマニフェストビルドファイルに応じて作成する必要のあるファイルを確認します。 コンパイルされた製品の単純なコピーでは満足できない多くの依存関係があります。

問題を開いたときに言ったことを言い直します。マニフェスト宣言ファイルとそのプロセス、およびアーティファクトの実行時間には違いがあります。
私たちがInfrastructure-as-Code、さらには不変のインフラストラクチャを本当に信じている場合、Docker自体がさらに推進していて、私はそれが好きです。これはIMOと真剣に検討する必要があります（ここの投稿1の肥大化を参照）

ありがとうございました

本当に興味深いもう1つの使用例は、ソフトウェアのアップグレードです。 FreeIPAの場合のように、本番データのコピーを使用して実際にテストし、さまざまなコンポーネントがすべて正常にアップグレードできることを確認する必要がある場合があります。 それでも、「ビルド」環境でアップグレードを実行する必要があります。 データの本番コピーを別の場所に配置して、アップグレードされた新しいバージョンのコンテナーを本番環境に移動したときに、アップグレードを行った正確なデータをマウンドできるようにする必要があります。

もう1つの例は、スキーマを頻繁に変更し、データベースをOracleからバージョン5.6（IIRC）のPostgresqlに変更するSatellite/Spacewalkです。

コンテナ化されたビルドでソフトウェアのアップグレードを行っているときに、特に分散/マイクロサービスを使用して一時的にデータにアクセスする必要がある場合は、非常に多くのシナリオがあります。

基本的に、-vバインドマウントを使用して通常のコンテナーを実行し、次に「docker commit」を実行することにより、手動アップグレードを実行する必要があります。 自動化されたDockerfileビルドで同じ機能が利用できない理由を理解できませんか？

キャッシュを指摘する@yngndrwの2番目：Maven、npm、apt、rpmなどの多くの一般的なプロジェクトにまったく同じ理由が当てはまります-共有キャッシュを許可すると、ビルドが劇的に高速化されますが、最終的なイメージにすることはできません。

@stevenschlanskerに同意します。 キャッシュボリュームをアタッチするための多くの要件、またはある種の数ギガバイトのデータである可能性があります。これらは、生データとしてではなく、最終イメージに（解析された状態で）存在する必要があります。

また、 docker runで使用できるボリュームをサポートするために、 docker buildを拡張することへの一貫した抵抗に悩まされてきました。 再構築するたびにパッケージリポジトリ全体を再ダウンロードする必要がある場合、Dockerイメージの開発と反復がより困難で時間がかかるように見えるため、「ホストに依存しないビルド」のマントラが非常に説得力があるとは思いませんでした。画像。

私の最初のユースケースは、開発の反復をスピードアップするためにOSパッケージリポジトリをキャッシュしたいというものでした。 私がある程度成功して使用している回避策は、 @ fatherlinuxによって提案されたアプローチに似ています。これは、 docker buildとDockerfileのレスリングを完全に放棄し、 docker runを使用して最初から開始することです。標準シェルスクリプトのdocker commitが続きます。

ちょっとした実験として、POSIXシェルスクリプトを少し使って、テクニックをdocker buildの本格的な代替品に拡張しました： dockerize 。

このスクリプトまたは一般的なアプローチをテストしたい場合は、それが興味深いか役立つか（または、まったく機能するかどうか）をお知らせください。 使用するには、スクリプトをPATHのどこかに置き、ビルドスクリプトのシバンとして追加し（ #!のもの）、Dockerインストールスクリプトの開始を示す2番目のシバン行の前に関連する環境変数を設定します。

FROM 、 RUNDIR 、およびVOLUME変数は、引数としてdocker runに自動的に渡されます。
TAG 、 EXPOSE 、およびWORKDIR変数は、引数としてdocker commitに自動的に渡されます。

他のすべての変数はシェルで評価され、環境引数としてdocker runに渡され、ビルドスクリプト内で使用できるようになります。

たとえば、このスクリプトはビルド間でAlpine Linuxパッケージをキャッシュして再利用します（VOLUMEはホームディレクトリをCACHEにマウントし、インストールスクリプトでOSのパッケージリポジトリキャッシュのシンボリックリンクとして使用されます）。

#!/usr/bin/env dockerize
FROM=alpine
TAG=${TAG:-wjordan/my-image}
WORKDIR=/var/cache/dockerize
CACHE=/var/cache/docker
EXPOSE=3001
VOLUME="${HOME}/.docker-cache:${CACHE} ${PWD}:${WORKDIR}:ro /tmp"
#!/bin/sh
ln -s ${CACHE}/apk /var/cache/apk
ln -s ${CACHE}/apk /etc/apk/cache
set -e
apk --update add gcc g++ make libc-dev python
[...etc etc build...]

それで、先週MesoConでDockerからフランスの派遣団に会った後（それは喜びの人でした）私は彼らが社内で同じ問題を抱えていることに気づき、彼らが必要なものを新しいスリムな画像にコピーするハックを開発しました。
私は、ハッキングは企業の世界では歓迎されていると思います;）そしてこの要求は適切に処理されるべきです。
聞いてくれてありがとう...

また、ビルド時にキャッシュディレクトリを共有することでビルドを高速化するために、ビルド時の-vフラグを追加することに賛成です。

@yngndrw2つの関連する問題を閉じた理由がわかりません。 私はあなたの＃59号を読みましたが、これがこれとどのように関連しているかわかりません。 場合によっては、実行時に必要がないときにコンテナが肥大化することがあります。 最初の投稿を読んでください。
ここで何かを見逃していないことを願っています...長い一日だったので：-o

@zrml問題https://github.com/aspnet/aspnet-docker/issues/59は、すべてのDockerファイルへのビルド中にdockerが提供する組み込みのレイヤーごとのキャッシュに関連していましたが、この現在の問題は、ホストボリュームを使用して、ボリュームを特別に使用するdockerfileに依存するdockerfile固有のキャッシュを提供することについて話し合っています。 問題https://github.com/aspnet/aspnet-docker/issues/59は、特にaspnet-dockerプロジェクト/リポジトリに関連していないため、閉じました。

あなたが言及していると思うもう1つの問題は、 https：//github.com/progrium/dokku/issues/1231の問題です。これは、組み込みのDockerレイヤーキャッシングを明示的に無効にするDokkuプロセスに関するものでした。 Michaelは、この動作を構成できるようにするためにDokkuに変更を加えました。これにより、Dokkuプロジェクト/リポジトリに関する問題が解決され、問題も解決されました。

未解決のDocker関連の問題がまだ存在する可能性があります（つまり、Dockerが問題https://github.com/aspnet/aspnet-docker/issues/59で期待したように組み込みのレイヤーキャッシングを処理しなかったのはなぜですか）。それがなぜであるかを解明し、それがまだ起こっているかどうかを確認する機会がありませんでした。 それでも問題が解決しない場合は、この現在の問題とは異なるため、このプロジェクト/リポジトリの新しい問題を提起する必要があります。

@yngndrwは正確に、これは異なり、@ docker.comとして知られていることに同意するので、よろしければ再開します...まあ、できません。 よろしいですか？
少なくともSFを閉じる前に、SFの同僚からのコメントをいくつか見たいです。

ところで、私は@ cpuguy83から、ユーザーケースを開いて、ログ＃3156からすべてを説明するように求められました。

@zrmlフォローするかどうかわかりません-再度開きたいのはhttps://github.com/aspnet/aspnet-docker/issues/59ですか？ これは/aspnet/ aspnet-dockerの問題ではないため、その問題を再度開くのは適切ではないと思います。 これは実際には/docker/ dockerの新しい問題であるはずですが、検証する必要があり、最初に生成される再現可能な手順が必要になります。

いや、いや、昨日閉店したこれ＃14080。

この問題はまだ開いていますか？

@yngndrw赤い「閉じた」アイコンを読み間違えたと思います。 謝罪。

ビルド時間-vが大きな助けになることに心から同意します。

ビルドキャッシングは1つのユースケースです。

もう1つのユースケースは、ビルド時にsshキーを使用して、レイヤーに保存せずにプライベートリポジトリからビルドすることです。これにより、 https ：//github.com/dockito/vaultのようなハッキングの必要がなくなります。

これは企業の世界では地獄なので、ここでコメントします。
SSLインターセプトプロキシがありますが、トラフィックを転送することはできますが、プロジェクトのヒープは、SSL接続が良好であると想定しているため、ひどく死んでしまいます。

私のマシン（したがってDocker Builder）はプロキシを信頼していますが、Dockerイメージは信頼していません。
さらに最悪のベストプラクティスは、コンテナー内でcurlを使用することです。これは面倒なので、Dockerfileを変更してビルドする必要があります。 -vオプションを使用して証明書をマウントでき、満足しています。

これは言われています。 Dockerのせいではなく、apt-getの動作と同様のシステムを使用する必要があるときにhttpsを使用するパッケージマネージャーのせいです。 それでも安全で検証可能であり、httpプロキシによってキャッシュすることもできます。

@btreppは、別の良いユースケースをありがとうございます。

別の状況が考えられます。

dockerfilesでやりたいことの1つは、「コンパイルされた」dockerfileを使用してビルドツールを出荷しないことです。 Cアプリがgccを必要とする理由も、rubyアプリがイメージ内のバンドラーを必要とする理由もありませんが、現在Dockerビルドを使用しています。

私が持っていたアイデアは、dockerfileを指定することです。これは、内部でビルドするときに複数のdockerコマンドを実行します。 以下の疑似っぽいdockerfiles。

他を構築するDockerファイル

FROM dockerbuilder
RUN docker build -t docker/builder myapp/builder/Dockerfile
RUN docker run -v /app:/app builder
RUN docker build -t btrepp/myapplication myapp/Dockerfile

btrepp / myapplication dockerfile

FROM debian:jessie+sayrubyruntime
ADD . /app //(this is code thats been build using the builder dockerfile
ENTRYPOINT ["rails s"]

ここに、すべてのバンドルインストール/パッケージ管理とビルドスクリプトを実行する一時コンテナーがありますが、ランタイムコンテナーが必要とするファイルを生成します。

ランタイムコンテナは、この結果を追加するだけです。つまり、rubyをインストールするだけで済みます。 たとえばGCCまたは静的にリンクされたgoの場合、実行するのにコアOSファイル以外のものは必要ないかもしれません。

これにより、Dockerイメージが超軽量に保たれます。

ここでの問題は、一時的なビルダーコンテナが最後になくなることです。つまり、ある種のキャッシュをロードする機能がないと非常に高価になり、 debian：jessieを何度も取得することになります。

このような特定の手法を使用している人を見てきましたが、外部httpサーバーを使用してビルドファイルを追加しています。 すべてをdockerでビルドし続けたいと思います。 Dockerイメージを使用してこれを適切に行う方法はおそらくありますが。 runを使用して、ボリュームをマウントできるようにします。

別の例を示します。 カーネルのすべてのデバッグシンボル（Yuuuuge）を含むsystemtapのコンテナーを作成するとします。 基盤となる/lib/ modulesをマウントして、yumコマンドがインストールするRPMを認識できるようにする必要があります。

さらに、1.5GBのイメージ（デバッグシンボルから）以外の場所にこれらをライブで配置したいのかもしれません

Dockerfileを書きに行ったところ、不可能だと気づきました:-(

docker run --privileged -v /lib/modules:/lib/modules --tty=true --interactive=true rhel7/rhel-tools /bin/bash
yum --enablerepo=rhel-7-server-debug-rpms install kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r)
docker ps -a
CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS                        PORTS               NAMES
52dac30dc495        rhel7/rhel-tools:latest   "/bin/bash"         34 minutes ago      Exited (0) 15 minutes ago                         dreamy_thompson
docker commit dreamy_thompson stap:latest

https://access.redhat.com/solutions/1420883

他の理由でバグがクローズされたので、ここで＃3949からユースケースを繰り返したいと思います。

Dockerでプロプライエタリソフトウェアをサンドボックス化したいのですが。 どこにでもホストすることは違法であり、ダウンロードプロセスを現実的に（または合法的に）自動化することはできません。 合計すると、インストーラーは約22GBになります（リリースごとに大きくなります）。 これをビルド時にDockerイメージにコピーする必要があると期待するのはばかげていると思います。

この必要な機能に関するニュースはありますか？
ありがとうございます

_USER POLL_

_このディスカッションに変更があった場合に通知を受け取る最良の方法は、右上の[購読]ボタンをクリックすることです。_

以下にリストされている人々は、ランダムな+1であなたの有意義な議論に感謝しています。

@vad

この機能の+1！

もう1つのユースケースは、ビルド時にsshキーを使用して、レイヤーに保存せずにプライベートリポジトリからビルドすることです。これにより、 https ：//github.com/dockito/vaultのようなハッキングの必要がなくなります。

これは私たちのユースケースでもあります（この場合、ホストでtmpfsを使用してレンダリングされたsshキー）。

これのもう1つの使用例は、ビルド時間を短縮するためのCIサーバー上のnode_modulesディレクトリのローカルキャッシュです。
npm installは非常に遅く、 package.jsonが画像にADDされている現在の「最良の」ケースでも、 npm installが実行されてからpackage.jsonへの変更に基づいて追加および構築された実際のプロジェクトソースは、すべての依存関係を再度ダウンロードする必要があります。

ノード/npm側でのこれに関する問題については、npm / npm＃8836を参照してください。

パッケージの復元が遅いことと、レイヤーに現在のパッケージをキャッシュした結果のイメージサイズに関する、関連するaspnet-dockerの問題。 パッケージのキャッシュには、マウントされたボリュームを使用する方がはるかに優れています。
https://github.com/aspnet/aspnet-docker/issues/123

これは言語固有の問題ではありません。パッケージマネージャーが現在受け入れられている標準であることを考えると、多くの人に影響があります。

OPは、「docker build -v」がビルドプロセスをランタイム環境から切り離すのに大いに役立つという点で、問題を頭に抱えています。

「マルベリーハーバー」を構築するいくつかのプロジェクトを見てきました。これらのプロジェクトは、実際のDockerを構築するために使用され、プッシュ/配布されます。 これは、管理とコンピューティングリソースの両方の観点から非常に複雑であり、CIと単体テストが遅くなり、全体的に生産性の低い開発ワークフローになります。

私はこれについて考えてきました、そして私が考えることができる他のオプションは「src」レイヤーとしてレイヤーをマークする機能です。

これらのレイヤーの線に沿ったものは、Dockerのビルド中にのみアクセス可能ですが、結果のイメージファイルにはプルされません。

このようにして、Dockerは以前のレイヤー/イメージ、一時的なビルドアーティファクトをキャッシュできますが、最終的なイメージを利用するためにこれらは必要ありません。

例えば。

FROM ubuntu
RUN apt-get install gcc
ADDPRIVATE . /tmp/src <--these can be cached by docker locally
RUNPRIVATE make     <-- basically these layers become scoped to the current build process/dockerfile
RUN make install <--result of this layer is required.

もちろん、これは、重要なファイルを除外することができるため、自分が何を上手く行っているかを知る必要があることを意味します。

@yngndrw
ネットコアのような状況でのはるかに優れたソリューションは、パッケージ管理にHTTPSを使用しないことです。その後、Dockerビルド用の透過的なキャッシングプロキシを持つようにiptables + squidを設定するのは簡単です。私の個人的な意見では、これらのパッケージマネージャーはゲームでは、sslが辞任するため、企業環境での使用はひどいものですが、apt-getなどは完全に正常に機能し、Docker用のiptables+squidで既にキャッシュ可能です。

また、ビルド時間ボリュームを使用することの欠点もわかります。dockerfileは再現性が低く、docker build -t btrepp / myappの外部で追加のセットアップが必要になります。また、dockerhubでの自動ビルドが困難になります。

@btrepp ：私はあなたの提案が好きです。 Dockerが教えてくれるハードコードされたTMPディレクトリを使用してユースケースを生きることもできます。これにより、すべてのレイヤーから最終的なアーティファクトを構築するときに、1つを忘れたり除外したりできるようになります。 /this_is_the_tmp_explosion_folder_that_will_be_removed_from_your_final_container_imageにマウントされています
簡単です...

@btrepp私はあなたのソースレイヤーのアイデアがとても好きです。

ただし、SSLを使用しないパッケージマネージャーに関しては、同意しない必要があります。

そのようなパッケージをキャッシュしたい場合は、公式ソースを反映した（ローカル）プライベートパッケージフィードを代わりに使用する必要があります。 HTTPに戻すことは私には悪い考えのように思えます。特に、多くのパッケージマネージャーがパッケージに署名していないようであり、したがってHTTPSに依存していることを考えると。

この問題がまだ修正されていないときに使用できるツールgrammarly/rockerがあります。

@yngndrw

ローカルプロキシなどである私のポイントは、長い間解決されてきた問題です。 パッケージマネージャーは検証のみが必要であり、プライバシーは必要ありません。 httpsを使用することは検証を提供する怠惰な方法ですが、プライバシーの添付ファイルが付属しています。

http（s）を介してプルダウンされるときに、「super_awesome_ruby_lib」をプライベートにする必要がある理由はありません。 より良い方法は、ルビーの宝石にキーリングを付けることです。 または、既知の公開鍵でさえ、パッケージに署名するためのものです。 これは多かれ少なかれapt-getの仕組みであり、標準のhttpプロキシが物事をキャッシュできるようにします。

ローカルのプライベートパッケージフィードに関しては、dockerはこれ自体もサポートしていません。 標準フィードを無効にする方法はありません。https証明書が証明書ストアにない場合は、_正しく_失われます。 Dockerは、画像をプルするときに、少なくともメインフィードを常にチェックしたいと思っていると確信しています。 Afaik the rocket / rktの実装では、signing+httpを使用してコンテナイメージを取得していました。

ビルド時間ボリュームの主な動機がパッケージのキャッシュだけである場合、現在のDockerの自動化/純粋性の一部を損なうのではなく、キャッシュをより適切にサポートするようにパッケージマネージャーに圧力をかける必要があると思います。

明確にするために、私はパッケージマネージャーがhttpを使用してhttpsを削除するだけに切り替えることを推奨していません。 中間者攻撃を防ぐために、パッケージの検証が必要です。 彼らが必要としないのは、httpsを「セキュリティがすべてのスレッジハンマーを捕まえる」提供として使用するプライバシーの側面です。

それは本当に狭い視野です。 あなたは、パッケージマネージャーの世界全体に、アプリケーションが構築されると彼らが考える方法に関するDockerの規定に合うように彼らがどのように振る舞うかを変更するように求めています。

このスレッドでこれが必要な理由の例は他にもたくさんあります。 「アプリケーションの構築に使用するすべてのツールの動作を変更するだけでよい」と言っても、問題は解決されません。ユーザーを回避するだけです。

（Dockerのパブリックレジストリへのアタッチメントにも強く同意しません。パブリックレジストリへのアクセスを禁止し、内部レジストリのみを使用できるようにすることを強く望んでいます。しかし、それはまったく別のテーマです。）

私にとってはdocker build -vも必要です。

この例では、関連する製品の事前構成されたインストールで構成されるイメージを構築する必要があり、インストーラーは2GBを超えています。 ホストボリュームをマウントできないため、ホストOSに既にダウンロードしているにもかかわらず、インストーラーでイメージをビルドできません。ホストOSには、さまざまなツール/プロトコル、たとえばhttps cert/authを使用したプロキシを使用できます。 、または多分少し急流。

回避策として、 docker buildの間にwgetを使用してインストーラーを再ダウンロードする必要があります。これは、非常に制限された環境であり、利便性がはるかに低く、時間がかかり、エラーが発生しやすくなります。

また、製品のインストール/構成オプションの柔軟性により、単にインストーラーでイメージを出荷するよりも、製品がプレインストールされた状態でイメージを出荷する方がはるかに理にかなっています。

@thaJeztahこれが起こる可能性はありますか？

これが、Dockerを使用しない（または実際には使用できない）唯一の理由です。

-vオプションを含むDockerのRedHatバージョンでパッチを提供しています。 しかし、これに対する真の解決策は、Dockerビルド以外のOCIコンテナイメージをビルドするための新しいさまざまな方法を構築することです。

@rhatdan RHELまたはFedora？

また、resin.ioの内部バージョンのdockerにdockerbuildの-vオプションを実装しました。 ここで差分を見つけることができますhttps://github.com/resin-io/docker/commit/9d155107b06c7f96a8951cbbc18287eeab8f60cc

@rhatdan @petrosaggこのためのPRを作成できますか？

@jeremyherbertパッチは、RHEL、CentOS、およびFedoraの最近のすべてのバージョンに付属するdockerデーモンに含まれています...

@graingert過去に提出しましたが、却下されました。

@rhatdanあなたはそれにリンクがありますか？

@runco​​mリンクはありますか？

@thaJeztahこれはあなたたちが拒否したであろうものですか？

クローズされた、または対応されていない既存の問題のリストは次のとおりです。
https://github.com/docker/docker/issues/3949
https://github.com/docker/docker/issues/3156
https://github.com/docker/docker/issues/14251
https://github.com/docker/docker/issues/18603

RHEL / CentOS /Fedoraで使用されるProjectAtomicパッチに関する情報は、次の場所にあります。
http://www.projectatomic.io/blog/2016/08/docker-patches/

@daveisferaは、RWボリュームではなくRボリュームのみを追加するように見えるため、 @yngndrwと私のユースケースでは機能しません。

@graingertなぜRWボリュームが必要なのですか？ 特定の場合の回避策として、読み取り専用を理解しています。

スキーマの移行をテストすることは、1つの正当な理由です...

2016年11月1日午前10時36分、ブライアンゴフは次のように書いています。

@graingert https://github.com/graingertなぜRWボリュームが必要なのですか？
特定の場合の回避策として、読み取り専用を理解しています。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/14080#issuecomment -257582035、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAHLZdp0D6fAtuNglajPBIwnpWGq3slOks5q5050gaJpZM4FIdOc。

スコットマッカーティ

スコット。 [email protected]

http://crunchtools.com

@fatherlinux

@cpuguy83RWのもう1つのユースケースはccacheです

@fatherlinuxフォローするかどうかわかりません。 なぜこれにボリュームが必要なのですか？ また、なぜビルドフェーズで実行する必要があるのですか？

この機能の使用例は少し異なります。ASP.Net5パッケージマネージャーによってダウンロード/更新されるパッケージをキャッシュします。 パッケージマネージャーは独自のキャッシュフォルダーを管理するため、最終的にはビルド間で再利用できるフォルダーが必要になります。

たとえば、マウントをバインドします。

docker build -v /home/jenkins/pythonapp/cache/pip:/root/.cache/pip  -t pythonapp .
docker build -v /home/jenkins/scalaapp/cache/ivy2:/root/.ivy2  -t scalaapp .

スキーマの移行は、次の場合に実行する必要があることが多いためです。
ソフトウェアがインストールされます。 読み取り専用コンテナを実行する場合は、
にいるとき以外はソフトウェアをインストールしないでください
ビルドフェーズ....。

2016年11月1日午前10時42分、ブライアンゴフは次のように書いています。

@fatherlinuxhttps ://github.com/fatherlinuxフォローするかどうかわかりません。
なぜこれにボリュームが必要なのですか？ また、なぜそれが中に行われなければならないのですか？
ビルドフェーズ？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/14080#issuecomment -257583693、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAHLZfhBG8RUWtqPD-6RaLC7uoCNc-3nks5q50_TgaJpZM4FIdOc。

スコットマッカーティ

スコット。 [email protected]

http://crunchtools.com

@fatherlinux

このディレクトリの内容によってビルドがホストに依存することはないことを私は知っています（これらのマウントがないと、ビルドはとにかく動作しますが、遅くなります）

NFSは30年前のようにこれを解決しました...

2016年11月1日午前10時45分、トーマス・グレインジャーは次のように書いています。

このディレクトリの内容がビルドを停止しないことを私は知っています
べき等またはホストに依存している（これらのマウントが欠落していると、
とにかく動作するビルド）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/14080#issuecomment -257584576、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAHLZS75Vq0BSEvUjI2oXORsS0el2mwOks5q51CQgaJpZM4FIdOc。

スコットマッカーティ

スコット。 [email protected]

http://crunchtools.com

@fatherlinux

NFSは30年前のようにこれを解決しました...

役に立たないコメント

@graingert申し訳ありませんが、それは深刻に間違っていました。 私はあまりにも迅速に対応しようとしていて、十分なコンテキストを提供していませんでした。 真剣に、私たちはこれらのタイプの問題のいくつかを解決するためにCRIOと組み合わせたNFSを検討しています。

イメージレジストリとbuldの両方に、多くの共通点があります。 あなたが話しているのは基本的にキャッシングの問題です。 NFS、特に組み込みのキャッシングにより、ビルドをホストに依存せず、すべてのキャッシングを処理できます。

したがって、-vビルド時間オプションを使用しても、ビルドを1つのホストのみにロックする必要はありません。 インターネットの規模に依存しない場合もありますが、ビルド環境を単一のサイトまたは場所に制御する多くの人にとっては十分です。

@fatherlinux gitlabまたはtravisキャッシングを使用して、キャッシュディレクトリを取得し、S3にアップロード/ダウンロードします。

@graingertええ、しかしそれは特定のタイプのデータ/アプリでのみ機能し、またバケットレベルでのみ機能し、posixメタデータとブロックレベルでは機能しません。 certianタイプのフロントエンドおよびミドルウェアアプリの場合、問題ありません。 データベーススキーマの移行では、事前にテストを行い、速度を上げるためにキャッシュをローカルにする必要があります。通常、キャッシュはposixである必要があります。

1TBのデータを含むMySQLGaleraクラスターがあり、アップグレードを実行したいとします。これらはすべてコンテナー内にあります。 コンテナ化/オーケストレーションされたマルチノード、シャーディングされたガレラは本当に便利です。 アップグレードのたびにスキーマの移行を手動でテストする必要はありません。

データボリューム（Kube Worldではpv）のスナップショットを作成し、ビルドサーバーに公開してから、アップグレードとスキーマの移行をテストします。 すべてが正常に機能し、テストに合格した場合は、本番コンテナを構築し、本番環境でスキーマの移行を実行します。

@graingert申し訳ありませんが、追加するのを忘れて、テスト実行で使用されたスナップショットを破棄します...ビルドイベントとテストイベントを別々にオーケストレーションしたくありませんが、それは可能です...

@fatherlinuxこれは直交するユースケースだと思います...

@graingertは有用なコメントではありません。 何に直交しますか？ ビルド中の-vの要求に直交します。これは、この会話の内容であると私が理解したものですか？

このフラグにはいくつかの異なる用途があります。

• キャッシュ、Dockerビルドサーバー間で共有
• 単一のDockerfileの「ビルド中」にのみ適用されるADDのようなキーワード。 たとえば、巨大なファイルを追加してから、画像から除外します。
• すべての出力を無視するADD+RUNのようなキーワード。 たとえば、巨大なファイルを追加してから、ステップを実行し、画像への変更を無視します。1つのステップでADD + RUNを実行してから、レイヤーをスキップします。

後の2つのユースケースは、2つの新しいキーワードを使用してより明確に解決できます。

BUILDCONSTFILE <path>

各実行の前にCOPY <path>を実行し、実行後に<path>をイメージから削除します。

TEST <cmd> WITH <paths>

パスをコピーしてコマンドを実行し、終了ステータスが0の場合、親イメージからビルドを続行します。それ以外の場合は、ビルドを停止します。

個人的には、TEST ... WITHは、コンテナー全体をテストする別のCIステップでより適切に処理されると思います。

はじめに：私はビルドに--mountを追加しても大丈夫だと_思います_（ "-v"はおそらくそれほど多くはありません）。 実装、キャッシングがどのように処理されるか（または処理されないか）などについて100％確実ではありません。

Dockerプロジェクトの場合、ビルダーイメージをビルドします。
基本的に必要なものはすべて揃っており、コードをコピーしますが、実際にはDockerをビルドしません。
これを調整するMakefileがあります。 したがって、 make buildはイメージをビルドし、 make binaryは依存関係としてbuildを使用してバイナリをビルドします。

バイナリを作成すると、ビルドイメージが実行され、ビルドが実行されます。これにより、インクリメンタルビルドのパッケージキャッシュなど、必要なものにマウントできます。
これのほとんどは非常に単純で、簡単に調整できます。
したがって、今日このケースを処理する方法は確かにあります。Dockerだけでは100％処理できず（これは必ずしも悪いことではありません）、CIシステムでこれを機能させる必要があります。

@cpuguy83これは私のユースケースのほとんどを釘付けにするだろうと思います。 私が理解しているように、--mountは読み取り専用を意味しますか？ および-vを読み取り/書き込みしますか？

@ cpuguy83また、私たちは主に、IMHOがますます一般的なパターンになりつつある「ビルダー」イメージを構築しています...

@fatherlinux swarm servicesおよび現在（1.13の場合） docker runは、はるかに正確で柔軟な--mountをサポートしています： https ：//docs.docker.com/engine/reference/commandline/service_create/#

ドキュメントに3番目のタイプのマウントtmpfsがないようです。

ああ、とてもかっこいい、ありがとう...

2016年11月1日午後2時20分、ブライアンゴフは次のように書いています。

@fatherlinux https://github.com/fatherlinux swarm services and now
（1.13の場合）| docker run | |--mount|をサポートしますこれははるかに正確です
柔軟：
https://docs.docker.com/engine/reference/commandline/service_create/#/add -bind-mounts-or-volumes

ドキュメントに3番目のタイプのマウント|tmpfs|がないようです。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/docker/issues/14080#issuecomment -257648598、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAHLZXv_VBfVi4WUAjVijE-SKR0ErRC4ks5q54L2gaJpZM4FIdOc。

スコットマッカーティ

スコット。 [email protected]

http://crunchtools.com

@fatherlinux

@ cpuguy83ビルダーパターンも頻繁に使用しており、画像に保持されず、レイヤーの無効化にも耐えられるキャッシュが必要です。

Yoctoイメージを構築し、NFSストレージに共有sstateキャッシュがあります。 もう1つのユースケースはnpmキャッシュです。これにより、 RUN npm installレイヤー全体を無効にできますが、パッケージがキャッシュされるため、より高速に再計算できます。

@graingertの投稿に基づく考えられる妥協案として、dockerfileに巨大なファイルのオプションのハッシュを含めることができず、dockerはビルドの実行時にこれをチェックしますか？ その場合、決定論的ビルドに問題はなく、ある時点で奇妙なエラーで爆発するのではなく、ビルドする人にとって必要な依存関係がないことは明らかです。 とにかくdockerfileと一緒に配布する必要があるsshキーなどにも同じことが言えます。

また、巨大なファイルの_コピー_を必要とするアイデアは理想的ではないと思います。 私が使用したいファイルサイズは10〜40 GBのオーダーであり、優れたssdを使用しても、少なくとも1〜2分はコピーする価値があります。 これは、DockerにすでにあるADDディレクティブに関する私の問題です。 イメージがビルドされるたびに30GBを追加したくないので、余分な空き領域をすべて確保し、イメージを潰す必要があります。

これを使用している目的では機能しません。 キャッシュミスはビルド中に計算され、将来のためにsstateに保存されるため、ビルドでバインドマウントされたRWであるyoctoビルドシステムからのsstateキャッシュを含むボリュームがあります。 私たちのディレクトリも約30GBなので、ハッシュの計算でさえ時間がかかります。

決定論的なビルドの概念を理解したことはありません。 今日のセマンティクスでも、自分の足を撃つ方法があります。 たとえば、内部IPからcurl何かを取得できます。 突然、このDockerfileはどこでも機能しなくなり、ホストに依存します。 しかし、なぜあなたがそれをしたいのかという正当なケースがあります。 たとえば、ローカルHTTPキャッシュ。

ビルドはとにかく決定論的ではなく、今日のネットワーク上でバインドマウントされたボリュームをエミュレートできるので、必要に応じて適切な警告を表示するネイティブな方法を提供してみませんか？

@petrosagg @zrml @thaJeztah私たちが知っていることは：

• ＃7115＃3156を調べてみると、この同じ問題について議論している何年も前の問題の長いリストを見つけることができます
• ほとんどは再現性の理由でクローズされました（または古いDockerfile syntax is frozenコメント、そしてHEALTHCHECK命令が追加された後、フリーズは削除されましたが、問題はクローズされたままでした）
• この問題により、多くのチームが長年にわたって日常の開発でコンテナの使いやすさや生産性を向上させることができなくなりました。 @btreppが言ったように、これは地獄です
• Dockerの人々はこの問題に気づいていますが、これは私のdockerビルドが壊れたクラスをもたらすでしょう！ 共有キャッシュが良くないために問題が発生する
• しかし、ディスクキャッシュからネットワークキャッシュに移行しても、ビルドの信頼性は向上しないようで、httpを介した栄光のキャッシュとして機能し、事態を悪化させることがわかっています（ビルドごとにインターネットをダウンロードする、HTTPS、ファイルのサイズ、コンテナのビルド時のディスクスラッシング、レイヤーキャッシング、複雑なビルドオーケストレーションなど）

私たちが知っていることをすべて考えると、これはDupeまたはWontFixのいずれかとしてクローズされる可能性が高いと思います。 私たちがどのようなユースケースを提供するかは問題ではないようです。 更新：ここで間違っていることを嬉しく思います。 提案はオープンに見えます:)

当社は不可知論的なコンテナランタイムに移行し、まもなく不可知論的なイメージ構築エクスペリエンスにも移行する必要があります。 しかし、否定性は役に立たないので、これはそれを議論するのに適切な場所ではありません。 それは別の投稿である必要があります。

@rdsubhasは、完了したらリンクを共有することに気を配っていますか？

@rdsubhasそれは素晴らしい要約です。 @ cpuguy83は、ほとんどのユースケースをカバーするビルド中に--mountを追加しても問題ないと考えているため、このスレッドはdupe/wontfixとして閉じられるようには見えません。

私が知りたいのは、現在の提案が与えられていることです：

1. Dockerfile構文を変更しません
2. ビルドを現在よりもホストに依存させることはありません

アイデアに関して残された反論はどれですか？ ない場合は、 --mountメカニズムの実装の詳細について話し合う必要があります。

ビルドはすでにホストに依存しており、再現できないという議論を強化するために、このプロパティを持つDockerfileフラグメントのリストを提供します。

# Install different software depending on the kernel version of the host
RUN wget http://example.com/$(uname -r)/some_resource

# example.intranet is only accessible from specific hosts
RUN wget http://example.intranet/some_resource

# get something from localhost
RUN wget http://localhost/some_resource

# gcc will enable optimizations supported by the host's CPU
RUN gcc -march=native .....

# node:latest changes as time goes by
FROM node

# ubuntu package lists change as time goes by
RUN apt-get update

# install different software depending on the docker storage driver
RUN if [ $(mount | head -n 1 | awk '{print $5}') == "zfs" ]; then .....; fi

正直なところ、 --mountを追加して、ユーザーにキャッシュの無効化（ --no-cache ）を処理させるだけで、問題はないと思います。 CLIからのよりきめ細かいキャッシュ制御を、すべてまたは何もないよりも見たいと思うかもしれませんが、それは別のトピックです。

私のユースケース

私はしばらくの間同様の問題に直面していますが、解決策が完成するまで画像のサイズを大きくすることを選択しました。 誰かがより良い回避策を見つけた場合に備えて、ここで私のシナリオを説明しようと思います。

条件

1. CircleCIには、ビルド中にすべての内部依存関係をダウンロードするためのsshキーがあります
2. GitHubは内部依存関係をホストし、その他はビルド中にイメージ内からダウンロードできます

オプション

1. --build-argを使用して、ビルド中にトークンを渡します（強くお勧めしません）。 これは、追加の手順なしで「機能する」ため、非常に魅力的で簡単なオプションです。
2. すべての依存関係をダウンロードして、ビルドコンテキストに追加します。 残念ながら、 ADDとCOPYは別々のレイヤーで実行されるため、前のレイヤーのデータで行き詰まります。

一部の画像のサイズが2倍以上になる場合もありますが、現時点では全体のサイズは許容範囲内です。 ビルド履歴からビルド時間引数を削除するPR（私はそれを見つけることができないようです）があったと思いますが、キャッシュの懸念irrcのために受け入れられませんでした。
他の回避策が使用されていると聞いてうれしいです。

@misakwa1.14のビルドでシークレットをサポートする可能性があります。

@cpuguy83を聞いてとてもエキサイティングです。 発売時期に注目します。 それは間違いなく私のワークフローのいくつかを単純化するでしょう。

1.14でのビルドでシークレットをサポートする可能性があります。

yarn-cacheなどの他のタイプのボリュームのビルド時マッピングのマッピングにも機能しますか？

ところで、docker-composeを使用してプロダクションイメージを構築する興味深い方法があります。私はそれが機能し、非常に効果的であることがわかりました。

したがって、次のようなファイルdocker-compose.build.ymlを作成します。

services: 
  my-app:
    image: mhart/alpine-node:7.1.0
    container_name: my-app-build-container # to have fixed name
    volumes:
    - ${YARN_CACHE}:/root/.cache/yarn # attach yarn cache from host
    - ${HOME}/.ssh:/.ssh:ro    # attach secrets
    - ./:/source
    environment: # set any vars you need
     TEST_VAR: "some value"    
    ports:
    - "3000"
    working_dir: /app/my-app # set needed correct working dir even if if doesn't exist in container while build type
    command: sh /source/my-app.docker.build.sh # build script

1）dockercomposeを使用してコンテナーを構築します。

$ docker-compose -f docker-compose.build.yml up --force-recreate my-app

コンテナを作成し、シェルビルドスクリプトmy-app.docker.build.shを実行します。私は、 Dockerfileを使用せず、ビルドスクリプトですべてを実行します。

• 必要なOSパッケージをインストールする
• 必要なソースコードをコピーします（マップされ/sourceフォルダーから）
• 依存関係をインストールする
• 必要に応じてビルド/コンパイル/テスト
• ターゲット環境が機能するために必要のないパッケージやものを削除します（最終的なイメージサイズを縮小するため）

次に、コンテナーからイメージを作成し、ターゲット環境で実行する必要があるCMDを置き換えます。

docker commit -c "CMD npm run serve" my-app-build-container my-app-build-image:tag

これで、イメージの準備が整い、ビルド時にのみ使用できる外部ヤーンキャッシュと外部シークレットキーが使用されます。

@whitecolorうん、動作します:) 1つを除いて： docker buildは、ビルドコンテキストのアップロードに非常に効果的です。 マウントされたソースボリュームは、残念ながらリモートのDockerデーモンでは機能しません（たとえば、低電力/帯域幅のラップトップ用のクラウド上のDockerマシン）。 そのためには、面倒なdocker run 、 docker cp 、 docker runなどの一連のDockerコマンドを実行してから、最終的なイメージのスナップショットを作成する必要がありますが、実際にはハッキーです。

これをDockerビルドの正式な部分にし、レイヤー化とビルドコンテキストを使用することは本当に役立ちます😄

@rdsubhasはい、あなたは正しいです

@whitecolorそれは本当にシンプルで効果的な解決策です。 プロジェクトのビルドを30〜40分で約5分に短縮しました。 --mount on build機能を持つ可能性を楽しみにしていますが、今のところ、このソリューションは実際に私のパイプラインのブロックを解除します。

これは、私が問題＃17745に残したコメントであり、クローズされたと理解していましたが、重複とはマークされていませんでした。 後者の点については間違っていたようです。Bugzillaのように、何かを「RESOLVED DUPLICATE」として明示的にマークし、バグの上部の説明領域に表示するシステムに慣れていることを認めます。 私は気にしない読者です。 （それで、私の謝罪@graingert 、私は知る方法がほとんどなかったので、20ptフォントで私に怒鳴る必要はありません-それは過度でした。）

私の場合、これが役立つのはDebianシステムです。ボリュームとして/var/cache/aptをマウントするので、同じ.debファイルを何度も再ダウンロードする必要はありません。 （特にここオーストラリアでは、本当に「無制限」のインターネット割り当ては存在しません。存在したとしても、ダウンロードを待つのに無駄な時間があります。）

または、別のシナリオでは、ビルドを実行していますが、障害リストやコードカバレッジレポートなどのテストレポートも生成されます。これらは、イメージと一緒に出荷する必要はありませんが、手元に置いておくと便利なアーティファクトです。 これらは、CIサーバーがCIサーバーが取得してホストするためのイメージを構築するときに、ボリュームに書き込むことができます。

または今夜、Gentooベースのイメージを自分で作成しています。ホストから/usr/portageをマウントしたいと思います。 Dockerfileが、ボリュームをマウントせずに実行しているときに、「ねえ、 /usr/portage （コンテナ内）が空です。問題ありません」と気付くのは難しくありません。ボリュームをそのまま使用するため、新しいコピーを取得する時間を節約できます。

これらのスマートを追加することは、Bourneシェルスクリプトのifステートメントで簡単です…ボリュームをマウントするための基礎となるロジックが最初に存在する場合。 現在、Gentooイメージの場合、ビルドを実行するたびに/usr/portageをプルする必要があります（幸い、ミラーはLAN上にあります）。つまり、その1つのステップが完了するまで数分待つ必要があります。

これが価値のある提案である理由はたくさんあります。＃7115で提案されたネストされたビルドが上記の場合に役立つかどうかは疑わしいです。

@whitecolorには興味深いアプローチがありますが、そうする場合は、Dockerシステムの完全に外部にあるMakefileを使用してビルドを実行することもできます。

@sjlong​​land私はあなたに怒鳴っていませんでした、私は大きな「解決された重複」通知をポリフィルしていました

私はdockerとdocker-composeを使用して、インフラストラクチャ用のいくつかのコンテナーを構築しています。 コンテナーはマイクロサービスであり、ほとんどがnodeJSで記述されていますが、Mavenフレームワークを使用してJavaで記述されたマイクロサービスが1つあります。
Javaコンテナーを再構築するたびに、数十の依存関係がMavenからダウンロードされます。 これには数分かかります。 その後、コードは約15秒でビルドされます。

これは非常に醜く、CI戦略にかなり大きな影響を与えます。

このシナリオでは、ビルドの依存関係を持つボリュームが欠落しているか空であるかは実際には問題ではありません。その場合、依存関係がダウンロードされるためです。 再現性は影響を受けません。

依存関係を改ざんし、そこに厄介なコードを挿入する可能性があるため、セキュリティ上の懸念があることを理解しています。 「ビルドボリューム」でビルドされたイメージをdocker-hubまたはdocker-storeで公開しないようにすることで、簡単に回避できるIMHO。
これを別の言い方をすれば、Dockerの企業での使用と個人での使用の範囲を区別する必要があります。

@steppsはdocker-composeの代わりにhttps://pypi.python.org/pypi/shipwrightをチェックアウトします

私はしばらくの間このスレッドをフォローしていて、自分にとって良い解決策を探しています。 最小限の労力で柔軟な方法で最小限のコンテナーを構築するために、私は@edannenbergによるhttps://github.com/edannenberg/gentoo-bbが本当に好きです。

• ビルド時の依存関係を実行時の依存関係から分離します
• ビルドはコンテナで行われ、分離され、クリーンで、再現性があります
• イメージとビルドの順序の間の依存関係を処理します

これはGentooのPortageを使用して出現することに基づいているため、 @sjlong​​landはGentooベースの画像に適しています。 Distファイルとバイナリパッケージはキャッシュされるため、ダウンロードしたり再構築したりする必要がなく、再構築が高速になります。 ビルドプロセスを簡単にカスタマイズするためのフックがあります。 サードパーティソフトウェアのインストールは簡単です。たとえば、gitを使用してリポジトリのクローンを作成してからビルドし、ビルドのみを最終イメージに保持します。 Dockerfileをテンプレート化します。

簡単な例はfigletの場合です：-

build.conf：

IMAGE_PARENT="gentoobb/glibc"

Dockerfile.template：

FROM ${IMAGE_PARENT}
ADD rootfs.tar /
USER figlet
CMD ["gentoo-bb"]
ENTRYPOINT ["figlet"]

builld.sh

PACKAGES="app-misc/figlet"

configure_rootfs_build() {
        useradd figlet
}

私は@whitecolorのソリューションが好きです。それは、Dockerテクノロジーだけを使用し、次に単純なシェルスクリプトまたはその他の使用したいものを使用するだけです。 より完全なので、私はgentoo-bbを使用しています。 Shipwrightは、ブランチの処理など、開発者に焦点を当てた機能に適しています。 https://github.com/grammarly/rockerも興味深いようです。 みんなを共有してくれてありがとう。

ちょうど別の声が山に追加されました。 ビルド時にローカルボリュームをマウントできれば、非常に複雑な開発環境は非常に簡単になります。

回避策は、ビルド中にローカルファイルを公開するhttpサーバーを実行し、curl/wgetなどを使用してファイルをDockerビルドに取り込むことです。 しかし、私は本当にそのようなハックが不要であることを望みます。

別のユースケース..数十の異なるバージョンのプロプライエタリOSを構築するためのDockerイメージを構築したいと思います。 インストールメディアは>80GBなので、これをDockerビルド環境にコピーすることはできません。 バインドマウントの方がはるかに望ましいでしょう。

もう1つ：私のプロジェクトでは、コンテナ内のソースからビルドするために、リポジトリ内のDockerfilesを配布しています。 現在、コンテナ内の別のgitクローンをgithubからプルしています。 浅いクローンとすべてがありますが、それでも...

そのため、rhel7ビルドホストで[1]をテストしたところ、RedHatのdockerデーモンのビルドにはビルド用の-vオプションがあります。 私はCentOS/Fedoraでテストしていませんが、Fedora/CentOSでもおそらくテストされていると思います。 テストする価値があります。 また、RHELDeveloperのサブスクリプションは無料になりました[2]。

@fatherlinuxFedoraでは`dockerbuild-v'も利用できます。

@fatherlinuxCentOS7バージョンにはそれが含まれています。

+1これは公式のDockerに追加するのに本当に便利な機能だと思います。

centosとlinuxmint（現在は17.03.1-ceを実行しています）の両方で更新されましたが、ここで何かが足りませんか？ オプション-vが表示されません

ミントについて

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=18
DISTRIB_CODENAME=sarah
DISTRIB_DESCRIPTION="Linux Mint 18 Sarah"
$ docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Fri Mar 24 00:45:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

CentOS7で

# docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --build-arg list             Set build-time variables (default [])
      --cache-from stringSlice     Images to consider as cache sources
      --cgroup-parent string       Optional parent cgroup for the container
      --compress                   Compress the build context using gzip
      --cpu-period int             Limit the CPU CFS (Completely Fair Scheduler) period
      --cpu-quota int              Limit the CPU CFS (Completely Fair Scheduler) quota
  -c, --cpu-shares int             CPU shares (relative weight)
      --cpuset-cpus string         CPUs in which to allow execution (0-3, 0,1)
      --cpuset-mems string         MEMs in which to allow execution (0-3, 0,1)
      --disable-content-trust      Skip image verification (default true)
  -f, --file string                Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --force-rm                   Always remove intermediate containers
      --help                       Print usage
      --isolation string           Container isolation technology
      --label list                 Set metadata for an image (default [])
  -m, --memory string              Memory limit
      --memory-swap string         Swap limit equal to memory plus swap: '-1' to enable unlimited swap
      --network string             Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                   Do not use cache when building the image
      --pull                       Always attempt to pull a newer version of the image
  -q, --quiet                      Suppress the build output and print image ID on success
      --rm                         Remove intermediate containers after a successful build (default true)
      --security-opt stringSlice   Security options
      --shm-size string            Size of /dev/shm, default value is 64MB
  -t, --tag list                   Name and optionally a tag in the 'name:tag' format (default [])
      --ulimit ulimit              Ulimit options (default [])
# docker version
Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:05:44 2017
 OS/Arch:      linux/amd64
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core) 

@wilfriedroset CentOS 7では、非公式のDockerパッケージがオプションを提供します。 私はそれがEPELリポジトリの一部だと思います。

@nathanjacksonに感謝します。 公式リリースでこの機能のETAはありますか？

@wilfriedroset AFAIK、「ビルドの移植性」を維持するためにこの機能を公式のDockerに含めるべきではないと（数回）決定されたため、ETAはありません。 別名、DockerfileをDockerビルドサービスを含むどこでも実行できるようにします。

私の経験では、限られたビルドの移植性は顧客が本当に望んでいるものです。 彼らはビルド環境/ファームをセットアップし、ビルドがその環境で常に再構築できることを保証したいと考えています。 -vビルドオプションは、これを妨げるものではありません。

たとえば、NFSマウントを使用する場合は、すべてのビルドサーバーのfstabにそのマウントがあることを確認してください。そうすれば、ファーム内のどこでも問題なくビルドが完了します。

RHEL7.3の場合
`` ``
[ root @ rhel7〜 ]＃docker build --help

使用法：dockerbuild[オプション]パス| URL | -

Dockerfileからイメージを構築する

オプション：
--build-arg valueビルド時変数を設定します（デフォルト[]）
--cgroup-parentstringコンテナのオプションの親cgroup
--cpu-period int CPU CFS（Completely Fair Scheduler）期間を制限します
--cpu-quota int CPU CFS（Completely Fair Scheduler）クォータを制限します
-c、-cpu-shares int CPUシェア（相対的な重み）
--cpuset-実行を許可するcpus文字列CPU（0-3、0,1）
--cpuset-mems文字列実行を許可するMEM（0-3、0,1）
--disable-content-trustイメージ検証をスキップします（デフォルトはtrue）
-f、-file string Dockerfileの名前（デフォルトは「PATH / Dockerfile」）
--force-rm常に中間コンテナを削除します
--help印刷の使用法
--分離文字列コンテナ分離テクノロジ
--label value画像のメタデータを設定します（デフォルト[]）
-m、-memorystringメモリ制限
--memory-swap stringメモリにスワップを加えたものに等しいスワップ制限：無制限のスワップを有効にするには「-1」
--no-cacheイメージを構築するときにキャッシュを使用しません
--pull常に新しいバージョンのイメージをプルしようとします
-q、-quietビルド出力を抑制し、成功するとイメージIDを出力します
--rmビルドが成功した後、中間コンテナーを削除します（デフォルトはtrue）
--shm-size string / dev / shmのサイズ、デフォルト値は64MB
-t、-tagvalue名前およびオプションで' name：tag '形式のタグ（デフォルト[]）
--ulimit値Ulimitオプション（デフォルト[]）
-v、-volume valueビルド時のバインドマウントを設定します（デフォルト[]）
`` `

CI構築ノードプロジェクトの別のユースケースは、すべてのイメージを構築するときにCIのyarnキャッシュを共有することです。

+1：node_modulesを何度もインストールすることは、特にnodejsマイクロサービスにとっては本当にひどいことです
私はnfsでこの問題を解決しようとしていますが、「繰り返し可能」はこの機能を実装しない理由にはならないでしょう...

これは、＃31257と＃32063を統合することでさらに重要になるようです。

＃32507を見てください

@fatherlinuxは、Dockerfile内にCOPYコマンドを含めることができる場合に、ビルドの移植性がどのように機能するかを説明できますか？ （時間の複雑さの理由で）大きなファイルのコピー数を避けたいという問題があり、ファイルをコンテナーと共有するためのビルド時の読み取り専用オプションを探しています。

@arunmkhttps ://github.com/moby/moby/issues/32507を参照してください

@ arunmk @cpuguy83正確に。 アイデアは、ビルド時にデータをコンテナにコピーしたくないということです。 それはそれを非常に大きくすることができます。 ビルド時にデータを利用できるようにしたいだけです。 上記のように、Red Hatのバージョンのdockerデーモンで-vバインドマウントを実行できます。これにより、データを利用できるようになりますが、現在は読み取り専用です（先週私を燃やしました）。

したがって、今日必要な場合は、Fedora、CentOS、またはRHELをチェックして、ビルド時にデータの読み取り専用コピーをマウントできます...

また、ビルドファーム内での移植性が必要な場合は、NFSなどをお勧めします。

コピーする必要はなく、最終的なイメージに含めるだけの場合は、マルチステージビルドを使用してこれを処理できます。

不自然な例：

FROM fatImage AS build
COPY bigData /data
RUN some_stoff /data

FROM tinyImage
COPY --from=build /data/result

明確化してくれてありがとう@fatherlinux
@cpuguy83詳細をありがとう。 珍しいかもしれない私の問題にさらに詳細を追加させてください：私は3.3GBのファイルを生成するビルドシステムを持っています。 これは、Dockerコンテナー内に構築されたRPMに追加されます。 したがって、生成されるコピーは2つあります。1つはビルドシステムからDockerコンテナーに、もう1つはDockerコンテナー内からRPM内に作成されます。 今、私は2番目のコピーを避けることはできません。 最初のコピーを避けることを考えていましたが、多段階のビルドでもそれは不可能のようです。
大きなファイルを繰り返し使用すると、多段コピーの実行回数が「1」に減っていることは理解できます。 一度使って、「0」に減らしたいと思いました。 それが不可能だということを私は正しく理解していますか？

@arunmkクライアントからビルドインスタンスに何をコピーする必要があるかに関係なく。

@cpuguy83説明してくれてありがとう。 今のところオーバーヘッドを取る必要があるようです。 それは原子性を持っているということですか？

@fatherlinux

RHEL7で-vを使用して、ビルド中にディレクトリを読み取り専用でマウントしようとしましたが、次のエラーが発生します。

Dockerビルドではボリュームはサポートされていません。 バインドマウントのみを使用してください。

これは、Dockerからのものではなく、RHELからのdockerパッケージでのみ機能します。 パッチはアップストリームで受け入れられませんでした。

@fatherlinux

RHEL7で-vを使用して、ビルド中にディレクトリを読み取り専用でマウントしようとしましたが、次のエラーが発生します。

Dockerビルドではボリュームはサポートされていません。 バインドマウントのみを使用してください。

@fcntl

エラーが言ったようにバインドを使用する必要があります。おそらく$＃ /hostsomething:/containersomething -v /somethingを使用しました

@thebigbやおそらく他の人たち、私たちはDockerのビルド中にccacheを使用できるようにインフラストラクチャをセットアップしました。 役立つ場合はhttps://github.com/WebHare/ccache-memcached-serverで公開していますが、理想的にはこの問題を解決すると廃止される可能性があります。

追加しようとしていたのですが、これが本当に必要なユースケースはccacheです。 Dockerイメージのビルド中にccacheキャッシュをマウントできるようにしたいと思います。これは、イメージ自体に含まれている意味がありません。 @unilynx回避策を見ていきます-良いタイミングです！

別の声を使ってください。

私の使用例：現在、ロッカーのMOUNTコマンドを使用して、 /root/.cache ＃$ディレクトリと/var/cache/apkディレクトリを共有しています。

何らかの理由で、apkパッケージとpipパッケージへのネットワークアクセスが非常に（非常に）遅いです。 再構築すると、プロセスに非常に時間がかかります。 このビルド時のMOUNT機能を使用すると、作業がはるかに簡単になります。

@embray @roxmaは、 https： //github.com/moby/moby/issues/32507を参照して、ユースケースに対応できるかどうかを確認してください。 フィードバックを歓迎します

マルチステージビルドの導入により、Mavenのローカルキャッシュのボリュームマウントを指定する必要性が重要であることがわかりました。

@gim913これはあなたがどのコミュニティにも参加する方法ではありません。 貢献したい場合は、ここにリンクされている既存の提案を確認して、それらのいずれかがユースケースを解決するかどうかを確認してください。

@ gim913さまざまなディストリビューションへのDocker統合のこの段階では、環境の変更（つまり、Dockerを完全に削除する）は、「OS」を変更するよりもはるかに混乱を招くように思われます（別のLinuxディストリビューションからRedHatビルドに切り替えることを意味します。 -v？）

RedHatのバージョンのdockerを使用する方が簡単ではないでしょうか。 おそらく、ここの誰かが、ビルドで「-v」オプションを取得するための関連するパッチ/フォーク/コミットにあなたを向けることができます。

@unilynxここに行きます

wgetを使用してここに到達したいくつかの例を見ていました...私のユースケースは似ています...大きなtarballを解凍して実行したいだけです。 Dockerファイルをtarballで散らかしたり、ローカルWebサーバーからwgetを実行して時間を無駄にしたりしたくありません。 docker composeを使用して実行できるようにマウントすることは、ビルド時に行うのが妥当なことのようです。 よろしければ、プニートの変更をマージしてください:-)

私はPythonホイールをプリコンパイルし、それらをコピーして本当に必要のないレイヤーを作成せずにコンテナーにインストールしたい、または何らかの方法で押しつぶそうとする必要があります。 1日目と私はすでにrocker 😢😢😢を調べています

これは簡単に追加でき、非常に便利です（または、マウントコマンド。 rockerをもう一度参照してください）。 この機能または同様の不足している機能のスクリプトを作成するのに（コミュニティで）どのくらいの時間が費やされていますか？

@awbackerマルチスタッグビルドはこれをかなりうまく解決し、次のようなことができます

FROM something AS my_wheels
RUN compile_all_the_things

FROM something
COPY --from my_wheels /wherever
RUN do_stuff_with_wheels

最初の部分は、何かが変更された場合にのみ実行されます。 そのためのキャッシュは、他のビルド/ドッカーファイル間でも共有できます。
これにより、ビルド全体が自己完結型になります。

RUN --mountを許可する提案もあり、マウント仕様では、コピーする代わりにmy_wheelsビルドターゲットから物をマウントするように指示されます。

@kenyeeの場合と同様に、これはビルドコンテキストから何かをマウントする可能性があります。これは、17.07では、experimentalは必要に応じて段階的にのみ送信されます。

@cpuguy83これは実際には機能しません-少なくともGradleJavaビルドでは。 Gradle Jarファイルが事前にキャッシュされているベースDockerイメージがありますが、ソースのGradleビルドが、すべての依存関係をキャッシュにダウンロードするトリガーになります。

@ cpuguy83マルチステージでは、コピーされたホイールを結果の画像から削除することはできません。@ awbackerが話しているのはそれです。 したがって、/ whereeverフォルダーのコンテンツはキャッシュされ、画像サイズが大きくなります。

@BryanHuntビルドプロセスの一部は、depsをダウンロードすることですか？ 確かに、Gradleは、実際にビルドすることなく、これらをキャッシュする方法を提供する必要がありますか？

@ cpuguy83はい、depsはビルドの一部としてダウンロードされます。 基本的にMavenと同じです。 参考： https ：//github.com/gradle/gradle/issues/1049

ビルドマウントのPRはどこかにありましたか？

@graingertここに

このための👍。 Lunar Wayでは、CIサーバーからビルドとテストの依存関係を削除するために、単一のDockerビルドで完全な「ビルド->テスト->本番イメージのビルド」プロセスを実行したいと考えています。 マルチステージビルドではこれを行うことができますが、ビルドプロセスの中間コンテナーからテスト結果を取得することはできません。 したがって、今は2つのステップで実行する必要があります。テストイメージをビルドするための個別のDockerfileを使用して実行し、テストが成功した場合にのみ、prodイメージのビルドステップに進みます。

Dockerビルドの-vオプションを使用すると、テスト結果をCIサーバーからマウントされたフォルダーに保存し、現在の2ステッププロセスの必要性をなくすことができます。

@tbflwデフォルトでは、Dockerビルドは、ビルドが失敗した後、中間コンテナーを削除しません。 したがって、テストが失敗した場合は、それらからテスト結果を取得できます。

どうぞ、私たちも本当に、本当にこの機能が必要です！ アドホックパッチを使用してロッカーやフォークドッカーなどの他のツールに頼るのは、「移植性を構築する」という福音主義の概念を打ち破るよりもはるかに醜いです。

@BryanHunt @stepps @ yngndrw他の人も@awhitford
ビルドの依存関係をキャッシュする1つの方法は、ドキュメントのマルチステージgoビルドの例やpythononbuildDockerfileのようにビルドを機能させることです。
これは、Mavenで機能するように見える私が作成した例です。 ここにコピーします。

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

FROM openjdk
COPY --from=0 /usr/src/app/target/*.jar ./

コードベースの残りの部分をコピーする前に依存関係をダウンロードするように設定する必要があります。また、アーティファクトが保存される場所がVOLUMEにないことを確認してください。

@sixcornersそれはGradleでは機能しません

@BryanHuntこのDockerfileまたはこのアプローチはgradleでは機能しませんか？ cpuguy83は、実際にビルドを実行せずに依存関係をダウンロードする方法があるかどうかを尋ねました。 依存関係の解決タスクにリンクしました。 build.gradleファイルを追加して、そのタスクを実行できませんか？

@sixcornersモジュールが多数ある場合は、ビルドファイルおよびプロパティファイルとともにディレクトリ構造を複製する必要があります。 私はそれができると思いますが、これは非常にエラーが発生しやすいと思います。

@sixcornersによるマルチステージは興味深いトリックであり、さまざまなパッケージマネージャー（npm、composerなど）で使用されているのを見てきました。

ただし、ステージ0の画像で依存関係のリストがCOPY pom.xmlに変更されると、レイヤーが破棄され、キャッシュ全体が失われるという問題があります。 つまり、開発者がpom内の何か（コメント、1kBytesの依存関係）を変更するたびに、キャッシュ全体を再度ダウンロードする必要があります。

CIマシンの場合、イメージを構築し、依存関係が変化し続けるテストを実行します。つまり、（プロキシまたはアップストリームから）再ダウンロードする必要があり、再構築が非常に遅くなる何千ものパッケージです。 ボリュームとしてマウントされたローカルファイルベースのキャッシュは、はるかに高速です。

これは、開発者がイメージのビルドを繰り返す場合、特に接続が遅い場合にも問題になります。 ローカルのNexusインスタンスとそれにhttp_proxyを設定することはできますが、それ以外の副作用（Nexusを介したhttpリクエストのチャネリングなど）があります。

マルチステージは良い回避策ですが、理想的ではありません。

私たちが試みようとしている解決策は、共有ライブラリを構築し、依存関係キャッシュを保持することによってイメージを構築することです。 このイメージは、アプリのビルドイメージになります。 理想的ではありませんが、試してみる価値はあると思います。

ただし、依存関係のリストが変更されるたびに、ステージ0のイメージのCOPY pom.xmlによってレイヤーが破棄され、キャッシュ全体が失われるという問題があります。 つまり、開発者がpom内の何か（コメント、1kBytesの依存関係）を変更するたびに、キャッシュ全体を再度ダウンロードする必要があります。

@hasharは、 COPY --from機能がビルドステージに限定されないことに注意してください。 Dockerfileリファレンスから：

オプションで、 COPYは、送信されるビルドコンテキストの代わりに使用される前のビルドステージ（ FROM .. AS <name>で作成）にソースの場所を設定するために使用できるフラグ--from=<name|index> $を受け入れます。ユーザーによる。 このフラグは、 FROM命令で開始された以前のすべてのビルドステージに割り当てられた数値インデックスも受け入れます。 _指定された名前のビルドステージが見つからない場合は、代わりに同じ名前のイメージが使用されます。 _

これにより、依存関係のイメージを_ビルド_し、タグを付け、それを使用して依存関係をコピーすることができます。 例えば：

FROM maven
WORKDIR /usr/src/app
# /root/.m2 is a volume :(
ENV MAVEN_OPTS=-Dmaven.repo.local=../m2repo/
COPY pom.xml .
# v2.8 doesn't work :(
RUN mvn -B -e -C -T 1C org.apache.maven.plugins:maven-dependency-plugin:3.0.2:go-offline
COPY . .
RUN mvn -B -e -o -T 1C verify

docker build -t dependencies:1.0.0 .

また、依存関係にdependencies:1.0.0イメージを使用して指定します。

FROM openjdk
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar ./

または（テストする非常に基本的な例）。

$ mkdir example && cd example
$ touch dep-one.jar dep-two.jar dep-three.jar

$ docker build -t dependencies:1.0.0 . -f -<<'EOF'
FROM scratch
COPY . /usr/src/app/target/
EOF

$ docker build -t myimage -<<'EOF'
FROM busybox
RUN mkdir /foo
COPY --from=dependencies:1.0.0 /usr/src/app/target/*.jar /foo/
RUN ls -la /foo/
EOF

ビルドの出力には、次のように表示されます。

Step 4/4 : RUN ls -la /foo/
 ---> Running in 012a8dbef91d
total 8
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 .
drwxr-xr-x    1 root     root          4096 Oct  7 13:27 ..
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-one.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-three.jar
-rw-r--r--    1 root     root             0 Oct  7 13:26 dep-two.jar
 ---> 71fc7f4b8802

誰かがこのユースケースについてまだ言及しているかどうかはわかりませんが（ページを簡単に検索しました）、SSH認証ソケットをビルドコンテナにマウントすると、プライベートgitリポジトリを介してデプロイされた依存関係をはるかに簡単に利用できるようになります。 非最終ビルド段階でのキーのコピーなどに関して、Dockerfile内の定型文の必要性は少なくなります。

buildkitはgitをネイティブでサポートしています
https://github.com/moby/buildkit

解決する。
bashスクリプトを作成します（〜/ bin / docker-composeなど）：

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

そして、socatを使用するDockerfileでは：

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

次に、 docker-compose buildを実行します

別のユースケースを山に投げる。 Docker for Windowsを使用して、組み込みLinuxシステムを1つのコンテナーにビルドするためのファイルシステムを生成します。これを、ビルドステップ中に他のコンテナーと共有したいと思います。 私はこのコンテナーを操作して構成を変更したり、再構築したりします。そのため、Dockerfileでビルドを実行し、マルチステージビルドを使用することは、増分ビルドを失うため、あまり適していません。 クリーンビルドを実行するには約1.5時間かかるため、以前のビルドアーティファクトをキャッシュしたいと思います。 Windowsがシンボリックリンクを処理する方法が原因で、ホストにマウントされたボリュームにビルドできないため、名前付きボリュームを使用します。 理想的には、他のイメージのビルドステップでこれらの名前付きボリュームを共有したいと思います。 現時点では、ビルド出力のtar（約4GB）を作成してから、Dockerコピーを実行して、後続のビルドでWindowsホストで使用できるようにする必要があります。

Pythonの場合、 pip install packageすると、Pythonとその依存関係がキャッシュフォルダーにダウンロードされ、サイトパッケージにインストールされます。
良い習慣として、現在のレイヤーにゴミ/キャッシュを保存しないようにpip --no-cache-dir install packageを使用します。 ただし、ベストプラクティスとして、キャッシュフォルダーをビルドコンテキストから外すことが望まれます。 したがって、ビルド時間-vが役立ちます。
上記の一部のユーザーはCOPY . /somewhere/in/container/を使用しますが、ユーザーのアプリやファイルには問題ありませんが、キャッシュには問題ありません。 COPYはそれ自体としてもう1つのレイヤーを作成し、後のレイヤーのキャッシュを削除しても役に立たないためです。 他の悪い副作用は、COPYを使用するときにキャッシュが変更された場合、コンテキストが変更され、後続のレイヤーが無効になり、再構築が強制されることです。

@wtayyeb要件ファイルが変更されたときにのみpip install ...を実行するDockerfileがある場合、要件はアプリケーションのビルド時ほど頻繁には変更されないため、ビルド時間-vはそれほど重要ではないようです。

@wtayyebマルチステージDockerfileを使用して、キャッシュとリーンイメージの両方を使用できます。 つまり、インストーラーイメージを使用してPythonをディレクトリにインストールし、最終的なイメージにCOPY --fromを使用して、インストールアーティファクトやpip自体を含まない必要なpythonファイルのみを転送します。

@manishtomar 、ありがとう、はい、いいえ！ クリーンな場合、すべての依存関係が再度ダウンロードされ、ビルドされてホイールに変換されてキャッシュされてから、宛先環境にインストールされます。 したがって、要件をそこに入れると、それは1回限りの仕事になります。 ただし、1つの小さな依存関係が更新された場合、すべての依存関係を再ダウンロード、再構築、再ホイール、および再キャッシュして使用できるようにする必要があります。
CIを使用してライブラリとアプリケーションを複数のジョブのマトリックスで構築およびテストする場合、CIサーバー内の同時ジョブの数で上記の作業を乗算すると、SSDを使用した場合でもiowaitが3秒以上に上昇し、平均負荷が15を超えます。 （これらの数値は、2つの同時ビルドと最大20の依存関係を持つアプリで実際のものです）pipキャッシュは、準備ができたパッケージの再ダウンロード、再ビルド、および再ホイールを回避して、正しい方法でそれを行っていると思います。 bind -vがないと、時間とサーバーリソースが失われます。

@ibukanov 、ありがとう。 アプリパッケージをビルドして後で使用するためにマルチステージDockerfileを使用しています。 Dockerfileが1つだけで、それを数回ビルドしたい場合は役立ちますが、Dockerfileが複数あり、それぞれがpythonバージョン（現時点では2.7,3.6）に対してビルドされ、さらにいくつかのc-extensionsが必要な場合はどうなりますか？選択したベースイメージ用にビルドしますか？ 上記の段落はどうですか？

@thaJeztahあなたの提案は素晴らしく、時間を節約できますが、ビルドキャッシュの場合、他のイメージから何もコピーする必要はありません。
コピーせずに別の画像にアクセスできないのはなぜですか？

@thedrow私の例は、現在そこにある機能を使用したものです。 RUN --mountの提案（https://github.com/moby/moby/issues/32507）をご覧ください。これは、ユースケースにより適している可能性があります。

上記のスレッドを読むと、Dockerビルドプロセスの基本的な機能のギャップを修正するために、多くの人が応急修理を見つけようとしているのがわかります。 ホストマウントとイメージマウントを必ずしも混同しない限り、移植性の根拠から説得力のある議論は見当たりません。率直に言って、疑わしく怠惰な議論です。

私はgentooコンテナのユーザーでもあり、 https：//github.com/moby/moby/issues/3156からリダイレクトされました。これは、この欠落している機能の完全に有効なユースケースです。

私が本当に望んでいるのは、ビルド時に別のイメージのコンテンツをマウントして、イメージが肥大化しないようにする機能です。

@kbaegisは、 https：//github.com/moby/moby/issues/32507で提案されている機能と完全に一致しているように聞こえます

もちろん。 それは、3年ではなく1年のバックログで未実装のP3にすぎません。

https://github.com/projectatomic/buildahは、この基本的な機能のために、実際にはここでDockerビルドをかなり早く上回っているようです。 それが起こったら、パイプラインを切り替えるつもりだと思います。

@kbaegisこのディスカッションに追加するためにここに来たのは何ですか？ 別の提案と_正確に_一致するユースケースについて説明しました。

私が本当に望んでいるのは、ビルド時に別のイメージのコンテンツをマウントして、イメージが肥大化しないようにする機能です。

それはオープンソースであり、物事は魔法のように存在することはありません。

ディスカッションに何を追加したいですか？

簡潔に言えば、私はこのツールセットから移行しています。 私はそこに一人ではないと確信しているので、それは開発チームにとって貴重な情報であると確信しています。

このユースケース（およびこの機能を提供する信頼できる回避策）をサポートするための氷河の速度と低い優先度により、私は他のツールに追い込まれ、機能が不足しているためにこのビルドパイプラインを放棄しています。

追加する（再ハッシュ、確かに）ユースケースがあります。 ＃32507はこれにより適しているかもしれません。

いくつかのバイオインフォマティクスパイプライン用のDockerイメージを作成しています。 いくつかのツールでは、コンパイル/インストールの前にいくつかのデータベースが存在している必要があります（質問しないでください。私のコードではありません）。 これらのデータベースは、最低でも30GBの重量があります。

実行時に、私は確かにそれらのデータベースが-vボリュームにマウントされることを意図しています。 残念ながら、ビルドプロセス中にこれらを「ベイク」せずにこれを行うことはできず、かなり卑劣なサイズのイメージになります。

@draeathはhttps://github.com/grammarly/rockerを見てください。 それはすでに素敵なMOUNT命令をサポートしています。

@draeathも、Buildahをチェックしてください。プログラミングツールのように設定されているため、デフォルトでマウントをサポートしています。 Dockerfileを使用したマウントもサポートします。

https://github.com/projectatomic/buildah

@fatherlinuxと@ligの両方に感謝します-これは私の仕事を成し遂げるのに役立ちます。 それでも、プロジェクトの外に出てそれを行う必要はないと思います。それでも、これと＃32507が実装されるのを楽しみにしています;）

私はいくつかのグーグルを介してここに来て、同じ機能、つまり「dockerrun」時間ではなく「dockerbuild」時間のボリュームを要求しました。

CPUを含む組み込みシステムがあります。 メーカーは、システムイメージを作成し、そのイメージをCPUに転送するためのツールを提供しています。 このツールは私にとってサードパーティであり、変更することはできません。 メーカーも私の要求でそれを変更する可能性は低いです。

最初のパス「ファームウェアイメージのビルド」を実行するDockerイメージをビルドしてから、ファームウェアイメージを新しいオフラインPCBにプッシュするだけのコンテナーを生成できるようにしたいと思います。 Dockerfileは次のようになります。
- - - - - [ ここで切れ ] - - - - -
ビルダーとしてのベースイメージから
コピーsrcsrc
build-srcを実行します

フラッシャーとしてのベースイメージから
COPY --from = builder build-artifacts
cpu-build-and-flash--build-onlyを実行します
- - - - - [ ここで切れ ] - - - - -
残念ながら、cpu-build-and-flashステップでは、ファームウェアイメージをデバイスにプッシュしない場合でも、USBバスを介してターゲットデバイスにアクセスする必要があります。 したがって、「dockerrun」コマンドから「-v/ dev / usb / bus：/ dev / usb / bus」を取得し、代わりにビルドに含める必要があります。

これが現在不可能であることは明らかです。

私が進めている回避策は、コンテナをイメージに「docker container commit」することで、点滅するイメージを手動で作成することです。 ビルド時にUSBバスをマウントしたいだけです。

興味のある方のために更新してください：私は最近、buildahを使用してパイプ全体を正常に再構築しました。 現在、2つのビルドパイプラインを並行して実行しており、oci / buildahパイプラインはより小さなイメージを生成しています（具体的には、別のマウントでマスクして/ usr / portageを削除します）。

そして最後に、この機能はここにあります： https ://github.com/docker/docker-py/issues/1498

しかし、ビルドキャッシュ用のRWボリュームが必要です

2018年4月28日土曜日、17：29КоренбергМарк、 notifications @github.comは次のように書いています。

そして最後に、この機能はここにあります：docker / docker-py＃1498
https://github.com/docker/docker-py/issues/1498

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/14080#issuecomment-385188262 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAZQTJodLCCzyDdPFtNiIUZ_z85YvLWbks5ttJjagaJpZM4FIdOc
。

また、CIパイプラインの多段階ビルドプロセス中に単体テスト結果ファイルをエクスポートできるように、この機能（書き込み機能付き）も見たいと思います。 ビルドの移植性の精神を維持するために、-vスイッチが提供されていない場合、ファイルはその段階でテストイメージ内に内部的に書き込まれるだけです。

理想的な目標は、1回ビルドし、1回テストし、テストが失敗した場合でも（特にイベントが発生した場合でも）、結果ファイルをホストシステムに渡して、ビルドを停止することです。

はい、お願いします。 一日中。

完全に関連しているわけではありませんが、デプロイメントインフラストラクチャの一部を移行しており、ビルド後にイメージからファイルをコピーする方法が必要でした。 以下はトリックをしました：

docker build -t x .
ID=$(docker create x)
docker cp $ID:/package.deb .
docker rm $ID

多段dockerファイルが導入されたときにすでに追加されているはずです。 最終的には、特にCIビルドパイプラインの場合、マルチステージDockerファイルのステージとしてユニットテストの実行を開始するとすぐに、誰もがこの問題に直面することになります。 また、ユニットテストレポートをVSTSに公開する必要があるというこの問題にも直面しています。 すでに回避策を適用している@hoffaは言及しています。 しかし、結局のところ、それは回避策であり、物事を複雑にします。

ビルドキャッシュ用のビルド時ボリュームが必要な人のために、別の問題を作成する必要がありますか？

@ajbouhはい、おそらくhttps://github.com/moby/buildkit/issuesにあります

https://github.com/moby/moby/issues/32507#issuecomment-391685221を参照してください

2018年5月23日水曜日、19：22須田明弘[email protected]は次のように書いています。

@ajbouh https://github.com/ajbouhはい、おそらく
https://github.com/moby/buildkit/issues

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/14080#issuecomment-391566368 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcnSqNoVc4j34ElECy53gIfPecQFKfks5t1hlkgaJpZM4FIdOc
。

ビルド時にボリュームを追加することはできませんが、ホストを追加することはできます。そのため、 --add-host yum-mirror:$MIRROR_IPのようなものを使用してすべてのDockerイメージをビルドします。これは、ビルドイメージがラッパーを介して検出するyumミラーを提供します。ヤム。 プロジェクトが1日に何度も依存関係を変更し、オフラインまたは接続不良の場合に便利です（プロジェクトの一部には、多くの部門の更新とクリーンアップが含まれます）。

この問題を解決することに対するDockerの抵抗は腹立たしいと思います。

ビルドキットの実験的なサポートが最近統合され、 RUN --mount=<opts> <command>のオプションが付属しています。

@ cpuguy83へのリンク注： https ：//github.com/moby/buildkit/pull/442

@glensc @ cpuguy83この統合された機能のリリースはいつ期待できますか？

+1

RUN --mountはボリュームをサポートしていないため、 https：//github.com/avsm/docker-ssh-agent-forwardのようなものはビルド時に不可能なままですが、これに対する解決策は何ですか？

@ peter-edge https://github.com/moby/buildkit/pull/655

docker build --secretがついにDocker18.09で利用可能になりましたhttps://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

この問題を解決できますか？

--secretは、私が知る限り、キャッシングのユースケースには使用できません。

@AkihiroSuda RUN --mountは一般的に、この問題の解決策としてふさわしいもののように見えます。

はい、 RUN --mount=type=cache （キャッシュボリューム用）と--mount=type=secretとdocker build --secret （シークレットボリューム用）がほぼ問題をカバーしていると思います。

@AkihiroSudaだから、元の問題を解決する実用的な例を見るのは良いでしょう

@AkihiroSuda記事（https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066）からビルド中にマウントを使用する2つのユースケースを見ました：シークレットとSSH

[ひみつ]

docker build --secret id=mysite.key,src=path/to/mysite.key .
RUN --mount=type=secret,id=mysite.key,required <command-to-run>

[SSH]

RUN --mount=type=ssh git clone [email protected]:myorg/myproject.git myproject

この記事でもこの号でも使用方法が説明されていない他の2つのユースケース（私が覚えている）があります：

1） [キャッシュ] RUN --mount=type=cache
2）一般的なボリューム（たとえば、SSL証明書をマウントするため、またはビルド中に使用する必要があるが、生成されたイメージには含まれない大きなボリュームの場合など...）

ユースケースがwebpackを実行する前にyarnワークスペースをマウントすると

あなたはこれのすべてをすることができます。

RUN --mount=type=cache,from=<some image>,source=<path in from image>,target=<target>

from=<some image>をfrom=<some build stage>に置き換えることもできます

不自然な例を次に示します。

# syntax=docker/dockerfile:1.0.0-experimental
FROM busybox as hello
RUN  echo hello > /hello.txt

FROM scratch
RUN --mount=type=cache,from=busybox,source=/bin,target=/bin --mount=type=cache,from=hello,source=/hello.txt,target=/tmp/hello.txt echo /tmp/hello.txt

これに関するいくつかのドキュメントは次のとおりです： https ：//github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md

@AkihiroSudaに同意します。これですべてのケースを処理できるはずですが、そうでない場合はお知らせください。

@AkihiroSuda @ cpuguy83 ：残念ながら、現在の実装（docker 18.09のbuildkit）にはプライベートレジストリに問題があります。 現在のところ、プライベートレジストリを介して画像を取得する必要がある場合、これらの新機能は使用できません。 https://github.com/moby/moby/issues/38303で私のテストを参照してください。

これはJenkinsアーティファクトにも使用されると思います。たとえば、Dockerイメージを作成して内部で何かをコンパイルする場合、junitpytest出力などのアーティファクトを取得したいと思います。

これは非常に便利です。 RUN --mount=type=cache /user/.cache/pip pip install --experimentalを追加する必要はありません（パッケージインデックスの帯域幅を大幅に節約するため）。

buildah bud （ buildah build-using-dockerfile ）には--volume / -vオプションがあります：
https://github.com/containers/buildah/blob/master/docs/buildah-bud.md

buildahは、Dockerソケットなしで非ルートとしてビルドを実行できます。

ネットワークからのパッケージのダウンロードはより再現性が高いので？

クライアントに「--experimental」を追加する必要はなく、「DOCKER_BUILDKIT=1」のみを追加します。

はい、コンテキストがすべてDockerfileにあるという点で、ネットワークビルドの再現性が高くなっています。 ビルドを機能させるためにホストからコンテキストをマウントする必要がある場合、それは悪い経験です。

ビルドにイメージをマウントすることもできることに注意してください。

はい、コンテキストがすべてDockerfileにあるという点で、ネットワークビルドの再現性が高くなっています。

確かに、DockerfileにRUN apt-get updateがあると、イメージのビルドに必要なすべての手順が確実に実行されます。 ただし、追加のコンテキストがサードパーティからダウンロードされるため、再現できません。 マウントとの唯一の違いは、すべての外部コンテキストが実際にDockerfileで定義されていることです。

ビルドを機能させるためにホストからコンテキストをマウントする必要がある場合、それは悪い経験です。

Dockerビルドでの私の悪い経験は、再現性がないことです。ホストからキャッシュをマウントすることで間違いなくメリットが得られ、いくつかのユースケースがスピードアップすることは間違いありません。

最終的に私がやることは、多段階のビルドを行うことです。 ネットワークからコンテキストを取得する1つのイメージ。これにより、リモートコンテキストのスナップショットとして機能します。 次に、任意のバージョンでタグ付けすると、日付は正常に機能します。 例えば：

RUN apt-get update

docker build -t aptupdate-20190417

そして実際の画像では：

FROM aptupdate-20190417
FROM somebaseimage

COPY --from=aptupdate-20190417 /var/apt /var/apt

他のリモートコンテキストで繰り返すと、多かれ少なかれ再現可能なものがあります。

つまり、ネットワークアクセスに依存するDockerfileはおそらく再現可能ではありません。 マウントを使用すると再現性が失われる可能性がありますが、一部のユースケースを再現可能にするのに役立ちます。 しかし、Dockerfileには、実際にイメージをビルドするために必要なすべての手順が必要であると思いますが、私の経験では、ほとんどの場合、イメージをビルドするための独自のツールを作成します。

つまり、 RUN --mount=type=cacheはまさにこれに当てはまります。
または、レジストリの別のイメージからマウントして、フェッチすることもできます。

aptコマンドは、フェッチしたいものを固定することで（比較的）再現可能にすることができます。
しかし、本当にすべてのビットを制御したいのなら、なぜビルドでaptを使用しているのですか？ これをビルドホストに保存することは再現性がなく、ホスト間で簡単に壊れます。
それをレジストリに保持することは、ネットワーク障害の可能性を除いて悪いことではありません...もちろんそれは公正な批判です。

buildahとredhatのフォークの-vは、広すぎるため、ここでは明示的に拒否されました...役に立たないことは言うまでもありませんが、ホスト間で簡単に壊れてしまい、 docker buildの設計に反します。 。
一方、RHがそれを追加した理由（より正確には、彼らがそれに取り組むことを決めた理由）は、RHELクレデンシャルをビルド環境にマウントできるようにするためでした。

はい、コンテキストがすべてDockerfileにあるという点で、ネットワークビルドの再現性が高くなっています。 ビルドを機能させるためにホストからコンテキストをマウントする必要がある場合、それは悪い経験です。

私は激しく反対します。 ネットワークがダウンしているか、危険にさらされている可能性があります。 この場合、ローカルキャッシュは、インターネットがダウンしているときにビルド全体が失敗するのを防ぎます。

docker-compose.ymlでvolumes:を1回指定できます。 しかし、代わりにDOCKER_BUILDKIT=1を実行し、アップストリームで管理されているDockerfilesにRUN --mount=type=cacheを追加する必要がありますか？ なんで？

CIビルドでは、ボリュームマウント（ルートなしで非ルートとして実行されるビルド）にキャッシュできる、数十から数千のパッケージ（1日に数十または数百回）の不要な再ダウンロードが大量に発生することを意味します。ホスト上で独自のボリュームを持つ特権コンテナーを実行する機能）。

パッケージインデックスは、多くの場合、寄付によって惜しみなくサポートされています。 リモートリソースはビルドコンポーネントのより再現性の高いキャッシュであるという誤った信念に基づいて、再現性の誤った考えを満たすために帯域幅にそのお金を浪費することは、ひどく苛立たしいことです。

docker-compose.ymlが機能するように、 --volumeを追加してください。

docker-compose.ymlが機能するように、-volumeを追加してください。

「docker-compose」を正しく機能させるのは逆です。
docker-消費者にこのプロジェクトを作成します。その逆ではありません。

docker-composeはdockerソケットと相互作用します。 docker-compose YAMLは、コンテナーオプションを格納するための統合された方法です（これは、k8sポッド定義（podmanがある程度サポートします）に変換できます）。 DOCKER_BUILDKIT=1を再現可能な方法で指定するにはどうすればよいですか？ docker-compose.ymlで再現可能な方法でbuild_volumes:を指定できます。

1日にn回実行されるCIビルドスクリプトで、たとえばdocker-compose build （たとえば、ansibleを使用）またはpacker （buildahとpodmanの代わりに）を呼び出してイメージをビルドする場合、いくつかの目的があります：

• リソースの節約/リソースを無駄にしない
  
  
  
  • OSと言語ごとのパッケージを常に再ダウンロードしないでください。
  
  
  • 組織の帯域幅リソースをパッケージインデックスに保存します。
  
  
• 可用性を保証する
  
  
  
  • オフラインで動作する必要があります
  
  
  • 必要な数のコンポーネントに依存する必要があります
  
  
• ビルドの整合性を保証する
  
  
  
  • 同じパラメータで同じ画像を再現できる
  
  
  • 分散を分離/再現可能なビルドを提供
  
  
  • パッケージインデックスのようなリモートリソースは制御しません。
  
  
  • ネットワークパスを制御しません
    
    
    
    
    
    • DNSSECとDNSoverHTTPSが正しく実装されていない可能性があります
    
    
    
  
  
  • 私たちは禁止され、かなりレート制限される可能性があります
  
  
  • 署名されたリソースを検証するには、署名されたチェックサムを使用する必要があります
    
    
    
    
    
    • キーを使用してアクセスおよび署名するための承認は、どこかに委任されます
    
    
    
    • ENVironment変数は、コンテナ名前空間内のすべてのプロセスで使用できます
    
    
    
    • ビルド時のボリュームマウントは、ビルド時にのみ必要なキーを共有する1つの方法です（イメージキャッシュにリークすることはありません）。
    
    
    
  
  
• ビルドを高速に保つ
  
  
  
  • 頻繁な操作をキャッシュしてメモします。
  
  
  • キャッシュは、障害点、潜在的な差異、および再現性のないリスクを追加します。
    
    
    
    
    
    • HTTP（S！）プロキシキャッシュ
    
    
    
    • ネットワーク上のアプリケーション層キャッシュ
    
    
    
    • ローカルファイルシステムキャッシュ
    
    
    
  
  
  • 外部依存関係のない、ダムでフラッシュ可能なキャッシュを実装する
    
    
    
    
    
    • ローカルファイルシステムキャッシュ
    
    
    
  
  

キャッシュボリュームをフラッシュする必要がある場合は、キャッシュボリュームをフラッシュできます。

0.現状

RUN pip install app && rm -rf /root/.cache

• 今日可能
• O（n_builds）：帯域幅の使用
• オフラインでは機能しません：ネットワークによって異なります
• 再構築が遅い

A.コピー

COPY . /app/src/app
COPY .cache/pip /app/.cache/pip
RUN pip install /app/src/app \
    && rm -rf /app/.cache/pip

• 今日可能
• 〜O（1）パッケージインデックス帯域幅
• O（n）：ビルドごとに（* ONBUILD ）
  
  
  
  • キャッシュをコピーします
  
  
  • パッケージのアーカイブを解除します
  
  
  • キャッシュを削除します
  
  
• オフラインで動作します
• 再構築が遅い

B.アップストリームからすべてのDockerfileをフォークして変更し、 RUN --mount=type=cacheを追加して、環境変数を設定します

# Fork by copying to modify every pip install line
RUN --mount=type=cache /app/.cache/pip pip install /app/src/pip

$ DOCKER_BUILDKIT=1 docker build . [...]

• 今日可能
• これはすでに再現性の欠如をもたらします。出力に変動をもたらすextra-Dockerfile、extra-docker-compose.ymlパラメーターがあります：名前付きビルドイメージ。
• ドキュメント： --mount=type=cacheキャッシュをフラッシュする方法（？）
• 〜O（1）パッケージインデックス帯域幅
• オフラインで動作します
• 高速再構築

C.ビルド時にマウントされるボリュームを指定します

C.1。 buildah

$ buildah bud -v .cache/pip:/app/.cache.pip

• 今日可能
• また、再現性がありません
• ドキュメント：キャッシュをフラッシュする方法
• 〜O（1）パッケージインデックス帯域幅
• オフラインで動作します
• 高速再構築

C.2。 docker（この問題が求めているもの）

C.2.1 DockerCLI

$ docker build -v .cache/pip:/app/.cache.pip

• 今日は不可能
• また、再現性がありません
• ドキュメント：キャッシュをフラッシュする方法
• 〜O（1）パッケージインデックス帯域幅
• オフラインで動作します
• 高速再構築

C.2.2dockercompose

services:
  app:
    image: imgname:latest
    build: .
    build_volumes:  # "build_volumes" ?
    - ./.cache/pip:/app/.cache/pip

$ docker-compose build

• 今日は不可能
• また、再現性がありません
• ドキュメント：キャッシュをフラッシュする方法
• docker-composeスキーマのリビジョンが必要になります
• 〜O（1）パッケージインデックス帯域幅
• オフラインで動作します
• 高速再構築

..。

• コピー|| REMOTE_FETCH || 読んだ（）
  
  
  
  • これらのうち、最も再現性の高いものはどれですか？
  
  

：point_up：ただのリマインダーです。 チェックサムを確認することで、ダウンロードしたファイルを固定できます。 pipなどの一部のパッケージマネージャーもこれをサポートしています。

@westurner詳細な説明をありがとう。

以下はケースBに似ていると思いますが、キャッシュをクリアすると、ケースC2のようになります（あなたが求めているものだと思います）。

_docker-compose.yml：_

services:
  my-cache:
    build: ./my-cache
    image: local/my-cache

  my-image:
    build: ./my-image

_my-cache / Dockerfile：_

FROM python

RUN pip install app

_my-image / Dockerfile：_

FROM my-repo/my-image

RUN --mount=target=/export,type=bind,from=local/my-cache

RUN pip install /app/src/app

（https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache）

キャッシュイメージは次の方法で作成できます。

docker-compose build my-cache

コマンドRUN --mount=target=/export,type=bind,from=local/my-cacheは画像にバインドする必要があります。 キャッシュを更新する場合は、キャッシュイメージを削除して再構築できます。

これでもRUN --mount...のキャッシュを使用する場合は、バージョンで.envファイルを使用でき、バージョンをimage: local/my-cache:$MY_VERSIONとfrom=local/my-cache:$MY_VERSIONに含めます（ビルド引数として含まれています）。

my-cacheサービスをメインサービスと同じファイルに含めたくない場合は、別のdocker-composeファイルに含めることができます。

それでもDOCKER_BUILDKIT=1を使用する必要があり（Bの場合と同様ですが、これは将来のバージョンでは必要ないと思います）、再現性はありません（ただし、C2の場合もそうではありません）。

再現性がない場合、どのようなペナルティが発生しますか？ キャッシュイメージlocal/my-cacheをDocker Hub （異なるリポジトリ名）またはプライベートレジストリに配置し、ビルドごとにバージョンを使用すると（異なるキャッシュが作成されます）、同じバージョンは常に同じになりますキャッシュ、それはそれを再現可能にしませんか？ docker-composeファイルにサービスを含めてbuildコマンドを呼び出す必要はありません。 （Docker Hubにはネットワークからアクセスする必要がありますが、他のイメージでも同じだと思います。一度ダウンロードすると、新しいキャッシュを使用して新しいバージョンを生成しない限り、Docker Hubは不要になります）

免責事項：私は上記のコードをテストしていません。

@Yajo pipのチェックサムサポートは、元々「peep」で実装され、その後pipにマージされました。 既知の適切なハッシュを、pip要件ファイルエントリのURLフラグメントとして追加できます。 （今年はPyPAプロジェクトのセキュリティ改善のための資金があります。PyPIでのTUF（Update Framework、Docker Notaryと同様）のサポートは今年後半に計画されています。）DockerイメージでpipとPyPI（キーと信頼を使用）を正しくブートストラップする今年後半に話題になる可能性があります。
（編集;少しOTですが、関係者向けです） https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/

@lucasbasquerottoご協力いただきありがとうございます。 これは、ビルド時に--volumeを指定するよりもはるかに複雑です。 つまり、次のものが必要なようです。

• docker buildシェル環境でDOCKER_BUILDKIT=1を指定する
• RUN --mount=type=cacheを使用してアップストリームのDockerfileRUN命令を変更する
• 別のイメージへの読み取り/書き込みアクセス？ 可変性！ または、キャッシュはおそらく古いバージョンで凍結されていると言われていますか？

ホストからファイルをコピーできる場合、または他の場所に保存されていないビルド時パラメーターを指定できる場合、ビルド時にボリュームをマウントする際の再現性が低下することがわかりません。

コピー|| REMOTE_FETCH || 読んだ（）

• これらのうち、最も再現性の高いものはどれですか？

@westurner

Dockerビルドシェル環境でDOCKER_BUILDKIT=1を指定する

他の投稿で見たように、 docker-composeを使用する場合、およびコンテナーから実行する場合は、次のようになります。

$ sudo curl -L --fail https://github.com/docker/compose/releases/download/1.24.0/run.sh -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose

次に、ダウンロードしたファイルを/usr/local/bin/docker-composeで編集して、その環境変数を使用できます。 から変更する：

exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" $IMAGE "$@"

に

DOCKER_BUILDKIT=1
exec docker run --rm $DOCKER_RUN_OPTIONS $DOCKER_ADDR $COMPOSE_OPTIONS $VOLUMES -w "$(pwd)" --env DOCKER_BUILDKIT=$DOCKER_BUILDKIT $IMAGE "$@"

これは非常に簡単な変更であり、コマンドを実行する人には透過的です。

_（コンテナとして実行しない場合、上記は適用されません）_

RUN--cacheとargsを使用してアップストリームのDockerfileRUN命令を変更する

私が公開した場合、それはRUN --mount=type=bind...になりますが、いずれにせよ、 Dockerfileを変更しなければならないことも悪いIMOです。 -vオプションは、実際にははるかに優れており、より透過的です。

別のイメージへの読み取り/書き込みアクセス？ 可変性！ または、キャッシュはおそらく古いバージョンで凍結されていると言われていますか？

イメージをバインドすると、おそらくコンテナ（または複製されたファイルシステムを使用した名前）が作成され、ビルド中にそこで行われた変更によって元のイメージが変更されることはありません（意味がありません）。 したがって、ビルドでmy-repo/my-cache:my-versionという名前のキャッシュイメージを使用してビルドする場合、次のビルドではまったく同じになります（模倣可能性）。 より最新のキャッシュを使用する場合は、 my-repo/my-cache:my-new-versionのように、新しいバージョンで新しいイメージを作成して使用できます。

これらのうち、最も再現性の高いものはどれですか？

再現性は、別のマシンで実行してもまったく同じものだと思います。 この意味で、イメージを（安全で信頼性の高い）Dockerレジストリにプッシュし、そのイメージを変更しない場合は、再現可能であると考えます（インターネット接続に懸念がある場合は、プライベートレジストリを使用して、 VPNまたはそのようなもの（自分でプライベートレジストリを使用したことはありません））。

COPYコマンドがマシンのキャッシュをコピーしている場合、別のマシンでpip install （またはapt-getなど）を実行すると、別のときに保証できるため、再現可能とは見なされません。キャッシュの内容は同じになりますか？ 多分これはあなたにとって心配かもしれません。 そうでないかもしれない。

一方、「所有」している信頼できる場所（S3バケットなど）に所有しているファイルがある場合は、それらのファイルをマシンにダウンロードし、COPYコマンドを使用してそれらのファイルをコピーすると、別のファイルから複製できます。同じ結果のマシン（ファイルが変更されておらず、他のマシンが前のマシンと同じであると想定）。 ですから、これは再現可能だと思います。 それは、それらのファイルがどこから来るのか、そしてあなたがそれらをどれだけ制御できるかによって異なります。

正直なところ、すべての場合に100％再現可能であるとは考えていませんが（結局のところ、ハードウェアに障害が発生する可能性があります）、信頼性が高いほど優れています。 再現可能なプロセスについて言及するときは、主にその内容と結果が同じであることを指します。これには、内容が時間の経過とともに変化しないと仮定して、ネットワークからダウンロードしたものも含まれます（ネットワークの可能性は考慮していません）。この場合の失敗）。

コンテナ内でもgo mod download信頼できないものにするDockerネットワークのバグがあるので（少なくとも私たちのサイズのアプリケーションでは）、毎回実行してGOPATH/pkg/modをすべてダウンロードし直すだけです。無駄なだけでなく、壊れています。 🤷‍♀

--volumeを使用できれば、不要なファイルのコピーを大幅に回避できます。

@kevincantu RUN --mount = type=cacheはユースケースをカバーする必要があります

これには、Dockerビルド内からモジュールを少なくとも1回正常にダウンロードする必要があります。この特定のケースでは、これはまだ見たことがありません。

https://github.com/moby/moby/issues/14080#issuecomment -484314314 by @westurnerはかなり良い概要ですが、 buildkitを機能させることができませんでした：

$ sudo docker -v
Docker version 19.03.1, build 74b1e89

$ sudo DOCKER_BUILDKIT=1 docker build .
Ä+Ü Building 0.1s (2/2) FINISHED                                                                                                                
 => ÄinternalÜ load build definition from Dockerfile                                                                                       0.0s
 => => transferring dockerfile: 407B                                                                                                       0.0s
 => ÄinternalÜ load .dockerignore                                                                                                          0.0s
 => => transferring context: 2B                                                                                                            0.0s
failed to create LLB definition: Dockerfile parse error line 8: Unknown flag: mount

私のDockerfileは# syntax=docker/dockerfile:experimentalで始まります。

実際にdocker-composeで使いたいです。 DockerfileでENV DOCKER_BUILDKIT 1を試し、 docker-compose.ymlからARG DOCKER_BUILDKIT $を経由して渡しましたが、すべて同じです。

$ sudo docker-compose up --build
Building web
ERROR: Dockerfile parse error line 10: Unknown flag: mount

@lucasbasquerotto https://github.com/moby/moby/issues/14080#issuecomment -484639378で提案したものは、インストールされているバージョンのdocker-composeにどのように変換されますか？

最後に、これが私のユースケースをカバーするかどうかさえわかりません。おそらく、私がこれを追求すべきかどうかを教えてくれる人もいるかもしれません。 依存関係を更新するときに新しい依存関係のみをダウンロードする必要があるように、ビルド間で存続するローカル開発用のビルド時キャッシュを使用したいと思います。 したがって、 RUN --mount=type=cache,target=/depsをDockerfileに追加し、依存関係マネージャーのキャッシュを/depsに設定します。

docker composeについては、 https：//github.com/docker/compose/pull/6865を参照してください。これは、composeの次のリリース候補になります。

別のユースケースがあります...binfmtが構成されたx86_64ホスト上にarm用のコンテナーを構築したいと思います。 これには、 / usr/binにアーキテクチャ固有の静的qemucpuエミュレーターが必要です。

私の現在の解決策は、 qemu-arm-staticを次のようなファイルとしてコンテナに追加することです。

FROM arm32v7/alpine:3.10
COPY qemu-arm-static /usr/bin/qemu-arm-static
RUN apk update && apk upgrade
RUN apk add alpine-sdk cmake
...

より簡単な解決策は、次のようにコンテナ内で必要な場合にのみファイルをマウントすることです。
docker build -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static -t test:arm32v7 .
これはDockerの実行には非常に適していますが、コンテナーを構築するためのこの機能がありません。

x86_64ホストでarmコンテナーをビルドする別の解決策はありますか、または少なくともこの場合、ビルド時にボリュームを許可できますか？

@jneuhauserの最新のカーネルでは、これらのバイナリを静的にロードできるため、毎回設定する必要はありません。 これは、たとえば、起動後にlinuxkit/binfmtイメージを特権モードで1回実行することで実現できます。

最新のカーネルでは、これらのバイナリを静的にロードできるため、毎回設定する必要はありません。

@alehaaただし、コンテナー内に静的qemuエミュレーターバイナリはまだ必要ではありませんか？

@cybe Fフラグが使用されている場合、これはもう必要ありません（これは、 linuxkit/binfmtパッケージが行うことです）。 これについての詳細はここで見つけることができます。

誰かがビルドキットを試すための実用的なセットアップを提供できますか？ Ubuntuで動作させることができません。 私の設定は次のとおりです。

cat /etc/docker/daemon.json

{
  "experimental": true
}

Dockerfile

# syntax=docker/dockerfile:experimental

FROM ruby:2.6.3

RUN --mount=type=cache,target=/bundle/vendor

sudo docker -v

Dockerバージョン19.03.1、ビルド74b1e89

DOCKER_BUILDKIT=1 sudo docker build .

デーモンからのエラー応答：Dockerfile解析エラー行12：不明なフラグ：マウント

sudoは、 sudo -Eで指示するか、sudo内で変数を宣言しない限り、env変数を伝送しません。

この機能についていくつかの単語を書き、キャッシュする方法を示すいくつかの最小限の例を作成しました

• $＃$ dockerを使用した$ bundler依存関係
• $＃ docker-composeを使用した$ NPM依存関係

編集：以下を参照

@ cpuguy83ありがとう！

@thisismydesign興奮を台無しにして申し訳ありませんが、 node_modulesをキャッシュすることはできません。最終的な画像には表示されないため、アプリが壊れています。

@glenscくそー、その通りです。ビルド時のキャッシュを最終イメージの一部にする方法はありますか？

正直なところ、これは次のように宣伝されている機能について考慮されると思いました

ビルドコンテナがコンパイラとパッケージマネージャのディレクトリをキャッシュできるようにします。

代わりに〜/.npmをマップできるはずです… https： //docs.npmjs.com/files/folders.html#cache

@thisismydesign

ただし、Dockerfileにビルドするか、レジストリのどこかに格納されているリテラルイメージを使用して、 COPY --fromを使用することにより、別のイメージをキャッシュとして使用できます。

FROM example/my_node_modules:latest AS node_modules

FROM nodejs AS build
COPY --from=/node_modules node_modules 
...

これは、これをさまざまな目的に使用できる単なる例です。

うーん、これを持ってきてここに参加するのは嫌いです（こんにちは友達も）

しかし、これにはユースケースがあります。

ここに参加できる良い場所や、ダイジェストを取得するために参加できる電話やリストはありますか？

また、これにいくつかのリソースを投入する誰かが必要な場合は、1クリスノバと小さなチームがあり、おそらくこれを見るように説得することができます。

TLDRこれをコーディングできますか？ これについて話せる人はいますか？

_TLDR_これをコーディングできますか？ これについて話せる人はいますか？

Dockerについて話すことはできませんが、ビルドにボリュームマウントを追加することにオープンではないという印象があります（おそらく、この問題を解決する必要があります）

buildtime -vの多くのユースケースは、buildkitでカバーされるようになりました。 それは少なくとも私にとってはそれを解決しました。

次にビルドキットをチェックします-誰かが興味を持った場合に仕事を終わらせるハッキーなbashもあります。

ありがとう@unilynx

この問題を解決するために@unilynxに+1すると、buildkitはビルド時間のボリュームの問題も解決しました。

誰かがいくつかのリンクと例を落とした場合、私たちは友人に光沢のある閉じるボタンを押すように説得することができると思います。

（私もそれらから恩恵を受けるでしょう）

buildkitを使用したビルド時間ボリュームが最終イメージに存在しないため、キャッシュのユースケースは私や他の多くの人にとって解決されていません。

そのため、 buildの時点で使用されていた一時ボリュームからすべてのビルドアーティファクトを引き出し、上記のこのbashを使用して、以前のキャッシュでイメージを再構築することができました。

オーバーレイファイルシステムが小さなデルタのみを取得するように、イメージをそれ自体の上に再構築することができました。

ビルド時にボリュームを他のイメージに再利用することもできました。

他の人々はこれを行うことができませんか？

（キャッシュ）マウントは「実験的」フロントエンドにあります。 https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.mdで説明されています（会議に向かうところですが、より拡張された例をリンクできます）

@thaJeztahLMKに感謝します。

https://github.com/moby/moby/issues/14080#issuecomment -547662701

@thisismydesign興奮を台無しにして申し訳ありませんが、 node_modulesをキャッシュすることはできません。最終的な画像には表示されないため、アプリが壊れています。

@thaJeztah上記の問題が解決したとは思いません。 ビルド時にnpm installなどをキャッシュできるいくつかの例を見てみたいと思います。これにより、結果のイメージでキャッシュされたインストールを使用できるようになります。

@ kris-nova私はこの問題を解決しませんでしたが、bashスクリプトを使用するつもりはありません。 おそらく新しい問題が必要ですが、これはAFAIKがまだ解決されていないかなり一般的なユースケースです。

@thaJeztahキャッシュマウントを使用したいくつかの例を示します。これは、最終的なイメージにマウントが含まれず、ビルド時のキャッシュの多くのユースケースをカバーしていないことを示しています。

• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-build-cache
• https://github.com/c-hive/basics/tree/558fbd91d45e56e574ebb05fb8645268d5b01974/docker-compose-build-cache

npmの場合：npmキャッシュディレクトリにキャッシュマウントを使用しませんか（https://docs.npmjs.com/cli-commands/cache.html、通常は~/.npm ）？

@ankonそれはうまくいくかもしれません、ありがとう、私はそれを試してみます。 よくわからないもう1つのユースケースは、BundlerとRubyです。

したがって、Bundlerの場合（まだテストされていません）、少なくとも$BUNDLE_PATHのビルドボリュームを使用して、ビルド中にネットワークの依存関係を取り除くことができると思います。

bundle install
bundle package
bundle install --standalone --local

これは基本的に、キャッシュされたバンドルインストールディレクトリがあることを意味し、そこからgemを./vendor/cacheにパッケージ化し、 ./bundleに再インストールします。 ただし、これはgemのインストールとビルドにかかる時間を節約するものではなく、実際にはビルドステップが長くなる可能性があります。

キャッシュされたデータをイメージに保存する場合は、キャッシュからイメージにコピーします。

おかげで、しかし、それはまだより多くの回避策です。

• 追加のコピーを行う必要があります
• ビルド環境と実行環境の間で異なるディレクトリが必要だと思います（ビルド中にボリュームをマウントしたディレクトリは使用できませんよね？）ので、追加のセットアップが必要です

同じボリュームを最終的なイメージにマウントするためのネイティブオプションを用意するだけでどれだけの労力がかかるかはわかりませんが、使用が簡単になると確信しています。 これらは、このキャッシュを使用する方法が私には明らかではなかったスクリプト言語からの2つの例にすぎません。 これはさまざまな状況でも発生することは間違いありません。

@thisismydesign必要なのは、ビルドと実行の間でキャッシュを共有できるようにすることです。

buildkitはLinuxのみのソリューションですが、Windowsで何をしますか？

@thisismydesignなぜ（キャッシュ）マウントが最終イメージにとどまると期待するのかわかりません。 私はこれを期待していませんし、ダウンロードキャッシュマウントを使用しているという理由だけで、イメージに最大1GBを含めたくありません。

buildkitはLinuxのみのソリューションですが、Windowsで何をしますか？

Windowsでビルドキットを使用できます。

https://docs.docker.com/develop/develop-images/build_enhancements/

実行する前に環境変数を設定するよりも、Docker forWindowsUIを使用してデーモン設定を設定する方が簡単な場合があります。

リンクの上部にある@nigelgbanks ：

Only supported for building Linux containers

申し訳ありませんが、WindowsでLinuxコンテナを構築していると思います。

@thisismydesign必要なのは、ビルドと実行の間でキャッシュを共有できるようにすることです。

そうすれば、キャッシングに関する私のユースケースは解決するでしょう。

これを簡単にすると、CIでパッケージを何百万回も再ダウンロードする必要がなくなります。
年間ビルド。

CIサービスは実験的なビルドキット機能をサポートしていますか？

2020年6月13日土曜日午後2時8分[email protected]は次のように書いています。

@thisismydesignhttps ://github.com/thisismydesignそれは何のようです
ビルドと実行の間でキャッシュを共有できるようにしたいですか？

そうすれば、キャッシングに関する私のユースケースは解決するでしょう。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/moby/moby/issues/14080#issuecomment-643657987 、または
登録を解除する
https://github.com/notifications/unsubscribe-auth/AAAMNS6IEQDCO5F3LNHJK5TRWO6AJANCNFSM4BJB2OOA
。

CIサービスは実験的なビルドキット機能をサポートしていますか？

彼らはそれを明示的にサポートする必要がありますか？ buildkitでgitlab-ciを使用していますが、正常に機能します。 結局のところ、これは「dockerbuild」を呼び出すための別の方法にすぎません。

もちろん、独自のランナーをgitlabに持ち込まない限り、ビルド中にキャッシュヒットが発生する可能性は低くなります。

マルチステージビルドの名前付きステージからのコピーは別のソリューションです

FROM golang:1.7.3 AS builder
COPY --from=builder

しかし、コンテナイメージの局所性は、CIジョブスケジューリングではまだほとんど解決されていない問題です。

ランナーは、（多額の資金が不足している）パッケージリポジトリへの不要なリクエストを最小限に抑えるために、より粘着性があり、共通のファイルシステムで（中間の）イメージを共有する必要があります。

buildkitを試しましたが、ワークフローがわずかに改善されるだけで、「実際の」ボリュームまたはホストへのバインドマウントによって100％支援されます。

私はdocker buildを使用して古いglibcバージョンをクロスコンパイルしています。これは、新しいビルドコンテナーの一部であり、これらのglibcをビルドしてリンクすることができます。

これで、繰り返されるglibcソースのダウンロードがバインドマウント（ buildkitから）によって解決され、アーカイブは読み取り専用になり、問題はありません。 しかし、コンテナーがエラーで爆破されるため、ビルドが失敗した後、分析のためにビルドディレクトリにアクセスする方法がありません。 （アクセスするために再起動すると、ビルドが再起動されるため、役に立ちません）。

また、ビルドディレクトリを削除するためだけに、古いコンテナから新しいコンテナをビルドするようなフープを飛び越えなければならない理由がわかりません。ビルドディレクトリがそもそもマウントだったとしたら、とても簡単。 （ビルド後にmake installを実行するだけで、ビルドディレクトリやダウンロードされたソースのないクリーンなコンテナーができます）。

ですから、これは非常に有効な機能のリクエストであり、私たちの生活をずっと楽にしてくれると今でも信じています。 機能が悪用されたり、使用された場合に他の機能が破損したりする可能性があるからといって、それを実装することを絶対に避けなければならないという意味ではありません。 より強力なツールの追加の使用法と考えてください。

しかし、ビルドが失敗した後、分析のためにビルドディレクトリにアクセスする方法がありません

ビルドキットの機能リクエストのように聞こえます。 これは間違いなく既知の欠品です。

「ビルドディレクトリ」をフェッチするためのターゲットを持つことで、今日これを行うことができます。 実行に失敗した後でも、すべてがキャッシュされている必要があり、データを取得するための最後のステップが必要です。
ただし、これは少し回避策であることを理解してください。

また、ビルドディレクトリを削除するためだけに、古いコンテナから新しいコンテナをビルドするようなフープを飛び越えなければならない理由がわかりません。

ここであなたが望んでいる/期待していることをもっと説明できますか？

ここであなたが望んでいる/期待していることをもっと説明できますか？

この場合、1つの石で2羽の鳥を殺したいだけです。

• ホストから中間結果にアクセスする簡単な方法があります（ここでは「ビルドディレクトリ分析」）
• このストレージスペースが新しく構築されたイメージを汚染していないことを確認してください

これと、ビルドコンテナ（および「コンテナビルド」）がビルドを可能な限り簡単にする必要がある他のすべてのケースでは、 -v機能を提供するだけで、はるかにエレガントに解決できるので、私はこの機能を提供するための抵抗を理解するのは難しい。 buildkitが明らかに提供する「キャッシュ対応」機能とは別に、私はそれを正確にこの機能を実現するための複雑で面倒な方法としてしか見ることができません。 （そして、キャッシュが主な目標である多くの場合、それは-vによっても解決されますが、実行されている限り、マウントされたボリュームを特定のコンテナーにロックする必要がありますが、キャッシュにはbuildkitにも同じ制限があります。）

ここであなたが望んでいる/期待していることをもっと説明できますか？

私は多段階のビルドプロセスを使用しています。ビルド環境自体がコンテナ化されており、最終的にはアプリケーションとランタイム環境のみを含むイメージになります（ビルドツールは含まれません）。

私が欲しいのは、ビルドが成功した場合と失敗した場合の両方で、ビルド出力イメージに渡すことなく、単体テストとコードカバレッジの結果ファイルをホストシステムに出力するための暫定的なDockerビルドコンテナの方法です。抽出用（前のステップで単体テストに合格しなかった場合、ビルドプロセス全体が短絡するため、その状況では出力イメージがありません。その場合、単体テストの結果が最も必要になります） 。 ホストボリュームをDockerビルドプロセスにマウントできるかどうかを判断すると、内部テストコマンドで出力をマウントされたフォルダーに送信できます。

@mcattle
確かに、私が必要とする（機能の1つ）にも非常に似ています。
数日前にbuildahに移動して以来、必要なすべての機能などを手に入れました。 ビルドコンテナのデバッグは、終了したコンテナに柔軟にアクセスしてホストにリンクする可能性がなければ、まったく不可能でした。 今、私は幸せなキャンピングカーです。 （「競合他社」とのパーティーをクラッシュさせて申し訳ありません。違反があった場合はこのコメントを削除しますが、このスレッドで提示されたユースケースの非常に効果的な解決策であり、言及する必要があると思いました） 。

別のツールがあなたのニーズにより適していると言っても違和感はありません。

何かがあなたのために働くなら、それは素晴らしいです。

Dockerのv1ビルダーとbuildkitビルダーの両方の欠点は、このコンテキストではかなりよく理解されており、クライアントからのバインドマウントに頼る必要なしに、これらに対処する方法を検討しています。
[email protected]は次のように書いています：
「@mcattle
確かに、私が必要とする（機能の1つ）にも非常に似ています。
数日前にbuildahに移動して以来、必要なすべての機能などを入手しました。 ビルドコンテナのデバッグは、終了したコンテナに柔軟にアクセスしてホストにリンクする可能性がなければ、まったく不可能でした。 今、私は幸せなキャンピングカーです。 （「競合他社」とのパーティーをクラッシュさせて申し訳ありません。違反があった場合はこのコメントを削除しますが、このスレッドで提示されたユースケースの非常に効果的な解決策であり、言及する必要があると思いました） 。」

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

クライアントからのマウントをバインドするために頼る必要はありません。

ここでは、ビルド時の-vオプションが、ビルド時のネットワークリソースに依存する以上に、再現性に頼ったり、再現性を犠牲にしたりしない理由を説明します。

https://github.com/moby/moby/issues/14080#issuecomment -484314314：

コピー|| REMOTE_FETCH || 読んだ（）

• これらのうち、最も再現性の高いものはどれですか？

ビルド時間-v （およびcgroupsv2）についてもbuildahを使用します。

@mcattle私は同じ要件を持っていました。 ラベル付けで解決しました。

ビルド時間-v （およびcgroupsv2）についてもbuildahを使用します。

「-v」がサポートされているため、ビルドサーバーでUbuntu（dockerのみ）からFedora（dockerをpodman / buildahに置き換えた）への切り替えを真剣に検討しています。

ところで。 Podmanはルートレスモードもサポートしており、これまでのところ、Dockerと完全に互換性があるように見えます（Dockerデーモンのようにrootとして実行する代わりにrootlessモードを使用することによる--user / USERの影響とイメージキャッシングの違いを除く）。

PS。 ルートレス操作にはcgroupsv2が必要ですが、そのサポートはdockerよりもコンテナーランタイムに関するものです。 RunCの代わりにCRunを使用する場合（Fedoraのように）、cgroupsv2がサポートされます。 RunCはGitでv2とrootlessをサポートしていますが、数か月前にFedora（31）でテストしたときに問題が発生しました。

編集：UbuntuのGroovyにはpodman / buildah / etcがありますが、最新の20.04 LTSにはありませんが、Debianからインポートされたものは不安定だと思います。 少なくともまだ、LTSにバックポートされていません。 2018年からFedoraになっていると思います。

@ eero-tおそらくあなたはあなたのユースケースを説明することができます、そしてBuildKitが現在提供しているオプションに欠けているものはそれらのために扱われていません。