6 ms·

Does anyone that has used Terraform have any major complaints about it, or conversely any specific praises for something it does well compared to other tools in

Does anyone that has used Terraform have any major complaints about it, or conversely any specific praises for something it does well compared to other tools in that space?

scrollaway 10y ago
I haven't been using it very long but I'll go. My main complaints: - Very steep learning curve. It uses its own configuration language (HCL) which means you have new syntax to learn on top of its overwhelming API. - It's stateful, so you have a state file that you have to store and keep synchronized in your team. There's capabilities for storing the state remotely but it's very much not ideal. You seemingly can't generate that state file from scratch based on your current provider's state. - The templates are atrociously ugly and the string interpolation is limited, has extremely rough edges. - It's very much an 0.x product. I keep hitting bugs. EC2 machines don't destroy properly if they have mounted drives. S3 buckets can't be force-destroyed if they have versioning enabled. Some normalization issues here and there which cause constant changes to show up. - The custom format means the files aren't easily parsed and/or generated unless you're using hashicorp's own hcl go library. This sucks, to say the least. TOML with some conventions and jinja2 templating would have done the job just fine and would have been a ton more readable imho. It's still good software and design. I would definitely pick it up for new project, but I wouldn't bother migrating existing ones just yet unless you know you'll need it. I use it alongside Ansible and the two pair quite nicely.
- psadauskas 10y ago
  I agree with most of your points, but wanted to point out that Terraform also understands JSON for its config files, their HCL is just a simpler form. In one of my projects, I have most of the configs as .tf files, but another tool generates a bit of JSON (to update the ASG config after creating a new AMI) that Terraform incorporates into its plan.
  - scrollaway 10y ago
    That's true. More specifically (and if I understand hcl correctly), HCL is a superset of JSON which means JSON files are HCL files. (Source: https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl) I still wish they'd gone with TOML :) They have good reasoning as to why not JSON/YAML, but those are the issues TOML actually solves and it's just so much more readable imho.
- atombender 10y ago
  The state management system always struck me as very flawed design, and it's the reason I've not yet used Terraform. After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. A workaround is to manually reverse-engineer your current state into a state file, or use a third-party tool like Terraforming [1], but it still breaks the second anyone (either accidentally or intentionally for whatever reasons) bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design. Surely one of the primary uses of a tool like this must be that if something is modified behind your back, you are secure in the knowledge that you can whip out Terraform and it will force the world back into the right shape in a few seconds? That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however. I never understood the purpose of the state file. A tool like Terraform, from my perspective, should be stateless. It ought to compare its target to the world, and then attempt to converge the world to match the target. You could have local state as an option, in particular to detect interference, but I don't see why it's needed at all times. My current solution is to use Salt (not Salt Cloud, just the Salt "boto" states, using local masterless mode), but it's pretty terrible. I would really want a tool like Terraform, but without the flawed state management. [1] https://github.com/dtan4/terraforming https://github.com/dtan4/terraforming
  - jen20 10y ago
    > After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. One of the major features of the version released today is the ability to import existing resources in to Terraform state.
    - lobster_johnson 10y ago
      I wrote about that. That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however.
Rapzid 10y ago
Praise: - Often beats AWS to support on new features. AWS is traditionally not very good at coordinating service releases between IAM, CloudFormation, and whatever. - Modules better than nested stacks - Much better insight into what's going to change. This still seems to be the case with CloudFormation's change sets.. Particularly with nested stacks, which were sent to earth to torment us. - Nicer configuration than CloudFormation Woes: - Juggling multiple state files. This seems to be necessary if you are going to stamp out infrastructure across accounts and regions; this is double true if you want to roll changes gradually across regions/accounts. Prepare to write wrappers. - Creating modules is the only wait to organize tf files into folders. This can really rub you the wrong way because modules are isolated from the root and other modules' variables. You have to start passing in and out resource references :| There was an import proposal made 7 days ago that looks very nice. - Not much in the way of rollbacks.. - Potentially less flexible than CloudFormation; CloudFormation offers wait conditions, conditionals, rollbacks, update cancellations(with rollback), etc
chucky_z 10y ago
Yes, I've used Terraform since 0.3. I feel strongly about two things: 1) I screwed up at the beginning so hard (there were _no_ best practices to be found so it was a bit wild west) that I've come to the point where I need to use something else, or rewrite everything. 2) Terraform is best when you are in a silo by yourself, or you're using something to do the state applies for you (Atlas, or DIY through Jenkins and friends). It does a lot right that other tools don't do (stringing together resources is a cinch), but it also behaves in strange things and the statefile is both a huge positive, and a huge negative. If you need to move fast it's not a bad tool to choose at all. The BIG caveat here is as follows -- If you have a mixed-cloud setup and use AWS, GCE, Azure, DigitalOcean, etc.. at the same time; It's probably hands down the best tool for managing everything. Notes: - I only use AWS. I use some of the other TF providers mixed in with it. (Consul, Datadog) - I started from scratch (no AWS resources -> 100% Terraform), the general opinion seems to be this is the better place to start from. - I use a majority of Hashicorp's stuff and am quite partial to liking their products. Terraform is something I have the most opinions on. I have no problems strongly suggesting Packer, Consul, Vagrant, and Vault to anyone. - One of the main reasons I'm considering alternatives is that, at my current position, I'm having trouble getting folks to wrap their heads around Terraform.
user5994461 10y ago
VIP: Very Important Tip +++ Use jetbrains free IDE (IntelliJ, PyCharm...) and install the plugins for HCL support. You'll get syntax highlighting + auto completion for variable and infrastructure names + visual report on lines with errors and quickfixes. Now HCL just because the easiest language in the world. (Seriously, it's not even a language, it takes 1 hour to master the syntax, top.) +++ Use terraform to create all the infrastructure backbone. (VPC, subnets, routing tables, DHCP options, etc... ) Terraform is the single best tool in the world to do that. It's also the only one currently in existence that is actually able to do that. (ansible and the likes are missing critical modules). +++ Do NOT use terraform to manage instances nor security groups. These things change wayyy too often and you'll struggle with states. Use one of the ansible/salt to create and manage them. They refresh their inventory to keep with external changes (at least ansible does) and they allow to run scripts on the resources. (e.g. tag all the EBS volumes of the instance, after the instance is up). Bonus: For every instance "name" you create, create and put it in a security group with the same "name". Then you can manage security groups by name ;) +++ Terraform can import existing infrastructure since v0.7 (this release :D) Just sayin'. +++ The state files is annoying to share and keep updated It used to be put in git. (it's still possible). It can be put in S3 (or similar options). The sharing is faster and it makes less state issues. +++ Because of the state files, terraform is good for "static things" and terrible for "fast moving things". That makes terraform appropriate for the VPC/subnet/... provisioning (the first point in this list ) But it's terrible for instances and security groups (another point in the list ) Known your strengths and weaknesses, choose the right tool for the job ;)

Does anyone that has used Terraform have any major complaints about it, or conversely any specific praises for something it does well compared to other tools in that space?

scrollaway 10y ago

I haven't been using it very long but I'll go. My main complaints: - Very steep learning curve. It uses its own configuration language (HCL) which means you have new syntax to learn on top of its overwhelming API. - It's stateful, so you have a state file that you have to store and keep synchronized in your team. There's capabilities for storing the state remotely but it's very much not ideal. You seemingly can't generate that state file from scratch based on your current provider's state. - The templates are atrociously ugly and the string interpolation is limited, has extremely rough edges. - It's very much an 0.x product. I keep hitting bugs. EC2 machines don't destroy properly if they have mounted drives. S3 buckets can't be force-destroyed if they have versioning enabled. Some normalization issues here and there which cause constant changes to show up. - The custom format means the files aren't easily parsed and/or generated unless you're using hashicorp's own hcl go library. This sucks, to say the least. TOML with some conventions and jinja2 templating would have done the job just fine and would have been a ton more readable imho. It's still good software and design. I would definitely pick it up for new project, but I wouldn't bother migrating existing ones just yet unless you know you'll need it. I use it alongside Ansible and the two pair quite nicely.

psadauskas 10y ago
I agree with most of your points, but wanted to point out that Terraform also understands JSON for its config files, their HCL is just a simpler form. In one of my projects, I have most of the configs as .tf files, but another tool generates a bit of JSON (to update the ASG config after creating a new AMI) that Terraform incorporates into its plan.
- scrollaway 10y ago
  That's true. More specifically (and if I understand hcl correctly), HCL is a superset of JSON which means JSON files are HCL files. (Source: https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl) I still wish they'd gone with TOML :) They have good reasoning as to why not JSON/YAML, but those are the issues TOML actually solves and it's just so much more readable imho.
atombender 10y ago
The state management system always struck me as very flawed design, and it's the reason I've not yet used Terraform. After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. A workaround is to manually reverse-engineer your current state into a state file, or use a third-party tool like Terraforming [1], but it still breaks the second anyone (either accidentally or intentionally for whatever reasons) bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design. Surely one of the primary uses of a tool like this must be that if something is modified behind your back, you are secure in the knowledge that you can whip out Terraform and it will force the world back into the right shape in a few seconds? That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however. I never understood the purpose of the state file. A tool like Terraform, from my perspective, should be stateless. It ought to compare its target to the world, and then attempt to converge the world to match the target. You could have local state as an option, in particular to detect interference, but I don't see why it's needed at all times. My current solution is to use Salt (not Salt Cloud, just the Salt "boto" states, using local masterless mode), but it's pretty terrible. I would really want a tool like Terraform, but without the flawed state management. [1] https://github.com/dtan4/terraforming https://github.com/dtan4/terraforming
- jen20 10y ago
  > After all, it means that you have to start from scratch. If you any existing infrastructure — instances, load balancers, DNS, whatever — then anything you declare in Terraform will conflict, even if it's declared exactly identically. One of the major features of the version released today is the ability to import existing resources in to Terraform state.
  - lobster_johnson 10y ago
    I wrote about that. That being said, 0.7 has an import command now, so they recognize the problem. It's extremely limited and is not a complete solution yet, however.

Rapzid 10y ago

Praise: - Often beats AWS to support on new features. AWS is traditionally not very good at coordinating service releases between IAM, CloudFormation, and whatever. - Modules better than nested stacks - Much better insight into what's going to change. This still seems to be the case with CloudFormation's change sets.. Particularly with nested stacks, which were sent to earth to torment us. - Nicer configuration than CloudFormation Woes: - Juggling multiple state files. This seems to be necessary if you are going to stamp out infrastructure across accounts and regions; this is double true if you want to roll changes gradually across regions/accounts. Prepare to write wrappers. - Creating modules is the only wait to organize tf files into folders. This can really rub you the wrong way because modules are isolated from the root and other modules' variables. You have to start passing in and out resource references :| There was an import proposal made 7 days ago that looks very nice. - Not much in the way of rollbacks.. - Potentially less flexible than CloudFormation; CloudFormation offers wait conditions, conditionals, rollbacks, update cancellations(with rollback), etc

chucky_z 10y ago

Yes, I've used Terraform since 0.3. I feel strongly about two things: 1) I screwed up at the beginning so hard (there were _no_ best practices to be found so it was a bit wild west) that I've come to the point where I need to use something else, or rewrite everything. 2) Terraform is best when you are in a silo by yourself, or you're using something to do the state applies for you (Atlas, or DIY through Jenkins and friends). It does a lot right that other tools don't do (stringing together resources is a cinch), but it also behaves in strange things and the statefile is both a huge positive, and a huge negative. If you need to move fast it's not a bad tool to choose at all. The BIG caveat here is as follows -- If you have a mixed-cloud setup and use AWS, GCE, Azure, DigitalOcean, etc.. at the same time; It's probably hands down the best tool for managing everything. Notes: - I only use AWS. I use some of the other TF providers mixed in with it. (Consul, Datadog) - I started from scratch (no AWS resources -> 100% Terraform), the general opinion seems to be this is the better place to start from. - I use a majority of Hashicorp's stuff and am quite partial to liking their products. Terraform is something I have the most opinions on. I have no problems strongly suggesting Packer, Consul, Vagrant, and Vault to anyone. - One of the main reasons I'm considering alternatives is that, at my current position, I'm having trouble getting folks to wrap their heads around Terraform.

user5994461 10y ago

VIP: Very Important Tip +++ Use jetbrains free IDE (IntelliJ, PyCharm...) and install the plugins for HCL support. You'll get syntax highlighting + auto completion for variable and infrastructure names + visual report on lines with errors and quickfixes. Now HCL just because the easiest language in the world. (Seriously, it's not even a language, it takes 1 hour to master the syntax, top.) +++ Use terraform to create all the infrastructure backbone. (VPC, subnets, routing tables, DHCP options, etc... ) Terraform is the single best tool in the world to do that. It's also the only one currently in existence that is actually able to do that. (ansible and the likes are missing critical modules). +++ Do NOT use terraform to manage instances nor security groups. These things change wayyy too often and you'll struggle with states. Use one of the ansible/salt to create and manage them. They refresh their inventory to keep with external changes (at least ansible does) and they allow to run scripts on the resources. (e.g. tag all the EBS volumes of the instance, after the instance is up). Bonus: For every instance "name" you create, create and put it in a security group with the same "name". Then you can manage security groups by name ;) +++ Terraform can import existing infrastructure since v0.7 (this release :D) Just sayin'. +++ The state files is annoying to share and keep updated It used to be put in git. (it's still possible). It can be put in S3 (or similar options). The sharing is faster and it makes less state issues. +++ Because of the state files, terraform is good for "static things" and terrible for "fast moving things". That makes terraform appropriate for the VPC/subnet/... provisioning (the first point in this list ) But it's terrible for instances and security groups (another point in the list ) Known your strengths and weaknesses, choose the right tool for the job ;)