15 ms·

Terraform 0.12

• aynawn 7y ago
  Finally
• bshacklett 7y ago
  My biggest hope is that this means that some effort can be directed back to fixing bugs. I love what terraform can do, but I hate what I sometimes need to write to make it work. Also, I'll go out on a limb and say that I dislike the flexibility of iteration allowed in HCL 2. I know that people overwhelmingly asked for it, but my opinion is that it demonstrates a fundamental misunderstanding of how the v. 11 and earlier system was designed, and just how powerful completely declarative code can be.
  • kawsper 7y ago
    The biggest issue we have with Terraform (and other Hashicorp tools in general, really) is their different configuration formats, but mostly it is HCL limitations. I haven't found a solution for it, but I have lots of resources that are almost identical, except for a few arguments, but right now it seems like my options are to either write my own Ruby script to output .hcl files, or live with two resources that are almost identical, and live with the mistakes that could entail by future modifications. I haven't had the time to look into HCL2 yet, but maybe it is solved.
    • solatic 7y ago
      You can't write a local module for the resource that takes the differences as inputs?
      • kawsper 7y ago
        Maybe I can, but I am failing to grasp how templates or the modules work, we have these resources where only the ami is different (and sometimes the count): resource "aws_instance" "nomadclients_tick" { ami = "${data.aws_ami.nomadclient_tick.image_id}" instance_type = "t2.micro" count = 3 iam_instance_profile = "${aws_iam_instance_profile.consul-join.name}" subnet_id = "${element(aws_subnet.consul.*.id, count.index)}" vpc_security_group_ids = [ "${aws_security_group.rule01.id}", "${aws_security_group.rule02.id}", "${aws_security_group.rule03.id}", "${aws_security_group.rule04.id}", ] } resource "aws_instance" "nomadclients_tock" { ami = "${data.aws_ami.nomadclient_tock.image_id}" instance_type = "t2.micro" count = 3 iam_instance_profile = "${aws_iam_instance_profile.consul-join.name}" subnet_id = "${element(aws_subnet.consul.*.id, count.index)}" vpc_security_group_ids = [ "${aws_security_group.rule01.id}", "${aws_security_group.rule02.id}", "${aws_security_group.rule03.id}", "${aws_security_group.rule04.id}", ] } The examples I have found feels very difficult.
        • farzadb82 7y ago
          One way I can think of that will solve this problem is to do something like: resource "aws_instance" "nomadclients" { ami = "${count.index > 2 ? data.aws_ami.nomadclient_tick.image_id : data.aws_ami.nomadclient_tock.image_id}" instance_type = "t2.micro" count = 6 iam_instance_profile = "${aws_iam_instance_profile.consul-join.name}" subnet_id = "${element(aws_subnet.consul.*.id, count.index)}" vpc_security_group_ids = [ "${aws_security_group.rule01.id}", "${aws_security_group.rule02.id}", "${aws_security_group.rule03.id}", "${aws_security_group.rule04.id}", ] } The downside to this approach (in TF < 0.12), however, will become apparent when you want to modify the number of instances in one or both pools. This arrises from the way hcl v1 manages the counter index with each resource in the state; That is each resource is linked to a specific index and when that index is altered in someway, terraform will attempt to adjust the resources at each respective index accordingly. Because of these headaches, we decided to abandon hcl for these use cases and ended up writing our own preprocessor that takes a JSON configuration and generates individual JSON-based HCL (ie. .json.tf) that terraform can then use. We can leverage proper templating to generate many variants of a single resource in a higher level language, while still using terraform to manage the infrastructure and it only adds one additional step to the plan + apply process.
          • vegardx 7y ago
            Alternatively you could put the AMIs in an array, and just iterate over that array. locals { nomad_ami = [ "${data.aws_ami.nomadclient_tick.image_id}", "${data.aws_ami.nomadclient_tock.image_id}", ] } resource "aws_instance" "nomadclients" { count = 6 ami = "${element(local.nomad_ami, count.index)}" ... }
        • mhotchen 7y ago
          I personally would solve this issue with a local module (very easy to set up, just a subfolder with a main.tf that defines the resources[0] then it's called as here[1]) with two input variables[2]: a required ami variable, and an optional count variable which has a default of 3. I hope that helps. [0] https://www.terraform.io/docs/modules/index.html https://www.terraform.io/docs/modules/index.html [1] https://www.terraform.io/docs/modules/sources.html#local-paths https://www.terraform.io/docs/modules/sources.html#local-pat... [2] https://www.terraform.io/docs/configuration/variables.html https://www.terraform.io/docs/configuration/variables.html
    • kitotik 7y ago
      How does a var, template, or even a generic resource that runs a local script not solve this problem?
    • ivan_ah 7y ago
      +1 for the question about a "standard" or recommended way to parse and generate .tf files from a script. I have two use cases in mind: Use case 1: need to have a reproducible way to generate terraform folders for multiple almost-identical deployments (this can be solved via modules) Use case 2: need way to "promote" a deployment from staging to production (load a .tf file, change a few basic params then save again to a different folder --- doesn't really work with templates since I want to load an existing .tf file) One thing that might work is to use the combination of two tools: - https://github.com/virtuald/pyhcl https://github.com/virtuald/pyhcl = reads .tf, can export .tf.json - https://github.com/kvz/json2hcl https://github.com/kvz/json2hcl = convert .tf.json to .tf but feels hacky... Any other recommendations for .tf parsing and generation? (preferably in python or scriptable via python)
      • robfig 7y ago
        Your favorite tool that produces json should be able to work. I'd probably use jsonnet, which has a multi-file mode so that one template file can render into many json files.
    • crucialfelix 7y ago
      You can actually use JSON files in place of HCL: https://www.terraform.io/docs/configuration/syntax-json.html https://www.terraform.io/docs/configuration/syntax-json.html main.tf.json
  • kraig 7y ago
    IMO they should have dumped HCL once they caught a whiff of what Pulumi is up to, much rather go with actual languages that when you learn them, you pick up some valued knowledge. You can also do a whole lot more with Typescript than you can with HCL 2.
    • argd678 7y ago
      Agreed, the data model of Terraform simply doesn’t match the problem domain. You need an algorithm to codify the pattern and then data to fill in the params. Terraform doesn’t allow you to create the patterns you need in a way that’s debugable and doesn’t allow for code reuse. For simple setups it’s not apparent there’s a problem but when they get more complex it’s nearly impossible to use. Additionally you have to rewrite everything for each cloud provider, so it just expands the work required, all with no real IDE integration. I’d just write against the cloud provider APIs directly or look at Pulumi when they get interactive debugging.
      • dvtrn 7y ago
        I wouldn’t say it becomes impossible to use at scale, what happens at scale with terraform, but rather the opinionated nature of HCL makes itself present in ways you probably won’t ever have to deal with if you’re shepherding very small fleets or single serving resources. Personally I’m excited that loop operations now exist in 0.12 But thanks for the reference to Pulumi, had not heard of this and it looks very interesting.
      • oneplane 7y ago
        The Terraform language extension in VSCode is very good.
        • org3432 7y ago
          It's not good, it doesn't understand the TF types and recommends values that are invalid for the context, there's no inline help (you have to go look it up on the website), refactoring a variable name doesn't fully work, and you can't set breakpoints or trace through the execution to determine what's going on... I mean it's practically in the mid-80s, although most of those things worked even back then. The lesson here is that if you plan on making a language, even a DSL, you want to be sure you're really up for it since it's a lot of work.
• alexbanks 7y ago
  I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.
  • techntoke 7y ago
    Agreed about CF. AWS puts a huge emphasis on CloudFormation when they know it is sub-par. Ansible is pretty cool too because you can easily convert between YAML/JSON for CF, and add a lot of flexibility based on variables and other things such as error handling that you can't do with Terraform.
    • deboflo 7y ago
      Definitely not subpar. Cloudformation is an incredible service. I’ve used it to deploy thousands of stacks. It just works.
      • mirceal 7y ago
        does it rollback in the face of failure? /s
        • reilly3000 7y ago
          https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
          • mirceal 7y ago
            i know, hence the /s it was a jab at Terraform’s behavior
    • joseph 7y ago
      I don't agree it is subpar. I have a fairly long list of reasons for preferring CF over Terraform. I agree on combining CF with Ansible though. My recipe is to wrap a CF template in an Ansible role. It makes for a versioned chunk of automation that composes well with my other roles, including ones that are not CF based. Plus I can do non-CF setup tasks using any Ansible module, and even run tests, to get pretty much full end-to-end automation for a given stack. I haven't found a way to get the same degree of power and flexibility from Terraform without resorting to writing custom plugins.
• nodesocket 7y ago
  Terraform and Packer are the two most common tools I use with my DevOps consulting company. Most all of my clients previously were creating cloud resources manually within the U/I control panel. Moving to Terraform is a game changer in terms of transparency, auditability, and automation. With the release of Terraform Cloud[1] which provides centralized state storage, locking, history, and integration with GitHub the HashiCorp stack is a no-brainer. [1] https://app.terraform.io/signup?utm_source=banner&utm_campaign=intro_tf_cloud_remote https://app.terraform.io/signup?utm_source=banner&utm_campai...
• techntoke 7y ago
  I moved away from Terraform a long time ago. Ansible was way more powerful, handled errors and issues with state changes. Terraform was super picky about how you had to operate, slow and HCL was a terrible markup language. I wasn't really a huge fan of Ansible either though and more recently have been doing things in regular shell/Bash scripts. Now with Kubernetes and service brokers, there is no need for Terraform.
  • james_s_tayler 7y ago
    What about setting up and tearing down EKS clusters? I haven't used terraform but I learned about it through looking at this: https://learn.hashicorp.com/terraform/aws/eks-intro https://learn.hashicorp.com/terraform/aws/eks-intro So, I'd say Kubernetes itself does more heavy lifting but not all of it?
    • CrossWired 7y ago
      I use Terraform to create EKS, works pretty well. I have it setup to use Spot instances with a standard compute node as well as GPU nodes when needed. https://github.com/JasonCarter80/contoso_aws_k8s/tree/master/15_kubernetes https://github.com/JasonCarter80/contoso_aws_k8s/tree/master...
    • techntoke 7y ago
      Spinning up an EKS cluster is something you usually do once, and if you need multiple EKS clusters then you can bootstrap others from an initial cluster that you deploy with eksctl or AWS CLI.
  • kitotik 7y ago
    While there is certainly overlap, these products are trying to solve different problems. Ansible seems to focus on managing infrastructure, Terraform shines when creating infrastructure.
  • n42 7y ago
    Ansible can very easily, and often does, end up in situations where two runs of the same playbook both have drastically different results. roles/playbooks slowly become Bash scripts written in a YAML layer parsed as a Jinja2 template.. and the project turns into a mess of many layers of indirection. it attempts to and encourages declarative configuration, but is very hard to keep that way. it is difficult and requires determination to make Terraform do something in a non-declarative fashion. the end result is that when I look at a Terraform configuration I can very easily tell what is going on, because the end result is exactly what I read. where with Ansible, it very much depends on understanding the current state of the server you are about to run this playbook on, and you just have to cross your fingers and hope for the best.
• SlowRobotAhead 7y ago
  I’m a little unclear on terraform in practice. As you supposed to download this, use it’s language and syntax which is all it’s own thing, to define you services and then export that to a YAML setup that AWS CloudFormation (for example) is expecting? I assume there are reasons I wouldn’t just define it myself in YAML directly?
  • s09dfhks 7y ago
    there's no exporting. You write everything in there format to define your infrastructure, and then terraform turns it into AWS API calls
    • SlowRobotAhead 7y ago
      That makes sense. Now, other than the portability of AWS to Azure to GCP, why do I want this? Because with CloudFormation I can pull down and put up my “stacks” in layers and this isn’t necessarily the same as API calls (although on the backend maybe it is).
      • pseudalopex 7y ago
        Terraform can manage much more than AWS, Azure, and GCP.[1] [1] https://www.terraform.io/docs/providers/ https://www.terraform.io/docs/providers/
  • NikolaeVarius 7y ago
    No. It invokes infra changes directly, Cloudformation doesn't enter into this at all
  • EdwardDiego 7y ago
    Basically Terraform is cloud agnostic, so you can (theoretically) define something in Terraform and then use it on AWS, or GCP, or Azure.
    • merlincorey 7y ago
• n42 7y ago
  Congratulations to the team for a monumental release! The significance of the changes involved to ship 0.12 seems understated. This release paves the path to implement many highly requested features and fixes. Most noteworthy of which, in my opinion, is module counts.
• Ycros 7y ago
  Good stuff. It looks like they've addressed a few of the ergonomic issues in their language with this release. The old way of doing iteration and having to use string interpolations just to reference variables were annoying.
  • mirceal 7y ago
    Hashicorp got it right with Vagrant and its Ruby-based DSL. At the end of the day you could always drop down to a proper programming language and express what you wanted if the DSL was lacking. Why they had to invent this HCL monstrosity is beyond me.
• deleted 7y ago
  [deleted]
• reilly3000 7y ago
  I've been chasing infrastructure-as-code for a while, but I keep getting blocked by Terraform missing provider APIs (GCP Cloud Function Runtimes outside Nodejs, most recently), Kubernetes complexity, and generally being too lazy to sit down and bang out something in code that I can quickly iterate on with a console or quick CLI commands. I've had some wins with Serverless Framework, but outside that I've yet to see the payoff from the time I have put towards it. Am I defective?
  • colechristensen 7y ago
    Just not working at a large enough scale. Infrastructure as code becomes progressively more important as you add resources until you're at the point where terraform does the job of a whole team of administrators who would be spending all day clicking through UIs.
  • luhn 7y ago
    The UI is often a good way to quick get things done. Terraform requires a bit more investment, but has a huge payoff in the long run. Personally, I think staging/production is the greatest advantage. I can experiment and break things on staging, then when I apply the plan to production I can be confident I’m getting the same infrastructure. Infrastructure-as-code brings many programming amenities. You can write comments. You can easily see what a resource depends on and you can grep the repository to see what depends on it. You can version control it, which gives you a record of who changed what and possibly why. You can do code reviews. It does take more time then clicking through a UI, but I can’t imagine operating all but the smallest infrastructure without Terraform or similar.
  • merb 7y ago
    to be fair for kubernetes deployment you don't need a lot of knowledge. either use k3s or kubespray and just edit some variables. (baremetal)
  • linuxftw 7y ago
    No not defective; sounds like you could use some ansible in your life. It's easy to misuse ansible though. People try to consume it like puppet and use it for whole-system-declarative-state, which is usually not worth the squeeze in ansible. Treat it as glorified bash-scripting with smarter data handling and yaml-driven config files, and you'll have success.
• avitzurel 7y ago
  We are very heavy users of terraform. We have thousands of lines of HCL and our own providers etc... Terraform 0.x before 0.12 was heavily limited due to the syntax, you just worked around so many limitations. We are actively ignoring those limitations and we started working without our own templates using jinja that just generate vanilla terraform. No counts and no if/else needed. Maybe with .12 we can move some of these back to plain terraform. Upgrade so far is not smooth though, there are a lot of pains with the type system vs the plain old “I’ll figure it out for you”. ALL of this being said, I really appreciate Hashicorp’s work on this, we could not imagine our life without terraform.
• rossmohax 7y ago
  Language improvement is nowhere match to what Pululmi brings to the table without sacrificing any features.
• luhn 7y ago
  I’ve been very excited for this release. I’m a huge fan of Terraform—When I first started using it I quickly couldn’t imagine working without it, despite its many rough edges. But it continues to improve (I can think of very few projects that have had such large and consistent improvement) and this release is another huge step forward. Props to Hashicorp for the great work.
• zeeZ 7y ago
  > Terraform 0.12 is a major update Looks like a minor update to me...
  • IloveHN84 7y ago
    Before stable version x.y.z, if x is 0, then y means major
    • rurounijones 7y ago
      I am astounded that after all this time it is still 0.y.z I mean, it has been around for like 5+ years... I am even more astounded that people are happy to use a product that by its own definition is not stable. Same happen in ruby a lot. You find a Gem that claims to follow semantic versioning and it is still in 0.y.z after years of being used in production which flies in the face of https://semver.org/#how-do-i-know-when-to-release-100 https://semver.org/#how-do-i-know-when-to-release-100
      • hedwall 7y ago
        Where does Terraform claim to follow semver?
        • IloveHN84 7y ago
          Where doesn't it claim it? Using a versioning scheme like x.y.z _by default_ means semver
          • NikolaeVarius 7y ago
            No it doesn't. Why would you think it does?
        • rurounijones 7y ago
          I never said it did. I said rubygems did and often fail at following that. However I know of no common versioning scheme where 0.y.z is considered production ready.
• kkapelon 7y ago
  If you love terraform, please also look at Pulumi (I have no affiliation with them). https://pulumi.io/reference/vs/terraform.html https://pulumi.io/reference/vs/terraform.html https://github.com/pulumi/tf2pulumi https://github.com/pulumi/tf2pulumi
  • vegardx 7y ago
    I see there's a way to not use the hosted service for storing state files, but how do you address things like locking in Pulumi?
    • kkapelon 7y ago
      I haven't used that scenario, but you are responsible for locking. I guess if you use S3 or something similar to store/retrieve state you can easily make it work.
  • doliveira 7y ago
    Honestly I like the idea of using declarative code for infra stuff because this way it becomes an inventory-like configuration language. There is a reason why YAML dominates today.
    • kkapelon 7y ago
      Terraform does not use YAML. And in the last updates they try to make their HCL more "programming language like". Pulumi is already there (they are using an actual programming language)
      • doliveira 7y ago
        Of course Terraform does not use YAML. I mean that YAML or other approaches like HCL allow for a declarative style while maintaining some constructions like for-loops or conditionals. Having your infrastructure in an inventory-like codebase makes it clearer to reason about. It can't go too crazy like most programs end up like
    • 7y ago
• ses1984 7y ago
  People often complain about HCL being very limiting, that they are sick of templating HCL, etc. Has anyone tried the approach of writing some go code that imports terraform, rather than using the terraform CLI? This would give you the full power of golang to set up your resources.
• vander_elst 7y ago
  I work heavily with the Deployment Manager from GCP, so I am basically used to describe the infrastructure using python. What seriously bugged me about TF is how difficult it was to do simple stuff like having a nested loop within a resource. I know that 0.12 is supposed to help there and I am looking forward to the moment where TF will evolve into a proper programming language, supporting saner formats (already happening with json integration).
• anon1253 7y ago
  For a second I confused this with TerraGen (https://planetside.co.uk/ https://planetside.co.uk/) and got all excited about reliving a nostalgic youth.
• scarejunba 7y ago
  The upgrade path for this has been an absolute nightmare, made worse by the fact that we sat on the `google` provider 1.16 (lots of GKE stuff like node taints was moved out to `google-beta` in `google` 2.0 and TF 0.12 requires `google` 2.5 at least). There isn't even a straightforward transformation for many things. I get why it's this way, but brace yourself. I also made the mistake of `terraform plan`ning and updating my code as I went along. Just use `terraform validate`. Otherwise you're going to inadvertently promote the statefile before you're done dealing with all the issues (and you don't want that because it prevents you from aborting your upgrade and switching back to 0.11 till you're all ready). Not a real problem because the statefile is versioned but an annoyance nonetheless. The type issues were mostly easy to deal with, except for where things that were assignments now being blocks. For instance, look at this: master_authorized_networks_config { cidr_blocks { cidr_block = "10.0.0.0/8" display_name = "Example /8" } cidr_blocks { cidr_block = "10.1.2.3/32" display_name = "Example /32" } } That looked like: master_authorized_networks_config = { cidr_blocks = [ { cidr_block = "10.0.0.0/8" display_name = "Example /8" }, { cidr_block = "10.1.2.3/32" display_name = "Example /32" }, ] } before and `terraform 0.12upgrade` isn't about to help you navigate this. Especially if you previously assigned from a variable. In that case, it's going to make this monstrosity of a `for_each` over that thing. Jesus Christ. Still, I'm thrilled for the new stuff with the more type-safety. Not going to complain. If this is the price, then I'll pay. I just wish they'd done more to help the upgrade, but it's an 0.x release so fine.
• marenkay 7y ago
  As someone using Terraform from it's first release on I still think that Terraform has one fundamental flaw: It always looks at things using provider specific resource, while IMHO it should just expose a bunch of predefined resource types (see rOCCI specs e.g.) and then allow you to attach a specific provider to it. IMHO the biggest win as a user would be having not to have an implementation for every provider over and over. Do we really need to have a consul module for Azure, AWS, Tudeluuu and god knows who? No. That being said, Terraform in the long run still is the most reliable tool in that space. The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state.
  • ben0x539 7y ago
    > The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state. Hm, can you elaborate? S3 state seems perfectly serviceable, and I don't immediately see why I would want to operate on-prem resources just to maintain state.
    • zwischenzug 7y ago
      Sec policies.
      • marenkay 7y ago
        This, and also total lack of control.
    • marenkay 7y ago
      S3 is Amazon. In some cases you want to exert control over your state without being dependent on external parties. Currently Terraform Enterprise is the only approach to solving that and its a good one but... only if you're one of the big guns and even those sometimes think twice because the infrastructure state requires much more security than that offers.
      • 7y ago
• sriku 7y ago
  From a language and semantics perspective, any comparisons to Nix?
• k__ 7y ago
  Terraform still isn't stable? On the other hand, I'm usong React-Native, lol
• mellab2 7y ago
  Terraform is an amazing piece of technology but the biggest thing holding it back is HCL. I guess the intention was for it to serve as a happy middle ground between a full blown programming language and a configuration language - enabling some abstractions, but yet rigid enough to stop developers getting too carried away. I think unfortunately that trying to have it both ways doesn't really work and ends up leaving those writing the code frustrated - it's almost as if it's teasing you - you can feel there's all this power under the hood and you are given things like modules which are nice, but you always feel like you're on a of short leash. I switched from Terraform to Pulumi for a personal project recently and haven't looked back (no affiliation). Writing it with Typescript means you get excellent IDE support (using VSCode here) and access to the enormous JS ecosystem. I've also found myself creating a number of useful abstractions - that I would never have bothered to with HCL - like IAM helper functions, eg: const limitedReadAccessPolicy = createPolicy( "product-table-read-access", allow( ["dynamodb:Get*", "dynamodb:Query"], [table.arn, interpolate`${table.arn}/index/*`] ) ); vs resource "aws_iam_policy" "product_read_access" { name = "madu_${var.env_name}_product_read" policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Action": [ "dynamodb:Get*", "dynamodb:Query" ], "Effect": "Allow", "Resource": [ "${aws_dynamodb_table.products.arn}", "${aws_dynamodb_table.products.arn}/index/*" ] } ] } EOF }
• robfig 7y ago
  Question that's been bugging me and I haven't quite wrapped my head around -- For light usage, I find managing Terraform's state to be a significant hurdle. You basically have no choice but to set up secure remote storage unless you want to check passwords into source control. In contrast `kubectl apply` is so easy to use since it's stateless. It just creates or updates any resources provided, and it even supports --prune if you want the set of configuration to be treated as comprehensive. It seems like the main things that Terraform adds: 1. The ability to work with providers that require you to store their generated IDs to reference later. With kubernetes, the kind and name of the resource is enough to identify it; it does get assigned a UID, but you don't have to include that in the configuration since keys that are excluded are left as-is. 2. The ability to work with multiple different providers. I'm not sure how often you do have a single terraform project(is that the term?) with more than one provider, but I guess using the same set of tools, even if the configuration is provider-dependent, is nice. Is that accurate? Does Terraform offer any other advantages? If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration?
  • Znafon 7y ago
    Terraform shine when you combine multiple providers, kubectl manages Kube but Terraform helps you integrate K8s with the rest of your infrastructure (monitoring, Sentry,GitHub and GitLab, etc.) > I find managing Terraform's state to be a significant hurdle Have a look at https://app.terraform.io/signup/account https://app.terraform.io/signup/account, it's the free version of Terraform Enterprise and it makes managing your state very easy. >If you were building a configuration mechanism for your system from scratch to allow your users to configure it as code, would you make .a Terraform provider over a command line tool that can apply [--prune] that same configuration? I would make a Terraform provider, you get plans, modules, the possibility to integrate with other providers easily and creating a new Terraform provider is actually very easy!
• didip 7y ago
  First of all, I don't want to dismiss the fact that terraform is a great tool and mostly on the right path. But HCL is giving me Puppet DSL PTSD. Folks at Hashicorp should just embed JS engine and let users write definitions using a real language (JS). It's totally doable using library such-as Otto.