Integrating Red Hat Ansible Tower with VMware vRealize Automation is a very popular enterprise automation solution. SovLabs has several excellent integrations that can help you accomplish and scale your integration of these two powerful cloud automation tools. This article is the first in a series of four articles covering the integration of Red Hat Ansible Tower with VMware vRealize Automation, based primarily on the content and discussion from our webinar with Red Hat Ansible on May 22.
Requesting a vRealize Automation deployment from Ansible. How, and why you would want to do it.
The SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
The SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
The SovLabs Ansible Tower Plug-in for vRealize Automation CM Framework
Requesting a vRealize Automation deployment from Ansible
With Ansible Tower quickly growing in popularity, many developers and system administrators want to be able to utilize Ansible Tower to deploy infrastructure. This type of deployment is the subject of many debates within enterprise organizations, especially those with cloud teams trying to develop standards while enforcing policy and governance across organizations.
The good news is that organizations no longer have to choose between solutions. If you want to use Ansible to develop standards while enforcing policy and governance across organizations, now you can. Using the solution below you can request workloads from Ansible facilitated by vRA to enforce the desired standards and governance policies. Let’s take a look at how it works.
If I had a dollar for every time someone asked me, “Is there a place to define global properties in vRA?” throughout my career, I probably could have retired by now. The unfortunate answer to this question has always been “it does not”, but there is a way to apply properties to every request. Keep reading.
The Old Way
The old way to define global properties in vRA was to add the properties you wanted applied globally to each and every endpoint you had configured in vRA. So, if you had 25 endpoints and 20 properties you ended up have to enter 500 properties and 500 values. This method leads to inevitable typos, finger fatigue, and management overhead every time you need to update a value for any one of those properties or add a new property.
In Part 1 and Part 2 of this series, we created three inputs for our vRealize Automation blueprint: Production, WordPress, SOX compliance. These three inputs correspond to property groups that allow us to associate multiple custom properties to a single input. Using property groups allows us the ability to templatize how each input affects the outcome of a request. In this article, the Genie that we’ve previously released from the proverbial bottle is about to take form, as we walk through how these three inputs come together to determine the outcome of our request.
Let’s look at how the different input options impact the different modules.
In Part 1 of this series we walked through how you can use the SovLabs Property Toolkit and Template Engine to configure vRealize Automation (vRA) for our environment input. In this second part of the series, we’re going to walk through setting up the Application and Compliance inputs for our particular use case. If you are starting to see smoke, don’t be alarmed. It’s just our Genie being let out of the lamp.
In Part 1, we determined that the required options for our Application input will be:
Determine the Outcome
In this scenario, the selection of the application will have a significant impact on the outcome. However, while we need to think about the application, we also need to look at the larger picture. What do I mean by “the bigger picture”? Well, once we figure out the desired outcome for each of these items, we need to think about how each item relates to the environment and the choices we made in Part 1.
What if the requester chooses WordPress as the application and Production as the environment? Alternatively, what if they choose Microsoft SQL and Development? Will the outcome of the application differ based on the environment to which it is being deployed?
Some things to consider:
Do the workload specs change based on the environment selection?
Do development, test, and production instances have the same CPU and Memory requirements?
Do any of the integrations change based on application and environment?
Do WordPress and Microsoft SQL have the same backup requirements?
Does this requirement change based on which environment the workload is being deployed to?
Ever wish you were able to set more than one value from a single vRealize Automation (vRA) request input? Have you ever wished you could make some aspects of vRA more dynamic and flexible? Wish you could simplify the vRA request form? In this article I’m going to let the genie out of the bottle. All your wishes are about to come true. But before we summon our genie, let’s first dive into what it is that we are going to be wishing for. My wish is to have a simple vRA request page with only three inputs that can drive the outcome of every aspect of my request. Sounds too good to be true doesn’t it? We will find out soon enough.
Determine the needed Inputs
Determining what our inputs are going to be. For my scenario I need to the following three inputs:
The Environment (Production, Development, or Test)
The Application (WordPress or Microsoft SQL)
Compliance Needs (SOX or Non-SOX)
In my example, these are the only three items I need to know from the requester to build a server in my environment. The remaining info I can gather from the business group they belong to, what resources the workload is placed on, etc. I know every environment is different and many will require more than three inputs. Once you have read this entire 3-Part series, you will realize the number of inputs doesn’t matter. It’s how we use them that’s key.
Determine the outcome
What outcomes do we need to drive based on these inputs? Or, how will these help determine the outcome of the overall deployment? Will they influence items such as the machine hostname, Active Directory OU placement, vCenter Folder placement, vSphere tagging, application installation, etc?
If you have been to the VMware Solutions Exchange you most certainly have seen the name SovLabs. Although their solutions are regularly called plug-ins, I assure you they offer more than just orchestrator-based plug-ins. I first started working with their solutions earlier this year and I was instantly hooked. Many of you have used vRO extensions that were made available by Tom Bonanno or myself posted here on Dailyhypervisor. One in particular is the custom hostname extension for vRA. While that extension has helped hundreds if not more of you, many of you quickly discovered the downside of using it. That downside being management overhead and lack of support. As much as we would have liked to offer support to those in need we simply don’t have the bandwidth to do so. Even upgrading the extension we put out for new versions of vRA in a timely manner had its challenges for us.