Helm 3 has undergone some major changes versus its predecesor Helm 2. Spinnaker has introduced the use of Helm 3 in Spinnaker 1.19.0 along with Helm 2.
In this guide, we will be listing out the steps to implement the Helm 3 template baking (i.e. rendering), so the final manifest files will be available for performing deployment into K8s cluster.
Use-case is helm charts are hosted in a private helm repository and values are overridden by a vaules.yaml file from a GitHub repository.
- Spinnaker 1.19.0 or higher version
- A working Helm repository with Helm 3 charts
- Override values.yaml file on a GitHub repository
How does it work?
The Spinnaker software is installed with helm render engine. Spinnaker makes use of
helm template command to render the templates (with values input) into workable K8s manifest files. The manifest files can be used for deployment of K8s applications.
- Add Artifact accounts – Helm and GitHub
- Configure Input Artifacts for the Bake stage
- Setup Baking stage to produce rendered manifest files (base64 type)
- Setup Deployment stage using Baked manifest files
- Verify if application is deployed successfully
We explain the steps 1 to 3 in this guide, while 4 and 5 left to the users to perform as it can be done just like any other K8s deployment, with only difference being to use the baked manifest files produced in the step 3.
Add Artifact accounts – Helm and GitHub
With the help of
halyard let us enable helm type of artifacts, and add a helm account. The helm account in halyard points to a Helm repository and is accessible by the Halyard, Rosco and Clouddriver services.
Helm repository is simply a web directory containing the <helm-charts> .tgz files or .tar.gz files of whose meta information is recorded in a index.yaml file present in the root of the helm repository.
#Run these commands inside Halyard hal config features edit --artifacts true hal config artifact helm account add stable-helm-ac --repository https://kubernetes-charts.storage.googleapis.com #Note: No trailing slash in the URL #Add any private Helm repository hal config artifact helm account add saga-helm-ac --repository http://18.104.22.168 hal config artifact helm enable hal deploy apply
Optionally, if you like to override the values.yaml file from a GitHub repository, you can configure halyard with your GitHub account as below.
#Access tokens require repo scope for private repos and public_repo scope for public repos hal config artifact github account add saga-github-ac --token xxxxxxxxxxxxxxxyyyyyyyyyyyyyyyyyyyyyzzzzzzzzzz
Aftert these steps, the newly added account(s) should be visible to configure Expected Artifacts in Spinnaker UI. Give it some time to refesh the accounts in the UI.
Configure Input Artifacts fetch-able from Helm Repository
In Spinnaker UI, select the application and choose your pipeline and go to its Configuration stage. Now you should see the account you have added in the previous step. Select the account, chart name and its version.
In the screenshot, the Account name is added by hal command. The snippet of the meta information of the chart from index.yaml file from the Helm-chart repo is given below. The name of the chart and the version info in the UI are populated from the index.yaml meta-data file of the helm repo; You can pick your choice of chart and its version.
apiVersion: v1 entries: hellochart: - apiVersion: v2 appVersion: v1.0.0-helm3demo-1 created: "2020-03-22T03:51:19.498042129Z" description: A Helm chart for Kubernetes digest: 90467716ee0c0338dd2cab1481f293535b878bf31704624922cdc040820cc939 name: hellochart type: application urls: - http://22.214.171.124/charts/hellochart-0.1.0.tgz version: 0.1.0 generated: "2020-03-22T03:51:19.497596204Z"
In case of values.yaml file overriding, you can setup another Expected Artifact as seen below; otherwise it is not required.
It is mandatory to configure the Default Artifact for the GitHub artifact type, as shown above.
Setup Baking Stage to produce rendered manifest files
Once you have configured all of your possible input artifacts (which would be used in Bake/Deploy stages usually), you are good to configure Baking stage. After adding a Baking stage type, you can configure the inputs as seen in the screenshot below. If overriding of values.yaml is not required, you can skip that step.
You would also need to configure the output of Bake step. Once the manifest files are rendered, they are configured to produce Base64 type aftifact as shown below.
Solution: It takes few minutes to load the new accounts; wait for few minutes before you try further. If it is still not loading, make sure you run
hal config artifact helm enableand
hal deploy applyagain.
Solution: It seems like a defect in Spinnaker recognizing the Helm URL. During Hal configuration, make sure to remove the trailing slash from the URL.
hal config artifact helm account add stable-helm-ac --repository https://kubernetes-charts.storage.googleapis.com – Correct one.
hal config artifact helm account add stable-helm-ac --repository https://kubernetes-charts.storage.googleapis.com/ – Error (Busy loading the charts)
3. Problem: Artifact is not fetched or throws 404 File not found error for GitHub artifact.
Solution: It may be because of the token is being configured incorrectly. Verify the below
- Make sure the GitHub token is correct
- Make sure the token is given repo scope (GitHub Profile > Settings > Developer Settings > Personal access tokens > Select the token and the list of scopes are listed. Make sure to select ‘repo’ scope)
- Run the command
curl https://api.github.com/repos/sagayd/helm3demo/contents/chartbase/hellochart/values_lb.yaml \ -u nobody:xxxxxTOKENyyyyyyy. If you are able to see the meta-data, it means that the token is correct. Just re-verify and apply the changes on halyard.