The challenge with build automation is too much convenience
Think about it. If it's easy to compose and deploy workloads, it's also easy to develop sprawl, and a good system designer would have methods in place to mitigate that.
In a previous post I covered how to deploy vSphere VMs with Ansible and the Automation Value Proposition that comes with it:
Providing this capability to a company as-is is hazardous. Ask the following questions, in rough order of priority:
- How do we track decommissions/unused machines?
- How do we track who owns / uses what?
- How do we track what OS images are end-of-life?
- How do we track resource consumption (e.g. IP usage) and avoid re-using addresses?
- How do we track certificates?
VMs also don't do much good without customization, unless you're comfortable handing those root credentials to whomever wants them.
System Integration
Linux heads live for this type of work - we return to the Unix design principles where a system or subsystem should excel at a single task instead of solving all possible issues at the expense of quality.
Let's explore a multi-system integration:
For this example, we'll re-implement the previous VM build process, but orchestrate it with GitHub Actions. I'll provide a gist at the end of this post.
I don't keep my vCenter exposed to the internet, so there will be some preparation required for this Action to function. We're using several prerequisites, install them first:
1python3 -m pip install aiohttp pynetbox
2ansible-galaxy collection install vmware.vmware_rest netbox.netbox
This Action leverages parameterization heavily, with Ansible relying on variables injected from GitHub to the virtual environment (venv). It provides a little "quiz" that will let consumers define attributes about the deployed machine, e.g. vCPU count and memory. Any input sanitization should be done by Ansible in this context.
Once a VM deployed, the vmware_rest module returns the virtual machine's Managed Object ID (MOID). We can use that to get operational data about the VM via VMware Tools.
Ansible keeps all of this data as registered variables for future utilization. Now, we have to put the data somewhere persistent. Netbox is a valuable tool for documenting information assets, but it can also be used as an Inventory. We can dump all the information about the VM into netbox rather easily, and pave the way for further customization seamlessly.
Note: I excluded the Guest Customization play in this version of the deployment script. It hasn't been particularly stable across 8.x releases with my automated testing, either failing completely with a Service Unavailable or crashing vCenter. It is possible, however, to change IP addresses, install packages, copy artifacts with Ansible after the fact. Customization via Ansible might even be a better approach in more complex deployments.
@import url('https://cdn.rawgit.com/lonekorean/gist-syntax-themes/d49b91b3/stylesheets/idle-fingers.css');
@import url('https://fonts.googleapis.com/css?family=Open+Sans');
body {
font: 16px 'Open Sans', sans-serif;
}
body .gist .gist-file {
border-color: #555 #555 #444
}
body .gist .gist-data {
border-color: #555
}
body .gist .gist-meta {
color: #ffffff;
background: #373737;
}
body .gist .gist-meta a {
color: #ffffff
}
Top comments (0)