Commit Graph

5 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 7ae77e51f2
docs/extend: reformat notes
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e4fc8cfa23)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-04-19 19:42:49 +02:00
John Mulhausen 4a5db8d27e
Removing titles from md files
Signed-off-by: John Mulhausen <john@docker.com>
2017-10-13 15:24:06 -07:00
Frieder Bluemle 45c9b9b6c1
Fix GitHub spelling
Signed-off-by: Frieder Bluemle <frieder.bluemle@gmail.com>
2017-10-05 01:14:31 +08:00
Kir Kolyshkin 6d85a4f5f8 Fix repo references in docs
Since CLI was moved to a separate repo, these references are incorrect.
Fixed with the help of sed script, verified manually.

Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2017-07-28 10:32:42 -07:00
Brian Goff d8e04f68d3 Add support for metrics plugins
Allows for a plugin type that can be used to scrape metrics.
This is useful because metrics are not neccessarily at a standard
location... `--metrics-addr` must be set, and must currently be a TCP
socket.
Even if metrics are done via a unix socket, there's no guarentee where
the socket may be located on the system, making bind-mounting such a
socket into a container difficult (and racey, failure-prone on daemon
restart).

Metrics plugins side-step this issue by always listening on a unix
socket and then bind-mounting that into a known path in the plugin
container.

Note there has been similar work in the past (and ultimately punted at
the time) for consistent access to the Docker API from within a
container.

Why not add metrics to the Docker API and just provide a plugin with
access to the Docker API? Certainly this can be useful, but gives a lot
of control/access to a plugin that may only need the metrics. We can
look at supporting API plugins separately for this reason.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2017-06-02 00:11:05 +00:00