How to include files outside of Docker's build context?

Question

How can I include files from outside of Docker\'s build context using the \"ADD\" command in the Docker file?

From the Docker documentation:

T

Answer 1

I spent a good time trying to figure out a good pattern and how to better explain what's going on with this feature support. I realized that the best way to explain it was as follows...

• Dockerfile: Will only see files under its own relative path
• Context: a place in "space" where the files you want to share and your Dockerfile will be copied to

So, with that said, here's an example of the Dockerfile that needs to reuse a file called start.sh

Dockerfile

It ALWAYS will load from its relative path, having the current dir of itself as the local reference to the paths you specify.

COPY start.sh /runtime/start.sh

Files

Considering this idea, we can think of having multiple copies for the Dockerfiles building specific things, but they all need access to the start.sh.

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

Considering this structure and the files above, here's a docker-compose.yml

docker-compose.yaml

• In this example, your shared context dir is the runtime dir.
  • Same mental model here, think that all the files under this dir are moved over to the so-called context.
  • Similarly, just specify the Dockerfile that you want to copy to that same dir. You can specify that using dockerfile.
• the directory where your main content is located is the actual context to be set.

The docker-compose.yml is as follows

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 is set as the context, the shared file start.sh is copied there as well the Dockerfile specified by each dockerfile.
• Each gets to be built their own way, sharing the start file!

Cheers!

Answer 2

I had this same issue with a project and some data files that I wasn't able to move inside the repo context for HIPAA reasons. I ended up using 2 Dockerfiles. One builds the main application without the stuff I needed outside the container and publishes that to internal repo. Then a second dockerfile pulls that image and adds the data and creates a new image which is then deployed and never stored anywhere. Not ideal, but it worked for my purposes of keeping sensitive information out of the repo.