Leveraging Azure Tags and Azure Graph for deploying to your Blue/Green environments

Introduction

For this post I am assuming you are pretty familiar with the concept of deployment strategies (if not check out this post by Etienne). Now these are typically seen from an application deployment level, where platforms (like for instance Kubernetes) typically have out-of-the box mechanisms in place to do this. Now what if you would want to do this on an “infrastructure level”, like for instance the Kubernetes version of Azure Kubernetes Service. We could do an in-place upgrade, which will carefully cordon and drain the nodes. Though what if things go bad? We could do a Canary, Blue/Green, A/B, Shadow, … on cluster level too? Though how would we tackle the infrastructure point of view of this? That is the base for today’s post!

 

Architecture at hand

For today’s post we’ll leverage the following high level architecture ;

This project leverages Terraform under the hood. Things like DNS, Traffic Manager, Key Vault, CosmosDB, etc are “statefull’ where its lifecycle is fully managed by Terraform. On the other hand, our kubernetes clusters are “stateless” from an Infrastructure-as-Code point-of-view. We deploy them via Terraform, though do not keep track of them… All the lifecycle management is done on operating on the associated tags afterwards.

 

Community-Tool-of-the-day

The drawing above was not created in Visio for once. The above was made leveraging CloudSkew, which was created by Mithun Shanbhag. Always awesome to see community contributions, which we can only applaud!

Taking a glance at Rancher’s ability to manage the Azure Kubernetes Service (AKS)

Introduction

Pfew, it’s odd to admit that it has been a while since I’ve posted about Rancher. Though today is as good a day as any to pick up that thread… So today we’ll go through give or take the same objective as in the past, where we’ll notice that the integration has improved significantly with the arrival of AKS! Let’s get today’s post underway and deploy AKS from our Rancher control plane.

Preparation

Before the below started, I already had the following things ready ;

• A service principal with appropriate rights
• Installed Rancher 2.0

How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?

Introduction

Yesterday Rancher commented on my github request for windows support ;

Tested with rancher-server version – v1.3.0-rc1 with catalog “library” set to vnext branch in https://github.com/rancher/rancher-catalog

Able to add “Windows Server 2016 Standard Evaluation” hosts successfully to rancher environment with orchestration set to “windows”.

Able to launch containers in “nat” network and “transparent” network.

@kvaes , Windows 2016 support will be available as experimental feature in rancher-server 1.3.0 release.

Great news! Let’s take it out for a spin… 😀

 

Rancher Host

Installing the host(s) is the same as any other time…  Though the host will still be a Linux machine off course ;

sudo docker run -d –restart=unless-stopped -p 8080:8080 rancher/server:v1.3.0-rc1

Though notice that I specified the v1.3.0-rc1 tag… And let the system do its magic!

(Update : For the stable, release you can omit the -rc1 part!)

Note ; Be aware that this is an early release candidate. Do not use this for your production! There is for instance a bug with the GUI, where the “Auto”-theme is malfunctioning. So switch to light or dark to get that one fixed. 😉

Rancher End-to-End Service Example using an Owncloud-plus-mysql Deployment

Introduction

So what will we be doing today? We are going to leverage the power of the combination between docker containers & the rancher eco system. As a demonstration, we’ll be publishing “Owncloud” with a “mysql” backend. As we tend to like it a bit more secure, we’ll introduce a loadbalancer service as SSL termination. This as we want to keep our “Owncloud” as “vanilla” as possible. We’ll be pointing that service towards the outside world and will make it accessible via the “external dns”.

What can we optimize further about the design? (but is out-of-scope for today)

• Add sidekick containers for backup purposes
• Add data volume containers
• Introduce scalable worker containers (“Owncloud”)
• Introduce convoy for our data containers

Microsoft Azure : Budget Automation for your Development / Test Environment

Billing-per-minute

What is one of the biggest business advantages of Azure? You are only charge for your actual usage per minute.  For many organizations, the cost of a development/test environment is a sore spot as this costs a handful of cash. Today will introduce you to Azure Automation, which will let you orchestrate things, as stopping/starting your environment.

What are we going to do?

• Setup a dedicated account for our scheduled runbooks
• Configure two runbooks ; “stop all servers” & “start all servers”
• Schedule those runbooks

 

Setup a dedicated account for our scheduled runbooks

In my opinion, you always needs to set up dedicated accounts for services. They should not be running under anyones “personal” account. At a given point they will leave the company. At that time, if the system is still active and the user account will be decommissioned, the system will cease to halt. In addition, this will also give you a traceability of the actions of the given service.

So how do you setup a dedicated account for the scheduled runbooks? Check the following post ; Azure Automation: Authenticating to Azure using Azure Active Directory

In summary, the steps you will need to do ;

• Create an additional user in your Azure Active Directory
  
• Add the user as a co-administrator to your account

It’s also advised to note down both the full username (dixit, username@account.onmicrosoft.com) and the password you have assigned. After the creation, be sure to login with the account. You will be asked to change your password. If you “forget” (too lazy huh?) to do this step, you will get an authentication error when trying to use this account for your automations (So yes, I tried to be lazy too…).

 

Configure two runbooks ; “stop all servers” & “start all servers”

In this phase, we’ll do the following

• Create the Automation account (“folder”) under the Runbooks will be stored
• Create a “start all servers” runbook from the gallery
• Create a “stop all servers” runbook from the gallery

 

Browse to “Automation”, select “Runbook” and then choose “From Gallery”

 

In the gallery, go to “VM Lifecycle Management”, and select “Azure Automation Workflow to Schedule starting of all Azure Virtual Machines”

Press next, review the code. The code is pretty straight forward… But we’ll get into that later on.

Now enter the name of your runbook, and choose “Create a new automation account”. Give the account a name and choose your subscription & region.

Now we’ll repeat the process for the “stop all servers” runbook.

Now browse back to the “Automation” screen ;

Before we can go on with these steps, we’ll need to add our user to the “Assets” of our “Automation Account”. Browse to “Assets” and select “Add settings”.

Select “Add credential”… Then use “Windows Powershell Credential” as “Credential Type” and name the credential.

Now enter the user information you noted down earlier… and press save.

You are now good to go!

Select “Runbooks”, now you can see both runbooks we just created.

 

Select the “Stop-AllAzureVM” & adjust the two parameters and press save ;

• -Name “username@domain.onmicrosoft.com”
• -Subscriptionname “Subscription Name”

Select the “Start-AllAzureVM” & adjust the three parameters and press save ;

• -Name “username@domain.onmicrosoft.com”
• -Subscriptionname “Subscription Name”
• -Name “Your Most Important Server”

What did we just do for both scripts? We entered the user account & subscription under which the script will be executed. This is a mandatory step and understandingly so. Now let us test the “StartAllAzureVM”-script… I’ve prepared two virtual machines, which are currently shutdown.

So we’ll press “Test” on the runbook…

And yes, we are sure. Azure Automation will save the runbook one more time to be safe.

 

The output pane will show the status “starting”.

And it will change to “running” after a while.

.

Once you see the code below, you will know that you have been authenticated. So all our hard work with creating the user paid off! If you do not see this, that is the part you should be debugging…

Suddenly our “most important server” will be showing the status “Starting”…

 

And the output pane will verify this status!

So basically, we are safe to say that our script works. Let’s publish the runbooks so that we can schedule them later on.

 

For each runbook, press the “publish”-button

We are sure, and you will see the runbook shift from “draft” to “published”.

 

Congrats so far! We are now ready to schedule those babies!

 

Schedule those runbooks

So which steps will we be doing in this phase?

• Create two schedules ; “start of business day” & “end of business day”
• Attach the “start” runbook to the “start of business day” schedule
• Attach the “stop” runbook to the “end of business day” schedule

 

Let us start creating the two schedules ;

 

Go to our “Automation Account” and select “Assets”. Here you press the “Add Setting”-button.

Choose “Add Schedule”

Enter the name…

The schedule…

Rince & repeat…

Now we have both schedules. One that will occur at 08:00 and another one that will occur at 17:00 (5pm). Now let’s link our runbooks…

Go to our “Automation Account”, and select “Runbooks”. Click on one of them

Go to “Schedule”, and press “Link to an existing schedule”.

Select the schedule…

And you will see the schedule attached.

 

Rince & repeat for the other one.

 

Summary

With the power of automation & a gallery of pre-made runbooks, we were able to save our business tons of money by only running the servers during the business hours. Be aware that the above example does not accompany holidays / weekends… In addition, the money saving is “limited” to the “compute”, as the storage of your devices will remain “active” (on disk).