05.11.2021 | Michal Slovík | comment icon 0 Comment

Infrastructure as code (IaC): Deploy using Helm, Kubernetes and Azure DevOps

In this article, I would like to talk about the use of infrastructure within the code base. I will guide you through the pros and cons of infrastructure as code principles.

In general, infrastructure can be used in any application or project. The main goal of this article is to show you how it can be done and when it should be used. I used one of the project application and I skip things unrelated to this article (such as security, certificate, user management).

If you are considering using infrastructure in your project or application, remember first that it can be difficult to set up at first (it can be weeks for beginners), but it is easy (easier than trying to manage a virtual machine or the server itself) to maintain it.

Technology overview

Among the core principles of infrastructure is controlled, tested and automatic deployment. There are several tools to manage this process. I will focus on Kubernetes and Helm.

  • Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications, mostly docker container. With small applications it can be usefull to make changes in Kubernetes manually, but in large application it can be necessary to have these changes managed by an automatic workflow.
    In that case, Helm can help.
  • Helm can help you define, install, and upgrade the complex Kubernetes application. Helm enables Kubernetes users greater control over their cluster, just like the captain of a ship at the helm. But what if that’s still not enough, you have a complex application running on Kubernetes, but you would like to offer other developers to change the infrastructure of this application according to their needs, so version control (e.g. Git) can help you.
  • Azure DevOps Server provide version control (Git), project management, automated builds, testing and release management (pipelines in shortly) and other things necessary for project management. So when I put these things together, I can manage my infrastructure as code.
  • Infrastructure as code (or IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. Simplicity through code.

Architecture overview for one application

Architecture overview

Jump into Helm charts

I will now focus on Helm charts and templates for them. Helm uses a packaging format called charts.


NOTE
I suppose that you are familiar with the terms Docker, container, image, cluster, and all stuff related to Docker and Kubernetes. If not, for Docker please follow get-started and for Kubernetes visit kubernetes-basics


A chart is a collection of YAML files that describe a related set of Kubernetes resources. Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed. A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart, for example:

Helm templates generate manifest files, which are YAML resource descriptions that Kubernetes can understand.

In my case I use multiple images in one Helm directory so the structure is a little different.


NOTE
I am using Azure Cloud Shell with these version of tools:

Helm version

Kubernetes version

Docker version


I have everything running on top of Microsoft Azure Portal. My code is stored in Azure DevOps repositories, where I also have running pipeline for all build and deployment. Also, other resources as Kubernetes service is running in Azure Portal under project subscription, and project resource group. Helm also offers to connect to these resources from Azure pipelines.

Inside of running k8s (Kubernetes) cluster I have multiple namespaces, for each application one namespace so if something is going wrong it should not affect other applications. Firstly I can look deeply on one of the applications and their templates.

In my project every application consists of one Docker image (container) which is stored and build in another repository.

The application also contains Chart.yaml in format:

values.yaml file:

Most important part is templates folder with multiple files:

  • helm\first-app\templates\akvs.yaml
  • helm\first-app\templates\config.yaml
  • helm\first-app\templates\deployment.yaml
  • helm\first-app\templates\ingress.yaml
  • helm\first-app\templates\service.yaml
  • helm\first-app\templates\pvc-packages.yaml

Store and connect secrets from azure vault akvs.yaml

An external configuration loaded from a file that is better manageable than editing inside a Kubernetes cluster. You can edit this file (first-app-config.gcfg) in the Git repository and it will load with the latest information when changed.

Service and PVC files are not so important for our focus, but basically the service passes the default application port to web port 80. Ingress takes the rest and secures it. And PVC (PersistentVolumeClaim) is piece of storage in the cluster.

Ingress controller, basically, pass a web port for the http port and use it for this certificate, and tls make https for you.

The most important file is deployment.yaml. I will cut it into small pieces to make it more consistent and smooth. The first part is similar to another yaml configuration, the namespace should be the same as for the rest of the application. And one replica is enough for now, in the future you can increase it manually or scale them automatically. For automatic scaling in Kubernetes cluster visit horizontal-pod-autoscale or autoscaling-in-kubernetes.

Next part of deployment.yaml file is this checksum which handle each change in config file. If any changes is catch in config.yaml it will restart deployment for us. So it updates my application automatically.

This part consists of few important things. First environment variables, like License can be handles by Values file. Docker image itself, it is useful to use tags and port for specific application the same as I specify in service.

Persistent Volume is mapped in this part of deployment.yaml file, where I say to where should image find folder, files or configuration in persistent volumes.

At the last part of deployment file is responsible for using resource outside running containers.

Azure DevOps pipelines for Helm template

When I have prepared all the Helm charts and templates, I will focus on the pipeline. This channel should basically create or re-create the application I want to use with all the settings and file system.

The trigger for this pipeline should be any change in the folder where all the files, templates, and Helm charts associated with the first application are. Azure DevOps already has a task for helm deploy, which can make this job for me.

Similar steps apply to all applications. Each container (application) is in a separate namespace, so it can be easily managed and maintained without disturbing others. Each application has its own docker image (container) and also its own pipeline.

Conclusion and future steps

In this article, I showed you an example of using a container application and deploying it to the infrastructure using IaC. I mainly focused on things that can be used in any infrastructure, but in general this should also be preceded by other background work, such as ingress-controller, load-balancer for the communication. Also, installing and setting up the Helm is a also important, so there are definitely many ways I can continue with this story.

I would like to continue in the next articles to show you these things, the ingress-controller, load-balancer, certification and hopefully I will also focus on Azure Resource Manager (ARM) templates.

Sources

Azure Devops docker Helm IaaS iac infrastructure as code kubernetes Pipelines

Leave a Comment