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.