How to manually size your Azure Virtual Machine Scale Sets (vmss)?

Whilst exploring the Azure container service preview. One of the key components here is the “virtual machine scale set“. But as you can see, at the moment there isn’t much to configure via the portal…

So how can you (manually) update your virtual machine scale set? Use the following arm template : https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-scale-existing

Here you can enter the name of your virtual machine scale set and the new scale set capacity (or size). Execute the deployment and wait for a bit…

Even before the deployment finishes, you’ll see that the capacity has been changed.

Azure Resource Manager : Deployment variants within one script

Introduction
Today a quick post to show you that you can setup a deployment with several variants within the current template functions.
So for this post we’ll be combining the deploment for the rancher <a href="https://kvaes.wordpress.com/2016/01/22/deploying-rancher-server-via-an-azure-resource-manager-template/”>server & nodes into one script.

Docker : Storage Patterns for Persistence

Introduction

One of the sensitive areas when it comes to docker is persistent storage… A typical service upgrade involves shutting down the “V1” container and pulling/starting the “V2” container. If no actions are taken, then all your data will be wiped… This is not really the scenario we want off course!

So today we’ll go over several variants when it comes down to data persistence ;

• Default : No Data Persistence
• Data Volumes : Container Persistence
• Data Only Container : Container Persistence
• Host Mapped Volume : Container Persistence
• Host Mapped Volume, backed by Shared Storage : Host Persistence
• Convoy Volume Plugin : Host Persistence

What do I mean with the different (self invented) persistence level ;

• Container : An upgrade of the container will not scratch the data
• Host : A host failure will not result in data loss

So let’s go through the different variants, shall we?

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

Azure : ExpressRoute Connection Methods

Introduction

In the past I’ve already explained a bit on ExpressRoute… This is a topic on which I’ve had a vast amount of discussions in the past.

Thomas was a worthy sparring partner and truly had a big share in those discussions. Recently he pinged me to say that the naming has shifted. So we’ll be covering that today.