If you ever want to start an interoffice hunger games struggle, suggest changing your corporate hostname standard. If you do succeed to move forward on a new naming standard, getting there by committee makes Brexit look easy. I started researching this topic expecting to show the limited capability of the vRA built-in custom naming and then diving directly into vRO event broker workflows to meet those pesky hostname requirements. I was surprised how far I could get using only native vRA constructs to meet a naming standard and saving the vRO implementation for another day.
Here is the naming standard I am using which lets me identify several meta data items from just the name:
< Environment >< OS Type > – < Project Code > – < Server usage ><### Sequence>
- Environment – first initial of environments ( devl/test/staging/prod)
- OS Type – first initial of windows/linux
- Project Code – unique 3 digit value added as custom property on each project
- Server usage – (a/d/w/k) for application, database, web, or container server
- <### Sequence > – 3 digit number
For example – a development photon server running containers for project Tango which has a project code of CAS:
dl-cas-k001
First look at the Custom Naming on the projects shows it is fairly limited. Name can be configured to use various properties from the project, resource, endpoint and generated sequence (it says random but it is an increasing number sequence).
The biggest constraint with the custom naming template is user input during provisioning cannot be directly configured on the tamplate and it is not practical for the example naming standard which includes environments, os and server types.
This is where I originally planned to abandon built-in and go custom vRO, but then I started looking blueprint functions capabilities to manipulate the resource name. I set custom name template simply to:
${resource.name}${###}
On the blueprint I added inputs allowing the user to select the for deployment choices and which are also required for the naming standard.
I then leveraged the cloud assembly blueprint functions to build the resource name. The property value combines inputs, project properties, and functions to build the resource name to meet the standard. Here is the expression set for the name property on the resource to meet the naming standard (full blueprint is provided at end of post for reference):
properties: name: '${input.environment}${substring(input.image,0,1) == "w" ? "w" : "l"}-${to_lower(resource.network.projectCode)}-${input.servertype}'
I did hit an interesting gotcha. The project custom property (projectCode) is automatically injected to all resources, but it appears to be an ordering issue if attempting to use “self.projectCode”. I had to reference it from the network resource which is always configured before the VM resource.
As you can see from the deployments the servers are getting named according to standard based on the requests.
Project Lab: Production, windows, database server
Project Pacific: 3 Staging, centos, container servers
Project Tango: 2 Development, centos, application servers
The VM’s are also registered in DNS with the generated name:
At this point I still do not have any validation against DNS, AD, or CMDB to check if the names are unique and the objects do not exist. Hoping this validation becomes part of the custom name ability in vRA in future releases. I would have to default back to vRO/ABX today.
Would I use this for a large environment? No. I need the validation. vRO could be used to integrate with a hostname service or even provide a hostname service via XaaS for manual builds. This method would require modifying of all blueprints if a standards changed and is error prone depending on the blueprinter as well. But this proved to be an interesting experiment in the lab and forced me to learn the functions and expressions available on the blueprint.
Blueprint with inputs and functions:
formatVersion: 1 inputs: image: type: string title: Operating System description: The operating system version to use. enum: - centos - photon - windows 2016 - windows 2019 default: centos size: type: string title: Size description: How big do you need it. enum: - small - medium - large default: small environment: type: string title: Environment description: Target Application Environment oneOf: - title: Development const: d - title: Test const: t - title: Staging const: s - title: Production const: p default: d count: type: integer title: Count description: Number of VMs maximum: 8 minimum: 1 default: 1 servertype: type: string title: Server Usage description: Server usage for VM oneOf: - title: Webserver const: w - title: Appserver const: a - title: Database const: d - title: Container const: k resources: vm: type: Cloud.vSphere.Machine metadata: layoutPosition: - 0 - 0 properties: customizationSpec: '${substring(input.image,0,1) == "w" ? "windows" : "linux"}' image: '${input.image}' name: '${input.environment}${substring(input.image,0,1) == "w" ? "w" : "l"}-${to_lower(resource.network.projectCode)}-${input.servertype}' flavor: '${input.size}' count: '${input.count}' networks: - network: '${resource.network.id}' attachedDisks: [] network: type: Cloud.vSphere.Network metadata: layoutPosition: - 1 - 0 properties: networkType: existing
Until next time…
Anytime you learn, you gain. -Bob Ross
One thought on “A Virtual Machine by any other name would smell as sweet”