Before going into the details I would like to express my thanks to Andreas Diemer, Martin Kosturkov and Christian Liebner for their support in development and testing!
Infrastructure as a Service is one of the key use cases of the VMware vRealize Automation solution. While there’s comprehensive ways to create simple or advanced blueprints, customers must provide the required templates for vSphere VM deployments by themselves. The original installation and preparation of a template is something most customers are used to and can quickly be organized. But how about maintenance of the templates over their lifecycle? How do you make sure that templates are kept up-to-date and are getting latest updates permanently or on a regular base?
This article describes how such a process to update vSphere templates can be established using VMware vRealize Automation Codestream.
Codestream is an integrated component of vRealize Automation Cloud (SaaS). If customers would like to use the on-premise version, they need the Enterprise Edition of vRealize Automation 8.x. Codestream has also been available in older versions, but this article refers to the latest and greatest as part of the vRealize Automation 8.x architecture. As both vRealize Automation Cloud and vRealize Automation 8.x share the same architecture, the process is almost identical with minor modifications that might be required.
The principle here has been tested and verified with vRealize Automation Cloud.
One benefit of the new vRealize Automation architecture is that it works with so called image mappings. This is an architectural pillar of the cloud-agnostic architecture. Consumers use image mappings in their blueprints which have a user-friendly description of the image to be used for deployments – like “CentOS 7 x64” or Windows 2016 Standard”. Each image mapping is defined by the platform administrator and maps to the real image on the underlying platform in the background. This means that “CentOS 7 x64” might use a template called “CentOS-7-x64-2020-04-20” or similar which is completely hidden for the consumer. As a result, when the template mapping is updated there’s no change for the user requesting it in a blueprint.
Image mappings do support cross-cloud capabilities as well which is however not explained more deeply in this blog.
Automatic Template Update
When platform administrators need to update their templates, by default they need to do this manually. Depending on their desired cadence they need to do high level steps like changing the template to VM, start it up, run updates on it, make template again and update vRealize Automation configuration.
To automate this process, I have developed a Codestream pipeline that exactly is doing this job fully automatically. The pipeline leverages vRealize Orchestrator in the background for various tasks and talks to vRealize Automation API by REST to update configuration. Following tasks are executed prgrammatically:
- Clone of Template (current date and time added to name like Template-XYZ-2020-04-20-11-00)
- Change new Template to VM
- Start of VM
- Execute CLI task on VM (Linux in this example)
- Shutdown of VM
- Change new VM to Template
- Update Image Mapping on vRA
Deploying the solution
Find here the steps required to deploy the solution into your environment.
- vRealize Orchestrator installation on-premise (version 7.x as well as 8.x works)
- vRealize Automation Cloud account (vRealize Automation 8.x will work as well with slight modifications of Codestream pipeline)
- VM Linux Template (in my case CentOS 7 was used)
- Image mapping with related blueprint configuration on vRealize Automation
Step 1: Import of Orchestrator package
I recon everybody is familiar with importing an orchestrator package.
Download the Orchestrator Package. (unzip before use)
Step 2: Creation of vRealize Orchestrator Endpoint in Codestream
For a few tasks vRealize Orchestrator workflows are leveraged. Hence, it’s important to create an Orchestrator endpoint in Codestream. For on-premise access of vRealize Automation Cloud a cloud proxy must be deployed beforehand.
Step 3: Creation of Agent endpoint in Codestream
Codestream requires a reference to the Cloud Proxy used by adding an Agent endpoint.
Step 4: Modify Codestream yaml file
Download the Codestream Export. (unzip before use)
The provided Codestream yaml file “Automatic Template Update.yaml” does need modification prior to import to customize it for the target environment. Simply search for “!!CUSTOM!!” (without quotes) in the document and replace the string with the value of your environment:
- Reference to “project” requires your project name as value
- References to “vroServer” requires your created endpoint name from step 2 as value
- References to “agent” requires your created endpoint name from step 3 as value
After modification of the file please save it and import it in Codestream. Use “YAML”, “Create” and “read from file” as import options in the dialog.
Step 5: Check Pipeline and add input values
Open the pipeline in the editor and save it. This should show if save works fine or if there’s warning symbols on any of the steps in the pipeline. In case you face warning symbols (which shouldn’t be) you must solve them before the pipeline runs.
Move to the “Input” tab and insert all required input parameters. The API token can be retrieved from your account settings in vRealize Automation Cloud.
Run the pipeline
After all installation and configuration steps have been performed, the pipeline should run fine. When the pipeline has executed properly, you will see a new template of the one you mentioned with the current date/time added in your vCenter. Also, your image mapping will be updated accordingly.
- Dynamic Network Selection in request form with vRealize Automation 8 (part 2) - 21. May 2021
- vSphere with Tanzu with NSX-T medium sized edge - 8. January 2021
- Self-Service user onboarding in vRealize Automation - 17. December 2020