Dockerビルドコンテキストの目的は何ですか？
Dockerビルドコンテキストの目的は何ですか？ドキュメントから、コンテンツ全体がdockerデーモンに送信される「エントリ」ポイントであることを理解しています。しかし、生成されたイメージに現在のディレクトリの内容を実際に含めるためにDockerfileにCOPYまたはADDディレクティブを明示的に含める必要がある場合、例で提供されているデフォルトのユースケースを想定して、現在のディレクトリの内容全体を送信するポイントは何ですか？コンテキストがデーモンに送信されてイメージに含まれる場合、なぜこの追加手順を実行する必要があるのですか。圧縮されたアップロード/送信/コピータスクに、指定されたディレクトリのコンテンツがデフォルトで含まれないのはなぜですか？
例えばこのディレクトリ構造を考える
-rw-r--r-- 1 me me 7 Jun 8 18:52 .dockerignore
-rw-r--r-- 1 me me 1.1K Jun 9 12:42 Dockerfile
drwxr-xr-x 13 me me 4.0K Jun 8 19:43 myproject
このコマンドdocker build -t user/myproject：2.3を実行すると。
次に、生成されたイメージのどこかにmyprojectディレクトリが表示されると予想します。しかし、私は含める必要があります
ADD myproject /
そのために。
ビルドプロセスが現在のディレクトリの内容を圧縮してデーモンに送信する場合、どこに行きますか？そのコンテンツが画像で使用できるようにしないのはなぜですか？
TL; DR：「クライアントとデーモンが同じマシン上でも実行されない可能性があるため」
dockerコマンドは、PC（linux）またはLinuxで直接実行できるサービスであるdockerdのdockerクライアントです。 VM OSXまたはWindowsの場合。
Q：Dockerビルドコンテキストの目的は何ですか？
ここ から：
クライアントとデーモンが同じマシン上でさえ実行されない可能性があるため、この方法でこれを行わなければならないことも言及しておくとよいでしょう。この「コンテキスト」がなければ、デーモンマシンはADDまたはさもないと
Q：ビルドプロセスが現在のディレクトリの内容を圧縮してデーモンに送信する場合、どこに行きますか？
Dockerデーモンは圧縮ディレクトリを受け取り、その場で処理します。その瞬間にどこに保存されるかは関係ありません。
Q：なぜ画像でそのコンテンツを使用できるようにしないのですか？
これを考えてください：dockerはどのようにdoyouが各ファイル/ディレクトリをターゲットイメージに置きたいかを知ることができますか？ COPY/ADDディレクティブは、それぞれをどこに置くかを制御できます。あなたが言及したケースは、ディレクトリとターゲットのみがあるという些細な例にすぎません。