this post was submitted on 26 Mar 2025
67 points (95.9% liked)
Programming
19764 readers
105 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Its for easily deploying virtual machines. You can specify the VM specs, give it an install disk and some instructions, and it will churn out a VM for you.
Honestly, it's not great in my experience, nothing about it is common or portable, so if you change your VM host, it might all fall apart.
It's for far more than just deploying VMs: you can create pretty much anything you can on a cloud provider, such as databases, network rules, access tokens, object storage, etc.
Yeah, but I was trying to keep the description basic, to avoid turning it into a buzzword salad.
Have you used it much? Like it? Hate it? I'm curious to know others thoughts on it.
Disclaimer, I'm pretty much elbow deep into terraform daily and have written/contributed to a few providers.
A lot of this is highly dependent upon the providers (the thing that allows the Terraform engine to interface with APIs for AWS, Proxmox, vSphere, etc. The Telmate Proxmox provider in particular is/was quite awful with not realizing a provisioned VM had moved to a new host.
Also, the default/tutorial code tends to be not very flexible. The game changer for me was using the built-in functions for decoding yaml from a config file (like
yamldecode(file(config.yml))in a locals block. You can then specify your desired infrastructure with yaml and (if you write your Terraform code correctly) you can blowout hundreds of VMs, policies, firewall rules, dns records etc with a single manifest. I've also used thelocal_fileresource with a Terraform file template to dynamically create an Ansible inventory file based on what's deployed.I was using it to deploy VMs to vsphere, and to test, started by deploying against a local KVM. Got it all working, copied the config to my prod vsphere, hoping I could just update the creds, and bunch of the KVM flags didn't work for vsphere, so I had to fix/rewrite them, which wasted a lot of time.
TF would be amazing if it was a single API that appled generically to all backends. And it sorta is for the most part, but there are just a few footguns that can really spoil the mood. If they had a core API and anything non-portable was clearly documented, that would be good as well.
Yeah, that's the other thing to keep in mind, since the KVM APIs are different from the vSphere APIs, you can't just swap providers without changes. But if you were going from a test vSphere stack to a prod, you could update the endpoint and be just fine.
Hashicorp has caught some shit in the past about claiming the code covers multiple providers. Technically, it can if you do weird shit with modules, but in reality there isn't a clean way to have a single, easily understandable project that can provision to multiple platforms.
This is absurdly wrong. To anyone reading this comment there, ignore this guy.
Which part? Thats exactly what I've used terraform for, it might not be the full capabilities of it, but its one of the main use case?