Do you want to deploy more stacks faster? Sure, we all do.
By integrating Ansible Tower, Red Hat CloudForms, and Red Hat Satellite it’s possible to deploy stacks faster, more securely, and manage them after they are deployed. In this post, I’ll give a brief demonstration of what is possible when these systems are integrated. But first …
A Quick Background
For those that haven’t been following, Red Hat recently announced that it has entered an agreement to acquire Ansible. Ansible is a leading open source IT automation project and delivers an enterprise solution for IT automation via Ansible Tower.
CloudForms is a hybrid cloud management platform based on the ManageIQ community (Developed by ManageIQ who was acquired by Red Hat in 2012). CloudForms provides a myriad of functions that include:
- Monitoring and tracking
- Capacity management and planning
- Resource usage and optimization
- Workload life-cycle management
- Policies to govern access and usage
- Self-service portal and catalog
- Controls to manage requests
- Quota enforcement and usage
- Chargeback and cost allocation
- Automated provisioning
Finally, there is Red Hat Satellite, a platform for managing Red Hat systems. While Satellite provides many capabilities for managing systems, in this demonstration I focus on Satellite’s ability to provide trusted content and for tracking entitlements.
By combining these three powerful platforms it is possible to provide new levels of functionality to users who want to securely automate their IT environments and do it all with open source.
Integration Workflow
The diagram below illustrates one integration now possible that would allow users to combine the power of CloudForms, Red Hat Satellite, and Ansible Tower.
Step 0 – We assume that you have already created a playbook in GitHub and added it via a SCM synchronization job in Ansible Tower. It also assumes you have synchronized trusted content to a Red Hat Satellite.
Step 1 – A user requests a self-service catalog item from CloudForms.
Step 2 – CloudForms connects to the provider and creates the virtual machine(s).
Step 3 – Upon successful creation of virtual machines CloudForms reaches out to Ansible Tower and creates host(s) in the inventory to match the virtual machine(s) created. It also initiates a job on Ansible Tower to execute the appropriate playbook(s).
Step 4 – The virtual machine(s) subscribes to the Satellite and pulls trusted content from it as part of the playbook.
This is a high level overview for a tenant workflow.
A Short Demonstration
The video above illustrates something I cooked up in the lab illustrating the integration workflow I described in the previous section. In this case, a user selects a self-service catalog item in CloudForms for a web server. CloudForms provisions a virtual machine on Red Hat Enterprise Virtualization. CloudForms provisions the virtual machine (from a template) and passes in a ssh key into the machine via cloud-init. Then CloudForms reaches out to Ansible Tower and adds the VM (by IP Address) to an inventory and kicks off a job manually.
The nice thing about this approach is that by using an Ansible playbook to automate the deployment of a web server it would be very easy to create another self-service catalog item on vSphere, OpenStack, or other supported infrastructure provider and recreate the same workload. With CloudForms, Ansible, and Satellite users can deploy via workflow where needed or embrace model driven deployment to increase re-usability across a wide range of infrastructures when possible.
Of course, it would be really nice to integrate identity management into this demonstration so that credentials are not being injected via cloud-init and so credentials in Ansible Tower are centralized into a proper IDM system. Also, integration into a proper IPAM system would be nice (but hey, this is just a demo).
Summary
I hope this demonstration provided you with an idea of how Ansible Tower compliments Red Hat CloudForms and Red Hat Satellite to allow for automation of stacks. It should be noted that another key is that the more automation that takes place in playbooks in Ansible, the more portable (and presumably more maintainable) it is for end users.
Source
As is usually always the case with most all things I’ve written … you should have a professional software developer, creative person, or lawyer re-write it as appropriate.
CloudForms Automate Method (LabCorp/Infrastructure/VM/Provisioning/StateMachines/Methods/redhat_PostProvision)
Contents of /root/rhsm.sh on the VM template (referenced in Ansible Playbook)
all things open 
There are a few concerns here but first let me thank you for your demonstration because it gives a starting point.
1:-It looks like you’re using a callback method to basically PULL a job execution from Tower, hence you’re not using the orthodox method of pushing to CloudForms, instead you’re using the CloudForms Automate Method to make REST requests to Tower and make it run. This poises Tower as a single point of failure and it creates an optional dependency on Projects having to be updated.
2.-When are the Ansible Modules for CloudForms coming? We don’t see any listed here:
http://docs.ansible.com/ansible/list_of_cloud_modules.html
Thanks for your comment. ManageIQ (the upstream for CloudForms) has added support for Ansible Tower.
https://github.com/ManageIQ/manageiq/issues/6094
This means that you no longer need to write automate methods by hand to integrate, but you can now discover Ansible Tower (and it’s playbooks) and execute playbooks as a type within the service catalog. Regarding your comments of Ansible Tower being a Single Point of Failure it may be useful to use the HA setup of Tower to remove it as a SPOF.
http://docs.ansible.com/ansible-tower/2.2.0/html/administration/high_availability.html
Regarding Ansible Modules for CloudForms – what types of modules are you interested in using to automate CloudForms from Ansible Tower? I’m interested in understanding the use case more deeply. You can email me directly at jlabocki at redhat.com if you want to discuss this in more detail privately.