41–50 of 239 posts
On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk
My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform
In my opinion if you're doing manual fixes you're doing it wrong. Let's say you do your manual fix in your Dev environment. Do you remember to do it in Prod/whatever other environments you have? Are you sure you did the EXACT same thing? Did you change 5 other things trying to fix it first?
You end up with so many different deployment environments that are unique 'snowflakes', and when something breaks in one it might not affect the others cause they're in totally different states.
It's a nightmare.
In my opinion, infrastructure as code is the only way to do it in a serious environment.
Earlier quoted context omitted.
I'm one of the HashiCorp founders. Terraform 0.11 to 0.12 is by far the most difficult of the versions to upgrade between. I am really sorry about that. The other upgrades should be relatively minor as long as you read and follow the upgrade guides and upgrade one minor version at a time (0.11 => .12 => .13 etc.). There are rough edges for very specific cases but most of our customers were able to upgrade from 0.12 t…
Thanks, good to know that the upgrade to 12 is the biggest jump.
Perhaps off-topic but how have people upgraded TF codebases to new versions? Just last year we had a big effort to upgrade a huge code-base from 0.11 to 0.12. I feel like it should be a lot smoother than a full-team full-sprint effort.
0.12 -> 0.13: Well, we had to add what feels like a million required-provider-blocks and then some more. And sometimes it was tricky to pinpoint the module pulling in a default provider and crashing - `terraform providers` and `terraform graph` help there. The graph is easy to grep through to find the resources and modules pulling in wrong providers. And in the beginning the error message we got when we had to run 'terraform state upgrade-providers' was .. obscure. In newer versions, that message is much better.
0.13 -> 0.14 just happened and now the lock files are slowly piling in on demand.
My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform
Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The question you have is, how do you programmatically keep a copy of that state on your side of the API? The naive approach that tries to do this without state in code goes something like: a) invoke the remote API to look for something that should exist b) if it doe…
I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the existing resources we already have... every time I run a playbook I know that everything will end up just like I want it to be. Not bad for a naive approach I guess.
On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk
Are all variables, conditionals, templating, and loops done in Python? Or is some of that still needed on the Terraform side?
Earlier quoted context omitted.
I'm one of the HashiCorp founders. Terraform 0.11 to 0.12 is by far the most difficult of the versions to upgrade between. I am really sorry about that. The other upgrades should be relatively minor as long as you read and follow the upgrade guides and upgrade one minor version at a time (0.11 => .12 => .13 etc.). There are rough edges for very specific cases but most of our customers were able to upgrade from 0.12 t…
Our teams have something like 100,000 LOC in Terraform 0.12, and it's not all in one big monorepo. At that scale there is no such thing as a relatively minor version upgrade. We want to upgrade to get away from some persistent 0.12 bugs, but we literally don't have the time. We have to change all of the code, and then test every single project that uses that code in non-prod, and pray that the testing finds most of t…
Earlier quoted context omitted.
Our teams have something like 100,000 LOC in Terraform 0.12, and it's not all in one big monorepo. At that scale there is no such thing as a relatively minor version upgrade. We want to upgrade to get away from some persistent 0.12 bugs, but we literally don't have the time. We have to change all of the code, and then test every single project that uses that code in non-prod, and pray that the testing finds most of t…
Yeah same boat. We ended up doing several complete rewrites and finally giving up. My main grievance is hcl, it’s so close but so far from an actual programming language that it drives me mad, even after a few kilolines of it in prod.. we ended up going with pulumi which so far has served us well
I think both are a great idea as the DSL has given me so many headaches over the years.
Earlier quoted context omitted.
Between rbenv, tfenv, pyenv, sdkman and so on and so forth, maybe it's time for some sort of common OS-level env-management interface...?
Maybe asdf? https://github.com/asdf-vm/asdf
Earlier quoted context omitted.
Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The question you have is, how do you programmatically keep a copy of that state on your side of the API? The naive approach that tries to do this without state in code goes something like: a) invoke the remote API to look for something that should exist b) if it doe…
Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the exist…
Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate.
Ansible is more of a configuration management right?