How can I include files from outside of Docker's build context using the "ADD" command in the Docker file?
From the Docker documentation:
The path must be inside the context of the build; you cannot ADD
../something/something, because the first step of a docker build is to
send the context directory (and subdirectories) to the docker daemon.
I do not want to restructure my whole project just to accommodate Docker in this matter. I want to keep all my Docker files in the same sub-directory.
Also, it appears Docker does not yet (and may not ever) support symlinks: Dockerfile ADD command does not follow symlinks on host #1676.
The only other thing I can think of is to include a pre-build step to copy the files into the Docker build context (and configure my version control to ignore those files). Is there a better workaround for than that?
The best way to work around this is to specify the Dockerfile independently of the build context, using -f.
For instance, this command will give the ADD command access to anything in your current directory.
docker build -f docker-files/Dockerfile .
Update: Docker now allows having the Dockerfile outside the build context (fixed in 18.03.0-ce). So you can also do something like
docker build -f ../Dockerfile .
I often find myself utilizing the --build-arg option for this purpose. For example after putting the following in the Dockerfile:
ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa
You can just do:
docker build -t some-app --build-arg SSH_KEY="$(cat ~/file/outside/build/context/id_rsa)" .
But note the following warning from the Docker documentation:
Warning: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.
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!
On Linux you can mount other directories instead of symlinking them
mount --bind olddir newdir
See https://superuser.com/questions/842642 for more details.
I don't know if something similar is available for other OSes.
I also tried using Samba to share a folder and remount it into the Docker context which worked as well.
If you read the discussion in the issue 2745 not only docker may never support symlinks they may never support adding files outside your context. Seems to be a design philosophy that files that go into docker build should explicitly be part of its context or be from a URL where it is presumably deployed too with a fixed version so that the build is repeatable with well known URLs or files shipped with the docker container.
I prefer to build from a version controlled source - ie docker build
-t stuff http://my.git.org/repo - otherwise I'm building from some random place with random files.
fundamentally, no.... -- SvenDowideit, Docker Inc
Just my opinion but I think you should restructure to separate out the code and docker repositories. That way the containers can be generic and pull in any version of the code at run time rather than build time.
Alternatively, use docker as your fundamental code deployment artifact and then you put the dockerfile in the root of the code repository. if you go this route probably makes sense to have a parent docker container for more general system level details and a child container for setup specific to your code.
I believe the simpler workaround would be to change the 'context' itself.
So, for example, instead of giving:
docker build -t hello-demo-app .
which sets the current directory as the context, let's say you wanted the parent directory as the context, just use:
docker build -t hello-demo-app ..
You can also create a tarball of what the image needs first and use that as your context.
https://docs.docker.com/engine/reference/commandline/build/#/tarball-contexts
This behavior is given by the context directory that the docker or podman uses to present the files to the build process.
A nice trick here is by changing the context dir during the building instruction to the full path of the directory, that you want to expose to the daemon.
e.g:
docker build -t imageName:tag -f /path/to/the/Dockerfile /mysrc/path
using /mysrc/path instead of .(current directory), you'll be using that directory as a context, so any files under it can be seen by the build process.
This example you'll be exposing the entire /mysrc/path tree to the docker daemon.
When using this with docker the user ID who triggered the build must have recursively read permissions to any single directory or file from the context dir.
This can be useful in cases where you have the /home/user/myCoolProject/Dockerfile but want to bring to this container build context, files that aren't in the same directory.
Here is an example of building using context dir, but this time using podman instead of docker.
Lets take as example, having inside your Dockerfile a COPY or ADDinstruction which is copying files from a directory outside of your project, like:
FROM myImage:tag
...
...
COPY /opt/externalFile ./
ADD /home/user/AnotherProject/anotherExternalFile ./
...
In order to build this, with a container file located in the /home/user/myCoolProject/Dockerfile, just do something like:
cd /home/user/myCoolProject
podman build -t imageName:tag -f Dockefile /
Some known use cases to change the context dir, is when using a container as a toolchain for building your souce code.
e.g:
podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile /tmp/mysrc
or it can be a path relative, like:
podman build --platform linux/s390x -t myimage:mytag -f ./Dockerfile ../../
Another example using this time a global path:
FROM myImage:tag
...
...
COPY externalFile ./
ADD AnotherProject ./
...
Notice that now the full global path for the COPY and ADD is omitted in the Dockerfile command layers.
In this case the contex dir must be relative to where the files are, if both externalFile and AnotherProject are in /opt directory then the context dir for building it must be:
podman build -t imageName:tag -f ./Dockerfile /opt
Note when using COPY or ADD with context dir in docker:
The docker daemon will try to "stream" all the files visible on the context dir tree to the daemon, which can slowdown the build. And requires the user to have recursively permission from the context dir.
This behavior can be more costly specially when using the build through the API. However,with podman the build happens instantaneously, without needing recursively permissions, that's because podman does not enumerate the entire context dir, and doesn't use a client/server architecture as well.
The build for such cases can be way more interesting to use podman instead of docker, when you face such issues using a different context dir.
Some references:
https://docs.docker.com/engine/reference/commandline/build/
https://docs.podman.io/en/latest/markdown/podman-build.1.html
As is described in this GitHub issue the build actually happens in /tmp/docker-12345, so a relative path like ../relative-add/some-file is relative to /tmp/docker-12345. It would thus search for /tmp/relative-add/some-file, which is also shown in the error message.*
It is not allowed to include files from outside the build directory, so this results in the "Forbidden path" message."
Using docker-compose, I accomplished this by creating a service that mounts the volumes that I need and committing the image of the container. Then, in the subsequent service, I rely on the previously committed image, which has all of the data stored at mounted locations. You will then have have to copy these files to their ultimate destination, as host mounted directories do not get committed when running a docker commit command
You don't have to use docker-compose to accomplish this, but it makes life a bit easier
# 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
Create a wrapper docker build shell script that grabs the file then calls docker build then removes the file.
a simple solution not mentioned anywhere here from my quick skim:
have a wrapper script called docker_build.sh
have it create tarballs, copy large files to the current working directory
call docker build
clean up the tarballs, large files, etc
this solution is good because (1.) it doesn't have the security hole from copying in your SSH private key (2.) another solution uses sudo bind so that has another security hole there because it requires root permission to do bind.
I think as of earlier this year a feature was added in buildx to do just this.
If you have dockerfile 1.4+ and buildx 0.8+ you can do something like this
docker buildx build --build-context othersource= ../something/something .
Then in your docker file you can use the from command to add the context
ADD –from=othersource . /stuff
See this related post https://www.docker.com/blog/dockerfiles-now-support-multiple-build-contexts/
Workaround with links:
ln path/to/file/outside/context/file_to_copy ./file_to_copy
On Dockerfile, simply:
COPY file_to_copy /path/to/file
I was personally confused by some answers, so decided to explain it simply.
You should pass the context, you have specified in Dockerfile, to docker when
want to create image.
I always select root of project as the context in Dockerfile.
so for example if you use COPY command like COPY . .
first dot(.) is the context and second dot(.) is container working directory
Assuming the context is project root, dot(.) , and code structure is like this
sample-project/
docker/
Dockerfile
If you want to build image
and your path (the path you run the docker build command) is /full-path/sample-project/,
you should do this
docker build -f docker/Dockerfile .
and if your path is /full-path/sample-project/docker/,
you should do this
docker build -f Dockerfile ../
An easy workaround might be to simply mount the volume (using the -v or --mount flag) to the container when you run it and access the files that way.
example:
docker run -v /path/to/file/on/host:/desired/path/to/file/in/container/ image_name
for more see: https://docs.docker.com/storage/volumes/
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.
In my case, my Dockerfile is written like a template containing placeholders which I'm replacing with real value using my configuration file.
So I couldn't specify this file directly but pipe it into the docker build like this:
sed "s/%email_address%/$EMAIL_ADDRESS/;" ./Dockerfile | docker build -t katzda/bookings:latest . -f -;
But because of the pipe, the COPY command didn't work. But the above way solves it by -f - (explicitly saying file not provided). Doing only - without the -f flag, the context AND the Dockerfile are not provided which is a caveat.
How to share typescript code between two Dockerfiles
I had this same problem, but for sharing files between two typescript projects. Some of the other answers didn't work for me because I needed to preserve the relative import paths between the shared code. I solved it by organizing my code like this:
api/
Dockerfile
src/
models/
index.ts
frontend/
Dockerfile
src/
models/
index.ts
shared/
model1.ts
model2.ts
index.ts
.dockerignore
Note: After extracting the shared code into that top folder, I avoided needing to update the import paths because I updated api/models/index.ts and frontend/models/index.ts to export from shared: (eg export * from '../../../shared)
Since the build context is now one directory higher, I had to make a few additional changes:
Update the build command to use the new context:
docker build -f Dockerfile .. (two dots instead of one)
Use a single .dockerignore at the top level to exclude all node_modules. (eg **/node_modules/**)
Prefix the Dockerfile COPY commands with api/ or frontend/
Copy shared (in addition to api/src or frontend/src)
WORKDIR /usr/src/app
COPY api/package*.json ./ <---- Prefix with api/
RUN npm ci
COPY api/src api/ts*.json ./ <---- Prefix with api/
COPY shared usr/src/shared <---- ADDED
RUN npm run build
This was the easiest way I could send everything to docker, while preserving the relative import paths in both projects. The tricky (annoying) part was all the changes/consequences caused by the build context being up one directory.
One quick and dirty way is to set the build context up as many levels as you need - but this can have consequences.
If you're working in a microservices architecture that looks like this:
./Code/Repo1
./Code/Repo2
...
You can set the build context to the parent Code directory and then access everything, but it turns out that with a large number of repositories, this can result in the build taking a long time.
An example situation could be that another team maintains a database schema in Repo1 and your team's code in Repo2 depends on this. You want to dockerise this dependency with some of your own seed data without worrying about schema changes or polluting the other team's repository (depending on what the changes are you may still have to change your seed data scripts of course)
The second approach is hacky but gets around the issue of long builds:
Create a sh (or ps1) script in ./Code/Repo2 to copy the files you need and invoke the docker commands you want, for example:
#!/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
In the docker-compose file, simply set the context as Repo2 root and use the content of the ./db/schema directory in your dockerfile without worrying about the path.
Bear in mind that you will run the risk of accidentally committing this directory to source control, but scripting cleanup actions should be easy enough.
Related
First of all, I am sorry if I misinterpret what I get, I'm completly new to Docker.
So I'm developping a software to process csv files into a database, and everything runs in GCP. To run my code, I have access to a Cloud Run that can use Docker images.
Today I added 3 new files :
'BusinessLogic/Repository/AcademyRepository.cs'
'BusinessLogic/Repository/Interfaces/ISourceRepository.cs'
'BusinessLogic/Repository/SourceRepository.cs'
Prior to these modifications, I had to run 3 commands to publish my code on the cloud run :
dotnet build
gcloud builds submit --tag gcr.io/myproject/mytag
gcloud run deploy myservice gcr.io/myproject/mytag--platform managed
But since I added these files, I get the following error :
/usr/share/dotnet/sdk/3.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.DefaultItems.targets(295,5): error NETSDK1022: Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'BusinessLogic/Repository/AcademyRepository.cs'; 'BusinessLogic/Repository/Interfaces/ISourceRepository.cs'; 'BusinessLogic/Repository/SourceRepository.cs' [/app/MyProject.csproj]
I saw on multiple threads to check .csproj files for weird ... entries but there was nothing like this in mine.
And here is my dockerfile :
# Use Microsoft's official build .NET image.
# https://hub.docker.com/_/microsoft-dotnet-core-sdk/
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-alpine AS build
WORKDIR /app
# Install production dependencies.
# Copy csproj and restore as distinct layers.
COPY *.csproj ./
RUN dotnet restore
# Copy local code to the container image.
COPY . ./
WORKDIR /app
# Build a release artifact.
RUN dotnet publish -c Release -o out # This step fails
# Use Microsoft's official runtime .NET image.
# https://hub.docker.com/_/microsoft-dotnet-core-aspnet/
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-alpine AS runtime
RUN echo 'http://dl-cdn.alpinelinux.org/alpine/v3.8/main' >> /etc/apk/repositories && apk update --no-cache && apk add --no-cache bash libc6-compat=1.1.19-r11
WORKDIR /app
COPY --from=build /app/out ./
# Run the web service on container startup.
ENTRYPOINT ["dotnet", "MyDll.dll"]
I tried running the command that fails outside of the gcloud builds submit command but nothing wrong happened
If I delete the files and comment the related code, the problem vanishes ... but I kinda need those files
EDIT :
Editing a csproj file from visual studio doesn't show you the actual file, it shows you a modified version. I edited the csproj with notepad, cleaned then recompiled the project but the problem is still here.
Found a workaround :
Here is a part of my architecture :
BusinessLogic
--- Repositories
--- Interface
The problem resides in the "Interface" folder. By deleting it and adding my interfaces in the parent folder (Repositories), the problem disappears. Still no idea how to solve the real problem though
I have two paths. One to take templates from and one to generate documents in.
Deploying this on Docker works fine (the App starts, works and gives no warnings), bind mount creates these 2 directories on my local machine, but doesn't seem to use them, or even create them? on the container.
Here is what I tried:
1) Specified paths in AppSettings.json (this is my configuration without Docker, it will be overridden below in docker-compose file)
"RootDirectoryForDocuments": {
"DocumentsRoot": "TestDocumentsDir",
"TemplatesRoot": "TestTemplatesDir"
}
2) Created Docker Compose File. Here first I'm giving the paths as environment variables and then trying to make the container use them in volumes section:
version: "3.7"
services:
hraapi:
build: ../Hra.Api
environment:
- ASPNETCORE_ENVIRONMENT=Development
- ENV_RootDirectoryForDocuments_DocumentsRoot="/app/GeneratedDocs"
- ENV_RootDirectoryForDocuments_TemplatesRoot="/app/Templates"
image: user/hra.api:v1.0
container_name: hra.api
ports:
- "5000:80"
depends_on:
- hradb
volumes:
- C:/Users/User/Desktop/GeneratedDocs:/app/GeneratedDocs
- C:/Users/User/Desktop/Templates:/app/Templates
When I run this DockerCompose it automatically creates these 2 Folders on my Desktop. However, I was hoping it would create and use them in the Container as well.
I tried a lot to find how ASP.NET Core containers are structured, in order to use an already existing path there but without success.
I'm sorry, I can't comment yet, but here might be solution to your "container hierarchy" problem:
Do this docker works on your local machine? You can log into the working docker container using the id of the container and check exactly what's happening inside on the filesystem.
First, get the docker id:
#> docker ps
Then, using the id (it will look like: ka7859adgfa59)
#> docker exec -it ka7859adgfa59 /bin/bash
you can get inside the container with bash shell.
The "volumes:" part uses the Short Syntax, which should create those folders inside if they are not there already SHORT SYNTAX
In my .net core 2 application, I have files
appsettings.Development.json
appsettings.Staging.json
Application is dockerized and I have a docker-compose.yml with corresponding docker-compose.override.yml.
Inside docker-compose.override.yml I have ports and Staging related things using ENV variables
serviceone:
environment:
- ASPNETCORE_ENVIRONMENT=Staging
- ASPNETCORE_URLS=http://0.0.0.0:5500
ports:
- "5500:5500"
This works perfectly so far, cause I had only one dockerize env (Staging), Development one I use only for debugging locally. Now I want to introduce support for QA by having another docker image for QA.
I'll put appsettings.QA.json in the solution and my question is:
Should I create another docker-compose.overrideSTAGING.yml (or what's the naming convention here) and how will docker-compose know about it's existence?
Currently, I'm using docker-compose up --build from cli
Should I create another docker-compose.overrideSTAGING.yml (or what's the naming convention here) and how will docker-compose know about it's existence?
Compose only includes docker-compose.yml and docker-compose.override.yml files, by default.
You should use the -f option to include files with different names.
See explanation here.
Summary
Having a docker-compose.yml file that builds an image like this:
services:
my-service:
build:
context: My.VS.AppFolder
networks:
- my-docker
networks:
my-docker:
external: true
the defined network is only avaliable in the ENTRYPOINT. But not during build. How can I access another container on the same network my-docker during build of the Dockerfile?
Use case: Fetching NuGet packages from private repo
Description of the use case
I have an ASP.NET Core MVC 2.1 web application. For a better seperation of concerns, I want to implement certain features in another seperated web app (e.g admin interface). To avoid copying shared things like app layout (Razor) or some helper utility classes, I created a shared project for those things.
So there are three projects now:
MyApp (The original application)
MyApp.Core (For shared things)
MyApp.Admin
Since MyApp.Core needs to be referenced from the other projects, I installed BaGet as simple NuGet hosting repo for my docker build environment. This container is internally referenced with it's DNS name in nuget.config, created at solution level of MyApp (same on new MyApp.Admin but let's focus on MyApp for simplicity).
The problems
In the Dockerfile of MyApp I'm doing now this:
RUN dotnet restore --configfile nuget.config
and need to access the dns name called baget on the my-docker network. Researchs show that this is only possible with at least version 3.4 of docker-compose, and seems still not officially documentated. But Docker removed several options from v2 in v3, for example ressource limits like mem_limits I'm using. From v3, they're only avaliable using swarm, not on single nodes any more.
So I currently don't see any solution than migrating to v3 and swarm, which would cause extra work and complexity without benefits other than this networking issue. My project isn't that big that swarm is required.
I found two ways of working around this problem:
Build with docker cli tool instead of docker-compose
Instead of docker-compose up -d --build, I manually build the image using dockers CLI tool because it has a --network switch that allows specifying the network during build:
docker build --network my-docker -t my-service:latest --build-arg ASPNETCORE_ENVIRONMENT=Development My.VS.AppFolder
Now reference this image in docker-compose.yml instead of building it there:
services:
my-service:
image: my-service:latest
After the image was build, run docker-compose up -d without the --build flag. This causes a bit of overhead since you have to CLI calls and for real tagging like alpine-3.2.1, this tag need to be specified with an env variable and passed to both docker/docker-compose. But it seems the best working alternative for productive usage.
Compatibility mode
There is a --compatibility switch in docker-compose since 1.20.0 that allows using the new v3 file version, but map swarm options like ressource limits to the locally v2 form. In other words: You can use specifiy ressources in v3 and they apply on docker-compose when this switch is used. Otherwise, they would be ignored on docker-compose and only have effect with docker stack deploy.
So with this switch, you can profit from the ability of defining a network during build, without loosing ressource limits. But the documentation warns that this is not stable enough for productive usage:
We recommend against using --compatibility mode in production. Because the resulting configuration is only an approximate using non-Swarm mode properties, it may produce unexpected results.
For this reason, I don't consider it as a real solution and use the first approach of building the image using dockers CLI where specifiying a network is possible.
I have ASP.NET MVC application in .NET Core. I run it in Docker using docker-compose.yml and command:
docker-compose up –d
Now I can display my website on http://localhost:5000.
But if I change something in class or cshtml file I don't see those changes on http://localhost:5000. What should I do? Stop container and what next? Or something else?
You should rebuild your container
docker-compose up –d --build
You can rebuild specific containers in docker-compose like this
docker-compose up –d --build service_name_1 service_name_2
from this source https://docs.docker.com/compose/reference/build/
docker-compose build
Estimated reading time: 1 minute
Usage: build [options] [--build-arg key=val...] [SERVICE...]
Options:
--compress Compress the build context using gzip.
--force-rm Always remove intermediate containers.
--no-cache Do not use cache when building the image.
--pull Always attempt to pull a newer version of the image.
-m, --memory MEM Sets memory limit for the build container.
--build-arg key=val Set build-time variables for services.
--parallel Build images in parallel.
Services are built once and then tagged, by default as project_service. For example, composetest_db. If the Compose file specifies an image name, the image is tagged with that name, substituting any variables beforehand. See variable substitution.
If you change a service’s Dockerfile or the contents of its build directory, run docker-compose build to rebuild it.