201–210 of 315 posts
Earlier quoted context omitted.
What better tools do you have in mind? Most of the people I know in the space have been moving _to_ Terraform, although CDK has improved enough over CF to be appealing for people who are all in on Amazon.
"better" is subjective. But Pulumi fixes a lot of the pain points of terraform for me.
Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…
I haven't done a lot of infrastructure work in the past few years so haven't stayed super on top of the latest changes. I last used it heavily in the earlier days, roughly 4-7 years ago now. And while a lot of the community was great, put in a lot of work on the product, and generally wanted to improve the tool, there were also a lot of very vocal stodgy old timers that were really resistant to any improvements from…
Terraform has been a great tool and it's always surprising to me to hear people hating on it.
People tend to complain about HCL a lot, I think it’s a great language for infrastructure. I don’t want a “real programming language” for provisioning infrastructure. I feel like every time I’ve seen someone “need” a real programming language, that there is a _better_ way to do the task at hand with HCL. That being said, there are some ugly bits. 1. Remote state as a data source means your infra is broken, you just d…
I'm not sure I understand #1. Your points would still apply if a resource (e.g. aws_instance.foo) is created in one module and then referenced as a data source (e.g. data.aws_instance.foo) in another module. Are you suggesting remote state is different? Or would you also advise against referencing data source attributes from resources created in other modules?
In #1 there is also a tight coupling between two different sources. If team A changes their output, the dependent team B's references break.
Also 1.2: security. If I can read an attribute from your state file, I can read the whole thing.
Earlier quoted context omitted.
100%. Terraform is half-way between a tool for generating the configuration and applying it. I think Terraform's application engine is actually quite good, but I would like to use a much better tool to generate the config. (And be able to diff that config) You can feed JSON to Terraform however this falls over if you need dependencies for output values. This usually isn't an issue because most Cloud provider resource…
You may be interested in Pulumi: https://www.pulumi.com/ Basically it's Terraform but instead of declaring your resources in HCL, you declare them in a real programming language. You're still producing a declarative config that the engine then diffs, applies etc. In fact, it's compatible with existing terraform providers, so it has a surprisingly large selection of things you can use it for. Note their docs will try…
There is a dupe Terraform post on Hacker news frontpage. I'll post my comment here too :-) I recommend breaking out your terraform code into separate folders and calling them "components". Write a wrapper around the terraform script to pass in -var-file which uses an argument called ENVIRONMENT that you pass to the wrapper. I think the built in support for modules is less useful for what you actually want to do becau…
I've been using Terragrunt to keep my Terraform DRYU in a similar manner. It's a bit of a rethink in how you structure things but I've been happy so far. https://terragrunt.gruntwork.io/
Earlier quoted context omitted.
> Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. CloudFormation ? > There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. CloudFormation.
Yeah, CloudFormation is workable in this regard (I've created a neat generator for Python), although it has lots of its own problems (e.g., if you want to create a new resource, you have to run it as its own lambda--your infra-as-code needs its own infra which needs its own infra-as-code).
care to share? (I know some hn users often don't w/o being asked, out of a sense of not wanting to be seen as self-promoting.)
For example, could the following be library functions that you could glue together in the programming language of your choice: (a) get current state of infra, (b) calculate diff between desired state and current state, (c) perform a single step (safely) that represents a granular change in infra, (d) perform a series of steps representing infra changes with safe rollback?
Does something like this already exist?
I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…
Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential.
I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting.
Experiences appreciated!
Earlier quoted context omitted.
> Two years ago I looked into it and rather then having an abstraction from cloud providers This is a misrepresentation I've seen multiple times and I don't know how it's come to be. Terraform doesn't abstract resources. It simply supports all cloud providers and lets you intermix resources from different clouds inside a single project. Resources can depend on each other and use each other's attributes. As an example…
I believe the issue is the Terraform has been labelled: “Cloud agnostic”. That was why I believed that Terraform would abstract away the individual cloud providers. It depends on your interpretation of the word “agnostic”. Personally I would say a more correct description would be: Support for multiple cloud providers.