絶対パス

まず、に絶対パスを使用することはできませんCOPY。すべてのパスは、ビルドのコンテキスト内にある必要がありますDockerfile。つまり、に関連している必要があります。ホストのフォルダ構造が次のような場合

my-docker-directory
-- Dockerfile
-- docker-compose.yml
-- addons

その後、を使用することができますCOPY addons /path/to/directory/inside/container。以降のすべての説明では、にaddons関連するフォルダーがあると想定していますDockerfile。

ディレクトリのマウント

COPY実行時にフォルダをコンテナにマウントするだけではありません。実際にはディレクトリをマウントしません。代わりに、addonsされるコピーに/path/to/directory/inside/container内部の画像。このプロセスは単方向（ホスト>イメージ）で発生し、イメージがビルドされたときにのみ発生することを理解することが重要です。

COPYバイナリにコンパイルされたソースコードのように、ビルド時に必要だった依存関係をイメージに追加するように設計されています。それが絶対パスができない理由です。Dockerfile通常、トップレベル領域にソースコード/設定ファイルと一緒に配置されています。

イメージのビルドプロセスは、を使用して強制する場合を除いて、最初の実行でのみ発生しdocker-compose up --buildます。しかし、これはあなたが望むものではないようです。実行時にホストからディレクトリをマウントするにvolumeは、docker-composeファイルでaを使用します。

version: '3'
services:
  test:
    build: .
    volumes:
      - ./addons/:/path/to/directory/inside/container

いつ使用しCOPY、いつボリュームを使用しますか？

それはことを認識することが重要だCOPYとADDしますコピーする場合は、ビルド時に画像にものをvolumes（画像でそれらを含めず）runtumeでホストからそれらをマウントします。したがって、通常は、デフォルトの構成ファイルのようにユーザーが必要とする一般的なものをイメージにコピーします。

ボリュームには、カスタマイズされた構成ファイルなど、ホストからのファイルを含める必要があります。またはデータベースのデータディレクトリとして永続的なもの。ボリュームがないと、これらのコンテナーは機能しますが、永続的ではありません。そのため、コンテナを再起動するとすべてのコンテンツが失われます。

一方が他方を除外しないことに注意してください。それはにいいのよCOPY、ユーザーがそれらを変更するボリュームでこれを無効にすることができる画像では、いくつかのアプリケーションのデフォルトの設定、。特に開発中は、変更された単一の構成ファイルに対してイメージ全体を再構築する必要がないため、これにより作業が簡単になります*。

*統合キャッシュメカニズム用にDockerfilesを最適化することは良い習慣ですが。aDockerfileが適切に記述されている場合、小さな構成変更の再構築にそれほど時間はかからないことがよくあります。しかし、それはこの範囲外の別のトピックです。

例を挙げたより詳細な説明

基本的なセットアップCOPYでDockerfile

簡単な例としてDockerfile、nginxウェブサーバーイメージからを作成し、その中にhtmlをコピーします

FROM nginx:alpine
COPY my-html /usr/share/nginx/html

デモコンテンツを含むフォルダを作成しましょう

mkdir my-html
echo "Dockerfile content" > my-html/index.html

ミニマルを追加します docker-compose.yml

version: '3'
services:
  test:
    build: .

を使用して初めて実行するとdocker-compose up -d、イメージがビルドされ、テストページが提供されます。

root@server2:~/docker-so-example# docker-compose up -d
Creating network "docker-so-example_default" with the default driver
Creating docker-so-example_test_1 ... done

root@server2:~/docker-so-example# curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' docker-so-example_test_1)
Dockerfile content

テストファイルを操作してみましょう。

echo "NEW Modified content" > my-html/index.html

でサーバーをcurl再度要求すると、古い応答が返されます。

root@server2:~/docker-so-example# curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' docker-so-example_test_1)
Dockerfile content

コンテンツを適用するには、再構築が必要です。

docker-compose down && docker-compose up -d --build

これで、変更を確認できます。

root@server2:~/docker-so-example# curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' docker-so-example_test_1)
NEW Modified content

でボリュームを使用する docker-compose

違いを示すために、次のdocker-compose.ymlようにファイルを変更してボリュームを使用します。

version: '3'
services:
  test:
    build: .
    volumes:
      - ./my-html:/usr/share/nginx/html

次に、を使用docker-compose down && docker-compose up -dしてコンテナを再起動し、再試行します。

root@server2:~/docker-so-example# echo "Again changed content" > my-html/index.html
root@server2:~/docker-so-example# curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' docker-so-example_test_1)
NEW Modified content
root@server2:~/docker-so-example# echo "Some content" > my-html/index.html
root@server2:~/docker-so-example# curl $(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' docker-so-example_test_1)
Some content

イメージを再構築しておらず、変更がすぐに適用されることに注意してください。ボリュームを使用すると、ファイルはイメージに含まれません。