ONEDock is a set of extensions for OpenNebula to use Docker containers as first-class entities, just as if they were lightweight Virtual Machines (VM). For that, Docker is configured to act as an hypervisor so that it behaves just as KVM or other hypervisors do in the context of OpenNebula.

The underlying idea is that when OpenNebula is asked for a VM, a Docker container will be deployed instead. In the context of OpenNebula, it is managed as if it was a VM, and the user will be able to use IP addresses to access to the container.

Docker Machine and similar projects deploy VMs in different Cloud Management Plattforms (e.g. OpenNebula, OpenStack) or commercial providers (like Amazon EC2), installing Docker on them. Afterwards, it is possible to deploy and manage Docker containers inside them, using the Docker client tools that communicate directly with the Docker services deployed inside the aforementioned VMs.

Instead, ONEDock takes a different approach by deploying Docker containers on top of bare-metal nodes, thus considering the containers as first-class citizens in OpenNebula. This allows to seamlessly integrate the benefits of Docker containers (quick deployment, limited overhead, availability of Docker images, etc.) in a Cloud Management Platform such as OpenNebula. On the other side, it provides new features for containers that are usually reserved for VMs (e.g. enhanced IP addressing, attachment of block devices, etc.).

ONEDock tries to adapt Docker semantics to the OpenNebula context. The workflow for a whole use-case is the following:

1. An image is registered in a datastore of type ‘onedock’, by using the oneimage command.
2. ONEDock will download the image from Docker Hub.
3. A VM that uses an image registered in the ‘onedock’ datastore is requested.
4. When the VM is scheduled, ONEDock will actually create a Docker container instead of the VM, and the container will be daemonized (e.g. kept alive).
5. If the container has been connected to a network, it is possible to be accessed (e.g. using ssh or http).

The most prominent feature of ONEDock is that it does not introduce any API changes, therefore it does not modify the way of interacting with OpenNebula: It is possible to use the ONE CLI (i.e. oneimage, onevm, onetemplate), OpenNebula Sunstone, XML-RPC, etc. and keep the usual lifecycle for the VMs.

Technical details

ONEDock provides 4 components that need to be integrated into the OpenNebula deployment:

• ONEDock Datastore, that enables to create a datastore that contains Docker images. It is self-managed in the sense that images are created as references that are automatically downloaded from Docker Hub.
• ONEDock Transfer Manager, that stages the docker images that are in a Docker datastore into the virtualization hosts.
• ONEDock Monitoring Driver, that monitors the virtualization hosts in the context of the Docker hypervisor.
• ONEDock Virtual Machine Manager, that carries out the tasks related to the lifecycle of the Docker containers as if they were VMs.

These components have to be installed in the proper folders of a ONE frontend (i.e. /var/lib/remotes/) and activated in the oned.conf file. Therefore, no source code modifications of OpenNebula are required.

Once this has been done, it is possible to create datastores of type ‘onedock’ and virtualization hosts that use ‘onedock’ as the virtual machine manager.

The ONEDock datastore

In order to deploy a Docker container, a Docker image is required. When you run a container, Docker automatically retrieves the image from the Docker Hub repository.

To avoid that all virtualization hosts access Docker Hub, and as kind of cache, ONEDock supports a private registry installed in the OpenNebula front-end. Then, the references to the Docker images will point to the private Docker registry. ONEDock supports Docker registry v2.0.

The network in ONEDock

Docker containers are conceived to run applications, and so, it is common to find that ports are redirected to public ports in the machine that hosts the Docker container. ONEDock enhances this behaviour in order to expose all the ports of the container as it would happen in a VM. Therefore, you can run different services in different ports without the need of exposing them explicitly. The container will have an IP address where all the ports are available.

Testing ONEDock

ONEDock can be evaluated in a sandbox before deploying it in your on-premises Cloud. Easy as 1, 2, 3:

1. Install Vagrant
2. Spin up the vagrant VM, which will be automatically configured with ONE, ONEDock, the docker registry and all the needed components.
3. Start creating Docker containers with the common ONE commands (i.e. onevm create, etc.)

Or

1. Install LXC
2. Create a testing container (using a self contained cli-utility that installs ONE, ONEDock, the docker registry and all the needed components).
3. Start using ONE by issuing the common ONE commands (i.e. onevm create, etc.)

Getting ONEDock

ONEDock has been developed in the framework of the INDIGO-DataCloud (https://www.indigo-datacloud.eu) project under the Apache 2.0 license. You can get it from the public repository https://github.com/indigo-dc/onedock.

ONEDock is accepting contributions. You are invited to interact with us in the GitHub repository, by asking questions or opening new issues.