141–150 of 315 posts
Not sure about pulumi, but AWS CDK and CloudFormation can't handle that as one step (there are some horrific hacks). With Terraform it's absolutely trivial.
I was liking CDK up to that point, but that limitation is a complete deal breaker for me. Had to come back to my old friend Terraform.
Earlier quoted context omitted.
I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…
You can reduce a little bit of the repetition in YAML with anchors. There are tools that convert JSON/YAML into HCL. https://learnxinyminutes.com/docs/yaml/#:~:text=yaml%20also%...
The Python/Go/etc script is what humans interface with, and it is DRY. The YAML/HCL/etc is what the Terraform engine operates on and humans should very rarely need to interact with this.
Earlier quoted context omitted.
I don't know if people have even tried Pulumi before recommending it. I've tried it, and it has buggy defaults, diff generation, etc. Each time I applied the same code, it would generate a diff based off of some internal defaults and... recreate the exact same infrastructure by _tearing it down_ and making it fresh. Not ideal. Would advise using the TF CDK specifically.
> Each time I applied the same code, it would generate a diff based off of some internal defaults and... recreate the exact same infrastructure by _tearing it down_ and making it fresh. Not ideal. Not quite the same, but in vanilla Terraform if you simply rename a resource it will tear it down and recreate it even though the resource itself hasn't changed. Makes refactoring really painful. I think you can work around…
terraform state mv [old name] [new name]
Earlier quoted context omitted.
I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…
This would be great. Perhaps it could be based on https://dhall-lang.org/
As an aside, I think functional concepts could have made their way into mainstream programming much earlier if the FP people would have been willing to lower themselves to syntax that is readable to us plebs--I think this is no small part of Rust's success. People say syntax doesn't matter, but I disagree.
Earlier quoted context omitted.
You can reduce a little bit of the repetition in YAML with anchors. There are tools that convert JSON/YAML into HCL. https://learnxinyminutes.com/docs/yaml/#:~:text=yaml%20also%...
I think you misunderstand the problem I'm trying to solve, or maybe I misunderstand your response. My goal isn't to write YAML instead of HCL, my goal is to get rid of HCL and Terraform semantics altogether. If I had my way, Terraform's low level engine would operate on a verbose (i.e., "not DRY") YAML (or JSON or HCL or I don't care) description of resources which would be generated from (for example) a Python scrip…
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…
I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…
Terraform-CDK, as of now, needs to go through standard HCL parser. Sadly, there is no backdoor into Terraform's internal structures. If HCL (as a language) is the limitation for you, the CDK does not let you fly around it.
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.
However, you can develop cloud agnostic modules that you can then consume, which allows for a decent cloud-agnostic experience.
Earlier quoted context omitted.
It's a very interesting point. I've been part of managing rather large Terraform infrastructures (1000+ resources) for a couple of years, but I'm a Pulumi n00b with only about a month of experience. The infrastructure I'm managing right now with Pulumi is much smaller, only around 130-140 different resources. For me it ultimately came down to developer productivity. I'm much better at convincing Pulumi to do what I w…
The stack I manage with Pulumi is currently around 300 resources. (I think that count is inflated by all the secrets in AWS Secrets Manager, because each secret has two resources: the secret and the current version.) I currently manage it by myself, but I'm hoping that won't be the case for very long. Maybe the ending of my previous comment was too cynical. But I think I've repeatedly made the mistake of valuing my p…
In my particular case I don't plan to have my company grow much at all - we're staying small. I think Pulumi is a sensible "bet" for me, because it does what I need right now really well. Sure, there's a bit of a risk, but worst case scenario I would spend a day or two to migrate what I have back to Terraform.
I would definitely not have made the call to "let's just switch everything to Pulumi" if I was still working at a larger company. As you said, a large talent pool / community is a huge deal when you have the option to hire people who can spend time learning a particular tool or language.
You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.
CloudFormation is too limited. I imagine most companies use much more than AWS. Off the top of my head, we use Cloudflare, PagerDuty, GitLab, etc all of which have Terraform providers. What happens when you have to use something outside of AWS? How do you codify those changes?
As far as I know, it is possible to bridge terraform providers into a CFN stack using that mechanism, similar to how Pulumi works
0: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...