11 software delivery problems solved by intelligence software delivery platform  Download
Select Page
Share

What is Helm and Helm Charts?

Helm is the first application package manager running atop Kubernetes. It streamlines installing and managing Kubernetes applications. Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.. These charts allow convenient management of Kubernetes with simple commands.

Baking Helm Charts in Spinnaker

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 the K8s cluster.
 
Use-case of baking helm charts in Spinnaker : helm charts are hosted in a private helm repository and values are overridden by a vaules.yaml file from a GitHub repository.

Pre-requirements for baking

  • 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 a helm render engine. Spinnaker makes use of the helm template commands to render the templates (with values input) into workable K8s manifest files. The manifest files can be used for the deployment of K8s applications.

Procedure Outline

  1. Add Artifact accounts – Helm and GitHub
  2. Configure Input Artifacts for the Bake stage
  3. Setup Baking stage to produce rendered manifest files (base64 type)
  4. Setup Deployment stage using Baked manifest files
  5. Verify if the application is deployed successfully

We explain 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 the only difference being to use the baked manifest files produced in step 3.

1. 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 .tgz files or .tar.gz files of whose meta information is recorded in an 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://52.252.54.0 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
				
			

After 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.

2. Configure Input Artifacts fetch-able from Helm Repository

Configure Input Artifacts fetch-able from Helm Repository

 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 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://172.42.42.113/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 set up another Expected Artifact as seen below; otherwise, it is not required.

Configure Input Artifacts fetch-able from Helm Repository in Spinnaker.

 Configure Input Artifacts fetch-able from Helm Repository in Spinnaker.(contd.)

 
It is mandatory to configure the Default Artifact for the GitHub artifact type, as shown above.

3. 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.

 
Setup Baking Stage to produce rendered manifest files

 Setup Baking Stage to produce rendered manifest files

You would also need to configure the output of the Bake step. Once the manifest files are rendered, they are configured to produce Base64 type artifact as shown below.

Setup Baking Stage in Spinnaker to produce rendered Helm Chart 3 manifest filess

 Setup Baking Stage in Spinnaker to produce rendered Helm Chart 3 manifest files

Troubleshooting Helm Charts

Problem:

I have added the Helm repository, but it is not displayed in the Spinnaker pipeline configuration.

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 enable and hal deploy apply again.

Problem:

My helm account is visible, but I am unable to see any chart as it is busy loading the Charts. See the sample screenshot below.

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)
				
			

Problem:

Artifact is not fetched or throws 404 File not found error for GitHub artifact.

Solution:

It may be because the token is being configured incorrectly. Verify the below
  1. Make sure the GitHub token is correct
  2. 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)
  3. 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 the halyard.

So in this article, we have shown you how to the steps to implement the Helm 3 template baking (i.e. rendering), so that the final manifest files will be available for performing deployment into the Kubernetes (K8s) cluster. If you wish to streamline your Continuous Delivery, please read the following articles:

[/vc_column_text][vc_cta h2=”Get Help with Helm charts” h4=”Hassle free , 24/7 Support” style=”3d” el_width=”lg” add_button=”right” btn_title=”Contact Us” btn_style=”gradient” btn_size=”lg” btn_align=”right” add_icon=”left” i_icon_fontawesome=”fa fa-life-ring” i_color=”sandy_brown” i_size=”xl” btn_link=”url:https%3A%2F%2Fwww.opsmx.com%2Fcontact.html|||”][/vc_cta][vc_column_text]

OpsMx is a leading provider of Continuous Delivery solutions that help enterprises safely deliver software at scale and without any human intervention. We help engineering teams take the risk and manual effort out of releasing innovations at the speed of modern business. For additional information, contact us

[/vc_column_text][/vc_column][/vc_row]

0 Comments

Submit a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.