121–130 of 167 posts
Earlier quoted context omitted.
Yes it can run external commands via custom resources.
Terraform allows you to call an arbitrary shell command in you machine, not just trigger some webhook.
Earlier quoted context omitted.
Terraform allows you to call an arbitrary shell command in you machine, not just trigger some webhook.
What is the practical difference between “calling an arbitrary shell command” and “calling an arbitrary lambda”?
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?
Earlier quoted context omitted.
What is the practical difference between “calling an arbitrary shell command” and “calling an arbitrary lambda”?
Honestly I don't even know how to respond to such a comment. Let's just leave it at that.
Earlier quoted context omitted.
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 a…
+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…
Earlier quoted context omitted.
Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
The nice thing about Terraform (and Ansible) imo is that they don't require a daemon but just run locally (or on CI), with some shared state in a object store.
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 --…
> I find managing Terraform's state to be a significant hurdle Have a look at 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!
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.
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 t…
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.
Earlier quoted context omitted.
Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns. I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of reso…
Long-time user of Terraform here, never used CloudFormation. Where does CloudFormation beat Terraform?