VMware Cloud Assembly is part of the new SaaS based VMware Cloud Automation Services offering, a set of cloud management services that was launched at VMworld US 2018. In a first post on Cloud Assembly I introduced the concept of the cloud agnostic machine, an component in a Cloud Assembly blueprint that allows you to deploy exactly the same blueprint to different clouds: currently supported are vSphere, AWS and Azure. In this post I want to dive a little deeper in this concept, and show you how to build a cloud agnostic blueprint which also provides you with options to select your cloud of choice during the initial request.
If you want first want to learn more about the basics of Cloud Assembly, read this article first: VMworld 2018 – A first look at VMware Cloud Assembly – Cloud Management-as-a-Service.
In this post we’re going to have a closer look at the coding part of the following blueprint:
The YAML code for this blueprint is:
inputs:
environment:
type: string
enum:
- production
- test
description: Production or test deployment
title: Deployment type
osimage:
type: string
enum:
- CentOS7
- Ubuntu-16.04-LTS
description: Choose your Linux distribution
title: Linux OS
resources:
vm01:
type: Cloud.Machine
properties:
image: '${input.osimage}'
flavor: nano
networks:
- name: '${MyNetwork01.name}'
assignPublicIpAddress: true
constraints:
- tag: 'environment:${input.environment}'
MyNetwork01:
type: Cloud.Network
properties:
name: MyNetwork01
The code consists of two parts, an input part that is used to gather input parameters when the blueprint is deployed. On top of that there’s also a resources part, that includes the virtual machine and network components that are used in this blueprint. The trick is that the input part is used to select the environment, and the image that will be deployed. For the environment we have two options in this example: test (running on AWS) and production (running on-premises vSphere). For the image part we also have two options: CentOS7 and Ubuntu-16.04-LTS.
The input part is actually setting two variables in YAML code, namely ${input.environment} and ${input.osimage}. These two variables are used in the resources part of the YAML code and will determine the selected image and also set a capability tag. The image variable is linked to the configured image flavors (read more about falvors in my previous article) in the environment. The capability tag is used to select AWS or vSphere, because the tag “environment:test” is linked to AWS and “environment:production” is linked to vSphere.
After you’ve selected the preferred image and environment at the request screen, the blueprint will be deployed to the cloud of choice!
