Deploying Eucalyptus via Ansible playbook(s)

The first cut of the Ansible deployment playbook for deploying Eucalyptus private clouds is ready.  I’ve merged the first “release” into the master branch here: https://github.com/lwade/eucalyptus-playbook. Feedback and contributions are very welcome, please file issues against the project.

This playbook allows a user to deploy a single front-end cloud (i.e. all component on a single system) and as many NC’s as they want.  Although admittedly I’ve only tested with one so far.  I’ve followed, to a certain degree, the best practices described here:  http://ansible.cc/docs/bestpractices.html

Overall I’m pretty happy with it, there are some areas which I’d like to re-write and improve but the groundwork is there.  It was all very fluid to start with and doing something multi-tier has been enjoyable. I’ve also learnt what its like to automate a deployment of Eucalyptus and there are probably a number of things we should improve to make it easier in this regard.  Like getting rid of the euca_conf requirement to register systems, doing it via config file would be better 🙂

For those familiar with Ansible you will (hopefully) see that I’ve started to split common tasks out to encourage their reuse.  I’m certainly not finished here but I think what I have lays the groundwork for task re-use to then enable different topologies.

Fundamentally, to deploy a cloud with a specific topology the master playbook is called which then references a particular collection of tasks to achieve the desired results.  After all, a playbook is just a list of tasks, right?  So currently there is only one playbook for the single front-end topology: cloud-deploy-sfe.yml.  By looking at this, you’ll be able to see what tasks are referenced to build the cloud platform.  The next topology I plan to create is one for a non-HA split front-end topology (where all Eucalyptus cloud and cluster tier components are on separate hosts).  After that, I’ll look to address a couple of HA topologies. These are the kind of topologies folks are putting into production use.

The directory hierarchy looks like this:

|-- cloud
|-- cloud-deploy-distrib-nonha.yml
|-- cloud-deploy-sfe.yml
|-- cluster
|   |-- handlers
|   |   `-- cluster.yml
|   `-- tasks
|       |-- node-key-fetch.yml
|       `-- node-registration.yml
|-- common
|   |-- files
|   |-- handlers
|   |   |-- initialization.yml
|   |   `-- services.yml
|   |-- tasks
|   |   |-- component-registration.yml
|   |   |-- creds.yml
|   |   |-- initialization.yml
|   |   |-- packages.yml
|   |   |-- preconfig.yml
|   |   |-- refresh-facts.yml
|   |   |-- storage.yml
|   |   `-- template-configuration.yml
|   `-- templates
|       `-- eucalyptus.conf.j2
|-- group_vars
|   |-- all
|   |-- clustercontroller
|   |-- nodecontroller
|   `-- storagecontroller
|-- hosts
|-- host_vars
|-- node
|   |-- handlers
|   |   `-- node-preconfig.yml
|   |-- tasks
|   |   |-- node-key-copy.yml
|   |   `-- node-preconfig.yml
|   `-- templates
|       |-- ifconfig_bridge_interface.j2
|       `-- ifconfig_bridge.j2
|-- readme
`-- vars
    |-- cloudcontroller.yml
    |-- clustercontroller.yml
    |-- nodecontroller-net.yml
    |-- nodecontroller.yml
    |-- storagecontroller.yml
    `-- walrus.yml

It’s probably worth explaining the structure (I’ll be updating the readme soon) ….

|-- cloud
|-- cloud-deploy-distrib-nonha.yml
|-- cloud-deploy-sfe.yml
|-- cluster
|-- common
|-- group_vars
|-- hosts
|-- host_vars
|-- node
|-- readme
`-- vars

Note: structure may change, there are already some tasks which should really be moved into their tiered component hierarchies.

• cloud – this directory holds any specific task includes, handlers, files and templates for the cloud controller tier (CLC + Walrus)
• cloud-deploy* files – these are the top-level playbooks which pull in the tasks for the platform tiers.  From a users perspective, these will be the playbooks they choose to run to deploy a certain topology and configuration.
• cluster – this directory holds specific tasks includes, handlers, files and templates for the cluster layer (CC + SC)
• common – all common tasks, handlers, files and templates are found in this directory.  Tasks which are shared across all tiers and components should end up in here.
• group_vars – these are variables which apply to host groups.
• hosts – the inventory file, put your hosts into here, based on group (role).
• host_vars – host specific variables, of which there are none (at the moment).
• node – this directory holds specific tasks includes, handlers, files and templates for the node controllers in a cluster.
• readme – the readme which needs expanding 😉
• vars – this holds variable include files which cannot be used across groups or that need to be set statically for whatever reason.

Please take it for a spin and file issues against the project in GitHub.  If we get enough traction, I’m likely to split this out into a separate repo entirely.

Advertisements