Moby: ファイルグロブを使用したDockerfileCOPYは、ファイルをサブディレクトリから宛先ディレクトリにコピーします

docker infoおよびuname -aからの出力で元のメッセージを更新し、問題報告テンプレートに従って再フォーマットしました。

私は1.6.2と1.8でこれを持っています
https://gist.github.com/jrabbit/e4f864ca1664ec0dd288第2レベルのディレクトリは、何らかの理由で第1レベルのディレクトリとして扱われる必要がありますか？

グーグルの場合：COPY * / srcで問題が発生した場合は、COPY / / srcを試してください。

@jfchevrette私はこれがなぜ起こっているのか知っていると思います。
COPY files/* /test/あり、これはCOPY files/dir files/file1 files/file2 files/file /test/ます。 これを個々のCOPYコマンド（たとえば、 COPY files/dir /test/ ）に分割すると、（良くも悪くも）COPYが各argdirの内容を宛先dirにコピーすることがわかります。 arg dir自体ではなく、内容です。 あなたが第3レベルのdirsを追加した場合、私はそれらが固執するに違いない。

COPYがトップレベルのディレクトリを保持しないという事実に私はわくわくしていませんが、それはしばらくの間そのようになっています。

可能であれば、srcツリーの1つ上のレベルをコピーすることで、これをそれほど苦痛にしないようにすることができます。

@duglinが正しいと確信しており、その動作を変更することは非常に危険です。 多くのdockerfileは、意図しないものを壊したり、単にコピーしたりする可能性があります。

ただし、長期的には、コピーがcpやrsyncなどのツールがフォルダーのグロブと末尾のスラッシュを処理する方法に従っている方がよいと私は主張します。 COPYがdir / *に一致するサブフォルダーから宛先IMOにファイルをコピーすることは絶対に期待されていません。

@jfchevretteうん-これを「修正」する必要がある最初のチャンス。
今のところそれを閉じます...

@duglinだから、閉じるということは修正されないということですか？

@tugberkugurluうん、少なくとも今のところは。 ビルドインフラストラクチャ全体をやり直す作業が進行中であり、それを行うときは、COPY（またはその新しい同等のもの）を適切に動作させることができます。

@duglinありがとう。 この問題を開いたままにして、ここでステータスを更新することは可能ですか？ それとも、私が購読できる他の問題はありますか？

@tugberkugurlu 「クライアント側ビルダーのサポート」に問題があると思いましたが、見つからないようです。 つまり、ROADMAP（https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax）が言うことだけです。

問題を未解決のままにしておくことに関しては、私たちはそれができないと思います。 Dockerが従っている一般的なルールは、すぐに実行できない問題をすべて閉じることです。 将来の作業のための問題は、通常、問題に対して何らかのアクション（PR）を実行できるように状況が変化すると、閉じられ、再開されます。

@duglinこれは非常に深刻な問題です。この問題は、0.1リリースで発生したため、単に閉じる必要はありません。 これを2.0リリースのターゲットにする方が適切です（マイルストーンはgithubにもあります）。

私はほとんどの人が使用すると思います：

COPY . /app

.gitignore内の他のすべてのフォルダをブラックリストに登録するか、単一レベルのディレクトリ構造を持ち、実際にはmvセマンティクスを持つ$ COPYを使用します。

COPY src /myapp

誰かが実際にディレクトリ構造をフラット化するためにCOPYを使用することを想像するのは非常に難しいです。 これに対する他の回避策は、 tar -cf .. & ADD tarfile.tar.gzを使用することです。 少なくともこれを変更することは本当に役に立ちます。 もう1つは、ディレクトリ名COPY src /srcとCOPY src/ /src （現在は完全に無視されています）のスラッシュを尊重することです。

ダグリンは2015年9月1日にこれを閉じました

@duglinこれはばかげて腹立たしい問題であり、閉じるべきではありません。 COPYコマンドは、文書化された使用法と例とは特に一致しない動作をします。

@tjwebb未解決の問題https://github.com/docker/docker/issues/29211がまだあります。 これは、完全に下位互換性のあるこれを修正する方法がある場合にのみ調べることができます。 これをどのように実装できるかという提案があれば、私たちは提案を受け入れます（もしあなたがそうするなら、これを自由に書いて、この問題にリンクする提案を開いてください）。 cpの処理方法には、（たとえば）OS XとLinuxの間にすでに違いがあることに注意してください。

mkdir -p repro-15858 \
  && cd repro-15858 \
  && mkdir -p source/dir1 source/dir2 \
  && touch source/file1 source/dir1/dir1-file1 \
  && mkdir -p target1 target2 target3 target4 target5 target6

cp -r source target1 \
&& cp -r source/ target2 \
&& cp -r source/ target3/ \
&& cp -r source/* target4/ \
&& cp -r source/dir* target5/ \
&& cp -r source/dir*/ target6/ \
&& tree

OS X：

.
├── source
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target1
│   └── source
│       ├── dir1
│       │   └── dir1-file1
│       ├── dir2
│       └── file1
├── target2
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target3
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target4
│   ├── dir1
│   │   └── dir1-file1
│   ├── dir2
│   └── file1
├── target5
│   ├── dir1
│   │   └── dir1-file1
│   └── dir2
└── target6
    └── dir1-file1

20 directories, 12 files

Ubuntuの場合（/ bin / sh）

.
|-- source
|   |-- dir1
|   |   `-- dir1-file1
|   |-- dir2
|   `-- file1
|-- target1
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target2
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target3
|   `-- source
|       |-- dir1
|       |   `-- dir1-file1
|       |-- dir2
|       `-- file1
|-- target4
|   |-- dir1
|   |   `-- dir1-file1
|   |-- dir2
|   `-- file1
|-- target5
|   |-- dir1
|   |   `-- dir1-file1
|   `-- dir2
`-- target6
    |-- dir1
    |   `-- dir1-file1
    `-- dir2

24 directories, 12 files

diff --git a/macos.txt b/ubuntu.txt
index 188d2c3..d776f19 100644
--- a/macos.txt
+++ b/ubuntu.txt
@@ -11,15 +11,17 @@
 │       ├── dir2
 │       └── file1
 ├── target2
-│   ├── dir1
-│   │   └── dir1-file1
-│   ├── dir2
-│   └── file1
+│   └── source
+│       ├── dir1
+│       │   └── dir1-file1
+│       ├── dir2
+│       └── file1
 ├── target3
-│   ├── dir1
-│   │   └── dir1-file1
-│   ├── dir2
-│   └── file1
+│   └── source
+│       ├── dir1
+│       │   └── dir1-file1
+│       ├── dir2
+│       └── file1
 ├── target4
 │   ├── dir1
 │   │   └── dir1-file1
@@ -30,6 +32,8 @@
 │   │   └── dir1-file1
 │   └── dir2
 └── target6
-    └── dir1-file1
+    ├── dir1
+    │   └── dir1-file1
+    └── dir2

-20 directories, 12 files
+24 directories, 12 files

新しいコマンドCPを作成し、今度は正しく取得してください。

私は上記を繰り返します、これは数え切れないほどの開発時間を無駄にしたに違いありません、それは非常に直感的ではありません。

私から+1。 これは本当にばかげた振る舞いであり、COPYが持つべき方法を実行するCPコマンドを追加するだけで簡単に修正できます。

「下位互換性」は警官です

TL; DRバージョン：

COPY * /appを使用しないでください。期待どおりの動作をしません。
ディレクトリツリーを保持するには、代わりにCOPY . /appを使用してください。

COPYは、そのサブフォルダーのみをコピーできます。

これに数え切れないほどの時間を費やしただけです...なぜこれがこのように機能するのですか？

私はPaketを使用しており、正しい構造で以下をコピーしたいと思います。

.
├── .paket/
│   ├── paket.exe
│   ├── paket.bootstrapper.exe
├── paket.dependencies
├── paket.lock
├── projectN/

そして、 COPY *paket* ./を実行すると、コンテナ内で次のようになります。

.
├── paket.dependencies
├── paket.lock

COPYとADDに--globまたは--recursiveフラグを追加するのはどうですか？

コピー 。 / destinationはサブフォルダーを保持します。

3年とこれはまだ問題です：-/

これが修正されるときに、ETAを取得できますか？

問題ない...
上から...
コピー 。

確かに、半日発煙してここにたどり着いた後は、もはや問題ではありません。 もちろん ：）
建設的になりましょう、

_COPY_への新しい_CP_コマンドまたは--recursiveフラグが本当に必要なので、下位互換性が維持されます。

次のように、イメージビルドに関する警告も表示する場合のポイント：
誤用の可能性を検出した場合はDirectory structure not preserved with COPY *, use CP or COPY . More here <link>. 。

サブディレクトリ内のネストされたlernapackage.jsonファイルをコピーして、依存関係が変更された場合にのみトリガーするnpm installキャッシュをより有効に活用するために、これを探しています。 現在、変更されたすべてのファイルにより、依存関係が再インストールされます。

このようなものは素晴らしいでしょう：

COPY ["package.json", "packages/*/package.json", "/app/"]

＃29211みんなをチェックしてください。 これは閉鎖されており、誰も気にしません。

@zentby会話はここにあり、問題はそこで追跡されます（これは閉じられているため）...混乱しています。

回避策は、 COPYファイルとRUN cp-Rコマンドです。

COPY files /tmp/
RUN cp -R /tmp/etc/* /etc/ && rm -rf /tmp/etc

COPYコマンドは、キャッシュを無効にすべきではないファイルが異なる場合にキャッシュを破棄するため、 @ instabledesignでは機能しません（たとえば、npm依存関係のインストールに関連するファイルのみをコピーしたいので、頻繁には変更されません）

また、ファイルのセット（私の場合は、dotnetcoreの* .slnファイルと* .csprojファイル）だけを逆キャッシュにコピーする必要がありました。 回避策の1つは、必要なファイルだけのtarボールを作成してから、Dockerファイルにtarボールを追加することです。 ええ、Dockerファイルに加えてシェルスクリプトが必要です...

build.sh

#!/bin/bash

# unfortunately there's no easy way to copy just the *.sln and *.csproj (see https://github.com/moby/moby/issues/15858)
# so we generate a tar file containing the required files for the layer

find .. -name '*.csproj' -o -name 'Finomial.InternalServicesCore.sln' -o -name 'nuget.config' | sort | tar cf dotnet-restore.tar -T - 2> /dev/null

docker build -t finomial/iscore-build -f Dockerfile ..

Dockerファイル

FROM microsoft/aspnetcore-build:2.0
WORKDIR /src

# set up a layer for dotnet restore 

ADD docker/dotnet-restore.tar ./

RUN dotnet restore

# now copy all the source and do the dotnet buld
COPY . ./

RUN dotnet publish --no-restore -c Release -o bin Finomial.InternalServicesCore.sln

複数のCOPYコマンドを使用してこれを行うことができますが、複数の画像レイヤーを作成し、最終的な画像サイズを肥大化させるという欠点があります。

上記のkayjteaのように、 docker buildコマンドをヘルパービルドスクリプトでラップして、ディレクトリ構造を保持するtarballを作成し、それらをADDで作成することもできますが、これにより複雑さが増し、 docker-compose buildのようなものが壊れます。

実際、 COPYはPOSIX準拠の/bin/cp -rコマンドと同じように機能するはずですが、現在の動作は経験のある人にとっては完全に直感的ではありませんが、「下位互換性」では起こらないようです。 * nixシステムで。

私が見つけた最善の妥協点は、ハックとして多段階ビルドを使用することです。

FROM scratch as project_root
# Use COPY to move individual directories
# and WORKDIR to change directory
WORKDIR /
COPY ./file1 .
COPY ./dir1/ ./dir1/
COPY ./dir2/ .
WORKDIR /newDir
COPY ./file2 .

# The actual final build you end up using/pushing
# Node.js app as example
FROM node
WORKDIR /opt/app

COPY package.json .
RUN npm install

COPY --from=project_root / .
CMD ["npm", "start"]

これは1つのDockerfile内に自己完結しており、 ADD project.tarが機能するのと同じように、最終的なイメージに1つのレイヤーのみを作成します。

完全なCOPYコマンドがあると、Dockerビルドキャッシュを保持しようとするときに非常に役立ちます。 ROSコミュニティは、パッケージのネストされたワークスペースを使用して開発され、各パッケージは独自のpackage.xmlファイルで依存関係を宣言します。 これらのファイルは、依存関係マネージャーがアップストリームライブラリをインストールするために使用します。 これらのpackage.xmlファイルは、基礎が設定されると、パッケージ自体のコードに比較的まれにしか変更されません。 コピー中にディレクトリツリー構造が保持されている場合は、Dockerのビルド中にワークスペースを2段階でコピーするだけで、キャッシュを最大化できます。

# copy project dependency metadata
COPY ./**/package.xml /opt/ws/

# install step that fetches unsatisfied dependency
RUN dependency_manager install --workspace /opt/ws/

# copy the rest of the project's code
COPY ./ /opt/ws/

# compile code with cached dependencies
RUN build_tool build --workspace /opt/ws/

したがって、上記の依存関係インストールレイヤーのキャッシュは、開発者が宣言された依存関係を変更した場合にのみ無効になりますが、パッケージのコードを変更すると、コンパイルレイヤーのみが無効になります。

現在、一致したすべてのpackage.xmlファイルが、宛先ディレクトリのルートに相互に重ねてコピーされており、最後にグローブされたファイルが、イメージに残っている唯一のpackage.xmlです。 これは、ユーザーにとって非常に直感的ではありません。 コピーされたファイルが互いに上書きされるのはなぜですか。さらに、未定義の動作が最終的にイメージに残ります。

これは、基本的にパッケージ管理を行うすべてのスタックで非常に苦痛であるため、私たちの多くに影響を及ぼします。 修正できますか？ シーシュ。 2015年から問題になっています！ CPの新しいコマンドを使用するという提案は良いものです。

これを再開できますか？ COPYコマンドが、globのような実際に広く採用されている標準ではなく、パスマッチングにgolang内部関数を使用するのは非常に面倒な動作です。

実験的なビルドキット構文の回避策を使用してグロビンを介してコピーしたい場合は、キャッシュがそれほど正確または堅牢でなくても、ここのコメントを参照してください： https ：//github.com/moby/moby/issues

選択的なグロブスタイルのコピーをキャッシュできるように、この問題を再度開いてほしいと思います。

https://github.com/moby/moby/issues/15858#issuecomment -462017830の例では、マルチステージビルドを介して比較的簡単な回避策を実現しました。同様のニーズを持つ多くの人は、コピーされた任意のキャッシュを高く評価する可能性があると考えました。ビルドコンテキストからのアーティファクト。 マルチステージビルドを使用すると、ディレクトリをフィルタリング/前処理してキャッシュすることができます。

# Add prior stage to cache/copy from
FROM ubuntu AS package_cache

# Copy from build context
WORKDIR /tmp
COPY ./ ./src

# Filter or glob files to cache upon
RUN mkdir ./cache && cd ./src && \
    find ./ -name "package.xml" | \
      xargs cp --parents -t ../cache

# Continue with primary stage
FROM ubuntu

# copy project dependency metadata
COPY --from=package_cache /tmp/cache /opt/ws/

# install step that fetches unsatisfied dependency
RUN dependency_manager install --workspace /opt/ws/

# copy the rest of the project's code
COPY ./ /opt/ws/

# compile code with cached dependencies
RUN build_tool build --workspace /opt/ws/

実際の作業例については、こちらもご覧ください： https ：//github.com/ros-planning/navigation2/pull/1122

サブディレクトリ内のネストされたlernapackage.jsonファイルをコピーして、依存関係が変更された場合にのみトリガーするnpm installキャッシュをより有効に活用するために、これを探しています。 現在、変更されたすべてのファイルにより、依存関係が再インストールされます。

このようなものは素晴らしいでしょう：

COPY ["package.json", "packages/*/package.json", "/app/"]

まったく同じユースケースを持っているim。

サブディレクトリ内のネストされたlernapackage.jsonファイルをコピーして、依存関係が変更された場合にのみトリガーするnpm installキャッシュをより有効に活用するために、これを探しています。 現在、変更されたすべてのファイルにより、依存関係が再インストールされます。

このようなものは素晴らしいでしょう：

COPY ["package.json", "packages/*/package.json", "/app/"]

この場合ですが、Yarnワークスペース用です。

2020年ですが、これはまだ修正されていません。

誰かがdotnet設定でこれに苦労している場合は、*。csprojファイルのディレクトリ構造を復元して復元を実行できるdotnetコアグローバルツールを作成することで解決しました。 ここでそれを行う方法についてのドキュメントを参照してください。

参考までに、理論的には他の設定でも同様のアプローチを使用できますが、基本的にツールはフォルダー構造をリバースエンジニアリングするため、たとえばlernaやyarnワークスペースのセットアップがどれほど簡単か可能かはわかりません。 興味があれば調査してください。 人々がdotnetコアランタイムをインストールして動作させることができれば、同じツールでも可能である可能性があります。そうでない場合は、ノードなど、新しい依存関係を必要としない言語で同じアプローチを構築する必要があります。私は推測する。

コピーコマンドの実装が最初の年の学生の仕事であったことは驚くべきことですが、今では長年の経験を持つ熟練したプログラマーにとっては複雑すぎます...

これはおそらくこれまでで最も恥ずかしいバグではありませんが、出力なしで長年の議論が続いていることを考慮すると、確かにトップになります。

@benmccallum
参考までに、理論的には他の設定でも同様のアプローチを使用できますが、基本的にツールはフォルダ構造をリバースエンジニアリングします。

ほとんどの場合、 https： //github.com/moby/moby/issues/15858#issuecomment -532016362が提案したことを実行し、マルチステージビルドを使用してプレフィルターを実行する方が簡単ではありませんか？

また、 dotnet restoreの場合、これは比較的簡単なパターンです。

# Prefiltering stage using find -exec and cp --parents to copy out
# the project files in their proper directory structure.
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS dotnet-prep
COPY . ./src/
RUN mkdir ./proj && cd ./src && \
  find . -type f -a \( -iname "*.sln" -o -iname "*.csproj" \) \
    -exec cp --parents "{}" ../proj/ \;

# New build stage, independent cache
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS dotnet-build

# Copy only the project files with correct directory structure
# then restore packages
COPY --from=dotnet-prep ./proj ./src/
RUN dotnet restore

# Copy everything else
COPY --from=dotnet-prep ./src ./src/
# etc.

それでも、DockerがCOPYコマンドに、通常の正常な同期セマンティクスに従った適切なバリアントを実装したことがないという適切な言い訳にはなりません。
つまり; 来て！

@rjgotten 、私はそれが好きです！ 確かに私がやったことよりもはるかに簡単で、なぜこれが私のニーズに合わないのかわかりません。 明日試してみます。これがうまくいったら、より良いアプローチとしてこれを推奨するようにドキュメントを変更します。

私の最初の問題は私がWindowsを使用していたことだったと思うので、おそらくその提案を却下しました。 私はもういませんが、完全を期すために同等のWindowsバージョンはありますか？ PowerShellがdotnetコアイメージにプリインストールされているのだろうか...

追加の/繰り返されるFROMの必要性は本当にありますか...しかし？ RUNを実行するたびに、キャッシュ用の新しいレイヤーが作成されますよね？ 何かが足りないのかもしれませんが、これについて考えなければならなかったのは久しぶりです！

PowerShellがdotnetコアイメージにプリインストールされているのだろうか...

実はそうだと思います。 これにより、クロスプラットフォームの方法でこれを行うのが少し簡単になります。

追加の/繰り返されるFROMの必要性は本当にありますか...しかし？

分離されたビルドステージは、独立したレイヤーキャッシングを取得します。
最初の段階で準備作業を行います。 最初はすべてをコピーする必要があるため、_any_ファイルが変更されると、常に最初のレイヤーのキャッシュが無効になり、その後のレイヤーが無効になります。 しかし、それは_そのビルドステージ内の_レイヤーにのみ当てはまります。

第2段階は、プロジェクト関連のファイルを_のみ_コピーすることから始まり、それらのファイルが同じである限り、つまり同じファイル名である限り、 同じコンテンツ; など-ビルド間で、そのレイヤーは無効になりません。 つまり、これらのプロジェクトファイルが実際に変更されない限り、 dotnet restoreレイヤーも無効になりません。

これと一緒に座る時間がありました、そして私は今理解しています！ Dockerは楽しいものです。常に時間を費やさない限り、すべてのコマンドがどのように機能するかを忘れてしまうからです。 重要なのは、RUNコマンドがDockerイメージのファイルシステムでのみ機能し、ビルドコンテキストファイルでは機能しないことを忘れていたことです。 したがって、dirsを保持する複雑なRUNコマンドを実行する前に、すべてをコピーする必要があります。 そしてそれが私たちがまともなCOPYグロビングを切実に必要としている理由です！

そのアプローチ
最初のCOPYcmdは、おっしゃるように、_everything_をコピーしてから、.slnファイルと.csprojファイルを別の/ projフォルダーに引き出します。 コードを変更すると、これらの手順が無効になります。 重要なのは、これが回避している制限は、素晴らしいRUN linux cmdが、以前の貪欲なCOPYによってもたらされた_dockerイメージ上の_ファイルに対してのみ操作できることです。

次に、新しいステージが開始され、/ projフォルダーの内容がコピーされ、 dotnet restoreで使用できるようになります。 キャッシュの「キー」は本質的にファイルハッシュであるため、これによってこのキャッシュレイヤーが破壊されることはめったになく、後続のdotnet restore層も破壊されないため、コストのかかる復元を回避できます。 良い！

私のアプローチ
ドットネットの復元に影響を与えるファイルを引き継ぐために、さらにいくつかのCOPYコマンドを犠牲にして、これに1つのビルドステージのみを使用します。 具体的には、すべての.csprojファイルを1つのディレクトリにフラット化し、グローバルツールを使用して、エントリの.slnファイルから適切なディレクトリ構造を再構築します。 すべてのsrcファイルをコピーするのはこの後だけなので、常にすべてのsrcファイルを前もってコピーする必要はなく、ここまでのレイヤーを定期的に効果的にキャッシュできます。

要点
それぞれのアプローチがどれほど効果的かは、人々のコードベースに依存すると思います。 私たちの場合、モノレポジトリには、「すべてのsrcover」COPYでコピーされる多くの共有コードがあります。 .dockerignoreはここで役立ちますが、維持するのが難しいので、そのCOPYではかなり「貪欲」です。 とても遅いです。 そのため、私のアプローチは少し複雑ですが、おそらくこの代替案よりも高速です。

説明してくれてありがとう。 まだこの会話をしなければならないなんて信じられません。 これが今より簡単かどうかを確認するために、新しいBuildKitのものを調査する必要があります。 他の誰かがそれをしましたか？

BuildKitの調査
RUN --mount=type=bind -このように聞こえますが、これにより、ビルドコンテキストに対して派手なLinux cmdを実行できます（ RUNがイメージのファイルシステムに限定されるだけではありません）。 実際、デフォルトでビルドコンテキストになっているようです。

RUN --mount=type=cache -保存されているある種の再利用可能なキャッシュディレクトリ（dockerビルド間？）のように聞こえますか？ つまり、本質的には、パッケージを復元するためのキャッシュレイヤーについてあまり心配する必要はありません。以前に復元されたパッケージの再利用されたキャッシュを使用すると、すでにはるかに高速になるからです。

この問題は「クローズ」されており、回避策に慣れているため、まだ修正されていないと思います。

なぜ人々が他の種類のコンテナに移動する傾向があるのか​​理解できないとき。

他に使える容器タイプはありますか？ これが何年も経ってもサポートされていないなんて信じられませんか？ dockerはオープンソースプロジェクトですか？誰かが修正してもらえますか？

EarthlyにはCOPY --dirオプションがあり、コピーをcp -rのように動作させることができます。 おそらく、これはDockerfileにも移植できますか？

.netコアアプリケーションのイメージの構築を高速化するには、復元されたすべてのnugetパッケージを含む中間コンテナーを作成する必要があります。 マルチプロジェクトソリューションでは、この回避策を使用しました。 すべてのプロジェクトファイルを1つのフォルダーにコピーし、それぞれに対してdotnetrestoreを実行しました。 フォルダ階層を保持できないため、プロジェクトの欠落についていくつかの警告がありますが、それでも解決策は機能しています。

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build

# Nugets restore
WORKDIR /src/allprojects          # just temporary storage for .csproj files
COPY */*.csproj ./
RUN for file in $(ls *.csproj); do dotnet restore ${file}; done

# Build/Publish
WORKDIR /src/solution             # actual folder with source code and full hierarchy 
COPY . .
RUN dotnet publish "MyProject/MyProject.csproj" -c Release -o /bublish/myproject

# Run Application
FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS base
WORKDIR /app
COPY --from=build /bublish/myproject .
ENTRYPOINT ["dotnet", "MyProject.dll"]

@zatuliveter
フォルダ階層を保持できないため、プロジェクトの欠落についていくつかの警告がありますが、それでも解決策は機能しています。

番号; それは機能しません。 そして、その理由は次のとおりです。

.NET Coreは、パッケージのメタ情報を各プロジェクトに関連付けられた./objサブディレクトリに格納します。 その情報が存在しない場合、パッケージはインストールされて使用できる状態であるとは見なされません。 （私を信じてはいけませんか？次に、 ./objフォルダーを破棄してから、たとえばVSCodeでプロジェクトを開き、パッケージの復元を再実行するように求められるのを確認してください。どうぞ、試してみてください。）

パッケージの復元を実行するプロジェクトファイルが次のdotnet buildまたはdotnet publishとは異なるディレクトリ構造にある場合、これらのコマンドはパッケージが復元されたとは見なしません。

ソリューションが完全に失敗しない理由は、 dotnet publishとdotnet buildの両方がdotnet restoreを意味するためです。 復元されていないパッケージを積極的にチェックし、オンザフライで復元します。 彼らがこれを行うのを避けるために、あなたは積極的にあなたがしていない--no-restoreフラグを渡す必要があります。

つまり、実際には、ソリューションが実行しているのは、パッケージ_TWICE_を復元することです。 初回は、再利用するための正しいディレクトリ構造に入らないため、本質的に時間とスペースの大きな浪費です。 2回目は、 publishコマンドの一部として暗黙的に機能します。 ただし、これはビルドと公開の操作と同じレイヤーの一部であるため、コードの変更とは別にパッケージが実際にキャッシュされることはありません。

@rjgotten 、
ご返信とご説明ありがとうございます。
実際、すべてのnugetパッケージは、「build」dockerコンテナーのglobal-packagesフォルダーにキャッシュされます。 私の場合、それは/root/.nuget/packages/フォルダーであり、 objフォルダーには、このグローバルストレージへの参照を含む小さなファイルが含まれているだけなので、（おっしゃるように）ストレージを無駄にすることはありません。
すべてのnugetがコンテナにキャッシュされるため、公開中の2回目の復元は少なくともx10倍速くなります（私の場合）。

@ zatuliveter @ rjgottenここの最後にある情報に感謝します。 私は同様の問題に遭遇し、あなたが与えた例を改善するために次のdockerfileを思いついた。 バッシュは確かに私の強いスーツではないので、私に気楽に行ってください！ 私たちの構造は、すべてのプロジェクトでProject/Project.csprojです。 これにより、すべてのprojファイルがコピーされ、正しい場所に移動されてから、復元/すべてのコピー/公開が実行されます。

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ./*/*.csproj ./proj/
RUN for file in $(ls ./proj); do mkdir /src/${file%.*} && mv ./proj/${file} /src/${file%.*}/${file}; done
RUN dotnet restore "MyProject/MyProject.csproj"
COPY . .
WORKDIR "/src/MyProject"
RUN dotnet publish "MyProject.csproj" -c Release -o /app --no-restore