7 ms·
I personally feel HCL (or any specific thing) is a large disadvantage for any orchestration platform. Kubernetes is an API for infrastructure. This is why it us
by gravypod 6y ago
I personally feel HCL (or any specific thing) is a large disadvantage for any orchestration platform. Kubernetes is an API for infrastructure. This is why it uses json/yaml. It doesn't mean your configuration should use json/yaml natively.
You can easily write tools that generate json/yaml for you based on your needs. For most applications you're deploying you'll need:
1. A Deployment
2. A Service that points to that Deployment
3. An Ingress or similar
In some cases you'll want to manage persistent state on disk and you'll need a StatefulSet.
A good example of this can be seen https://youtu.be/keT8ixRS6Fk?t=1317 https://youtu.be/keT8ixRS6Fk?t=1317 and https://youtu.be/muvU1DYrY0w?t=581 https://youtu.be/muvU1DYrY0w?t=581
- okso 6y agoHCL is JSON compatible, and Nomad can load JSON natively.
- mrkurt 6y agoIt can only load json with the api, the nomad CLI can't launch json jobs.
- core-questions 6y agoBut who would use the Nomad CLI for serious work? I use the Terraform provider for Nomad to launch all my jobs.
- mrkurt 6y agoMe? It's handy to be able to dump -> modify -> load jobs when I'm poking at things. No one said anything about serious work, though, they said "load json natively".
- AnxiousCoward 6y agoYou may not use it for automation. But you usually do much exploratory work before doing the automation. That's where the various CLIs for all kinds of things come in really handy.
- hedwall 6y agoYes it can. "For machine-friendliness, Nomad can also read JSON-equivalent configurations. In general, we recommend using the HCL syntax." https://www.nomadproject.io/docs/job-specification#job-specification https://www.nomadproject.io/docs/job-specification#job-speci...
- gravypod 6y agoI assumed that was a possibility but that still means "HCL" isn't a benefit since kubectl can load json from the CLI and from apiserver.
- xyzzy_plugh 6y agoA thousand times this. With Kubernetes, you can even use one of the many native clients (and/or protobuf) which makes converting from something else a breeze, avoiding the JSON/YAML entirely. You get static typing, you can write tests, etc.
- sofixa 6y agoWell, it's same thing with Nomad - there are native SDKs, protobuf and a classical JSON REST API for everything.
- sofixa 6y ago> You can easily write tools that generate json/yaml for you based on your needs. For most applications you're deploying you'll need: Can you with yaml? Helm tries, but isn't that great, jinja ( depending on how its done ( jinja in yaml as in ansible or jinja to yaml as in SaltStack)) does an ok job, but fundamentally managing a language which uses spaces for logic with code is hard, and certainly YAML wasn't created to be managed that way. JSON i agree, you can easily convert your language of choice's data structures to it. But do you have to? It adds another layer of complexity, and you can have unexpected bugs ( since you have a logic layer that creates JSON, which could be wrong due to a logical error). HCL is a DSL that needs learning and few use outside of Hashicorp products, but IMHO it's not that hard ( docs are great, tutorials are plenty) and it's worthwhile to have data+logic in the same human and machine readable layer. In any case, Nomad accepts JSON for everything ( mostly for when non-humans interact with it).
- gravypod 6y agoHelm, in my personal opinion, is one of the biggest mistakes of the kubernetes ecosystem. Not embracing Jsonnet, Cue, Dhall, or even an in-language DSL like Pulumi has set the usability of kube back quite far.
- jpgvm 6y ago$DAY_JOB replaced helm with custom tool that does equivalent of kubectl apply by uses Jsonnet as templating engine. I intend to write an OSS version of it because Jsonnet really is probably the best fit here (though Cue/Dhall are interesting I think Jsonnet is easiest to get others to adopt).
- gravypod 6y agoI've done the same in the past. The important thing is making it so it's easy to build up abstractions and to work in a sensible deployment flow. kubectl is close but doesn't understand secrets/variables, the concept of clusters, or changing image tags programmatically. It's difficult to get right.
- nunez 6y agoUnless you start messing with Operators (which are hot right now) for desired state configuration within your cluster, which can, theoretically, be written in anything, but realistically tend to be written in Golang.
- gravypod 6y agoYep, exactly. KubeDB is a great example of this.
- tutfbhuf 6y agoI think operators are great and true to the k8s spirit. You describe your desired state (e.g. a postgres database) according to a CRD. And the operator will make your yaml definition become reality. I think the declarative approach is a big improvement over the imperative step-by-step setup. I rather like to describe how I would like things to be, instead of having to create the desired state myself.
- nunez 6y agoTo be clear: I like operators! I was just responding to the parent post; JSON/YAML aren’t the only ways to express things in the Kubeverse.
- AnxiousCoward 6y agoMay be. But operators are a relative pain to develop. I prefer the HCL approach. You can have modules instead of operators, and while HCL overall might be painful, it's less painful, IMO, than constantly changing operators. My team spends a significant amount of time chasing deprecations of operators and associated helm charts.
- darthrupert 6y agoHCL alone is a good reason to prefer Nomad over any YAML mess that exists.