[Question] How useful is dhall-kubernetes (in my context) ?

[PierreR]

Honest question.

I am wondering how useful is dhall-kubernetes in the context of a dhall infrastructure setting that would inevitably be using Helm and Terraform as much as possible (instead of plain deployment yaml files).

I just thought of asking this question here directly after replying to dhall-lang/dhall-haskell#97.

Thanks for your reply.

[ari-becker]

Using dhall-kubernetes convinced us to completely ditch our Helm infrastructure. Which is to say, we had Helm running in production, we did some proofs-of-concept running dhall-kubernetes, and the results were so good that now we're trying to get rid of Helm ASAP.

Why is it "inevitable" for you to use Helm? Are you approaching the space as a developer in an organization where ops/infrastructure requires you to write Helm charts, or are you approaching the space from the ops/infrastructure side where Helm promises to help manage the different applications/systems you have running in a Kubernetes cluster?

Even if you are in a position where you have no choice but to use Helm (for its package management feature-set, which is orthogonal to dhall-kubernetes), you can use dhall-to-yaml and dhall-kubernetes to generate all of the Kubernetes YAML files, use a blank values.yaml, and then instead of the Helm chart being configurable, you can generate separate immutable Helm charts in each case in which you would have written a different values.yaml file. I wouldn't necessarily say that's a good idea - you're not testing the same Helm chart in pre-production environments as you are in production, it's more difficult to manage the charts if you're storing them in ChartMuseum or similar - but it's doable if you're hamstrung by your ops/infra team's policies. You'll get value out of such a setup if you also use Dhall to generate application or other config and not just the Kubernetes objects.

If you're coming at it from the ops/infra side... Dhall is a much, much more powerful language than Helm's Go Templates; do yourself a favor, ditch Helm, don't look back. You can do better than Helm's package management featureset by installing "packages" into their own individual namespaces, which also allows you to set a ResourceQuota over the entire "package" and prevent poorly defined or tested Helm packages from toppling your cluster. If you start to use dhall-kubernetes to manage all of the Kubernetes objects in your cluster, then making sure that the right objects have the right namespaces becomes a trivial task as the namespaces are no longer statically defined (e.g. namespace = "${environment}-${package}-${service}").

[arianvp]

I've been planning to do a larger tutorial akin to https://kubectl.docs.kubernetes.io whilst also comparing to other approaches like helm for a while. But that'll come after we release the new version which will have quite a few breaking changes. Once we have the new release out, I'll be focusing more on propaganda. Gonna need people's help though. I'd love to see examples of recipes the community came up with within their work, which we can aggregate somewhere.

Hopefully such a tutorial will quickly show people which patterns dhall is good at with.

[PierreR]

Thanks ! Your replies cheer me up ! I will take a closer look to dhall-kubernetes asap !

[f-f]

@ari-becker yours is such a great testimonial 😄

I'll add my perspective to this too:

• at work we have been trying to avoid Helm as much as possible (because security concerns) and we are doing just great (we don't have a huge deployment and we are a single team though, so the perspective of someone managing a cluster with tens of teams might be different)
• the other big reason to use Dhall for us is that it's really easy to integrate Kubernetes and Terraform to share configurations. I have a half-finished post about this, but "implementation time" usually eats up my "writing time" 😄 But as @arianvp said, as soon as we get API v2 #57 out I'll work on publishing it