Use GitHub Actions to Deploy Helm Charts to an EKS Cluster

You know how sometimes you create an Action just so every dev on earth doesn’t have to create their own automation? That’s how we wound up creating Deploy Helm to EKS.

Instead of manually deploying Helm to EKS, you can use this Action to automate deployment from your GitHub workflow.

We’ve tried it out with our clients to automate the deployment of Helm charts, and we think it’s ready to share with you.

Why Use Helm Charts

When you’re deploying an application to a Kubernetes cluster, you need several specific YAML files: deployment, service, ingress, config maps, service accounts, secrets, and so on. You then customize those files for each cluster/environment/namespace.

Helm allows you to create templates from those YAML files, replacing actual values with a variable.

These variables have their default values defined in a file called values.yaml. Once that file’s in place, we can then create custom values.yaml files for each deployment, or just pass in key/value pairs.

In short, Helm is a great tool that allows you to have a single chart for all deployments while still being able to have customizations for different environments.

Why Use the Deploy Helm to EKS Action

The Deploy Helm to EKS action automates the steps needed to connect to EKS and deploy a Helm Chart. The action creates the Namespace if it doesn’t exist and then performs the installation of the Helm Chart. As an added bonus, it works for fresh installations as well as updates.

This action also simplifies a couple of things. It removes the need to obtain and store a config file for each cluster, since we’re using AWS credentials to connect to the EKS cluster by name. It also makes it easier to determine how all of our different values and files that we need to pass are used, since the action makes them all inputs.

How to Use the Deploy Helm to EKS Action

To demonstrate how the action works, I’ll walk you through an example. 

In our example, we’ll assume a directory structure such as the one on the right. It includes a folder called API (our microservice) with a folder for the Helm chart files.

We also have a folder inside API for each namespace. In our example, the namespace and the cluster name are environmental variables.

Prepare

To prepare, create 2 GitHub secrets, which I’ll recommend calling AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. These secrets should contain the Secret-Access-Key and the Access-Key-ID of an AWS account that has rights to deploy to the EKS cluster(s).

Your EKS cluster needs an externally accessible Kubernetes API Endpoint. Alternatively, you can use a self-hosted runner in AWS that can access the endpoint.

Create Your Workflow

Below is an example of a complete workflow that triggers when a file is updated in the ./api/prod-api folder. The file should be named ./.github/workflows/deploy-prod-api.yaml.

Be sure to include a step to check out your repository, and then add this action.

 
name: PROD API

on:
  workflow_dispatch: {}
  push:
    branches:
      - master
    paths:
      - /api/prod-api/*

env:
  namespace: prod-api
  cluster: prod-cluster

jobs:
  deploy:
    runs-on: self-hosted
    steps:

    - name: Checkout Github Repo
      uses: actions/checkout@v2

    - name: Deploy Helm
      uses: bitovi/github-actions-deploy-eks-helm@v1.0.0
      with:
        aws-access-key-id: $
        aws-secret-access-key: $
        aws-region: us-west-2
        cluster-name: $
        cluster-role-arn: $
        config-files: api/$/values.yaml
        chart-path: api/chart
        namespace: $
        name: api

Let’s look at a couple of other examples of how you can use this action.

Example: Self Hosted Helm

Below is an example of deploying charts from your GitHub Repo. Not all of the fields are required.

uses: bitovi/github-actions-deploy-eks-helm@v1.0.0
with:
  aws-access-key-id: $
  aws-secret-access-key: $
  aws-region: us-west-2
  cluster-name: mycluster
  config-files: .github/values/dev.yaml
  chart-path: chart/
  namespace: dev
  values: key1=value1,key2=value2
  name: release_name

Example: External Helm Chart

In this example, your chart lives in an external repository. You just need to ensure that we have a values.yaml file for each environment and specify it in the correct location.

- name: Deploy Helm
      uses: bitovi/github-actions-deploy-eks-helm@v1.0.0
      with:
        aws-access-key-id: $
        aws-secret-access-key: $
        aws-region: us-west-2
        cluster-name: mycluster
        cluster-role-arn: $
        config-files: fluent-bit/prod/values.yaml
        chart-path: fluent/fluent-bit
        namespace: logging
        name: fluent-bit
        chart-repository: https://fluent.github.io/helm-charts

Inputs

Below are the available inputs that can be used with step.with keys.

Feedback on Deploy Helm Chart to EKS Action

We created this GitHub action to automate the deployment of Helm charts to EKS, and we’re hoping it achieves that. If you have feedback, ideas for improvement, or just want to talk DevOps with us, drop into Bitovi's Discord Community and post in the #devops channel!

Need DevOps Help? Work with Us 

We collaborate with other development teams on deployment automation, resiliency, observability, and infrastructure migration and management. Click here to get a free consultation on how to tackle your biggest DevOps problems.