Deployah – deploy to Kubernetes from a short spec, no Helm, nothing in-cluster

3 pointsposted 7 hours ago
by atkrad
(github.com)

15 Comments

gopherly

7 hours ago

How do you deploy apps to Kubernetes without writing Helm charts?

I mean the middle ground: not hand-writing charts/YAML, and not installing an in-cluster PaaS either. What do people actually use for that, especially CLI-only?

verdverm

7 hours ago

I'm using CUE (config) + Helm (reconsiliation)

This post is also using helm, putting a DSL in front because yaml sucks and templated yaml is insane. The problem here is the DSL, devs don't want a DSL for k8s ime, it becomes yet another abstraction of complexity. I render full k8s yaml for helm and avoid the templates

mring33621

6 hours ago

"yaml sucks and templated yaml is insane"

I'm happy to hear that I'm not the only one that thinks this.

atkrad

6 hours ago

Same. Templated YAML is what pushed me away from writing charts by hand.

verdverm

6 hours ago

likewise! I cannot understand the field of devops willingness not only to endure this, but find double templated yaml (Argo+helm) appealing. So many of my peers prefer to do what everyone else is doing and slog through the pain.

atkrad

6 hours ago

Yeah, Argo + Helm double templating is rough. I stayed client-side on purpose so you can still inspect the release with normal helm commands.

znpy

6 hours ago

This is overall a bad idea, and I wouldn't touch the clusters i managed with a ten-foot pole.

For starters, having nothing running in the clusters means you have to give rw cluster access to developers. Developers should not be allowed near production without adult supervision.

Then, it simplifies nothing but adds its own complexity on top. You still need to understand helm for when this tool will (inevitably!) produce something that doesn't work the way you thought it would or when it produces something that doesn't match the mental model you made about it.

Also it seems to also spin local kubernetes clusters?

Also it seems to be have a dependency on nip.io hard-coded? Looks like an easy jackpot kind of target ? (you hijack nip.io dns records, you get a bunch of traffic from developers' laptop).

So a bad idea overall in my opinion.

atkrad

6 hours ago

Fair points. A few clarifications though.

On cluster access: Deployah does not ask you to hand developers cluster-admin on prod. It is a client-side CLI, same class as helm/kubectl. Whoever runs it needs whatever RBAC you already give that identity. The intended split is deployah.yaml for the app, and deployah.platform.yaml for contexts, domains, TLS, profiles. Platform/ops can own that second file, and prod deploys can stay in CI with a locked-down service account. If your bar is "no human kube credentials on prod at all", this is not the tool, and neither is bare helm from a laptop.

On Helm: agree that when something breaks, being able to run helm get / helm history helps. The goal is not "never learn Kubernetes". It is "do not write a chart for every small app". Day to day you work with the spec; the release is still a normal Helm release if you need to inspect it.

On local clusters: yes, optional. deployah cluster up is for laptop/dev only. Prod is just a kubeconfig context from the platform file.

On nip.io: that is only the scaffold default for the local environment (127.0.0.1.nip.io), so you get a hostname without editing /etc/hosts. Production domains come from deployah.platform.yaml, e.g. example.com with cert-manager. If you do not want nip.io even locally, change baseDomain. The "hijack nip.io, steal laptop traffic" risk is real for any tool that defaults to nip.io for local URLs; it is not hard-coded into prod deploys.

So I would not point this at unmanaged prod clusters either. The fit I care about is local/dev and small teams that already have a kubeconfig and do not want an in-cluster PaaS. Happy to hear where that still looks wrong.