Added Tag command to build multiple tagged images in one Dockerfile

[drewcsillag]

No description provided.

[vieux]

ping @shykes

[vieux]

@drewcsillag could you please rebase master ? Thanks

[drewcsillag]

@vieux Rebased

[creack]

The thing is that Dockerfiles are meant to be shared. Having a hardcoded tag will result in conflict. It might override local tags, it needs to be retagged in order to be pushed, etc..

Maybe we can prepend the user's login to the tag?
Also, it might be a bit outside the scope but it would be nice to have docker display all the resulting images ID and tags after the build.

[drewcsillag]

On Thu 22 Aug 2013 01:45:07 PM EDT, Guillaume J. Charmes wrote:

The thing is that Dockerfiles are meant to be shared.

But there are a ton of situations where they won't be shared and/or
only pushed to private registries and having this kind of thing is
super useful. For example:

FROM company-base-image
RUN ...
....
TAG company-daemon:base

FROM company-daemon:base
ADD env-specific-config
TAG company-daemon:dev

FROM company-daemon:base
ADD us-datacenter-specific-config
TAG company-daemon:prod-us-dc

FROM company-daemon:base
ADD eu-datacenter-specific-config
TAG company-daemon:prod-eu-dc

I have and can continue to do external tooling for this, but this is a
lot cleaner and more straightforward to be able to do it in the
Dockerfile itself.

I would posit that those who wish to share their Dockerfiles can simply
choose not to use this command -- maybe some mention in the doc might
be helpful in this direction. Sorta like how people who wish to share
Makefiles stick to things that everyone has/is likely to have.

Having a
hardcoded tag will result in conflict. It might override local tags,
it needs to be retagged in order to be pushed, etc..

Maybe we can prepend the user's login to the tag?
Also, it might be a bit outside the scope but it would be nice to have
docker display all the resulting images ID and tags after the build.

—
Reply to this email directly or view it on GitHub
#1618 (comment).

[drewcsillag]

ping @shykes @crosbymichael

[crosbymichael]

I think the pros outweigh the cons.

@shykes Any thoughts? I know we turned down TAG in the Dockerfile once before because of the reasons that @creack discussed but I think this is useful for internal deployments and are not meant to be published online.

LGTM

[drewcsillag]

ping @shykes

[tianon]

For the curious, the original discussion is in #886. As a quick summary of the conclusion, it ended being closed based on the issue of nefarious Dockerfiles being able to overwrite important base images trivially, such as the official ubuntu images. To quote @shykes from that thread:

I agree that we're missing a few things in the naming system, and letting image authors influence the naming is necessary. This will be addressed in the 1.0 api. Part of the answer is to allow for nested naming, so that a Dockerfile can set names relative to its scope.

Perhaps as a temporary stopgap, it could be helpful to have a "pedantic" flag for docker build that disallows use of potentially dangerous commands such as TAG?

[drewcsillag]

Rebased per request.

[drewcsillag]

@tianon I'm thinking the other direction, that perhaps we could have an "allow potentially dangerous" flag. I'll work on it and add it to this PR.

[drewcsillag]

ping @shykes

[drewcsillag]

ping @shykes @crosbymichael @creack

[drewcsillag]

Hold up. Rebase required.....

[drewcsillag]

Ok, bunch of rebase-merge screwup fixed. @shykes @crosbymichael @creack

[vieux]

could you add some documentation on the new flag ? (at least update the usage)

[drewcsillag]

@vieux Done.

[shykes]

"Only for internal deployments" is not good enough, if it's available people will use it, including for public images. Just like "expose 80:80", it ended up causing more trouble than it solved.

I can't merge this until we have an acceptable solution to the side effect. 

—
@solomonstre
@getdocker

On Fri, Sep 20, 2013 at 9:02 AM, Drew Csillag notifications@github.com
wrote:

@vieux Done.

Reply to this email directly or view it on GitHub:
#1618 (comment)

[jamtur01]

I am afraid I rather dislike this idea. :( I feel like it pollutes the Dockerfile concept and that hardcoded TAGs will just end with conflicts and confusion. -1 to merge.

[EvanKrall]

My use case seems similar to @drewcsillag's.

I'd like to deploy services inside containers, and also use containers to manage build dependencies. I'd like to avoid deploying the build-only dependencies to production.

As an example, my service may need gcc to compile, but I don't need gcc on my production machines.

I can think of two ways to accomplish this: a TAG instruction, like discussed here, or extending the FROM command to support paths to other Dockerfiles.

TAG instruction

In the first example, I may have a Dockerfile that looks something like this:

FROM baseimage
RUN apt-get install apache2
RUN apt-get install libjpeg
TAG servicebase

FROM servicebase
RUN apt-get install gcc
RUN apt-get install make
VOLUME /myservice
TAG build

FROM servicebase
ADD . /myservice
TAG production

Then I could docker run -v $PWD:/source build make to compile my code.

Relative FROM command

I could create 3 Dockerfiles:

# Dockerfile.base
FROM baseimage
RUN apt-get install apache2
RUN apt-get install libjpeg

# Dockerfile.build
FROM ./Dockerfile.base
RUN apt-get install gcc
RUN apt-get install make
VOLUME /myservice

# Dockerfile.deploy
FROM ./Dockerfile.base
ADD . /myservice

Essentially, any way to go back and branch off an older state, without explicitly tagging it or pushing it to a registry, would be very helpful.

[gabrtv]

I've spoken with @shykes and @creack about this. The consensus was that:

1. TAG should become a new instruction
2. We should allow multiple TAGs within a single Dockerfile to facilitate building sub-images from a base image

From what I can tell this is essentially what @EvanKrall outlined in TAG Instruction: #1618 (comment) Ideally we would tackle the new TAG syntax in one PR, then the sub-image (FROM baseimage) in another PR.

@drewcsillag thoughts?

[creack]

@gabrtv The TAG should actually be a tag, not a repo name. We should revise the wording, tag is confusing.
when we run docker build -t name ., We create an image within the repository name with the tag latest.
TAG should not create a new repository but a new tag. When there is no -t set, we should automatically name the repository with something like build-xx. That way, it will be much easier to cleanup and see what images have been built with docker build instead of having only anonymous images.

[tianon]

So in the context of what @creack has clarified, it might make sense to add some kind of syntax like FROM :tag to imply that we want the following commands to be based on a tag from the current repo.

[crosbymichael]

@drewcsillag

I think this can be closed in favor of the PR that @gabrtv will be completing this using the -t option and applying actual tags to the resulting images. I think the result will work for everyone.

Thanks!