cc @dmcgowan @crosbymichael @tonistiigi

I don't like use of FUSE. There is no equivalent solution for non Linux OS in general. Nor do I like mounting on /dev.

/dev/, /sys, or even /docker :)

I really do like the idea that we have a standard place for container introspection - maybe it could be implemented as a volume plugin :)

I'm 👍 for removing FUSE and just using a real filesystem #24110 (comment)

I'm not sure we can mount a directory in /sys or /proc, maybe /run is one of options.

I'll update PR when we reach consensus about the design

maybe it could be implemented as a volume plugin :)

I like that thought :)

Seems like all of this information could be gotten from the docker.sock no? Why not inject a heavily access-controlled-by-default docker.sock into all containers, with CLI switches or some other mechanism for opening that up in parts? Alternatively one could repackage only the parts of the Docker API that are appropriate for a meta-data service a la Digital Ocean ( https://developers.digitalocean.com/documentation/metadata/). This could live it it's own socket (simple filesystem-based discovery) or at a pre-defined link-local IP or on the Docker bridge.

P.S. I apologize if any of this has been previously covered and/or decided against. If that is the case please point me to the relevant discussion(s)!

@SvenDowideit @thaJeztah

I once considered making that a volume plugin.
But I think it is worth supporting that as a standard feature rather than as a 3rd party plugin.
Maybe 👍 for built-in volume plugin.

@dweomer

I once considered the socket, but

• you need to install a rich REST client to containers
• there is no equivalent of AF_UNIX for Windows, AFAIK (correct me if wrong). It is possible to use pre-defined IP instead, but it doesn't work when --net=none.

Comparison (correct me if wrong 😄, last update Jul 26, 1:42 UTC)

Currently I'm +1 for FS (bind-mount), but not strongly sticking to it.

I'm planning to modify the PR so as to:

• use bind-mount instead of FUSE
• introduce RuntimeContext struct (suggested by @stevvooe Pass swarm task information as environment variables into each task #24110 (comment))
• File names will be like /dev/docker/v1/task/slot (introduced API ver, eliminated JSON. based on suggestion by @mcassaniti Pass swarm task information as environment variables into each task #24110 (comment))

I'm still not sure about:

• should it be mounted under /dev/docker /run/docker? /run/docker-context?
• should it be a built-in volume plugin? (what about default standard mount point?, what about the volume name?)

Thanks for starting the work on this @AkihiroSuda - note that most maintainers are still very busy on the 1.12 release, but we should definitely give this attention once we have some time on our hands. Having an introspection API has been on the list of a long time, but still needed more discussion in what form; hopefully this PR (and related issue) gets the discussion going again.

FWIW; we should give proper thought if this should be available by default or as an opt-in (the API can expose information that you may not want to have available in just "any" container). Also, it should be discussed if the API can be "scoped", so that only a limited subset of information is available to a container (think of multi-tenant situations). The last obviously depends on what we want to expose (e.g., "docker events" are currently used by various containers, and currently implemented by bind-mounting /var/run/docker.sock inside a container; we should really have a better alternative for that)

Windows does have the equivalent of sockets, "named pipes" which is what the Docker now uses on WIndows (it used to always use a tcp socket).

@AkihiroSuda

I'm still not sure about:

• should it be mounted under /dev/docker?
• should it be a built-in volume plugin? (what about default mount point?)

• I like /run/docker/ better than /dev/docker
• If you do it as a volume plugin isn't the concept of a default mount point moot? Because the user is now enlisting the meta-data/introspection service via volume plugin they will also have to specify where to mount it at, thereby offloading the service-discovery pre-allocation/bootstrap/set-aside to the end-user.

+1 to built in volume plugin :)

I'll try to rework on this as a built-in volume plugin, sorry for long delay

Opened a new PR (built-in volume driver): #26331

It looks like this:

$ docker service create --name nginx --replicas 3 --mount type=volume,src=docker_introspection,dst=/foo nginx
$ docker exec -it $SOME_NGINX_CONTAINER bash -c 'for f in $(find /foo -type f);do echo ===$f===; cat $f; done'
===/foo/v1/container/name===
/nginx.2.76rasygemgtwq9akwzmurtuze
===/foo/v1/container/labels===
com.docker.swarm.task.name=nginx.2
com.docker.swarm.node.id=7l4osfysnqpu347o5o88lyjqy
com.docker.swarm.service.id=cbnmi8ecj9buk9375bl342q1s
com.docker.swarm.service.name=nginx
com.docker.swarm.task=
com.docker.swarm.task.id=76rasygemgtwq9akwzmurtuze
===/foo/v1/container/id===
5f1e9ead122451486395c6afe2ce0975dd94ace730496a7c9c6474ec0b8bb672
===/foo/v1/task/name===
===/foo/v1/task/slot===
2
===/foo/v1/task/labels===
===/foo/v1/task/id===
76rasygemgtwq9akwzmurtuze
===/foo/v1/service/name===
nginx
===/foo/v1/service/labels===
===/foo/v1/service/id===
cbnmi8ecj9buk9375bl342q1s
===/foo/v1/node/name===
===/foo/v1/node/labels===
===/foo/v1/node/id===
7l4osfysnqpu347o5o88lyjqy