Deployment Using Helm* Chart

As outlined in the Developer Workflow, Deploy Helm* Charts Helm* chart is a packaging tool for Kubernetes* applications.

In this step, we will write Helm charts to deploy the Tutorial Server and the Tutorial Web UI.

While it is possible to write one Helm chart encompassing both applications, it is more conventional to have a chart for each application. An alternative approach is to write a single umbrella chart that contains both charts as as sub-charts. This more advanced topic is not covered in this tutorial.

Note

Making this structural choice has important implications for how the application is deployed, but the Edge Orchestrator platform simplifies this process by using a Deployment Package to bundle the two applications together. This is covered in Deployment Package.

Name this the “Tutorial Chart” and create it in a new folder outside of the development directories you created previously.

mkdir tutorial-chart
cd tutorial-chart
helm version
helm create tutorial-server
helm create tutorial-web-ui

The helm create command creates a sample Helm directory structure suitable for deploying the NGINX* Web Server by default, which works here, since Tutorial Web UI is based on NGINX.

Understanding the Helm Chart

The directory structure of each chart looks like the following:

├── Chart.yaml
├── charts
├── templates
│     ├── NOTES.txt
│     ├── _helpers.tpl
│     ├── deployment.yaml
│     ├── hpa.yaml
│     ├── ingress.yaml
│     ├── service.yaml
│     ├── serviceaccount.yaml
│     └── tests
│          └── test-connection.yaml
└── values.yaml

It contains many resources that will work with Kubernetes and can be viewed using the helm template command (for tutorial-server it will be similar for tutorial-web-ui).

helm -n tutorial template --release-name foobar ./tutorial-server

The output in yaml format shows the result of the templates in the templates directory when the values.yaml file is applied to it.

For instance, this snippet from the output shows what each file in the templates folder produces and how it will be rendered in the Kubernetes platform. You can see the creation of a Service and a ServiceAccount and how the release-name and the namespace are applied:

---
# Source: tutorial-server/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: foobar-tutorial-server
  labels:
    helm.sh/chart: tutorial-server-0.1.0
    app.kubernetes.io/name: tutorial-server
    app.kubernetes.io/instance: foobar
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
---
# Source: tutorial-server/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: foobar-tutorial-server
  labels:
    helm.sh/chart: tutorial-server-0.1.0
    app.kubernetes.io/name: tutorial-server
    app.kubernetes.io/instance: foobar
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: tutorial-server
    app.kubernetes.io/instance: foobar
......

Inspecting the values.yaml file shows how the powerful configurability of Helm allows overriding template behavior without having to adjust the templates. For instance, the following snippet shows how the image repository, tag and pull policy can be overridden just by changing the values.yaml file.

# example
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: ""

nameOverride: ""
fullnameOverride: ""

service:
  type: ClusterIP
  port: 80

A common practice is to create a values-production.yaml file that contains values that will override the inbuilt values.yaml rather than modify it. (You will see this demonstrated later.) Managing different versions of override files is an import part of Edge Orchestrator deployment.

In the next section, you will learn how to modify the charts for this tutorial.