Skip to content
This repository has been archived by the owner on May 7, 2024. It is now read-only.

26. Deploying to Azure

Jump to bottom
eiximenis edited this page Apr 17, 2018 · 1 revision

On the previous page, we added the files kubernetes needs for deployment. We've covered in detail all the minutia of deploying Kubernetes into Azure in other eShop tutorials, so we'll keep this brief. You can find this very detailed explanation here: Kubernetes and ACS

Prerequisites

In order to complete this portion of the tutorial, you'll need to have a few things already configured

  • An Azure subscription
  • Azure CLI installed
  • kubectl installed

If you do not have these things, refer to this tutorial in the Azure Quickstart Guide. Our tutorial below actually tracks very closely with the tutorial linked.

Deployment

The first thing that we need to is create a Resource Group in Azure. Let's execute this command:

az group create --name eShopResourceGroup --location eastus

The output should look like the image below.

Next, we need to tell Azure to build our orchestrator. TO do this, we need to specify which orchestrator we want to use and which resource group in our account we want to associate this result with. You should change the admin-username and admin-password in the command below.

az acs create --orchestrator-type=kubernetes --resource-group eShopResourceGroup --name=eShopK8SCluster --agent-count=2 --generate-ssh-keys --windows --admin-username azureuser --admin-password myPassword12

If you do not specify the windows flag, it will default to Linux. This command will take several minutes to complete, after which you should see output like the one below.

If no errors were returned, we're free to deploy via our yml files. Point kubectl to where the .yml files reside and let Kubernetes do the rest!

kubectl apply -f .\eshop-sql-container-deployment.yml
kubectl apply -f .\eshop-wcf-container-deployment.yml

You will see output like the image below.

We can poll our deployment and watch the status as the pods spin up. Under "status", we want to see both pods with the value of "running"

Kubernetes comes with a web-based UI which allows for you to diagnose issues, see the status of your pods, and do plenty of other things. Once your pods successfully spin up, we want to launch this so we can grab the external IP address of the WCF service. Additionally, if there was an error and your pods never reach the "running" status, we can also open this UI to get more information about the cause of the failure.

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kuber
netes-dashboard.yaml
kubectl get proxy

The last command will output the IP address and port that the Kubernetes Web UI is running on. For example, it should look like:

Staring to serve on 127.0.0.1:8001

Enter the address with the addition of /ui on the end (for example: 127.0.0.1:8001/ui) into a web browser. You will be greeted by a UI like the one below.

Under ReplicaSets, click on the WCF service.

You will find the IP that needs to go into the App.config our of Winforms app.

Taking this IP address, go into App.config in our WinForms solution and edit the endpoint:

<endpoint address="http://<YOUR NEW ADDRESS HERE>/CatalogService.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICatalogService"
                contract="eShopServiceReference.ICatalogService" name="BasicHttpBinding_ICatalogService" />

You can now launch the WinForms solution and you'll be greeted by the familiar view of the app - except this time, it's talking to our containers through Kubernetes in the cloud!

Next Steps

This marks the end of our journey of modernizing our WinForms & WCF app. You can learn more about the known bugs and quirks in this project by visiting Quirks and Known Bugs

Clone this wiki locally