Oh, geeze. This is about: terraform.io
Ha! That was my first thought too. Where is the information about terraforming Mars?
Terraform Gotchas and How We Work Around Them
41–50 of 82 posts
Re: Terraform Gotchas and How We Work Around Them
#42Hey author here! Happy to answer any questions etc :-)
Have you tried Terragrunt[1]?
Re: Terraform Gotchas and How We Work Around Them
#43I absolutely can't stand how destructive terraform is by nature. We have switched to Ansible, which has an excellent AWS module, and never looked back.
Why Ansible rather than Elastic Beanstalk or Cloud Formation?
It's vendor-agnostic? And CF is super slow and limited to a small number of resources (not sure if it's a 100 or a 1000).
Re: Terraform Gotchas and How We Work Around Them
#44I thought terragrunt was a must have for that kind of deployment.
I'm curious about that as well. I was told by coworkers that Hashicorp added support for DynamoDB which rendered terragrunt redundant but I haven't had time to look into it.
terraform {
backend "s3" {
region = "us-west-1"
bucket = "foo-tf-us-west-1"
key = "foobar.tfstate"
dynamodb_table = "tf-lock"
}
https://www.terraform.io/docs/backends/types/s3.html#dynamod...
Re: Terraform Gotchas and How We Work Around Them
#45Terraform has interested me for a while, and I've been meaning to give it a try, but haven't had a chance just yet. From what I have seen so far though, there isn't really that much difference/benefit over CloudFormation. We currently have 95% of our resources in AWS with about 4% in Azure, and 1% in Google Cloud. It's great that Terraform is 'mulit-cloud' but it still seems like you have to write .tf's catered to ea…
Here's a real-world benefit I had over the weekend. I've been using Terraform for a Google Cloud project, and was coming to setting up DNS records. I wanted to have dual DNS providers for redundancy. With Terraform, it was trivial, as I just added a second Terraform resource for DNSimple (with Google Cloud DNS as my 'main' DNS resource).
The beauty of Terraform is that you can orchestrate all of your infrastructure, not just the stuff in one stack. If you've got 95%/4%/1% in AWS/Azure/GCP, how do you manage/reference the non-AWS resources? Terraform gives you a unified way to reference and link cross-infrastructure resources.
Re: Terraform Gotchas and How We Work Around Them
#46There's another similar issue with how EC2 security group rules are encoded: you can encode them either as ingress/egress stanzas on an "aws_security_group" resource, or you can attach rules to a security group resource with separate "aws_security_group_rule". You can't mix the two approaches on a single security group resource. We adopted the ingress/egress stanza on security group resource approach. If we ever want…
Hey there. Disclaimer: one of the creators of Terraform
I wanted to apologize that this is super confusing. All the scenarios where this exists (there are many) are historical. We originally went with the "nested" approach and now prefer the "split" approach for good reasons shown to us by users. But we kept both for backwards compatibility reasons. We have no good mechanism to enforce a migration at the moment. There are a couple ways we can resolve this technically in the future. For now, we should probably make sure the docs are annotated in all situations of the limitations of nested vs. standalone. I'll mention this to the team!
Re: Terraform Gotchas and How We Work Around Them
#47Earlier quoted context omitted.
Oh interesting. Note to self: see if there's an option to disable `terraform apply` without a plan. I always refresh when running the pre-apply plan, but while iterating I use that. Do you always run your `tffreshplan` command before applying?
Agree would be nice to add a new option which prevents invoking `apply` without a supplied plan argument. Create an issue in the GitHub, I'll upvote.
My muscle memory for "terraform apply" was too strong, so I just moved "terraform" out of my path altogether. Now I have a wrapper that invokes it safely (or a Makefile, depending on which project I'm working on).
Re: Terraform Gotchas and How We Work Around Them
#48Terraform has interested me for a while, and I've been meaning to give it a try, but haven't had a chance just yet. From what I have seen so far though, there isn't really that much difference/benefit over CloudFormation. We currently have 95% of our resources in AWS with about 4% in Azure, and 1% in Google Cloud. It's great that Terraform is 'mulit-cloud' but it still seems like you have to write .tf's catered to ea…
CloudFormation's approach for post-provisioning deployments is much more limited than the options that Terraform provides as first-class citizens. For example, there's a Chef provisioner as well as local-exec and remote-exec. With CloudFormation, the only options exist in the form of cloud-init that uses userdata.
However, this isn't to say that Terraform is always better than CloudFormation. In fact, I'd prefer to use CloudFormation for A/B | Blue-Green deploys because it supports UpdatePolicy options for rotating newly configured images into an autoscaling group. The logic to do that in Terraform is really not trivial at all (there is no clean, straightforward way to do such deployments with Terraform). Furthermore, rollbacks are significantly more reliable in my experience using CloudFormation than Terraform. Rollbacks may be easier to orchestrate using Terraform than CloudFormation though due to easier reference to non-AWS resources.
My preferred style of AWS deployments and infrastructure-as-code layering is Terraform with broken out modules and generating smaller CloudFormation templates for individual application components that need to be deployed often. This seems like a worst-of-both-worlds option but I think keeping CloudFormation templates constrained to just ASG modifications avoids a lot of the problems.
Re: Terraform Gotchas and How We Work Around Them
#49Re: Terraform Gotchas and How We Work Around Them
#50Terraform has interested me for a while, and I've been meaning to give it a try, but haven't had a chance just yet. From what I have seen so far though, there isn't really that much difference/benefit over CloudFormation. We currently have 95% of our resources in AWS with about 4% in Azure, and 1% in Google Cloud. It's great that Terraform is 'mulit-cloud' but it still seems like you have to write .tf's catered to ea…
I've been thru the CFN v TF question. We came up with a list of benefits of TF over CFN. (Yes, I know - one-sided, but we wanted to document the decision with a bit more substance than "oh it's just better")
* Ability to separate data (variables/parameters) from configs.
* Easier to read (well at least pre-YAML CFN).
* Allows comments in the code.
* Version control changes (diffs) are easier to read.
* Multi-Cloud support. Works against AWS, Google Compute, Azure, Docker, more.
* Multi-provider in general: can provision resources across multiple different cloud providers at once.
* Can write modules in TF that can be reused in multiple different configs.
* Tracks state via a version-controllable data file.
* 'terraform plan' is essentially a no-op mode to see what changes would occur without actual running or making changes.
* Actively developed.