- Discovering the significance of tags in automation assembler
- Tags Mind Mapping
- Level of Precedence in Tagging
- Effective & Basic Tag Strategy
- Demo Time
- Tag Management
- Conclusion
Discovering the significance of tags in automation assembler
Tags represent a vital aspect of Automation Assembler, serving to guide the allocation of deployments through the matching of capabilities and constraints. A comprehensive comprehension and adept implementation of tags are essential to fully leverage Automation Assembler. Essentially, tags are descriptive markers applied to items within Automation Assembler. Organizations have the autonomy to create tags tailored to their specific requirements and operational framework. Tags function not solely as labels, but exert control over the allocation of resources and infrastructure by Automation Assembler in order to construct deployable services. Moreover, tags contribute to the governance framework within Automation Assembler.
Tags Mind Mapping
Capture1: –

As shown in capture 1 is mind map of tags. lets review each component.
- Capability Tag: –
1.0 In Automation Assembler, capability tags play a crucial role in defining deployment capabilities for infrastructure components and form the core of placement logic in VMware Aria Automation alongside constraints. These capability tags can be created on compute resources, cloud zones, images, image maps, and networks and network profiles.
1.1 The creation of these resources offers options for adding capability tags, or alternatively, the Tag Management page in Automation Assembler can be utilized for this purpose.
1.2 Notably, capability tags assigned to cloud zones and network profiles have an impact on all resources within those respective zones or profiles, while those associated with storage or network components solely influence the specific components to which they are applied.
1.3 These capability tags typically specify characteristics such as location for a compute resource, adapter type for a network, or tier level for a storage resource, as well as other pertinent business considerations.
1.4 It is imperative to logically organize capability tags in alignment with specific business requirements, bearing in mind that Automation Assembler uses capability tags from cloud zones to correspond with constraints on cloud templates during deployment.
1.5 Hence, the effective establishment and utilization of capability tags necessitate an understanding of and careful planning for appropriate cloud template constraints to ensure anticipated matching.
Capture 2: –

2. Constraint Tags: –
2.0 The tags assigned to projects and cloud templates act as constraint tags when matching capability tags on infrastructure resources, profiles, and cloud zones. Within cloud templates, the Automation Assembler leverages this matching functionality to allocate resources for deployments.
Automation Assembler provides two primary methods for utilizing constraint tags.
2.1 The first involves configuring projects and images, allowing tags to function as constraints for associating resources with the project or image.
2.2 The second method applies to cloud templates, where specified constraint tags are utilized to select resources for deployments. Constraints implemented through these methods are amalgamated within cloud templates to outline a set of deployment requirements, thereby defining available deployment resources.
Modifier : –
The usage of modifiers indicates that the Constraint tag will be interpreted as a requirement, preference, or negation. Let us now explore the three modifiers in detail:
2.3 Hard modifier: – The term “hard” modifier denotes that the constraint tag is obligatory for deployment. Failure to meet the constraint will result in deployment failure. Furthermore, the key:value tag is synonymous with the key:value: hard tag.
2.4 Soft modifier: -The soft modifier indicates that the constraint tag represents a preference. When VMware Aria Automation identifies a resource that fulfills the constraint tag, it utilizes that resource. If VMware Aria Automation is unable to locate a resource that meets the constraint tag, it proceeds with deployment using an alternative resource, notwithstanding its failure to meet the constraint tag. Moreover, the key:value tag is interchangeable with the key:value:soft tag.
2.5 ! Not Modifier: -The “!” modifier, also known as the negation modifier, is a valuable tool for applying constraints to resource deployment. When used in conjunction with a tag (with or without the hard or soft modifiers), the “!” modifier prevents deployment to resources sharing a matching tag. This can be particularly useful when fine-tuning deployment strategies and ensuring precise resource allocation in complex environments.

3. Resource Tags: –
Resource tags play a vital role in the provisioning process as they can be applied to the resources being deployed. Beyond any machine-specific tags, the resource tags defined in a project are universally attached to all deployed machine resources within that project. These resource tags can be further differentiated based on their function, such as business, technical, and security tags. Implementing resource tags within VMware Aria Automation Templates leads to the categorized labeling of the machines within the computing platform. For instance, when a vSphere VM with confidentiality is deployed using VMware Aria Automation, the VM is labeled through vSphere’s integrated security tagging mechanism.

5. Types: –
External Tag: – The following information has been sourced from vSphere, NSX, VMware Cloud on AWS, as well as public clouds including Amazon Web Services and Microsoft Azure. External tags are observable in the originating cloud account and VMware Aria Automation Assembler. Upon importation, these external tags are made available as user-defined tags.
Internal tag: – The internal tags are exclusively defined and visible within the VMware Aria Automation Assembler. They are further categorized into standard tags and user-defined tags. It is imperative to thoroughly analyze these two types of internal tags.
Standard Tags: -During the provisioning process on vSphere, Amazon Web Services, and Microsoft Azure deployments, the application of tags occurs automatically. Unlike other tags, standard tags cannot be utilized by users during deployment configuration, and no constraints are imposed. Standard tags are stored as system custom properties and are added to deployments subsequent to provisioning.
User-defined tags: -User-defined tags, defined by a user of VMware Aria Automation Assembler, are utilized within the system to categorize and organize resources. These tags are important for distinguishing between different capabilities and constraints within the system, allowing for effective management and allocation of resources.
Level of Precedence in Tagging
- In cases where the tags assigned to the project clash with the tags present in the cloud template, the system prioritizes the project’s tags. For instance, if the network constraint within the project specifies location: Bangalore, and the network constraint in VMware Aria Automation Templates specifies location: Delhi, the project’s constraint will take precedence. Therefore, the final constraint will be location: Bangalore.
Capture 1: –

2. The storage Policy property associated with a disk supersedes any storage constraint tag assigned to a machine.
Capture 2: –

3. The presence of a storage constraint tag on a machine supersedes the designated VMware Aria Automation storage profile.
Capture 3: –

4. When a storage policy property is applied to a disk, it takes precedence over the preferred VMware Aria Automation storage profile.
Capture 4: –

Effective & Basic Tag Strategy
The subsequent enumeration delineates the typical considerations to be taken into account when formulating your strategic plan. It is important to note that these considerations are indicative rather than exhaustive.
Effective Tag Strategy: –
- Develop and implement a cohesive tagging strategy that aligns with your business structure and disseminate this plan to all relevant users. The strategy should meet your deployment requirements, employ clear and easily comprehensible language, and be accessible to all relevant users.
- Please ensure the use of clear and meaningful names and values for tags. Specifically, when naming tags for storage and network items, strive for clarity and coherence to facilitate users’ comprehension when selecting or reviewing tag assignments for a deployed resource.
- While it is possible to create tags using a name without a value, it is considered best practice to assign a relevant value to each tag name. Doing so enhances clarity for other users regarding tag usage.
- When assigning tags, please refrain from duplicating or adding irrelevant tags. For instance, only utilize tags for network items that directly pertain to network issues.
Basic Tag Strategy: –
- In which diverse environments do you deploy? Commonly, you will establish tags to depict each environment.
- How are the computing resources structured and utilized to facilitate deployments.
- In which regions or locations are your deployments situated? Typically, tags will be created at the profile level to represent each of these distinct regions or locations.
- How many distinct storage options are available for deployments, and how would you prefer to classify them? These options should be identified using tags.
- Please ensure that networking options are categorized and tagged appropriately to align with the network and storage profiles they are associated with. By coordinating these tags, we can establish a logical framework for the deployment of resources, providing a finer level of control over their allocation.
- When integrating cloud zone and network profile capability tags with constraint tags, it is advisable for administrators to establish capability tags for cloud zones and network profiles first. Subsequently, users can develop cloud templates with constraints that are aligned with the established capability tags. This sequential process ensures an effective coordination between capability and constraint tags within the cloud infrastructure.
- As an effective implementation strategy, it is advantageous to commence by individually tagging your compute infrastructure resources. It is advisable to employ logical categories for tag names that correspond to the specific resources. Following the tagging of resources, you can then proceed to determine the most suitable approach for creating tags for cloud zones, storage, and network profiles that align with your requirements.
Demo Time
This will be divided in 03 tasks as below: –
- Demo Agenda
- Demo Execution
- Demo Validation
- Demo Agenda: – In this demo, our goal is to complete the following task: Task-01: We will be given the Resource tag under the Projects. Once VMs are provisioned, the tags will be automatically assigned. In this demo, we will use the tag name “Project: GoldenGate”.
Capture 1: –

2. Task-02: -We will utilize the Environmental Compute Tag (Category – User defined Tag) so that the VMs can be provisioned under the default/assigned Compute Cluster during provisioning.
Capture 1.2: –

3. Task-03: -We use Constraint tags for the Security Groups and apply them to securityGroupType ‘existing’. To assign the correct security group, blueprint constraints are compared with infrastructure capability tags set by the administrator on security groups. These security groups are created under NSX. Note: By default, all constraints are hard modifiers.
Capture 1.3: –

4. Task-04: -We are utilizing Constraint tags for the NSX segments. With this method, we can specify the Network CIDR, Network Type, and Segment tag. This allows the appropriate tags to be automatically assigned when provisioning VMs based on the segments. Please note that by default, all constraints are hard modifiers.
Capture 1.4: –

2. Demo Execution: – In this session, we will endeavor to carry out and ensure alignment with the demonstration agenda.
Capture 2: –

Step 1:- Click on Deploy
Note: – In this execution we will be provisioning 02 VMs with the below Specs.

Capture 2.1: –

Step 1: – Select the Create a new deployment
Step 2: – Gives the rememberable name.
Step 3: – template version I used the Current Draft.
Step 4: – Click on Next
Step 5: – Cluster ENV- vSAN Cluster auto-selected
Note: – We have selected vSAN-Cluster as a default Cluster Environment.
Step 6: – Click on deploy.
Capture 2.2: –

In capture 2.2, we can see the deployment has started.
Capture 2.3: –

In the capture 2.3 we can see the deployment has successfully completed. In my lab, it will take a maximum of 13 minutes to provision the VMs with all attributes.
3. Demo Validation:-
3.1 We need to perform a validation to ensure that the Resource tag assigned to the provisioned virtual machines within the vCenter environment is accurate and aligned with the intended configurations.
Capture 3.1: –

Step 1:- We can see the VM Name is successfully assigned-Overlay_node-031-mcm3338-273152077837.
Note: User Defined Name ”Overlay_node-031” Aria Automation assigned UUID mcm3338-273152077837.
Step 2: – We can see Resource tag “Project: GoldenGate” is successfully assigned to Overlay_node-031.
Step 3: – We can see the VM Name is successfully assigned-Web_node-031-mcm3340-273152161177.
Note: User Defined Name ”Web_node-031” Aria Automation assigned UUID mcm3340-273152161177.
Step 4: – We can see Resource tag “Project:GoldenGate” is successfully assigned to Web_node-031.
The resource tag output has been verified to fully align with the requirements of Demo agenda task 1.
3.2 Let’s ensure that the designated cluster on the provisioned virtual machines (VMs) in the vCenter is properly validated.
Capture 3.2: –

Step 1: – Cluster name —VRA
Step 2: – Overlay_node-031-mcm3338-273152077837 VM is Provisioned under the correct Cluster.
Step 3: – Web_node-031-mcm3340-273152161177 VM is Provisioned under the correct Cluster
Step 4: – Environment Cluster tag (user-defined tag)—vSAN Cluster is pre-assigned.
The Environment Cluster tag output fully aligns with the requirements of Demo agenda task 2.
3.3:- Ensure that the provisioned virtual machines (VMs) are placed within the designated Security Groups as per the Constraint tags.
Capture 3.3: –

Step 1: – Security Group Name- “Overlay-VM-Group”
Step 2: – Click on View members
Step 3: – Click on VIFs and we can the VM name “Overlay_node-031-mcm3338-273152077837” and IP address “172.16.1.107”.
Step 4: – Security Group Name- “Web-VM-Group”
Step 5: – Click on View members
Step 6: – Click on VIFs and we can the VM name “Web_node-031-mcm3340-273152161177 ” and IP address “172.17.1.107”.
“The output of the Security Group Constraint tag aligns perfectly with the requirements outlined in Demo agenda task 3.”
3.4 When adding constraint tags for the NSX segments, provide details for the Network CIDR. This information will be used during the provisioning of the VMs, so make sure to include the appropriate tags: –
Capture 3.4.1: –

Step 1: – Segment name: – Overlay Segment
Step 2: – Network CIDR: – 172.16.1.x/24
Step 3: – Segment Port associated with VM: – Overlay_node-031-mcm3338-273152077837.vmx@049fb255-dde2-4a88-b75f-424c66a71ed4
Capture 3.4.2: –

Step 1: – Segment name: – Web Segment
Step 2: – Network CIDR: – 172.17.1.x/24
Step 3: – Segment Port associated with VM: – Web_node-031-mcm3340-273152161177.vmx@67f3f61c-bacc-47ae-aa0a-209674318496
The constraint tag for NSX Segment output fully adheres to the requirements of Demo agenda task 4.
4. Let’s double-check and verify the vCenter/NSX UI captures mentioned earlier by comparing them with the output from the NSX Command Line Interface (NSXCLI).: –
Overlay_node-031 Capture 3.4.3: –

Step 1:- run the cmd on NSXCLI “get cgroup with ip “VM IP address”” to validate the provisioned VM (Overlay_node-031) on vCenter UI output with the NSX CLI output.
Step 2: – run the cmd on NSXCLI “get cgroup with mac “VM MAC address”” to validate the provisioned VM (Overlay_node-031) on vCenter UI output with the NSX CLI output.
Step 3: – run the cmd on NSXCLI “get cgroup with mac “VM MAC address”” to validate the provisioned VM (Overlay_node-031) connected to NSX logical Switch on vCenter UI output with the NSX CLI output.
Step 4:- run the cmd on NSXCLI “get cgroup UUID logical-objects” to validate the provisioned VM (Overlay_node-031) VIF attached with NSX logical Switch port on NSX UI output with the NSX CLI output.
Web-node-031
Capture 3.4.4: –

Step 1:- run the cmd on NSXCLI “get cgroup with ip “VM IP address”” to validate the provisioned VM (Web_node-031) on vCenter UI output with the NSX CLI output.
Step 2: – run the cmd on NSXCLI “get cgroup with mac “VM MAC address”” to validate the provisioned VM (Web_node-031) on vCenter UI output with the NSX CLI output.
Step 3: – run the cmd on NSXCLI “get cgroup with mac “VM MAC address”” to validate the provisioned VM (Web_node-031) connected to NSX logical Switch on vCenter UI output with the NSX CLI output.
Step 4:- run the cmd on NSXCLI “get cgroup UUID logical-objects” to validate the provisioned VM (Web_node-031) VIF attached with NSX logical Switch port on NSX UI output with the NSX CLI output.
Tag Management
Within Automation Assembler, the Tag Management page serves as a comprehensive platform for meticulously supervising and organizing your tags library. In addition to monitoring your existing tags, this page provides the functionality to create new tags. Furthermore, it is the exclusive area where you can analyze and identify external tags. By utilizing the Tag Management page, you can gain detailed insights into the allocation and application of tags, including in-depth information regarding the specific users and locations linked to their usage.
Capture 1: –

Step 1: – Click on Infrastructure
Step 2: – Click on Tags under configure
Step 3: – Click on Tags under the Tag management.
Note: – Under tags we will find the origin of tags nature.
Let’s consider an illustration to grasp how tags are utilized.
Example: – Resource tag ”Project:GoldenGate” with whom and where it used.
Capture 1.1: –

Step 1: – As per the example i selected the key “Project” with value “GoldenGate”
Step 2:- Once you select, it will redirect to Tag Usage Page and we can see the Overlay_node-031 & Web_node-031 VMs are tagged under the Project:GoldenGate.
Conclusion
If you would like to see the YAML code used in this lab demo, Click below: –
https://github.com/PuneetSharma-Repositories/Tagging-Placement-in-Aria-Automation.git
In this publication, our focus is on elucidating the critical role of tags in Aria automation and their application as Provisioned objects within NSX. A comprehensive examination of the hierarchical precedence of tagging and the necessity of a well-defined tag strategy will be conducted. Additionally, the demonstration will present an in-depth analysis of the integration of tagging at various levels of implementation and initialization.


Leave a comment