Isnt this a dup of #6457

@crosbymichael ... someone else at red hat is interested in this too ...

@crosbymichael hey, so I've broadened the scope a little, not much. This accommodates access to container Name, ID, and the downstream requirements of the /etc/machine-id contents (http://www.freedesktop.org/software/systemd/man/machine-id.html)

I would find this very useful to aid in the manual introspection I do to get containers to orchestrate themselves, but... should this really be in the file system? or should this be done 'properly' via the introspection socket - something like docker whoami

@SvenDowideit understandable. I'm going on the precedent of systemd's use of /etc/machine-id, for having this in the filesystem. I would not be opposed to a /sys or /proc style transient filesystem for introspection stuff like this. As for running docker whoami, that wouldn't be inside a running container, would it?

yes, docker whoami would be running inside a container

@SvenDowideit woah. Is this bind mounting in docker? I'm not opposed to an introspection like this, but seems a little wiley to tailor docker for a limited container access. I would not give a container full access to calling docker. perhaps a trimmed single purpose executable similar to dockerinit, that is bind mounted and can traverse that barrier.

you can't rely on obscurity by using a cut down binary. 'Properly' will require the socket to be filtered to only give the container info it should have.

makes me think someone should make a libswarm introspection backend that we connect to when docker run --introspect

I think if we want introspective capabilities it shouldn't be based on writing files to /etc.

@SvenDowideit understandable. Though the kind of interaction you're describing is neat, but I'm hoping for a standard way (or place) to get the machine's UUID.

@ibuildthecloud fair. But as I've stated before, this is based on precedent. I'm not describing an open socket to the docker daemon that lives in /etc, but an identification of /etc/container-id is basically the same concept as /etc/hostname which the unix way

@vbatts I could live with the idea of machine-id because that's an existing freedesktop standard, it's just the idea of inventing new ones. That sets a precedent I'm not comfortable with. But looking at machine-id, I'm also hesitant because of the various possibilities of how that can be managed. I can see arguments that the machine-id should be generated per imagine, per container, or per invocation (on start). Being that the machine-id is just a guid in a file, it seems like letting the user or image maintainer manage it is not a huge burden and maybe be preferable.

@crosbymichael and @shykes what do y'all see as acceptable forms of identity?

@vbatts @ibuildthecloud from the machine-id docs;

Programs may use this ID to identify the host with a globally unique ID in the network

IMO this implies that;

• An image should not contain a machine-id (committing a container should strip the machine-id)
• The. machine-id should be generated upon initialisation of the container
• Each container should have a unique machine-id; each instance should be unique, thus cloning/exporting/importing a container should strip and re-generate the machine-id
• Stopping/resuming a container should not affect the machine-id
• Problematic; Moving a container to a different host (how to guarantee that the container is moved, not duplicated)

At least, that's my interpretation.

@thaJeztah true, and that still makes me think that having an /me remote API that works when you're inside a container and accessing an introspection socket seem well worth it.

@thaJeztah good points. Thankfully, containers are not portable, images are. And this code does initialize the id on every container run. So even commiting the id file, it would be overwritten on any build or run

if its in the image, thats bad mkay :)

@SvenDowideit i wouldn't go so far as to say bad. Since it is initialized on every run and build, then presence of the previous value is at best history of the where the image came from (which docker inspect -f '{{.Container}}' <image> already includes as well ...)

30min of IRC chatter about this https://botbot.me/freenode/docker-dev/msg/18090155/

removed the /etc/containter-name and a couple of defers.

Presently this will initialize /etc/machine-id and /etc/container-id for containers.

@vbatts - imo that combined with docker commit is bad - compare it to

mount --bind /sys/docker/id /etc/machine-id - or even fixing systemd to be less ew

What ever happened to the idea of using environment variables for these? Couldn't they be injected into the container during startup? Seems a lot easier than adding files to the FS or counting docker itself being installed in the container to "phone home".

btw - big +1 for the container_id being available within the container. Allowing it to know itself is a good thing for when it/if it ever does need to "phone home". But even in other cases, like something in the container needing to tell someone else who it is (so some kind of correlation could be done) would be good.

this is still being debated on whether to use an env variable, like in #7685

If we are going to do something for this, #7685 is more like the route that we want to take. Closing this in favor of #7685 so we can focus on that implementation.