[HN Gopher] Terraform 0.15 General Availability
___________________________________________________________________
Terraform 0.15 General Availability
Author : myroon5
Score : 71 points
Date : 2021-04-14 19:05 UTC (3 hours ago)
(HTM) web link (www.hashicorp.com)
(TXT) w3m dump (www.hashicorp.com)
| [deleted]
| llbeansandrice wrote:
| 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.
| yjftsjthsd-h wrote:
| On the bright side, now that they've committed to a stable
| state file format it should get better
| garymoon wrote:
| 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.
| mitchellh wrote:
| 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. :)
| 0xbadcafebee wrote:
| 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.
| dastx wrote:
| You can use tfenv to upgrade individual workspaces one at a
| time. You don't need to do a big bang upgrade.
|
| Note upgrading to 0.13 is quite easy and terraform actually
| has a subcommand that does most of the work you (usually no
| additional steps required).
|
| > I am already looking around for some way to remove
| Terraform from our org because it is slowly strangling our
| productivity.
|
| The only other alternatives you have are Pulumi. All other
| alternatives are in my opinion, way worse. You can use
| ansible, which I'd even worse because you have to manage
| ansible version upgrades and have no way of figuring out
| what changes will be made (yes, --diff is usually useless).
| You can manage manually, but good luck. Lastly your option
| is CFN (or Azure/GCP equivalent) but then you have no way
| of managing anything outside of the cloud environment.
| cyberpunk wrote:
| Yeah same boat. We ended up doing several complete rewrites
| and finally giving up. My main grievance is hcl, it's so
| close but so far from an actual programming language that
| it drives me mad, even after a few kilolines of it in
| prod.. we ended up going with pulumi which so far has
| served us well
| diroussel wrote:
| It seems that terraform CDK has been introduced to
| compete directly with pulumi.
|
| I think both are a great idea as the DSL has given me so
| many headaches over the years.
| Thaxll wrote:
| There is no solution where 100k loc is not going to be
| challenging to keep over time.
| pizza234 wrote:
| While it's not possible to make an apple-to-apple
| comparison (Terraform-to-?), if we compare to something
| based on an imperative language, say Puppet or Chef,
| there is a huge difference.
|
| In my opinion, Terraform's big issue is that it was born
| as a declarative tool for managing infrastructure. Large
| configurations (IMO) necessarily ossify, because you
| don't have an imperative language that makes small
| progressive changes toleratable - it's a giant
| interrelated lump.
|
| What's worse, when it grows, one needs to split it in
| different configurations, and one loses referential
| safety (resources will needed to be linked dynamically).
|
| A, say, Chef project of equivalent size, can be changed
| with more ease, even if it's in a way, even less safe,
| because you have the flexibilty of a programming language
| (of course, configuration management frameworks like that
| have of different set of problems).
|
| I'm really puzzled by the design choice of a declarative
| language. Having experience with configuration
| management, it's obvious to me that a declarative
| language is insufficient and destined to implode (and
| make projects implode). Look at the iterative constructs,
| for example, or the fact that some entities like modules
| have taken a long time to be more first class citizens
| (for example, we're stuck with old-style modules that are
| hard to migrate).
| Thaxll wrote:
| I have really bad memories of the change between puppet 2
| and 3 for example.
| sciurus wrote:
| > compare to something based on an imperative language,
| say Puppet or Chef
|
| I'm puzzled by this comparison. I consider both of these
| to be primarily declarative languages. You deckare the
| state you want puppet or chef to enforce, not how they
| get there.
|
| E.G. https://puppet.com/blog/puppets-declarative-
| language-modelin...
| diroussel wrote:
| We also found tf 0.12 to be quite slow. But this was fixed
| in 0.13 and how it feels lightning fast compared to before.
| llbeansandrice wrote:
| Thanks, good to know that the upgrade to 12 is the biggest
| jump.
| john37386 wrote:
| 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
| jasonvorhe wrote:
| 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.
| _joel wrote:
| 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)
| uglygoblin wrote:
| 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 :)
| scottsuch wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| In 0.14 that is no longer available.
| tetha wrote:
| 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.
| jokethrowaway wrote:
| 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.
| llbeansandrice wrote:
| We had this issue as well where another team was on 0.12 and
| we were still on 11 and even running a plan I think could
| ruin the state.
|
| We now have all of the systems tf version pinned:
|
| ``` terraform { required_version = "= 0.12.29" ... } ```
|
| As other said tfenv let's you easily switch between versions
| but you don't get a warning if you're accidentally on 0.12
| but the repo is currently using something else.
| _joel wrote:
| We use this https://github.com/tfutils/tfenv
| yjftsjthsd-h wrote:
| 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 wrote:
| 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...?
| darkwater wrote:
| Maybe asdf? https://github.com/asdf-vm/asdf
| diroussel wrote:
| 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 wrote:
| 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)
| 0xbadcafebee wrote:
| You can whip up something pretty quickly as a shell
| wrapper and add to it as you need. I just threw this
| together: https://gist.github.com/peterwwillis/755002d6d3
| 849af5bbc6cb8... $ cliv
| Usage: /home/vagrant/bin/cliv [OPTS]
| /home/vagrant/bin/cliv [-i] VERSION [CMD [ARGS ..]]
| Opts: -l List versions
| -h This screen -n
| Create a new /home/vagrant/.cliv/VERSION -i
| Clear current environment $ cliv -n tf012
| $ cliv -n tf013 $ cliv -l tf012 tf013
| $ cp terraform-v12 ~/.cliv/tf012/bin/terraform $ cp
| terraform-v13 ~/.cliv/tf013/bin/terraform $ cliv
| tf012 terraform Terraform v0.12.29 $ cliv
| tf013 terraform Terraform v0.13.3 $ cliv -i
| tf012 PATH=/home/vagrant/.cliv/tf012/bin:/home/vagr
| ant/bin:/usr/local/sbin:/usr/local/bin: /usr/sbin:/
| usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
| PWD=/home/vagrant
| dang wrote:
| I had to put a newline in your PATH because the unbroken
| string was borking the page layout. Sorry, it's our bug.
| Someday someone will show me how to fix it. Some people
| have come close.
| dguaraglia wrote:
| 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.
| darkwater wrote:
| 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 wrote:
| 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
| theopsguy wrote:
| If you like CDK, then i highly recommend pulumi
| k__ wrote:
| How do they differ?
| xyzzy123 wrote:
| So regular CDK is basically a program-driven CFN generator.
|
| Pulumi has a similar model where you build a resource graph
| at runtime BUT it's also got the execution engine built-in
| to the tool.
|
| What this means in practice is that you can create
| resources (like a kube cluster) and then use them as
| providers (e.g provision state tracked resources with kube
| api) all in the same operation.
|
| You can also (in code) define "dynamic providers", meaning
| you can easily extend the execution engine to do custom
| things related to your workload.
|
| Neither terraform nor CDK can really do those things very
| well. TF is not powerful enough language-wise, and in CDK
| the execution phase is locked away from you.
| justin_oaks wrote:
| Are all variables, conditionals, templating, and loops done in
| Python? Or is some of that still needed on the Terraform side?
| diroussel wrote:
| Basically you create the desired state DAG in procedural
| code, rather than the TF DSL. Blithe diffing and applying are
| the same.
| wooly_bully wrote:
| 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.
| dastx wrote:
| > 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).
|
| Maybe not node/python, but I'm pretty sure you can use
| terraform as a package in go. If not, there is always the
| "make temp dir, write/download files necessary tf files, run
| terraform apply"
| wooly_bully wrote:
| That's good to know at least; will give the go API a look.
| The latter option you're recommending is essentially what I
| went with (Node bin script that shells out to run cdktf
| commands).
| dxxvi wrote:
| 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 wrote:
| 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.
| jen20 wrote:
| You absolutely can manually fix and sync state:
|
| `terraform refresh` does this.
|
| (Disclaimer: I am an ex-core-maintainer of Terraform)
| dasil003 wrote:
| Have you ever set something up manually via AWS console, then 6
| months later totally forgot the steps you took and end up
| wasting a lot of time reverse engineering what you did in order
| to make a comparatively small change?
|
| After that perhaps you vowed to take better notes, so the next
| time you do it that way, but then 6 months later you find that
| you missed some detail, or there was some changes in between
| that were not recorded.
|
| So then you decide you're going to do everything by API and
| save the commands, so you write a bunch of bash scripts that
| execute against the AWS CLI. Over time you add several more for
| different operations (eg. adding an instance, configuring new
| ssl cert, etc), but the list of scripts grows very long, and
| you find that each one makes a lot of implicit assumptions
| about the state of the infra when its run, so you end up with
| varying degrees of confidence in the scripts depending on how
| often you run them.
|
| Now you are primed for Terraform. At this point you realize the
| hard part about cloud configuration is state management.
| Furthermore, you realize there are some common patterns of how
| different components and APIs interact with regard to serial
| dependencies and operation idempotency, however the specifics
| vary by service and by use case. Terraform gives you a standard
| substrate for state management, and a framework for developing
| service "providers" that know how to interact with APIs and map
| them to state. All of this happens in code which is
| declarative, can be code reviewed, and state which can be
| centrally tracked and shared among a large team for a clear
| audit trail.
|
| There's definitely a learning curve, but once you learn it the
| overhead is pretty small compared to the benefits, even for
| small teams IMHO.
| dkobran wrote:
| Great explanation!
| darkwater wrote:
| 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.
| moufestaphio wrote:
| > we cannot manually fix some minor mistakes of ours when
| creating resources because that'll mess up terraform
|
| In my opinion if you're doing manual fixes you're doing it
| wrong. Let's say you do your manual fix in your Dev
| environment. Do you remember to do it in Prod/whatever other
| environments you have? Are you _sure_ you did the EXACT same
| thing? Did you change 5 other things trying to fix it first?
|
| You end up with so many different deployment environments that
| are unique 'snowflakes', and when something breaks in one it
| might not affect the others cause they're in totally different
| states.
|
| It's a nightmare.
|
| In my opinion, infrastructure as code is the only way to do it
| in a serious environment.
| llbeansandrice wrote:
| 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 wrote:
| 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.
| Chilinot wrote:
| Terraform allows us to implement development practices into our
| sysadmin lives. Such as code reviews, etc.
|
| For example, at my work this is what i do to apply changes to
| our AWS setup:
|
| 1. Fetch the latest version of our git repo.
|
| 2. Create a new git branch named after the Jira ticket im
| working on.
|
| 3. Solve the jira ticket by modifying the terraform code
| accordingly.
|
| 4. Submit a pull request and assign one of my colleagues as
| reviewer.
|
| 5. They review my solution, tell me to correct some issues that
| there might be, or straight up approves my solution.
|
| 6. My PR is merged into master.
|
| 7. I download the latest master version and apply the codebase.
|
| This way we always have at least two people verify any changes
| to our infrastructure, minimizing the risk of fuckups and
| ensures solutions are as good as possible.
| hrktb wrote:
| Reading the sister comments, I kind of understand the appeal
| of terraform for huge/multi cloud infra systems.
|
| Now, managing changes in code doesn't look too far from
| dealing with kubernetes' json/yml config and applying them to
| the current cluster, provided it would be trickier when
| expanding to multiple cluster or doing complex orchestrating.
|
| I guess TF makes a lot more sense for on-premise, bare metal
| VMs ?
| DenseComet wrote:
| I think the right way is to use TF to provision the
| kubernetes cluster and underlying resources such as storage
| connections, dns, etc, and then use kubernetes to deploy
| the app.
| temp0826 wrote:
| I spent a lot of time in both sets of docs for sure (along with
| perusing the console and creating test resources manually to
| see what options and switches I might be overlooking).
|
| I think tf really shines when you start using multiple
| providers to manage things outside of the cloud though. In my
| last gig I was for example using the workspaces feature and
| auth0 provider to have separate auth stacks for our different
| envs, being able to use values created by one providers
| resources in another's was nifty
| cmeacham98 wrote:
| > we cannot manually fix some minor mistakes of ours when
| creating resources because that'll mess up terraform
|
| This is a feature, not a bug. Terraform is a tool to
| (reproducibly) enshrine your infrastructure in code. 'Minor
| manual fixes' are often left undocumented and known only to 1-2
| people, and suddenly become major problems when your
| infrastructure comes crashing down and nobody knows why it used
| to work.
| solatic wrote:
| Because the state exists regardless. When you write code that
| interfaces with AWS, there's always something that exists on
| the other side of the AWS API. The question you have is, how do
| you programmatically keep a copy of that state on _your_ side
| of the API?
|
| The naive approach that tries to do this without state in code
| goes something like:
|
| a) invoke the remote API to look for something that should
| exist b) if it doesn't exist, invoke the remote API to create
| it c) use the property of the thing to do something else
|
| What Terraform does is cleanly separate your state (don't look
| stuff up you already know exists) from the API (which is
| handled by an open-source library, aka the provider) from your
| configuration (which can now be declarative). Because the state
| and API calls are abstracted away, the configuration itself is
| much more clean, easy to reason about, and easier to maintain.
| mr_C wrote:
| Maybe an unpopular opinion but what you just described as
| "naive" is arguably a better solution than Terraform's
| overengineering.
|
| I use Ansible to manage multiple clouds (Openstack,
| AWS...etc) using a mix of custom modules and public
| collections. I don't need a "state", I couldn't care less if
| resources exist or not, upgrades between versions are smooth,
| module/collection upgrades doesn't interfere with all the
| existing resources we already have... every time I run a
| playbook I know that everything will end up just like I want
| it to be. Not bad for a naive approach I guess.
| llbeansandrice wrote:
| I haven't used Ansible so maybe I'm incorrect here but
| aren't tf and Ansible solving slightly different problems?
|
| Terraform feels like infrastructure management to me. We
| use it to provision underlying resources: Networking,
| Clusters, Nodes, Alerts, etc. All of the actual code
| deployments are entirely separate.
|
| Ansible is more of a configuration management right?
| ggregoire wrote:
| I've never used them but there are modules to provision
| stuff on AWS: https://docs.ansible.com/ansible/latest/sce
| nario_guides/guid...
| diroussel wrote:
| If you have an ansible playbook that creates a certain
| resource, and you delete that code. Next time you run it,
| it won't delete the resource because there is no state
| management.
|
| You have to add code to as only to be sure to remove the
| non-longer needed resource. But how long does that code
| need to stay there.
|
| Ansible is supposed to engender a decorative approach, but
| it's very easy to slip into procedural code. Whereas
| terraform is much more declarative.
| mr_C wrote:
| Who cares if there is a dangling dns records somewhere or
| an extra allocated floating ip? In practice you could
| just set state:absent to whatever you are trying to
| remove or just remove it manually, the latter is most of
| the time faster than dealing with state management once
| you have a behemoth in prod that no one wants to break.
| [deleted]
| erik_seaberg wrote:
| Some resources will cost money every month, forever.
| There's also a risk that your legacy environment only
| works because a dangling resource wasn't cleaned up, and
| a new clone of the environment will fail.
| kstrauser wrote:
| "I just spent a couple of hours standing up a specific
| resource, which was kind of a pain in the neck. Oh, now I need
| 23 more of them! That'll take another 30 seconds to generate
| the configuration and create the new resources."
|
| That's why I like Terraform.
|
| Edit: "Also, I created a thing 2 years ago and now I need
| another one. Oh, here it is in Terraform." It's incredibly nice
| not to have to re-learn how to make that thing, and remember
| what its quirks and dependencies are.
|
| In short, I consider Terraform exactly like I consider shell
| scripts: it's not _perfect_ , not by a long shot, but once you
| have it working it tends to stay working and you don't have to
| invent it again the next time you need to do something.
| dastx wrote:
| Reproducible infra, gitops, automation and much more.
|
| For me, the biggest thing is, when I go into AWS I struggle to
| find everything that is intrinsically linked to another
| resource. Say you have a lambda, to find which iam is linked to
| it, and what permissions it has is 2 separate tabs, then
| another for e.g. security groups, probably more tabs for other
| things. While using aws-cli makes it slightly easier, it's
| still a lot of effort to do this effectively.
|
| With terraform I can look in one repo that has all the above,
| often in the same file too. Finding out what your infra looks
| like is a lot easier.
|
| Regarding the state, you should not be touching your infra
| outside your code, if you do (e.g. while you're testing in
| dev), you should make the same changes in tf once you've
| confirmed it's what you want, and otherwise you undo those
| changes.
|
| With further automation (e.g. tfcloud) you can even enforce
| these things by auto applying workspaces which ensures manual
| changes are always undone.
___________________________________________________________________
(page generated 2021-04-14 23:00 UTC)