Moby: 除外されたファイルでのコピーはできません

https://docs.docker.com/reference/builder/#dockerignore-fileを参照してください
プロジェクトのルートにある.dockerignoreファイルにエントリを追加できます。

.dockerignoreはこの問題を解決しません。 私が書いたように、「他の部分は別のコピーの対象となります」。

それで、他のコピーに基づいて条件付きでコピーしたいですか？

コンテキストには、多くのディレクトリA1 ... A10とディレクトリBが含まれています。A1... A10には1つの宛先があり、Bには別の宛先があります。

COPY A1 /some/where/A1/
COPY A2 /some/where/A2/
...
COPY A10 /some/where/A10/
COPY B some/where/else/B/

そして、これは厄介です。

それのどの部分が厄介ですか？ それらをすべて個別にリストしますか？

COPY A* /some/where/
COPY B /some/where/else/

これは機能しますか？

A1..A10、Bという名前は偽物でした。 さらに、 COPY A* ...は、ディレクトリの_contents_をまとめます。

私が認める選択肢はいくつかありますが、どれも厄介だと思います。 私は最初の投稿で3つ言及しました。 4番目のオプションは、A1..A10が新しいディレクトリAに移動されるように、ソースコードを永続的に再配置することです。追加のネストレベルは必要ないため、これが必要ないことを期待していました。現在のツールでは、その時、私のドッキングされたプロジェクトを特別な場合。

（BTW、＃6094（以下のシンボリックリンク）がこの場合に役立ちます。しかし、明らかに、これもオプションではありません。）

@bronger COPYがcpとまったく同じように動作した場合、それはあなたのユースケースを解決しますか？

100％理解できるかわかりません。
たぶん@duglinは一見することができます。

@bronger @ cpuguy83が正しい質問をしたと思いますが、「cp」を使用している場合、これをどのように解決しますか？ 私は「cp」のある種の除外オプションを調べて気づかなかったので、「dockerbuild」の外でこれをどのように解決するかわかりません。

cpの振る舞いで、私は言うことによって状況を改善することができました

COPY ["A1", ... "A10", "/some/where/"]

「A11」ディレクトリを追加した場合、その行を考える必要があるため、これはまだ軽度のメンテナンスの問題です。 しかし、それは許容できるでしょう。

さらに、すべてをコピーして不要な部分を削除しても、コピー自体以外のパフォーマンスへの影響はほとんどないため、cpは除外する必要はありません。 dockerのCOPYを使用すると、Bが変更されるたびにキャッシュが誤って無効になり、画像が大きくなることを意味します。

@brongerあなたができること：

COPY a b c d /some/where

あなたが提案していたように。

COPY ... RUN rm ...を実行する場合、はい、追加のレイヤーがありますが、それでもキャッシュを使用できるはずです。 それが原因でキャッシュミスが発生した場合は、お知らせください。そうすべきではないと思います。

しかし

COPY a b c d /some/where/

ディレクトリ/ some / where / {a、b、c、d}を作成する代わりに、ディレクトリabcdの内容を一緒にコピーします。 これは、srcディレクトリにスラッシュが追加されたrsyncのように機能します。 したがって、_four_命令

COPY a /some/where/a/
COPY b /some/where/b/
COPY c /some/where/c/
COPY d /some/where/d/

必要です。

キャッシュに関しては...私が言うなら

COPY . /some/where/
RUN rm -Rf /some/where/e

eが変更された場合、キャッシュは使用されませんが、eは操作に効果的に含まれていません。

@brongerうん、悲しいことにあなたは正しい。 --exclude zzzタイプのフラグを追加できると思いますが、 https： //github.com/docker/docker/blob/master/ROADMAP.md#22 -dockerfile-syntaxによると、多くのフラグを取得できない可能性があります。今トラクション。

けっこうだ。 次に、当面はCOPY + rmを使用して、FixMeコメントを追加します。 お時間をいただきありがとうございます！

ちょうど：+1：この問題。 COPYがrsyncの末尾のスラッシュセマンティクスを反映していないことを定期的に後悔しています。 これは、1つのステートメントで複数のディレクトリをコピーできないことを意味し、レイヤーの急増につながります。

1つを除いて多くのディレクトリをコピーしたい場合がよくあります（異なるレイヤー無効化効果を持たせたいので、後でコピーします）。そのため、 --excludeも役立ちます。

また、 man rsyncから：

       A trailing slash on the source changes this behavior to avoid  creating
       an  additional  directory level at the destination.  You can think of a
       trailing / on a source as meaning "copy the contents of this directory"
       as  opposed  to  "copy  the  directory  by name", but in both cases the
       attributes of the containing directory are transferred to the  contain‐
       ing  directory on the destination.  In other words, each of the follow‐
       ing commands copies the files in the same way, including their  setting
       of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

たくさんのワイルドなDockerfileを壊さずに、今は変更できないと思います。

具体的な例として、次のようなディレクトリがあるとします。

/vendor
/part1
/part2
/part3
/...
/partN

私は次のようなものが欲しいです：

COPY /vendor /docker/vendor
RUN /vendor/build
COPY /part1 /part2 ... /partN /docker/ # copy directories part1-N to /docker/part{1..N}/
RUN /docker/build1-N.sh

そのため、part1-Nは/vendorの構築を無効にしません。 （/ vendorはpart1-Nと比較してほとんど更新されないため）。

私は以前、part1-Nを独自のディレクトリに配置することでこれを回避したので、次のようにします。

/vendor
/src/part1-N

しかし、私はプロジェクトでこの問題に遭遇したので、簡単に再配置することはできません。

@prallerの良い例ですが、まったく同じ問題に直面しています。 主な問題は、Goのfilepath.Matchでは、正規表現と比較して創造性があまり高くないことです（つまり、アンチパターンがありません）。

私はちょうどこれのためにやや頭の悪い回避策を思いついた。 COPYはディレクトリを除外できませんが、ADDはtgzを展開できます。

これは、追加のビルドステップの1つです。
tar --exclude = '。/ deferred_copy' -czfall_but_deferred.tgz。
Dockerビルド..。

次に、Dockerfileで：
ADD ./all_but_deferred.tgz / application_dir /
..めったに変更されないレイヤーの内容..
追加 。 / application_dir /
..頻繁に変化するレイヤーの内容

これにより、包含/除外しようとする無駄なレイヤーの塊なしで、包含/除外/何でもするためのtarの完全な構文が得られます。

@ jason-kane共有してくれてありがとう、これはいいトリックです。 小さなポイントが1つありますz （gzip）フラグをtarに追加できないようです。これにより、sha256チェックサム値が変更され、Dockerキャッシュが無効になります。 そうでなければ、このアプローチは私にとって素晴らしい働きをします。

この問題の+1は、多くのglobライブラリがサポートしているのと同じ方法でサポートできると思います。

node_modules以外のすべてをコピーする提案があります

COPY . /app -node_modules/

私も同じ問題に遭遇します。JavaWebアプリが約900MBの場合、それは私にとってちょっと苦痛ですが、そのほぼ80％はめったに変更されません。
これは私のアプリケーションの初期の状態であり、フォルダ構造はある程度安定しているので、キャッシュを使用できるように6〜7 COPYレイヤーを追加してもかまいませんが、ファイルやディレクトリが増えると、長期的には確実に問題になります。追加されます

👍

docker cpでも同じ問題が発生しますが、1つを除くすべてのファイルをフォルダーからコピーしたい

ここでまったく同じ問題。 gitリポジトリをコピーして.gitディレクトリを除外したい。

@oaxlinには、.dockerignoreファイルを使用できます。

@antoinecoそれでうまくいくと思いますか？ 試してからしばらく経ちましたが、少なくともその時点では、 .dockerignoreはdocker cpでは機能しなかったと確信しています。

@ kkozmic-絶対に確認してください:)しかし、あなたが言及したdocker cp CLIサブコマンドは、この問題の範囲であるDockerfileにあるCOPYステートメントとは異なります。

docker cpは、実際にはDockerfileやとは何の関係もありません。 dockerignoreですが、一方で、イメージの構築には使用されません。

これも本当に欲しいです-ビルドをスピードアップするために、ビルドの前の部分にあるフォルダーをコピーして、キャッシュが役立つでしょう...

ユースケースが何であるかはわかりませんが、COPYが問題を解決する前に、除外するファイルに触れるだけではありませんか？

RUN touch /app/node_modules
COPY . /app
RUN rm /app/node_modules

AFAIK COPYはファイルを上書きしないので、これでうまくいくと思います。

おっと、気にしないでください、 COPYは実際にファイルを上書きしているように見えます。 npmがインストールしてCOPY . /usr/src/appを実行するhttps://nodejs.org/en/docs/guides/nodejs-docker-webapp/に少し戸惑っています。 node_modulesはdockerが無視されると想定していると思いますか？ 一方、 COPY_NO_OVERWRITE （より適切な名前が必要）コマンドを使用することは、コピー中にファイルを無視する1つの方法です（無視したいもののために空のファイル/ディレクトリを作成する必要があります）。

FWIW、これはとても醜いです。

私は別のハックソリューションを見つけました：

プロジェクト構造の例：
アプリ/
config /
脚本/
スペック/
静的/
..。

私たちが欲しい：

1. 静的コピー/
2. 他のファイルをコピーする
3. アプリをコピー/

ハックソリューション：
ADD ./static /home/app
ADD ["./[^s^a]*", "./s[^t]*", "/home/app/"]
ADD ./app /home/app

2番目のADDは、「。/st 」と「./a」を除くすべてをコピーすることと同等です。
改善のためのアイデアはありますか？

コメントのステータスはどれですか？

👍

👍

👍

👍

.gitignoreと同じ方法で.dockerignoreファイルを作成するのはどうですか？

@mirestrepoこの問題の最初の2つのフォローアップを参照してください。

現在、これはC＃/ dotnet開発用のメガパフォーマンスです。

私が欲しいもの：

• まず、すべての外部dllをDockerイメージにコピーします（My * .dllを除くすべて）
• 次に、すべてのdllをコピーします（My。*。dllで始まり​​ます）。

を除いてすべてをコピーすることはできないので、これは（簡単に）不可能のようです。

したがって、dllが二重にコピーされてDockerファイルのサイズが大きくなるか、すべてが1つのレイヤーにコピーされます。
外部dllはキャッシュされるのではなく毎回コピーされるため、後者はメガナーフになります。

@adresdvilasolutoinに感謝します私はそれを分割することができました：

COPY ["[^M][^y]*","/app/"] 
COPY ./My* /app/

これでも、最初のコマンドで.jsonファイルがコピーされるという問題が残りますが

@antoinecoのおかげで、私の問題は解決しました。 .gitディレクトリをDockerイメージにコピーしなくなりました。

これにより、画像サイズが劇的に改善され、Dockerキャッシングシステムに対して画像がはるかに使いやすくなりました。

私も同じ問題を抱えてる。 残りのファイルの前にコピーしたい大きなファイルがあるので、コピーに時間がかかるため、コンテキストを変更しても繰り返されません（7 GBのbinファイル）。 新しい回避策はありますか？

COPYおよびプルーニングアプローチの問題は、プルーニング前のレイヤーが引き続きすべてのデータを保持していることです。

COPY . --exclude=a --exclude=bは非常に便利です。 @ cpuguy83、どう思いますか？

@Nowaker私はそれが好きです。 とにかくtarとrsyncと一致しているようです。
これはdockerignoreと同じフォーマットをサポートするはずだと思いますか？

@tonistiigi @dnephin

このケースは＃32507で処理されると思います。

@ cpuguy83うん。 最も注目すべきは、 COPY --chown=uid:gidに沿ったものです

@dnephin RUN --mountは、出力が生成された後に不要なデータに基づいて何かを生成することを中心とした、まったく異なるユースケースのように聞こえます。 （たとえば、Goでコンパイルしたり、MarkdownファイルからHTMLを生成したりします）。 RUN --mountはドープであり、現在取り組んでいるプロジェクト（Sphinxを使用してAPIドキュメントを生成する）で間違いなく使用します。

COPY somedir --exclude=excludeddir1 --exclude=excludeddir2は、最終的にイメージに含まれる必要があるが、1つだけでなく複数のCOPYステートメントに飛び散るデータのコピーを中心としています。 目標は、プロジェクトのルートに多数のディレクトリがあり、変更/増加する可能性がある場合に、明示的なCOPY first second third .... eleventh destination/を回避することです。

私の場合、ソースファイルが変更されていない場合にキャッシュが使用されることを確認するために、最初に必須ではないファイルを除いて、ほとんどのファイルをコピーしたいと思います。 次に、コンパイル/生成します-コピーされたファイルが変更されていない場合はキャッシュを使用します（イェーイ）。 最初に、以前に除外したファイルをコピーします。これは、前回のビルド以降に変更された可能性がありますが、それらの変更はコンパイル/生成には影響しません。 明らかに、私はにたくさんのファイルとディレクトリを持っています。 最初にコピーしたいのですが、最後にコピーしたいのはカップルだけです。

アイデアは、 RUN --mountが多くの問題を解決できるということです。 COPY --excludeは、1つの問題のみを解決します。

個々の問題を解決するためにたくさんの構文を追加するよりも、多くの問題を解決するものを追加したいと思います。 RUN --mount... rsync --exclude ... （または個々のものをコピーするスクリプト）を使用すると、 COPY --excludeと同等になります。

@dnephinああ、私はRUN --mount rsyncを考えていませんでした！ 優れた！ 👍

それは確かに素晴らしいです。 ただし、rsyncしたいものだけでなく、マウントされたディレクトリで何かが変更されるとキャッシュが無効になるため、 @ Nowakerでキャッシュを効率的に活用することはできません。

そのrsyncの出力を他の何かの入力として使用し、そこで実際に変更されたファイルがない場合、キャッシュは再び取得されます。 あなたが本当にそれを望んでいるなら、あなたは現在https://gist.github.com/tonistiigi/38ead7a4ed60565996d207a7d589d9c4#file-gistfile1-txt-L130-L140のようなものでこれを行うことができます。 RUN --mount （またはビルドキットのLLB）での唯一の変更点は、ステージ間で実際にファイルをコピーする必要はなく、直接アクセスできるため、はるかに高速です。

https://docs.docker.com/develop/develop-images/multistage-build/を使用するのはどうですか？

FROM php:7.2-apache as source
COPY ./src/ /var/www/html/
RUN rm -rf /var/www/html/vendor/
RUN rm -rf /var/www/html/tests/

FROM php:7.2-apache
COPY --from=source /var/www/html/ /var/www/html/

@antoinecoウェルプ、それならもう素晴らしいものではありません。 ご指摘いただきありがとうございます。

@MartijnHolsこれは良い回避策です。 投稿していただきありがとうございます。

メンテナにとって：そうは言っても、「COPYに--chownを実装する理由、マルチステージビルドでRUNchownを使用できる」と言えます。 正気のために--excludeが必要です。 最近のDockerfilesにはあまりにも多くの回避策があります。

COPY --excludeの恩恵を受けるユースケースがあります。 コンテナ全体にコピーする必要があるビッグデータフォルダがあります。 そのディレクトリの内容は頻繁に変更される可能性があります。 キャッシュのパフォーマンスを向上させるために、ディレクトリに1つの大きなファイルがあり、残りをコピーする前に、それ自体のレイヤーにコピーします。 現在のところ、このタイプのコンテナを説明するのは不必要に冗長です。

Requirements.txtを中心としたレイヤードキャッシングを使用する正しい方法は何ですか

私はこれを持っています：

/root-app
 - /Dockerfile
 - /requirements.txt
 - /LICENSE
 - /helloworld.py
 - /app-1
     -/app-1/script1
     -/app-1/script2
     -/app-1/script3
 - /app-2
     -/app-2/script1

そしてDockerfile：

FROM python:slim
COPY ./requirements.txt /
RUN pip install --trusted-host pypi.python.org -r /requirements.txt
WORKDIR /root-app
COPY . /helloworld
CMD ["python", "helloworld.py"]

2番目のCOPYコマンドを使用して要件ビルドキャッシュを除外する正しい方法は何ですか...同様に、app-1とapp-2があまり変更されない場合は、それらをレイヤー化しますか？

@axehayzこれがあなたが求めているものかどうかはわかりませんが、 https： //medium.com/@guillaumejacquart/node-js-docker-workflow-12febcc0eed8のノードワークフローと同様のことを行います。

つまり、2番目のコピーがCOPY .あっても問題ありません。 pip installが前にある限り、インストールされたパッケージのキャッシュが無効になることはありません。

同じ問題に直面しました。 現時点では、別のディレクトリにあるファイルを展開したいと思います。

COPY --exclude = ... --exclude = ..の別のケースがあります。

画像サイズを縮小するためにCOPY--from = oldimageを実行しようとしています。ほとんどのファイルをコピーする必要がありますが、一部のファイルはコピーしません。 ディレクトリごとに実行できますが、これは面倒ですが、機能します...しかし、dirs /ファイルのリストを除外するか、複数の除外オプションを指定できると、非常に優れており、保守が容易になります。

それで、3年半後、まったく承認がありませんか？

@asimonfユースケースを理解するために、たくさんの謝辞があります。 誰もこの仕事をしていないということですか？ それは正しいです。 私たちは皆、自分たちが取り組むことについて選択をしなければなりません。

正直なところ、これは、Dockerfileに少し余分に書き込む必要がある場合でも、既存の機能を使用して非常に簡単に実行できます。

# haven't tested exact syntax, but this is the general idea
FROM myRsync AS files
COPY . /foo
RUN mkdir /result && rsync -r --exclude=<pattern> /foo/ /result/

FROM scratch
COPY --from=files /result/* /

buildkitを使用すると、追加のステージも必要ありません

#syntax=docker/dockerfile:experimental
..
RUN --mount=target=/ctx rsync ... /ctx/ /src/

マルチステージビルドを使用して何かが足りない場合を除いて、ここでの解決策とは思えません。 キャッシュは、COPY段階ではまだ無効になっています。

マルチステージビルドを使用して何かが足りない場合を除いて、ここでの解決策とは思えません。 キャッシュは、COPY段階ではまだ無効になっています。

これは正しいです。 それは私が今抱えている問題です。

マルチステージは私にとって素晴らしい働きをします。

キャッシュを完全に活用するために、ビルドをマルチステージに分割しています。次のようになります。

FROM alpine as source

WORKDIR /app
COPY . ./
RUN scripts/stagify-files

FROM node:12.4.0

WORKDIR /app

# Step 0: Setup environments
COPY --from=source /app/stage0 ./
RUN stage0-build.sh

# Step 1: Install npm packages
COPY --from=source /app/stage1 ./
RUN stage1-build.sh

# Step 2: Build project
COPY --from=source /app/stage2 ./
RUN stage2-build.sh

@zenozenのプロセスでの課題は、Dockerビルド専用にアプリケーションレイアウトを調整する必要があることです。これは、多くの人がやりたくないことです。
Dockerの使用は、アプリケーションファイルのレイアウト方法（保守性、新入社員の使いやすさ、プロジェクト間の標準、フレームワーク要件など）を理解する際にバランスを取るための多くの考慮事項の1つです。

@cfletcher私はあなたが何を意味するのか完全に理解できるかどうかわかりません。

上記の変更では、実際にDockerfileをサブサブディレクトリに移動しました（rsyncを使用してこれらのファイルを停滞させようとすると多くの問題が発生しました）。つまり、Dockerfileを非表示にしようとしていました。

私が提案したアプローチは、私が想像するように一般的です。 プロジェクトに100個のファイルがあるとします。 そのうちの1つを選択してstage0を作成し、次に1 + 10を選択してステージ1を作成し、次に100をすべて選択してステージ2を作成します。各ステージは前のステージの上にスタックされ、異なるビルドコマンドがあります。 複雑なプロジェクト構造の場合、それは単にstagify-filesロジックが複雑になることを意味します。

私にとって最大の理由は、コードをモジュールに分割し、 npm installを実行する前にすべてのpackage.jsonファイルをコピーする必要があることです。

また、コピーのためのある種の除外引数が必要です。 ルートディレクトリには20以上のファイルと10以上のディレクトリがあります。 2つのディレクトリといくつかのファイルを大量にコーディングします。 これらを2つのCOPYレイヤーに分割したいと思います。 1つは、私たちが決して触れない静的ファイルとディレクトリ用であり、もう1つは、私たちが常に触れるファイルとディレクトリ用です。

非常に悲しいことに、これはまだ無視されています。 これにより、キャッシュを無効にしないために1つのディレクトリを除外できれば、ビルドごとに5分節約できたはずです。

buildkitを使用すると、キャッシュはpre-buildkitのように親イメージに依存しません。
したがって、前述のrsyncソリューションでは、変更があるたびに同期する必要があるという点でヒットしますが、後続のステージはコンテンツに基づいてキャッシュされ、転送される内容が変更されない場合はキャッシュされます。 ..少なくとも私の完全なオンザスポット理論では、これらのステージはキャッシュを使用する必要があります。

単純な--excludeフラグをCOPYに追加するのは、とても難しい販売です。 これはTOP30で最も支持されているチケットであり、他のTOP30チケットと比較して実装に関しては比較的簡単です。 :(

物議を醸すものではなく、作業が必要です。

@ cpuguy83イェーイ。 それは物議を醸す/やや拒否されたように見えました。 品質基準に合格すれば、 COPY --excludeの適切なPRが受け入れられる可能性が高いということですか？

すべてのメンテナについて話すことはできませんが、これとIIRCについて、これがdockerignoreや構文などにどのように関係するかについて、1か月ほど前に@tonistiigiに話しました（そして、dockerignoreが構文的に不十分であるという事実）。

変更はビルドキットに入れる必要があります。

COPY --exclude=... --exclude=...賛成-モノリスリポジトリの場合も必要

賛成！ COPY !(excludedfile) .で試してみましたが、これはBashで動作するはずですが、Dockerでは動作しません

$＃$ Dockerfile $＃$内のすべてのCOPYステートメントに対して.dockerignoreファイル内のすべてを繰り返さなければならないという提案は好きではありません。 画像の一部になり、優先されるべきではないものでDRYを維持できること、imho。

＃33923を見ると、ビルドコンテキストから除外したいものが、 COPYステートメントから除外したいものとまったく同じであるのは偶然ではないと思います。 私はこのようなものが良い解決策になると信じています：

COPY --use-dockerignore <source> <target>

または、おそらく次のようなものです。

COPY --use-ignorefile=".gitignore" <source> <target>

.dockerignoreが通常.gitignoreの90％の複製であることに気付くと、無視されたすべてのファイルとフォルダーをCOPYステートメントごとにもう一度繰り返す必要があるのは非常に面倒です。 より良い方法が必要です。

@ asbjornu.gitignoreと.dockerignoreはまったく同じものではありません。 特に、アーティファクトがビルドステージで生成され、gitにまったく存在しないマルチステージビルドの場合でも、結果のイメージに含める必要があります。
そして、はい、導入されたマルチステージビルドでは、ステージごとに異なる.dockerignoreファイルを使用する機能が必要です-絶対に。

「dockerbuild」の外でコピーしたいことがよくあります。 このような場合、.dockerignoreは何もしません。 唯一の賢明な解決策である「dockercp」の修正が必要です

この号が発行されてから5年になります。 2020年9月、私はまだこれが欲しいです。 多くの人が回避策としてハックを提案していますが、ほとんどすべての人と他の人が何らかの形でexcludeフラグを要求しています。 この問題をしばらくの間未解決のままにしないでください。

何かが必要な場合は、それに取り組むか、それに取り組む誰かを見つける必要があります。

何かが必要な場合は、それに取り組むか、それに取り組む誰かを見つける必要があります。

まず、アップストリームがこれを望んでいるかどうかを知る必要があります。

https://github.com/moby/moby/issues/15771#issuecomment -550571058

ソースコードのレビュー後、まずここhttps://github.com/tonistiigi/fsutil/blob/master/copy/copy.goでコピー機能を拡張する必要があると思います。 その後、libsolverでbackend.goを拡張できます。その後、ASTとbuildkitのフロントエンドを拡張できるようになります。
しかしその後、コピーはunixcpよりもrsyncセマンティックに近くなります。

更新：はい、copy.goを拡張した後、すべてがhttps://github.com/moby/buildkit/pull/1492に近くなり、除外のリストが解析されます。