Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Dockerfile ADD command does not follow symlinks on host #1676
Docker version 0.6.1. Tested on ubuntu.
I have a Dockerfile with the following statement:
ADD my-archive.tar.gz /archive/my-archive.tar.gz
where my-archive.tar.gz is a symlink from the build directory on the host system to a valid and readable my-archive.tar.gz archive. The /archive path on the destination/container exists.
If my-archive.tar.gz is a hardlink things work just fine.
Symlinking is common practice when joining up resources on the filesystem for a build, and as such should be followed.
@sgargan We do not allow this because it's not repeatable. A symlink on your machine is the not the same as my machine and the same Dockerfile would produce two different results. Also having symlinks to /etc/paasswd would cause issues because it would link the host files and not your local files.
I'm definitely not advocating symlinking to a file on the host. Really what I'm talking about is adding the contents of a symlink'd file in the build to a concrete path in the image. I typically have all my docker/devops files in a git repo with relative path symlinks where needed so I'm not repeating myself. If you have a clone of the repo, you have the symlink too, so in this case the symlinks are same on all machines. I'd like to be able to use ADD to pull the contents of a file symlink'd next to the docker file and write the contents into the image not the symlink.
Then in the docker file
add somecommon /etc/concrete_somecommon
after which /etc/concrete_somecommon would be a normal file with the contents of the file symlink'd in the build folder.
I would definitely find it useful to enable this even if it came with a warning that its against the general accepted practice.
Does this sound unreasonable? am I missing something?
The solution to that is going to be Dockerfile dependency. For example, you'll have many subdirectories that each contain Dockerfiles that may or may not depend on each other or on a common directory (like a common library of code). There will then be a Dockerfile at the root (common) level that handles the "orchestration" of building these sub-Dockerfiles correctly with the common context that they need.
@tianon recursive Dockerfiles are cool! But, forced recursive Dockerfiles aren't. Look into the mess that recursive Makefiles can create.
More importantly, this is does not solve the problem-- not even remotely. Projects have very particular directory structures, often imposed by a variety of organizational, cultural, and even system constraints. These structures are blown up dramatically when considering how companies handle their own vm images and provisioning. Things like configuration files, auth keys, etc are distributed independently of the source code itself, and often referenced or symlinked in. These things are not in the same repository, and often not even handled by the same engineers. Docker forcing a particular directory structure, makes it cumbersome to use and a pain to work with. This is not the usual Docker smart systems design we're used to. Symlinks are really just files, for good reason. Docker should treat them so, just like tar, and all sorts of file distribution tools do.
Well this is an issue for me too for other reasons, it happens I have a project stored with git-annex so it is symlinks everywhere, I already workaround it with a small script that echoes those back to real files but I would love to be able to pass a flag to the docker build command like