As a cloud administrator, you can create a Microsoft Azure cloud account for account regions to which your team will deploy VMware Aria Automation cloud templates.
VMware Aria Automation Microsoft Azure integrations support Azure Marketplace images. Users can specify an Azure Marketplace when they set up image mapping in Automation Assembler. Automation Assembler automatically picks up the plan information in any specified Marketplace image. When using Marketplace images, users must accept legal terms for plans in their Azure portal or an exception will occur when they try to deployment the cloud template and the deployment will fail.
To view an example use case of how Microsoft Azure cloud account works in VMware Aria Automation see WordPress end-to-end use case.
Prerequisites
- Verify that you have the required administrator credentials and have enabled HTTPS access on port 443. See Credentials required for working with cloud accounts in VMware Aria Automation.
- Verify that you have the required user role. See What are the VMware Aria Automation user roles.
- Configure a Microsoft Azure account for use with VMware Aria Automation. See Configure Microsoft Azure for use with VMware Aria Automation Assembler.
Procedure
- If you need to add tags to support a tagging strategy, enter capability tags. See How do I use tags to manage Automation Assembler resources and deployments and Creating a tagging strategy.
For more information about how capability tags and constraint tags help control deployment placements, see the Constraint Tags and Placement video tutorial.
Results
The account is added to VMware Aria Automation, and the selected regions are available for the specified cloud zone.
What to do next
Create infrastructure resources for this cloud account.
The cloud template type:cloud.Azure.ResourceGroup option is visible in the auto-suggestion list and the properties pop-ups in the cloud template as seen in the following samples.
When you add an Azure cloud account to a cloud template, you can choose to reuse availability sets if you want. Subscriptions have a limit of 2000 availability sets and 25,000 virtual machines, so it makes sense to reuse availability sets when possible. There are two YAML properties that you can use to control how deployments use availability sets. The availabilitySetName property enables you to specify an availability set to use. The second property is doNotAttachAvailabilitySet which is set to false by default. If this property is set to true, VMware Aria Automation will create the deployment with no availability set.
You can use availability sets or availability zones with an Azure cloud account, but not both.
You cannot create a deployment without an availability set if you use a load balancer attached to the virtual machine.
The following table describes how VMware Aria Automation behaves depending on whether a resource group and an availability set are specified in the cloud template.
An availability set cannot exist without being part of a resource group. The availability sets in a given resource group must have unique names. Availability sets can have the same name only if they are part of different resource groups.
If you do not specify a resource group name, then VMware Aria Automation will create a new resource group, which means that a new availability set must also be created even if a name is passed. The new set will use the name that is passed.
| Resource Group Specified | Availability Set Specified | Result |
|---|---|---|
| No | No | VMware Aria Automation creates a new resource group and a new availability set for the virtual machine. |
| Yes | No | VMware Aria Automation reuses the existing resource group and creates a new availability set for the virtual machine. |
| No | Yes | VMware Aria Automation creates a new resource group and a new availability set with the specified name. |
| Yes | Yes | VMware Aria Automation reuses the existing resource group. If an availability set with the specified name already exists in that group, it will also be reused. If there is no availability set with the specified name in the group, a new one is created with that name. |
As an alternative, you can use availability zones with deployed Azure virtual machines rather than availability sets. If you use availability zones, you can specify an Azure availability zone for a provisioned machine, either by tagging compute resources or by using restrictions expressed through flavor mapping.
This feature enables users to provision a machine in an Azure availability zone by tagging the computes, or selecting the flavor mapping that contains the desired availability zone.
If you want to use availability zones for an Azure virtual machine, you must explicitly pass the attachAvailabilityZone boolean property set to true in the cloud template for the cloud account as shown in the following cloud template snippet.
format version: 1
inputs: {}
resources:
Cloud_Aure_Machine_1:
type: Cloud Azure Machine
properties:
image: ubuntu
flavor: small
attachAvailabilityZone: true
If this property is not present, no availability zone are used for the provisioned machine; instead, an availability set is created. If this property is present and set to true, you can select the desired availability zone on the Compute tab of the cloud zone.
If availability zones are used in a cloud account, the IP SKU type and IP allocation method will be Static and the PublicIPAddress sku type is limited to Standard. Also, not all availability zones are supported for every flavor in every region. The following table outlines the regions that support selection of availability zones. Note that each of the supported regions has three zones. Each region in the table should support Azure availability zones, but depending on the selected size in the flavor mapping, it can be restricted to only one zone.
| Region | Zones Supported |
|---|---|
| Brazil South | 3 |
| Canada Central | 3 |
| Central US | 3 |
| East US | 3 |
| East US 2 | 3 |
| South Central US | 3 |
| West US 2 | 3 |
| West US 3 | 3 |
| US Gov Virginia | 3 |
| East Asia | 3 |
| Southeast Asia | 3 |
| Australia East | 3 |
| China North 3 | 3 |
| Central India | 3 |
| Japan East | 3 |
| Korea Central | 3 |
| North Europe | 3 |
| West Europe | 3 |
| France Central | 3 |
| Germany West Central | 3 |
| Norway East | 3 |
| Sweden Central | 3 |
| Switzerland North | 3 |
| UK South | 3 |
| South Africa North | 3 |
If you want to use machine provisioning in an availability zone and later have a working ssh to the machine, you must first have a correctly configured network security group, with enabled ssh, in the Azure portal. In addition, you must create a network profile with the enumerated data for the network and security groups and then use this network profile on provisioning.
Automation Assembler supports Azure disk snapshots for deployed virtual machines. See Working with snapshots for Microsoft Azure virtual machine disks in VMware Aria Operations for more information.
Automation Assembler supports several boot diagnostics options for Azure deployments. Boot diagnostics supports debugging of Azure virtual machines and includes collection of log information and relevant screen shots. See Using boot diagnostics and log analytics with a Microsoft Azure virtual machine for more information.
In addition to standard disk options, Azure integrations supports selection of Azure performance disk types for users of Azure SSD Premium managed disks. This feature enables users to maximize performance as needs demand. Not all performance disk configurations are supported. See https://learn.microsoft.com/en-us/azure/virtual-machines/disks-change-performance for more information about supported configuations.
You can configure the performance disk type during deployment configuration using the performanceTierType property in your cloud template. The following example demonstrates a potential implementation.
formatVersion: 1
inputs: {}
resources:
Cloud_Azure_Disk_1:
type: Cloud.Azure.Disk
properties:
capacityGb: 2
managedDiskType: Premium SSD
performanceTier: P1
