Helm for Deployment

We’re about ready to deploy into kubernetes. However, deployment is not exactly straightforward. There are a lot of configuration files that we need to create and maintain in order to explain to the container management system how to deploy our application. We can use tools like kubectl to promote these files, but it quickly becomes cumbersome. In this article we’ll explain how helm will assist us with deployment.

Kubernetes Overview

This is a very simple and over simplification of the kubernetes environment and I would say that it may even be inaccurate depending on the application and its configuration, but for our very high level discussion it will be useful.

The pods are the actual instances of a microservice. You can configure how many instances should be available (for failover and scalability purposes). They pull the image out of the docker registry on startup.

Most applications need some sort of configuration (in our example service, the datasource) in order to be able to function correctly. Now that we’re in a distributed environment (multiple service instances running simultaneously) we need to make sure that the running instances are using the same configuration. That’s where configmaps come in. They store the configuration for our application and make sure that all instances are running with the same configuration.

Finally, since we have multiple service instances we need a loadbalancer to determine which instance will handle a request. This is where the service comes in. It links all of the pods to a single endpoint. It can be configured to be available outside of the cluster and that can function as an ingress point to the cluster. This is how we’ll be configuring our service.

There are also kubenetes configuration that we’re not discussing related to security and access. These are required (letting our deployment see our configmap for example) and must be deployed, but doing all of this by hand is tedious and error prone. We’re going to use a tool called Helm to manage templates of our kubernetes deployment configuration and inject values into them instead. This is very similar to properties in an application context for spring.

Helm Overview

Again, this is a gross oversimplification. Helm is a deployment configuration management tool but functions also as a deployment tool. By defining templates for the kubernetes deployment configuration we can just use a values.yaml to inject our application’s values into it. This will create a ‘real’ deployment configuration that we can push into kubernetes. Since kubernetes knows about the docker repository (from the deployment configuration) it will setup the configuration definition, pull the image, build a pod from it using the specified configuration, setup the service to front the pods and start up everything.

The only command we have to know in order to make all of this happen is helm install. We can also upgrade any changes to the docker image or configuration with helm upgrade and we can revert those changes with helm rollback.

Additionally, we can package the finalized deployment configuration into (what is called) a chart so that we can version our application deployment configuration. We can combine our helm charts into an umbrella chart as well, which allows us to define our entire cluster which is a very powerful tool from an operations perspective.

Lets get started.

Helm File Installation

Helm Install

Use your package manager to install helm.

Helm Template

Paul Czarkowski has done a lot of work creating a ‘standard’ spring boot helm chart template project that we’ll rely heavily on. We’re basically going to lift that entire structure, drop it into our project and then change the values.yaml file to reflect our application’s needs.

Create a directory for helm in src/main/helm/medium-customer. copy the contents of that project into the helm/medium-customer directory.

Make the following changes to values.yaml

image:
  repository: r.cfcr.io/docketdynamics/medium-customer

spring:
## Uncomment if you want to activate a specfic spring profile
  # profile: kubernetes
  ## Ensures that Spring trusts Kubernetes certificate for use with
  ## service discovery, configuration, etc.
trustKubernetesCertificates: true
## customized parameters/config for your spring app.
  ## by default will be rendered to `/config/application.yml`
config:
## Currently only supports file
type: file
## Contents of config in YAML
content: |-
      server:
        tomcat:
          accesslog:
            enabled: true
            pattern: '%h %l %u %t \"%r\" %s %b zipkin:[%{X-B3-TraceId}i, %{X-B3-SpanId}i, %{X-B3-ParentSpanId}i]'
    spring:
      application:
        name: customer
      jackson:
        deserialization:
          FAIL_ON_UNKNOWN_PROPERTIES: false
      datasource:
        hikari:
          connectionTimeout: 20000
          maximumPoolSize: 2
        url: jdbc:postgresql://ec2***.amazonaws.com:5432/df***oe

Also update the chart.yaml

apiVersion: v1
appVersion: 0.0.1
description: A Helm chart for Kubernetes
name: medium-customer
version: 0.0.1
maintainers:
  - name: brook
    email: [email protected]

Build and Commit

We can’t test this yet until we have a cluster working. Let’s go ahead and commit these changes for now.

git checkout -b helm
mvn clean install
git add .
git commit -m "helm chart create"
git push --set-upstream origin helm
git checkout master
git merge helm
git push