Overview:

It can be challenging to create a reliable continuous integration/continuous delivery (CI/CD) process for a microservices architecture. Individual teams must be able to release services quickly and reliably, without disrupting other teams or destabilizing the application as a whole.

This article describes an example CI/CD pipeline for deploying microservices to Azure Kubernetes Service (AKS). Every team and project is different, so don’t take this article as a set of hard-and-fast rules. Instead, it’s meant to be a starting point for designing your own CI/CD process.

The goals of a CI/CD pipeline for Kubernetes hosted microservices can be summarized as follows:

  • Teams can build and deploy their services independently.
  • Code changes that pass the CI process are automatically deployed to a production-like environment.
  • Quality gates are enforced at each stage of the pipeline.
  • A new version of a service can be deployed side by side with the previous version.

Assumptions

For purposes of this example, here are some assumptions about the development team and the code base:

  • The code repository is a monorepo, with folders organized by microservice.
  • The team’s branching strategy is based on trunk-based development.
  • The team uses release branches to manage releases. Separate releases are created for each microservice.
  • The CI/CD process uses Azure Pipelines to build, test, and deploy the microservices to AKS.
  • The container images for each microservice are stored in Azure Container Registry.
  • The team uses Helm charts to package each microservice.
  • A push deployment model is used, where Azure Pipelines and associated agents perform deployments by connecting directly to the AKS cluster.

These assumptions drive many of the specific details of the CI/CD pipeline. However, the basic approach described here be adapted for other processes, tools, and services, such as Jenkins or Docker Hub.

Alternatives

The following are common alternatives customers might use when choosing a CI/CD strategy with Azure Kubernetes Service:

  • As an alternative to using Helm as a package management and deployment tool, Kustomize is a Kubernetes native configuration management tool that introduces a template-free way to customize and parameterize application configuration.
  • As an alternative to using Azure DevOps for Git repositories and pipelines, GitHub Repositories can be used for private and public Git repositories, and GitHub Actions can be used for CI/CD pipelines.
  • As an alternative to using a push deployment model, managing Kubernetes configuration at large scale can be done using GitOps (pull deployment model), where an in-cluster Kubernetes operator synchronizes cluster state, based on the configuration that’s stored in a Git repository.

Azure DevOps Pipeline

The following diagram shows the end-to-end CI/CD process described in this article:

CI/CD for AKS apps with Azure Pipelines

Potential use cases

Use Azure Pipelines to deploy AKS applications.

Architecture

Dataflow

  1. A pull request (PR) to Azure Repos Git triggers a PR pipeline. This pipeline runs fast quality checks such as linting, building, and unit testing the code. If any of the checks fail, the PR doesn’t merge. The result of a successful run of this pipeline is a successful merge of the PR.
  2. A merge to Azure Repos Git triggers a CI pipeline. This pipeline runs the same tasks as the PR pipeline with some important additions. The CI pipeline runs integration tests. These tests require secrets, so this pipeline gets those secrets from Azure Key Vault.
  3. The result of a successful run of this pipeline is the creation and publishing of a container image in a non-production Azure Container Registry.
  4. The completion of the CI pipeline triggers the CD pipeline.
  5. The CD pipeline deploys a YAML template to the staging AKS environment. The template specifies the container image from the non-production environment. The pipeline then performs acceptance tests against the staging environment to validate the deployment. A manual validation task is run if the tests succeed, requiring a person to validate the deployment and resume the pipeline. The manual validation step is optional. Some organizations will automatically deploy.
  6. If the manual intervention is resumed, the CD pipeline promotes the image from the non-production Azure Container Registry to the production registry.
  7. The CD pipeline deploys a YAML template to the production AKS environment. The template specifies the container image from the production environment.
  8. Container Insights periodically forwards performance metrics, inventory data, and health state information from container hosts and containers to Azure Monitor.
  9. Azure Monitor collects observability data such as logs and metrics so that an operator can analyze health, performance, and usage data. Application Insights collects all application-specific monitoring data, such as traces. Azure Log Analytics is used to store all that data.

Components

  • Container Insights collects logs and metrics and logs and forwards them to Azure Monitor.
  • Azure Container Registry is a managed, private container registry service on Azure. Use Container Registry to store private container images.
  • Azure Kubernetes Service is a managed Kubernetes service where Azure handles critical tasks, like health monitoring and maintenance.
  • Defender for DevOps performs static analysis and helps you gain visibility of security postures across multiple pipelines in AKS development and deployment.

Summary of Deployment Methods to Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is a popular managed Kubernetes service offered by Microsoft Azure. It provides a scalable and manageable platform for deploying containerized applications. When it comes to deployment to AKS, there are several methods available that offer different levels of automation and integration. This document provides an overview of these methods:

1. Azure Pipelines: Azure Pipelines is a continuous integration and delivery (CI/CD) service that seamlessly integrates with AKS. With Azure Pipelines, you can build, test, and deploy your applications directly to AKS. It offers a user-friendly interface, allowing you to configure your build and release pipelines with ease.

2. GitHub Actions: GitHub Actions is an open-source automation platform that integrates with AKS. It allows you to automate your build, test, and deployment workflows directly within your GitHub repository. You can create workflows that build and push images to container registries like Azure Container Registry and then deploy them to AKS. GitHub Actions provides flexibility and customization options, allowing you to tailor the deployment process to your needs.

3. Automated Deployments (Preview): Automated Deployments is a feature in preview that allows for setting up automated deployments to AKS using GitOps principles. GitOps is a term used to describe the practice of using Git as the source of truth for declarative infrastructure, enabling automated deployments to Kubernetes clusters. With Automated Deployments, you can define your deployment configurations as code in GitHub, and then have them automatically deployed to AKS. This eliminates the need for manual intervention and provides a more efficient and streamlined deployment process.

4.Jenkins: An open-source automation server that can be used to automate all sorts of tasks related to building, testing, and deploying code. The tutorial guides you through deploying from GitHub to AKS using Jenkins, which involves setting up a Jenkins server and creating a pipeline that pulls from GitHub and deploys to AKS.

Conclusion

In conclusion, these methods provide robust options for automating the deployment process to AKS, each with its own set of tools and processes. Whether you prefer a fully integrated Azure solution or an open-source approach, there’s a deployment strategy that fits your workflow. AKS offers a variety of deployment methods, allowing you to choose the one that best suits your requirements and preferences.

References:

https://learn.microsoft.com/en-us/azure/architecture/microservices/ci-cd

https://learn.microsoft.com/en-us/azure/architecture/microservices/ci-cd-kubernetes

https://learn.microsoft.com/en-us/azure/aks/devops-pipeline?tabs=cli&pivots=pipelines-yaml

https://learn.microsoft.com/en-us/azure/aks/kubernetes-action

https://learn.microsoft.com/en-us/azure/aks/automated-deployments

https://learn.microsoft.com/en-us/azure/developer/jenkins/deploy-from-github-to-aks?toc=%2Fazure%2Faks%2Ftoc.json&bc=%2Fazure%2Faks%2Fbreadcrumb%2Ftoc.json

One thought on “CI/CD for microservices architectures”

Leave a Reply to Decoding Software Architecture: Patterns, Strategies, and Real-World Microservices Journey – Rajeev Singh | Coder, Blogger, YouTuberCancel reply

Discover more from Rajeev Singh | Coder, Blogger, YouTuber

Subscribe now to keep reading and get access to the full archive.

Continue reading