Creating a Helm repository in two ways: using Google Cloud Artifact and Github Pages
Helm is the tool to install and manage K8S applications.
A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
A Repository is a place where charts can be collected and shared. It’s like the Docker Hub for Docker images or the PyPI Library for Python packages, but for Kubernetes packages.
Deploy from an unpackaged chart
The simple pipeline to deploy an unpackaged chart is shown above. The code is committed to a remote repository, that triggers a CI/CD pipeline to build the Docker image and push it to an image registry. Then Helm directly build the chart from the Docker image that is stored in the registry, and installs it to the target K8S cluster as a release.
This works well in the testing environment, while in production, often one chart is installed many times into the same cluster, as different releases. So it is important to keep a track of the different versions of the chart for rollback and debugging. Also, we could shorten the deployment process, by reusing stored Helm charts rather than building the same chart every time.
Deploy from a packaged chart
This pipeline added a step to build and push the Helm chart to the Helm repo. Once the chart is pushed to the Helm repo, it can be reused in other releases in different environments, no need to be built again.
There are several ways to set up a Helm repo, here I listed two that I have been trying out:
Set up the Helm repo using Github Pages
Github Pages is a static site hosting service that takes HTML, CSS, and JavaScript files straight from a repository on GitHub, optionally runs the files through a build process, and publishes a website. The benefit of adopting it is that you keep your project site code in the same code repo as the project itself.
For the implementation steps, helm.sh has a clear walk-through page for it. I just wanna address the challenge I encountered when implementing a private Helm repo. We follow the steps and created a page like below:
For the private GitHub Pages, if we simply added the above link to the Helm repo, there will be an error of authentication failure. Instead, we need to redirect the entry of the above URL to the the new endpoint ofraw.githubusercontent.com in the index.yamlThe new endpoint supports the basic authentication required for the private feed.
# Generate the index.yaml that pointed to the new endpoint
helm repo index . --url https://raw.githubusercontent.com/{your_org_name}/{your_project_name}/gh-pages/
# Push the change to the remote pos
git add index.yaml
git commit -m "Updated from ref: $GITHUB_SHA"
git push origin gh-pagesAnd then boom! When we access to the GitHub pages URL https://scaling-adventure-820c3edc.pages.github.io/index.yaml the repo page is working!
apiVersion: v1
entries:
model-api:
- apiVersion: v2
appVersion: 1.16.0
created: "2023-01-19T13:11:23.369817737Z"
description: A Helm chart for Kubernetes
digest: 637ebc468865ccbfcf6a218d349ac647da9aa2b8ac02353610b72ecdefc2346a
name: model-api
type: application
urls:
- https://raw.githubusercontent.com/ingka-group-digital/pco-model-apps/gh-pages/model-api-0.1.0.tgz
version: 0.1.0For the full procedures about creating a private helm repository using github pages enterprise via CICD pipeline, I’d recommend this clear tutorial to walk through.
Set up the Helm repo using Google Artifact Registry
Google Artifact Registry is an evolution of Container Registry, that can serve as a single place for the organisation to manage not only the container images, but also non-container artifacts like language packages for Python, Java, and Node.
The setup procedures are also clearly stated on the Google Cloud page. Firstly, we need to authentication Helm with Google Cloud, the safest way as recommended is to use the short-lived access token that a service account uses to access your Google Cloud resource.
Once the authentication is done, we can let Helm interact with the artifact registry, such as pushing the chart to the repo, or showing the chart information.
# push the built chart to the remote artifact repo
helm push model-api-0.1.0.tgz oci://europe-west4-docker.pkg.dev/{your_google_cloud_project}/helm-repo
# list the images that are stored under the artifact repo
gcloud artifacts docker images list europe-west4-docker.pkg.dev/{your_google_cloud_project}/helm-repo
# we can show the chart that lies on the docker artifact repo
helm show chart oci://europe-west4-docker.pkg.dev/{your_google_cloud_project}/helm-repo/model-api
# Output is like below:
# apiVersion: v2
# appVersion: 1.16.0
# description: A Helm chart for Kubernetes
# name: model-api
# type: application
# version: 0.1.0Conclusion
Both ways provide a storage place for Helm charts that have version controlling and some access control. We do encounter some difficulties to set up during the real production environment. For GitHub Pages, the difficulty lies in creating the Private Helm repo. While for the Google Artifact Registry, authentication requires some tuned-up to get it to work.
