Continuous Integration and Continuous Delivery (CI/CD) with Helm charts and Argo CD
Efficient and automated deployment of web applications across multiple environments is essential for focussing on implementing customer-specific requirements.
In this blog post, we will show you one potential way of doing this.
Introduction
We have already been using various methods, such as PowerShell scripts or Azure DevOps Pipelines, to enable us to integrate and deploy the applications that we are developing. Most of them require manual intervention, and sometimes time-consuming adaptation as the application evolves, and are therefore more prone to errors. A fully automated solution is being deployed to avoid this, as well as to facilitate the constant integration and deployment of containerised applications.
Kubernetes, Helm and Argo CD
To develop scalable, reusable and adaptable applications, we use a microservice architecture, which results in various Docker images, as already mentioned in the blog post about Dapr runtime. The cloud-native computing approach enables us to deploy lightweight images on a wide range of systems.
Kubernetes is a system that allows us to manage container applications, which is also referred to as “orchestration”. Helm, which reduces the complexity of deploying Kubernetes, provides additional support. Using Yaml files, a kind of template is created for deploying the containers, which can be easily reused.
A Helm chart consists of three basic components:
The chart file
This is where the metadata of the application is defined, such as the name and the version.
The value file
The variables for controlling the templates are set in this file, for example to define which docker image is to be used or how many containers are to be created.
The template folder
This is where the templates for creating manifests based on the values from the value file are located, which are then used by Kubernetes to create the respective resources.
To be able to deploy the application via continuous integration and continuous delivery at the final stage, further components are required:
GitHub Actions to run unit tests, create the images and upload them to an Artifactory (artifact repository) in the event of a new release (tagged and triggered by commits in a certain branch) to make them available for deployment.
Argo CD, as a declarative GitOps continuous delivery tool for Kubernetes. It automates the deployment of the various components, for which it uses the available images from the Artifactory.
Thus, the GitHub repository from which the images are created constitutes the single point of truth, which also decides on the version that is deployed. In doing so, it is common to define rules for each environment as to when which versions are deployed. In the development environment, for example, the containers are redeployed as soon as a new version of the images is available, for example from version v1.3.1 to v1.3.2. In the production environment, automatic deployment does not make sense, as a new version may contain errors. In this case, only versions that have been tested and verified are provided.
Challenge
One challenge was to create the Helm charts in such a way that they were easy to reuse and adapt for different environments. For example, in the developer environment, the same password for a database must not be used as in the production environment.
Another challenge was to evaluate the Helm charts of existing software components. Locally, Docker images from the manufacturer could be used, but Helm charts were not provided in some cases. These then had to be sourced from third-party providers.
Advantages and disadvantages
+ A clear benefit is the time saved for manual deployment and integration, which grows each time it is used.
+ The rollback option offers the solution of switching back to an earlier version that worked before in the event of an error in the field.
+ This type of setup provides consistency when integrating and deploying a wide variety of applications.
+ Automation prevents errors that could occur during repetitive tasks if carried out by the developer.
- The infrastructure as a whole has a certain degree of complexity, which takes people time to familiarise themselves with.
- It is not worth the effort of operating such an infrastructure for just one application. The major benefits only become apparent when several applications are operated.
Conclusion
In order to focus more on implementing customer-specific requirements, it is helpful to be able to integrate and deploy applications in as automated a manner as possible.
The one-off effort involved in setting up the workflows and systems pays off when this infrastructure is reused for other applications and the entire system is standardised.
Not only does GitHub Actions facilitate automated image building, but it also helps the developer to carry out checks and tests prior to a review.
Kubernetes, Helm and Argo CD may appear a bit complex at first glance. This obstacle can be overcome by helping each other to use these tools.
Based on our accumulated experience, we are now able to implement more projects that can benefit from automated integration and deployment. This eliminates the need for the aforementioned induction period and work can be started immediately.
We look forward to hearing from you.