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!

Landscaping a Secure/Closed Loop Infrastructure in Azure with Terraform & Azure Devops

Introduction

Posts about security are always the ones that make everyone get really excited… Or maybe not everyone. 😉 Anyhow, what is typically the weakest link in any security design? Indeed, the human touch… The effects of this can range from having seen secrets to creating drift (unwanted changes vs de expected baseline). In today’s post, I’ll walk you through an example setup that aims to close some additional holes for you. How will we be doing this? By basically automating the entire infrastructure management with Azure Devops & Terraform. Now you’ll probably think, what does that have to do with security? Good response! We’re going to reduce the points to where human contact can interfere with our security measures. Though we want to do this without putting our agility at risk!

 

Blueprint

For this exercise, we’re going to leverage this blueprint ;

Generating a docs website powered by Git & Markdown

Introduction

Did you know I’m a huge fan of the Microsoft / Azure docs? Did you also know that the docs websites are powered by GitHub repositories? Let that one sink in… So you can leverage the same way you collaborate on code, work on publishing documentation?!? How awesome is that!

After a bit of looking around, it appears DocFX is actually powered to do this. I don’t know if this is the tool used behind the docs website. Though there seem to be a lot of similarities. Anyhow, today’s post will be a quick walkthrough on how to setup DocFX with VSTS to publish your GitHub driven repo to an Azure Web App.

 

So what will we be needing?

Ingredients

• GitHub repository
• VSTS Account
• Azure App Service
• A tool to do the conversion : DocFX
• Chocolatey to install DocFX

 

Initialize the repository

Be sure to install DocFX on your dev station to initialize the repository. This is done by running “docfx init -q” inside of your repository.

 

Afterwards do your typical Git magic to sync your local version with GitHub (or equivalent). Now you’ll have a dummy skeleton ready for usage, and you can now structure it to your liking! My effort is going into making docs for VMchooser.

Azure : “My first REST API Call”-tutorial

Introduction

For today’s post, we’re going to do a REST call towards an Azure API. For this we’re going to create a “Servce Principal” and afterwards use the credentials from this object to get an access token (via the Oauth2 Client Credentials Grant) for our API.

 

Protocol Flow

What’s the flow going to be?

1. The application does a clients_credential call. Here it’ll provide ;
   1.  it’s application id as a client_id
   2. it’s secret as the client_secret
   3. choose “clients_credentials” as the grant_type
   4. set the “resource” to “https://management.azure.com”
2. AAD will return an access token
3. You can now call the API adding an additional header ;
   1. Header Name = Authorization
   2. Header Value = “Bearer *accesstoken*”
4. The API will return a response

(Source : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service )

 

Now let’s see how that would look in reality?

From Github to ACI – A tale how to use Visual Studio Team Services & Azure Container Registry for Container CI/CD

Introduction

Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;

To here ;

By using a CI/CD pipeline.

 

Flow of the day

What will we be doing today?

• Kick-off a VSTS build once a change has been made to our Github repo
  • Build a container via VSTS
  • Publish the container to an ACR (Azure Container Registry)
• Kick-off a VSTS release once the build succeeded
  • Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath

Sound cool? Let’s get to it!

Azure : Pushing Azure Resource Manager Templates through a CI/CD (release) pipeline with Visual Studio Team Services

Introduction

From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…

Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!

 

Prerequisites

Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉

Azure : Deploying a domain controller via DSC pull

Introduction

Today’s blog post will showcase how you can leverage the DSC pull feature of Azure Automation when deploying workloads to Azure. To many, the following question will pop up ; “Why use a pull mechanism, whilst I could use the DSC extension to push my configs?”. The answer is pretty simple  The pull mechanism facilitates the lifecycle flow of workloads better. You can easily update the config of the virtual machine and do follow-up on the rollout of your configuration.

 

The Flow

Now how would such a flow go?

1. We’ll use an ARM template to deploy (and afterwards keep) our Azure Automation Account (up-to-date)
2. We’ll use a script to import the Powershell modules into our Azure Automation Account, which are needed to compile configurations.
3. We’ll use a script to import & compile the DSC configurations into ou Azure Automation Account.
4. We’ll use an ARM template to deploy the domain controller.
5. This ARM template will also register the VM with the Azure Automation Account and link it with a given DSC configuration.
6. The configuration will be applied and the updates will be reported back to the Azure Automation Account.

 

Deep-dive Demo

(EDIT 30/7/17  : Added network pre-req)

Azure Governance – Policy Automation

Introduction

In my last post I talked about the possibility to manage “Azure Resource Manager Policies” via the portal. Where the policy is a good location to view the policies, this is not the area you want to be managing your policies! In today’s post, we’ll look how we can automate these things. This to ensure that all policies are effective towards their scope and remain that way. Once your subscriptions grows, you can have way too many resources & resource groups at your hands. Setting up things manually is not the way to go…

 

Microsoft Azure Enterprise Scaffold

How to do governance in Azure is a very common questions. So if you have found yourself asking questions in regards to that topic, do not feel strange! One of the prime resources I can recommend in this area is the “Microsoft Azure Enterprise Scaffold” ;

The scaffold is based on practices we have gathered from many engagements with clients of various sizes. Those clients range from small organizations developing solutions in the cloud to Fortune 500 enterprises and independent software vendors who are migrating and developing solutions in the cloud. The enterprise scaffold is “purpose-built” to be flexible to support both traditional IT workloads and agile workloads; such as, developers creating software-as-a-service (SaaS) applications based on Azure capabilities.

An alternative way to landscaping in Azure… Terraform!

Introduction

In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?

• We’ll be creating a kind of service user in Azure which Terraform will use to log in.
• We’ll be authoring a small configuration file that will serve as the input for our network
• We’ll be applying that configuration file.

Seem simple enough? Let’s get started!

Azure : Mixing LogicApps & Functions as a periodic data retriever

Introduction

There are various articles/blogs/etc that compare logicapps vs flow vs functions vs azure automation, etc… Though there was one use case where I often struggled what to use ;

What to use when I want to retrieve a file from X on a Y timed interval?

Azure Functions? Great abstraction, though the output files have random names. Sometimes / Often I want to be able to control that.

Flow? Doesn’t allow the customization I was looking for. More to integrate existing / popular services.

Azure Automation? Very good and gets the job done. The only downside, you need to code a lot of logic yourself.

Azure Logic Apps? Shows potential, but doesn’t let you include custom functions. Or does it…?!?

You can link Azure Functions to Logic Apps and create some the flow I was looking for.

 

The Flow

So what do I want to do?

• On a daily basis
• Retrieve content from an authenticated API
• Save the content to a Blob storage

And afterwards I’ll use other services to process that data. 🙂

 

The Proof-of-Concept

What do I want to achieve? On a daily basis I want to retrieve data from a service provider that serves sports data. And if you are looking for such a thing, check out MySportsFeed! So back to our proof-of-concept; how will this look in Logic Apps?

Let’s dissect this flow…