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

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

github.com

3 pointsatkrad12 comments

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.

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.

The use case you describe (small team) can just use a shared helm chart, customised through values.yaml to run whatever image is needed.

This (deployah) add a very large layer of complexity. It’s a no for me.

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?

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

"yaml sucks and templated yaml is insane"

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

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.

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

This is a good bridge to something new eventually. There is Timoni, which was a CUE based attempt to replace Helm, but imo, it stayed too true to helm concepts and missed the opportunities CUE enables.

From experience, you will likely get the most pushback / dropoff from the DSL. Like people want to get at helm if needed, creating an abstraction (DSL) of the underlying k8s constructs will make it too challenging to get at the actual underlying k8s resources. I get that yaml is repeatative and there is a place for reuse, but a custom CLI and DSL is not paletable.

I was recently scolded for telling my coworkers that they are 'nose blind' to the mess that is our CI/CD 'pipeline'.

Maven, docker buildx, jenkins, github actions, helm, ArgoCD, Tekton, Terraform

It's an often-broken Franken-Goldberg machine

oooh that smell, can't you smell that smell?

I've architected our CI pipeline (newer folks are doing the CD portion), it's a monorepo tamed with CUE and Dagger, runs on Jenkins that needs to simulate an air gapped install of k8s then some helm. Can't imagine using multiple systems for the same piece of the pipeline!

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

Reply on news.ycombinator.com