A RESTful API framework for managing containers over a set of Docker Nodes.
Will also run a watcher process that will monitor, fix and rebalance containers on the cluster.
Click here for quickstart guide
Web UI for interacting with kDaemon: kDaemon_UI
Full stack design can be read here Development Plan and here Daemon Design
The stack consists of multiple docker endpoints exposing their APIs to their internal network (or VPN) and managing the state of the cluster from a central location.
docker --\
docker -->kDaemon
docker __/
Your nodes need to be running the docker API
sudo docker -H 0.0.0.0:2375 -H unix:///var/run/docker.sock -d
Rethinkdb with database name of rethinkdb_dbname and tables
You should have golang 1.5+ available on your machine.
kDaemon is only tested on Linux. Any machine with an exposed Docker API should be able to become a node however.
[default]
bind_ip = 0.0.0.0 # IP to bind API to
api_port = 1337 # Port to bind API to
rethinkdb_host = 127.0.0.1 # RethinkDB Host
rethinkdb_port = 28015 # RethinkDB Port
rethinkdb_dbname = kdaemon # RethinkDB database name
api_version = 0.0 # Current API version. (You probably shouldnt change this)
go get github.com/superordinate/kDaemon
cd $GOPATH/src/github.com/superordinate/kDaemon
go build .
./kDaemon
You can interact with kDaemon in several ways. The easiest way to get started is to use our web-ui at: http://github.com/klouds/kdaemon_ui.
If you're interested in working directly with the REST APIs, you here's some documentation for you:
To add a node, you can POST to bind_ip:api_port/%API_VERSION%/nodes/create
{
"name":"Host1",
"d_ipaddr":"127.0.0.1",
"d_port": "2375",
}
To add an application, you can POST to bind_ip:api_port/%API_VERSION%/applications/create
{
"name":"ghost-blog",
"exposed_ports":"2368",
"docker_image": "ghost"
}
To create a container on your most available node, you can POST to bind_ip:api_port/%API_VERSION%/containers/create
note: The application_id is generated when adding a new application.
{
"name":"ghost-blog-ozzadar",
"application_id":75186c59-ec80-49d6-beb5-1bfac76e8525
}
POST to bind_ip:api_port/%API_VERSION%/container/launch/%CONTAINER_ID%
UPDATED (Feb 25 2016) --
1) adding a start container command to the list. Separating container creation/launch from each other because what was I thinking?
2) moved endpoints to /action/id to get rid of annoying pathing errors.
* POST /%API_VERSION%/nodes/create -- Creates a node
* PATCH /%API_VERSION%/nodes/update/id -- Edits a node
* DELETE /%API_VERSION%/nodes/delete/id -- Deletes a node
* GET /%API_VERSION%/nodes/id -- Gets node information
* GET /%API_VERSION%/nodes -- Gets all nodes
* POST /%API_VERSION%/applications/create -- Creates an application in the database
* PATCH /%API_VERSION%/applications/update/id -- Edits an application
* DELETE /%API_VERSION%/applications/delete/id -- Deletes an application
* GET /%API_VERSION%/applications/id -- Gets application information
* GET /%API_VERSION%/applications -- Gets all applications
* POST /%API_VERSION%/containers/create -- Creates a container on the cluster
* POST /%API_VERSION%/containers/launch/id -- Launches a container on the cluster
* POST /%API_VERSION%/containers/launch/id -- Stops a container on the cluster
* PATCH /%API_VERSION%/containers/update/id -- Edits a container
* DELETE /%API_VERSION%/containers/delete/id -- Deletes a container
* GET /%API_VERSION%/containers/id -- Gets container information
* GET /%API_VERSION%/containers -- Gets all containers