Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yoke: Infrastructure as code, but actually

xeiaso.net

Post reply on HN
Print view View original

101–110 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#101

Post by bbkane »

Kinrany wrote: post #75
sepositus wrote: post #8

From the website: > New tools like CUE, jsonnette, PKL, and others have emerged to address some of the short comings of raw YAML configuration and templating. Inspiring new K8s package managers such as timoni. However it is yoke’s stance that these tools will always fall short of the safety, flexibility and power of building your packages from code. The never-ending debate continues between configuration languages an…

It will once traditional languages are good enough

I disagree - I think there are fundamental tradeoffs between declarative and imperative ways of configuration so they'll never "converge" completely.

I am a huge fan of each camp stealing ideas from the other and thus "converging" closer.

I also like the two-step "write imperative code to generate declarative config" approach some systems take - Terraform/Pilumi do this. At the cost of having two steps, you get to write your for loops AND get a declarative "state" you can diff easily with the previous state.

Re: Yoke: Infrastructure as code, but actually

#102

Post by dijksterhuis »

evantbyrne wrote: post #96
voidfunc wrote: post #4

I ditched Terraform years ago and just interact with the raw cloud provider SDKs now. It's much easier to long-term evolve actual code and deal with weird edgecases that come up when you're not in beholden to the straight jacket that is configuration masquerading as code. Oh yea, and we can write tests for all that provisioning logic too.

I went through the same evolution, even built a PaaS for AWS, but I kept going and now just deploy my own stuff to VMs with Swarm via one command in Rove. It's great. And yes I know kubernetes I use it at work. It's an unnecessary waste of time.

> Swarm

docker swarm is so simple and easy compared to the utter behemoth that is k8s, and basically is all you need for CRUD webapps 80-90% of the time. add an RDS instance and you’re set.

i will always pick swarm in a small company* whenever possible until k8s or ECS makes sense because something has changed and it’s needed.

dont start with complexity.

* - bigger companies have different needs.

Re: Yoke: Infrastructure as code, but actually

#103

Post by chuckadams »

Aeolun wrote: post #65

Why is someone talking about infrastructure as code one moment, and then kubernetes manifests the next. The two are not the same. You can’t replace what Terraform or Pulumi does with kubernetes manifests.

IaC doesn't mean your infrastructure config has to be code, it means you manage your infrastructure config like code. As in version control, PRs, tests, that sort of thing. How much of it is Turing complete is up to you.

Re: Yoke: Infrastructure as code, but actually

#105

Post by dijksterhuis »

Aeolun wrote: post #68
akdor1154 wrote: post #58

Hill I will die on: Terraform being less expressive than a real language is a feature, not a drawback. CDK/Pulumi/Yoke is optimised for being easy to write, but code should be optimised to be easy to READ. Sure, cdk/pulumi/yoke lets you write the most clever and succinct construction you can compose in your favourite language.. however, whoever comes across your clever code next will probably want to hit you, especia…

> code should be optimised to be easy to READ You say that as if it’s impossible to write clear code. As soon as you have any form of multiple resources (e.g. create x of y) I’ll take the real programming language over terraform.

> As soon as you have any form of multiple resources

terraform handles this with for_each. need 10 EBS volumes on 10 EC2 instances? for_each and link instance id of the each value. done. theres a bunch of stuff i now don’t have to worry about (does the instance actually exist yet? other validation edge cases?)

https://developer.hashicorp.com/terraform/language/meta-argu...

> You say that as if it’s impossible to write clear code.

not the parent, but i feel their usage of the word “code” was in error. i don’t care about how, i care about what.

the HCL is purely a defintion/description of what the infrastructure looks like. what resources will be created? that is all it is. i want that. to define the infra and move on. i don’t want low level control of every minutia to do with infrastructure. i want to read a config file and just know what resources will exist in the account. wanna know every resource that exists? `terraform state list` … job done. no reading code required.

HCL/terraform is to define my cloud resources, not to control them or their creation. if i want control, then i need to whip out some go/python.

that’s my vibe on CDK libraries/platform APIs versus terraform.

Re: Yoke: Infrastructure as code, but actually

#106

Post by Spivak »

Aeolun wrote: post #68
akdor1154 wrote: post #58

Hill I will die on: Terraform being less expressive than a real language is a feature, not a drawback. CDK/Pulumi/Yoke is optimised for being easy to write, but code should be optimised to be easy to READ. Sure, cdk/pulumi/yoke lets you write the most clever and succinct construction you can compose in your favourite language.. however, whoever comes across your clever code next will probably want to hit you, especia…

> code should be optimised to be easy to READ You say that as if it’s impossible to write clear code. As soon as you have any form of multiple resources (e.g. create x of y) I’ll take the real programming language over terraform.

You can understand every single terraform codebase using nothing other than the terraform documentation itself. All abstractions are provided by the language itself.

Clear isn't really the word I would call it, more that the real work being done is exposed and always visible.

Re: Yoke: Infrastructure as code, but actually

#107

Post by abound »

I think I've commented this elsewhere, but using Cue [1] is also great for this purpose, with no extra infrastructure. E.g. you define a Cue Template [2], which seems analogous to Yoke/ATC's CRDs, and then your definitions just include the data.

Here's an example of Vaultwarden running on my K8s cluster:

    deployment: bitwarden: {
      spec: {
       template: {
        spec: {
         containers: [{
          image: "vaultwarden/server:1.32.7"
          env: [{
           name:  "ROCKET_PORT"
           value: "8080"
          }, {
           name: "ADMIN_TOKEN"
           valueFrom: secretKeyRef: {
            name: "bitwarden-secrets"
            key:  "ADMIN_TOKEN"
           }
          }]
          volumeMounts: [{
           name:      "data"
           mountPath: "/data"
           subPath:   "bitwarden"
          }]
          ports: [{
           containerPort: 8080
           name:          "web"
          }]
         }]
         volumes: [{
          name: "data"
          persistentVolumeClaim: claimName: "local-pvc"
         }]
        }
       }
      }
     }
And simpler services are, well, even simpler:

    deployment: myapp: spec: template: spec: containers: [{
      ports: [{
       containerPort: 8080
       name:          "web"
      }]
     }]
And with Cue, you get strongly typed values for everything, and can add tighter constraints as well. This expands to the relevant YAML resources (Services, Deployments, etc), which then get applied to the cluster. The nice thing of this approach is that the cluster doesn't need to know anything about how you manage your resources.

[1] https://cuelang.org/

[2] https://cuelang.org/docs/tour/types/templates/

Re: Yoke: Infrastructure as code, but actually

#108

Post by esafak »

chubot wrote: post #42

This is not code. This is configuration. FWIW we've been working on letting you declare data in YSH, a new Unix shell. So you can arbitrarily interleave code and data, with the same syntax. The config dialect is called "Hay" - Hay Ain't YAML. Here's a demo based on this example: https://github.com/oils-for-unix/blog-code/blob/main/hay/iac... It looks almost the same as HCL (although I think this was convergent evolut…

Where is YSH? Is it built into the oil shell? The YSH link in https://www.oilshell.org/cross-ref.html#YSH is broken.

Re: Yoke: Infrastructure as code, but actually

#109

Post by adamgordonbell »

I'm very much onboard with the 'hey, code is useful' idea. Code is most useful when you want to build abstractions around infrastructure.

You can do declarative code most of the time but bust out function calls and control flow and even more heavy weight abstractions when needed. And you get all that nice typechecking that speeds things up.

This is basically why I joined Pulumi and why I joined Earthly before that. ( CI needs to move beyond YAML as well).

Where I disagree is that Pulumi ( or CDK or CDKTF) running the language runtime of the language you've decided to use is a problem.

Re: Yoke: Infrastructure as code, but actually

#110

Post by SOLAR_FIELDS »

solatic wrote: post #90
ljm wrote: post #89

Earlier quoted context omitted.

K8S is at a point now where I'd probably try to configure whatever I can inside the cluster as an operator or controller. There are going to be situations where that isn't practical, but the ability to describe all the pieces of your infra as a CRD is quite nice and it takes some pain out of having things split between terraform/pulumi/cdk and yaml. At that point, you're just running your own little cloud instead of…

Sure, but the Kubernetes cluster itself, plus its foundational extra controllers (e.g. FluxCD) are basically static and therefore should be configured in Terraform.

That’s only true if you go with an architecture that involves doing so in terraform. A common pattern I implement is an initial management cluster bootstrap that runs Argo then after that it’s possible to manage everything, including cluster components of “child” clusters, using Argo. Can use either cluster api provider or cross plane for that, or one of the cloud specific ones like ack.

One single imperative helm install command to start the whole train rolling then after that it’s all IaC

Post reply on HN