Chapter 7: Automating Helm Processes Using CI/CD and GitOps

In this book, we have so far discussed two high-level processes. First, we explored using Helm as an end user, leveraging Helm as a package manager to deploy applications of varying complexities to Kubernetes. Second, we explored developing and testing Helm charts as a chart developer, which involved encapsulating Kubernetes complexities in Helm charts and performing tests on charts to ensure that the required features were delivered to end users successfully.

Both of these processes involve invoking various different Helm CLI commands. These Helm CLI commands, while effective in carrying out their respective tasks, require manual invocation from the command line. Manual invocation can serve as a pain point when managing multiple different charts or applications and can make it difficult for larger enterprises to scale. As a result, we should explore alternative options that provide additional automation on top of what...

Technical requirements

This chapter requires you to have the following technologies installed on your local machine:

• Minikube
• Helm
• kubectl
• Git

In addition to these tools, you should find the Packt repository containing resources associated with the examples used in this chapter on GitHub at https://github.com/PacktPublishing/-Learn-Helm. This repository will be referenced throughout this chapter.

Understanding CI/CD and GitOps

So far, we have addressed many of the key concepts that are inherent to Helm development—building, testing, and deploying. However, our exploration has been limited to manual configurations and invocations of the Helm CLI. While this is okay when getting started with Helm, as you look to move a chart into a production-like environment, there are several questions that you need to consider, including the following:

• How can I be sure that the best practices for chart development and deployment are enforced?
• What are the implications of collaborators participating in the development and deployment processes?

These points are applicable to any software project, not just to Helm chart development. While we have covered a lot of best practices so far, when taking on new collaborators, they may not have the same understanding of these topics or the discipline to perform these crucial steps. Through the use of automation and repeatable...

Setting up our environment

In this chapter, we will develop two different pipelines to demonstrate how different processes around Helm can be automated.

Take the following steps to begin setting up your local environment:

1. First, given the increased memory requirements of this chapter, you should delete your minikube cluster and recreate it with 4g of memory if it was not inititalized with 4g of memory in Chapter 2, Preparing a Kubernetes and Helm Environment. This can be done by running the following commands:

   $ minikube delete
   $ minikube start --memory=4g

2. Once Minikube starts, create a new namespace called chapter7:

   $ kubectl create namespace chapter7

You should, additionally, fork the Packt repository, which will allow you to make modifications against the repository based on the steps described in these exercises:

1. Create a fork of the Packt repository by clicking the Fork button on the Git repo:

   Figure 7.1 – Select the Fork button to fork the...

Creating a CI pipeline to build Helm charts

The concept of CI can be applied to the perspective of a chart developer who builds, tests, packages, and releases Helm charts to a chart repository. In this section, we will describe what using an end-to-end CI pipeline to streamline this process may look like, as well as walk you through how to build an example pipeline. The first step is to design the components required for the example pipeline.

Designing the pipeline

In the previous chapters, developing Helm charts was largely a manual process. While Helm provides automation for creating test hooks in a Kubernetes cluster, the invocation of the helm lint, helm test, or ct lint-and-install commands is manually executed after a change in code to ensure tests still pass. Once linting and testing continue to pass after a code change, the chart can be packaged by running the helm package command. If the chart is served using a GitHub Pages repository (such as the one created in Chapter...

Creating a CD pipeline to deploy applications with Helm

A CD pipeline is a set of repeatable steps that can deploy to one or more different environments in an automated fashion. In this section, we will create a CD pipeline to deploy the nginx chart that we tested and pushed to our GitHub Pages repository in the previous section. GitOps will also be leveraged by referencing the values files saved to a git repository.

Let's design the high-level steps that need to be included in this pipeline.

Designing the pipeline

In previous chapters, deploying to a Kubernetes environment with Helm was a manual process. This CD pipeline, however, is designed to deploy to multiple different environments while abstracting the use of Helm.

The following steps describe the CD workflow that we will cover in this section:

1. Add the stable GitHub Pages repository containing the nginx chart release.
2. Deploy the nginx chart to the development environment.
3. Deploy the nginx chart...

Cleaning up

To clean up your Minikube cluster of this chapter's exercises, delete the chapter7, dev, qa, and prod namespaces:

$ kubectl delete ns chapter7
$ kubectl delete ns dev
$ kubectl delete ns qa
$ kubectl delete ns prod

You can also shut down your Minikube VM:

$ minikube stop

Summary

Invoking the Helm CLI in CI and CD pipelines is an efficient way of further abstracting the capabilities that Helm provides. Chart developers can automate the end-to-end chart development process by writing a CI pipeline that lints, tests, packages, and releases charts to a chart repository. End users can write a CD pipeline that uses Helm to deploy a chart across multiple different environments, leveraging GitOps to ensure applications can be deployed and configured as code. Writing pipelines helps developers and companies scale applications faster and more easily by abstracting and automating processes that could otherwise become tedious and introduce human error.

In the next chapter, we will introduce another option for abstracting the Helm CLI—writing a Helm operator.

Further reading

To learn more about the chart testing container image, go to https://helm.sh/blog/chart-testing-intro/.

To learn more about Jenkins and Jenkins pipelines, check out the Jenkins project documentation (https://jenkins.io/doc/), the Jenkins pipeline documentation (https://jenkins.io/doc/book/pipeline/) and the Multibranch Pipeline plugin documentation (https://plugins.jenkins.io/workflow-multibranch/).

Questions

1. What is the difference between CI and CD?
2. What is the difference between CI/CD and GitOps?
3. What high-level steps are included in a CI/CD pipeline for creating and releasing Helm charts?
4. What advantages does CI bring to chart developers?
5. What high-level steps are included in a CD pipeline for deploying Helm charts?
6. What advantages does a CD pipeline bring to a chart's end users?
7. How can you maintain an application's configuration as code for multiple environments? What can you do to reduce boilerplate across the values files?