This is Part 2 of Reducing Helm Chart Boilerplate with Named Templates and Library Charts.

In Part 1 of this blog series, I talked about how you can use named templates to reduce boilerplate throughout a single Helm chart. Now, we’re going to expand on that idea by discussing how you can use library charts to reduce boilerplate across multiple Helm charts. To do this, we will focus on the concept of library charts.

Understanding Library Charts

A library chart is a Helm chart consisting entirely of named templates. As you can recall from Part 1, a named template is a reusable template that contains boilerplate common to your chart resources. The named templates we described in Part 1 were defined in a file called _helpers.tpl and were only visible to the Helm chart that it belonged to.

Library charts expand on this idea by containing named templates that capture boilerplate common across all of your Helm charts. Your Helm charts can use these named templates by declaring the library chart as a dependency.

Note that library charts do not deploy anything to your Kubernetes cluster. Instead, they are imported by application charts to simplify chart development and maintenance.

Now that we have introduced library charts, let’s look at how you can create one.

Creating Library Charts

Creating a library chart is similar to creating a regular application chart. Here’s the basic structure of a library chart:

library-chart/
  Chart.yaml
  templates/

Pretty simple! Notice that library charts do not contain values.yaml files, since it’s the responsibility of the application chart to provide that instead.

One gotcha is to be sure the typesetting in Chart.yaml is library to differentiate this from a normal application chart:

apiVersion: v2
name: library-chart
version: 1.0.0
type: library

Your named templates will go under the templates/ folder. You could structure this by using a single _helpers.tpl file like this:

templates/
  _helpers.tpl

#kubernetes #devops #containers #helm