Intro to chartmuseum and helm dependencies

chartmuseum and helm dependecies are efficient tools to deploy applications for different customers. This reduce duplicated lines of code in helm charts, and provide versioned helm charts the software provided to the customer for rollingback easily, and fit gitops very well. When searhing for a tutorial I didn’t find one, so I write this myself.

Chartmuseum

chartmuseum is a rest service that you can get/modify/delete helm charts, and support storing them in cloud. https://github.com/helm/chartmuseum

Helm dependencies

Helm dependencies allow to link one helm chart with the other and generate a chart that represents a group of charts.

https://helm.sh/docs/helm/helm_dependency/#helm

So you can define one application requires which services to be able to work.

For example,

wordpress needs mariadb

https://github.com/helm/charts/blob/master/stable/wordpress/requirements.yaml

You can configure mariadb in values.yaml

https://github.com/helm/charts/blob/master/stable/wordpress/values.yaml#L343

You can find the chart repository points to https://kubernetes-charts.storage.googleapis.com/

For your customized chart, you can push it to chartmuseum running locally.

Scenario

I have to provide software for Nike and Adidas. Nike buys my shipping and ordering services, whereas Adidas buys shipping service only.

Nike

A helm chart depends on shipping and ordering, looks like the following:

Chart.yaml

ApiVersion: v2
name: nike
description: A Helm chart for Kubernetes
version: 1.5.0
dependencies:
  - name: shipping
    version: 21.0.0
    repository: http://localhost:8080
   
  - name: ordering
    version: 12.0.0
    repository: http://localhost:8080

Adidas

Chart.yaml

ApiVersion: v2
name: adidas
description: A Helm chart for Kubernetes
version: 1.1.0
dependencies:
  - name: shipping
    version: 22.1.1
    repository: http://localhost:8080

This brings lots of flexibilities of versioning. Chart museum stores all versions of charts. If a new version doesn’t work, it’s very simple to rollback by deploying the old version of chart.

For example, the shipping service is updated to a newer version, and the chart version is also updated to 1.6.0, if this version doesn’t work, it’s very straightforward to rollback to the previous version 1.5.0.

ApiVersion: v2
name: nike
description: A Helm chart for Kubernetes
version: 1.6.0
dependencies:
  - name: shipping
    version: 22.1.1
    repository: http://localhost:8080
   
  - name: ordering
    version: 12.0.0
    repository: http://localhost:8080

Step by step demo

Start a chartmuseum locally using docker-compose

docker-compose.yaml

version: '3'
services:
  chartmuseum:
    image: chartmuseum/chartmuseum:latest
    volumes:
    - ~/.helm/repository/local:/data/charts
    ports:
    - "8080:8080"
    environment:
    - STORAGE=local
    - STORAGE_LOCAL_ROOTDIR=/data/charts
    - PORT=8080

Create shipping and ordering service

helm create shipping // create a chart called shipping
helm create ordering
helm repo add chartmuseum http://localhost:8080
helm push shipping chartmuseum // push the chart to chart museum
helm push ordering chartmuseum

Now prepare the chart for our customer, nike.

helm create nike

remove all stuff in templates and keep Chart.yaml and values.yaml

add dependencies to Chart.yaml

dependencies:
  - name: shipping
    version: 0.1.0
    repository: http://localhost:8080
    
  - name: ordering
    version: 0.1.0
    repository: http://localhost:8080

Then, run

helm dep up // generats a lock file for helm dep
helm push nike chartmuseum

You should see charts in http://localhost:8080/api/charts

Gitops

In gitops, when a PR of shipping service merged into master, the version is updated, let’s say from 1.5 to 1.6, CI pushes the updated version 1.6 to chartmuseum. Someone has to manually update the version of shiping service in nike chart to 1.6 by a PR. When this PR in nike chart is merged, nike chart is then deployed to k8s.