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

131–140 of 169 posts

Re: Yoke: Infrastructure as code, but actually

#131

Post by anonfordays »

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…

>It's almost certainly because I come from the Enterprise Tech world rather than Software Dev world, where the default state of infrastructure is permanent and mutable, forever. Modern devs, who (rightly!) like immutable containers and block storage and build tools to support these deployments by default, just don't get why the Enterprise tech stack is so much more different

This is generally true, but the interesting thing about Terraform is it was created specifically to work in the world of "immutable by default." This is why Terraform automatically creates and destroys instead of mutating in many (most?) cases, shys away from using provisioners to mutate resources after creation, etc.

Re: Yoke: Infrastructure as code, but actually

#132

Post by stego-tech »

anonfordays wrote: post #131
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…

>It's almost certainly because I come from the Enterprise Tech world rather than Software Dev world, where the default state of infrastructure is permanent and mutable, forever. Modern devs, who (rightly!) like immutable containers and block storage and build tools to support these deployments by default, just don't get why the Enterprise tech stack is so much more different This is generally true, but the interestin…

Yep, and that's why I only very recently picked it up in Enterprise world, where the AWS team used it to deploy resources. What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time Terraform (or whatever fork they're now using post-Hashicorp) updates/changes, because Enterprise architecture is mutable by default and cannot simply be torn down and replaced.

Re: Yoke: Infrastructure as code, but actually

#133

Post by throwanem »

stego-tech wrote: post #130
ctrlp wrote: post #129

Earlier quoted context omitted.

what sort of cryptid are you?

As the username implies, the "dinosaur on the internet" kind. The classic trope of the IT person who live(d) in their windowless cave, surrounded by a cacophony of whirling fans and grinding hard drives, retired kit repurposed into a lab since the budget never allowed for a proper one. Graphic tees and blue jeans, an enigmatic mystery to the masses who complain stuff is broken but also that they don't know why I'm he…

I miss that kind of work.

Re: Yoke: Infrastructure as code, but actually

#134

Post by inopinatus »

plmpsu wrote: post #5
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.

How are you handling creating multiple resources in parallel? or rolling back changes after an unsuccessful run?

A very small shell script.

Re: Yoke: Infrastructure as code, but actually

#136

Post by nosefrog »

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…

Reminds me of gcl (yikes).

Re: Yoke: Infrastructure as code, but actually

#138

Post by ctrlp »

stego-tech wrote: post #130
ctrlp wrote: post #129

Earlier quoted context omitted.

what sort of cryptid are you?

As the username implies, the "dinosaur on the internet" kind. The classic trope of the IT person who live(d) in their windowless cave, surrounded by a cacophony of whirling fans and grinding hard drives, retired kit repurposed into a lab since the budget never allowed for a proper one. Graphic tees and blue jeans, an enigmatic mystery to the masses who complain stuff is broken but also that they don't know why I'm he…

the stegotech, a mythical beast that, unlike the BOFH, will not bite the hand that submits a support ticket

Re: Yoke: Infrastructure as code, but actually

#139

Post by kikimora »

diggan wrote: post #63
kikimora wrote: post #43

Earlier quoted context omitted.

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 chan…

I get the idea but I don't think it addresses the issue. There has to be a function that a) checks if instance exists b) checks if instance state is what I want (e.g. it has 8 GB ram) c) if not it updates the instance. Ideally it also locks environment while doing this to prevent race conditions. It can be written but seems to be quite cumbersome. Complexity of this code and also time it takes to run it what concerns me most.

I guess this is why terraform state is there. IMHO state is IaaC biggest weakness because you have to keep it consistent with actual cloud state. If we can just query state from the cloud and make it performant + be able to automatically (or just fast enough) select resources to be update it would be ideal.

Re: Yoke: Infrastructure as code, but actually

#140

Post by xena »

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.
Post reply on HN