Azure (Resource Manager)

Azure provides a new way to deploy and manage virtual machines and other resources. If you used the earlier service deployment model and want to learn about the changes, see Understanding Resource Manager deployment and classic deployment.

Integration with Azure can be set up using the following steps:

  1. Navigate to the Azure portal.
  2. On the dashboard, click the link to Subscriptions.
  3. Copy the subscription ID you would like CloudBolt to use. This will be used when setting up the RH in CloudBolt.
  4. Create an Active Directory application that can access resources. Follow the instructions available in Azure’s documentation.
  5. Record the Client ID, Secret, and Tenant ID for the new Active Directory application, as those will also be needed to set up the RH in Cloudbolt.
  1. Note: the new Azure portal refers to Client ID as ‘Application ID’, and Tenant ID as ‘Directory ID’. The Secret will be an authentication key generated using Azure’s documentation.
  1. Add the application as an owner for the subscription.
  1. Click on ‘subscriptions’ from the menu on the left and select the subscription you will be using. You might have to click ‘More services’ to see the option for ‘subscriptions’.

  2. Click on ‘Access control (IAM)’ for the chosen subscription.

  3. Click on ‘Add’, choose ‘owner’, search for your application name, select it and click ‘save’.

    1. Note: If owner permissions are not allowed for your subscription, the minimal permissions needed are ‘Virtual Machine Contributor’ and ‘Storage Account Contributor’.
  1. From the Resource Handlers page in the CloudBolt UI, click the “Add a resource handler” button and enter the relevant information from above, and select which locations you would like CloudBolt to manage

Provisioning VMs

Azure requires a username and password when provisioning a new server. The owner’s CloudBolt username is the default username, but there is no default password. There is a password parameter provided with every Azure environment to allow users to specify a password on the order form. You can also set a default in the Global Parameter Defaults page of the UI.

Managed Disks

Servers may be provisioned with managed disks (default) or with a custom storage account (“Use custom storage account” Azure parameter). By default, servers are provisioned with Standard HDD-based storage. To use high-performance, low-latency SSD disks on supported server sizes, admins should configure the “Storage Type” Azure parameter.

When provisioning a new VM with managed disks, CloudBolt supports adding managed data disks during provisioning. You can do so by adding the ‘size for disk N’ parameters to your environment.

CloudBolt also supports the use of managed disks with an Availability Set. When choosing a pre-existing Availability set, be sure to check whether the availability set is managed. You can tell by checking the SKU of the availability set; those with ‘Aligned’ SKUs are compatible with managed disks, and those with ‘Classic’ SKUs are compatible with non-managed disks. If you are auto-creating an availability set, CloudBolt will handle that for you.

Azure Parameters

Out-Of-the-Box Azure Parameters

These parameters come out of the box in all Azure environments.

  • Azure Resource Group: Allows you to specify a resource group to provision into or auto-create a new one.
  • Availability Set: a logical grouping of VMs within a datacenter that allows Azure to understand how your application is built to provide for redundancy and availability. This parameter allows you to choose an existing or auto-create a new availability set for your VM. Cannot be used with Availability Zone.
  • Availability Zone: Azure availability zone, 1, 2, or 3. Cannot be used with Availability Set. Not all node sizes are available in all Availability Zones in all regions.
  • Use custom storage account: If true, specify an existing Azure storage account to be used or let one be created automatically; otherwise, Azure will manage disks and storage accounts automatically.
  • Azure Storage Account: Allows you to specify a location for storing VM disks or auto-create a new one.
  • Create a Public IP Address: When set to true, the server will be assigned a public IP address.
  • Node Size: CloudBolt automatically syncs the available Node Sizes for Azure VMs, so you can just select the one that best fits your needs.

Optional Azure Parameters

To further customize your Azure VMs, there are optional parameters which can be added to groups, environments, or directly to servers. These include:

  • Azure License Type: If you would like to take advantage of Azure’s “bring your own license” functionality, add this parameter to the group or environment so an appropriate value, such as “Windows_Server”, can be provided in the order form and used during provisioning.
  • Deallocate with power off: When set to True on a server, powering off the server will also deallocate it, which stops the VM from incurring charges, but also deletes the public and internal IP.
  • Location: or ‘node_location’, allows you to specify a location for the VM. Also known as region, zone, tenant or datacenter, depending on the provider.
  • Skip Creation of Security Group: If set to true, the server will not receive its own network security group. The subnet security group will still apply.
  • Delete Empty Azure Resource Group: If set to true, deleting a server will clean up its resource group if the resulting group is empty.
  • OS Disk Host Caching: or ‘disk_host_caching’, supports three values: None, ReadOnly, ReadWrite. If this parameter is not included, the default value of ReadOnly is used for the OS Disk.
  • Data Disk Host Caching: or ‘disk_1_host_caching’, ‘disk_2_host_caching’, etc. Each parameter of this type supports three values: None, ReadOnly, ReadWrite. If this parameter is not included, the default value of ReadOnly is used for any additional Data Disks.

Resizing Existing VMs

Azure offers several sizes for Virtual Machines using human readable terms like, “Basic_A1,” or, “Standard_D3.” These terms summarize a few statistics about the compute resources that will be available to your virtual machine such as number of CPUs, amount of memory, and which type of disk you can attach. The specifics behind each size word may vary slightly between each data center and availability zone but they should be roughly equivalant. For more detailed info, see the Microsoft documentation on available sizes for Linux Virtual Machines or for Windows Virtual Machines.

Be aware that not every size is available to every machine for resizing. Microsoft warns that choices may be limited by where your existing virtual machine is deployed. The sizes you can choose from when launching a Resize Job are the union of those Azure says are available for your specific VM, and the sizes your CloudBolt Admins have configured in the CloudBolt Environment your VM is in. For example, if Azure says it can resize to set{‘Basic_A0’, ‘Basic_A1’, ‘Basic_A2’} and your CloudBolt Environment is configured with set{‘Basic_A1’, ‘Basic_A2’, ‘Basic_A3’}, your available choices are the union, those options which appear in both sets: set{‘Basic_A1’, ‘Basic_A2’}.

Enabling Resize VM Server Action for Azure

As a CloudBolt admin, you can decide whether you want to Enable or Disable the, Resize VM Server Action. Navigate to the Admin –> Server Actions page (https://[cb_server]>/actions/server_actions/) and find a Server Action called, Resize VM. Click the Enable/Disable toggle control to set it to your liking.

When enabled, the Server Action will appear in the Server Actions column on the left hand side of the Server Details page for any Server running in Azure.

Manually Resizing a VM

In the CloudBolt instance, when you click on a Server to see its ServerDetails page, you’ll see a Server Action on the left hand side of the Server Details page called, ‘Resize VM.’ When you click it, CloudBolt will present a modal dialog to ask you what new size you’d like your VM to be. The choices in this dialog are constrained as described above. After you select a size, you may click, Run, and CloudBolt will start a Job to resize your VM. Once the Job is complete, you will see the values for CPU Count and Memory, shown in the, Hardware, section of the Overview tab on the Server Details page, have been updated to reflect the new values.

Resizing a VM through the CloudBolt API

For general information on API usage, including authentication, see: CloudBolt API v2.0

When requesting the JSON-serialized representation of a CloudBolt Server from the API like so:

$ curl -H "Authorization: Bearer [encrypted_token_value]" https://[cb_server]/api/v2/servers/[server_number]/

You will see a section listing available Server Actions including the URIs that request them:

{
    "_links": {
        "actions": [
            {
                "Resize VM": {
                    "href": "/api/v2/servers/[server_number]/actions/2/",
                    "title": "Run 'Resize VM' on '[server_hostname]'"
                }
            }
        ]
    }
}

Upon finding the, href for the Resize VM Action, you can use it in a POST request like so:

$ curl -XPOST -H 'Content-Type: application/json' -d '{"new_size": "Basic_A2"}' -H "Authorization: Bearer [encrypted_token_value]" http://localhost:8000/api/v2/servers/45/actions/2/

Note that CloudBolt honors the same constraints for valid sizes in the API as it does in the UI. If you specify a size in the API that’s not valid, your job will fail.

Modifying or Adding Disks

Azure has some specific parameters associated with disks that other resource handlers do not have. In addition to Disk Size, you also may need to specify parameters around Storage type or Account. If the original disk is an Azure Managed Disk, all additional disks will be managed disks, however you will need to specify Storage Type. If the orignal is not managed, you will specify the Storage Account you want associated with the new disk. If no storage account is selected, a new one will be created for the additional disk.

When placing a modification order to add or change disks in the API, these are the accepted parameters:

disk_size: The size to change the original disk to
new_disk_size: The size for the new disk to be added
storage_account_arm: The Storage Account associated with the new un-managed disk.
storage_account_type_arm: The Storage Account Type for additional managed disks (ie. Premium_LRS or Standard_LRS)

Importing Images

Azure provides over 3000 images per region, and fetching all of them can take a long time. To avoid fetching the entire list when you want to use an image, CloudBolt provides a few options for importing images, including the ability to add a single public Image manually, the ability to import all private images, the rule ‘Fetch and Cache Available Azure Images’ which will cache all available images, and the option to run that rule with a whitelist.

Manually Importing an Image

When you have just a single image to import from Azure, you can avoid the rule mentioned above by importing it manually from the Resource Handler’s Images tab.

This feature is available from the Manually Import Images button at the top of the tab, where you would then enter the publisher, offer, SKU, and version of the image from Azure and select one or more regions to import the image for. When a single image is imported this way, it will be automatically added to any environments associated with the region it is imported to, requiring no further configuration to provision using this image.

Importing Private Images

With a single click, you can import all of your private images from Azure in a given resource handler.

First, make sure you have already imported the regions that your private images belong to from the resource handler’s Regions tab. Next, navigate to the Images tab and click Import Private Images. Doing so will automatically create images in CloudBolt for each private image discovered, then add each image to the environment(s) for the associated region, requiring no further configuration to provision using this image.

Getting All Azure Images

The Fetch and Cache Available Azure Images rule is provided in order to cache available Azure images. The rule gets run nightly, and must run once in order for images to initially show up. When images are cached using this rule, there are additional steps needed to be taken in order to make the images available to provision with.

To make a cached image available to provision on an environment:

1. Navigate to an Azure Resource Handler’s Images tab 2. Click Import Images above the region you’d like to import a cached image to. 3. Select images from the list in the dialog and submit. Doing this will automatically add the image to all environments associated with this region.

Using a Whitelist

By default, the Fetch and Cache Available Azure Images rule imports all available images, but you have the option to enable the use of a whitelist of images provided by CloudBolt or create your own whitelist.

To enable the use of a whitelist, go to Admin > Rules > Fetch and Cache Available Azure Images and edit the use_whitelist action input, changing the default value to True.

Then, you may implement your own whitelist in customer_settings.py. This must be a list of tuples containing the publisher, offer, SKU and version of each image you’d like to import, like the following example:

AZURE_IMAGE_WHITELIST = [
    # Specify a tuple containing the 'publisher', 'offer', 'SKU', and 'version' of the image.
    ('redhat', 'RHEL', '6.7', '6.7.20160302'),
    ('MicrosoftWindowsServer', 'WindowsServer', '2012-R2-Datacenter', '4.0.20160518'),
    ('canonical', 'UbuntuServer', '16.04.0-LTS', '16.04.201605161'),
    # You can also create an image that will always use the latest version by replacing the version with 'latest'
    ('openlogic', 'CentOS', '6.5', 'latest')
]

Syncing Resources

Resource Groups and Storage Accounts can be managed directly from CloudBolt via tabs on the Environment detail pages. On each tab, you can sync existing resources from your Azure subscription. You can add new resources directly, although both resource types can also be automatically created when provisioning a server.

Existing resources can be deleted, which will remove that resource from Azure. CloudBolt provides a parameter ‘Delete Empty Azure Resource Group’ available to add to Azure environments and servers. When deleting a server with this parameter set to True, the associated Resource Group will also be deleted if it becomes empty.

Existing resources can also be enabled or disabled in CloudBolt, which determines if that resource is available as a parameter for provisioning servers within the given environment.

Alternative Cloud Environments

Normally, the Azure resource handler connects to the default public version of Azure, including regions in the US and Canada. However, it can also connect to alternative clouds with their own regions like Germany, China, and US Gov. Choose one of the alternate Cloud Environment choices when creating a new instance of the resource handler, or on the credentials form of an existing handler.

Tagging Resources

CloudBolt will apply tags to Azure resources (VMs, Resource Groups, Public IPs, etc.) during provisioning and will also synchronize tags on existing resources. Read more on how to utilize the tagging feature in our documentation on Tagging in CloudBolt