Orchestrate Docker containers with OpenStack Heat.
Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code.
Orchestrating containers is a known issue. Docker makes it easy to deploy containers, but what about sharing information among them? There are a couple of ways of orchestrating containers using existing cluster managers such as Hadoop Yarn, Apache Mesos, etc...
The purpose of this project is to bring the support for orchestrating Docker containers in an OpenStack environment using Heat. This opens the possiblity to easily interact with other OpenStack resources already supported by Heat such as a Nova instance, a Swift datastore, etc...
Starting with the Havana roadmap, Nova will support a new hypervisor for managing Docker containers. Since Nova is already well supported by Heat, it's actually already possible to orchestrate Docker containers by using Nova instances (with the Docker hypervisor enabled on Nova itself).
Using Docker behind Nova brings actually a lot of advantages since all Nova features are available "for free".
However provisionning Docker containers directly from Heat enables the possibility to use the whole Docker remote HTTP API directly from a Heat template. This unlocks all Docker features without having to wait for the Nova hypervisor to support them.
It's important to note that both approaches are actively supported and will evolve over time. This Heat plugin does not aim to replace the Docker hypervisor for Nova.
First of all the code sits there: https://github.com/dotcloud/openstack-heat-docker/
I recommend to use DevStack. Following the steps 1, 2 and 3 is enough since Nova is not needed here.
NOTE: Heat scans the directory /usr/lib/heat to find plugins to load.
Running the following the following commands will actually install the Docker plugin in an existing Heat setup.
git clone git@github.com:dotcloud/openstack-heat-docker.git
ln -sf $(cd openstack-heat-docker/plugin; pwd) /usr/lib/heat/docker
Only the process "heat-engine" needs to be restarted to load the new installed plugin. Here is how to do it with devstack
- Attach to the screen (using the "screen -rd" command);
- Find the "h-engine" window (ctrl+n to switch to the next window);
- Interrupt the process and restart it.
Since calls to Heat are authenticated, the Keystone token needs to be loaded in the environment. With devstack, here is how it works:
cd devstack
. openrc
heat stack-list
The last comment asks Heat to return the previous created stacks. Since it's a new setup, nothing will be return. But if there is no error displayed, it means that all previous steps have be run successfully.
The example shipped with the project shows how to deploy a blog under Wordpress using a MySQL database. The current wordpress containers available right now on Docker Index usually embed Apache, Wordpress and MySQL all in one single container. The difference is that two containers will be deployed. One for the MySQL server, another for Apache+Wordpress. The Database information (IP, port and password) are injected in the environment of the Wordpress container. So we can easily imagine a Wordpress container scaled accross different hosts using the same database (the latter being scaled using a master/slave setup).
Let's try to run the example. The following command will provision the stack:
heat stack-create wordpress -f openstack-heat-docker/example/templates/wordpress_mysql.yml
If it went well, you should be able to see the stack with the status "CREATION_COMPLETE".
heat stack-list
+--------------------------------------+------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+-----------------+----------------------+
| 239cc009-00fe-4c6f-ac67-f8873df38f08 | wordpress | CREATE_COMPLETE | 2013-10-15T23:23:08Z |
+--------------------------------------+------------+-----------------+----------------------+
And the corresponding containers in Docker:
docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
5513c532b4dc samalba/wordpress:latest /usr/sbin/apache2 -D 2 minutes ago Up 2 minutes 49174->80
b98d764d109d samalba/mysql:latest /start_mysqld.sh 2 minutes ago Up 2 minutes 49173->3306
In this example, connecting with a web browser on the port 49174 of host will show the wordpress install page.
FIXME: INCLUDE SCREENSHOT
The Heat template also generated the Blog URL:
heat stack-show wordpress
The Docker plugins uses the docker-py library to talk to the Docker daemon.
FIXME: include architectural schema
By default, each Docker resource declared in the Heat template will end up being mapped to a container on the local machine. In this case, heat-engine talks to the local Docker daemon through its unix socket. However it's possible to specify a DockerEndpoint parameter for a given Docker resource. The result will be to map this specific resource to a Docker daemon being pointed by the endpoint.
TODO: Document the way of referencing DockerHost resources to other Docker resources