Support for explicit container names

[prologic]

Hi, Before I submit a PR for this I wanted to gauge the reaction/feedback first.

See: https://github.com/therealprologic/fig/commit/1653955606881c9d9268cfcf8044cfde01128b1c

This adds optional explicit container names to fig. Use-case:

autodock:
    image: prologic/autodock
    name: autodock
    ports:
        - 1338:1338
    volumes:
        - /var/run/docker.sock:/var/run/docker.sock

hipache:
    image: hipache
    name: hipache
    ports:
        - 80:80
        - 443:443

[thaJeztah]

Could you give an example what the resulting containers would be named like? project_hipache_1? hipache_1? Or just hipache?

Also, can you give a use case to explain when this is more helpful than renaming the service itself?

No negative comments I just couldn't grasp that from your example alone :)

[prologic]

Sure that's why I asked for feedback :)

Okay so the container names would be automagically generated normally unless name is in the service spec. So if you have a service spec of:

service:
    image: my_image
    name: my_name

Then service would have a name of "my_service" and appear so in a docker ps

The use-case for all this is to "fig up" some pieces of infrastructure and be able to reference container names by their canonical name rather than <project>_<service>_<suffix>.

[thaJeztah]

Doesn't fig (currently) rely heavily on the project_ prefix to find the containers? (wondering).

Would that cope well with scaling? A _2 suffix is still added when scaling > 1, but no suffix for the first instance?

[prologic]

With what I've done so far (minus a minor issue with fig ps);

Links and Volumes-From will (and do) work just fine if you explicitly give a service a "container name" via name. However; scaling of such services will not work of course. So one would not do this for their "web" service for instance.

OTOH this is really meant for outside use of fig as an orchestration tool where one can fig up a bunch of infrastructural containers with explicit names and still fig up various projects with auto-generated names.

[thaJeztah]

All right then, clear :)

Probably useful too to fig-up and "include" some existing containers in your fig project.

So, yeah, I see some useful stuff in there, but also think containers generated with a custom name will act different than the other services. Which is fine, if you're aware of that, but does require proper documentation to explain to users.

So, I guess it's up to the maintainers :)

[prologic]

Cool then I'll fix up some other minor issues, write docs and submit a PR
closing this issue
On Nov 18, 2014 7:25 AM, "Sebastiaan van Stijn" notifications@github.com
wrote:

All right then, clear :)

Probably useful too to fig-up and "include" some existing containers in
your fig project.

So, yeah, I see some useful stuff in there, but also think containers
generated with a custom name will act different than the other
services. Which is fine, if you're aware of that, but does require proper
documentation to explain to users.

So, I guess it's up to the maintainers :)

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

[thaJeztah]

Perhaps see what others think of it as well?

[prologic]

Sure :) I still need to do more testing and tidying up...
On Nov 18, 2014 7:35 AM, "Sebastiaan van Stijn" notifications@github.com
wrote:

Perhaps see what others think of it as well?

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

[totallymike]

Personally I'd like to see this. I use fig as my development environment for a number of projects, and it'd be nice to let each one of the do:

db:
  image: postgres:9.3.5
  name: pg

so they can share a database instance (and, more importantly, volume). As long as the database names don't collide, this would be lovely for me.

Furthermore, it could be useful for a shared ruby gems volume, among other things.

[prologic]

Glad I'm not the only one :) I'll try and clean up the patches adn submit a proper PR soon. Anyone else want this? :)

[nizsheanez]

me +1.
I think it useful for containers without daemons, which i usually use for package managers - bower, npm, composer.
And i just create container like:
docker run -dt --name=js -v $(pwd):/app dockerfile/nodejs-bower-gulp
and then run commands inside this container:
docker exec -it js bash -c "bower update"

[kcmerrill]

+1 for explicit container names!

[hadim]

+1

[aanand]

This would be good, particularly the sharing use-case. fig scale would need to exit with a helpful error.

Off the top of my head I'm not sure how much of an ordeal this would be to implement, but once labels are in Docker and we're no longer relying on names (moby/moby#9882), it'll be a lot easier.

[funkyfuture]

@therealprologic i haven't tried your commits yet (propably tomorrow), but is there anything i can help you with to make it PR-ready?

[baptistedonaux]

+1

[frankscholten]

+1

[MrMMorris]

+1!

I was trying to have one of our developers run compose and it broke because their root dir name is different than mine

[thaJeztah]

Happy to inform that support for labels (moby/moby#9882) was merged and will be included in the upcoming 1.6 release of Docker.

Also, I think there are currently a number of related issues in this area (#652, #869, #941 among others); perhaps the discussion should be focussed on the global proposal #1066 (but that's just a suggestion)

[kcmerrill]

I've read and re-read the proposal but I don't understand how adding labels allows one to customize explicitly the container name?

If anybody has any additional insight they'd be willing to share I'd love additional information. For me, explicit container names in docker-compose/fig are essential to using reverse proxies based on container names.

[thaJeztah]

@kcmerrill Right now, Compose uses a naming convention (projectname_servicename_instance) in order to "identify" which containers belong to which project, because there are no other ways to do that.

Now that labels are possible, labels can be used to "identify" the containers, without having to use a special naming.

For example, by starting a container named foobar but adding some labels;

--label com.docker.compose.project=myproject
--label com.docker.compose.service=web
--label com.docker.compose.instance=1

With those labels, compose is able to determine that the container belongs to project myproject, that it is the container for the web service, and that it is the "first" (1) instance.

The name of the container is no longer relevant and can be changed/customized without problems.

Also docker supports filtering based on labels, so to find all containers belonging to a project, compose can use docker ps --filter label=com.docker.compose.project=myproject to find all containers belonging to project my project.

(Note: the com.docker.compose prefix is used to "namespace" labels to prevent conflicts with user-defined labels)

Hope this helps!

[kcmerrill]

Thanks for the information @thaJeztah!

[thaJeztah]

@kcmerrill wrt your reverse proxy; have a look at https://github.com/jwilder/nginx-proxy (or on the Docker Hub: https://registry.hub.docker.com/u/jwilder/nginx-proxy/)

Using that image as a proxy, you can automatically configure the proxy by adding an environment variable to your containers, e.g. VIRTUAL_HOST=www.example.com, without having to rely on the container name (which is a lot more flexible, as it will also work when scaling a service)

[kcmerrill]

Thanks @thaJeztah for the additional information. I'll be sure to take a peek.

I must have a specific use case(or doing something that drastically deviates ), so I ended up building my own tools to explicitly use container names.

• yoda.kcmerrill.com
• registry.hub.docker.com/u/kcmerrill/automagicproxy/

[rkettelerij]

+1 for explicit container names. Otherwise you'll end up manually building a base image before being able te reference it in Dockerfiles which are build using the 'build' command in docker-compose.yml.

[nicktgr15]

+1

[koliyo]

+1

[dreamcat4]

+1

[blop]

+1

[neg3ntropy]

+1 so that you can have a "data" compose which you rarely delete, and then services with volumes_from using container names.

[pfultz2]

Otherwise you'll end up manually building a base image before being able te reference it in Dockerfiles which are build using the 'build' command in docker-compose.yml.

This is a very useful use case for having explicit container names.

[riclox]

👍

[aanand]

Closing in favour of #1518