Dockerファイルの「ADD」コマンドを使用して、Dockerのビルドコンテキスト外のファイルを含めるにはどうすればよいですか？

Dockerドキュメントから：

パスはビルドのコンテキスト内にある必要があります。../something/somethingを追加することはできません。Dockerビルドの最初のステップは、コンテキストディレクトリ（およびサブディレクトリ）をdockerデーモンに送信することです。

この問題でDockerに対応するためだけにプロジェクト全体を再構築したくありません。すべてのDockerファイルを同じサブディレクトリに保持したい。

また、Dockerはまだシンボリックリンクをサポートしていないようです（今後もサポートしない可能性があります）。DockerfileADDコマンドは、ホスト＃1676のシンボリックリンクをたどりません。

他に考えられる唯一のことは、ファイルをDockerビルドコンテキストにコピーするための事前ビルドステップを含めることです（そして、それらのファイルを無視するようにバージョンコントロールを構成します）。それよりも良い回避策はありますか？

これを回避する最善の方法は、-fを使用して、ビルドコンテキストとは無関係にDockerfileを指定することです。

たとえば、このコマンドはADDコマンドに現在のディレクトリ内のあらゆるものへのアクセスを許可します。

docker build -f docker-files/Dockerfile .

更新：DockerはDockerfileをビルドコンテキストの外に置くことができるようになりました（18.03.0-ce、https： //github.com/docker/cli/pull/886で修正）。したがって、次のようなこともできます

docker build -f ../Dockerfile .

--build-argこの目的でオプションを利用していることがよくあります。たとえば、Dockerfileに次のように入力した後：

ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa

あなたはただ行うことができます：

docker build -t some-app --build-arg SSH_KEY="$(cat ~/file/outside/build/context/id_rsa)" .

ただし、Dockerドキュメントの次の警告に注意してください。

警告：githubキー、ユーザー認証情報などのシークレットを渡すためにビルド時変数を使用することはお勧めしません。ビルド時変数の値は、docker historyコマンドを使用してイメージのすべてのユーザーに表示されます。

Linuxでは、他のディレクトリをシンボリックリンクする代わりにマウントできます

mount --bind olddir newdir

詳細については、https：//superuser.com/questions/842642を参照してください。

他のOSで同様のものが利用できるかどうかはわかりません。また、Sambaを使用してフォルダーを共有し、それをDockerコンテキストに再マウントしてみたところ、同様に機能しました。

私は良いパターンを見つけ、この機能のサポートで何が起こっているかをよりよく説明する方法を見つけるために良い時間を費やしました。それを説明する最良の方法は次のとおりであることがわかりました...

• Dockerfile：独自の相対パスにあるファイルのみを表示します
• コンテキスト：共有するファイルとDockerfileがコピーされる「スペース」内の場所

ということで、これがDockerfileの例です。 start.sh

Dockerfile

これはALWAYS、自身の現在のディレクトリを有し、その相対パスからロードされlocal、指定したパスを参照します。

COPY start.sh /runtime/start.sh

ファイル

このアイデアを考えると、Dockerfileの複数のコピーで特定のものを構築することを考えることができますが、すべてにへのアクセスが必要ですstart.sh。

./all-services/
   /start.sh
   /service-X/Dockerfile
   /service-Y/Dockerfile
   /service-Z/Dockerfile
./docker-compose.yaml

この構造と上記のファイルを考慮して、ここにdocker-compose.ymlがあります

docker-compose.yaml

• この例では、sharedコンテキストdirはruntimedirです。
  • ここでも同じメンタルモデルです。このdirの下にあるすべてのファイルが、いわゆるに移動されると考えてくださいcontext。
  • 同様に、同じディレクトリにコピーするDockerfileを指定するだけです。を使用して指定できますdockerfile。
• メインコンテンツが配置されているディレクトリは、設定される実際のコンテキストです。

docker-compose.yml次のようです

version: "3.3"
services:

  service-A
    build:
      context: ./all-service
      dockerfile: ./service-A/Dockerfile

  service-B
    build:
      context: ./all-service
      dockerfile: ./service-B/Dockerfile

  service-C
    build:
      context: ./all-service
      dockerfile: ./service-C/Dockerfile

• all-serviceがコンテキストとして設定されている場合、共有ファイルstart.shがそこにコピーされ、それぞれで指定されたDockerfileもコピーされますdockerfile。
• それぞれが独自の方法で構築され、開始ファイルを共有します！

乾杯！

問題2745の説明を読むと、Dockerがシンボリックリンクをサポートできないだけでなく、コンテキスト外でのファイルの追加をサポートできない可能性があります。Dockerビルドに入るファイルは明示的にそのコンテキストの一部であるか、おそらく固定バージョンでもデプロイされているURLからのものでなければならないという設計哲学のようですDockerコンテナ。

私はバージョン管理されたソース（つまりdocker build -t stuff http://my.git.org/repo）からビルドすることを好みます。それ以外の場合は、ランダムファイルのあるランダムな場所からビルドします。

基本的には違います...-SvenDowideit、Docker Inc

私の意見だけですが、コードとドッカーのリポジトリを分離するために再構築する必要があると思います。そうすることで、コンテナーを汎用的にして、ビルド時ではなく実行時にコードの任意のバージョンを取り込むことができます。

または、基本的なコードデプロイメントアーティファクトとしてdockerを使用してから、dockerfileをコードリポジトリのルートに配置します。この方法を使用する場合、より一般的なシステムレベルの詳細には親のDockerコンテナーを、コードに固有の設定には子のコンテナーを使用するのが理にかなっています。

より簡単な回避策は、「コンテキスト」自体を変更することだと思います。

したがって、たとえば、次のようにする代わりに：

docker build -t hello-demo-app .

これは、現在のディレクトリをコンテキストとして設定します。たとえば、親ディレクトリをコンテキストとして使用するには、次のように使用します。

docker build -t hello-demo-app ..

画像が最初に必要とするもののtarballを作成し、それをコンテキストとして使用することもできます。

https://docs.docker.com/engine/reference/commandline/build/#/tarball-contexts

docker-composeを使用して、必要なボリュームをマウントするサービスを作成し、コンテナーのイメージをコミットすることでこれを実現しました。次に、後続のサービスでは、マウントされた場所にすべてのデータが保存されている、以前にコミットされたイメージを使用します。docker commitコマンドを実行するとホストにマウントされたディレクトリはコミットされないため、これらのファイルを最終的な宛先にコピーする必要があります。

これを達成するためにdocker-composeを使用する必要はありませんが、これにより生活が少し簡単になります

# docker-compose.yml

version: '3'
  services:
    stage:
      image: alpine
      volumes:
        - /host/machine/path:/tmp/container/path
      command: bash -c "cp -r /tmp/container/path /final/container/path"
    setup:
      image: stage

# setup.sh

# Start "stage" service
docker-compose up stage

# Commit changes to an image named "stage"
docker commit $(docker-compose ps -q stage) stage

# Start setup service off of stage image
docker-compose up setup

HIPPAの理由で、プロジェクトと一部のデータファイルで同じ問題があり、リポジトリコンテキスト内で移動できませんでした。2つのDockerfileを使用することになりました。1つは、コンテナーの外で必要なものなしでメインアプリケーションをビルドし、それを内部リポジトリーに公開します。次に、2番目のdockerfileがそのイメージをプルしてデータを追加し、新しいイメージを作成します。このイメージは、展開され、どこにも保存されません。理想的ではありませんが、機密情報をリポジトリから除外するという私の目的には役立ちました。

簡単な回避策としては、実行時にボリュームを（-vまたは--mountフラグを使用して）コンテナーにマウントし、その方法でファイルにアクセスするだけです。

例：

docker run -v /path/to/file/on/host:/desired/path/to/file/in/container/ image_name

詳細については、https：//docs.docker.com/storage/volumes/を参照してください。

この GitHubの問題で説明されているように、ビルドは実際には/tmp/docker-12345で行われるため、などの相対パス../relative-add/some-fileはに相対的/tmp/docker-12345です。したがって/tmp/relative-add/some-file、エラーメッセージにも表示されるを検索します。*

ビルドディレクトリの外からのファイルのインクルードは許可されていないため、「禁止されたパス」というメッセージが表示されます。」

すばやく簡単な方法の1つは、ビルドコンテキストを必要なだけ多くのレベルに設定することですが、これにより結果が生じる可能性があります。次のようなマイクロサービスアーキテクチャで作業している場合：

./Code/Repo1
./Code/Repo2
...

ビルドコンテキストを親Codeディレクトリに設定してすべてにアクセスできますが、多数のリポジトリがあると、ビルドに時間がかかることがわかります。

状況の例として、別のチームがデータベーススキーマを保持しRepo1ていて、チームのコードがRepo2これに依存している場合があります。スキーマの変更を心配したり、他のチームのリポジトリを汚染したりせずに、この依存関係を独自のシードデータの一部とドッキングしたい場合（変更内容によっては、シードデータスクリプトを変更する必要がある場合もあります）2番目のアプローチはハッキーですがロングビルドの問題を回避します：

でsh（またはps1）スクリプト./Code/Repo2を作成して、必要なファイルをコピーし、必要なdocker コマンドを呼び出します。次に例を示します。

#!/bin/bash
rm -r ./db/schema
mkdir ./db/schema

cp  -r ../Repo1/db/schema ./db/schema

docker-compose -f docker-compose.yml down
docker container prune -f
docker-compose -f docker-compose.yml up --build

docker-composeファイルで、コンテキストをRepo2ルートとして設定し./db/schema、パスを気にせずにdockerfile のディレクトリのコンテンツを使用します。このディレクトリを誤ってソース管理にコミットするリスクを負うことになりますが、クリーンアップアクションのスクリプトは十分簡単である必要があります。

私の場合、私のDockerfileは、構成ファイルを使用して実際の値に置き換えるプレースホルダーを含むテンプレートのように記述されています。

したがって、このファイルを直接指定することはできませんでしたが、次のようにそれをdockerビルドにパイプします。

sed "s/%email_address%/$EMAIL_ADDRESS/;" ./Dockerfile | docker build -t katzda/bookings:latest . -f -;

しかし、パイプが原因で、COPYコマンドは機能しませんでした。しかし、上記の方法はそれを解決し-f -ます（明示的にファイルが提供されていないと言っています）。フラグ-なしで行うだけ-fで、コンテキストとDockerfileは提供されません。これは警告です。

トリックは、Dockerパスを指定した場合、ビルドコマンドでコンテキストを指定して親ディレクトリのファイルを含めることができることを認識することです。Dockerfileを次のように変更します。

...
COPY ./ /dest/
...

次に、ビルドコマンドは次のようになります。

docker built -t TAG -f DOCKER_FILE_PATH CONTEXT

プロジェクトディレクトリから

docker built -t username/project[:tag] -f ./docker/Dockerfile .

プロジェクト/ドッカーから

docker built -t username/project[:tag] -f ./docker/Dockerfile ..