dhall-kubernetes VS helm

I hate yaml with a passion. It marginally better than xml for reading (wins huge on comment syntax) and worse for everything else. It makes zero sense we somehow ended up with it as standard configuration serialization format.

Note yaml is not a DSL. It's a tree serialization format! Everything interesting is happening after it is parsed. Extreme examples point to e.g. github actions conditions.

Anyway, back on topic - maybe not prolog for CDK, but still quite interesting: Dhall-kubernetes - https://github.com/dhall-lang/dhall-kubernetes

At this point, if it’s painful enough, why isn’t compiling-to-yml tools more popular?

Example: https://github.com/dhall-lang/dhall-kubernetes

Haven’t used dhall myself but I’d definitely prefer a DSL on top of yaml.

Dhall provides https://github.com/dhall-lang/dhall-kubernetes which is exactly this: statically type-checked kubernetes config generation.

Dhall is my favorite configuration language that I never get around to using.

I manage DNS in Terraform, and since every Terraform provider uses different objects definitions, and every object definition is rather verbose, Dhall would be a way to specify my own DRY types and leave the provider-specific details in one place. Adding new DNS entries and moving several domains between providers would be a matter of changing fewer lines.

Dhall also has Kubernetes bindings:

https://github.com/dhall-lang/dhall-kubernetes

Although I'm tempted to just stick to Helm here, even though it's less type-safe.

Not Helm directly, but does something like Dhall fit your question? https://github.com/dhall-lang/dhall-kubernetes

Have you heard about Dhall? It’s a programming language used for generating configuration files for a variety of purposes. One of them is to replace old and limited formats such as JSON and YAML. It is DRYable, secure, and even suitable for creating K8s manifests. The latter option isn’t something for anyone: you have to learn a new language and deal with its peculiarities, but it might be really helpful when you have tons of YAML configs. I’ve recently made a short intro to Dhall for K8s in this review.

Best thing is Dhall that I am aware of. Same situation, working as a consultant, forced to use broken things.

https://github.com/dhall-lang/dhall-kubernetes

Lets look at a specific example. Take Kubernetes: everything is yaml, with complete schemas, all the way down. From your perspective this is configuration utopia, right? Meanwhile back in reality k8s is the poster child of "yaml hell". From the day it was released, people took one look at it, gave it a giant NOPE and instantly spawned half a dozen templating languages. The most popular of these is helm, which has a terrible, no good, very bad design: full of potential injection attacks from purely textual string substitution, manually specified indentation to embed parameterized blocks, virtually no intermediate validation, no way to validate unused features, etc etc

Compare to dhall which publishes a complete set of dhall-k8s schema mappings which enables you to factor out any design you want down to as few configuration variables as you like, while validating the configuration generators themselves at design time. https://github.com/dhall-lang/dhall-kubernetes#more-modular-...

The solution I like is Dhall. They even have a Kubernetes solution that will catch a lot of issues at compile-time, before you try to apply it to Kubernetes. At earthly we aren't actually using it though. Our Kubernetes guru found it to be a bit slow but I am hopeful it or something like it will be the future.

Applying Kubernetes manifests individually is problematic because files can get overlooked. Packaging your applications as Helm charts lets you version your manifests and easily repeat deployments into different environments. Helm tracks the state of each deployment as a "release" in your cluster.

helm

Explanation here: https://github.com/helm/helm/issues/12681#issuecomment-19593...

Looks like it's a bug in Helm, but actually isn't Helm's fault, the issue was introduced by Fedora Linux.

Helm (Get from here https://helm.sh/)

It’s also well understood that having a k8s cluster is not enough to make developers able to host their services - you need a devops team to work with them, using tools like delivery pipelines, Helm, kustomize, infra as code, service mesh, ingress, secrets management, key management - the list goes on! Developer Portals like Backstage, Port and Cortex have started to emerge to help manage some of this complexity.

Kubernetes orchestrates deployments and manages resources through yaml configuration files. While Kubernetes supports a wide array of resources and configurations, our aim in this tutorial is to maintain simplicity. For the sake of clarity and ease of understanding, we will use yaml configurations with hardcoded values. This method simplifies the learning process but isn’t ideal for production environments due to the need for manual updates with each new deployment. Although there are methods to streamline and automate this process, such as using Helm charts or bash scripts, we’ll not delve into those techniques to keep the tutorial manageable and avoid fatigue — you might be quite tired by that point!

Helm is a package manager that automates Kubernetes applications' creation, packaging, configuration, and deployment by combining your configuration files into a single reusable package. This eliminates the requirement to create the mentioned Kubernetes resources by ourselves since they have been implemented within the Helm chart. All we need to do is configure it as needed to match our requirements. From the public Helm chart repository, we can get the charts for common software packages like Consul, Jenkins SonarQube, etc. We can also create our own Helm charts for our custom applications so that we don’t need to repeat ourselves and simplify deployments.

We can search for charts https://helm.sh/ . Charts can be pulled(downloaded) and optionally unpacked(untar).

Generally I felt as if I was diving in the deepest of waters without the correct equipement and that was horrifying. Unfortunately to me, I had to dive even deeper before getting equiped with tools like ArgoCD, and k8slens. I had to start working with... HELM.

Within the architecture of Cyclops, a central component is the Helm engine. Helm is very popular within the Kubernetes community; chances are you have already run into it. The popularity of Helm plays to Cyclops's strength because of its straightforward integration.