Open deadjoe opened 9 years ago
It's not visible in Docker inspect but it is there.
However, at the moment the "weave api" is the command line provided by the ‘weave‘ command. There are a couple of features, such as ‘weave status‘, that are implemented via that http port, but you wouldn't get very far if you only used those two.
Thanks for reply.
Does that means till now i can't wrote some management function in our own code that communicate with weave directly via REST way? Like create/start/stop, attach/detach actions?
If so , we have to directly invoke the CLI of weave and parse the cmd return results.
Yes, you have to invoke the CLI for launch, stop, attach, detach, etc. There's not much to parse in the output for most commands - if weave
started a new container you get its ID; if something went wrong (marked by a non-zero exit code) you get some message(s) that are intended for humans.
We would be very interested to hear more about your use-case - motivating why REST would be better for you than a command-line.
I would also note there is a Docker project to add "plugins" and/or "network drivers" in future, which we expect weave to be able to work with, in which case you would hit the Docker http API for most operations, adding extra parameters where needed by weave.
thanks for reply,
We are build our own PaaS system, build upon loose-coupling architecture which lead to API centric. our lower level resource manager has storage adapters, network adapters and IaaS adapters. It's reasonable to construct our network adapters to manage weave network and OVS (in future).
we need to enable weave layer a flat REST api layer so that our network adapter's central logical can be simple and unified.
Just like docker has it's remote API that simplified and unified our centric logical of management layer.
we have read weave blog post "Life and Docker Networking" and agree that in the future users and developers can benefit from Docker 's "plugin and network drivers for weave network". But it should not be the only way we build and manage weave network. Independent management interface can help weave adapter more scene.
In order to create an HTTP API for weave as a whole, there needs to be an endpoint to talk to. Which requires a daemon of some sort. Requiring users to manage the lifecycle of a daemon is a pain, so we'd either have to package it for various distributions, or, better, let docker take care of the lifecycle, i.e. run the daemon as a docker container. It looks like we can get access to everything we need from a container, by running with --net=host
and mounting /proc
.
The existing shell script would have to become a thin wrapper which a) launches the weave daemon, and b) turns the CLI commands into HTTP API invocations. For the current weave command set it may just be possible to do all that in a shell script w/o too much hassle. Once we get into constructing or deconstructing non-trivial JSON, the shell script would have to go.
Security is another issue. Cue X509 certificates and all the usability joy they bring.
Hi, is there rest API endpoint to get 'weave report' json data?
@avkonst yes, although it's undocumented so it might change. We have discussed moving the endpoint from a TCP socket to a Unix socket, for instance.
Currently it's accessible via curl 127.0.0.1:6784/report -H 'Accept: application/json'
If you need it remotely accessible the same path will answer on the 'status' address, which you can set as described on the metrics page
are there any docs contains the way to access weave via REST API?
I have seen that there is a "HTTP_PORT" =6784 in the source code but can't see it from docker inspect after weave launched.
I am trying to write a testing code to operate weave via REST API.
Thanks,