You are browsing a read-only backup copy of Wikitech. The live site can be found at


From Wikitech-static
Revision as of 15:30, 2 October 2021 by imported>BryanDavis (remove redirect)
Jump to navigation Jump to search

Helm[1] is the package manager for Kubernetes.

It is used to build Helm charts, which are packages of Kubernetes resources that are used to deploy apps to a cluster. Those charts are kept in a repository served by chartmuseum.

For deployment it is called via helmfile[2] in combination with helm-diff[3] to present the to be applied changes to the user. For instructions on how to deploy services and configuration changes with helmfile, see Kubernetes/Deployments.


We're providing separate packages for operations/debs/helm (helm 2.x) and operations/debs/helm3, both may be installed at the same time.

The packages operations/debs/helmfile and operations/debs/helm-diff follow the same packaging workflow, so we document that here together.

Testing a new version

If you are wondering "How do I test a new helm version before reaching production", one possible strategy could be to do the following:

1) Start working locally, importing the new version and building the new Debian package.

2) Install it, and test helm with Minikube (for example, try helm lint, helm template, helm upgrade, etc.. on some charts in operations/deployment-charts).

3) If the results are good, proceed with importing/installing/publishing on deneb/apt1001 and upgrade CI to use the new helm version (see below how to do it).

4) If CI runs fine (that involves using helm lint on all charts for example), proceed with deploying helm3 more widely (check for more info about where to the package is installed).

Importing a new version

The packages are build using Git-buildpackage. The imported upstream tarballs should include the complete vendor directory.

  • Check out the version (git tag) to import
    ./debian/repack "vX.Y.Z"
  • This drops you into a shell with the git tag checked out. Do necessary changes here and commit
    glide install --strip-vendor
    # or
    go mod vendor
    git add -f vendor
    # git diff --name-status --cached | grep -v 'vendor/' # to make sure you only changed vendor
    git commit -m "added vendor"
  • Exiting the shell will build a tarball to import
    gbp import-orig /path/to/tarball.tar.xz
  • Push changes (including the tag crated by gpb) to gerrit
    git push gerrit --all
    git push gerrit --tags
  • Add a debian/changelog entry (as CR)
    gbp dch # Edit debian/changelog
    git commit
    git review

Building a new version

  • Check out the git repo on the build host
  • Build the package
    BACKPORTS=yes gbp buildpackage --git-pbuilder --git-no-pbuilder-autoconf --git-dist=buster -sa -uc -us

Publish a new version

# on apt1001
rsync -vaz deneb.codfw.wmnet::pbuilder-result/buster-amd64/*<PACKAGE VERSION>* .
sudo -i reprepro -C main include buster-wikimedia /path/to/<PACKAGE>.changes

# Check where the package is in reprepro
sudo -i reprepro lsbycomponent helm3
# Copy the package over to other distros (this is possible because they only contain static binaries)
sudo -i reprepro copy stretch-wikimedia buster-wikimedia <PACKAGE>
sudo -i reprepro copy jessie-wikimedia buster-wikimedia <PACKAGE>

Update CI image

We're using helm/helmfile in operations/deployment-charts to lint and verify charts.

To update the envoy version used there, bump the changelog at dockerfiles/helm-linter/changelog:

dch -D wikimedia --force-distribution -c changelog

And add the new version to jjb/operations-misc.yaml in a second patch (example)

When this is merged and build, run CI (maybe just rebuild last at ?) to verify the new version against our charts/deployments.