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 will always load from its relative path, having the current directory 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 directory is the runtime directory.
  • Same mental model here, think that all the files under this directory are moved over to the so-called context.
  • Similarly, just specify the Dockerfile that you want to copy to that same directory. 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!