Single Instance Virtual Machine SLA in Azure

Were you aware that Microsoft Azure offers single Instance Virtual Machine SLA? SLA stands for service level agreement which is a contract between you, the end user, and Microsoft wherein a level of service is expected. If a specified level of service is not provided, the end user may claim a financial credit. Yes, that’s right, Microsoft Azure now offers single instance VM SLA as long as you use premium storage for the OS disk and data disks. Microsoft guarantees you will have VM connectivity of at least 99.9% of the time. This equates to about 43 mins per month of potential unavailability.

availability set

You may ask, “Why would I want to deploy a single instance VM?” In many situations a customer may have an application that is not built for scaling out. Or scaling out could be cost prohibitive for the application and the customer is fine with running their application in a single VM. In fact, many customers are used to deploying single VMs in their data center and taking advantage of live migration or vMotion. However, when you operate in the cloud you need to think differently to obtain high availability.

If high availability and a higher level SLA is needed, then you should deploy at least 2 VMs into an availability set. This will provide you with 99.95% uptime guarantee. An availability set is a logical grouping of VMs that spans across fault and update domains. In the event of a planned maintenance event or an unplanned event, at least 1 VM will remain running. This is due to hardware clusters in Azure being divided into update and fault domains. These domains are defined by hosts that share a common update cycle or physical infrastructure. In addition, these clusters support a range of VM sizes. When the first VM of an availability set is deployed, the hardware cluster is chosen based on the supported VMs. By default availability sets are configured with 5 update domains (configurable to 20) and 3 fault domains.

If you are still using VMs with unmanaged disks (traditional storage), it is recommended to convert those VMs to use Managed Disks. If you are not familiar with Managed Disks, stay tuned as I will be talking about these in a future blog post.

Azure in a Box

This summer Microsoft is expected to go GA with their Azure Stack offering. If you are not familiar with this, think of it as “Azure in a box”. This would get installed in your datacenter or offered up by a service provider for you to consume. The release of Azure Stack has been a long while coming as it was first announced in late 2015. Currently Technical Preview 3 (TP3) is available for evaluation so some of this info could change. Everything that I am about to talk about is publicly available on Microsoft’s website.

A Walk Down Memory Lane..

Remember those days when you needed to spin up a VM to test something. There wasn’t a lot of choices. You had to either reach out to IT to request that they spin up a VM for you and provide you access, or you could spin one up on your laptop using a type 2 hypervisor which had its limitations. Typically, this had to go through an approval process that sometimes took weeks. For those of you graybeards, who have been around the industry as long as I have, you didn’t even have the luxury of virtualization and you had to request a server. How did we ever get anything done back then?

Not so long ago companies like Amazon, Microsoft, and Google started to offer up hyperscale environments where you could allocate resources and pay for them as you use them. The sheer size of these environments allowed them to offer these resources at a low-price point. This allowed companies to move from a CAPEX to an OPEX model which started the evolution of the public cloud. However, there are many companies that have either security concerns or compliance requirements that keep them from taking advantage of the public cloud and all it has to offer or those who wish to have complete control of their data and resources.

Enter the private cloud, hosted in your datacenter or a service provider’s datacenter. Companies must evolve and to stay relevant in the industry they need to focus on providing value to their customers. In the case of the private cloud, those customers could be your own internal business units. These BUs need the capability to have self-service deployment and agility.

Prior to Azure Stack there was Azure Pack which provided these capabilities. This was a big step in the right direction as it provided a lot of these capabilities but there was something missing. What if you had a workload running on Azure Pack and you wanted to be able to run it in public Azure without having to make any changes. This was not easily done as the APIs were not consistent. Microsoft Azure had already seen so much growth that a new user experience was in order which gave Microsoft a chance to build a new portal and a new deployment model (resource manager). This left a lot of users in a state of confusion having to keep up with learning and supporting both.

Fast Forward to Today..

Now that Azure Stack has been developed, you get consistency across both private and public clouds. The APIs are consistent, the deployment models are consistent, and the user experience is consistent. Users can now log in with the same identities utilizing ADFS or Azure AD. Developers can use the same tools that they are familiar with. Think of Azure Stack as being an extension of Azure bringing agility and faster innovation to cloud computing, all behind your firewall. This allows for a true hybrid cloud experience.

Purchasing, Licensing, Pricing and Support..

At GA, Azure Stack is going to be available through three hardware vendors, Dell EMC, HPE, and Lenovo on preapproved hardware, delivered as an integrated system, with software preinstalled. Cisco recently announced they will be joining the other three hardware manufacturers. Expect to see their offering soon after GA. I wouldn’t be surprised to see other manufacturers jump in on this as well.

The software licensing will be available via EA and CSP only. If you have an existing EA Azure subscription, you can use that same one for consuming Azure Stack. CSP providers will be able to use the same tenant subscriptions for customers as well. MSDN, Free trials, and Biz Spark offers cannot be used with Azure Stack. You will be able to use on-premises Windows Server and SQL Server license with Azure Stack as long as you comply with product licensing. If you BYOL you will only be charged for consumption on the base VM.

Azure Stack services will be priced the same as Azure, on a pay-as-you-use model. At GA, the following services will be charged on a consumption basis: Virtual Machines, Azure Storage, App Service, and Azure Functions. You will be billed for Azure Stack usage as part of your regular Azure invoice. See below chart for how those services will be metered.

Image credit to Microsoft

With Azure Stack, there will be two support contracts, one purchased from the hardware vendor and one from Microsoft. For those customers who have an existing Premiere or Azure support contract with Microsoft today, it will cover Azure Stack as well.


Azure stack brings purpose-built integrated systems to your datacenter that allows speed and agility to help you modernize your applications across a hybrid environment. It allows developers to build applications using a consistent set of services, tools, and processes. Operations is now able to deploy to the location that meets the needs of their business meeting technical and regulatory requirements, all while paying only for what you use.

For additional information on Azure Stack refer to this link.


Alexa Skill App for Azure Infrastructure Exam

Like a lot of you out there, I received an Echo Tap from my daughter for Christmas. The funny thing is I had the same idea as a gift and bought the Echo for my wife and grandkids. I also received the Echo Dot through my company. Needless to say, Alexa is all over my house. For those of you who are not familiar, Alexa is the wake word. This triggers the Echo to listen to your command. Immediately after doing a little research to see what Alexa was capable of, I noticed there were skills that you could enable for further functionality. As I have a passion for learning new things, I thought how cool it would be if I could build my own Alexa skill. What if Alexa could help me study for an exam? Well, now she can.

As my focus is on cloud technologies, I searched through the skills library to see if I could find anything around Azure and AWS. It turns out that there were a couple around AWS but nothing around Microsoft, specifically Azure. So I knew what my next project was going to be. I did a little research and found some guidance around building your own Alexa skills app, based on the trivia framework.

The really cool thing about this is I could use the AWS Lambda service which allows you to run code in the cloud without having to worry about deploying or managing the servers. If the traffic to my skill all of the sudden ramps up, the service will scale out as needed and when the traffic slows it will scale back in. This is what is referred to as “Serverless Computing”. You mean I can run code in the cloud without having to worry about the server or the infrastructure, it scales as needed and its highly available? The answer is Yes. This is a very powerful service which I feel is going to get a lot of attention moving forward.

I simply created a Lambda function in AWS, added my code, set the configuration and added a trigger for the Alexa Skills Kit. I then logged into the developer console and opened the Alexa Skills Kit where I defined my skill. This included providing skill information, defining the interaction model, setting the configuration using my newly created Lambda function ARN (amazon resource name), configuring the publishing information, and specifying the privacy and compliance. The capability exists within the developer portal to be able to test and validate as well. Once my skill was tested and validated I submitted it for certification. The certification process can take up to 7 days to go through testing at AWS to ensure you have met security requirements and the functional and user experience passes. If your skill doesn’t meet the criteria you will be notified and asked to resolve the issues and resubmit. Make sure you do not infringe on anyone’s intellectual property.

My Alexa skill is based on studying for the 70-533 Azure Infrastructure exam. I was excited to receive an email that my skill has been certified and has been published to the skill store. I encourage you to check it out and please rate it or provide a review. The name of my skill is “Azure Quiz Buddy” and you can search for it or locate it under the Education and Reference category.

I hope you will enjoy my new Alexa skill and be inspired to go and build your own.

Using Terraform Across Multiple Cloud Providers

Are you utilizing multiple cloud providers and finding it difficult to keep track of how to compose the different definition or configuration files? I feel your pain. Depending on what cloud provider you are using, you need to use a specific format when building your templates, scripts, etc. Previously most deployments were done imperatively. This means that you tell the machine how to do something and as a result what you want to happen will happen. This works and can be useful in certain scenarios. However, the more preferable way of deployment would be to use a declarative deployment model. This is done by telling the machine what you would like to happen and the it figures out how to do it. What if there was a way to create definition files that could be used across multiple cloud platforms wherein a common language was used to lay down the infrastructure. This would be beneficial right? Well, you are in luck! Have you heard of HashiCorp, more specifically Terraform? In this post I am going to show you how Infrastructure as Code works by using terraform across multiple cloud providers.

So what is Terraform

Terraform is one of many tools available in the HashiCorp Ecosystem.

  • Atlas – commercial product. Combines Packer, Terraform, and Consul.
  • Packer – tool for creating images.
  • Terraform – tool for creating, combining, and modifying infrastructure.
  • Consul – tool for service discovery, service registry, and health checks.
  • Serf – tool for cluster membership and fault detection.
  • Vagrant – tool for managing dev environments

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. It can be used across multiple providers such as Azure, AWS, Google Cloud, among many others. Basically you define the components or resources in your configuration file, tell it which provider to use, generate an execution plan prior to deployment, and then execute the build. So, how is this done? It’s done through abstraction of resources and providers.

Key features of terraform are:

  • Infrastructure as Code – process of managing and provisioning infrastructure and configuration through high-level configuration syntax.
  • Execution Plans – shows what the deployment will do prior to actually doing anything. Helps avoids failed deployments.
  • Resource Graph – allows terraform to map out the resources and dependencies to deploy the infrastructure as efficiently as possible.
  • Change Automation – helps avoid human error while changes are orchestrated.

This all sounds good, but aren’t there other tool sets out there that do the same thing? Sure, but the power comes by being able to use across multiple providers. From a deployment perspective I could use Resource Manager in Azure, Cloud Formation in AWS, or Cloud Deployment Manager in GCE but they are all specific to their respective cloud. Terraform can be used across all three. Let’s be clear though, terraform is not a configuration management tool such as Chef and Puppet. You can still continue to use those tools for their intended purpose by using provisioners once the resource has been created. Terraform focuses on the higher-level abstraction of the datacenter and its services. Terraform is an open source tool that provides a simple, easy to read syntax that allows for standardization within organizations.


Terraform can be installed on your workstation and is distributed as a packaged zip archive that supports multiple platforms and architectures.

  • Download the appropriate package for your system. For me, its Windows 64-bit but Linux distros are suppored as well.
  • Create a folder at the root of the OS drive called terraform. Unzip the package to this folder. A single executable will be present.
  • Ensure the install directory is included in the PATH variable for the user. For Windows you can type the following in PowerShell. (click on the code block to expand)
[Environment]::SetEnvironmentVariable("PATH", $env:PATH + ({;C:\terraform},{C:\terraform})[$env:PATH[-1] -eq ';'], "User")

Once that is done, we are ready. Verify the installation by opening a terminal session and typing “terraform”. This can be done using Cmd, PowerShell, or VS Code (with the PS plugin).

Deployment across Multiple Providers

Now I will demonstrate deploying some simple resources across Microsoft’s Azure, Amazon’s AWS and Google’s Compute Engine using terraform.

Microsoft Azure

There are a few prerequisites for getting started.

  • ensure you have an Azure subscription
  • ensure you have your client_id, client_secret, subscription_id, and tenant_id
  • setup two entities – AAD Application and AAD Service Principal
  • have Azure PowerShell tools installed (Windows users) and/or Azure CLI for Linux distros.

To setup terraform to access Azure there is a script that you can download and run that will create the AAD Application and AAD Service Principal. Download and execute the “./azure-setup setup” command and login to your Azure subscription with admin privileges. Provide an arbitrary application name such as “terraform” and supply a password. Once the script has completed, it will display the values for the needed prerequisites.

I created a new file called “” with the contents below and stored it in C:\terraform\Azure. Plugin the values for the provider.

variable "resourcesname" {
  default = "helloterraform"

# Configure the Microsoft Azure Provider
provider "azurerm" {
    client_id       = "your_client_id"
    client_secret   = "your_client_secret"
    subscription_id = "your_subscription_id"
    tenant_id       = "your_tenant_id"

# create a resource group if it doesn't exist
resource "azurerm_resource_group" "helloterraform" {
    name = "terraformtest"
    location = "West US"

# create virtual network
resource "azurerm_virtual_network" "helloterraformnetwork" {
    name = "vnet1"
    address_space = [""]
    location = "West US"
    resource_group_name = "${}"

# create subnet
resource "azurerm_subnet" "helloterraformsubnet" {
    name = "subnet1"
    resource_group_name = "${}"
    virtual_network_name = "${}"
    address_prefix = ""

# create public IPs
resource "azurerm_public_ip" "helloterraformips" {
    name = "tfvm1-pip"
    location = "West US"
    resource_group_name = "${}"
    public_ip_address_allocation = "dynamic"

# create network interface
resource "azurerm_network_interface" "helloterraformnic" {
    name = "tfvm1-nic"
    location = "West US"
    resource_group_name = "${}"

    ip_configuration {
        name = "testconfiguration1"
        subnet_id = "${}"
        private_ip_address_allocation = "static"
        private_ip_address = ""
        public_ip_address_id = "${}"

# create storage account
resource "azurerm_storage_account" "helloterraformstorage" {
    name = "tfstor01"
    resource_group_name = "${}"
    location = "westus"
    account_type = "Standard_LRS"

# create storage container
resource "azurerm_storage_container" "helloterraformstoragestoragecontainer" {
    name = "vhd"
    resource_group_name = "${}"
    storage_account_name = "${}"
    container_access_type = "private"
    depends_on = ["azurerm_storage_account.helloterraformstorage"]

# create virtual machine
resource "azurerm_virtual_machine" "helloterraformvm" {
    name = "tfvm1"
    location = "West US"
    resource_group_name = "${}"
    network_interface_ids = ["${}"]
    vm_size = "Standard_A0"

    storage_image_reference {
        publisher = "Canonical"
        offer = "UbuntuServer"
        sku = "14.04.2-LTS"
        version = "latest"

    storage_os_disk {
        name = "tfvm1-osdisk"
        vhd_uri = "${azurerm_storage_account.helloterraformstorage.primary_blob_endpoint}${}/myosdisk.vhd"
        caching = "ReadWrite"
        create_option = "FromImage"

    os_profile {
        computer_name = "hostname"
        admin_username = "daryl"
        admin_password = "PrivD3m0!"

    os_profile_linux_config {
        disable_password_authentication = false

Navigate to that same directory and type “terraform plan”. The output shows what changes terraform will make. Here we can see that there is going to be eight new resources added. (as the output is quite long I have omitted most of it)

Once confirmed that this is what we really want to do, we can execute by typing “terraform apply”. This will start the deployment in your Azure account. In just a few minutes we will have a virtual machine running Ubuntu-14.04.

Here we can see all the resources that were deployed in our resource group. Wasn’t there eight resources within our file? Yes, but some resources such as the subnet, nic, and storage container are not exposed.

We can verify (inspect) the state using “terraform show”.

Once we are done, we can clean up by removing what was installed previously. We can run “terraform plan -destroy” as a pre-check validation which shows 8 resources to destroy.

Running “terraform destroy” and confirming with “yes” will cleanup for us.

Let’s move on and see how this looks in AWS.


There are a few prerequisites for getting started.

  • ensure you have an AWS account
  • ensure you have an access key and secret key

To create an access key, from the AWS portal, click on the Service drop down and select IAM. Click on Users, select your user account, click on the Security Credentials tab and click on “Create Access Key”. You will need the Access Key Id and Secret.

I created a new file called “” with the contents below and stored it in C:\terraform\AWS. Plugin your values for the provider.

provider "aws" {
  access_key = "your_access_key"
  secret_key = "your_secret_key"
  region     = "us-west-2"

resource "aws_instance" "example" {
  ami           = "ami-d07d8db0"
  instance_type = "t2.micro"

Navigate to that same directory and type “terraform plan”. The output shows what changes terraform will make. Here we can see that there is going to be one new resource added.

Once confirmed that this is what we really want to do, we can execute by typing “terraform apply”. This will start the deployment in your AWS account. In just a few minutes we will have a virtual machine running Ubuntu-16.04.

We can verify (inspect) the state using “terraform show”.

Once we are done, we can clean up by removing what was installed previously. We can run “terraform plan -destroy” as a pre-check validation prior to running “terraform destroy” and confirming with “yes”.

Let’s move on and see how this looks in GCE.

Google Compute Engine

There are a few prerequisites for getting started.

  • ensure you have a Google Cloud account
  • ensure you have an authentication file in the same folder as your terraform file

To create an authentication file, from the GCE portal, search API Manager. Click on the Credentials tab and click “Create Credential” and select Service Account Key. Select “Compute Engine default service account”, select “JSON”, and Create. Save the file as account.json.

I created a new file called “” with the contents below and stored it in C:\terraform\Google.

// Configure the Google Cloud provider
provider "google" {
  credentials = "${file("account.json")}"
  project     = "triple-baton-144217"
  region      = "us-west1-a"

// Create a new instance
resource "google_compute_instance" "default" {
  name = "testvm1"
  machine_type = "n1-standard-1"
  zone = "us-west1-a"
  disk {
      image = "debian-cloud/debian-8"

  network_interface {
      network = "default"
      access_config {



// Create a rule to allow http access 
resource "google_compute_firewall" "default" {
    name = "http"
    network = "default"

    allow {
        protocol = "tcp"
        ports = ["80", "8080"]

Navigate to that same directory and type “terraform plan”. The output shows what changes terraform will make. Here we can see that there is going to be two new resources added.

Once confirmed that this is what we really want to do, we can execute by typing “terraform apply”. This will start the deployment in your GCE account. In just a few minutes we will have a virtual machine running Debian-8.

We can verify (inspect) the state using “terraform show”.

Once we are done, we can clean up by removing what was installed previously. We can run “terraform plan -destroy” as a pre-check validation prior to running “terraform destroy” and confirming with “yes”.

Keep in mind that these are just examples to use in a test environment and are not meant for production. For production we would take advantage of defining variables and using a vault for storing credentials and secrets.


As you can see I was able to deploy resources in Azure, AWS, and Google with very little effort. You can see how much easier terraform is to read than traditional JSON or ARM syntax. I’m not saying that this should be the only tool in your toolbox, but you can see just how powerful and simple it is. If you are looking to deploy resources across multiple providers, take advantage of Infrastructure as Code by using Terraform. Stay tuned as I will be discussing some of the other tools in the HashiCorp Ecosystem in future posts.


Azure Container Service and Docker Swarm

Today I wanted to talk about Azure Container Service, aka ACS. ACS went into Genearal Availability back in April of 2016. So what is ACS you ask? ACS is a service in Azure that allows you to create, configure, and manage a cluster of virtual machines that are preconfigured to run containerized applications. Microsoft is taking a bit of the hard work on for you in setting up a cluster to support containers. You could surely deploy a set of virtual machines on your own and install the docker engine and create a cluster. But why go through the hassle when you can let the Container Service handle it all while taking advantage of the enterprise features in Azure. With ACS, you select the size, the number of hosts, and choice of orchestrator tools, and Container Service does its magic. You can continue to use the tools you are familiar with and use the orchestrator of your choice. Azure Container Service leverages the Docker container format to ensure that your application containers are fully portable. Container Service offers you a choice of using DC/OS or Docker Swarm for scale and orchestration operations. Simply put, Azure Container Service is a container hosting environment that utilizes open source tools. With all the momentum around containers these days, ACS is a service that will allow you to start testing containers in a matter of minutes.

Getting Started

Some people may argue that they are not ready to start testing with containers. Maybe they think having a monolithic application excludes them from using containers. Well, thats the good thing about containers, you can do a lift-and-shift of a monolithic app into a container if desired. There are several advantages to moving to containers, such as fast deployment, scalability, portability and avoiding vendor lock-in. Based on a state of the app development survey done in early 2016, 80% of respondents felt that Docker would be central to cloud strategy with 3 out of 4 stating their top initiatives would revolve around modernizing legacy apps and moving to a microservices architecture. Some will argue that microservices has been around for a long time and debate how containers would help. Yes, microservices have been around for a while but what Docker and containers does is to allow it to be faster, more streamlined, and offers better collaboration across the dev and ops teams. Its all about Build, Ship, Run, any app, on any stack, anywhere. Are you starting to see the value of containers now?


Lets begin by deploying an ACS cluster using Docker Swarm as the orchestrator. Since this is our first introduction to ACS I will demonstrate how this is done in the portal. However, you can deploy a cluster using ARM templates which you can find in the GitHub repo for azure-quickstart-templates.

Login to the Azure Portal, click +New, type “azure container service” and select.


Select Azure Container Service and click Create.


Note: You are going to need an SSH Public Key that will be used for authentication against the ACS VMs. It is important for the key to include a prefix of ‘ssh-rsa’ and a suffix of ‘username@acsdemo’. You can accomplish this by using PuttyGen to create a public and private key.

Open PuttyGen and click Generate. In order to create randomness move your cursor around the blank space while the key is being generated. Save the public and private key to a local folder. Optionally you can create a password to protect the private key. You can leave PuttyGen open as you will need the key in the next step.


On the Basics blade fill in the appropriate info including the SSH public key you just generated making sure to add the suffix of ‘username@linuxvm’ and click OK. In my example I used ‘daryl@acsdemo55’.

basics blade

 On the Framework Configuration blade select your choice of orchestrator to use when managing the applications on the cluster. Here you have two options to choose from, DC/OS or Swarm. We will choose Swarm in this demo. So what is Docker Swarm you ask? Swarm is a simple tool which controls a cluster of Docker hosts and exposes it as a single virtual host. Since Swarm uses the standard Docker API, you can use any tool that understands Docker commands. In addition, Swarm follows the “batteries included but removable” principle meaning that its extensible with other 3rd party plugins.

Framework configuration blade

On the Azure Container Service Settings blade select the number of agents and masters, the size of the agent VMs, and a unique DNS name prefix. The agent count will be the initial number of VMs in the VM scale set and will be members of the swarm cluster that you will create.

Azure container service settings blade

On the Summary blade, ensure validation has passed. At this point you can download the template that will be used for the deployment. If you wanted to customize the deployment, you could cancel this deployment, edit the json template and then deploy the template. In our demo we will continue with the default. Click OK to continue and click on Purchase to agree to the terms.

Summary blade

At this point the container service is being deployed as per your configuration. You can see this pinned on the dashboard.


Once the deployment has completed, mine took around 10 minutes, you will get a notification on the dashboard that the deployment was successful. In addition, you can click on the resource group and the Last deployment should say Succeeded.

Resource Group blade

Now that the deployment has completed, let’s see what we have from a resource standpoint. Here you can see that we have two load balancers, one for the swarm agent and another for the swarm master. In addition, we have an availability set that includes the three masters (spread across 3 fault domains and 5 update domains) and a VM scale set that includes the three agents. All of which makes up the container service.

Swarm resources

Here we have the virtual network along with the public IP for the LBs, and the associated nics for each master server.

Swarm resources 2

And finally the storage accounts. You may be wondering why are there so many. The storage account ending in …swarmdiag0 is for the diagnostic logs. The storage account ‘ye4r6pe25gdmsswarm0’ includes the 3 OS disks for the masters. The remaining 5 storage accounts are for the OS disks of the agents. Since the VMSS is limited to 100 VMs with the recommendation of 20 VMs per storage account, this gives us 5 storage accounts. Since we only have 3 agents you will notice that 2 of the storage accounts are empty. However, when you scale the VMSS, the VMs will be distributed across all 5 storage accounts. This will also help to avoid IO contention since standard storage accounts are limited to 20,000 IOPS.

Storage accounts

Now that we have the container service deployed and understand what our resources are, let’s see what this looks like from an architectural standpoint. Here you can see that by default there are 3 NAT rules configured with port 22 load-balanced for the swarm master. In addition, application traffic is being load-balanced for the swarm agents.

swarm architecture
Image courtesy of Microsoft

Connecting to ACS Cluster

To connect to the cluster we will create an SSH tunnel with Putty on Windows. If you don’t already have Putty downloaded to your system, you can find it from the link mentioned above. The reason for creating a tunnel is to have encrypted communications between my localhost and the ACS cluster (specifically the swarm master).

First, we need to locate the public DNS name of load-balanced masters by opening the Resource Group and clicking on the swarm master IP resource. Copy the DNS name.

swarm master IP

Open Putty and enter a host name that is comprised of the cluster admin user name and the public DNS name of the master ( Enter 2200 for the port. Select SSH and Auth and Browse for the private key we created earlier. Next, select Tunnel and enter 2375 for the Source Port and localhost:2375 for the Destination and click Add. Optionally you can give the session a name and Save it for later use. Click Open when you are ready to connect. Click Yes to accept the connection.

putty configuartion

We can confirm our connection by reviewing the Putty event log. Now we are ready to start using Docker.

Putty event log

Managing Containers with Docker Swarm

Now that we are connected to the master, let’s verify that we have two containers running on each of the masters by typing “docker ps”. The containers present are “swarm” and progrium/consul” which are used to create and manage the cluster.

master containers

Now lets check to see if we have a swarm cluster. Type “docker node ls” to view the nodes that are participating in the cluster. The response shows us that the node is not a swarm manager. To create the swarm cluster we type “docker swarm init” on the master. The response shows the node is now acting as a manager.

docker swarm init

If we have more than one master, which in most cases we would, we will need to join the other members to the cluster. You can type “docker swarm join-token manager” to get the command for joining another node as a manager to the swarm.

docker swarm join-token manager

Now we need to login to the other two masters and run this command. Following the same approach as connecting to the first master but changing the port to 2201 and 2202 respectively.

swarm join node 1

swarm join node 2

Once all the master have been joined to the swarm we will connect back to the first master and type “docker node ls” which will show all the masters that have joined the swarm as a manager. Notice the one marked with Leader.

Note: An important concept to understand is that this is not where you will run your application containers. Those will run on the agents.

docker node ls

(Optional) If we needed to remove a master we can do so by logging into that master and type “docker node demote <name>” then “docker swarm leave”. Then log back into the leader and type “docker node ls” shows that the master is in a down status. Now we can remove it by typing “docker node rm swarm-master-xxxxx-x”. Typing “docker node ls” will show the master has been removed.

remove docker node

(Optional) To add a master back into the swarm, we just log into that master and type the “docker swarm join <token> host:port” command that we discovered earlier.

docker swarm join node 1

After logging back into the leader again, we can also see the details of each master by typing “docker node inspect <ID>”.

docker inspect

Now that we have our swarm cluster. Let’s review the agent nodes and their status. Type “docker -H tcp://localhost:2375 info” which shows the swarm agents and their details.

swarm agent info

Now we need to export the the DOCKER_HOST variable to ensure that our application container will start against the agent endpoint and not on the local swarm master. Type “export DOCKER_HOST=tcp://” which can be found from the previous output listed as Primary. Now when we type “docker ps” we don’t see any containers.

export docker_host

Now we can create a container by typing “docker run -d -p 80:80 dubuqingfeng/docker-web-game” and verify that its running. If this image is not available you can swap it with another.

pull container

To verify that we can access our container we need to locate the DNS name of the swarm agent load-balancer. We can find this by selecting the swarm-agent IP resource and copy the DNS name.

swarm agent DNS

Open your favorite browser, paste, and voila. We have games. Translate the page if you like and select Get Started and you can play Mario Brothers.



Azure Container Service really helps to get containers up and running and allows you to use either Swarm or DC/OS as the orchestrator. In this blog post I showed you how to stand up ACS, how to connect to it, and then how to deploy a Swarm cluster with a simple container running on it. I hope that you have enjoyed this post and feel a little more comfortable with Azure Container Service and Docker Swarm. Stay tuned for more on Docker.