Quick Guide to VCF Automation for VCD Administrators

 

Tagging Design for VMware Aria Automation Assembler for Private Cloud Automation for VMware Cloud Foundation

Tags express capabilities and constraints that determine how and where resources are allocated to workloads during the provisioning process.

Tagging serves as the foundation for the workload placement in VMware Aria Automation Assembler. Tags are labels that you apply to VMware Aria Automation Assembler constructs. Tags facilitate policy-driven placement by directing how and where VMware Aria Automation Assembler uses resources and infrastructure to build services across private and public clouds. Structurally, tags must follow the key:value pair convention, for example, region:us-wes-1, but their construction is largely open. Tags also facilitate search and identification of compute, storage, and network resources, as well as provisioned machines, by using logical and natural language context.

Tagging Strategy

Before you create and use tags in VMware Aria Automation Assembler, you must establish a well-defined and adaptive tagging strategy and taxonomy. A tagging strategy ensures that users who create and use tags understand what the tags mean, how the tags must be used, and where or when the tags must be applied. For example, a tagging strategy can determine the tags that can be discovered, for example, vSphere tags, and the tags that can be user-defined and managed by using VMware Aria Automation Assembler.

Best practices for an effective tagging strategy:

• Plan and communicate - Create, communicate, and execute a plan for tagging that relates to the structure of your organization. Your plan must support your deployment requirements, use clear natural language, and be understandable to all applicable users.

• Simple and adaptive - Use simple, clear, and meaningful names and values for tags. Users can easily understand capabilities and constraints when using tags in cloud templates or reviewing tag assignments for a resource. Apply relevant tags to resources while avoiding unnecessary tagging that might result in deployment or operations challenges.

Tag Types

In terms of origination, tags can be external and internal:

External tags

Discovered and imported from vSphere, NSX, and VMware Cloud on AWS, as well as from public clouds, such as Amazon Web Services and Microsoft Azure. External tags are visible in both the originating cloud account and VMware Aria Automation Assembler.

When imported, the external tags are available as user-defined tags.

Internal tags

Defined and visible only in VMware Aria Automation Assembler.

Tags can be also divided into standard and user-defined types:

Standard tags

Applied automatically during provisioning on vSphere, Amazon Web Services, and Microsoft Azure deployments.

Unlike other tags, users cannot use standard tags during deployment configuration, and no constraints are applied. Standard tags are stored as system custom properties and are added to deployments after provisioning.

User-defined tags

Defined by a VMware Aria Automation Assembler user.

In terms of use, tags can be divided into capability and constraints:

Capability tags

Used to define capabilities of an object and to define placement logic for deployment. These tags define the required connectivity, functionality, and capabilities for deployments.

You can create capability tags on resources, such as cloud zones, storage and storage profiles, and networks and network profiles. Capability tags on storage or network components affect only the components on which they are applied. VMware Aria Automation Assembler matches capability tags with constraints from cloud zones and on cloud templates at deployment time.

Constraint tags

Used to define deployment requirements. Constraint tags on cloud templates and components match capabilities defined on resources, cloud zones, and network and storage profiles to generate deployments with the required configuration.

You can apply constraint tags to two constructs - project and image configuration, and cloud template deployment. Constraints applied to both constructs are merged in cloud templates to form a set of deployment requirements.

When configuring VMware Aria Automation Assembler, you apply constraint tags to projects to provide governance directly at the project level. All constraints added at this level are applied to all cloud templates that are requested for the applicable project. If a tag on a project conflicts with a tag on a cloud template, the project tag takes precedence, allowing you to enforce governance rules.

On cloud templates, you add constraint tags in the YAML structure to match the appropriate capability tags that your cloud administrator created on VMware Aria Automation Assembler objects and resources. In addition, there are other more complex options for implementing constraint tags. For example, you can use a variable to populate one or more tags on a request, so that you can specify one or more of the tags at request time.

Create constraint tags by using the tag label in the cloud template YAML. Constraint tags from projects are added to the constraint tags created in cloud templates.

In this example, the cloud template constraint attempts to deploy on objects with the cloud:private capability tag applied:

constraints:
     - tag:          
          cloud:private

In this example, a cloud template expression is added for user selection with a cloud template input:

inputs:
     targetCloud:  
          type:string
               enum:                                                       
                    - private
                    - vmc
                    - aws
                    - azure
                    - gcp
                    - ......
 constraints: 
 - tag: '${"cloud:" + to_lower(input.targetCloud)}'

If the user selects private, the constraint tag is set to cloud:private.

Constraints are typically defined in a cloud template in the format - [!]tag_key[:tag_value][:hard|:soft].

Consider the following formats when you configure constraints:

Constraint Formats

Format	Description
key:value or key:value:hard	Use this tag format when a cloud template must be provisioned on resources with a matching capability tag. If no matching tag is found, the deployment process fails.
key:value:soft	Use this tag format when you prefer a matching resource. If there is no matching tag, the deployment process proceeds without failing and accepts resources.
!key:value	Use this tag format, with the hard or soft value, when you want the deployment process to avoid resources with a matching tag.

Comparison of Capability and Constraint Tags in VMware Aria Automation Assembler

Objects Type	Objects	Capability	Constraint
General	Cloud account	✓	x
	Integration	✓	x
	Cloud zone	✓	x
	Project	x	✓
Mappings	Image mapping	x	x
	Flavor mapping	x	✓
Profiles	Storage profile	✓	x
	Network profile	✓	x
Compute	Cluster	✓	x
	Resource pool	✓	x
	Availability zone	✓	x
Storage	Storage policy	x	x
	Datastore / Cluster	x	x
Network	Network profile	✓	x
	IP range	x	x
	Load balancer	✓	x
	Network domain	x	x
Machines	Machine	x	x
Volumes	Volume	x	x
Kubernetes	Kubernetes	x	x
Security	Security group	✓	x
Cloud template	Cloud template	x	✓

Sequencing and Simulation

The following list summarizes the high-level operations and sequence of capability and constraint tag processing:

1. Cloud zones are filtered by several criteria, including availability and profiles. Tags in profiles for the zone are matched.

2. Cloud zone and compute capability tags are used to filter the remaining cloud zones by hard constraints.

3. Provisioning priority is used to select a cloud zone from the remaining filtered cloud zones. If there are several cloud zones with the same provisioning priority, they are sorted by matching soft constraints, using a combination of the cloud zone and compute capabilities.

4. After a cloud zone is selected, a host is selected by matching a series of filters, including hard and soft constraints as expressed in cloud templates.

You can simulate a provisioning request to validate your configurations. Based on the provided values, the request goes through the projects, cloud zones, and profiles configurations without executing the provisioning.