5 ms·

Helm-Compose – The Docker-compose like tool for K8s development

54 points by tuunit 3y ago

tuunit 3y ago
A docker-compose like tool for multi helm chart deployment handling. Primarily meant to be used for development, to be able to quickly deploy all dependent services and tools from within a single yaml file.
- remram 3y ago
  How does it differ from Helm? Templating resources and sub-charts is already what Helm does.
  - tuunit 3y ago
    First and for most you can only have one sub chart layer in helm. So if you want to setup a full environment replica on your local machine using your production helm charts, which might already have chart dependencies you cannot use another wrapper helm chart at the top. As helm does not have sub-sub-dependency / recursive resolution. Furthermore, helm compose allows for FULL configuration as code. With helm you always have define some parameters in the command line like the correct namespace, release name and chart name and chart version with helm compose you just write: "helm compose up". Obviously, that can be solved by aliases but this way truly everything is kept inside a configuration file.
    - remram 3y ago
      > First and for most you can only have one sub chart layer in helm I don't think that's true?
      - tuunit 3y ago
        the request for this feature has been open since 2017: https://github.com/helm/helm/issues/2247 https://github.com/helm/helm/issues/2247
        remram 3y ago
        It's related but I don't think it prevents you from having nested dependencies. This is about building packaged charts with multiple levels in one go (e.g. without packaging the nested ones first).
don-code 3y ago
We've been using Helmsman (https://github.com/Praqma/helmsman https://github.com/Praqma/helmsman) for the same use case. It supports some other creature comforts (automatic fetching of parameters from AWS SSM, chart ordering, etc.) and seems a bit more mature.
seymon 3y ago
What are the benefits over using helmfile? https://helmfile.readthedocs.io/ https://helmfile.readthedocs.io/
- seabrookmx 3y ago
  Or dependencies? https://helm.sh/docs/helm/helm_dependency/ https://helm.sh/docs/helm/helm_dependency/
  - MuffinFlavored 3y ago
    Or just kubectl apply a bunch of yaml files? or argocd / helm charts?
    - SOLAR_FIELDS 3y ago
      Those two are not like what grandparent is saying. Helm dependencies are native to helm like docker compose is native to docker. Kubectl apply a bunch of yaml files is like saying “run a bunch of docker files instead of docker compose” and argocd isn’t the same realm, that is a hosted solution that requires a remote k8s cluster. I guess you could run it locally but you would be making commits to a git repo for iteration which would be slow annoying and painful. It solves an entirely different problem set to this one, it’s not meant to solve local dev iteration loops. The comparison of helm compose and helm dependencies is much more apples to apples as they essentially solve the exact same problem in similar way
      - MuffinFlavored 3y ago
        Well said/good points. What's your preferred way to orchestrate deployments/configs/resources/workloads into k8s?
        SOLAR_FIELDS 3y ago
        Into k8s? I do like Argo/flux as it’s declarative. It works for most normal use cases. I would recommend that if you have a typical use case go with that first. Declarative and pull based deploys are quite powerful. For local/hybrid stuff there’s things like Tilt that can be combined with a push based approach that is a simple helm install. If you have something fancy though you’ll probably have to write some custom orchestration pushed based tooling. I would reach for a tool like Dagster, Prefect or Temporal for that kind of thing. You probably don’t need custom orchestration tooling unless you’re doing multi tenant multi cloud deployments though. Even terraform is a decent deploy tool if you don’t want to go all in on helm/flux/argo etc. I would especially recommend that approach if your use cases are not fancy and you already use terraform. It would be push based but still declarative and quite simple to use, albeit clunky and a bit slow like everything terraform.
nlunbeck 3y ago
I'm all for the idea of using the compose spec for other configs -- its so elegant and its always nice to see everything in one place.
qntty 3y ago
Now we just need an orchestrator for all of our helm charts
aliencat 3y ago
Sharing a tool that I wrote to convert docker-compose file to kubernetes deployment YAML: https://docker2kube.app.enting.org/ https://docker2kube.app.enting.org/ Hope it helps someone!
- gorkish 3y ago
  how does this tool differ from kompose
mati365 3y ago
Why not just use podman quadlet and systemd?
doctoboggan 3y ago
How does this differ from the "umbrella chart" pattern? I am able to install my whole stack with a single call to `helm install`. I will admit the dependency handling (subchart naming), and enabling/disabling is a little clunky but it does have everything needed.
temptemptemp111 3y ago
[dead]
zapt02 3y ago
There's clearly no lack of existing solutions in the k8s space because a majority of the comments are currently "why not use X instead".

54 points by tuunit 3y ago

A docker-compose like tool for multi helm chart deployment handling. Primarily meant to be used for development, to be able to quickly deploy all dependent services and tools from within a single yaml file.

remram 3y ago
How does it differ from Helm? Templating resources and sub-charts is already what Helm does.
- tuunit 3y ago
  First and for most you can only have one sub chart layer in helm. So if you want to setup a full environment replica on your local machine using your production helm charts, which might already have chart dependencies you cannot use another wrapper helm chart at the top. As helm does not have sub-sub-dependency / recursive resolution. Furthermore, helm compose allows for FULL configuration as code. With helm you always have define some parameters in the command line like the correct namespace, release name and chart name and chart version with helm compose you just write: "helm compose up". Obviously, that can be solved by aliases but this way truly everything is kept inside a configuration file.
  - remram 3y ago
    > First and for most you can only have one sub chart layer in helm I don't think that's true?
    - tuunit 3y ago
      the request for this feature has been open since 2017: https://github.com/helm/helm/issues/2247 https://github.com/helm/helm/issues/2247
      - remram 3y ago
        It's related but I don't think it prevents you from having nested dependencies. This is about building packaged charts with multiple levels in one go (e.g. without packaging the nested ones first).

don-code 3y ago

We've been using Helmsman (https://github.com/Praqma/helmsman https://github.com/Praqma/helmsman) for the same use case. It supports some other creature comforts (automatic fetching of parameters from AWS SSM, chart ordering, etc.) and seems a bit more mature.

seymon 3y ago

What are the benefits over using helmfile? https://helmfile.readthedocs.io/ https://helmfile.readthedocs.io/

seabrookmx 3y ago
Or dependencies? https://helm.sh/docs/helm/helm_dependency/ https://helm.sh/docs/helm/helm_dependency/
- MuffinFlavored 3y ago
  Or just kubectl apply a bunch of yaml files? or argocd / helm charts?
  - SOLAR_FIELDS 3y ago
    Those two are not like what grandparent is saying. Helm dependencies are native to helm like docker compose is native to docker. Kubectl apply a bunch of yaml files is like saying “run a bunch of docker files instead of docker compose” and argocd isn’t the same realm, that is a hosted solution that requires a remote k8s cluster. I guess you could run it locally but you would be making commits to a git repo for iteration which would be slow annoying and painful. It solves an entirely different problem set to this one, it’s not meant to solve local dev iteration loops. The comparison of helm compose and helm dependencies is much more apples to apples as they essentially solve the exact same problem in similar way
    - MuffinFlavored 3y ago
      Well said/good points. What's your preferred way to orchestrate deployments/configs/resources/workloads into k8s?
      - SOLAR_FIELDS 3y ago
        Into k8s? I do like Argo/flux as it’s declarative. It works for most normal use cases. I would recommend that if you have a typical use case go with that first. Declarative and pull based deploys are quite powerful. For local/hybrid stuff there’s things like Tilt that can be combined with a push based approach that is a simple helm install. If you have something fancy though you’ll probably have to write some custom orchestration pushed based tooling. I would reach for a tool like Dagster, Prefect or Temporal for that kind of thing. You probably don’t need custom orchestration tooling unless you’re doing multi tenant multi cloud deployments though. Even terraform is a decent deploy tool if you don’t want to go all in on helm/flux/argo etc. I would especially recommend that approach if your use cases are not fancy and you already use terraform. It would be push based but still declarative and quite simple to use, albeit clunky and a bit slow like everything terraform.

nlunbeck 3y ago

I'm all for the idea of using the compose spec for other configs -- its so elegant and its always nice to see everything in one place.

qntty 3y ago

Now we just need an orchestrator for all of our helm charts

aliencat 3y ago

Sharing a tool that I wrote to convert docker-compose file to kubernetes deployment YAML: https://docker2kube.app.enting.org/ https://docker2kube.app.enting.org/ Hope it helps someone!

gorkish 3y ago
how does this tool differ from kompose

mati365 3y ago

Why not just use podman quadlet and systemd?

doctoboggan 3y ago

How does this differ from the "umbrella chart" pattern? I am able to install my whole stack with a single call to `helm install`. I will admit the dependency handling (subchart naming), and enabling/disabling is a little clunky but it does have everything needed.

temptemptemp111 3y ago

[dead]

zapt02 3y ago

There's clearly no lack of existing solutions in the k8s space because a majority of the comments are currently "why not use X instead".