Introduction
With the changing application development and deployment paradigm from monolithic to microservices to more advanced one, a need of automation arises, which includes the automatic scheduling of the micro-components to our servers, automatic configuration, supervision, and failure handling. Not only deployment combination count increases but the interdependencies of the components also rise. This calls for the automation which takes responsibility for automatic scheduling, configuration, monitoring, error handling, and scaling. Hosting the microservices in containers solves the purpose but then comes the question of orchestration. If a microservice needs to be hosted in a container it also needs the orchestration of the container.
This is exactly where Kubernetes comes into the picture.
Kubernetes not only benefits development team in application deployment but also is a boon for the DevOps team that helps in monitoring and error handling. Kubernetes offers a layer of abstraction where the DevOps do not have to worry about keeping an eye upon the individual applications rather they manage and supervise Kubernetes and other related infrastructure.
In the last two articles, we learned how to create ASP.NET Core application and dockerize it and then deploy it on the local Kubernetes cluster.
In this article, we will learn how to deploy the already created dockerized ASP.NET Core application to Azure Kubernetes Cluster. We’ll also explore Azure Container Registry (ACR).
Thesis
In this article, we'll demonstrate how to orchestrate the deployment and scaling of an entire ASP.NET Core application using Docker and Azure Kubernetes Services. The entire article will be divided into three parts as follows.
From the last article, the Docker image of the application is ready, it’s time to push the image to the registry. We’ll use
Azure Container Registry that can be shared with other developers if needed.
Time to use Azure CLI. Log in to Azure using the az login command.
Create a resource group with the name as aksgroup and the location as australiaeast.
Run the az acr create command, specify the name as learningaksacr, the resource group as aksgroup, the location as australiaeast, and the sku as standard.
After the container registry being created, the image needs to be pushed. Use the az acr login command and specify the name of our registry, which is the learningaksacr.
After successful login, before pushing, tag the local image with the login server name of the container registry. Type az acr list -o table command. Copy the login server name and keep it handy. To list the Docker images available on this machine, we can use the docker image list command. We have the aks:local image, which needs to be tagged using the login server name.
Now, run the docker tag command, specify the local image name, which is the aks:local; specify the new name, which is going to be the login server name; then the image name and the tag, which is going to be aks:v1.
Verify this by docker image list command and we see the successfully tagged image. Both local and tagged image share the same image Id.
Now use docker push command to push the tagged image to the registry.
Once pushed, use the az acr repository command with the list argument, specify the name of the registry, and display the output in a tabular format. The result of the command shows that we have successfully pushed our image to Azure Container Registry (ACR).
This image can now be used or accessed by any other Docker machine or the AKS cluster can easily pull this image from the registry.
Deploying Azure Kubernetes Service (AKS) Cluster
We deployed the Kubernetes cluster locally, now it’s time to deploy to Azure using Azure Kubernetes Service(AKS). With AKS, a production-grade Kubernetes cluster could easily be provisioned. Before proceeding, create a service principal i.e. registering the application to Azure Active Directory (AD) and create an identity for it. It is required if the application is needed to expose to other Azure services. This identity is called a service principal. Create a service principal using the Azure CLI by using the az ad sp create-for-rbac –skip-assignment to create a service principal. Once created you get the details as shown in the following image.
![Azure Kubernetes Services - Deploying ASP.NET Core Application To Azure Kubernetes Services]()
Keep the appId and password handy and now it’s time to grant the permissions to the service principal to pull the images from the ACR. I am using PowerShell window here. Get the ACR resource ID using the az acr show command. Then, grant the reader role to the AKS cluster so that it can read the images stored in ACR using the az role assignment create command. Use the app ID that was copied earlier, and the scope is set to the resource ID of the ACR, which was fetched from the az acr show command.
Now, create our AKS cluster using the az aks create command as shown in the following image. Provide a name, the resource-group. For the node-count, make it a single worker node. Use the generate-ssh-keys to generate the SSH public and the private key files. Specify the service-principal and the client-secret, which is the application ID and the password copied earlier. Run the command.
After the deployment is complete, and to connect to our AKS cluster from the client computer, use the kubectl command-line interface.
The .kube file located at the user’s location as shown in the following image contains the server setting set to a local server running on port 6445.
Get the credentials of our AKS cluster, i.e., just deployed by using the az aks get-credentials command, specify the name and the resource-group name.
Now, go back to the .kube\config and notice that server now reflects the AKS cluster running in Azure.
To verify, execute the kubectl get nodes command.
As a result, we can see a single node worker confirming the successful provisioning of our Azure Kubernetes Service cluster.
Deploying ASP.NET Core Application to AKS
The cluster is all set for the application to be deployed into it now.
Open the aksdeploy.yml file at the root of the application.
As of now, the image is referring to a local Docker image. We need to change it to refer to the image we pushed to our Azure Container Registry.
So, instead of aks:local, provide the image name on the server with the tag as well as shown in the following picture.
Earlier we deployed this application to the local cluster and used the service type as NodePort. Now that we're deploying those to a cloud service like Azure, we can change the type to LoadBalancer.
Save the file. Again, use kubectl apply command for deployment.
This will create defined Kubernetes objects, which includes deployment and service. The service created exposes the application to the internet.
To monitor the progress of the deployment, use the kubectl get service command with the --watch argument. Initially, the external IP of the aks deployment service appears as pending. Once the external IP has changed from pending to an IP address, copy the IP.
To test your application, browse to the external IP address.
We can see our application running on a worker node within an AKS cluster.
Conclusion
This article was an end to end article to understand how to containerize and deploy an ASP.NET application to local Kubernetes and Azure Kubernetes Service. We also explored the role of Azure Container registry in the article.