Azure

Wombat in Azure

There are a few extra parameters and settings that are required when using wombat with Azure. This section details these extra requirements and shows more examples on using Azure.

Authentication Credentials

When building and deploying a wombat project to Azure a method is required to communicate with Azure. This is not simply a username and password combination and must be a Service Principal Name (SPN). These are easy to create if you have the correct permissions on the subscription that will be deployed to.

Creating SPNs can be done with two different tools as described below. All of the methods will provide the following information:

• Application ID (also known as the Client Id)
• Object ID
• Tenant ID

When using packer these details need to be set as environment variables, as well as the subscription ID. The names of the environment variables are as follows:

• Subscription ID = AZURE_SUBSCRIPTION_ID
• Client ID = AZURE_CLIENT_ID
• Client Secret (application password) = AZURE_CLIENT_SECRET
• Tenant ID = AZURE_TENANT_ID
• Object ID = AZURE_OBJECT_ID

1 - Azure XPlat Cli

Thie requires the installation of the Azure XPlat CLI tool which is a Node application. (https://github.com/Azure/azure-xplat-cli).

One command can be used to create the SPN

$> azure login
$> azure sp create -n <APPLICATION_NAME> -p <PASSWORD>

The APPLICATION_NAME can be anything that is recognisable. If the name has spaces in it surround it with quotes.

After creating the service principal it needs to be given permissions in the subscription. As it will need to be able to create machines then it must have a minium permission of Contriutor.

$> azure role assigment create --objectId <OBJECT_ID> -o Contriutor -c /subscriptions/<SUBSCRIPTION_ID>

The OBJECT_ID will be given in the output to the first command.

2 - Powershell

Although PowerShell is available on Windows platforms, the PowerShell modules need to be installed to work with Azure. (https://docs.microsoft.com/en-us/powershell/azureps-cmdlets-docs/).

# Login to the subscription
$> Add-AzureRmAccount
# Create the application
$> $app = New-AzureRmAdApplication -DisplayName "<APPLICATION_NAME>" -HomePage "https://myapp.com" -IdentifierUris "https://myapp.com/myapp" -Password <PASSWORD>
# Give the application permissions to create resources
$> New-AzureRmRoleAssignment -RoleDefinitionName Contributor -ServicePrincipalName $app.ApplicationId

When using this method the HomePage and IdenfierUris must be provided but they do not have to active URLs.

Building

After setting up the environment variables wombat can be used to build the images that will be created for the demo.

The name that has been specified in the wombat.yml file will be the name of the resource group that is created to store the custom images and where the hard disks for the virtual machines will be stored.

Additionally the azure section in the wombat.yml file must contain the location into which everything will be deployed as well as the storage account to be use, e.g.

azure:
   location:  uksouth
   storage_account: edmhuwa4fmejx9we

The resource group (RG) and storage account (SA) will be created by Wombat during the build phase. The RG will automatically be tagged with the username environment variable or the value given to the owner attribute in the wombat.yml file. More tags can be added to the RG by adding them to the azure section in the wombat file. Please see Configuration for more information.

The following command will create the images for the demo for just the Azure platform in parallel.

$> wombat build -o azure-arm --parallel

Deploying

When the images have been created the new machines can be created from them. This is achieved using the deploy sub-command.

Wombat makes use of Azure Resource Manager (ARM) templates to perform the deployment. There is a template built into Wombat that needs to be rendered with the information from the log files generated from the build. This is done using the following command:

$> wombat deploy -c azure --update-lock --update-template --async <NAME>

The NAME in the wombat.yml file is used as the name of the stack thus this is the value that needs to be used in the above command. The --async option means that the request will be sent to Azure rather than blocking and providing progress updates on the command line.

Deleting

Wombat is able to clean up the stacks that it creates. In the case of Azure there are two modes within the deletion phase.

1. Delete all the resources apart from the storage account (Default)
2. Delete the RG

The first mode is less destructive as the custom images that where generated during the build are not destroyed. This is useful if continually deploying machines for testing for example.

During the creation of the template in the deployment phase two ARM templates were created. The have the naming convention of:

1. <NAME>.json
2. <NAME>.tidy.json

It is file 1 that is used to create the resources for the demo project. File 2 is used during a clean up operation. This template just has the name of the SA in it, but it is run in Complete mode which means that Azure will just ensure that only that single resource exists and will remove all other resources.

Peform cleanup:

$> wombat delete -c azure --async <NAME>

NOTE: It will take time for the resources to delete and it it imperative that a deployment is not attempted until this is complete otherwise there will be conflicts on existing names of resources.

Delete the resource group:

$> wombat delete -c azure --async --all <NAME>

NOTE: Deleting an RG takes time. If you wish to deploy another demo immediately be sure to change the NAME and the Azure storage account settings in wombat.yml to avoid clashes with items being deleted.