DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Create, Install, Upgrade, and Rollback a Helm Chart (Part 1)

Create, Install, Upgrade, and Rollback a Helm Chart (Part 1)

In the first part of this two-part tutorial, we take a look at creating a Helm chart, configuring it, and uploading it to the repository.

Gunter Rotsaert user avatar by
Gunter Rotsaert
CORE ·
Oct. 12, 18 · Tutorial
Like (6)
Save
Tweet
Share
27.28K Views

Join the DZone community and get the full member experience.

Join For Free

In this post we will explain how we can use Helm for installing our application. In part 1 we will take a look at how we can create a Helm Chart for our application and how to package it. In part 2 we will cover how to install the Helm package to a Kubernetes cluster, how to upgrade our Helm Chart and how to rollback our Helm Chart.

Create a Helm Chart

A prerequisite for what we are going to do in this post is an installed Helm Client and Server (Tiller). We explained in a previous post how to do this.

We can create the required files for a Helm Chart manually, but the easiest way is to create it with the following Helm command where myhelmchartplanet is the name of your Helm Chart:

helm create myhelmchartplanet

This will generate a default directory structure with default files in it:

  • charts: a directory to configure dependencies to other charts. We will not use this in our post.
  • templates: a directory to configure Kubernetes, it contains templates which combined with the values.yaml will generate valid Kubernetes manifest files
    • deployment.yaml: the configuration yaml file for the Kubernetes deployment
    • ingress.yaml: the configuration yaml file for the Kubernetes ingress
    • NOTES.txt: a text file containing notes which will be printed after installation
    • service.yaml: the configuration yaml file for the Kubernetes service
  • Chart.yaml: the chart yaml file containing e.g. version information
  • README.md: a readme file with extra information about your chart, how to use it, which values can be adapted, and so on
  • values.yaml: the values to be used in your chart. The values are used in the templates files

We will push this configuration to a GitHub repository (see tag v0.1.0). Next step is to adapt the default files to our needs. The application we will package and deploy is a simple Spring Boot application which prints a hello message when accessing the /hello URL. We used it before in a previous post and created a Docker image for it (we will use version 0.0.2-SNAPSHOT) which comes very handy at this moment.

Chart.yaml

So, first step is to adapt the Chart.yaml as follows:

apiVersion: v1 
appVersion: "0.0.2-SNAPSHOT" 
description: A Helm chart for Kubernetes 
name: myhelmchartplanet 
version: 0.1.0

Let's take a look at the different items:

  •  apiVersion : this is the Chart API version and should always have the value v1 (required)
  •  appVersion : this is more informative and contains the version of the application which is contained in the package. In our case 0.0.2-SNAPSHOT. (optional)
  •  description : a short description about the Chart (optional)
  •  name : the name of the Chart (required)
  •  version : the version of our Chart. As you can see, this is a different thing than the version of our application. They can be the same, but it is not required, as they are independent of each other. The version number has to be in the SemVer 2 format (required).

With this configuration, our Helm Chart will be named myhelmchartplanet-0.1.0.

values.yaml

With the values.yaml file, we can adapt several values which are used in the Kubernetes templates files. We will change the following default values:

  •  image.repository : the URL where our Docker image can be found
  •  image.tag : the tag of the Docker image we want to deploy
  •  service.type : we change it to NodePort  instead of ClusterIP  in order to expose it outside our cluster, just like we did before
  •  service.port : we set it to 8080, the port our application is using
  •  service.nodePort : since we use the type NodePort, we also have to set the port to use

The values.yaml file has the following content after our adaptations:


replicaCount: 1

image:
    repository: mydeveloperplanet/mykubernetesplanet
    tag: 0.0.2-SNAPSHOT
    pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
    type: NodePort
    port: 8080
    nodePort: 30036

ingress:
    enabled: false
    annotations: {}
    path: /
    hosts:
        - chart-example.local
    tls: []

resources: {}
nodeSelector: {}
tolerations: []
affinity: {}

service.yaml

Because we are using the service type NodePort , we have to change something to the service.yaml:

  •  targetPort : the default value is http, we change it in order that the port of our application is being used
  •  nodePort : we also have to define the property nodePort in order that our service sets it properly when being deployed to Kubernetes

Our adapted service.yaml is the following:


apiVersion: v1
kind: Service
metadata:
    name: {{ include "myHelmChartPlanet.fullname" . }}
    labels:
        app: {{ include "myHelmChartPlanet.name" . }}
        chart: {{ include "myHelmChartPlanet.chart" . }}
        release: {{ .Release.Name }}
        heritage: {{ .Release.Service }}
spec:
    type: {{ .Values.service.type }}
    ports:
        - port: {{ .Values.service.port }}
          targetPort: {{ .Values.service.port }}
          protocol: TCP
          name: http
          nodePort: {{ .Values.service.nodePort }}
    selector:
        app: {{ include "myHelmChartPlanet.name" . }}
        release: {{ .Release.Name }}

deployment.yaml

In the deployment file, we have to put the livenessProbe  and readinessProbe   in comments. These will check our application whether it is ready and alive, but we did not include the Spring Boot Actuator plugin in our application which will provide the URL to check the readiness and liveness of our application.

Check the Correctness of Your Chart

In order to check whether the changes you made to the different configuration files, you can issue the following command which will check the formatting and information:

helm lint myhelmchartplanet

I don't know exactly what is being checked, but it once gave no issues when the deployment to Kubernetes went wrong. It is therefore not a complete check on a correct Kubernetes configuration. Just be aware of that.

Package the Helm Chart

Now that we have adapted the chart configuration to our needs and that we have pushed everything to a git repository, it is time to package our Helm Chart. Execute the following command from outside your git repository, the command will search for a directory with the name of the Helm Chart from where it is issued:

helm package myhelmchartplanet

The package is being created (a tar gz file) and the following response is shown:

Successfully packaged chart and saved it to: /home/developer/myhelmchartplanet-0.1.0.tgz

As we said before, the name of our Helm Chart will be myhelmchartplanet-0.1.0 and here we can clearly see that.

Chart Repository

Before we can install the Helm package we created, we must make it downloadable. This is done by means of a Chart Repository. A Chart Repository contains packaged Helm Charts. It is not much more than a website containing an index.yaml and the Helm packages. When you browse to your home directory to the directory .helm/repository/local, then you notice that our packaged Helm Chart is added to this directory. The index.yaml file is automatically updated and contains metadata about the packages. It looks like the following:


apiVersion: v1
entries:
  myhelmchartplanet:
  - apiVersion: v1
    appVersion: 0.0.2-SNAPSHOT
    created: 2018-09-16T14:51:02.933628266+02:00
    description: A Helm chart for Kubernetes
    digest: sha256:a9c44411c15b7aa980f1c2d2f8deb29a82fcbb98eebdfc4ccecbf0910bf8e051
    name: myhelmchartplanet
    urls:
    - http://127.0.0.1:8879/charts/myhelmchartplanet-0.1.0.tgz
    version: 0.1.0
generated: 2018-08-26T18:01:30.000450767+02:00

In a production environment, you must ensure that your Helm packages are not stored on your local machine but are placed in a "real" repository. E.g. Google Cloud Storage, Artifactory, GitHub Page or just an ordinary webserver.

Summary

In part 1 of this post, we created our own Helm Chart, explained some of the files that are required, packaged our Helm Chart and made it available in a Chart repository. Next time we will continue with installing our Helm package to our Kubernetes cluster, upgrade it and execute a rollback.

Chart application Kubernetes Rollback (data management) Spring Framework Docker (software) Repository (version control)

Published at DZone with permission of Gunter Rotsaert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Are the Different Types of API Testing?
  • 5 Recent Amazing AI Advancements
  • Introduction to Cloud Native
  • Unlocking the Power of ChatGPT

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: