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

161–169 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#161

Post by glitchcrab »

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.

I use the cluster-api provider for Proxmox running in an ephemeral cluster (usually kind) to bootstrap the Kubernetes cluster to a point where Flux gets installed and it takes over managing itself. I then throw the kind cluster away as I no longer need it.

Re: Yoke: Infrastructure as code, but actually

#162

Post by chubot »

esafak wrote: post #108
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.

Yes sorry, if you install the latest oils-for-unix binary - https://oils.pub/release/latest/ - Then you will get a symlink called "ysh".

It's also available in a few distros, HomeBrew, etc.

As mentioned, the demo depends on a bug fix that hasn't been released yet. Right now there are a bunch of people on Zulip giving feedback, so you are welcome to join and ask questions / give feedback, or wait until it's more fully baked

YSH itself is pretty "baked", but the Hay part is in flux

---

I fixed the link, thank you for mentioning that!

https://www.oilshell.org/cross-ref.html?tag=YSH#YSH

Re: Yoke: Infrastructure as code, but actually

#163

Post by davidmdm91 »

empath75 wrote: post #91
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.

Writing your own operator is a lot of complexity when what you want to do is deploy a package.

Via Yoke's AirTrafficController, it's easy to define a package as a CRD and its implementation (a program that takes the CR and outputs the desired underlying resources) and the AirTrafficController takes care of the rest.

You no longer need to think about reconciler loops, figuring out any orphaned state, etc.

Re: Yoke: Infrastructure as code, but actually

#164

Post by dvektor »

Little did my guy know that he would be starting one of the more hackernews-ish arguments out there.

"is terraform code?", and despite everyone knowing exactly what he means, everyone must try to prove him wrong because he didn't choose the best example to prove his point.

Re: Yoke: Infrastructure as code, but actually

#165

Post by mdaniel »

JohnMakin wrote: post #141
stego-tech wrote: post #127

These sorts of posts are fascinating "nerd snipes" to cryptids like me. On the surface, they look incredibly interesting and I want to learn more! Terraform isn't code? Please explain to me why not, you have my attention . Then I get to the real meat of the issue, which is often along the lines of, "I'm a software developer who has to handle my own infrastructure and I hate it , because infrastructure doesn't behave…

Thanks for posting this, I favorited it - having carved out a weird niche in my career as an "infra" guy, inevitably I deal with a lot of IAC. I run into this attitude a lot by devs - they are indeed annoyed by managing infrastructure, because it innately is not like software! I know I'm reiterating what you said but it is so important to understand this. Here is a thing I run into a lot: "Our infra is brittle and be…

> I can push a terraform PR, get approved, but I won't actually know whether what I did was valid until you try to push it live

Our concession to this risk was that once a merge request was approved, the automation was free to to run the apply pipeline step, leaving open the very likely possibility that TF shit itself. However, since it wasn't actually merged yet, push fixes until TF stopped shitting itself

I'm cognizant that solution doesn't "scale," in that if you have a high throughput repo those merge requests will almost certainly clash, but it worked for us because it meant less merge request overhead (context switching). It also, obviously, leveraged the "new pushes revoke merge request approval" which I feel is good hygiene but some places are "once approved, always approved"

Re: Yoke: Infrastructure as code, but actually

#166

Post by gregmac »

JohnMakin wrote: post #144
gregmac wrote: post #126

Earlier quoted context omitted.

Having debugged this sort of thing before, it's actually really hard to figure that out. The entire stack is kind of bad at both logging and having understandable error messages. You get things like this: ╷ │ Error: googleapi: Error 400: The request has errors, badRequest │ │ with google_cloudfunctions_function.function, │ on main.tf line 46, in resource "google_cloudfunctions_function" "function": │ 46: resource "go…

The nice thing though, if you are a developer, is that most of these providers code is open source. We've had cases where we've forked providers and fixed bugs on our own before we could get something merged in. I've personally fixed several provider bugs on my own out of annoyance - terraform's just a wrapper around cloud API's, usually, and you can be in control of how that works.

Yep, agreed, and IMHO in a lot of cases, as-is, terraform wouldn't be viable as a closed-source product. At least, I would have got frustrated and ditched it.

I haven't personally found a real bug in terraform or a provider yet, but I've had to refer to the source many times to figure out what is actually happening. It's always been either misuse on my part, or drift that the provider couldn't resolve.

I still consider it a failure though if it takes looking at source code to figure out what's actually going on -- whether it's vendor or in-house. The ironic and annoying part is it usually takes a deeper level of knowledge to write better error messages, but the people with that knowledge don't have the perception of it being a problem. I fight this battle internally with my own teams all the time. The problem is not getting people to make a change, but recognizing that the message is misleading/confusing/unclear to their users (eg: developers who are not domain experts like them) in the first place.

Re: Yoke: Infrastructure as code, but actually

#167

Post by mdaniel »

strangelove026 wrote: post #148
abound wrote: post #107

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: [{ nam…

I was kind of interested in cue earlier last year as IIRC it can be served by helm and is much much better than templating yaml. Never really got started with it. Wish they had an LSP too. https://github.com/cue-lang/cue/issues/142

What the hell is going on with their bot copy-pasting every comment on that issue? What a mess

Anyway, I wanted to ask what you meant by "served by helm?" I knew about https://github.com/stefanprodan/timoni and https://github.com/holos-run/holos but I believe they are merely "inspired by helm" and not "cue for helm"

Re: Yoke: Infrastructure as code, but actually

#168

Post by mdaniel »

xena wrote: post #140
figmert wrote: post #112

Slightly related, in everything I see that allows adding secrets or env vars as code, they seem to prefer a list of objects instead of a key value pair for these. Does anyone know why this is? I know in some cases you can add additional values, but this seems easily solved by dynamically determining what the value is. I'd much rather write: env: key: value instead of env: - name: key value: value

The reason they do that is because then you can do things like extract envvar values from secrets.

Pedantically, there's nothing stopping them from doing it the way CFN does it: dispatching on the value's type:

  env:
    AWS_REGION: us-east-1
    AWS_SECRET_ACCESS_KEY:
      valueFrom: ...
CFN even goes as far as having two ways to pull off that stunt, magic prefixes and objects

  Properties:
    ImageId: !Ref MyAwesomeAmi
    # or
    ImageId:
      Ref: MyAwesomeAmi
    # or cursed "{{resolve" syntax
    ImageId: !Join
      - ''
      - - '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-'
        - Ref: EksVersion
        - '/x86_64/latest/image_id}}'
    # which ends up being "ImageId: '{{resolve:ssm:/aws/service/bottlerocket/aws-k8s-1.31/x86_64/latest/image_id}}'" and then *that* gets replaced by the CFN service at provisioning time

Re: Yoke: Infrastructure as code, but actually

#169

Post by mdaniel »

dijit wrote: post #123
Kinrany wrote: post #121

Earlier quoted context omitted.

The definitions can be declarative but generated from code

I think we need something like samurai/ninja for terraform, that would be sweeeeet

I believe you just discovered cdktf https://github.com/hashicorp/terraform-cdk#cdk-for-terraform

Also, I couldn't search for samurai in order to know if it's "jinja2 for $other_language" or what, but I just inferred that you wanted a templating language to generate terraform files

Post reply on HN