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

61–70 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#61

Post by jonasdegendt »

bbu wrote: post #37
xena wrote: post #9

Earlier quoted context omitted.

Author here. It's mainly for k8s resources; but if you install operators like external-dns or something like crossplane into your cluster, you can manage infra too.

ok, that makes sense. A better Helm would be nice. timoni.sh is getting better and better, but Cue is a big hurdle. Unfortunately, I'm not a big fan of the yaml-hell that crossplane is either. But as a Terraform replacement systeminit.com is still the strongest looking contender.

> A better Helm would be nice.

Consider CDK8s (Typescript or Go) or Jsonnet. We evaluated Cue and the two aforementioned options and ended up with CDK8s using Typescript and it's incredibly powerful.

Re: Yoke: Infrastructure as code, but actually

#62

Post by supriyo-biswas »

I feel that writing out infrastructure templates through a "proper programming language" (for the lack of a better term) comes with some sharp tradeoffs that many don't recognize.

A big feature of most IaC tools is that they are relatively logic-less and therefore can be easily understood at a glance, allowing for easier reasoning about what resources can be created, and this ability is diminished by introducing logic, and debugging issues in them becomes a nightmare. A large company I used to work for had a system just like that, and while I thankfully never had to work with said system, hearing statements like you can "debug your templates with pry[1]" being touted as a feature is something I hope to never hear again.

[1] https://github.com/pry/pry

Re: Yoke: Infrastructure as code, but actually

#63

Post by diggan »

kikimora wrote: post #43
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’ve been thinking about this for a long time. But doesn’t it brings a host of other issues? For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created? I need to make a small change, how do I know what parts of my scripts to run?

> For example, I need to update instance RAM from 4 to 8 Gb but how do I know if the instance exists or should be created?

    let front_id = if instance_exists("front_balancer") {
      return fetch_instance("front_balancer").id
    } else {
      return create_new_instance("front_balancer", front_balancer_opts).id
    }
Or however else you would manage that sort of thing in your favorite programming language.

> I need to make a small change, how do I know what parts of my scripts to run?

Either just re-run the parts you know you've changed (manually or based on git diffs), or even better, make the entire thing idempotent and you won't have to care, re-run the entire program after each change and it'll automagically work.

Re: Yoke: Infrastructure as code, but actually

#64

Post by sureglymop »

xena wrote: post #9
bbu wrote: post #7

Looks promising but it starts with a (justified) rant about terraform and then goes into how to replace Helm. I am confused. Can yoke be used to create and manage infrastructure or just k8s resources?

Author here. It's mainly for k8s resources; but if you install operators like external-dns or something like crossplane into your cluster, you can manage infra too.

What alternative to terraform would one use to set up the whole cluster before provisioning any resources?

I currently have a custom script that is a mix between terraform and ansible that sets up a proxmox cluster, then a k3s cluster and a few haproxys with keepalived on top. Granted, maybe not the most standard setup.

Re: Yoke: Infrastructure as code, but actually

#66

Post by Aeolun »

cedws wrote: post #51
WatchDog wrote: post #22

I'm quite happy with CDK[0]. My experience is only with the main AWS cloudformation based version of CDK, although there is also CDK for terraform, which supports any resource that terraform supports, although some of what I'm about to say is not applicable to that version. What I like about CDK, is that you can write real code, and it supports a wide range of languages, although typescript is the best experience. Pr…

In your experience how often have you had template builds succeed but then fail at apply time? This kind of issue is what I find most frustrating about IaC today, your 'code' 'compiling' means nothing because all of the validations are serverside, and sometimes you won't find out something's wrong until Terraform is already half done applying. I want to be able to declare my infrastructure, be able to fully validate…

I find Pulumi very nice here because it persists state after every successful resource creation. If it breaks somewhere in the middle, the next run will just pick up where it left off last time.

CDK… well, CDK doesn’t get in an invalid state often either, but that’s because it spends 30m rolling back every time something goes wrong.

Re: Yoke: Infrastructure as code, but actually

#67

Post by voidnap »

thayne wrote: post #32

> This is not code. This is configuration. I don't think those two things are mutually exclusive. IMO hcl is absolutely code. As is html, and css, json, and yaml. It isn't a full programming language, and I often wish it was, but I wouldn't say it isn't code.

JSON YAML are file formats for data. Is XML code? Is SVG code? Is a GIF code? Is a BMP code?

Re: Yoke: Infrastructure as code, but actually

#68

Post by Aeolun »

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.

Re: Yoke: Infrastructure as code, but actually

#70

Post by Aeolun »

taberiand wrote: post #44
danw1979 wrote: post #33

Earlier quoted context omitted.

Just go with plain Terraform. You can check the docs for the GCP provider to see if the resources you want to manage are "importable" into the Terraform state file; they usually are and you'll see a section at the bottom of each resources documentation page showing you how to do this. e.g. https://registry.terraform.io/providers/hashicorp/google/lat... Your process will be - 1. Write TF configuration approximating wh…

You don't need to write all the tf upfront for existing resources. Use `import` resources in a .tf file (I like to just call it imports.tf) and run `terraform plan -generate-config-out=imported.tf` That will dump the tf resources - often requires a little adjustment to the generated script, but it's a huge time saver

I used this instead of terraformer. Can agree that it’s a huge timesaver.
Post reply on HN