Most of you are probably writing new service apps to run on modern PAAS platforms like Azure Service Fabric, but what are we going to do about the legacy apps? What if there is no budget or interest for rewriting legacy apps to modern platforms? Many enterprises have LOB or third party apps that were designed to run on a Classic Windows OS platform in an Active Directory domain. For various reasons, enterprises are migrating as much workload as they can to Azure, and these classic apps can usually be deployed onto a Windows VM in Azure in pretty much the same manner as they deployed onto a VM or physical host on-premises. But what if there was a better way? What if we could get those apps deployed onto as modern platform, such as Containers, without rewriting a single line of code? If you have looked into this you already know there are lots of obstacles, but I’m here to tell you that it can be done.
In this series of articles, I’m going to cover how to get legacy apps to run on Windows Containers in Azure without changing a single line of source code. I’m not going to spend a lot of time going over why Containers as so awesome, but I will point out that:
- Containers are MUCH easier to manage in all stages of life, and
- you can pack lots of low demand apps (which would otherwise require lots of VMs) into a single VM.
The first wave or posts will preset a completely manual way of doing things. A later post will present some automation and Docker Files that will really simplify things.
Special Considerations for Legacy Apps
We have identified three major aspects of the deployment of legacy apps onto Windows Containers on Azure that might need special attention depending on the architecture of the apps.
- Active Directory Support
- IIS Installation and Management
- Multi-tenancy Port Collision
Active Directory Support
Many legacy apps use Active Directory for authentication of entities and authorization of access to services. We will demonstrate how to use Group Managed Service Accounts and new security features in Windows Containers to enable a limited level Active Directory support.
IIS Installation and Management
Many legacy apps are based on IIS and ship with documentation which describes deployment and management operations primarily via the IIS Manager. This console is a GUI. Windows Containers do not support any form of GUI, all 'local' operations must be performed via a command line interface. We will demonstrate how to prepare containers for IIS administration via a remote instance of the IIS Manager.
Multi-tenancy Port Collision
Many apps (legacy and modern) provide service interfaces on TCP ports. Many of these service interfaces expect to reside on a well-known port, for example HTTP (80) and HTTPS(443). The current implementation of Windows Containers employs a port mapping mechanism to expose ports running on the container to access from outside the container, and any other access from the network to the container is blocked. All access to the services on the container must be made via a mapped port on the container host. Obviously port numbers cannot be shared by multiple services, so each service must map to a unique port number. This is usually a blocker, especially with HTTP clients which usually expect to operate on the well-known ports. We will demonstrate how to use the Azure Load Balancer to resolve this issue.