41–50 of 70 posts
You can version the Terraform configuration, either in a public Git repository or in a Cloud Storage bucket. Use Object Versioning to version configurations in a storage bucket.
https://cloud.google.com/infrastructure-manager/docs/overvie...
I’m sure there’s some 100% subjective, hallucinated value statement but never felt a reason to bother.
I’ve only ever used an AWS SDK and “saved state” to git in the form of my SDK scripts.
Switched from Python+boto to Go+SDK a few years ago rather than learn some DSL the Lindy effect clock was ticking on.
Can anyone explain the point of TF? I’m sure there’s some 100% subjective, hallucinated value statement but never felt a reason to bother. I’ve only ever used an AWS SDK and “saved state” to git in the form of my SDK scripts. Switched from Python+boto to Go+SDK a few years ago rather than learn some DSL the Lindy effect clock was ticking on.
- the problem: if something gets deleted, or if you make a bunch of changes and want to undo them, or if you need to make a change to a lot of stuff at once, or if you want to copy what you've built to a new region, how do you do it? or, if you're on a team, how do you as a team make and track changes to your cloud infrastructure?
- terraform as a solution: you describe your cloud infrastructure as yaml files. terraform can figure out what is different between what's in your cloud infrastructure and what your yaml files say it should look like. and, it can make changes to your cloud to e.g. build it from scratch, make wide-ranging changes, make a copy of it, etc.
- since your yaml files are code, you can also create a repo and do PRs to make and track changes to your cloud infrastructure as it evolves over time
Earlier quoted context omitted.
In my experience, running a plan is much less likely to catch a bad value than the AWS provider. Subjectively, the AWS provider will at least validate that fields have valid values during the plan step. The Google provider doesn't seem to validate actual values until apply, and then you get a failure
I can’t help but feel… sad about this. I only recently picked up Terraform and am astounded that this is what goes as coding in the infrastructure world. I was coming from Ansible so there was only improvement to be had, but man did Terraform let me down so far. It (well, the provider) doesn’t validate fields until apply. That’s just so… sad. How is that acceptable? It’s like a car without a steering wheel, and peopl…
Can anyone explain the point of TF? I’m sure there’s some 100% subjective, hallucinated value statement but never felt a reason to bother. I’ve only ever used an AWS SDK and “saved state” to git in the form of my SDK scripts. Switched from Python+boto to Go+SDK a few years ago rather than learn some DSL the Lindy effect clock was ticking on.
- the situation: you build cloud infrastructure via CLI or console - the problem: if something gets deleted, or if you make a bunch of changes and want to undo them, or if you need to make a change to a lot of stuff at once, or if you want to copy what you've built to a new region, how do you do it? or, if you're on a team, how do you as a team make and track changes to your cloud infrastructure? - terraform as a sol…
Is there anything particularly painful about working with the Google Cloud Terraform provider? If there isn't, I would rather use OpenTF with that provider and manage state myself.
I was really hoping this would come with rollback support for deployments. That, to me, would be the big advantage of having gcp manage the tfstate. It doesn’t look like that’s currently supported, but maybe that’s coming in the future.
Earlier quoted context omitted.
Why would you assume that there is no license in place for this?
They may well do, but to be honest my fundamental point extends beyond just Google. Hashicorp benefits extensively from third parties maintaining their own providers.
Earlier quoted context omitted.
I haven't used Cloudformation in three years, how's it doing these days?
I see a roughly even split of people using CFn, Terraform and (Python) CDK. AWS shot themselves in the foot by making the Python version of CDK second-tier after Typescript; IaC is still done by DevOps people far more often than application people, and DevOps people use Python. Another gripe is the number of services and new features which launch without CFn support, which also blocks CDK support; when Terraform supp…
What? It's not second-tier at all, every single feature in Python is in sync with TypeScript, the library versions are in sync, and the docs for all the languages are auto-generated. They're not second-tier, they're 100% single tier.
Wonder if they have to pay licensing fees to hashicorp for using terraform this way. It’s essentially replacing terraform cloud for GCP resources.
Which is why it's all the more puzzling Google didn't spring for OpenTF here. They single-handedly could have proven it as the fork of choice but instead they're paying into HashiCorp's bad decision?