How to change the password on a VM scale set

Problem: You forgot the VM password on an Azure VM scale set, or you need to change it. How do you do it?

At first glance this can be difficult because every new VM sets its password from the VMSS model you created when the scale set was first deployed, and there are no options to change the password in the model. If you write a fancy sshpass script to change the password remotely on all the existing VMs, new VMs will still come up with the old password.

Fortunately this is the kind of problem VM extensions are good at solving. If you set a password using a VM extension, all the VMs in the scale set, including new VMs will run the same extension. Here’s a PowerShell example which uses the VMAccess extension, also known as VMAccessAgent.

$vmssName = "myvmss"
$vmssResourceGroup = "myvmssrg"
$publicConfig = @{"UserName" = "newuser"}
$privateConfig = @{"Password" = "********"}
$extName = "VMAccessAgent"
$publisher = "Microsoft.Compute"
$vmss = Get-AzureRmVmss -ResourceGroupName $vmssResourceGroup -VMScaleSetName $vmssName
$vmss = Add-AzureRmVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $publisher -Setting $publicConfig -ProtectedSetting $privateConfig -Type $extName -TypeHandlerVersion "2.0" -AutoUpgradeMinorVersion $true
Update-AzureRmVmss -ResourceGroupName $vmssResourceGroup -Name $vmssName  VirtualMachineScaleSet $vmss

This script will update the scale set model to add an extension which will always set the password on any new VMs. If your scale set upgradePolicy property is set to “Automatic” it will start working on all existing VMs too. If the property is set to “Manual” then you need to apply it to existing VMs (e.g. using Update-AzureRmVmssInstance if using PowerShell, az vmss update-instances using CLI 2.0, or upgrade in the Instances tab in the Azure portal).

Hopefully in the future there will be a “set password” easy-button in the portal which deploys this extension behind the scenes, or a way to update the password in the VMSS model. 

Posted in Cloud, Computers and Internet, VM Scale Sets | Tagged , | Leave a comment

How to add autoscale to an Azure VM scale set

It is easy to create an Azure VM scale set in the Azure portal, and there is an option to create it with basic CPU based autoscale settings. But suppose you created a scale set without any autoscale settings and now you want to add some autoscale rules. How do you do that?

This article shows 3 different ways to add autoscale settings to an existing scale set:

  1. Add autoscale rules using Azure PowerShell
  2. Create an Azure template to add scaling rules
  3. Call the REST API or a managed SDK

In these examples, the scale metric used is “Percentage CPU”. You can find a list of valid metrics to scale on here: under the heading Microsoft.Compute/virtualMachineScaleSets.

1. Add autoscale rules using PowerShell

There are three main Azure PowerShell commands required to set up autoscale. First create some rules with New-AzureRmAutoscaleRule, then create a profile with New-AzureRmAutoscaleProfile, and finally add a setting with Add-AzureRmAutoscaleSetting. There are more commands available to do things like set up notification addresses and webhooks but the script below shows a basic setup to scale horizontally based on CPU usage. Scaling out when average CPU is greater than 60% and scaling in when average CPU is less than 30%:

$subid = "yoursubscriptionid"
$rgname = "yourresourcegroup"
$vmssname = "yourscalesetname"
$location = "yourlocation" # e.g. southcentralus

$rule1 = New-AzureRmAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId /subscriptions/$subid/resourceGroups/$rgname/providers/Microsoft.Compute/virtualMachineScaleSets/$vmssname -Operator GreaterThan -MetricStatistic Average -Threshold 60 -TimeGrain 00:01:00 -TimeWindow 00:05:00 -ScaleActionCooldown 00:05:00 -ScaleActionDirection Increase -ScaleActionValue 1
$rule2 = New-AzureRmAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId /subscriptions/$subid/resourceGroups/$rgname/providers/Microsoft.Compute/virtualMachineScaleSets/$vmssname -Operator LessThan -MetricStatistic Average -Threshold 30 -TimeGrain 00:01:00 -TimeWindow 00:05:00 -ScaleActionCooldown 00:05:00 -ScaleActionDirection Decrease -ScaleActionValue 1
$profile1 = New-AzureRmAutoscaleProfile -DefaultCapacity 2 -MaximumCapacity 10 -MinimumCapacity 2 -Rules $rule1,$rule2 -Name "autoprofile1"
Add-AzureRmAutoscaleSetting -Location $location -Name "autosetting1" -ResourceGroup $rgname -TargetResourceId /subscriptions/$subid/resourceGroups/$rgname/providers/Microsoft.Compute/virtualMachineScaleSets/$vmssname -AutoscaleProfiles $profile1 

After running this script you can look at the VM scale set properties in the Azure portal and it will show that Autoscale is set to On. Autoscale will start kicking in, and if your scale set isn’t doing any work your VMs will start getting deleted based on the rules above.

There are a couple of important things to point out about this script.

Firstly the MetricName “Percentage CPU”. This is a host metric name. I.e. the autoscale service is getting the information from the hypervisor host rather than from any agent running in the VM. This is recommended because the host metric pipeline (aka the MDM pipeline) is faster and more reliable than the older method of getting autoscale metrics based on running a diagnostic agent inside the VM. See Autoscaling VM scale sets with host metrics for more information.

Secondly make sure you’re using the latest version of Azure PowerShell, which at the time of writing is 3.6.0. Check here: – various parameters get added or deprecated as versions progress. If you get errors or warnings when running scripts a good initial troubleshooting step is to upgrade to the latest Azure PowerShell.

2. Create an Azure template to add scaling rules

An alternative way of adding autoscale settings to a scale set is by deploying a specialized template. Look at an Azure Resource Manager template like this one: – it’s used to create a VM scale set, install a Python Bottle webserver on each VM, and autoscale based on CPU usage. You can isolate the autoscale component and deploy it as its own template if you wish. I.e. the part that starts with:

  “type”: “Microsoft.Insights/autoscaleSettings”,

The important values in the autoscaleSettings which reference back to the scale set are: “targetResourceUri”, and “metricResourceUri”. Here’s an example template which isolates the autoscale settings and can be deployed against an existing scale set: – this template could be further improved by parameterizing the autoscale metric names and thresholds.

3. Call the REST API or managed SDK directly

When you add autoscale settings using PowerShell, behind the scenes it is calling the Azure REST API. You can see the calls it makes by passing the –debug parameter. Here is an example of a Python program which adds autoscale settings using the REST API:

It uses the azurerm library which is basically a set of REST wrappers. Note that in order to use this library you need a Service Principal (described in steps 1-4 here: ).

All the official Azure SDKs (Python, Java etc.) have function calls to create autoscale rules and settings.

4. What about the Azure portal?

Ideally you should be able to edit autoscale settings for an existing scale set directly in the portal. That’s on the portal roadmap, but not in place yet (at the time of writing).

Posted in autoscale, Cloud, Computers and Internet, Python, VM Scale Sets | Tagged , , , | Leave a comment

VIP Swap – blue-green deployment in Azure Resource Manager

How do you automate deployment of a multi-VM application from staging to production?

Two high-level approaches might be:
1. Roll out deployment, update one or more VMs at a time. This can be a good approach to avoid downtime, as only a subset of machines are down during update. It assumes different versions of the application can coexist. See:

2. Create a staging cluster and move it to production by swapping the network endpoints. Also known as a blue-green deployment, this is a good way to publish an application as a consistent or immutable set, but can involve downtime during the transition.

This article describes how to swap the public IP addresses between two Azure Load Balancers in Azure Resource Manager (ARM). You can use this method if for example you have two VM scale sets behind load balancers, one production and one staging, and you want to move the staging scale set into production.

The Azure Cloud Service (classic) deployment method included an asynchronous Swap Deployment operation, which was a fast and powerful way to initiate a virtual IP address swap between staging and deployment environments. Azure Resource Manager doesn’t have an equivalent built-in VIP swap function, so if you have a staging environment behind a load balancer, and want to swap it with a production environment behind another load balancer, you have to do something like:

  • Unassign the public IP from load balancer 2’s front-end IP configuration.
  • Assign the public IP from load balancer 2 to load balancer 1.
  • Assign the public IP from load balancer 1 to load balancer 2.
  • Since you can’t assign a public IP address to another resource until it has been unassigned from its current resource, one way to do this is to create a temporary IP address as a float. E.g.

  • Create a temporary public IP address.
  • Assign the temp IP address to LB1.
  • Assign LB1’s old IP address to LB2.
  • Assign LB2’s old IP address to LB1.
  • Delete the temp IP address.
  • One caveat to be aware of is that these operations involve some downtime. Unassigning a public IP address can take around ~30 seconds (at the time of writing), therefore total downtime for your app could be at least 60 seconds as temp/staging/production IP addresses are moved around.

    Test environment

    To test VIP swap in ARM I created two load balancers in the same resource group and VNET, and associated each one with a different VM scale set. The Azure Resource Manager templates used to set up this infrastructure can be found here: 

    PowerShell VIP swap example

    # put your load balancer names, resource group and location here
    $lb1name = 'vipswap1lb'
    $lb2name = 'vipswap2lb'
    $rgname = 'vipswap'
    $location = 'southcentralus'
    # create a new temporary public ip address
    "Creating a temporary public IP address"
    new-AzureRmPublicIpAddress -name 'floatip' -ResourceGroupName $rgname -location $location -AllocationMethod Dynamic
    $floatip = Get-AzureRmPublicIpAddress -name 'floatip' -ResourceGroupName $rgname
    # get the LB1 model
    $lb1 = Get-AzureRmLoadBalancer -Name $lb1name -ResourceGroupName $rgname
    $lb1_ip_id = $
    # set the LB1 IP addr to floatip
    "Assigning the temporary public IP address id " + $ + " to load balancer " + $lb1name
    $ = $
    Set-AzureRmLoadBalancer -LoadBalancer $lb1
    # get the LB2 model
    $lb2 = Get-AzureRmLoadBalancer -Name $lb2name -ResourceGroupName $rgname
    $lb2_ip_id = $
    # set the LB2 IP addr to lb1 IP
    "Assigning the public IP address id " + $lb1_ip_id + "to load balancer " + $lb2name
    $ = $lb1_ip_id
    Set-AzureRmLoadBalancer -LoadBalancer $lb2
    # set the LB1 IP addr to old lb2 IP
    "Assigning the public IP id " + $lb2_ip_id + " to load balancer " + $lb1name
    $ = $lb2_ip_id
    Set-AzureRmLoadBalancer -LoadBalancer $lb1
    # now delete the floatip
    "Deleting the temporary public IP address"
    Remove-AzureRmPublicIpAddress -Name 'floatip' -ResourceGroupName $rgname -Force

    Python VIP swap example

    Here’s a Python example based on the azurerm REST wrapper library, which follows the same logic, and adds some timing code: 

    The output looks like this:


    In this case downtime was measured at 61 seconds.

    Next steps

    If your application requires immutable deployment approaches, for further reading take a look at the Azure Spinnaker, an Azure port of Netflix’s open source continuous delivery platform: and associated templates:

    Posted in Cloud, Computers and Internet, Python, VM Scale Sets | Tagged , , , | 2 Comments

    Deploying Minecraft Server on Azure

    The Azure Marketplace now has a Minecraft Server offering which deploys a customizable Minecraft Server to an Azure virtual machine. This replaces an older Azure Gallery Minecraft item which was often out of date, sometimes broken, and eventually removed.

    The new solution template creates an Azure virtual machine running Ubuntu 16.04 and installs Minecraft Server running on it. It also creates the other cloud infrastructure components you need, including: a resource group, virtual network, public IP address, DNS name, network security group (NSG). Additionally it lets you set several Minecraft server configuration parameters at deployment time. What follows is a brief user guide covering how to deploy and operate your Minecraft Server running in Azure.

    What you need to get started

    Finding the Minecraft Server

    You can deploy the Minecraft Server Marketplace solution to a new VM directly from the Azure Marketplace or by searching for it from the Azure portal.

    From the Marketplace

    Go to the Minecraft server Marketplace product page and click GET IT NOW.


    From there click Continue and you’ll be taken to the Azure portal..

    From the Portal

    You can also deploy the Minecraft Server directly from the Azure Portal. Click the ‘+’ sign and type “minecraft” in the search.


    Deploying the Minecraft Server

    Once you’ve selected the Minecraft Server product in the portal you’ll see a description and a Create button.

    Click Create.

    From here the portal takes you through a set of forms known as portal blades to configure the deployment. Let’s go through them one by one:



    VM username – A Linux user name you’ll use if you need to log on to the virtual machine.

    Password – The password you’ll use if you need to log on to the virtual machine. Don’t forget this.

    Subscription – If you have access to more than one Azure subscription, choose the one you want to use for this deployment.

    Resource group – A logical container for your resources. It’s a good idea to create a new one here, that way if you want to remove everything you created at some point you can simply delete the resource group and it won’t affect any other deployments.

    Location – Pick the region where the resources will be created. Picking somewhere local to you is usually a good idea to minimize network round-trip time.

    Click OK.

    Virtual Machine Settings


    Public IP address resource name – Leave the default setting.

    Domain name label – Pick a unique domain name for your server. No punctuation, spaces etc., just letters and/or numbers. Later when you connect to this server the full domain name will be like: <yourdomainname>.<yourlocation>

    Size – The size of the virtual machine. You can accept the default or choose a larger machine with more CPU/memory, but it is not recommended to choose a smaller machine like A0 or D0. If you do pick a smaller VM size the server might get a bit laggy.

    Click OK.

    Minecraft Server Settings


    Minecraft username – This is your Minecraft username – get it right or you won’t be an operator of the Minecraft server that gets created. Don’t put an email address or anything else, except a valid Minecraft username.

    Minecraft server version – This should default to the latest version of the Minecraft server and hence not need changing. The field is editable just in case a new server version comes out and the Azure Marketplace product hasn’t been updated yet. If there is a new server version available you can put it here.

    difficulty – The default Difficulty of 1 means peaceful mode. Check here for what values you can use for this and the next few parameters:

    level-name – Whatever you want your new Minecraft world to be called or leave the default value. Don’t use any special characters which could interfere with a bash script. E.g. no spaces, single quotes, explanation marks, backslashes (unless you’re deliberately escaping a character).

    game-mode – The default value is 0 – Survival mode. 1 is creative.

    white-list – Set this to true to make this invite-only. Initially only you would have access, and for people to join you’ll have to use operator commands to add them to the white-list.

    enable-command-block – If this is true you can create command blocks in the server, which empowers you to build a near limitless array of quasi-magical operations.

    spawn-monsters – Controls whether monsters show up at night or not.

    generate-structures – Controls whether your world will have temples and villages.

    level-seed –  Leave this blank to use a random seed. The seed controls which of the 18,446,744,073,709,551,616 possible worlds are generated. As with level-name, avoid using characters which could interfere with the bash script which installs Minecraft. No spaces or punctuation like quotes, explanation marks, backslashes.

    Click OK


    Next you’ll see a summary of the options you picked…


    Click OK.


    At the purchase blade you confirm that you’re deploying the Azure resources. Note there are no extra charges on top of the Azure resources, just the basic compute and storage charges.


    Once you click the Purchase button your Minecraft server will start deploying and you’ll see a progress icon on the dashboard. Allow several minute for this to deploy.


    Connecting to the Minecraft Server

    Once deployment is complete you’ll see the resources that were created in the portal..


    Click on the Public IP address and you’ll see the DNS name you’ll use to connect to from your Minecraft launcher:


    Start your Minecraft desktop client. Use the regular desktop app, not a pocket edition which won’t connect to regular multiplayer servers like the one you just created. Click Play->Multiplayer and then select Direct Connect or Add Server like this:


    Once connected you (and only you) should be an operator. You should be able to type commands like /gamemode 1 to switch to Creative mode:

    Minecraft 1.11.2 2_11_2017 2_55_43 PM

    The full list of operator commands can be found on the Minecraft wiki:

    Troubleshooting and managing
    Troubleshooting may involve logging on to the VM directly. For this you need to SSH to the DNS address. If you’re connecting from Windows you’ll need to get an SSH client like putty (see this article for more examples), or better still SSH directly from the Windows subsystem for Linux which is available in Windows 10 Anniversary edition and later. In the example above the SSH command would be:
    ssh -l mcuser

    1. Manually stopping/starting the Minecraft server on the VM
      ssh to the VM
      sudo systemctl stop minecraft-server
      sudo systemctl start minecraft-server

    2. If you need to edit any of the Minecraft server files, they are in /srv/minecraft_server

    3. Cannot SSH to the VM
    Go here:

    4. Upgrading Minecraft to the latest server version
    Use this script:

    Next Steps

    There is another Minecraft server in the Azure Marketplace called Multicraft. I’ve not tried it myself yet but Bitnami have good solutions. It’s an advanced hosting platform for Minecraft so worth trying.

    If you have any ideas to improve the Azure Marketplace Minecraft Server template, the source files are here: – please take a look and log issues or submit a PR. 

    Posted in Cloud, Computers and Internet, Games, Ubuntu | Tagged , , , | 9 Comments

    Autoscaling VM scale sets with Azure host metrics

    It’s now easier to set up autoscaling with Azure VM scale sets than it used to be. Until recently the only way to set up autoscaling for scale sets was by installing the Azure diagnostics extension in every VM. The diagnostics extension was required to emit performance data to a storage account that you also had to manage. Your autoscale rules would then reference that data to evaluate whether to trigger a scale action.

    In October (2016) a more efficient data pipeline for Azure VMs went into production, based on host metrics. Host metrics means the hypervisor host machine which is running the Azure VM collects performance data about the VM and stores it in a free account which is managed on your behalf. This is the data being used when you look at your VM scale set properties in the Azure portal and view or edit a graph..


    Autoscaling using Azure templates

    You can access the host metric data directly, and also set up Azure autoscale rules to use it. The autoscaling templates in Azure Quickstart templates have already been converted to use host based metrics (that is, they no longer install a diagnostics extension, no longer create a storage account for metrics, and reference the host metric display names in the autoscale rules). This makes the templates simpler than they used to be. See the following for example:

    E.g. looking at one of the scale rules in the python-bottle template, the Percentage CPU host metric is referenced:


    The host metric names you can use in the scale rules are documented here:

    E.g. at the time of writing:


    Metric Display Name


    Aggregation Type


    Percentage CPU

    Percentage CPU



    The percentage of allocated compute units that are currently in use by the Virtual Machine(s)

    Network In

    Network In



    The number of bytes received on all network interfaces by the Virtual Machine(s) (Incoming Traffic)

    Network Out

    Network Out



    The number of bytes out on all network interfaces by the Virtual Machine(s) (Outgoing Traffic)

    Disk Read Bytes

    Disk Read Bytes



    Total bytes read from disk during monitoring period

    Disk Write Bytes

    Disk Write Bytes



    Total bytes written to disk during monitoring period

    Disk Read Operations/Sec

    Disk Read Operations/Sec



    Disk Read IOPS

    Disk Write Operations/Sec

    Disk Write Operations/Sec



    Disk Write IOPS

    If you need to autoscale using other metrics e.g. memory, it is recommended to keep using the diagnostics extensions.

    Accessing host metrics directly

    You can view the host metrics data coming from scale sets directly using the Azure Monitor REST API (formerly known as the Insights API). Using a simple Python program like this one for example:, I can view the same data that the graph in the Azure portal shows me..


    Or create my own graphs (in this case by just dumping data in a spreadsheet):


    Here’s another example, this time feeding the data into a matplotlib graph.. The graph below shows a case of maxing-out the CPU of the 201-vmss-bottle-autoscale scale set, starting with a capacity of 1 and then autoscale kicking in to scale out to 2 VMs. It looks like it may have scaled out to 3 and then back to a steady state of 2



    Posted in Cloud, Computers and Internet, Python, VM Scale Sets | 1 Comment

    Azure scale set upgrade policy explained


    Azure VM scale sets have an “upgradePolicy” setting which can be set to “Manual” or “Automatic”. What does this setting do? What should you set it to? and how do you set it?

    What upgrade policy means

    The upgrade policy of a scale set determines what happens next after you change the scale set model. I.e. regardless of this setting nothing “automatic” happens unless you make a change to the model. Changing the scale set model means changing a property of the scale set which affects VMs, for example, the VM size (sku->name), the OS version, an extension property.

    If you change a scale set property in the model (i.e. change a value and update the scale set), then if the upgradePolicy is set to “Manual”, nothing happens. It will be up to you to then apply the model to VMs in the scale set manually. E.g. by calling the Update-AzureRmVmssInstance PowerShell command or the Azure CLI 2.0 az vmss update-instances command. When you apply the model to a VM, this will typically result in a reboot, and if you’re changing the OS version, a reimage.

    For more information about how to manually roll out an upgrade across VMs in a scale set, refer to:

    If the upgradePolicy is set to “Automatic”, when you deploy an updated scale set model, the update will be applied to all the VMs in the scale set at once. This is likely to result in an interruption to your application, which is why it is usually recommended to set this value to “Manual”.

    What to set upgradePolicy to

    If you don’t mind all your VMs being rebooted at the same time, you can set upgradePolicy to “Automatic”. Otherwise set it to “Manual” and take care of applying changes to the scale set model to individual VMs yourself. It is fairly easy to script rolling out the update to VMs while maintaining application uptime. See for more details.

    If your scale set is in a Service Fabric cluster, certain updates like changing OS version are blocked (currently – that will change in future), and it is recommended that upgradePolicy be set to “Automatic”, as Service Fabric takes care of safely applying model changes (like updated extension settings) while maintaining availability. 

    How do you set upgrade policy?

    A simple way to change the upgradePolicy setting is to change it in the template you used to deploy a scale set and redeploy the template. If you didn’t use a template (for example created it from scratch using imperative PowerShell or CLI commands, or deployed it from the portal), a simple place to change the property is in the Azure Resource Explorer. Find your scale set under Microsoft.Compute in your resource group, and select Edit. Change the upgradePolicy setting and click PUT.

    What about fully automated OS updates and patching?

    In Azure PaaS v1 (Worker and Web roles), you could deploy cloud services and never have to worry about patching. OS updates were automatically taken care of behind the scenes. People looking at migrating cloud services to scale sets often ask when they can get equivalent functionality on scale sets. Automated patching is a feature that is expected from PaaS. It is reasonable to expect scale sets (which is an infrastructure layer designed to support PaaS solutions) to provide this ability.

    Fully automated OS updates is on the scale set roadmap, but for now only manual patching is available. There will be some interim steps along the way, for example expect to see built-in manually triggered rolling updates coming soon.

    In theory the primitives available now can be used to create a DIY automated upgrade feature. For example you could write an Azure Function which checks to see if there is a new OS platform image version, then updates the VMSS model with the new version, and then rolls out the update across the scale set. The VMSS Editor tool implements the manually triggered rolling update part of this for example. It’s on my to do list to write a simple auto-upgrade demo, but I won’t try and claim it would be equivalent to a fully automated Azure service.

    Posted in Cloud, Computers and Internet, VM Scale Sets | Tagged , , | Leave a comment

    Deploying Azure Container Service using the azurerm Python library


    Azure Container Service is an easy to deploy container framework for Azure. It’s an open framework that among other things lets you choose whether to deploy DCOS or Swarm based cluster orchestration. You can deploy ACS directly from the Azure Portal or command line, and it has a convenient set of REST APIs to deploy and manage the service programmatically, which is supported by the standard Azure SDKs. The azurerm Python library of Azure REST wrappers also recently added support for ACS.

    Here’s an example showing how you can deploy a new Container Service with azurerm. You can see a similar example in the examples section of the azurerm github repo:, and see all the ACS API calls exercised in the azurerm ACS unit tests.

    import azurerm
    from cryptography.hazmat.primitives import serialization
    from cryptography.hazmat.primitives.asymmetric import rsa
    from cryptography.hazmat.backends import default_backend
    from haikunator import Haikunator  # used to generate random word strings
    import json
    import sys
    tenant_id = "your tenant id"
    app_id = "your application id"
    app_secret = "your application secret"
    subscription_id = "your Azure subscription id"
    # authenticate
    access_token = azurerm.get_access_token(tenant_id, app_id, app_secret)
    # set Azure data center location
    location = 'eastus'
    # create resource group - use Haikunator to generate a random name
    rgname = Haikunator.haikunate() 
    print('Creating resource group: ' + rgname)
    response = azurerm.create_resource_group(access_token, subscription_id, rgname, location)
    if response.status_code != 201:
        print(json.dumps(response.json(), sort_keys=False, indent=2, separators=(',', ': ')))
        sys.exit('Expecting return code 201 from create_resource_group(): ')
    # create Container Service name and DNS values - random names again
    service_name = Haikunator.haikunate(delimiter='')
    agent_dns = Haikunator.haikunate(delimiter='')
    master_dns = Haikunator.haikunate(delimiter='')
    # generate RSA Key for container service - put your own public key here instead
    key = rsa.generate_private_key(backend=default_backend(), public_exponent=65537, \
    public_key = key.public_key().public_bytes(serialization.Encoding.OpenSSH, \
    # create container service (orchestrator will default to DCOS)
    agent_count = 3                # the container hosts which will do the work
    agent_vm_size = 'Standard_A1'
    master_count = 1               # use 3 for production deployments
    admin_user = 'azure'
    print('Creating container service: ' + service_name)
    print('Agent DNS: ' + agent_dns)
    print('Master DNS: ' + master_dns)
    print('Agents: ' + str(agent_count) + ' * ' + agent_vm_size)
    print('Master count: ' + str(master_count))
    response = azurerm.create_container_service(access_token, subscription_id, \
        rgname, service_name, agent_count, agent_vm_size, agent_dns, \
        master_dns, admin_user, public_key, location, master_count=master_count)
    if response.status_code != 201:
        sys.exit('Expecting return code 201 from create_container_service(): ' + str(response.status_code))
    print(json.dumps(response.json(), sort_keys=False, indent=2, separators=(',', ': ')))
    Posted in Cloud, Computers and Internet, Containers, Python | Tagged , , , , | Leave a comment