VMware Cloud Assembly - Part 2 - Tags & Inputs

Published: Cloud-Services vRealize-Automation

Purpose

This is the second post on VMware Cloud Services specifically on Cloud Assembly(CAS). In this post I am going to talk about tags and inputs. As always, I will record a video on the same topics as well. This is for those friends who are more inclined towards visual learning than reading.

I sincerely hope you find this post useful.

Introduction

Before I even start, let me clear few facts. First, I am way behind the schedule for this post. This is due to a prolonged illness and a serious surgery. Second, VMware changed the name from VMware Cloud Services to vRealize Automation Cloud. This makes sense and is inline with the on-premises solution. So, currently vRealize Automation Cloud is the umbrella term for all of the Automation services, while Cloud Assembly is the solution which deals with the automation part.

Inputs on the other hand lets you customize the blueprints. This will in turn enable you to interact with end users and use those values at runtime to make decisions and influence deployment.

So, without much delay let’s delve in the topics.

Tags

First we will discuss Tags and then we will talk about inputs.

Why use Tags

The question that comes in mind is why do we need to learn about Tags and what’s the importance of this? In the new policy driven cloud world tags and a proper tagging strategy has become more important than ever. Without a proper Tagging strategy you cannot build a enterprise class cloud deployment. Besides a proper tagging will let us identify, classify and group different objects and build relationships based on that. This in turn will let us co-relate those objects in different products.

For example, if you define a tag in vCenter server, it will be discovered in Cloud Assembly and vRealize Operations Manager (vROps) both. So, in turn will let you co-relate and track the VM’s throughout these products.

Details

In respect of Cloud Assembly the following are true about tags:

  • It is the most critical component of Cloud Assembly that drives the placement of deployments
  • Tags are essentially labels that you add to Cloud Assembly items
  • It generally follows the name:value convention. Though you may create tags with name only (not advised)
  • In terms of origin, tags can be divided into two types - external tags & internal tags
    • External tags are tags that are defined in vCenter and then discovered and used by Cloud Assembly. These are visible both in vCenter and Cloud Assembly
    • Internal tags are tags that are defined in Cloud Assembly. These are seen and used only in Cloud Assembly.
  • In terms of nature, tags can be divided into two categories - capability tags & constraints tags
    • Capability tags are tags which defines capabilities of objects. For example, compute, storage, network etc.
    • Constraints tags are tags which defines types of constraints which we want to put in the deployments. These are typically defined in Blueprints and Projects, so that we restrict deployment based on the set criteria.
  • Also based on type, again tags can be categorized into two categories - Standard and User Defined
    • Standard Tags are tags which are already defined in Cloud Assembly. They come into existence once the deployment is done and we can access these values. Provided below is a list of these type of tags.
    • User Defined tags are tags defined by users. These are customizable and completely user defined.
  • If tags constraints are defined in both project and blueprint, then while deciding the placement, the constraints are merged. But in case of conflicting constraints (tags), the constraint defined in project takes precedence. We can avoid this precedence and in case of a conflict, can force the failure of deployment by setting the flag failOnConstraintMergeConflict
  • We can use 3 constraints per project. It can be hard or soft constraint. Hard constraints are always enforced and failure to comply will ensure failure of deployment. While failure to meet soft constraints will still enable deployment.
  • Constraints are typically defined in blueprint in the format - [!]tag_key[:tag_value][:hard|:soft]

How tags work

Provided below is a picture depicting how the tags work. Detailed explanation is provided in the video provided below.

  • Cloud zones are filtered by several criteria, including availability and profiles; tags in profiles for the region or the zone it belongs to are matched at this point.
  • Zone and compute capability tags are used to filter the remaining cloud zones by hard constraints.
  • Out of the filtered zones, priority is used to select a cloud zone. If there are several cloud zones with the same priority, they are sorted by matching soft constraints, using a combination of the cloud zone and compute capabilities.
  • After a cloud zone is selected, a host is selected by matching a series of filters, including hard & soft constraints as expressed in blueprints.
  • If tags on the project conflict with tags on the blueprint, the project tags take precedence

Implementation Considerations

Provided below are the points you need to consider before implementing Tags.

  • Typically, create tags for all different environments. For example, AWS, AZURE, vSphere
  • Consider different computer resources and create tags accordingly. E.g. Production-Cluster, Test-Cluster etc.
  • Create tags based on region or locations. Typically, create tags, at the profile level, that represents each of these different regions or locations.
  • Categorize and create tags for different storages. For example, Tier1, Tier2 etc.
  • Categorize networking options and create tags to accommodate all applicable options. E.g. DMZ, DB_LAN etc.
  • Create and coordinate blueprint constraint tags and cloud zone capability tags that match. E.g. Test, Dev, Production.
  • Coordinate tags on network and storage resources so that they make logical sense in context of the network and storage profiles in which they are used
  • Coordinate cloud zone and network profile capability tags, and other capability tags, with blueprint constraint tags

Best Practices

  • Have a clear plan and communicate the plan to all users
  • Plan must support the deployment needs.
  • Tags needs to be human readable and understandable
  • Use simple, clear, and meaningful names and values for tags.
  • Though you can create tags using a name with no value, as a best practice says not to do so

Inputs

Next discussion point is inputs. This is another important topic in terms of customizing the Blueprints and enhancing the deployments.

  • Add an inputs section to your blueprint code, where you set the selectable values.
  • Then, in the resources section, reference an input parameter using
    ${input.property-name} syntax.
  • Check Expressions and Expression Syntax for further details
  • Also, for more details on input check the VMware Documentation.

Demo Environment

Provided below is a picture depicting details of my lab setup. For a detailed explanation please check out the video.

Provided below is a picture of the blueprint used in the demo.

Video

Provided below is a link to the video explaining the above topics. This is for those who prefer listening and viewing to reading.
Also, at the end of the video I have a short demo showing the discussed topics.

Conclusion

In this post I covered two major aspects of Cloud Assembly. Utilizing these two aspects you should be able to configure advance Blueprints and placements. In the next post I am going to talk about Extensibility. So, stay tuned for ABX actions and vRO workflows.

Copyright by Sajal Debnath @2023. All rights reserved.