11 ms·

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

• 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.
  • throwdbaaway 5y ago
    Ansible? Compared to terraform, it should require less effort from the user, without having to worry about states. Compared to aws cloudformation or gcp cloud deployment manager, it should require less effort as well, without having to learn the different idiosyncrasies of these proprietary tools. > It's just drivers for the cloud API in question Exactly, and if you are on gcp, both the ansible modules and the terraform modules are even generated from one code base: https://github.com/GoogleCloudPlatform/magic-modules https://github.com/GoogleCloudPlatform/magic-modules
    • akvadrako 5y ago
      I used ansible for AWS a few years ago - it's terrible. Not by design, just that most of the modules are buggy and incomplete.
• Chilinot 6y ago
  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 5y ago
    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 5y ago
      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.
    • erik_seaberg 5y ago
      Also cloud hosted services. E.g., terraform knows how to manage hundreds of AWS resource types (IAM roles, DynamoDB tables, S3 buckets), sometimes even before CloudFormation does. There seems to be some kind of https://github.com/aws-controllers-k8s/community https://github.com/aws-controllers-k8s/community in early beta, but I don’t know how much it supports so far or whether it can diff a resource and modify it in-place.
    • sciurus 5y ago
• temp0826 6y ago
  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 6y ago
  > 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 6y ago
  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 6y ago
    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 6y ago
      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 5y ago
        I've never used them but there are modules to provision stuff on AWS: https://docs.ansible.com/ansible/latest/scenario_guides/guide_aws.html https://docs.ansible.com/ansible/latest/scenario_guides/guid... Edit: seems limited to ec2 and s3: https://docs.ansible.com/ansible/latest/collections/amazon/aws/index.html#plugins-in-amazon-aws https://docs.ansible.com/ansible/latest/collections/amazon/a... Although you could provision other services with some custom modules using the aws-cli.
• kstrauser 6y ago
  "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.
  • matwood 5y ago
    > "Also, I created a thing 2 years ago and now I need another one." Let me add, this thing was changed 2 years ago to add an option...why? Git blame to the rescue... I probably use git history more in my tf code than in my regular programming.
    • pm90 5y ago
      Absolutely invaluable to have this, especially for infrastructure changes which often involve ugly hacks to get around limitations but which may just not be clear at first.
• dastx 6y ago
  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.
• jen20 6y ago
  You absolutely can manually fix and sync state: `terraform refresh` does this. (Disclaimer: I am an ex-core-maintainer of Terraform)
• dasil003 6y ago
  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 6y ago
    Great explanation!
  • aprdm 5y ago
    The jump from what you mentioned in paragraph 2 to 3 is not necessarily Terraform. You can use other tools, like Ansible, that IMO have a much better framework than Terraform. I use Terraform for extremely simple stuff that is easy to destroy/recreate. Projects of bigger scale IMO are better served with Ansible and friends.
    • themacguffinman 5y ago
• moufestaphio 6y ago
  > 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.
  • kstrauser 5y ago
    I think there's a middle ground if you're not sure how to fix a mistake in Terraform but you know how to do it in the console: * Make your changes by hand * Right afterward, run "terraform plan" to see how Terraform would undo your changes * Edit your Terraform config to reflect those changes, and run "terraform plan" again to make sure you caught everything. Repeat until it's a no-op. Now you've got a log of what you've done in a Git-ready format, and you can repeat it elsewhere, and you've learned how to make that console change in code.
    • matwood 5y ago
      You can do it that way, but I find the tf docs easier and more concise to use than clicking around the AWS UI.
      • kstrauser 5y ago
        I do too, but that was an invaluable tool when we were first switching over and learning the ropes.
    • pm90 5y ago
      This. I’m surprised at how many folks don’t realize you can do this and capture your changes in terraform by looking at the plan and making tf code changes until the plan doesn’t show a diff
• csomar 5y ago
  > we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform I find this to be the best advantage to Terraform. These small changes make your infrastructure harder to re-produce in the future; and unless you have strong documentation rules, you lost what is there in your infrastructure.
• matwood 5y ago
  > we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform I had an old boss who fixed minor mistakes in stored procedures on the live server and then wondered why they broke again when builds went out...
• darthrupert 5y ago
  You are not supposed to do anything manually ever in a cloud environment managed by a declarative tool. That's not just for terraform but for all of them.
• manojlds 5y ago
  You can definitely manually fix something and then just have to update the terraform code and it should be fine. But it depends on what kind of manual fix you are doing as some changes are inplace while some require recreation.
• takeda 5y ago
  Well... I'm puzzled about it on AWS. I don't know about Azure, but on GCP I tried their equivalent of CloudFormation and it was absolutely POS. Reported a bug in their repo, and got response acknowledging the bug, but it's in specific component's API that is owned by another team (within Google of course) and there's not much they can do about it. Like WTF? Do they think I have better chance reaching them than them? Tried then TF and it was much simpler and everything worked as expected. On AWS though, seriously, TF is inferior.