Anthony Chu

Update (January 2018) The ACI Connector has been replaced by the Virual Kubelet project. The functionalities are similar but the installation steps are slightly different.

Azure Container Instances (ACI) allows us to run containers without worrying about infrastructure. We can give it any container image and it'll happily run it; it'll even provision an external IP address for the container. It's "serverless containers": we're only charged when the containers run. It's great for batch workloads or long-running containers where we don't want to deal with infrastructure.

ACI provides a low-level infrastructure building block for running containers. We can sort of think of it like a VM; instead of running a VM image, it runs a container image.

One exciting example of how ACI can be used in combination with a container orchestrator is the experimental ACI Connector for Kubernetes. When installed in a Kubernetes cluster, the ACI Connector creates virtual nodes in the cluster. They behave like nodes with unlimited capacity. We can schedule pods to run on them, but they will actually be run as container groups on ACI.

Perhaps, one day, ACI Connector will be the foundation that enables "serverless Kubernetes"... imagine an Azure Container Service (AKS) Kubernetes cluster that has no physical nodes, and all work is scheduled on Azure Container Instances!

Recently, Windows container support was added to ACI Connector for Kubernetes. Today, we'll take a look at how to use it to run Windows containers.

When I last blogged about ASP.NET 4.x applications and web.config transformations in Windows containers, I was baking the transform files in the container images themselves. While this worked, the secrets were stored inside the container images. A much better approach is to supply the transformation at the time of container startup; we can do this by mounting a file when starting the container.

It's a common and useful practice to configure a container using environment variables. However, ASP.NET 4.7 and older versions use Web.config files for configuration, and there's no built-in mechanism to override those settings using environment variables. ASP.NET 4.7.1 adds an extensibility point called configuration builders that allows overriding configuration from sources including environment variables, but this requires us to upgrade the app to 4.7.1 and needs some minor changes to the codebase.

So I started thinking if it's possible to containerize ASP.NET applications in a way that allows us to override configuration using environment variables without the need to upgrade the app to 4.7.1 or change any code. This would make it much easier to lift and shift existing ASP.NET workloads to containers.

In Azure, the recommended place to store application secrets is Azure Key Vault. ASP.NET Core makes it easy for an application to read secrets from Key Vault, but the application needs to be given valid credentials to do so. These credentials are often stored in plain text in an app setting, allowing anyone with access to the application to see them.

Managed Service Identity (MSI) was created to solve this problem. We can use it to access Key Vault without storing any secrets or credentials information in our web application.

Today, we'll take a look at how to use ASP.NET Core with MSI and Key Vault to properly secure and access secrets.

Azure Cosmos DB can replicate a single account's data to as many of Azure's 30+ regions as we want to. Applications around the world can read from the closest location to minimize latency. Write operations, however, are still sent to a single designated write region.

Update: July 19, 2018 - Cosmos DB now has multi-master support to allow writing to the closest region!

Thankfully, the write region can be changed. A read region can be designated as the new write region in a matter of seconds, and this change can be initiated programmatically via a REST API. If our application's dominant workload changes regions based on time of day, we can respond by changing the write region to the one with the most activity. Sometimes this strategy is called "follow the sun" or "follow the clock".

Today, we'll look at how to use Azure Functions to automatically change a Cosmos DB account's write region on a schedule. We'll do this using Azure's newly announced Managed Service Identity feature.