Terraform is part of a movement called “Infrastructure as Code” (IaC) which allows engineers to define their cloud infrastructure using code.
This is extremely useful as it allows you to:
version infrastructure changes
automate resource and configuration creation and management
have reproducible environments (think production and staging envs, or deploying a new production env to another datacenter)
Terraform (and OpenTofu) is different to most IaC project as it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers, where their competitors are limited to their own platform (I think of AWS’s Cloud Development Kit)
In my experience with AWS, you run into issues using terraform that CDK just doesn’t have. I’d rather have a different reliable system for each cloud environment than one system that is suboptimal for each environment. Since the providers are different, you don’t really have anything in common besides using HCL as the language anyway.
Out of curiosity, what kind of issues have you faced?
I work with aws in gov and terraform is used for everything, I’ve not encountered any issues as of yet.
The one that comes to mind is changing the security group for lambdas from an auto generated one (unspecified in terraform) to a specified one. It had some kind of chicken/egg situation so I ended up having to run two change sets - one to have both security groups set then another to remove the extra. Had to do the same thing in cdk and it just worked. There have been other similar things where everything is fine until you hit some edge case and then you’re just wasting time and money doing acrobatics to work around the quirks (that don’t exist in cdk).
I’m not in the devops group and they’re attached to TF for some reason so I don’t get a say in what we use, but I am the “everything is busted call in anyone that can help” guy so I end up dealing with the problems lol
it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers
Nicely put. I frequently see the first part of this sentence and not the second. (Maybe I only pay attention to the first part and then disappoint myself…)
Terraform/Tofu allow me to use the same basic syntax and to have one project that controls AWS/GCP/K8s/my home servers, but I cannot use it to describe “a running server process” and just deploy that on any of those places. Instead I’d need to have like aws_beanstalk_service { ... } and gcp_application { ... } and kubernetes_manifest { ... } and systemd_service { ... } and the contents of those blocks would be totally different (and I’d need a bunch of different ancillary blocks for each of those).
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.
nothing about it is common or portable, so if you change your VM host, it might all fall apart.
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 the local_file resource 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.
Infrastructure configuration that is automatically applied to the cloud infrastructure. Like starting and stopping new instances and services, changing connections between them, etc. (I assume anyway.)
Imagine a tool that gives you a language in which you can describe the hardware resources you want from a cloud provider. Say you want multiple different classes of servers with different sets of firewall rules. Something like Terraform allows you to put that into a text-based form, make changes to it, re-run the tool and expect resources to be created, changed and destroyed to match what you wrote down.
I felt completely lost. What is Terraform?
Not exactly sure what that means, but that may help someone!
Terraform is part of a movement called “Infrastructure as Code” (IaC) which allows engineers to define their cloud infrastructure using code.
This is extremely useful as it allows you to:
version infrastructure changes
automate resource and configuration creation and management
have reproducible environments (think production and staging envs, or deploying a new production env to another datacenter)
Terraform (and OpenTofu) is different to most IaC project as it is agnostic of cloud providers: you can use it to deploy infrastructure to multiple providers, where their competitors are limited to their own platform (I think of AWS’s Cloud Development Kit)
In my experience with AWS, you run into issues using terraform that CDK just doesn’t have. I’d rather have a different reliable system for each cloud environment than one system that is suboptimal for each environment. Since the providers are different, you don’t really have anything in common besides using HCL as the language anyway.
Out of curiosity, what kind of issues have you faced? I work with aws in gov and terraform is used for everything, I’ve not encountered any issues as of yet.
The one that comes to mind is changing the security group for lambdas from an auto generated one (unspecified in terraform) to a specified one. It had some kind of chicken/egg situation so I ended up having to run two change sets - one to have both security groups set then another to remove the extra. Had to do the same thing in cdk and it just worked. There have been other similar things where everything is fine until you hit some edge case and then you’re just wasting time and money doing acrobatics to work around the quirks (that don’t exist in cdk).
I’m not in the devops group and they’re attached to TF for some reason so I don’t get a say in what we use, but I am the “everything is busted call in anyone that can help” guy so I end up dealing with the problems lol
Nicely put. I frequently see the first part of this sentence and not the second. (Maybe I only pay attention to the first part and then disappoint myself…)
Terraform/Tofu allow me to use the same basic syntax and to have one project that controls AWS/GCP/K8s/my home servers, but I cannot use it to describe “a running server process” and just deploy that on any of those places. Instead I’d need to have like
aws_beanstalk_service { ... }andgcp_application { ... }andkubernetes_manifest { ... }andsystemd_service { ... }and the contents of those blocks would be totally different (and I’d need a bunch of different ancillary blocks for each of those).Thanks for the detailed comment!
It’s useful for configuring a turbo encabulator.
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.
Infrastructure configuration that is automatically applied to the cloud infrastructure. Like starting and stopping new instances and services, changing connections between them, etc. (I assume anyway.)
Imagine a tool that gives you a language in which you can describe the hardware resources you want from a cloud provider. Say you want multiple different classes of servers with different sets of firewall rules. Something like Terraform allows you to put that into a text-based form, make changes to it, re-run the tool and expect resources to be created, changed and destroyed to match what you wrote down.
It’s just a way of defining configurations
Like an .ini file.