On Wednesday, May 22, SovLabs teamed up with Red Hat Ansible to offer a deep dive technical webinar, “Best Practices for Integrating vRealize Automation and Ansible Tower.” You can watch webinar in its entirety on the Red Hat Ansible website here. Below is a brief summary of the webinar — with timestamps — so you can quickly navigate to the parts you want to see and hear the most.
Introduction (0:00 – 7:45)
Red Hat Ansible Sr. Field Product Manager Kyle Benson walks the audience through the highlights of the Ansible product line:
- Ansible Engine: Simple command line automation
- Ansible Tower: Operationalize your automation
Kyle then notes upcoming enhancements to the Ansible products, announced at Red Hat Summit, that focus on expanding Ansible Tower and Ansible automation into a few key areas:
- Automation Insights – A new analytics tool in Ansible Tower 3.5 (scheduled to release in the summer of 2019), that provides customers information on what their environment looks like, how their automation is going, is it successful or not, and provides greater detail on what’s happening within their automation environment.
- Ansible Galaxy is expanding to make it more valuable to Ansible customers day in and day out.
- Certified Content to Customers – Within Ansible Core, there will be Ansible Collections, which will allow the release of new modules and capabilities within Ansible at a faster pace as well as new content to be collected and distributed across different levels of automation – system, level, or playbook specific roles – from customers and partners.
- Adoption & Training Services – In addition to training and consulting from Red Hat, they are providing tools that make it easier to get started testing in Ansible including a developer tool kit featuring Molecule which will allow people who are writing Ansible playbooks to deliver in a test-driven way.
Kyle invited everyone in the audience to attend AnsibleFest September 24 – 26 in Atlanta.
Overview: How Ansible Tower integrates with vRealize (7:45 – 10:15)
Using PowerPoint slides to illustrate how things work, Sid walks us through four different use cases for integrating Ansible Tower with vRealize Automation. Those use cases are:
- Requesting a workload deployment from within Ansible Tower
- SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
- SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
- SovLabs Ansible Tower Plugin for vRealize Automation CM Framework
SovLabs makes endpoint integrations and platform enhancements for vRealize Automation to allow you to achieve integrations without writing any custom code. The SovLabs Ansible Tower modules offer 2 ways to consume the software under one license:
- SovLabs Ansible Tower Module for vRA – a data driven approach to vRA allowing you to drive the outcome using your data that’s important to you
- Plugin for vRA CM Framework – allows you to build more point specific blueprints that might be specific to certain applications that you want to deploy. (Requires vRealize Automation Enterprise).
Both methods are available with the license so customers are free to choose either or both methods to fit their needs.
Use Case 1: Request a Workload Deployment from Any Platform (10:16 – 13:05)
Moving into actual use cases, Sid explains how we (SovLabs) frequently get asked how to use Ansible Tower to consume this type of lifecycle event. In this example we use Ansible Tower to initiate the request to vRA, then it will invoke a blueprint lifecycle from within vRA. vRA will then invoke SovLabs’ integrations throughout that lifecycle. Ultimately the request ends with the registration of that machine into the Ansible inventory and invoking an Ansible job template.
Two lifecycle events (handled by SovLabs) to pay attention to are Naming and IPAM / DNS. In order for Ansible integration to work effectively, Ansible needs to be able to resolve the machine name that is being deployed from DNS. This process doesn’t have to take place with our modules, but it’s a very effective way to make sure it happens as part of the provisioning lifecycle before the Ansible Tower integration is invoked.
SovLabs takes a data driven approach to using vRA. We can build very generic blueprints inside vRA and drive them via data. Blueprints can be invoked from within vRA or from outside providers like Ansible, taking in the necessary data we need so we can drive the outcome from within vRA using things like naming, IPAM, and placement down through inventory, playbooks, etc. This approach only works with non-CM versions of the SovLabs plugin, but both versions do work together in the same vRA environment.
Use Case 2: SovLabs Ansible Tower Module for vRealize Automation with Static Inventory (13:06 – 14:09)
Here’s an example of the data-driven approach using Ansible Tower integration with a static inventory. Initially vRA communicates with Ansible Tower, and places the machine in the appropriate static inventory within Tower. As part of that process, you can dynamically register that machine within the appropriate inventory groups and also transfer over the entire payload for use as part of the job template.
Sid then walked us through how to integrate Ansible Tower using static inventory. vRA will communicate with Ansible Tower and place the machine into the appropriate static inventory within Tower. As part of that process, vRA can dynamically register that machine into the appropriate inventory groups and also transfer the entire vRA payload to AT as well for use as part of the job template. As part of that deployment, you can go ahead and execute the job templates (single or multiple) that you want to deploy.
In a decommission event within vRA, you can also execute deprovision job templates if you need to deprovision job templates from the machine before it’s destroyed.
Use Case 3: SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory (14:10 – 15:45)
To begin the third use case, Sid describes how, initially, there’s an inventory profile configured within vRA that tells Ansible what it should be pulling from within vRA. This inventory profile allows you to configure filters, such as “only machines from a particular business unit” or “only machines with certain properties within vRA”. Once that profile is created, Ansible can then reach out to vRA and pull in the machines that match this criteria into the appropriate inventory. And, much like we saw with static deployments, it can then associate them dynamically with the appropriate inventory groups as well as bring over payload data associated with those machines. It also can then execute job templates associated with that inventory without needing a provisioning event to happen within vRA.
Of course, you may want this to occur as part of a provisioning event, which we can do as well, by invoking that inventory process to take place, and applying the appropriate job templates to the inventoried machine that’s part of that deployment. We can also invoke those deprovisioned job templates and remove that machine from inventory when it is decommissioned from within vRA.
Use Case 4: SovLabs Ansible Tower Plugin for vRealize Automation CM Framework (15:46 – 18:48)
This process is slightly different than the data driven approach where you might build more specific blueprints that have specific configurations contained within and invoke that blueprint by calling it rather than driving it via specific data. Those configurations then invoke our modules and tell them what needs to happen. This approach works with the SovLabs module and the CM Framework, but it’s also important to point out you can take a hybrid approach, where some of the components within the blueprint can be driven dynamically via data and others are statically configured within the blueprint.
Visually, it’s also a Drag-n-Drop canvas based approach. When you build your blueprints on the canvas you can simply Drag-n-Drop the Ansible Tower models and invoke the appropriate job template that you want in relationship to the component machines that are part of the blueprint.
You can invoke the job templates to be deployed as part of the deployment event where the Apache modules are associated with machines on the canvas, and you can associate job templates and deprovision job templates.
Other benefits of the SovLabs Ansible Tower Plugin for vRealize Automation CM Framework include being able to see the status of the provisioning event within vRA itself. You can see the job templates listed, what their status is, and also be able to see them on a decommissioned machine.
SovLabs Ansible Tower Integration Comparison (18:49 – 19:48)
You get all these capabilities with your SovLabs Ansible Tower Module license. Based on your use cases, you may want to use different configurations. For example, for a brown-field environment, the dynamic inventory for the CM Framework is going to be more conducive so you can query and bring in pre existing workloads from vRA.
For greenfield deployments, any one of the modules can be sufficient depending on your needs and use cases.
In order to leverage the CM Framework Module, vRA Enterprise is required.
Lab Environment Demonstrations of SovLabs, Ansible Tower, and vRealize Automation (19:49 – 35:08)
For the remaining 15 minutes or so, Sid shares his screen to demonstrate exactly how to perform the operations that he just described in his slides. Watch the video to learn exactly how to perform these tasks to expertly integrate Ansible Tower with vRealize Automation.
There was a short Q&A session, which we will publish in a future post. Thank you for catching up on the webinar, Best Practices For Integrating vRealize Automation and Ansible. Please follow SovLabs on Twitter or LinkedIn to learn about future webinars.
