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:
Format |
Description |
---|---|
|
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. |
|
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. |
|
Use this tag format, with the hard or soft value, when you want the deployment process to avoid resources with a matching tag. |
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:
-
Cloud zones are filtered by several criteria, including availability and profiles. Tags in profiles for the zone are matched.
-
Cloud zone and compute capability tags are used to filter the remaining cloud zones by hard constraints.
-
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.
-
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.
Decision ID |
Design Decision |
Design Justification |
Design Implication |
---|---|---|---|
PCA-VAA-CA-CFG-001 |
Establish and publish a well-defined strategy, implementation, and taxonomy for the tagging of cloud resources. |
With capability and constraint tags, you can organize and activate cloud resources and profiles for resource consumption by using the declarative nature of cloud templates to define deployment configurations. |
Your strategy must account for external tags, for example, vSphere and NSX tags, and internal user-defined tags managed through VMware Aria Automation Assembler. |
PCA-VAA-CA-CFG-002 |
Apply constraint tags to the cloud template YAML structure. |
During a provisioning operation, capabilities are matched with constraints, each expressed as tags, in cloud templates and images to determine the deployment configuration. |
You must manage the capability tags on your cloud resources, such as cloud zones, storage and storage profiles, networks and network profiles. |
The design decisions regarding the use of tags on cloud accounts, cloud zones, projects, and profiles are provided within the specific architecture topics.