weaveworks / weave

Simple, resilient multi-host containers networking and more.
https://www.weave.works
Apache License 2.0
6.61k stars 668 forks source link

API access to weave #236

Open deadjoe opened 9 years ago

deadjoe commented 9 years ago

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,

bboreham commented 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.

deadjoe commented 9 years ago

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.

bboreham commented 9 years ago

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.

deadjoe commented 9 years ago

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.

rade commented 9 years ago

230 will go some way to resolving this issue, by making it possible to use the docker API for starting containers that get connected to the weave network.

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.

avkonst commented 7 years ago

Hi, is there rest API endpoint to get 'weave report' json data?

bboreham commented 7 years ago

@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