Setup an IIS Blue Green Environment with Azure Devops

Use case:

We want to achieve zero downtime deployments of a Web Application, using Blue/Green Websites (replicas) on a single IIS Webserver.

We will be using ARR (Application Request Routing) and leverage Azure Devops YAML Pipelines to automate the setup.

What is ARR?

Application Request Routing is the Load Balancer feature (and reverse Proxy) in IIS.

IIS Application Request Routing (ARR) 3 enables Web server administrators, hosting providers, and Content Delivery Networks (CDNs) to increase Web application scalability and reliability through rule-based routing, client and host name affinity, load balancing of HTTP server requests, and distributed disk caching. With ARR, administrators can optimize resource utilization for application servers to reduce management costs for Web server farms and shared hosting environments.

Application Request Routing

You can install it via the Web Platform Installer btw.

In our use case we are going to use ARR to orchestrate user traffic across two websites (Blue/Green) to achieve zerodowntime during deployments.

The Components

Once ARR is installed on the webserver we need:

• a Powershell script that leverages appcmd to set up our IIS Server Farm (which is the load balancer for our Blue/Green websites
• a YAML Template that calls the before mentioned script and performs other useful tasks
  👉Check out my other article if you are interested my Azure Devops YAML Template tips
• a main YAML Pipeline that calls the above template.

Most of the magic actually lies in the Powershell script which sets up the server farm, add the servers, binds the ports and finally configures the healthcheck.

This leads to the following prerequisites:

1. Your app must have some sort of healthprobe, in our case myapp.domain.io/api/pingreturns a simple pongwhen it’s up.
2. Also you need to ensure that ‘replica’ CNAMEs are pointing to the right server (in our case it’s the same host of the IIS ARR server).
   myapp.domain.io is the public facing endpoint
   myapp-8031.domain.io and myapp-8032.domain.io are the private ones which are only used by the ARR load balancer.
   📌note that I’m using ports as names for the replicas, you could use blue/green, red/black or whatever, it’s just easier to automate this way for now.

Powershell Script to Ensure Web Farm

# Create the farm
...
# Add health check
...
# Add servers to farm
...
# URL Rewrite
...

Get the full script here: https://github.com/mieel/azdo-iis-alwaysup/blob/main/scripts/Set-IisWebFarm.ps1

You can actually execute this script locally on the server as a one off thing, skipping all the pipeline stuff.

Deployment YAML template

Here the essentials parts to complete this use case.
We need to create a YAML Template, let’s call this file alwaysup-deploy.yaml
First you’ll need these parameters:

# alwaysup-deploy.yaml
parameters:
- name: StageName
  default: Development
- name: WebRoot
  default: 'D:\Webserver'
# IIS ARR Settings
- name: IisReplicaPorts
  type: object
- name: IisBaseUrl
  default: ''
- name: IishealthCheckUrl
  default: '$(IisBaseUrl)/api/ping'
- name: IishealthCheckResponse
  default: 'pong'
- name: IishealthCheckInterval
  default: '00:00:10'
- name: IisUseSsl
  default: false

📌Note that IisReplicaPorts is an object. This allows us to provide a list as input.

Then declare the Stage:

stages:
- stage: ${{ parameters.StageName }}
  variables:
  - name: PackagePath
    value: <Path/of/package-to-deploy>       
    # this should be your artifact download destination
  - name: DeployPath
    value: ${{ parameters.WebRoot }}\${{ parameters.SiteName }} 

In the stage, create a jobssection, with one jobwith the the following main steps:

Call the Powershell script to ensure the IIS Server Farm:

# alwaysup-deploy.yaml
..
stages:
  - stage:
    ..
    jobs:
    - job:
      steps:
      ..
      - task: PowerShell@2
        displayName: 'Ensure IIS Web Farm'
        inputs:
          filePath: path/to/script/Set-IISWebFarm.ps1
          arguments: "-BaseUrl ${{ parameters.IisBaseUrl }} -Replicaports @(${{ join(',',parameters.IisReplicaPorts) }}) -healthCheckUrl ${{ parameters.IishealthCheckUrl }} -healthCheckResponse ${{ parameters.IishealthCheckResponse }} -healthCheckInterval ${{ parameters.IishealthCheckInterval }} -Ssl  ${{ parameters.IisUseSsl }}"

Now we are going to do a foreach loop on the given replicaPorts input.

# alwaysup-deploy.yaml
parameters:
..
stages:
  - stage:
    ..
    jobs:
    - job:
      steps:
      ..
      ### Setup up IIS Websites
      - ${{ each port in parameters.IisReplicaPorts }}:
        - task: IISWebAppManagementOnMachineGroup@0
          displayName: Configure IIS Site ${{ port }}
          inputs:
            IISDeploymentType: 'IISWebsite'
            ActionIISWebsite: 'CreateOrUpdateWebsite'
            WebsiteName: ${{ parameters.SiteName }}_${{ port }}
            WebsitePhysicalPath: $(DeployPath)_${{ port }}
            WebsitePhysicalPathAuth: 'WebsiteUserPassThrough'
            CreateOrUpdateAppPoolForWebsite: true
            AppPoolNameForWebsite: ${{ parameters.SiteName }}_${{ port }}
            AddBinding: true
            bindings: '{"bindings": [{"protocol": "http", "port": "${{ port }}", "ipAddress": "*"}]}'
       ### Deploy Files into IIS Site Physical location
       - task: IISWebAppDeploymentOnMachineGroup@0
         displayName: Deploy IIS Web Site
           inputs:
           WebSiteName: '${{ parameters.SiteName }}_${{ port }}'
           Package: $(PackagePath)

Main YAML Pipeline

Finally in our Azure Devops Pipeline, reference the deployment Template like this:

#azure-pipelines.yaml
..
..
stages:
- template: path/to/alwaysup.yaml
  parameters:
    StageName: Staging
    SiteName: myapp
    IisReplicaPorts: 
    - '8081'
    - '8082'
    IisBaseurl: myapp.domain.io

Some things to note:

• Since our Template is in fact a stage on it’s own, you have to reference the Template in the stages section of the main YAML (azure-pipelines.yaml)
• the healthcheck parameters in alwaysup-deploy.yamlare optional, by default it takes */api/ping as the healthcheck url, and response should be pong
• 💡 You can actually set up more than two website copies using this script. Just provide more ports in the ReplicaPorts array.

End Result

So as the end result, you should have:

• a 💙Blue website: myapp-8081.domain.io , listening on port 8081
• a 💚Green website: myapp-8082.domain.io , listening on port 8082
• a Server Farm that listens to: myapp.domain.io
  which balances traffic between green and blue

Hitting myapp.domain.io/api/ping will return alternating responses from💙8081 and 💚8082 (default distribution is 50/50)

Next Steps

Now we have a Pipeline to set this all up, we need an automated workflow to perform actual zero downtime deployment. The one we have now will just deploy to both websites, and disrupt any connected user sessions.

First we want to direct all users to Green, when Blue is completely drained we can start updating it. (💙0/💚100)
Once the 💙deployment is done, we direct a small set of users to Blue (💙10/💚90)
When the tests are clear, we can start directing all users to Blue (💙100/💚0).
Once 💚Green is completely drained we can updating it as well, again testing it with a small subset of users (💙90/💚10).
Finally split the user traffic 💚50/💙50 again.

Ideally we want this all automated and I shall try to cover this in one of my next articles.

👉 Meanwhile you can check out this guys blog on how to automate some of these steps