There have been a couple of blogs written about Ansible and vRealize Automation in the past. I posted a few of them at the bottom of this blog for reference. However in this blog I wanted to highlight the integration in a bit more depth and update you on some new features that may be of interest. I will be focusing on Ansible Open Source in this blog, I did write a blog on our integration with Ansible Tower that you can find here.
I get asked quite often how the integration between vRealize Automation and Ansible works and what can be done. The end result is fairly easy to explain, we can execute an Ansible Playbook on a machine at time of deployment. Pretty simple yes, but there are various ways to use Ansible and configure playbooks, variables and connections. So lets deep dive into the use cases and primary integration features.
Quick Review on Ansible Integration
The Ansible open-source provider for the vRealize Automation blueprint service runs one or more given playbook(s) in the given order when a new machine is provisioned and this process automates the configuration management for application deployments and system configurations. Optionally, one or more playbook(s) can be provided to run before the machine is deleted as well.
Ansible has host_key_checking enabled by default. If a host is re-installed and has a different key in “known_hosts”, this will result in an error message until corrected. To avoid this then set host_key_checked = False in the ansible.cfg file.
Ansible Vault is a feature that allows for the storing of sensitive data such as passwords. Vault is encrypted with a password. vRealize Automation Ansible integration uses vault to encrypt data such as ssh password to host machine. Ensure your ansible.cfg is pointing to your vault location via the vault_password_file parameter.
Within vRealize Automation go to Infrastructure –> Integrations and click “Add Integration”. There you will see the Ansible tile. Fill in the fields to connect to your Ansible Control Machine and you can start creating blueprints and call playbooks.
If you check the Use Sudo Command for this User checkbox set to true, then in linux the user must have NOPASSWD in the sudoers rules. This is for linux only.
Creating the Blueprint
Within vRealize Automation blueprints can be created by going to Design —> Blueprints and click “New” or if you are source controlling blueprints in gitlab or github then they should appear in your blueprint list if a sync has been done.
If you are creating a blueprint from scratch then simply drag and drop a Cloud Agnostic machine onto the canvas (or any Virtual Machine type you want to use) and then drag a network and then find the Ansible object on the left hand side.
Then you can drag the dependency line to the machine(s) you want the Ansible playbook to run on or you can modify the YAML code under the Ansible object
host: ‘${resource.Cloud_Machine_1.*}’
There are a few properties that need to be filled out in the blueprint. I will highlight just a few here:
inventoryFile – path to the inventory file (default is /etc/ansible/hosts)
osType – Linux or Windows, the osType selection will tell ansible whether to use SSH or WinRM as the default connection method
privateKeyFile – besides usename/password option to connect from Ansible Control Machine to the Node you can setup a private key file
hostVariables – allow for connection variables to be set on the node. In order to see the host_vars that were configured in previous deployments you can go to the ansible control machine and navigate to /etc/ansible/host_vars and you will see the IP addresses of the machines deployed. Go into the directory of the machine you are interested in and open up the file vra_user_host_vars.yml
Here is a sample blueprint.
Multi-Cloud Deployments
One of the main reasons why organizations adopt vRealize Automation is the extensive multi-cloud capabilities. When we discuss Ansible integration that use case is just as relevant and achievable. Many customers who use the Ansible integration deploy machines into AWS or Azure and then run the playbooks on those cloud machines even if the Ansible Control Machine is a virtual machine within vCenter.
Using private_key_files we can create a secure connection from Ansible Control machine to the cloud machine node and still achieve our multi-cloud goals. Here is an example blueprint.
vRealize Automation also supports machines that do not have a public IP address. This can be handy when deploying a machine behind a secure Secure VPC or Azure Private Network and you do not want to expose the public IP. For machines provisioned the address property in the create resource is only populated when the machine is connected to a public network. The Ansible Integration looks at the deviceIndex for the Virtual Machine (the index of the NIC attached to the machine). If the deviceIndex property is not set in the blueprint, the first network attached is used.
Example of the property in the blueprint, this if found under the network property within the virtual machine object.
New Features Worth Mentioning
We now support playbook level variables that can be optionally specified along with the playbook path. Users can provide the playbook level variables using -e or -extra-vars option in the blueprint yaml. Here is an example:
Syntax to specify variables can be any of the following:
Key-Value Pairs:
Values passed in using the key=value syntax are interpreted as strings. User can use the JSON format if needed to pass in anything that should not be a string (Boolean, integer, float, lists, etc.).
JSON format example:
For more information about Ansible Vars see this in the Ansible Docs – https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html
Hopefully this update on our Ansible Open Source integration was helpful! Here are some other blogs about our Ansible Integration that you might find useful.
Ansible Tower Integration with vRealize Automation
Ansible Integration Comes to Cloud Assembly!
Cloud Assembly VM Guest Management With Ansible
