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

  • Understand the basic process flow of Azure DevOps

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.

  • 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.

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.

- 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jonathan

Jonathan

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