Azure Kubernetes Service (AKS) with Azure DevOps — Part 1

A little personal history with Azure DevOps. This is a service heard so many times and maybe some of us tried to get it working so many times. One thing for sure is that I do not think anyone would have the confidence to say they know every aspect of this service. It covers not only the scopes of development and operations but also the communication and coordination within an organization. It could just achieve the day-to-day tasks in so many different ways!

Just like my other articles, this one is to share my personal learning and that would be the activities around building Docker images and deploy them on AKS! Alright, with the scope set, we would dive into the technical details. This article could be challenging if you do not know about Docker and Kubernetes operations.

  • Understand the basic process flow of Azure DevOps

Users that would like to start exploring Azure DevOps would need to understand this service is barely a tool to automate the actions developers or IT administrator do on a daily basis. Without proper understanding of what each operation means, it would be extremely difficult to complete the setup.

Prerequisite Actions

Continuous Integration (CI)

From my angle, I would say CI means the development side of the process. That could include application development, in other words programming, and also ensuring the latest codes would be submitted to the place to be deployed.

After countless searching on the Net, I could safely say there is no one article that would give you the full concept of what CI means and how it could be done. The reason is simple, everyone is getting into DevOps from their angle and that angle might not be familiar to you and me. So, I chose this article that actually has relatively clear explanation on the steps that would need to be set. Please follow all the steps under the topic “Azure DevOps” and you could fork my GitHub project (forked from shkube and modified) for practicing the concept.

  • Make sure a service connection from Azure DevOps to Azure Resource Manager (ARM) is created. This setup is for Azure DevOps to be able to leverage the yet-created Azure active directory service principal (AAD SP) for performing all sorts of operations. Normally, this AAD SP would be getting contributor role in the target Azure subscription. Please refer to this site for more information.
  • Within the CI pipeline, notice the file would be named as “azure-pipelines.yml) and all the actions would be added into the file in the following format. The operations we have here are
- Docker Compose (Build services): To read the "Dockerfile" in you connected repository, build a local container image and run an application based on that local container image.- Docker Compose (Push services): After knowing the container image could be build and run, tag the container image and push it to the target ACR.- Copy Files: This is to copy the file "deployment.yml" from connected repository to Azure DevOps space. Notice at this point, the referred image is still the local one.- Publish Artifact: Artifact is another word for whatever you created in the operation process. In this case, the copied file (deployment.yml) would be put in somewhere within Azure DevOps so future operations could use it.

If any additional step needs to be added, we could click on the circled icon and search for the right action.

If everything completes successfully, all actions should end with green check and a container image should be showing in the target ACR.

Moving on to Continuous Deployment (CD).

Continuous Deployment (CD)

CD to me means the process of making sure the code would run on the infrastructure (in this case, AKS). Please follow the process under the topic “Azure Releases” in the same article above. If you are like me, very new to the world of DevOps, pipeline here means the jobs and tasks you would need to perform. This could be using creating a new namespace inside AKS cluster or deploying the application to AKS cluster; release here means the overall configuration at that moment, so basically the overall “state” of the current jobs and tasks. It is confusing to me at first. However, when you think of a situation that the new configuration state might have issues that are hard to debug, the fastest way to get production environment to be back online is to use the last release. If we think it that way, it makes sense all of a sudden.

When clicking into the “1 job, 4 tasks” under “Dev”.

- Job: Only 1 agent job in this setup. However, you could add as many as needed.- Tasks:
1. Install Kubectl latest: This is pretty self-explanatory, which is installing the latest Kubernetes client command tool in the agent VM.
2. kubectl create: This is the operation to create a new namespace. With more and more deployments in the Kubernetes environment, you would need to separate them with namespaces. It is easy to find and easy to troubleshoot.3. kubectl apply: This is the operation to deploy the actual applications into the AKS cluster, which could include deployments, services, service accounts etc. 4. kubectl set: This is to switch out the image that is being used in the current deployment. We know that local container image works and is uploaded to ACR. Now, we would need to have the application to use the ACR's image instead of the local one. This is to ensure in the future, whenever there is a change in the container image, after the whole CI/CD process, the application would be running in the latest image.

Right now, it is time to see whether everything is working as expected within the AKS environment.

There are so many other operations that could be done with Azure DevOps, but the next article would be focusing on how to set up Visual Studio Code to integrate the code development process into the whole CI/CD pipeline, so the flow is even more completed! Happy learning!

Learning new things about Kubernetes every day. Hopefully, the learning notes could help people on the same journey!