Generate docker-compose.yaml from Helm charts

Question

I am interested in generating docker-compose.yaml files from Helm charts. Is there a good way or tool to do this?

I realize that this is in the opposite direction from what most people are doing. Why I want to do this:

1. Our production systems run Kubernetes via Helm charts. We've got a full blown k8s and Helm setup already; no need to use a tool like Kompose to get us there. The question is how to convert Helm to docker-compose, not the other way around.
2. We want our Helm charts to be the single authoritative source of container configuration. They are able to describe a superset of what docker-compose can.
3. Running a set of services using Helm on a development machine is more time and resource consuming than running the same set of services via docker-compose. We do not want to slow development down by having engineers run using Helm/k8s.
4. We do not want to maintain two sets of configurations.

Can anybody recommend how to do this, or suggest a different solution to the time/resources issue encountered on development machines?

Neurosurgery

I don't think you can easily translate things like multi-container pods, service DNS, or ConfigMaps back to plain-Docker space. What's the specific resource issue you're encountering? There are several different local-Kubernetes setups that could work (and don't necessarily involve a dedicated VM). – Yulan

The resource issue is the time to iterate. Specifically, if in a suite of services (a, b), I make code changes to b, it takes time n to build and spin up b in docker-compose, whereas it takes time 2*b to build and spin up b using Helm. – Neurosurgery

For #3 ("Running a set of services using Helm on a development machine is more time and resource consuming than running the same set of services via docker-compose"), what specifically is the time consuming part? Can't you just "helm install" locally? – Hydrotherapeutics

Max, you're correct, it's not necessarily more time consuming. Underneath the layers and configuration it's all just Docker containers being spun up. But it is definitely more resource consuming in terms of the number of containers/pods running (to support the features that make up Kubernetes). Run kubectl get pods --all-namespaces to see what I mean. – Neurosurgery

Totally agree with your third point, however I think the only way to maintain single application environment both for developers and production is to mimic production locally as close as possible, rather then building workarounds. There are lightweight k8s installations desired to run locally, like microk8s or [k3s](k3s.io, You can either mount local directories inside the pods or use ksync. – Wicker

@Neurosurgery Which parts of the k8s/helm process do you think takes up the extra time? If you're not using the same container service for image builds there might be an image push? k8s scheduling should only be a few more seconds than compose startup. – Brout

I agree, I also need to convert helm chart to a docker compose. Simply because doing this manually would be too painful. I have generic helm templates and values.yaml file with >1k lines. Stuff can dynamically resolve microservice deps etc. I need to be able to output dry run to a file that could be run on a docker compose. Impossible? I don't think so. Use heuristics. Missing DNS? Drop dns, replace: localhost + internal pod port. Network policy? Drop. Impossible feature? Warn: no support. Even broken output better than nothing - faster to fix few things than write everything from scratch. – Nectar

Answer 1

Although this is an old question, I need to add my insights into this. It is basically impossible to do so, depending on you setup of course. Only if you have the most simple setup of your application this will work.

First problem: There are no Pods in Docker, trying to emulate this with Docker-Compose will not work well. The K8s-DNS is not available and service-discovery through it, simply isn't there. Lots of other stuff that K8s does is not possible (no Ingress configuration in Docker)

Unless you service is a single container with only minimal configuration and no use what so ever of K8s-features, it will not work.

We use Rancher-Desktop which works well and even installs Helm with it. We used Docker-Desktop before and it also worked quite well. Buy your developers decent hardware, if their workstations don't support a local K8s-Installation.

Mudlark

Answer 2

While I agree one 100% that there should be a tool to preform translations between the two stacks. One states "We do not want to maintain two sets of configurations" but still wants two sets of configurations.

Easier to get your devs onboard with the same stack you use in production instead of the other way around.

That said, the method I tend to use is with xslt and xpath. Even then the results are not the same.

Helm Charts usually include secrets and config files along with deployment and container specs. Docker-compose only needs the deployment/container spec. So my process is to have helm generate the results for a kubernetes deployment.yml to stdout then use a yml to xml mitter. From there use xmlstarlet with a xslt template with needed xpath selections to create the resulting docker-compose.yml file.

It sounds convoluted but its just usual UNIX text processing (e.g. helm install --dry-run --debug | yaml2xml | xml tr ~/lib/docker-compose.xslt /dev/stdin > ./docker-compose.yml && pipx run yamllint ./docker-compose.yml). where the following is happening:

helm prints a deployment.yaml to stdout, then yaml2xml [a custom script that parses that and turns it into raw xml] prints xml to stdout, then that's parsed and translated by xml(1). The last step there is to lint the results for just in case.

Conceivable

What's in the XSLT script? I wonder if some other transformation tool might work better; the ytt tool is part of the Carvel Kubernetes toolkit, for example, but it should be able to do arbitrary YAML-to-YAML transformation (with fewer angle brackets). – Yulan

idk much about ytt but what I do see is a wall of hash-at and esoteric DSL statements. Also if one is going down the rabbit hole of using a domain specific tool for x job then we'd have a xkcd927 for every individual task and all of it behind a -aaS paywall. the xslt is simple. Just three xsl statements with "text" output, apply-template "/", and some xsl:value-of xpath selectors on the value side for the docker-compose.yaml keywords. IMHO easier to read than handlebars (aka go templates), hcl, or ytt macro language. Gets the job done. (can also generate reports/docs w/same toolset) – Conceivable