Container tagging / naming

[shykes]

In previous conversations I think we agreed that the ability to tag containers would be nice, but there was no compelling reason to add it to the core. Especially with globally unique IDs, it's super easy for a user to store all the metadata he needs himself: users, applications, services, versions, source repository, source tag, whatever.

However there is one thing that is only possible in the core: atomic operations on a set of containers matching certain tags. In the future that might be a necessary feature, for a number of reasons:

a) Performance (to avoid running 200 duplicate commands for 200 containers)
b) Reliability (eg. less moving parts when coordinating many dockers)
c) Ease of development

I don't have a set opinion, but wanted to write this down for later discussion.

[shykes]

@synack and @progrium (among others) both asked for the ability to name containers - which seems like a special case of tagging.

So maybe we want this in the core after all?

[progrium]

docker is a manager so it should play index. a pid file approach would suck (means containers have to know their id, be able to write it somewhere). and any third party tool would have to work with docker to figure out the id of every container somehow, and that's already a problem. but that problem would go away if you knew the way to reference a container before you made it.

[progrium]

I was skeptical of tags. But I think containers should work similarly to images now. I don't know about the name "repository" but having a base name and optional tag would be nice to help look up ids. In theory, you should never have to work with ids. Imagine a PaaS and you named containers (using dotcloud terms) < user>/< app>/< server>.< instance> and then tags would be used for deployments. v1, v2, v3 ... they'd all have their own ids and all be unique containers.

[dstrctrng]

+1, names would let me autoconfigure based on convention, like memcacheXX containers would get written to a memcached.yml, or mysql-master, mysql-replica would get paired together without each knowing about the other. The devs using my containers would focus on the logical names instead of implementation details like IDs.

[jpetazzo]

Some thoughts about naming, based on our experience at dotCloud...

EC2 uses tags, and doesn't have a way to name instances (an instance will be i-42ab69cd). Oh, right, you can give a Name tag, and it will show up in the console in the "Name" column; but you can't address instances by name and uniqueness is not enforced. In practice this is nice when you use the console, but overall a bit error-prone, because uniqueness is not enforced. On the dotCloud platform, we set the Name tag to be the FQDN of the instance, and we use meaningful names (admin-8, gateway-7, ...). This is very useful when working under pressure (e.g. when an outage happens), for the following reasons.

1. It's easier to shout across the room "check foo-55, I think it's blowing up!" rather than "check i-42f0a... no wait... i-42f9a... oh crap" (yes, you can also copy paste on IRC/e-mail)
2. Some well-known resources are "pinned" to specific instances. E.g. you can have a large cluster of MySQL instances, but know that your main MySQL database masterdb is on instances tagged db-1 and db-2. Most of the time, you don't care, because you have a resource location service that will tell you instantly the exact location of any resource; but when said service is down (and relies on said db), you're very happy to have some fallback.

For those reasons, we decided that the naming scheme on the dotCloud platform would be different; i.e. for a given scaled service, each service instance would get an assigned number (0,1,2...) and uniqueness would be enforced. This, however, has other shortcomings.

1. Uniqueness is only local to a machine. Nothing prevents from having two identical containers on two different hosts; and then, of course, you're in trouble.
2. Relying on that "hard-coded in your brain" mapping (evoked in the previous paragraph) doesn't work that well, neither. It's nice to know that your super important masterdb is on host db-1, but when it gets migrated, it doesn't work anymore, and you're back to square zero (e.g. having to parallel-ssh to your whole cluster to figure out where the database is, because the naming system is broken).

I assume that we can't / don't want to ensure global uniqueness of container names (that would require some distributed naming system, and suddenly a herd of zookeepers, doozers, and other weird beasts are hammering to gates to get in!); however, some way to easily find a container "when the sh_it hits the fan" would be really great. Picture the following scenario: you need to stop (or enter) a specific instance of a given service, but your global container db (maintained by you, outside of docker) is down. Let's hope that you have some way to locate the docker host running the instance you're looking for. Now, how do you locate the specific container easily (=not with a 4-lines obscure shell pipeline that takes you 5 minutes to grok correctly through SSH), quickly (=not by running a command on each of the hundreds or thousands of containers running on the machine), and reliably (=not yielding 4 false positives of down or unrelated containers before pointing to the right one)? *Even if docker's structures have been corrupted/messed with?_

Any solution to the last problem gets my immediate buy-in :-)

[shykes]

Hi Jerome, I'm not sure what you're asking or suggesting.

Names willl be a convenience for single-machine use. They should not be
used to name or lookup containers across multiple hosts.

On Friday, April 5, 2013, Jérôme Petazzoni wrote:

Some thoughts about naming, based on our experience at dotCloud...

EC2 uses tags, and doesn't have a way to name instances (an instance will
be i-42ab69cd). Oh, right, you can give a Name tag, and it will show up
in the console in the "Name" column; but you can't address instances by
name and uniqueness is not enforced. In practice this is nice when you use
the console, but overall a bit error-prone, because uniqueness is not
enforced. On the dotCloud platform, we set the Name tag to be the FQDN of
the instance, and we use meaningful names (admin-8, gateway-7, ...). This
is very useful when working under pressure (e.g. when an outage happens),
for the following reasons.

1. It's easier to shout across the room "check foo-55, I think it's
   blowing up!" rather than "check i-42f0a... no wait... i-42f9a... oh crap"
   (yes, you can also copy paste on IRC/e-mail)
2. Some well-known resources are "pinned" to specific instances. E.g. you
   can have a large cluster of MySQL instances, but know that your main MySQL
   database masterdb is on instances tagged db-1 and db-2. Most of the time,
   you don't care, because you have a resource location service that will tell
   you instantly the exact location of any resource; but when said service is
   down (and relies on said db), you're very happy to have some fallback.

For those reasons, we decided that the naming scheme on the dotCloud
platform would be different; i.e. for a given scaled service, each service
instance would get an assigned number (0,1,2...) and uniqueness would be
enforced. This, however, has other shortcomings.

1. Uniqueness is only local to a machine. Nothing prevents from having two
   identical containers on two different hosts; and then, of course, you're in
   trouble.
2. Relying on that "hard-coded in your brain" mapping (evoked in the
   previous paragraph) doesn't work that well, neither. It's nice to know that
   your super important masterdb is on host db-1, but when it gets migrated,
   it doesn't work anymore, and you're back to square zero (e.g. having to
   parallel-ssh to your whole cluster to figure out where the database is,
   because the naming system is broken).

I assume that we can't / don't want to ensure global uniqueness of
container names (that would require some distributed naming system, and
suddenly a herd of zookeepers, doozers, and other weird beasts are
hammering to gates to get in!); however, some way to easily find a
container "when the sh_it hits the fan" would be really great. Picture the
following scenario: you need to stop (or enter) a specific instance of a
given service, but your global container db (maintained by you, outside of
docker) is down. Let's hope that you have some way to locate the docker
host running the instance you're looking for. Now, how do you locate the
specific container easily (=not with a 4-lines obscure shell pipeline that
takes you 5 minutes to grok correctly through SSH), quickly (=not by
running a command on each of the hundreds or thousands of containers
running on the machine), and reliably (=not yielding 4 false positives of
down or unrelated containers before pointing to the right o ne)? *Even if
docker's structures have been corrupted/messed with?_

Any solution to the last problem gets my immediate buy-in :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-15965238
.

[progrium]

Sometimes global uniqueness is just scoping. Put the host machine's name in
the name. That's why I was suggesting we use the hostname option to let you
specify a referenceable name.

IMHO, we shouldn't try to address global uniqueness. It should be something
the user can do on their own, augmented by other systems.

In your scenario, I would solve it with a better service discovery system.
One that doesn't have a central DB. Also one that is not necessarily Doozer
or Zookeeper.

On Fri, Apr 5, 2013 at 9:12 AM, Jérôme Petazzoni
notifications@github.comwrote:

Some thoughts about naming, based on our experience at dotCloud...

EC2 uses tags, and doesn't have a way to name instances (an instance will
be i-42ab69cd). Oh, right, you can give a Name tag, and it will show up
in the console in the "Name" column; but you can't address instances by
name and uniqueness is not enforced. In practice this is nice when you use
the console, but overall a bit error-prone, because uniqueness is not
enforced. On the dotCloud platform, we set the Name tag to be the FQDN of
the instance, and we use meaningful names (admin-8, gateway-7, ...). This
is very useful when working under pressure (e.g. when an outage happens),
for the following reasons.

1. It's easier to shout across the room "check foo-55, I think it's
   blowing up!" rather than "check i-42f0a... no wait... i-42f9a... oh crap"
   (yes, you can also copy paste on IRC/e-mail)
2. Some well-known resources are "pinned" to specific instances. E.g. you
   can have a large cluster of MySQL instances, but know that your main MySQL
   database masterdb is on instances tagged db-1 and db-2. Most of the time,
   you don't care, because you have a resource location service that will tell
   you instantly the exact location of any resource; but when said service is
   down (and relies on said db), you're very happy to have some fallback.

For those reasons, we decided that the naming scheme on the dotCloud
platform would be different; i.e. for a given scaled service, each service
instance would get an assigned number (0,1,2...) and uniqueness would be
enforced. This, however, has other shortcomings.

1. Uniqueness is only local to a machine. Nothing prevents from having two
   identical containers on two different hosts; and then, of course, you're in
   trouble.
2. Relying on that "hard-coded in your brain" mapping (evoked in the
   previous paragraph) doesn't work that well, neither. It's nice to know that
   your super important masterdb is on host db-1, but when it gets migrated,
   it doesn't work anymore, and you're back to square zero (e.g. having to
   parallel-ssh to your whole cluster to figure out where the database is,
   because the naming system is broken).

I assume that we can't / don't want to ensure global uniqueness of
container names (that would require some distributed naming system, and
suddenly a herd of zookeepers, doozers, and other weird beasts are
hammering to gates to get in!); however, some way to easily find a
container "when the sh_it hits the fan" would be really great. Picture the
following scenario: you need to stop (or enter) a specific instance of a
given service, but your global container db (maintained by you, outside of
docker) is down. Let's hope that you have some way to locate the docker
host running the instance you're looking for. Now, how do you locate the
specific container easily (=not with a 4-lines obscure shell pipeline that
takes you 5 minutes to grok correctly through SSH), quickly (=not by
running a command on each of the hundreds or thousands of containers
running on the machine), and reliably (=not yielding 4 false positives of
down or unrelated containers before pointing to the right o ne)? *Even if
docker's structures have been corrupted/messed with?_

Any solution to the last problem gets my immediate buy-in :-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-15965238
.

Jeff Lindsay
http://progrium.com

[jpetazzo]

Well, I was merely explaining my use case (which is the use case
experienced by ops on the dotCloud platform): "sometimes, you need to be
able to find a given process easily and quickly; i.e. on which host it is,
and in which container it is exactly". In my use case, said "process" is
identified by an arbitrary tag which is set by the operator when the
process start (and in our specific case, this tag is the container
hostname, but it doesn't need to be).

Then there is a very wide spectrum of possible implementations.

1. docker doesn't let you set a tag, so you have to retrieve the container
   ID when it starts, and store it in some database (zookeeper, redis, dns,
   whatever lets you do an easy mapping).
2. docker lets you set a tag, and retrieve it as well, and indexes the tags
   locally. Now you don't need to store the full container ID anymore, just
   the host running your container.
3. docker lets you set a tag, and the tags happen to be stored as flat
   files with a well-known layout (or something similar).

Notes:
(1) seems to be fine and well, until the central database is unavailable /
corrupted / inconsistent;
(2) makes things easier than (1) because as long as containers don't move
arbitrarily, your database doesn't change (and also, you can efficiently
use DNS to map containers to hosts);
(3) makes things easier than (2) when docker breaks, because finding a
container can be done with simple shell commands.

[brynary]

Container tagging feels like a core concept to me, and seems like a building block for the "container groups" feature that @shykes mentioned.

[warpfork]

Naming containers worries me. Even if the feature were implemented, I think that if I found myself tempted to use it, I'd suspect a bad smell and try to redesign to avoid using it.

Docker is powerful because it removes magic numbers from my life. It makes it possible for me to run, for example, two instances of nginx on my one host machine, without making a mess. Now what if I start working in a company that has a script that relies on one of their containers being named "nginx"? Or worse, "main"? Now try to set these up in jenkins or something that's trying to run selfcontained/concurrent tests. Whoops.

Maybe it's possible to build scripts around naming to make sure names are generated with unique suffixes to avoid that kind of problem... but I'm not sure it's reasonable to expect people to consistently do so, and even if it is done, then is that any better than just dealing with random IDs as they stand? If there was support for commands that run on sets of containers based on globbing of names, then I could see a potential gain, but otherwise, I see nothing.

[progrium]

@heavenlyhash so it sounds like you'd prefer tags.

[shykes]

Tentatively scheduling for 0.8

[shykes]

Just a heads up, this is confirmed for release in 0.6.5 tomorrow :)

[shykes]

This has been implemented in Docker 0.6.5.

[jamescarr]

👍