The adoption of containers is exploding because their lightweight and portable nature enables more reliable software delivery and accelerated software development and testing. Windows applications in containers have not enjoyed the same explosive growth as Linux applications, mainly because of lack of production ready Windows container orchestrator and management. Analysts estimate that 85 percent of enterprise line of business applications are based on .NET and Java. A significant percentage of that 85 percent are workloads that are executing on soon End of Support Windows Server 2008 and Windows Server 2008 R2.
Kubernetes 1.14 changed everything. Starting with the 1.14 release, Kubernetes now includes official support for Windows containers. Windows developers and platform operators— you can now develop Windows applications in containers for portability and then centralize management alongside Linux-based applications in Kubernetes.
VMware Enterprise PKS 1.5 includes Windows container support as a beta feature, providing a turnkey solution to easily provision Windows-based workers in a Kubernetes cluster. In this blog, we will use blogengine, a popular open-source project based on the ASP.NET, to demonstrate how you can modernize a traditional Windows application in Windows containers. How you can then use VMware Enterprise PKS 1.5 to manage the life cycle of the newly containerized app using Kubernetes. Details of this app can be found here: https://github.com/rxtur/BlogEngine.NET
Windows Containers
Microsoft has been working since 2014 in making containerizing Windows apps relatively straightforward. Artifacts to build and generate Docker images are often integrated into common Integrated Development Environments (IDE) from Microsoft. Visual Studio, for example, has built-in support for Docker container automation. In order to containerize the application using Visual Studio, all you have to do is right-click the project and select Add->Container Orchestrator Support.
Visual Studio then adds the Dockerfile, compose files, and a Docker project to the solution. It also inspects the project to determine the proper base image to use for your project.
Here is the Dockerfile generated by Visual Studio for our sample app:
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-ltsc2019
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish}
With Dockerfile in place, you can use Visual Studio to build the Docker image locally on your Windows 2019 development server and test for functionality. Visual Studio automatically links the .NET debugger and leverages docker-compose to set the environment setting for Internet Information Services (IIS). Once the sample app works on a local development environment, you need to merge the actions defined in docker compose to a single Dockerfile:
FROM mcr.microsoft.com/dotnet/framework/aspnet:4.7.2-windowsservercore-ltsc2019
ARG source
LABEL maintainer="[email protected]"
SHELL ["powershell", "-command"]
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .
RUN "c:/Windows/System32/inetsrv/appcmd.exe set config -section:system.webServer/security/authentication/anonymousAuthentication /userName: /commit:apphost"
RUN c:windowssystem32inetsrvappcmd.exe set AppPool DefaultAppPool '-processModel.identityType:LocalSystem' /commit:apphost
ENTRYPOINT [ "cmd", "/c", "C:\ServiceMonitor.exe w3svc" ]
You can then push the final image to the Harbor container registry to trigger additional automated CI pipeline events for testing.
Kubernetes Cluster
To set up the Windows-based Kubernetes cluster, check out the beta documentation. At a high level, you start by building a Windows stemcell for VMware vSphere and upload to the stemcell library. https://docs.pivotal.io/pivotalcf/2-5/windows/create-vsphere-stemcell.html. Windows 2019 Server is the only currently supported operating system from the upstream kubernetes community.
Windows Server Container (WSC) mode is the Windows implementation of the shared kernel container runtime. For container applications to run in WSC mode, the kernel of the Windows container operating system must match the Windows container host operating system. Windows container applications share the common operating system kernel provided by the host; isolation is provided using namespace.
The Windows beta program is designed to allow Windows platform operators and developers to plan out how an application should behave when refactored or lifted and shifted to Kubernetes. VMware does not recommend adding Windows nodes to an existing VMware Enterprise PKS deployment; a dedicated instance of the Ops Manager is required for the beta. Once you deploy the new Ops Manager, you configure deployment plans for enabling windows worker node; up to 3 plans are supported for the beta. Within each plan, you can have up to 5 Kubernetes Linux-based master nodes, 1 Linux-based worker node, and the remaining nodes can be Windows Server 2019. All nodes will use flannel for container networking. VMware Enterprise PKS will fully manage the entire Kubernetes cluster IP subnet allocation.
Deploy to Kubernetes
After your Docker image is built and validated through your CI pipeline, you are ready to deploy your app using Kubernetes. Here is a sample Kubernetes YAML file referencing the latest blog engine image pushed to the Harbor image registry.
apiVersion: apps/v1
kind: Deployment
metadata:
name: blog-2019
labels:
app: blog-2019
spec:
replicas: 1
template:
metadata:
name: blog-2019
labels:
app: blog-2019
spec:
containers:
- name: blog
Image: demo.goharbor.io/xiaog/blogenginenet:latest
resources:
limits:
cpu: 1
memory: 800m
requests:
cpu: .1
memory: 300m
ports:
- containerPort: 80
nodeSelector:
"beta.kubernetes.io/os": windows
selector:
matchLabels:
app: blog-2019
apiVersion: v1
kind: Service
metadata:
name: blog
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 80
selector:
app: blog-2019
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: example
namespace: default
spec:
rules:
- host: www.blog-2019.com
http:
paths:
- backend:
serviceName: blog
servicePort: 80
path: /
If you want to create a blog engine deployment with one replica at the outset, you can run the following:
Kubectl apply -f blog-2019.yaml
Once the app is deployed, you can scale up or down based on the application SLA.
Kubectl scale deployment blog-2019 --replicas==x
If you have a newer version of the blog engine app, you can leverage Kubernetes to perform and upgrade or rollback.
Call to Action
You can now develop Windows applications in containers for portability and then centralize their management alongside Linux-based applications in Kubernetes. Instead of handcrafting each Windows app, you can take advantage of Kubernetes to scale up and down, perform upgrades and rollback. The journey to cloud native for a Windows app has never been simpler with VMware Enterprise PKS 1.5. I encourage everyone to sign up for the beta program today (https://k8s.vmware.com/windows-containers-on-kubernetes/)
