Introduction
Many customers are leveraging configuration management tools like Ansible to do automated configuration management as well as application deployment in their infrastructure. vRealize Automation is perfectly suited to manage the underlying infrastructure layer and leverage Ansible on top for the application deployment and control.
There’s many good articles and blogs which explain in-depth how Ansible can be integrated with vRA like this one here http://www.vmtocloud.com/vra-ansible-integration-3-ways/
When I read these blogs I however had a more dynamic way in my mind for this type of integration. In a nutshell the idea has come up to place Ansible playbooks in a github repository, read them out through vRA and present them in a dropdown. Now the user should be able to select the proper playbook and deployment is automatically taking care about the actual installation through vRA and Ansible.
How does this sound?
Disclaimer
I need to mention at this point that I am not an Ansible expert nor somebody who has in-depth experience in writing best practice orchestrator workflows. This document is all about creating a demo case which works and shows the potential, it’s not intended to provide full guidance for a productive deployment.
Ansible
Ansible installation
To do a proper Ansible deployment an Ansible server is required. In my case I used a simple CentOS VM where I installed Ansible. There’s a lot of documentation on how to setup an Ansible server in the web, so I’ll only explain the relevant bullet points here
- Install Ansible with “yum install ansible”
- Modify /etc/ansible/ansible.cfg
- uncomment “disable host_key_checking”
- This is to make sure that a new host does not need to be added to the known_hosts file for proper SSH communication
The Orchestrator workflow used for this demo will download playbooks to /root/ansible-playbook-downloads. It will then create a temporary inventory file with “ansible-<IP>” notation and execute “ansible-playbook -i /root/ansible-<IP> /root/ansible-playbook-downloads/<playbookfilename>” going forward.
I am aware that Ansible is leveraging /etc/ansible/hosts inventory in most of the productive cases. To ease deployment for this demo case I decided to use the “-i" option which allows to specify an inventory file containing the target server IPs. With some effort the scripts obviously can be changed to modify hosts file properly.
Ansible playbooks
In my demo the ansible playbooks are stored on my github respository. There’s rather simple playbooks used for the initial use cases:
ansible-httpd-playbook.yml
- hosts: all
remote_user: root
tasks:
- name: httpd is installed
yum: name=httpd state=installed
- name: httpd is running and enabled
service: name=httpd state=started enabled=yes
ansible-mariadb-playbook.yml
- hosts: all
remote_user: root
tasks:
- name: mariadb is installed
yum: name=mariadb-server state=installed
- name: mariadb is running and enabled
service: name=mariadb state=started enabled=yes
SSH Key handling
Ansible is communicating through SSH protocol with its target hosts. For this it’s helpful having certificate-based authentication in place. For this demo I created an ssh-key on the Ansible server:
ssh-keygen -t rsa
After that the public key file /root/.ssh/authorized_keys file must be copied to the vRA/vRO server. If you don't want to change the defaults in the vRO workflow you should use the path mentioned here. Otherwise feel free to adapt it.
scp /root/.ssh/authorized_keys <vRO-host>:/etc/vco/app-server/data/authorized_keys
Login to the vRO server and set proper ownership:
chown vco:vco /etc/vco/app-server/data/authorized_keys
There’s an Orchestrator workflow in the package you are about to import below which includes a workflow that copies the above-mentioned file from Orchestrator server to the deployed target VM prior to executing the Ansible workflows.
Preparation in vRealize Orchestrator
Import Orchestrator Workflows
The Orchestrator workflows developed for this use case do leverage the guest script manager package for Orchestrator. Therefore, you have to download it in advance and import it into Orchestrator from this link:
https://code.vmware.com/samples/1317/guest-script-manager-package
Afterwards import the Orchestrator workflow package attached to this article. The package includes a high number of dependent workflows and actions which have to be imported or present before, but the most important one’s for this use case are:
- Workflow “Copy SSH Key”
Makes sure that the public SSH key is copied to the target VM enabling Ansible to start communication. - Workflow “Run Ansible Script on VM”
Downloads the Ansible playbook from GIT and runs the proper Ansible commands on the server to execute a playbook on the target VM. It leverages a script configuration resource also provided with this Orchestrator package. - Action “getGITFilenamesbyREST”
Reads filenames which includes yml in name from GIT repository. - Action “getGITDownloadURLbyREST”
Retrieves GIT Download URL for filename provided.
Registration of GIT REST Host
The workflows and actions issue REST calls to the github server. As these processes use a HTTPS connection, the related certificates must be imported to vRealize Orchestrator. To do this you have to run the “Add a REST host” workflow once pointing it to the github server:
Modification of Workflow Parameters
After successful import of the Orchestrator package you will find 2 new workflows in this directory.
The attributes of both workflows must be tailored to the target environment.
Most important values to change for “Copy SSH Key”:
- password: root password of target VM (to copy SSH key)
Most important values to change for “Run Ansible Script on VM”
- vm: Select VM where ansible has been installed
- vmPassword: insert root password for Ansible VM
- queryString: Modify repository URL if a different repository should be used
Preparation in vRA
Add Subscriptions in vRA
Actually there’s 2 subscriptions required in vRA to execute the imported vRO workflows, see screenshots below. It’s important to specify subscription priority to make sure that the workflows are executed in the correct order. Make sure that the subscriptions are published after creation.
Add Custom properties in vRA
There’s custom properties required to control the deployment process and add the playbook selection in the blueprint request form.
Adding playbook selection in request form
Create a new property definition as per screenshot below. Make sure you reference the Action “getGITFilenamesbyREST” as external script action and add the properties as needed:
- baseURL: https://api.github.com
- httpMethod: GET
- queryString: /repos/cferber/ansible-playbooks/contents (You can change this if different repository should be used. However you have to make sure it's changed accordingly in the attributes of the Orchestrator workflow above)
Adding property group for running SSH Key workflow
Adding property group for providing payload by EBS
Adding property group for running Ansible workflow
Prepare Linux Template in vRA
In this demo I did use a CentOS 7 template. A default installation of CentOS 7 should work straight away. I won’t explain how to create a CentOS 7 blueprint and publish it properly in this document, but this obviously will be required.
In addition it’s important to enable the property groups created above on the blueprint which makes sure that the workflows are executed at the right time in the provisioning process.
Final test and caveats
Now as you have configured everything properly you should be able to request a CentOS VM. The field “Select Ansible Playbook” should appear in the request form and your yml ansible playbook files available on github repository will be listed for selection.
If the playbook has been selected and request has been issued, deployment of VM should start and finish with application installed as per playbook selection.
If anything goes wrong, you have to leverage your vRA and vRO troubleshooting skills 🙂 I won’t go into detail on how to do this here.
One caveat I found was that there might be a race condition when multiple deployments run at the same time where one workflow might fail at the point where guest manager tries to modify files simultaneously. Manual re-run would work then however.
This is something that certainly could be solved. For the demo I would recommend only starting one deployment at a time.
Have fun!
