Recently we decided to deploy a private cloud to replace our RHEV setup. The reasoning behind this will be covered in an other blog post, but the main reason was the higher level of automation we could achieve with Opennebula compared to RHEV. In this post I would like to talk about how we used Ansible to help us with the setup of Opennebula and what we are going to do in the near future.
Why Ansible? Well, we were already using Ansible to perform repeatable deployments in our test environments to save us some valuable time compared to “manual” setups. This way we can test new code or deploy complete test environments faster.
So when we decided to deploy Opennebula we started writing ansible playbooks from the first start because we wanted to test several setups until we had a configuration that we found performant enough and was configured the way we wanted. This allowed us to rebuild the complete setup from scratch (using Cobbler for physical deployments) and have a fresh setup 30min later. This included a fully configured setup with Opennebula Management Node, Hypervisors(kvm) and everything we needed to further configure our Gluster storage backend.
One of the advantages of Ansible is that it is not just a configuration management tool but can do orchestration to. Opennebula for example uses SSH to communicate to all the hypervisor nodes. So during the deployment of a hypervisor node we use the delegate_to module to fetch the earlier generated ssh keys and deploy them on the hypervisor. Pretty convenient..
We currently have quite complete playbooks that use a combination of 3 roles. They do need some testing and when we feel they can be used by other people too, we’ll put them on the Ansible Galaxy.
- one_core : configures the base for both KVM nodes and the sunstone service
- one_sunstone : configures the Sunstone UI service
- one_kvmnode : configures the hypervisor
Until now we haven’t used Ansible to keep our config in sync or to do updates, but it’s something we have in the pipeline and should be quite trivial using the current Ansible playbooks.
Another thing we’ll start working on are modules to support Opennebula. We already had a look at the possibilities Opennebula provides and should be quite trivial to build using its API.
We are very pleased with both projects as they aim to keep things simple which is important to us since we are a very small team and have to move forward at a rather fast pace.
The playbooks can be found on github