A very frequently asked topic for VCF Automation is how to execute a script post provisioning of a VM. This usually is leveraged to invoke post deployment processes like configuration tasks, installation of agents or even middleware deployments. Customers also use it to bridge the gap to configuration management tools. There are multiple ways to achieve script execution with VCF Automation. Let me name a few of them to understand the variety and their preferences:
| Technology | Template preparation required | Flexibility | day-2 focus | Network connectivity required | out-of-the-box |
| Script in template | yes | low | no | no | yes |
| Cloud-init/Cloudbase-init | yes | middle | no | no | yes |
| SaltStack state file | no | high | yes | yes | requires SaltStack Server |
| Ansible playbook | no | high | yes | yes | requires Ansible Server |
| ABX action | no | middle | no | no | yes |
| VCF Orchestrator workflow | no | middle | no | no | yes |
And probably there are more. Even for single line items there might be multiple ways to do the task. All methods have their advantages and disadvantages as you can see in the table. While configuration management tools provide most flexibility, they require additional components to be installed and possibly additional licenses. On the other hand, the out-of-the-box capabilities don’t need additional components but typically have their focus in the boot strapping rather than full post deployment management.
In this blog I intentionally put focus on the Orchestrator way as it comes out-of-the-box, does not need network connectivity, supports all OS and still can be parametrized. In specific my goal was to provide a simple solution which is easy to understand and does not need to import a comprehensive package.
High level process
In a high level view we are starting a deployment through VCF Automation. With its extensibility feature an EBS event is triggered “post provisioning” of the VM. This event will be used for a subscription that runs a VCF Orchestrator workflow. Properties of the VM provisioning process are automatically handed over. The workflow will use the properties for accessing the guest OS through the VMTools and will run the script provided as defined in the properties. As the subscription is configured with “blocking” parameter, the VM provisioning task will wait until the workflow has successfully executed.
Orchestrator workflow
The solution shown here is based on the default workflow “Run Program in guest” which is part of every installation. This workflow executes a script in any guest operating system by leveraging the VMtools installed on it. While this workflow works fine standalone, there are some modifications required to integrate it with a VCF Automation deployment process. Therefore, I created another workflow based on this default workflow that adds the required components:
Find here the basic explanation of what each section is doing:
- Get VM object
It retrieves the vCenter VM object by the VM name provided from VCF Automation - Get run command details
Collects parameters for command execution from VCF Automation inputProperties - Vim3WaitToolsStarted
out-of-the-box action which waits until the VMTools are started in the guest OS - Run Script in VM
Main script from “Run Program in guest” that runs the guest script in the OS
For the next steps download the workflow package and import it into your VCF Orchestrator installation. The workflow configuration does not require any modification, although you certainly can tailor it to your needs if required.
VCF Automation Subscription
The Orchestrator workflow will be invoked by an EBS (event broker service) subscription. You need to create the subscription in VCF Automation as per below screen shots. Please wait until the VCF Orchestrator data collection has finished as otherwise you won’t see the imported workflow in the selection menu. You can verify the data collection process by going to Infrastructure -> Integrations -> embedded-vRO (provided the integrated Orchestrator is used)
It’s important to configure it with “blocking execution” as otherwise the VCF Automation workflow does not wait until it succeeded. Also make sure you add this “filter events in topic” to only invoke the workflow for the cloud templates that have the property “postscript: true”.
event.data.customProperties.postscript === "true"Cloud Template
As last step a cloud template which is doing a VM provisioning task is needed. I will not explain in detail how a cloud template is created. In general, it could be any type of cloud template, and it does not matter which OS is provisioned. The only requirement is that 4 properties must be populated.
- vmusername: <username in guest OS>
- vmpassword: <password in guest OS>
- scriptpath: <script to execute without parameters>
- scriptparameters: <parameters added to the script>
The username on the guest OS obviously needs appropriate permissions to execute the script. Many customers don’t want to store the user credentials in the cloud template which is why VCF Automation secrets can be used and referenced as well (see below). Secrets are configured in the “Infrastructure” tab of Aria Automation and stored in its database in a secure way.
The script is expected to be accessible in the OS template. It does not require any network connectivity per-se, however if it should be used to only invoke other scripts which e.g. are stored on a network share, obviously it requires network access.
In the example below the scriptparameters can also include variables from the cloud template like the VM name. It uses a standard template for a CentOS 8 linux VM.
formatVersion: 1
inputs: {}
resources:
Cloud_Network_1:
type: Cloud.Network
properties:
networkType: existing
centos:
type: Cloud.vSphere.Machine
properties:
image: CentOS8
cpuCount: 2
totalMemoryMB: 2048
postscript: true
vmusername: root
vmpassword: ${secret.deployment-root-password}
scriptpath: /usr/bin/echo
scriptparameters: '"The VM with name ${self.name} was deployed." > /tmp/echomessage'
networks:
- network: ${resource.Cloud_Network_1.id}
assignment: static
Testing the deployment
Now it comes to the final test which is just a normal deployment of the cloud template. If the process was successful, you should see a completed execution of the workflow in VCF Orchestrator. On the deployed guest OS there will be a file named “echomessage” in the /tmp directory which includes a simple sentence with the assigned VM name in it.
Have fun!
- VCF Automation – VM with post script execution - 18. December 2024