CloudInit via VMware Aria Automation Orchestrator – Part 2

The automatic and unattended installation of virtual machines can be achieved with several techniques. In this series, I´ll show the approach of using CloudInit together with VMware Aria Automation Orchestrator. This will be realized by the use of Guest OS Customization of the specific VM.

In Part 2 we will focus on creating the necessary Guest OS Customization data.

Guest OS Customization

To use these Customizations we have to set Advanced Configuration parameters to each VM that should be deployed from your templates.

According to the cloud-init documentation, there is a total of six variables we could set, although you always have to set two of them as a pair.

Property	Description
guestinfo.metadata	A YAML or JSON document containing the cloud-init metadata.
guestinfo.metadata.encoding	The encoding type for guestinfo.metadata.
guestinfo.userdata	A YAML document containing the cloud-init user data.
guestinfo.userdata.encoding	The encoding type for guestinfo.userdata.
guestinfo.vendordata	A YAML document containing the cloud-init vendor data.
guestinfo.vendordata.encoding	The encoding type for guestinfo.vendordata.

All guestinfo.*.encoding values may be set to base64 or gzip+base64.

In this guide we´re going to only use the metadata and userdata, but it could be easily extended to also support the vendordata.

---

To deploy a new VM from our template and with our set of customizations the workflow will roughly look like this:

• Clone VM from Template
• Generate Guestinfo data
• Apply Guestinfo data to the new VM
• PowerOn the VM and wait till cloud-init is done

And here comes our first problem, VMware Aria Automation Orchestrator does not have a module to generate base64 encoded data, nor can he gzip any data (at least I couldn´t find a way).

To counter these problems I´m using an extra webserver that will serve two PHP-based scripts to generate and provide the needed yaml files together with the right encoding and compression.

In the sample code for this article all necessary information is passed to those scripts during their call. But you could also change this to some kind of a database backend, then it could be enough to just send a hostname to the script and it fetches all the other data from the database.

The helping Apache

To provide those two scripts I´ve setup a small apache server together with the necessary changes for PHP to create yaml files. The setup is based on a RHEL9.3 installation, for reduced complexity I´m using simple HTTP and basic security functions for this example. If you should use this in a production environment I strongly advise using https, local firewall and so on.

First, we have to include EPEL to the installation

yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Now we can install apache with the needed addons

yum -y install httpd php php-pecl-yaml

Open http ports for the local firewall

firewall-cmd --add-service http --permanent
firewall-cmd --reload

Then start and enable apache to start at boot time

systemctl enable httpd
systemctl start httpd

The metadata helper

The metadata yaml file holds information for the setup of the VM. In this example, we set the hostname together with a static IP address during the boot process.

---
local-hostname: demohost
instance-id: demohost
hostname: demohost
network:
  version: 2
  ethernets:
    ens33:
      addresses:
      - 192.168.0.100/24
      routes:
      - to: 0.0.0.0/0
        via: 192.168.0.1
      nameservers:
        search:
        - sddc.local
        addresses:
        - 192.168.0.1
        - 192.168.0.2
...

This YAML will accomplish the just-mentioned changes to the VM.
The default route has to be set to 0.0.0.0/0 instead of just “default” which would break the RHEL deployment.

The example PHP code to produce this YAML and output it as gzip+base64 encoded string looks like this.

<?php
$hostname = $_GET["hostname"];
$ip = $_GET["ip"];
$cidr = $_GET["cidr"];
$gateway = $_GET["gateway"];
$dns_search = $_GET["dns_search"];
$dns1 = $_GET["dns1"];
$dns2 = $_GET["dns2"];

$metadata_linux = array (
    "local-hostname"=> $hostname,
	"instance-id"=> $hostname,
    "hostname"=> $hostname,
    "network"=> array(
		"version"=> 2,
		"ethernets"=> array(
			
			"ens33"=> array(
				"addresses"=> array("$ip/$cidr"),
				"routes"=> array(array("to"=> "0.0.0.0/0", "via"=>"$gateway"),
				),
				"nameservers"=>array(
					"search"=>array("$dns_search"),
					"addresses"=>array("$dns1","$dns2"),
				),
			),	
		),
	),
);
  

//uncomment to see your YAML for debugging
//echo "<pre>";
//print_r(yaml_emit($metadata_linux));
//echo "</pre>";


$gzdata = gzencode(yaml_emit($metadata_linux), 9);
echo base64_encode($gzdata);
?>

As mentioned before I´ll pass all necessary variables directly to the script. For ease of demonstration, there are no error-handling routines. For a production use, you should definitely add those.

To get the above YAML file you can test call the script (don´t forget to uncomment the debug lines).

http://<IP of webserver>/metadata_linux.php?hostname=demohost&ip=192.168.0.100&cidr=24&gateway=192.168.0.1&dns_search=sddc.local&dns1=192.168.0.1&dns2=192.168.0.2

When calling the script you will also see the encoded data right below the YAML output. This string will later be fetched by the Orchestrator and put as Advanced Setting to your VM.

The userdata helper

Now we will handle the userdata, which was the more tricky part of this. When you look at the metadata YAML file you can see the file starts with “—“. Those three hyphens will crash the cloud-init parsing of the userdata as it has to start with “#cloud-config”.

A YAML file to create a user called “automation” with a provided ssh-key and full sudo rights would look like this.

#cloud-config
cloud_final_modules:
- users-groups
- always
users:
- name: automation
  groups: sudo
  shell: /bin/bash
  sudo: ALL=(ALL) NOPASSWD:ALL
  ssh-authorized-keys:
  - ecdsa-sha2-nistp256 AAAAE2VjZHNhLXcoYTItbmlzdAyNTYAAAAIbmlzdHAyNTYAAABBBPzHmRl4lkSrJ3HLF4v/AxPbqy6pb6L4vR8gBezMVNrnYiiHu921EiH8JoCBpfPoIP4V/Eg2WyFCzz+0oa6Qk=

To generate this data I´ve used this script

<?php
$userdata_linux = array (
	"cloud_final_modules" => array( "users-groups","always" ),
    "users"=> array(
		array(
			"name"=>"automation",
			"groups"=>"sudo",
			"shell"=>"/bin/bash",
			"sudo"=>"ALL=(ALL) NOPASSWD:ALL",
			"ssh-authorized-keys"=> array("ecdsa-sha2-nistp256 AAAAE2VjZHNhLXcoYTItbmlzdAyNTYAAAAIbmlzdHAyNTYAAABBBPzHmRl4lkSrJ3HLF4v/AxPbqy6pb6L4vR8gBezMVNrnYiiHu921EiH8JoCBpfPoIP4V/Eg2WyFCzz+0oa6Qk=")
		),
	),
);

//uncomment to see the original YAML file before modifying it

//echo "<pre>";
//print_r(yaml_emit($userdata_linux));
//echo "</pre>";

//remove YAML specific characters
$yaml = yaml_emit($userdata_linux, YAML_UTF8_ENCODING, YAML_LN_BREAK);
$yaml = preg_replace('/^---\s/', '', $yaml);
$yaml = preg_replace('/\.\.\.$/', '', $yaml);

//add "#cloud-config" to the top of the file and append the YAML data
$header = "#cloud-config\n";
$all = $header;
$all .= $yaml;


//uncomment to see the changed data
//echo "<pre>";
//print_r($all);
//echo "</pre>";


$gzdata = gzencode($all);
echo base64_encode($gzdata);
?>

Again, the last line will encode and compress the YAML data and present it as string which will be used by Orchestrator later.

---

As everything is prepared now, let´s hop over to Part 3 and Orchestrator and build a workflow to finally deploy some VMs.