Anthony Chu

A couple of months ago, AzCopy was quietly added to Windows App Service and Azure Functions worker instances at D:\devtools\AzCopy\AzCopy.exe. It is used to upload files to blob storage from the command line. App Service allows the running of arbitrary scripts during deployment, meaning that there are a couple of scenarios that are now possible by calling AzCopy during App Service Git deployment, including deployments with a "Deploy to Azure" button:

• Upload files to blob storage for serving from a CDN during a Web App deployment
• Upload a single page application (SPA) frontend to blob storage during an Azure Function App deployment

Today, we'll use Joe Raio's popular Azure Functions Tug of War demo app to show how to upload the app's frontend assets to blob storage during deployment.

Azure Container Service (ACS) makes it really easy to provision a Kubernetes cluster in Azure. Today, we'll walk through the steps to set up a hybrid Kubernetes cluster with two agent pools: one for Linux and one for Windows. We'll also install an ingress controller and set it up with free and automatic SSL certificate management using Let's Encrypt. We should be able to do this in a few steps and under 20 minutes.

We'll then test out our cluster by deploying a hybrid application consisting of an ASP.NET application in a Windows container and a Redis instance in a Linux container.

Here's a simplified view of what we'll be deploying:

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.