Aria Automation (aka vRealize Automation) has a built-in support for Ansible open-source and Ansible Tower / Ansible Automation Platform. Once a cloud account is defined for Ansible, customers can add Ansible elements to the design canvas and combine them with virtual machine objects. In this case after provisioning a virtual machine, an ansible playbook or job is executed which runs in-guest modifications or application installations. The whole process is controlled through Aria Automation. While this is a good integration for day-1 provisioning of resources, currently there is no out-of-the-box integration for day-2 actions related to Ansible resources. However, Aria Automation includes several options to accommodate this by custom day-2 actions.
In this blog I will explain how to create a custom day-2 action leveraging ABX actions with python code for execution on an Ansible open-source server. The same procedure could be used for Ansible Tower / Ansible Automation Platform as well. In this case there’s modifications to the code needed to replace SSH connection/execute tasks by REST API tasks.
Prerequisites
The following components are needed as pre-configuration. Please refer to official Aria Automation documentation how to achieve that:
- Aria Automation installation with Ansible support. I tested with vRealize Automation 8.11 and Aria Automation 8.12, but older versions should be fine as well.
- Ansible open-source server with Ansible open-source integration
- Cloud template which includes linux VM provisioning + ansible configuration management resource (this demo is using CentOS). You might want to use my example playbooks for demo purposes.
Create Assembler Secret
The ABX action will use user and password authentication to the Ansible host. If other authentication mechanisms are desired, the code needs to be modified. For the storage of the user password, we will use the Aria Automation Assembler secret store leveraging a secure design. Prior to import of the ABX action this secret must be created on the Automation platform:
It just requires a name for the secret and the proper value which will be encrypted.
Import of the ABX Action
First download the pre-defined ABX action. After that you need to import the zip file into the Extensibility part of Aria Automation and assign it to a project.
Customizing action parameters
You must edit the action and change settings to share it between projects as otherwise it will not be available for a custom resource action.
All action parameters are defined by input variables. The base principle assumes that there is an Ansible open-source server which hosts the playbooks locally for execution. If you want to use some simple example playbooks for demo purposes, you can download them from here.
In my case the playbooks are stored in the /root/playbooks directory. Feel free to modify it to your needs. Following input values must be provided:
- playbook: The value is just a placeholder/default value. We will see in a later step how the user can be provided with a dropdown selection of the playbook to execute.
- playbook-path: Path on the Ansible server where playbook files are stored
- ansible-hostname: FQDN of the Ansible server (must be resolvable and accessible from the Aria Automation appliance)
- ansible-username: username to access the Ansible server through SSH
- ansible-userpassword: password of the user to access the Ansible server through SSH
Creating a custom action
Aria Automation provides several out-of-the-box actions for existing object types that can be leveraged. This includes power actions for VMs, snapshots, adding disks etc. In addition, there’s the option to create custom resource actions e.g. to access 3rd party functionality.
Ansible objects do not have day-2 actions out-of-the-box for the time being, therefore, a custom action is the way to go. To configure a custom action following steps must be performed:
Go to the design tab in Assembler and create a resource action
Configure it as per screenshot below.
The Display name is the name of the action the user sees when opening the actions menu of the Ansible object. You can define if the action is available for any project or only for specific ones. Under Resource Type you define that the action appears under the Cloud.Ansible object and not under any other object type. With the Action/Workflow setting you select the ABX action that we previously imported and configured. Make sure that the action imported is configured to be shared between projects or it will not appear.
Keep all property bindings as they are and select “edit request parameters” before saving the resource action.
In the upcoming form designer, you can customize the form fields to your needs. In this demo I have been adding the available playbook files on the Ansible server for selection from a dropdown.
Finally save the custom form and save the resource action.
Testing the Configuration
Now it’s time to test the configuration. You will need a deployed cloud template that includes an ansible (open-source) object for that.
In my case you can see a postgresql.yml playbook has been executed. This means the system should have postgresql db installed, but no mariadb. You can prove that by logging in to the VM and running “yum list installed” (for a redhat-based OS).
On the Ansible object you’ll find a new day-2 action “Install Application (Ansible)”. If you have selected a different name for it, it will be shown accordingly.
After execution of the day-2 action the modified request form comes up which shows the label values of the dropdown entities. When selecting and submitting one of the entries, the yaml file names will be handed over to the ABX action and the playbook is executed by it.
Once the process has finished you should see that the VM now has mariadb packages installed.
Have fun!
- Approval with Jira change ticket - 4. January 2024
- Automated SaltStack Minion Updates through winrepo - 9. November 2023
- Automated SaltStack Minion Updates - 27. October 2023