So... ahem what other idiots came here expecting a post about troubleshooting Martian habitability? ::Sulks off dejectedly::
At least one :)
at least two :)
Terraform Gotchas and How We Work Around Them
11–20 of 82 posts
Re: Terraform Gotchas and How We Work Around Them
#12So... ahem what other idiots came here expecting a post about troubleshooting Martian habitability? ::Sulks off dejectedly::
Now that project would be cool to see.
Re: Terraform Gotchas and How We Work Around Them
#13>Terraform state surgery
Did you try to use `terraform state mv`? I've found that command useful (albeit for much less than thousands of resources).
Re: Terraform Gotchas and How We Work Around Them
#14So... ahem what other idiots came here expecting a post about troubleshooting Martian habitability? ::Sulks off dejectedly::
Wikipedia has a decent article if you've never read it: https://en.wikipedia.org/wiki/Terraforming_of_Mars#Challenge...
Re: Terraform Gotchas and How We Work Around Them
#15Earlier quoted context omitted.
Great post! I too had the issue with AWS volume attachments and the need to separate them out. Luckily it happened early during some of my first provisioning and we realized it before standing up more databases. I now have a policy where each server has a separate EBS volume, using a volume attachment Terraform resource, for any data. Inline EBS volumes are just used for the OS. I've run into another similar type iss…
We ran into similar issues. From there I went one step further and wrote a tool to do the attachments for me (instead of using Terraform's aws_volume_attachment): https://github.com/sevagh/goat This way in Terraform I provision a group of volumes, a group of instances, and rely on `goat` to do the rest.
That's pretty cool. So is the model that you don't manage the volumes in TF at all?
(Btw I think I know people you know... also in Montreal and I know a couple folks at AdGear!)
Re: Terraform Gotchas and How We Work Around Them
#16> Always write your plan -out, and apply that plan
I have in my dotfiles:
alias tfplan='terraform plan -out=.tfplan -refresh=false'
alias tffreshplan='terraform plan -out=.tfplan'
alias tfapply='terraform apply .tfplan; rm .tfplan'
Re: Terraform Gotchas and How We Work Around Them
#17>Terraform state surgery Did you try to use `terraform state mv`? I've found that command useful (albeit for much less than thousands of resources).
I don't think it would work in this case, as the `ebs_block_device` block isn't a resource. In fact, the TF state doesn't even have the volume IDs for them!
An alternative to doing this was `terraform import` on all the volumes, then defining attachments, and hoping it all worked when you run `terraform plan`. I don't 100% remember now why we didn't do that.
Re: Terraform Gotchas and How We Work Around Them
#18Hey author here! Happy to answer any questions etc :-)
Great post. I think the area where things start to go off the rails with Terraform is variables/modules though. There are edge cases and gotchas with modules and not a lot of best practice guides.
Shameless plug, if anybody is looking for a guide on getting started with Terraform and Google Cloud Platform, I wrote a short blog post:
https://blog.elasticbyte.net/getting-started-with-terraform-...
Re: Terraform Gotchas and How We Work Around Them
#19Re: Terraform Gotchas and How We Work Around Them
#20> Always write your plan -out, and apply that plan I have in my dotfiles: alias tfplan='terraform plan -out=.tfplan -refresh=false' alias tffreshplan='terraform plan -out=.tfplan' alias tfapply='terraform apply .tfplan; rm .tfplan' That way I never accidentally `terraform apply` without creating a plan first. I also have it not refresh the state by default, which is mostly unnecessary and speeds up the planning signi…
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?