20 ms·

Terraform 0.15 General Availability

245 points by myroon5 6y ago

llbeansandrice 6y ago
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.
- _joel 6y ago
  With lots of swearing, at least in my experience when we did the same upgrade as you. I too am hoping this will be smoother in future and the changes stabilise. I guess if you're doing very simple stuff then it's not an issue but the larger the estate and 'custom' stuff that gets added the more difficult any upgrade becomes (tf or not)
- scottsuch 6y ago
  Our team just did a big effort to get from 11 to 12. After that the effort was quite minimal. Some little gotchas re: providers in 13 but we're just today finished the 14 upgrade and will probably let 15 marinate until we upgrade to that.
  - llbeansandrice 6y ago
    I think we're dealing with the providers now as we get warnings on 0.12.29 that they'll be deprecated in 13 so nice to know that we're over the biggest hill.
- mohsen0 6y ago
  It becomes much easier between other versions. Though upgrading 0.12 to 0.13 I remember, i had to pull the state and change the provider field manually to avoid recreation of some resources.
  - dastx 6y ago
    > i had to pull the state and change the provider field manually to avoid recreation of some resources. Terraform CLI introduced an upgrade command (can't remember what it's called) that automatically does this for you.
    - erik_seaberg 6y ago
      In 0.14 that is no longer available.
      - dastx 6y ago
        Terraform 0.14 is pretty much fully compatible with 0.13, so no such command is necessary. All you have to do is make sure your state is for version 0.13. Outside that it's a bunch of usability changes that do not affect your tf code.
- jokethrowaway 6y ago
  Someone not in our team upgraded version by mistake from 0.12 to 0.13 (he was contributing something small and used the latest), the CTO got involved and made us update everything and it was a big undertaking. Personally I have a nix shell file pinned to the exact version of terraform (as in, commit hash on the nix-packages repo) we use in every repo and just switch to that shell before doing anything.
  - _joel 6y ago
    We use this https://github.com/tfutils/tfenv https://github.com/tfutils/tfenv
  - yjftsjthsd-h 6y ago
    I'm a fan of tfenv for this; it's really easy to use and makes it trivial to pin each stack to an exact version of TF.
    - toyg 6y ago
      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...?
      - yjftsjthsd-h 6y ago
        That is a selling point of nix and docker, yes:) The catch is that doing it generically makes the whole thing more complicated (although I suspect nix and docker are more complex than is strictly required for that use case)
      - darkwater 6y ago
        Maybe asdf? https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
        diroussel 6y ago
        I use asdf and it’s great. You keep your versions in .tool-versions abs when you switch for branches you automatically get the right versions of node, java, terraform etc on your path.
- yjftsjthsd-h 6y ago
  On the bright side, now that they've committed to a stable state file format it should get better
- mitchellh 6y ago
  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 to subsequent versions same day without issue. Breaking changes and difficult upgrades is not something we want to do with Terraform (0.12 being a big exception as that was a very core "reset" so to speak). The reason there have been these changes in these recent releases is that we've been ensuring Terraform is in a place for 1.0 that we don't have to have difficult upgrades. You can see this path happening in each release: - Terraform 0.15: state file format stability - Terraform 0.14: provider dependency lock file - Terraform 0.13: required provider block (for more deterministic providers) - Terraform 0.12: stable JSON formats for plans/config parsing/etc. (particularly useful for interop with things like Terraform Cloud and 3rd party tooling) This was all done to lead up to a stable 1.0 release. As noted in the blog post, 0.15 is effectively a 1.0 pre-release so if everything goes well, we've MADE IT. For 1.0, we'll be outlining a number of very detailed compatibility promises which will make upgrades much easier going forward. :)
  - llbeansandrice 6y ago
    Thanks, good to know that the upgrade to 12 is the biggest jump.
    - john37386 6y ago
      I had the same question or concern. I also realized too late that 0.12 is a bigger one than first thought. I was not severely impacted in the end, but boy it was a long time that I didn't experience such a tough upgrade. Happy to know that the hardest is behind and looking forward to try 0.15. Thanks
  - 0xbadcafebee 6y ago
    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 the problems that will appear in production. And it's all owned by different groups and used in different projects, so that makes things longer/more complex. We also have to deal with provider version changes, upgrading CI pipelines and environments to be able to switch between Terraform binaries, and conventions to switch between code branches. I am already looking around for some way to remove Terraform from our org because it is slowly strangling our productivity. It's way too slow, there's too many footguns, it doesn't reliably predict changes, it breaks on apply like half of the time, and it's an arduous manual process to fix and clean up its broken state when it does eventually break. Not to mention just writing and testing the stuff takes forever, and the very obvious missing features like auto-generation and auto-import. I keep a channel just to rant about it. After Jenkins, Ansible and Puppet, it's one of those tools I dread but can't get away from.
- jasonvorhe 6y ago
  terraform 0.1xupgrade went pretty smoothly most of the time, with some minor manual changes and fixes here and there. Most of them were easily done in batch over the repository using sed. This approach worked for me in various setups from a small SaaS company to a major travel company as well as personal projects without issues.
- uglygoblin 6y ago
  I started using Terraform on our project in early 2019 which was version 0.11.13. The upgrade to 0.12.x seemed non-trivial so I put it off... now 2 years later and we're at 0.15.x. Looks like I need to clear my schedule in a upcoming sprint to get this done so the pain doesn't get even worse :)
- dguaraglia 6y ago
  As everyone else said: 0.11 to 0.12 was painful. After that, you just need to deal with converting the state whenever a new version comes out, but that's basically automated so not a biggie.
- tetha 6y ago
  From our experience. 0.11 -> 0.12: We're not attempting. We're in the process of changing out config management anyway and we're unhappy with a bunch of decisions in that terraform stack, so it's a good point to get rid of it. 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.
- garymoon 6y ago
  I upgraded from 11 to 12 like one year ago and from 12 to 13 some days ago (upgrade to 14 seems that will be straightforward) but in my case what I did: - Don't upgrade directly from 12 to 14, go to 13 first - If you have warnings after moving from 11, fix them first - Run the 0.13upgrade command in your code that will generate the required_providers - Run terraform-v13 init - Change to correct workspace if using some - Run terraform-v13 plan which will probably fail due to the new explicit required-providers rule, if that happens you need to modify the state with the correct providers https://www.terraform.io/upgrade-guides/0-13.html#why-do-i-see-provider-during-init- . In my case I have a lot of modules so I created an script that automated that process - Execute again terraform-v13 plan and verify that it will not make uncommon changes - Then run terraform-v13 apply.
  - matwood 6y ago
    > Don't upgrade directly from 12 to 14, go to 13 first The line above, plus running apply in each version is key. I literally just did the update from 11->latest for 3 different repos a couple of weeks ago. And tbh, its was only the first update where I had to make any code changes. The rest mostly worked.
- skywhopper 6y ago
  After 0.12 it has been much easier.
- capableweb 6y ago
  As no one seems to have mentioned anything, version numbers below 1.0 are generally considered unstable in terms of API interface (like HCL in this case) so if you'd like to avoid similar things in the future (with either Terraform or other tools), you're best to wait until they at least release version 1.0.
dxxvi 6y ago
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
- verdverm 6y ago
  A manual fix requires a git commit, as most use Terraform with GitOps and IaC. The point of using TF for many is reproducible infra and change approval workflows. So avoiding manual changes via the web consoles is what people are striving for.
- darkwater 6y ago
  To answer your questions: you generally look in the Terraform docs which are well written and always updated, because autogenerated. The state forces you and especially the team to almost never touch things directly. And if you do, you feel nasty for it.
- llbeansandrice 6y ago
  There are docs for terraform which are fairly general and then provider specific docs as well (aws/gcp/azure/etc). We like it because it is easy to recreate environments and entire infrastructures. It also makes it much easier to review infrastructure changes. >manually fix You can if you need to. TF can ignore changes to certain aspects of resources like desired count of ECS tasks which might autoscale up and down and you can always make the change manually and then update the code to reflect the change. That's a bit of a no-no though. Like pushing code without a review.
- 2ion 6y ago
  What else to use? All other tools operate at the same level as terraform, be it cloudformation or anything else. It's just drivers for the cloud API in question, each with their own drawbacks, idiocracies, limitations and workarounds. In a sense, these are all equal effort for the user.
darkwater 6y ago
Looks like Terraform is really approaching maturity and the 1.0 release already on the horizon is a deserved milestone. I really appreciated the lockfile for modules/providers added in 0.14 and 3rd party providers in the registry being promoted to 1St class citizens. It enables saner and more modular architectures in an easy enough way.
cmclaughlin 6y ago
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 https://github.com/hashicorp/terraform-cdk
- justin_oaks 6y ago
  Are all variables, conditionals, templating, and loops done in Python? Or is some of that still needed on the Terraform side?
  - diroussel 6y ago
    Basically you create the desired state DAG in procedural code, rather than the TF DSL. Blithe diffing and applying are the same.
    - ben0x539 6y ago
      Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation?
      - cmclaughlin 6y ago
        > Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation? No... the high level programming language really just serves as a bridge or translation layer to a Terraform compatible JSON file. Those sorts of evaluations don’t happen to the actually plan/apply. However, you may find it useful to make direct API calls to your cloud provider in cdktf stacks. For instance, I mostly use data lookups but if I want to perform string operations on that sort of data I would use boto3 instead.
- wooly_bully 6y ago
  The 'not using HCL' bit is really the only positive I've found so far because everything else has been more difficult than just using TF directly. I think my goals were slightly off from the beginning, because this is really just replacing one CLI with another for me at this point. What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can use where I can abstract away some of the difficulties of learning to use Terraform natively for simple use cases (i.e. deploy an S3-based frontend host). Ideally, I had intended to distribute some npm-installable packages which would run this stuff.
sali0 6y ago
So much hate ITT for such a great tool. Terraform is definitely not perfect but it's still one of my favorite tools, solely because of the amount of efficiency gained from learning it. Yes HCL is not perfect, but it is definitely adequate for a lot of applications. IMO, Hashicorp makes some of the most well thought out tools and I am grateful of their attitude towards open source.
- ksec 6y ago
  ITT = In This Thread. ( I had to look it up )
- dkdk8283 6y ago
  I’ve preferred cloud formation for many years. the amount of time I spend debugging problems related to TF is infuriating. at least with aws.
  - mbushey 6y ago
    Terraform makes me happy, I use it daily on AWS and GCP. I can't stand Cloud Formation.
  - halfmatthalfcat 6y ago
    The amount of tooling that has sprung out around managing large CloudFormation deployments is exactly the reason TF exists. CloudFormation is an untenable mess.
    - dkdk8283 6y ago
      No, it’s just that it’s not fun to learn.
deleted 6y ago
[deleted]
rad_gruchalski 6y ago
Awesome stuff. Congratulations on the release. Time to update the Ansible provisioner (https://github.com/radekg/terraform-provisioner-ansible https://github.com/radekg/terraform-provisioner-ansible) this coming weekend!
glenellen1 6y ago
Our organization just started looking at Crossplane instead of Terraform. It apparently gets around the lock issues [1] and is better suited for K8S environments. Some folks I work with think the community will eventually adopt Crossplane over Terraform. Anyone have any experience with it? [1] https://blog.crossplane.io/crossplane-vs-terraform/ https://blog.crossplane.io/crossplane-vs-terraform/
rantwasp 6y ago
I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know what will. It's basically YOLO-ing it and in case it does not work you're on your own. It's also leaving you in whatever state and now you need to figure out what it managed to do, what didn't work and figure out how to 1) make it work 2) make terraform understand that it worked. Usually this happens at the worst time when you are deploying to production. Do we want to talk about when plan "works" but it craps out on "apply"? Or about when it just loses tracks of resources. HCL? A disaster. Why would you need to invent your own language? Why oh why? Hashicorp also knows better. Remember Vagrant? Vagrant got it right with the DSL + you could always drop down to Ruby if you did something not covered by the DSL. My advice to you: use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).
- manishsharan 6y ago
  Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.
  - encryptluks2 6y ago
    When using Terraform you should think of your IaC as the plans to build or rebuild your infrastructure, not an extension. I built mine in a way where I can destroy all the infrastructure in a plan and then reapply. You don't have to worry about rollbacks when you can just rebuild everything without affecting your end service.
    - rantwasp 6y ago
      welcome to the real world where you sometimes cannot do what you are saying :(
dekhn 6y ago
terraform was a great idea but the language makes devops folks have to do a lot of extra work, purely due to language design features. Terragrunt helps with a lot of that, but combined with the version churn, long-standing bugs, and more, I really wanted an alternative that was small, and simple. Also: why isn't the state file created at command invocation by querying AWS for the state? Or at least have an option to generate the simplest TF for your current AWS state.
- mwarkentin 6y ago
  For the latter: https://github.com/GoogleCloudPlatform/terraformer https://github.com/GoogleCloudPlatform/terraformer
  - bogomipz 6y ago
    Does this basically automate a "terraform import" of existing infrastructure then?
theogravity 6y ago
For various reasons, I cannot use terraform stock. I have to use terragrunt, which wraps around terraform and provides a lot of functionality that terraform should have had.
ghjnut 6y ago
Hijacking a bit, but does anyone have any good resources/guides around managing terraform state in larger organizations? Terraform enterprise seems to address this but I was wondering if there's workflows that allowed subsections of infrastructure (think teams or systems) and didn't rely on a re-evaluation of the entire organization's assets. So far the only approach I've seen is having protected high level (VPC, subnets etc) as a separate state and using terraform_remote_state to reference those.
- techdragon 6y ago
  That’s pretty much the only way I’ve found using the existing open tools.
- llarsson 6y ago
  No, that's pretty much it. Some core components that most will include as remote state, and you can discover and use as remote state stuff from other teams, too. Quite basic, but something tells me this could very well be intentional, so that the enterprise offering has a clearly increased value.
- ec109685 6y ago
  The way we do it is 1) each team owns one or more of AWS sub accounts (e.g a particular app or function will be in its own account) 2) An internal version of this is used to establish and enforce company-wide standards: https://github.com/cloud-custodian/cloud-custodian https://github.com/cloud-custodian/cloud-custodian 3) A repository of terraform modules is shared amongst teams to standardize on how common AWS resources are used (e.g. enforce X, Y and Z for S3 buckets) This way, the per account setup (represented as a repo) is relatively small, common patterns are standardized, and there is still room for experimentation.
- saberience 6y ago
  We use Spacelift at our company, pretty new tool, but I prefer it to Terraform Enterprise and the migration was way easier.
- ygouzerh 6y ago
  We decided to go for Terraform Cloud in our company, it works really great. You can setup a workspace per subfolder, setup to automatic planning or not at each new commit, and put a team on it. Main features I see : store the state and take care about the durability and the encryption + can create teams + cicd pipeline + manage variables. There is a free tier until 5 active users also, good for experimenting it / showcase the advantages to stakeholders
goatinaboat 6y ago
Blows my mind how many people are basing business critical infrastructures on 0.something of anything
- HatchedLake721 6y ago
  Terraform (and hashicorp) don’t follow semver. Terraform has been spinning up infrastructure for small and $100billion+ companies for years, it came out in 2014. Business critical readiness is not measured whether something has or hasn’t got a “1.0” tag on GitHub.
  - takeda 6y ago
    and in 2021 finally is able to remove the environment that was actually deployed and not the one located in your current directory. I wouldn't call TF garbage, because real garbage is the native provisioning tool gcp has. It is just waay over-hyped tool. Reading comments here it is clear that the biggest proponents at most maybe used CF once or not at all. TF was great when it was released, it was superior to CF back then. HCL was much better then using JSON, but things improved dramatically. No need to worry about storing state, imports/exports where you can share values between stacks. CustomResources (where you can create a lambda function that does anything you need to), I used for example to configure AWS integration with DataDog, where it needs to create resource in AWS then make setup on DD side that create more resources. Combine that with managed stacksets and BOOM, now every account in the organization automatically sets up the integration. Imagine doing something like that with TF.
decebalus1 6y ago
I have been using terraform professionally at my current workplace for a while now and I would not recommend it to anyone when building and maintaining non-trivial infrastructure. - state management is a sad joke. Which would be fine if it wouldn't end up being an expensive joke sometimes. And by sometimes I mean right when you need to change production. Try destroying your stack with an AWS KMS key. Then create it again. Try killing apply and then try re-applying it. I have witnessed hours of developer time going down the drain to figure out what terraform was able to do, import resources, convince terraform that resources are added, write scripts to delete stuff.. A complete nightmare. Oh yeah, but just run apply twice, that usually fixes it. There is no such thing as a rollback in the world of terraform. We only roll forward! - bUt ItS cLouD AgNoSTic. No, it's not. You're writing separate stacks with their separate own custom resources and their separate requirements and separate policies. Just use cloudformation, gdm or whatever your cloud uses and automate these using a script if you're doing crosscloud crap. - but I want to avoid vendor lock-in. See above, odds are that you're already locked-in but still in denial. - HCL. I get it. Declarative, nice and clean. HAHAHA, who am I kidding. It sucks, it's stupid and pointless. Awful to write, awful to read, inconsistent, no proper tooling or editor support. Good luck maintaining dependencies or comprehending a complex stack. Why didn't they just build a DSL over a language people already know? Good luck 'refactoring' your resource definitions. Oh, and you also want to test it somehow without affecting a remote environment? Again, good luck, sucker. Because 'the plan' is a lie. And error messages seem to be written by someone waging war against their customers. In conclusion, I do not recommend terraform. In my opinion it is an overhyped piece of technology on which I would not bet my company/money on.
cies 6y ago
I think TF is used a lot in production for a pre-1.0 "we can break what ever we want". But then I also use it, happily :)
- jen20 6y ago
  Terraform (core) doesn’t follow semantic versioning, so pre-1.0 does not mean that. Ever since 0.4, the number of production users made working on it rather like changing the wheels on a bus while driving down the highway full of passengers!
  - cies 6y ago
    That's what I mean: it is defacto 1.0 already, just no communicated. And semver or not: pre-1.0 is pre-1.0. I was glad to read this announcement that they are making strides to get to 1.0.
te_chris 6y ago
All this energy and griping by people. Don’t get it. I’m excited for actual obfuscation. I’ve always thought tf cloud is probably the juiciest hacking target of all. All those keys.
sylens 6y ago
One of my biggest annoyances with Terraform is how you cannot start out by creating your state remotely - you have to run it first with local state and then move it to a remote backend on a subsequent run.
- svavs 6y ago
  Completely agree! My company has pretty strict rules for creating infrastructure in our upper environments. Devs are not able to do it and we want everything to run through our CI/CD pipeline. We either have to ask our cloud team to create the bucket or hack up our build file to add it. It would be nice, on the first run of terraform init, if it would check for the remote state bucket and then ask if you would like to create it if it does not exist.

245 points by myroon5 6y ago

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.

_joel 6y ago
With lots of swearing, at least in my experience when we did the same upgrade as you. I too am hoping this will be smoother in future and the changes stabilise. I guess if you're doing very simple stuff then it's not an issue but the larger the estate and 'custom' stuff that gets added the more difficult any upgrade becomes (tf or not)
scottsuch 6y ago
Our team just did a big effort to get from 11 to 12. After that the effort was quite minimal. Some little gotchas re: providers in 13 but we're just today finished the 14 upgrade and will probably let 15 marinate until we upgrade to that.
- llbeansandrice 6y ago
  I think we're dealing with the providers now as we get warnings on 0.12.29 that they'll be deprecated in 13 so nice to know that we're over the biggest hill.
mohsen0 6y ago
It becomes much easier between other versions. Though upgrading 0.12 to 0.13 I remember, i had to pull the state and change the provider field manually to avoid recreation of some resources.
- dastx 6y ago
  > i had to pull the state and change the provider field manually to avoid recreation of some resources. Terraform CLI introduced an upgrade command (can't remember what it's called) that automatically does this for you.
  - erik_seaberg 6y ago
    In 0.14 that is no longer available.
    - dastx 6y ago
      Terraform 0.14 is pretty much fully compatible with 0.13, so no such command is necessary. All you have to do is make sure your state is for version 0.13. Outside that it's a bunch of usability changes that do not affect your tf code.
jokethrowaway 6y ago
Someone not in our team upgraded version by mistake from 0.12 to 0.13 (he was contributing something small and used the latest), the CTO got involved and made us update everything and it was a big undertaking. Personally I have a nix shell file pinned to the exact version of terraform (as in, commit hash on the nix-packages repo) we use in every repo and just switch to that shell before doing anything.
- _joel 6y ago
  We use this https://github.com/tfutils/tfenv https://github.com/tfutils/tfenv
- yjftsjthsd-h 6y ago
  I'm a fan of tfenv for this; it's really easy to use and makes it trivial to pin each stack to an exact version of TF.
  - toyg 6y ago
    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...?
    - yjftsjthsd-h 6y ago
      That is a selling point of nix and docker, yes:) The catch is that doing it generically makes the whole thing more complicated (although I suspect nix and docker are more complex than is strictly required for that use case)
    - darkwater 6y ago
      Maybe asdf? https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
      - diroussel 6y ago
        I use asdf and it’s great. You keep your versions in .tool-versions abs when you switch for branches you automatically get the right versions of node, java, terraform etc on your path.
yjftsjthsd-h 6y ago
On the bright side, now that they've committed to a stable state file format it should get better
mitchellh 6y ago
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 to subsequent versions same day without issue. Breaking changes and difficult upgrades is not something we want to do with Terraform (0.12 being a big exception as that was a very core "reset" so to speak). The reason there have been these changes in these recent releases is that we've been ensuring Terraform is in a place for 1.0 that we don't have to have difficult upgrades. You can see this path happening in each release: - Terraform 0.15: state file format stability - Terraform 0.14: provider dependency lock file - Terraform 0.13: required provider block (for more deterministic providers) - Terraform 0.12: stable JSON formats for plans/config parsing/etc. (particularly useful for interop with things like Terraform Cloud and 3rd party tooling) This was all done to lead up to a stable 1.0 release. As noted in the blog post, 0.15 is effectively a 1.0 pre-release so if everything goes well, we've MADE IT. For 1.0, we'll be outlining a number of very detailed compatibility promises which will make upgrades much easier going forward. :)
- llbeansandrice 6y ago
  Thanks, good to know that the upgrade to 12 is the biggest jump.
  - john37386 6y ago
    I had the same question or concern. I also realized too late that 0.12 is a bigger one than first thought. I was not severely impacted in the end, but boy it was a long time that I didn't experience such a tough upgrade. Happy to know that the hardest is behind and looking forward to try 0.15. Thanks
- 0xbadcafebee 6y ago
  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 the problems that will appear in production. And it's all owned by different groups and used in different projects, so that makes things longer/more complex. We also have to deal with provider version changes, upgrading CI pipelines and environments to be able to switch between Terraform binaries, and conventions to switch between code branches. I am already looking around for some way to remove Terraform from our org because it is slowly strangling our productivity. It's way too slow, there's too many footguns, it doesn't reliably predict changes, it breaks on apply like half of the time, and it's an arduous manual process to fix and clean up its broken state when it does eventually break. Not to mention just writing and testing the stuff takes forever, and the very obvious missing features like auto-generation and auto-import. I keep a channel just to rant about it. After Jenkins, Ansible and Puppet, it's one of those tools I dread but can't get away from.
jasonvorhe 6y ago
terraform 0.1xupgrade went pretty smoothly most of the time, with some minor manual changes and fixes here and there. Most of them were easily done in batch over the repository using sed. This approach worked for me in various setups from a small SaaS company to a major travel company as well as personal projects without issues.
uglygoblin 6y ago
I started using Terraform on our project in early 2019 which was version 0.11.13. The upgrade to 0.12.x seemed non-trivial so I put it off... now 2 years later and we're at 0.15.x. Looks like I need to clear my schedule in a upcoming sprint to get this done so the pain doesn't get even worse :)
dguaraglia 6y ago
As everyone else said: 0.11 to 0.12 was painful. After that, you just need to deal with converting the state whenever a new version comes out, but that's basically automated so not a biggie.
tetha 6y ago
From our experience. 0.11 -> 0.12: We're not attempting. We're in the process of changing out config management anyway and we're unhappy with a bunch of decisions in that terraform stack, so it's a good point to get rid of it. 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.
garymoon 6y ago
I upgraded from 11 to 12 like one year ago and from 12 to 13 some days ago (upgrade to 14 seems that will be straightforward) but in my case what I did: - Don't upgrade directly from 12 to 14, go to 13 first - If you have warnings after moving from 11, fix them first - Run the 0.13upgrade command in your code that will generate the required_providers - Run terraform-v13 init - Change to correct workspace if using some - Run terraform-v13 plan which will probably fail due to the new explicit required-providers rule, if that happens you need to modify the state with the correct providers https://www.terraform.io/upgrade-guides/0-13.html#why-do-i-see-provider-during-init- . In my case I have a lot of modules so I created an script that automated that process - Execute again terraform-v13 plan and verify that it will not make uncommon changes - Then run terraform-v13 apply.
- matwood 6y ago
  > Don't upgrade directly from 12 to 14, go to 13 first The line above, plus running apply in each version is key. I literally just did the update from 11->latest for 3 different repos a couple of weeks ago. And tbh, its was only the first update where I had to make any code changes. The rest mostly worked.
skywhopper 6y ago
After 0.12 it has been much easier.
capableweb 6y ago
As no one seems to have mentioned anything, version numbers below 1.0 are generally considered unstable in terms of API interface (like HCL in this case) so if you'd like to avoid similar things in the future (with either Terraform or other tools), you're best to wait until they at least release version 1.0.

dxxvi 6y ago

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

verdverm 6y ago
A manual fix requires a git commit, as most use Terraform with GitOps and IaC. The point of using TF for many is reproducible infra and change approval workflows. So avoiding manual changes via the web consoles is what people are striving for.
darkwater 6y ago
To answer your questions: you generally look in the Terraform docs which are well written and always updated, because autogenerated. The state forces you and especially the team to almost never touch things directly. And if you do, you feel nasty for it.
llbeansandrice 6y ago
There are docs for terraform which are fairly general and then provider specific docs as well (aws/gcp/azure/etc). We like it because it is easy to recreate environments and entire infrastructures. It also makes it much easier to review infrastructure changes. >manually fix You can if you need to. TF can ignore changes to certain aspects of resources like desired count of ECS tasks which might autoscale up and down and you can always make the change manually and then update the code to reflect the change. That's a bit of a no-no though. Like pushing code without a review.
2ion 6y ago
What else to use? All other tools operate at the same level as terraform, be it cloudformation or anything else. It's just drivers for the cloud API in question, each with their own drawbacks, idiocracies, limitations and workarounds. In a sense, these are all equal effort for the user.

darkwater 6y ago

Looks like Terraform is really approaching maturity and the 1.0 release already on the horizon is a deserved milestone. I really appreciated the lockfile for modules/providers added in 0.14 and 3rd party providers in the registry being promoted to 1St class citizens. It enables saner and more modular architectures in an easy enough way.

cmclaughlin 6y ago

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 https://github.com/hashicorp/terraform-cdk

justin_oaks 6y ago
Are all variables, conditionals, templating, and loops done in Python? Or is some of that still needed on the Terraform side?
- diroussel 6y ago
  Basically you create the desired state DAG in procedural code, rather than the TF DSL. Blithe diffing and applying are the same.
  - ben0x539 6y ago
    Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation?
    - cmclaughlin 6y ago
      > Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation? No... the high level programming language really just serves as a bridge or translation layer to a Terraform compatible JSON file. Those sorts of evaluations don’t happen to the actually plan/apply. However, you may find it useful to make direct API calls to your cloud provider in cdktf stacks. For instance, I mostly use data lookups but if I want to perform string operations on that sort of data I would use boto3 instead.
wooly_bully 6y ago
The 'not using HCL' bit is really the only positive I've found so far because everything else has been more difficult than just using TF directly. I think my goals were slightly off from the beginning, because this is really just replacing one CLI with another for me at this point. What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can use where I can abstract away some of the difficulties of learning to use Terraform natively for simple use cases (i.e. deploy an S3-based frontend host). Ideally, I had intended to distribute some npm-installable packages which would run this stuff.

sali0 6y ago

So much hate ITT for such a great tool. Terraform is definitely not perfect but it's still one of my favorite tools, solely because of the amount of efficiency gained from learning it. Yes HCL is not perfect, but it is definitely adequate for a lot of applications. IMO, Hashicorp makes some of the most well thought out tools and I am grateful of their attitude towards open source.

ksec 6y ago
ITT = In This Thread. ( I had to look it up )
dkdk8283 6y ago
I’ve preferred cloud formation for many years. the amount of time I spend debugging problems related to TF is infuriating. at least with aws.
- mbushey 6y ago
  Terraform makes me happy, I use it daily on AWS and GCP. I can't stand Cloud Formation.
- halfmatthalfcat 6y ago
  The amount of tooling that has sprung out around managing large CloudFormation deployments is exactly the reason TF exists. CloudFormation is an untenable mess.
  - dkdk8283 6y ago
    No, it’s just that it’s not fun to learn.

deleted 6y ago

[deleted]

rad_gruchalski 6y ago

Awesome stuff. Congratulations on the release. Time to update the Ansible provisioner (https://github.com/radekg/terraform-provisioner-ansible https://github.com/radekg/terraform-provisioner-ansible) this coming weekend!

glenellen1 6y ago

Our organization just started looking at Crossplane instead of Terraform. It apparently gets around the lock issues [1] and is better suited for K8S environments. Some folks I work with think the community will eventually adopt Crossplane over Terraform. Anyone have any experience with it? [1] https://blog.crossplane.io/crossplane-vs-terraform/ https://blog.crossplane.io/crossplane-vs-terraform/

rantwasp 6y ago

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know what will. It's basically YOLO-ing it and in case it does not work you're on your own. It's also leaving you in whatever state and now you need to figure out what it managed to do, what didn't work and figure out how to 1) make it work 2) make terraform understand that it worked. Usually this happens at the worst time when you are deploying to production. Do we want to talk about when plan "works" but it craps out on "apply"? Or about when it just loses tracks of resources. HCL? A disaster. Why would you need to invent your own language? Why oh why? Hashicorp also knows better. Remember Vagrant? Vagrant got it right with the DSL + you could always drop down to Ruby if you did something not covered by the DSL. My advice to you: use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).

manishsharan 6y ago
Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.
- encryptluks2 6y ago
  When using Terraform you should think of your IaC as the plans to build or rebuild your infrastructure, not an extension. I built mine in a way where I can destroy all the infrastructure in a plan and then reapply. You don't have to worry about rollbacks when you can just rebuild everything without affecting your end service.
  - rantwasp 6y ago
    welcome to the real world where you sometimes cannot do what you are saying :(

dekhn 6y ago

terraform was a great idea but the language makes devops folks have to do a lot of extra work, purely due to language design features. Terragrunt helps with a lot of that, but combined with the version churn, long-standing bugs, and more, I really wanted an alternative that was small, and simple. Also: why isn't the state file created at command invocation by querying AWS for the state? Or at least have an option to generate the simplest TF for your current AWS state.

mwarkentin 6y ago
For the latter: https://github.com/GoogleCloudPlatform/terraformer https://github.com/GoogleCloudPlatform/terraformer
- bogomipz 6y ago
  Does this basically automate a "terraform import" of existing infrastructure then?

theogravity 6y ago

For various reasons, I cannot use terraform stock. I have to use terragrunt, which wraps around terraform and provides a lot of functionality that terraform should have had.

ghjnut 6y ago

Hijacking a bit, but does anyone have any good resources/guides around managing terraform state in larger organizations? Terraform enterprise seems to address this but I was wondering if there's workflows that allowed subsections of infrastructure (think teams or systems) and didn't rely on a re-evaluation of the entire organization's assets. So far the only approach I've seen is having protected high level (VPC, subnets etc) as a separate state and using terraform_remote_state to reference those.

techdragon 6y ago
That’s pretty much the only way I’ve found using the existing open tools.
llarsson 6y ago
No, that's pretty much it. Some core components that most will include as remote state, and you can discover and use as remote state stuff from other teams, too. Quite basic, but something tells me this could very well be intentional, so that the enterprise offering has a clearly increased value.
ec109685 6y ago
The way we do it is 1) each team owns one or more of AWS sub accounts (e.g a particular app or function will be in its own account) 2) An internal version of this is used to establish and enforce company-wide standards: https://github.com/cloud-custodian/cloud-custodian https://github.com/cloud-custodian/cloud-custodian 3) A repository of terraform modules is shared amongst teams to standardize on how common AWS resources are used (e.g. enforce X, Y and Z for S3 buckets) This way, the per account setup (represented as a repo) is relatively small, common patterns are standardized, and there is still room for experimentation.
saberience 6y ago
We use Spacelift at our company, pretty new tool, but I prefer it to Terraform Enterprise and the migration was way easier.
ygouzerh 6y ago
We decided to go for Terraform Cloud in our company, it works really great. You can setup a workspace per subfolder, setup to automatic planning or not at each new commit, and put a team on it. Main features I see : store the state and take care about the durability and the encryption + can create teams + cicd pipeline + manage variables. There is a free tier until 5 active users also, good for experimenting it / showcase the advantages to stakeholders

goatinaboat 6y ago

Blows my mind how many people are basing business critical infrastructures on 0.something of anything

HatchedLake721 6y ago
Terraform (and hashicorp) don’t follow semver. Terraform has been spinning up infrastructure for small and $100billion+ companies for years, it came out in 2014. Business critical readiness is not measured whether something has or hasn’t got a “1.0” tag on GitHub.
- takeda 6y ago
  and in 2021 finally is able to remove the environment that was actually deployed and not the one located in your current directory. I wouldn't call TF garbage, because real garbage is the native provisioning tool gcp has. It is just waay over-hyped tool. Reading comments here it is clear that the biggest proponents at most maybe used CF once or not at all. TF was great when it was released, it was superior to CF back then. HCL was much better then using JSON, but things improved dramatically. No need to worry about storing state, imports/exports where you can share values between stacks. CustomResources (where you can create a lambda function that does anything you need to), I used for example to configure AWS integration with DataDog, where it needs to create resource in AWS then make setup on DD side that create more resources. Combine that with managed stacksets and BOOM, now every account in the organization automatically sets up the integration. Imagine doing something like that with TF.

decebalus1 6y ago

I have been using terraform professionally at my current workplace for a while now and I would not recommend it to anyone when building and maintaining non-trivial infrastructure. - state management is a sad joke. Which would be fine if it wouldn't end up being an expensive joke sometimes. And by sometimes I mean right when you need to change production. Try destroying your stack with an AWS KMS key. Then create it again. Try killing apply and then try re-applying it. I have witnessed hours of developer time going down the drain to figure out what terraform was able to do, import resources, convince terraform that resources are added, write scripts to delete stuff.. A complete nightmare. Oh yeah, but just run apply twice, that usually fixes it. There is no such thing as a rollback in the world of terraform. We only roll forward! - bUt ItS cLouD AgNoSTic. No, it's not. You're writing separate stacks with their separate own custom resources and their separate requirements and separate policies. Just use cloudformation, gdm or whatever your cloud uses and automate these using a script if you're doing crosscloud crap. - but I want to avoid vendor lock-in. See above, odds are that you're already locked-in but still in denial. - HCL. I get it. Declarative, nice and clean. HAHAHA, who am I kidding. It sucks, it's stupid and pointless. Awful to write, awful to read, inconsistent, no proper tooling or editor support. Good luck maintaining dependencies or comprehending a complex stack. Why didn't they just build a DSL over a language people already know? Good luck 'refactoring' your resource definitions. Oh, and you also want to test it somehow without affecting a remote environment? Again, good luck, sucker. Because 'the plan' is a lie. And error messages seem to be written by someone waging war against their customers. In conclusion, I do not recommend terraform. In my opinion it is an overhyped piece of technology on which I would not bet my company/money on.

cies 6y ago

I think TF is used a lot in production for a pre-1.0 "we can break what ever we want". But then I also use it, happily :)

jen20 6y ago
Terraform (core) doesn’t follow semantic versioning, so pre-1.0 does not mean that. Ever since 0.4, the number of production users made working on it rather like changing the wheels on a bus while driving down the highway full of passengers!
- cies 6y ago
  That's what I mean: it is defacto 1.0 already, just no communicated. And semver or not: pre-1.0 is pre-1.0. I was glad to read this announcement that they are making strides to get to 1.0.

te_chris 6y ago

All this energy and griping by people. Don’t get it. I’m excited for actual obfuscation. I’ve always thought tf cloud is probably the juiciest hacking target of all. All those keys.

sylens 6y ago

One of my biggest annoyances with Terraform is how you cannot start out by creating your state remotely - you have to run it first with local state and then move it to a remote backend on a subsequent run.

svavs 6y ago
Completely agree! My company has pretty strict rules for creating infrastructure in our upper environments. Devs are not able to do it and we want everything to run through our CI/CD pipeline. We either have to ask our cloud team to create the bucket or hack up our build file to add it. It would be nice, on the first run of terraform init, if it would check for the remote state bucket and then ask if you would like to create it if it does not exist.