Allow specifying of a dockerfile as a path, not piping in.

[peterbraden]

Would be nice to be able to specify docker build -t my/thing -f my-dockerfile . so I could ADD files, and also have multiple dockerfiles.

[SvenDowideit]

I was just looking into this

Usage: docker build [OPTIONS] PATH | URL | -

so if you run

docker build -t my/thing my-dockerfile

complains about the tar file being too short.

It seems to me that the 'PATH' option isn't doccoed, so it might have some legacy meaning?

So - I wonder if detecting if PATH isa file, and is not a Tarfile.

personally, I have a set of Dockerfiles that I use to test, and would much rather have them all in one directory and also have a full context.

[tianon]

That PATH refers to a directory, not a specific Dockerfile.

[SvenDowideit]

oh, and then Tars that directory up to send to the server - cool!

so its possible to detect isafile, Tar up the dir its in, and then replace the Dockerfile in that tarball with the specified file.

or to use -f in the same way - allowing your Dockerfile definitions to live separately from the payload

now to work out how the tests work, try it out and see if it works for me

[peterbraden]

It doesn't tar anything up - the PATH is a directory in which it assumes there is a Dockerfile

[SvenDowideit]

thats not all it does with that PATH - reading the code, the 'context' is sent to the server by taring up the directory.

(ok, so i still don't know go, and i've only been reading the code for the last few minutes, so take it with a grain of skepticism )

[tianon]

Correct, so any nonremote files referenced via ADD must also be in that same directory or the daemon won't be able to access them.

[peterbraden]

Ah, I see what you're saying - yes - that's exactly what I want - a way to specify a dockerfile with -f, and then the directory PATH that might be separate.

so I could have:

docker build -t my/thing fooproj
docker build -t my/thing -f debug-dockerfile fooproj

[SvenDowideit]

#2108 (adding an include directive to Dockerfiles) adds an interesting wrinkle

should the include be relative to the specified dockerfile, or the PATH. not important yet though.

fun:

docker build -t my/thing fooproj
docker build -t my/thing -f ../../debug-dockerfile fooproj
docker build -t my/thing -f /opt/someproject/dockerfiles/debug-dockerfile fooproj

[SvenDowideit]

as extra bonus - there are no CmdBuild tests yet, so guess what I get to learn on first :)

[peterbraden]

@SvenDowideit are you working on this? I was thinking of maybe hacking on it today

[SvenDowideit]

I'm slowly getting myself familiar with the code and go, so go for it - I'm having too much fun just writing the unit tests (perhaps you can use the testing commits to help :)

[peterbraden]

I will do :)

[codeaholics]

I would like to see this functionality too. We have a system which can run in 3 different modes and we'd like to deploy 3 different containers -- 1 for each mode. That means 3 virtually identical docker files with just the CMD being different. But because of the paths only being directories, and the directories being the context for ADD commands, I cannot get this to work right now.

So: +1 from me!

[gabrtv]

Seems like this may have the same end goal as #1618 (though with different approaches). The idea there is to use a single Dockerfile with multiple TAG instructions that result in multiple images, versus multiple Dockerfiles and an include system as outlined here. Thoughts?

[peterbraden]

It seems as though if you can pipe a Dockerfile in, you should be able to specify a path as well. Interested to see what comes of #1618 but I think this offers many more possibilities.

[peterbraden]

This is where I'm at: https://github.com/peterbraden/docker/compare/2112-specify-dockerfile?expand=1

[dregin]

I was thrown by the fact that the documentation doesn't state clearly that the directory containing the Dockerfile is the build context - I made the wrong assumption that the build context was the current working directory, so if I passed a path to the Docerfile instead of it being in the current directory, files I tried to ADD from the current working directory bombed out with "no such file or directory" errors.

[bscott]

I'm getting the same error, Any Ideas

docker build Dockerfile

---

Uploading context

2013/12/11 21:52:32 Error: Error build: Tarball too short

[tianon]

@bscott try docker build . instead. Build takes a directory, not a file, and that's the "build context". :)

[bscott]

Worked Thx!, I just would like to choose between different Docker files.

[thedeeno]

+1 from me.

I need to create multiple images from my source. Each image is a separate concern that needs the same context to be built. Polluting a single Dockerfile (as suggested in #1618) is wonky. It'd be much cleaner for me to keep 3 separate <image-name>.docker files in my source.

I'd love to see something like this implemented.

[thedeeno]

This is more difficult to implement than it would at first seem. It appears that ./Dockerfile is pretty baked in. After initial investigation at least these files are involved:

api/client.go
archive/archive.go
buildfile.go
server.go

The client uses archive to tar build context and send it to the server which then uses archive to untar build context and hand the bytes off to buildfile.

The easiest implementation seems like it'd involve changing client and archive to overwrite the tar's ./Dockerfile with the file specified via this option. I'll investigate further.

[crosbymichael]

@thedeeno I'll take a look really quick and show you were the change should be made. I think it is only in one place.

[jakehow]

@itsafire everyone with this issue who has solved it is already using some sort of preprocessor or wrapper around docker build to achieve this goal.

The fragmentation around this situation is in conflict with the @docker team's stated goal of 'repeatability'. This discussion and the others are about resolving this issue.

[unleashed]

1+ year and 130+ comments and counting for a simple issue affecting most of the users... I'm impressed. Keep up the good work, Docker!

[zedtux]

+1

[farwayer]

Tools should help people to follow their own way, but not to impose the "right" way. A simple case that brought me to this discussion:

`-- project
     |-- deploy
     |    |-- .dockerignore
     |    |-- Dockerfile
     |    ...
     `-- src

My way is to keep project root clean. But ADD ../src and -f deploy/Dockerfile doesn't work. For now I have Dockerfile and .dockerignore in project root, but it is pain for me.

[zedtux]

On my side I have built a script which prepare a folder with the required files and execute the standard command line docker build -t my/image . as I have encountered the issue that the .dockerignore file is ignored by the ADD...

[joegoggins]

+1 sure would like to be able to have multiple Dockerfiles in a single repo. My use case: One image is for production use and deployment, another image is a reporting instance designed to use the same backend tools and database connectivity, but requires no front-end, web, system service, or process supervision...

[sporto]

+1 for this. I need to add files to different images from the same folder, for different servers.

[jfgreen]

+1 I'm enjoying Docker so far, but due to they way my team i setup I really need a way of building different deployables that share a good chunk of code, from one repo. Not particularly keen to build them all into an uberdocker container as then their deployment/release cycles are needlessly tied together. What's the best practice for getting round this?

[ShawnMilo]

@jfgreen: Put multiple Dockerfiles wherever you like, and name them whatever you like. Then have a bash script that copies them one at a time to the repo root as "./Dockerfile," runs "docker build," then deletes them. That's what I do for multiple projects and it works perfectly. I have a "dockerfiles" folder containing files named things like database, base, tests, etc. which are all Dockerfiles.

[jfgreen]

@ShawnMilo Thanks, that seems like a very reasonable workaround.

[andrewcstewart]

+1

[galo]

+1

[metcalfc]

+1 to a -f. There is a sane default which if the flag is omitted Docker will do the right thing. In the case that for whatever reason the very specific view of the right thing is for a user the wrong thing there is -f. Above comparisons to tools like make I think are reasonable. make is also a very opinionated utility originally written in 1976 and as such its had a reasonable amount of time to stabilize a feature set. I think its instructive that in man make the only flag that gets a mention in the very brief synopsis is... -f.

       make [ -f makefile ] [ options ] ... [ targets ] ...

There is no problem in opinionated, ux centered utilities, but some things likes like -f are pragmatic nods to the real world users live in. A tool should make your life easier not harder. If I have to write a Makefile or a shell script to work around a tool without a -f thats a failure of the tool. Clearly from the number of users that have taken the time to comment and weighed in to +1 the feature has significant utility even a year after it was initially proposed.

[aalexgabi]

+1

[rehanift]

+1 (or an official blog post with the recommended workaround)

[martinraison]

+1

[rokcarl]

+1

[duglin]

@crosbymichael I believe this can be closed now due to #9707 being merged

[crosbymichael]

VICTORY.

If you all want to try this new feature out you can download the binaries for master on:

master.dockerproject.com

[crosbymichael]

Thanks @duglin !

[jakehow]

👏

[zedtux]

Thank you @crosbymichael for the binary ! 👍

[palladius]

Well done guys! 👏

[olalonde]

So it's docker build -f Dockerfile.dev .? edit: yep