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.
- Ansible Tower initiates the request
- vRA receives the request and provisions the machine
- SovLabs integrations perform all the needed integrations
- SovLabs Ansible Tower module registers the machine to the Ansible Tower Inventory
- SovLabs Ansible Tower module invokes the requested Ansible Tower Job Templates against the deployed machine.
Something to think about before you begin
Consider the blueprint(s) you will build within vRA. While you may have many blueprints and may want to change your Ansible request to use different blueprints for different requests, there is a better way. In our three-part series called “Harness the power of vRealize Automation with the SovLabs Property Toolkit and Template Engine”, we walk you through how to create a dynamically-driven blueprint. This methodology will allow you to utilize a single blueprint and pass in parameters to drive the outcome.
I will use the same approach covered in the “Harness the Power” series for this blog, utilizing a single blueprint, and passing in the appropriate information from Ansible that vRA will use to deploy exactly what we need, bolstered by the SovLabs modules.
How to set it up
First, you need to create your yaml file that will invoke the script needed to call vRA. In my case that yaml looks like this:
name: deploy-vRA-VM
remote_user: root
connection: ssh
gather_facts: yes
hosts: all
tasks:
- name: deploy-vRA-VM
script: /opt/sovlabs/vra_request.shNothing fancy, but it gets the job done. You can, of course, use facts to parameterize this yaml file however you like. The example I’m showing has static settings just to illustrate the point.
Next, we need the script that is referenced in the yaml. In this case, my script is called vra_request.sh. The content of that script is below:
#!/bin/sh
vAPI_TOKEN="$(curl -s --insecure -H "Accept: application/json" -H 'Content-Type: application/json' --data '{"username":"user@domain.com","password":"XXXXXXXX","tenant":"demo-001"}' https://fqdn.vra.appliance/identity/api/tokens | cut -d\: -f5 | cut -d\, -f1 | awk '{print substr($0, 2, length($0) - 2)}' | tr -d "\n")"
AUTH="Bearer ${vAPI_TOKEN}"
curl --insecure -X POST \
'https://vra75demo.sovlabs.net/catalog-service/api/consumer/entitledCatalogItems/0c3b6bda-782c-456e-a180-ba02c4821d65/requests?businessGroupId=&requestedFor=vrasvc@sovlabs.net' \
-H 'Accept: application/json' \
-H "Authorization: $AUTH" \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Content-Type: application/json' \
-H 'Host: vra75demo.sovlabs.net' \
-H 'Postman-Token: dd84c77f-3132-407a-94ef-f019989bcd75,363ce053-1a96-48e2-81d3-a880004e83a4' \
-H 'User-Agent: PostmanRuntime/7.13.0' \
-H 'accept-encoding: gzip, deflate' \
-H 'cache-control: no-cache' \
-H 'consumer-catalog-item-guid: 0c3b6bda-782c-456e-a180-ba02c4821d65' \
-H 'content-length: 2700' \
-d '{
"type": "com.vmware.vcac.catalog.domain.request.CatalogItemProvisioningRequest",
"catalogItemId": "0c3b6bda-782c-456e-a180-ba02c4821d65",
"requestedFor": "user@domaint",
"businessGroupId": "",
"description": null,
"reasons": null,
"data":
{
"App_Function":"",
"ComponentMachine":
{
"componentTypeId":"com.vmware.csp.component.cafe.composition",
"componentId":null,"classId":"Blueprint.Component.Declaration",
"typeFilter":"NewServerRequest*ComponentMachine",
"data":
{
"Container.Auth.Password":"s2enc~+KphdnFNZDd0+Dx8NV0tRw==",
"LinuxVersion":"",
"SVL_Size":"",
"WindowsVersion":"",
"_cluster":1,
"_hasChildren":false,
"cpu":1,
"datacenter_location":null,
"description":null,
"disks":
[
{
"componentTypeId":"com.vmware.csp.iaas.blueprint.service",
"componentId":null,
"classId":"Infrastructure.Compute.Machine.MachineDisk",
"typeFilter":null,
"data":
{
"capacity":16,
"custom_properties":null,
"id":1541606812057,
"initial_location":"",
"is_clone":true,
"label":"Hard disk 1",
"storage_reservation_policy":"",
"userCreated":false,
"volumeId":0
}
}
],
"display_location":false,
"guest_customization_specification":"Linux",
"machine_prefix":null,
"max_network_adapters":-1,
"max_per_user":0,
"max_volumes":60,
"memory":256,
"nics":null,
"os_arch":"x86_64",
"os_distribution":null,
"os_type":"Linux",
"os_version":null,
"ovfAuthNeeded":false,
"ovf_proxy_endpoint":null,
"ovf_url":null,
"ovf_url_pwd":null,
"ovf_url_username":null,
"ovf_use_proxy":false,
"property_groups":null,
"reservation_policy":"null",
"security_groups":[],
"security_tags":[],
"snapshot_name":null,
"source_machine_external_snapshot":null,
"source_machine_vmsnapshot":null,
"storage":16
}
},
"SVL_App":"SVL_App_Apache",
"SVL_Compliance":"SVL_Compliance_None",
"SVL_Env":"SVL_Env_Production",
"SVL_Size":"SVL_Size_",
"_deploymentName":"Ansible",
"_leaseDays":"1",
"_number_of_instances":"1",
"test_property":"test_value"
}
}'In the above script, there are six inputs that are important to me. These inputs are the only ones I will ever change and they are used to drive the outcome I am trying to achieve. I should also point out that a lot of what you see above is very specific to my blueprint, so you should expect significant editing if you want this same script to work with your blueprints.
In my environment I can drive over 600+ different outcomes from a single blueprint just by passing a different input for the following 4 of my important input properties:
- SVL_App
- SVL_Compliance
- SVL_Env
- SVL_Size
Having architected the solution this way, I could simply publish documentation that details the acceptable values that each input takes and pass that documentation on to whoever wants to consume vRA. The documentation may need some updates as I add more values, but there is no need to publish information on dozens of blueprints (or more) and their inputs and values: I just need one blueprint.
The last piece of the integration of VMware vRealize Automation and Red Hat Ansible is to create a Job Template. You do need to have vRA setup and ready to go with your blueprint and the integrations you want to use, including the Ansible Tower integrations for Inventory and Job Template execution. We will look at these components in the next three articles in this series.
The original article can be found on the SovLabs Blog here.
