Azure – Control from the command line

Azurectl v2.0.7 has been released for SUSE Linux Enterprise via the Public Cloud module, and openSUSE via OBS.

For azurectl 2.0, we focused on a few specific areas, based on lessons we’ve learned using azurectl 1.x:

• more robust configuration
• reorganized commands and more consistent arguments
• a more maintainable codebase
• more comprehensive VM lifecycle tools
• complete publisher lifecycle tools

More robust configuration

In Azurectl 1.0, a single configuration file referred to all compute and storage accounts.  We found this approach too constrained, and for 2.0 we’ve transitioned to supporting multiple named configuration files. This allows both more robust support for different accounts, but also the ability to create configs for specific use patterns: since each config file refers to a default region, storage account, and storage container, users can quickly switch to different combinations by switching config files.

We use the additional flexibility provided by this new configuration approach to manage image publishing and our instance that provide the update infrastructure. While the functions are combined in the same account (subscription) the separated configuration allows us to manage the distinct functions by simply using the --account command line
argument.

Brand new in azurectl 2.0 is support for using management certificates and specifying an API endpoint, as an alternative to using publishsettings files. Management certificates are a great way to provide more fine-grained control of access to Azure’s ASM services, as opposed to publishsettings where a single certificate is auto-generated for managing an account. Specifying an API endpoint simplifies access to disconnected regions, new API endpoints, or alternative services with the same API, such as internal Azure Stack instances. Using the management certificates while specifying a specific endpoint provides great flexibility to work with disconnected regions such as the Azure German regions.

Reorganized commands and more consistent arguments

We’ve gone through our commands with a fine-toothed comb, and reorganized them into what we believe to be a more concise and logical structure. The commands are separated into three major areas:

• setup
• storage
• compute

For example, compute storage upload is now storage disk upload which we believe is more in line with the operation that is being performed.

As far as the arguments for the various commands are concerned, we reviewed the arguments in a more holistic approach and tried our best to have consistent argument names. This also led us to add a few more defaults, such as the inference of the blob name when uploading a VHD file to a disk, making the argument optional. The inferred blob name is provided as output to allow you to use it directly as an argument to the image creation command.

The help output for each command has been expanded to include the global arguments such as --account and --region. This should reduce the amount of searching required for command line arguments.

A more maintainable codebase

Under the hood, we noticed that many of our classes were bloating as we added new functions, so we took the opportunity to refactor into a hierarchy of smaller classes. We hope this helps maintain the code, simplify decision making as we add more functionality, and provide a more accessible codebase for new contributors. We’ve also switched our test framework over to py.test to take better advantage of related tools as we move forward.

More comprehensive VM lifecycle tools

azurectl 2.0 now supports the functions you need beyond creating and tearing down VMs; it now manages additional data disks, port forwarding (endpoints), reserved public IP addresses, multiple VMs in a single Cloud Service, and the Azure Files service.

For example, here’s a snippet bringing up an instance of SUSE Linux Enterprise Server 12 SP1, with a reserved IP, an additional 40GB data disk, access to Azure Files, and web ports opened. We’ll use the `pint` tool to discover our image name:

$ pint microsoft images --active --region 'West US' \
  --filter='name~12-sp1-v' --json
{
  "images": [
    {
      "deletedon": "",
      "deprecatedon": "",
      "name": "b4590d9e3ed742e4a1d46e5424aa335e__suse-sles-12-sp1-v20160414",
      "publishedon": "20160418",
      "region": "West US",
      "replacementname": "",
      "state": "active"
    }
  ]
}

$ azurectl compute reserved-ip create --name=demo
$ azurectl compute vm create --cloud-service-name=web-server-demo \
  --image-name=b4590d9e3ed742e4a1d46e5424aa335e__suse-sles-12-sp1-v20160414 \
  --reserved-ip-name=demo
$ azurectl compute data-disk create --size=40 \
  --cloud-service-name=web-server-demo
$ azurectl storage share create --name=demo-smb-share
$ azurectl compute endpoint create --name=HTTP --port=80 \
  --cloud-service-name=web-server-demo
$ azurectl compute endpoint create --name=HTTPS --port 443 \
  --cloud-service-name=web-server-demo

Complete publisher lifecycle tools

While this benefits a small audience, it was of large importance to us. Our dependency on PowerShell for publishing was one of the core drivers in starting the azurectl project, and we’re proud to say that SUSE Linux Enterprise Server and openSUSE are now published exclusively through azurectl on the Linux command line! From upload, to adding publishing metadata, to global replication, to the final step of publishing, the full lifecycle is supported in azurectl, and the base functions are all contributed upstream to the Azure Python SDK.

A look ahead

For azurectl, we will continue to focus on the ASM API provided by Azure. For users of the ARM (Azure Resource Management) API, you can expect a complementary Python-based tool to be made available soon.

We hope azurectl helps make Microsoft Azure more accessible for you, and welcome contributions for missing functionality and improved usability via our github project.