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?
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.
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.
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.
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.
Top comments (1)
awesome, will give it a try.