If you are attending my session and would like to undertake the exercise here’s what you’ll need to install locally, along with instructions on working with the code.
Pro-tip: As this is a demo consider using an Azure Region in North America where the compute cost per minute is lower than in Australia.
Prerequisites
- Visual Studio 2017: Community Edition.
- Docker for Windows: make sure to grab the stable release!
- Install a copy of PuTTY.
- Grab the demo code from Github (account not required).
- Demo 1: ASP.Net Web API (.Net Framework 4.6.1).
- Demo 2: ASP.Net Web API (.Net Core 1.1) – 1.0 Container Tag
- Demo 3: ASP.Net Web API (.Net Core 1.1) – 1.1 Container Tag
- Azure CLI 2.0: see how to install on the Microsoft Docs site (note: requires you to install Python).
- Install the Kubernetes tooling by reviewing the prerequisites for using the management UI.
- Create an Azure Container Registry instance – you can use this handy shortcut link to take you to the right place!
- Create an Azure Container Service instance, select Kubernetes as the orchestrator. See below for how to do this (hint: don’t use the Portal!)
Note that for both the Azure CLI and Kubernetes tools you might need to modify your PC’s PATH variable to include the paths to the ‘az’ and ‘kubectl’ commands.
On my install these ended up in:
az: C:\Users\simon\AppData\Roaming\Python\Python36\Scripts\
kubectl: c:\Program Files (x86)\
If you have any existing PowerShell or Command prompts open you will need to close and re-open to pick up the new path settings.
Readying your Docker-hosted App
When you compile your solution to deploy to Docker running on Azure, make sure you select the ‘Release’ configuration in Visual Studio. This will ensure the right entry point is created so your containers will start when deployed in Azure. If you run into issues, make sure you have this setting right!
If you compile the Demo2 solution it will produce a Docker image with the tag ‘1.0’. You can then compile the Demo3 solution which will produce a Docker image with the tag ‘1.1’. They can both live in your local environment side-by-side no issues.
Log into your Azure Subcription
Open up PowerShell or a Command Prompt and log into your subscription.
az login
Note: if you have more than one Subscription you will need to use the az account command to select the right one.
Creating an Azure Container Service with Kubernetes.
Before you do this step, make sure you have created your Azure Container Registry (ACR). The Azure Container Service has some logic built-in that will make it easier to pull images from ACR and avoid a bunch of cross-configuration. The ACR has to be in the same Subscription for this to work.
I chose to create an ACS instance using the Azure CLI because it allows me to control the Kubernetes cluster configuration better than the Portal.
The easiest way to get started is to follow the Kubernetes walk-through on the Microsoft Docs site.
Continue until you get to the “Create your first Kubernetes service” and then stop.
Publishing to your Registry
As a starting point make sure you enable the admin user for your Registry so you can push images to it. You can do this via the Portal under “Access keys”.
Start a new PowerShell prompt and let’s make sure we’re good to by seeing if our compiled .Net Core solution images are here.
docker images REPOSITORY TAG IMAGE ID CREATED SIZE siliconvalve.gab2017.demowebcore 1.0 e0f32b05eb19 1m ago 317MB siliconvalve.gab2017.demowebcore 1.1 a0732b0ead13 1m ago 317MB
Good!
Now let’s log into our Azure Registry.
docker login YOUR_ACR.azureacr.io -u ADMIN_USER -p PASSWORD Login Succeeded
Let’s tag and push our local images to our Azure Container Registry. Note this will take a while as it will publish the image which our case is 317MB. If you updated this in future only the differential will be re-published.
docker tag siliconvalve.gab2017.demowebcore:1.0 YOUR_ACR.azurecr.io/gab2017/siliconvalve.gab2017.demowebcore:1.0 docker tag siliconvalve.gab2017.demowebcore:1.1 YOUR_ACR.azurecr.io/gab2017/siliconvalve.gab2017.demowebcore:1.1 docker push YOUR_ACR.azurecr.io/gab2017/siliconvalve.gab2017.demowebcore:1.0 The push refers to a repository [YOUR_ACR.azurecr.io/gab2017/siliconvalve.gab2017.demowebcore] f190fc6d75e4: Pushed e64be9dd3979: Pushed c300a19b03ee: Pushed 33f8c8c50fa7: Pushed d856c3941aa0: Pushed 57b859e6bf6a: Pushed d17d48b2382a: Pushed latest: digest: sha256:14cf48fbab5949b7ad1bf0b6945201ea10ca9eb2a26b06f37 size: 1787
Repeat the ‘docker push’ for you 1.1 image too.
At this point we could now push this image to any compatible Docker host and it would run.
Deploying to Azure Container Service
Now comes the really fun bit :).
If you inspect the GAB-Demo2 project you will find a Kubernetes deployment file, the contents of which are displayed below.
If you update the Azure Container Registry path and insert an appropriate admin secret you now have a file that will deploy your docker image to a Kubernetes-managed Azure Container Service.
At your command line run:
kubectl create -f PATH_TO_FILE\gab-api-demo-deployment.yml service "gabdemo" created deployment "gabdemo" created
After a few minutes if you look in the Azure Portal you will find that a public load balancer has been created by Kubernetes which will allow you to hit the API definition at http://IP_OF_LOADBALANCER/swagger
You can also find this IP address by using the Kubernetes management UI, which we can get to using a secured tunnel to the Kubernetes management host (this step only works if you setup the ACS environment fully and downloaded credentials).
At your command prompt type:
az acs kubernetes browse --name=YOUR_CLUSTER_NAME --resource-group=YOUR_RESOURCE_GROUP Proxy running on 127.0.0.1:8001/ui Press CTRL+C to close the tunnel... Starting to serve on 127.0.0.1:8001
A browser will pop open on the Kubernetes management portal and you can then open the Services view and see your published endpoints by editing the ‘gabdemo’ Service and viewing the public IP address at the very bottom of the dialog.
If you hit the Swagger URL for this you might get a 500 server error – this is easy to fix (and is a bug in my code that I need to fix!) – simply change the URL in the Swagger page to include “v1.0” instead of “v1”.
Upgrade the Container image
For extra bonus points you can also upgrade the container image running by telling Kubernetes to modify the Service. You can do this either via the commandline using kubectl or you can edit the Service definition via the management web UI (shown below) and Kubernetes will upgrade the Container image running. If you hit the swagger page for the service you will see the API version has incremented to 1.1 now!
You could also choose to roll-back if you wanted – simply update the tag back to 1.0 and watch the API rollback.
So there we have it – modernising existing .Net Windows-hosted apps so they run on Docker Containers on Azure, managed by Kubernetes!
