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

91–100 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#91

Post by empath75 »

INTPenis wrote: post #76

Who are these ops people that want to write golang and rust? It seems like a tiny niche. If you're that comfortable writing golang or rust then why not just become a developer? I'm a lifelong ops person, since 2000, and I use Ansible or Terraform daily. I often wanted to learn golang better but I just never had the motivation. I'm a mean Python scripter, I can write a system integration in hours, but there's somethin…

I've written a bunch of k8s operators in go (and rust more recently). That's how basically everyone working with k8s does once you reach a certain level of complexity.

I don't really understand, in fact, why you'd use yoke instead of just writing an operator with kubebuilder or kube-rs.

Re: Yoke: Infrastructure as code, but actually

#92

Post by empath75 »

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.

You absolutely can.

https://www.crossplane.io/

I'm managing a few dozen cloud accounts on azure and aws with nothing but crossplane and a very small terraform script that bootstraps the control plane account.

Re: Yoke: Infrastructure as code, but actually

#93

Post by e12e »

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.

I've considered dropping terraform (openTofu) for our k8s resources since k8s is stateful anyway.

But that would complicate synchronization with resources outside of k8s, like tailscale, DNS, managed databases, cloud storage (S3 compatible) - and even mapping k8s ingress to load_balancer and external DNS.

So far I feel that everything in terraform is the most simple and reasonable solution - mostly because everything can be handled by a single tool and language.

Re: Yoke: Infrastructure as code, but actually

#94

Post by e12e »

sureglymop wrote: post #64
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.

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.

Do you have a complex Ansible setup? For the few bespoke VMs I need, I've been able to get away with cloud init so far - but they're explicitly set up to be reasonable to nuke and recreate - if they had more personality and needed to be more managed as pets - I would probably need to reach for something like Ansible - or see if I could build images (vm or Docker).

But then with images I'm on the hook for patching... Not simply auto-patching via apt...

Re: Yoke: Infrastructure as code, but actually

#95

Post by chuckadams »

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…

My main problem with CDK is that it only outputs a CloudFormation stack. I can sign up for a new cloud account, spin up a k8s cluster, deploy everything to it, and restore the database snapshot faster than CF will finish a job that's stuck on UPDATE_CLEANUP_IN_PROGRESS.

Of course there's also cdk8s, but I'll probably go with Pulumi instead if I need that. Right now I'm happy with helmfile, though not so much with helm itself. So I'll definitely be giving Yoke a look.

Re: Yoke: Infrastructure as code, but actually

#96

Post by evantbyrne »

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.

Re: Yoke: Infrastructure as code, but actually

#97

Post by [deleted] »

ForTheKidz wrote: post #85
INTPenis wrote: post #76

Who are these ops people that want to write golang and rust? It seems like a tiny niche. If you're that comfortable writing golang or rust then why not just become a developer? I'm a lifelong ops person, since 2000, and I use Ansible or Terraform daily. I often wanted to learn golang better but I just never had the motivation. I'm a mean Python scripter, I can write a system integration in hours, but there's somethin…

I don't really see a distinction between developer and ops person in this context. The whole point of all of these tools is to make infrastructure into code. Go isn't the choice I would have made but it's fine.

[deleted]

Re: Yoke: Infrastructure as code, but actually

#98

Post by e12e »

jonasdegendt wrote: post #61
bbu wrote: post #37

Earlier quoted context omitted.

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.

Hm... CDK8s just helps herding k8s yaml, nothing else?

There's nothing like terraform plan/apply?

I mean - some help wrangling yaml is welcome - but I already get (some) help from terraform with the k8s provider there...

Do you check in the generated yaml in git, or just the typescript code?

https://cdk8s.io/docs/latest/get-started/typescript/

Re: Yoke: Infrastructure as code, but actually

#99

Post by tekla »

kacesensitive wrote: post #55
taberiand wrote: post #53

Earlier quoted context omitted.

The point is terraform can do it, and it does it well. Just because you don't want to use Terraform properly doesn't mean it's bad at what it does. Using "a real programming language" to do the infra still has to solve the same issues faced by terraform. Using a programming language to define infra doesn't solve the auto scaling DNS issue, for example, you'll be using lambdas to create the dns either way. It also doe…

The core issue isn't whether Terraform can do it—it's how it does it. You're describing a workflow that requires multiple state files, external tools like Terragrunt, and sequential terraform apply runs to work around the fact that Terraform itself lacks imperative, runtime-driven logic. That’s not "using Terraform properly"—that’s compensating for its limitations. And sure, using a general-purpose language doesn’t m…

Yes, if you use your tools poorly, it will turn out badly.

I run infra that has dynamic scaling provisioned via Terraform. Guess what, we auto-scale from hundreds to thousands of boxes a day dynamically managed through TF and we have had no issues, since we bothered to figure out how to do it properly.

Re: Yoke: Infrastructure as code, but actually

#100

Post by [deleted] »

kacesensitive wrote: post #49
taberiand wrote: post #48

Earlier quoted context omitted.

You can't do it if you have the instances created with auto-scaling groups of course. But nobody would think you could, that's runtime not infra. With Terraform you are supposed to have multiple coupled state files, with a tree structure of references, so that eg the state file containing the DNS can reference the previously applied state file that created the instances You are supposed to run terraform apply in a se…

At that point, you’re conceding the exact limitation I was pointing out. Terraform can't handle truly dynamic infrastructure changes within a single plan because its execution model is declarative, not imperative. Saying "nobody would think you could" just acknowledges that Terraform lacks the flexibility of real code—because if it were actual code, you'd be able to handle this inline rather than orchestrating multip…

[deleted]
Post reply on HN