Helm is a powerful tool for managing applications on Kubernetes using charts. Helm enables you to define, install, and upgrade even complex applications with ease. However, when it comes to testing and development of multiple systems with separate Helm charts, it can sometimes be a bit cumbersome to manage all the resources, values, and dependencies.

This is where Helm-Compose comes into play, offering a solution to simplify and streamline the process and allow for full Configuration-as-Code support for all Helm CLI options.

What exactly is Helm-Compose?

It allows you to define and manage multiple Helm releases in a single docker-compose-like YAML file.

https://seacrew.github.io/helm-compose/

apiVersion: 1.1

releases:
  blog:
    chart: bitnami/wordpress
    chartVersion: 14.3.2
    namespace: blogs
    createNamespace: true

repositories:
  bitnami: https://charts.bitnami.com/bitnami

Motivation

Unfortunately, Helm charts don't support multiple layers of dependencies and a lot of Helm charts already have one or more dependencies on other charts like Redis or PostgreSQL. Therefore, a wrapper Helm chart around wouldn't suffice to setup all your deployments in one package. Furthermore, not all things could be encapsulated inside a Helm chart. Especially not options meant for the Helm CLI itself like network and security flags.

For this reason the idea of Helm-Compose was born.

How it works

With Helm-Compose, you can specify all your necessary Helm releases, their charts, Helm options and values in a single file. Making it easy to start, stop, and manage your Kubernetes applications during development from one central file with two simple commands:

helm compose up and helm compose down

This allows you to have a code revision of all helm options/flags you need for you deployments.

Getting started

Helm v3.10+ already needs to be installed on your system.

Installation

Install the latest version of Helm-Compose with the following command:

helm plugin install https://github.com/seacrew/helm-compose

Create Helm-Compose file

Create a helm-compose.yaml file in your project directory and define your Helm releases, charts, and values.

Here's a simple example:

apiVersion: 1.1

storage:
  name: wordpress
  type: local

releases:
  site1:
    chart: bitnami/wordpress
    chartVersion: 14.3.2
    namespace: site1
    createNamespace: true
    # You can either use values directly
    # or value files or even both together
    # valueFiles:
    #   - ./values/wordpress.yaml
    values:
      wordpressBlogName: Awesome Site
      wordpressPassword: awesome
      mariadb.auth:
        rootPassword: "awesome-password"

repositories:
  bitnami: https://charts.bitnami.com/bitnami

Deployment / Spin-Up

Now you are ready to deploy your simple stack with:

helm compose up

If you don't use one of the following expected file names you can use the optional -f flag to define the path to your Helm-Compose file:

• helm-compose.yaml
• helm-compose.yml
• helmcompose.yaml
• helm-compose.yml
• helmcompose.yaml
• helmcompose.yml
• helmcompose
• compose.yaml
• compose.yml

helm compose up -f mycomposefile.yaml

Tear-Down

For the tear-down use the following command:

helm compose down

Further Features

Managing of repositories: As the keen-eyed among you might already have detected in the previous YAML example, you can manage your Helm chart repositories:

repositories:
  bitnami: https://charts.bitnami.com/bitnami
  hashicorp: https://helm.releases.hashicorp.com

https://seacrew.github.io/helm-compose/latest/key-features-and-use-cases/#repository-handling

Revision Management: To be able to detect changes, especially removals between helm compose (up/down) executions. Helm-Compose creates encoded revisions similar to how Helm does it for single releases. However you have quite a bit control over where those revisions will be stored:

storage:
  # revision file name
  name: my-revision
  # revision storage provider type
  # currently supports local files,
  # kubernetes secrets and s3
  type: k8s # default: local
  # number of revisions to be stored
  numberOfRevisions: 5 # default 10
  # custom options for the selected
  # storage provider. in this case
  # a k8s namespace for storage
  namespace: config-as-code

Furthermore, revision handling allows for rollback to previous versions.

General revision handling docs:
https://seacrew.github.io/helm-compose/latest/key-features-and-use-cases/#revision-handling

Storage provider details:
https://seacrew.github.io/helm-compose/latest/storage-providers/

Benefits and Conclusion

So why and when would Helm-Compose be helpful to you?

1. Simplified Local Development: Helm-Compose provides a declarative way to define and manage your Helm releases. This means you can easily define the entire application stack in a single YAML file, including dependencies, and launch it with a single command as one unit.

2. Improved Collaboration: Sharing a Helm-Compose YAML file makes it simple for team members to get up and running with exactly the same application configuration and have a code revision of each and every Helm flag.

3. Isolation of Resources: Each Helm release defined in the Helm-Compose file is still isolated from the others, which mimics the behavior of running these releases separately in a production cluster.

4. Reproducible Environments: With Helm-Compose, you can ensure that your development environment closely matches your production environment. This helps uncover issues early in the development process and minimizes surprises when deploying to multiple environment and devices.