You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
Helm: Difference between revisions
imported>Hnowlan (Add link to deployments guide) |
imported>BryanDavis (remove redirect) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Kubernetes nav}} | |||
Helm<ref>https://github.com/helm/helm</ref> is the package manager for [[Kubernetes]]. | Helm<ref>https://github.com/helm/helm</ref> is the package manager for [[Kubernetes]]. | ||
It is used to build [[Helm chart|Helm charts]], which are packages of Kubernetes resources that are used to deploy apps to a cluster. | It is used to build [[Helm chart|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|chartmuseum]]. | ||
For deployment it is called via helmfile<ref>https://github.com/roboll/helmfile</ref> in combination with helm-diff<ref>https://github.com/databus23/helm-diff</ref> to present the to be applied changes to the user. For instructions on how to deploy services and configuration changes with helmfile, see [[Deployments | For deployment it is called via helmfile<ref>https://github.com/roboll/helmfile</ref> in combination with helm-diff<ref>https://github.com/databus23/helm-diff</ref> 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]]. | ||
==Packaging== | ==Packaging== | ||
| Line 9: | Line 10: | ||
The packages {{Gitweb|project=operations/debs/helmfile}} and {{Gitweb|project=operations/debs/helm-diff}} follow the same packaging workflow, so we document that here together. | The packages {{Gitweb|project=operations/debs/helmfile}} and {{Gitweb|project=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 {{Gitweb|project=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 https://debmonitor.wikimedia.org/ for more info about where to the package is installed). | |||
=== Importing a new version === | === Importing a new version === | ||
| Line 49: | Line 61: | ||
sudo -i reprepro -C main include buster-wikimedia /path/to/<PACKAGE>.changes | 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) | # 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 stretch-wikimedia buster-wikimedia <PACKAGE> | ||
sudo -i reprepro copy jessie-wikimedia buster-wikimedia <PACKAGE> | sudo -i reprepro copy jessie-wikimedia buster-wikimedia <PACKAGE> | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==== Update CI image ==== | |||
We're using helm/helmfile in {{Gitweb|project=operations/deployment-charts}} to lint and verify charts. | |||
To update the envoy version used there, bump the changelog at {{Gitweb|project=integration/config|file=dockerfiles/helm-linter/changelog}}: | |||
<syntaxhighlight lang="bash"> | |||
dch -D wikimedia --force-distribution -c changelog | |||
</syntaxhighlight> | |||
And add the new version to <code>jjb/operations-misc.yaml</code> in a second patch ([https://gerrit.wikimedia.org/r/c/integration/config/+/631767 example]) | |||
When this is merged and build, run CI (maybe just rebuild last at https://integration.wikimedia.org/ci/job/helm-lint/ ?) to verify the new version against our charts/deployments. | |||
==Resources== | ==Resources== | ||
Revision as of 15:30, 2 October 2021
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.
Packaging
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 https://debmonitor.wikimedia.org/ 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 https://integration.wikimedia.org/ci/job/helm-lint/ ?) to verify the new version against our charts/deployments.