111–120 of 315 posts
Earlier quoted context omitted.
How does terraform compare to ansible?
They're not competition. I use Terraform for infra provisioning, and Ansible for post-provisioning application setup. I also use Packer + Ansible playbooks to build my AMIs.
You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.
That being said, there are some ugly bits.
1. Remote state as a data source means your infra is broken, you just don’t know it yet. Two apply’s have to occur to get your infra in the correct state, but they are separated by an arbitrary amount of time between executions. Even if you automate it with CI/CD, your second root module could be broken until run since it depends on the output of the other module.
2. Public modules are absolute garbage. Go find the best one, it’s trash. Here is why, 10-20 orgs all come in and tweak the module to work for them. You’ll often see 1-10 resources in a module (sometimes more), but the module will end up with more _input complexity_ than the underlying resources. Sometimes even more inputs than all the original resources combined! In the end, you get a module that “works” for everyone, with a half baked “DRY abstraction” for N number of organizations.
3. Organizing code is hard, because we often don’t fully consider environments/workspaces, infrastructure ownership, change management, and other sociotechnical concerns. I think Terraform and IaC in general is the epitome of Conway’s Law and when the (changing) social structure of the organization isn’t followed, the code gets harder to work with. This point is at odds with #1 above.
4. People tend to think “terraform apply” is a magic transactional boundary around your infrastructure. If it applies, it worked!!! But in reality, if modules aren’t crafted correctly they can “apply” cleanly, but still introduce an outage while they are executing.
All that said, I’m excited for the 1.0 release. I love terraform. Thanks to all (except module authors) for the hard work.
Serious question. What value does Terraform provide? Two years ago I looked into it and rather then having an abstraction from cloud providers it seemed to require to still target (and code against) each one specifically. So, I was quite disappointed as I thought the value proposition was to not have to know x cloud provider specific terminologies. Any insights much appreciated. Edit: I was a little worried asking su…
As you go from 1 to 3, the programmability increases. 3 is additionally idempotent. As others mention, 3 has competing products and each has its warts.
Earlier quoted context omitted.
They're not competition. I use Terraform for infra provisioning, and Ansible for post-provisioning application setup. I also use Packer + Ansible playbooks to build my AMIs.
Yup, that's the best use-case. The more that cloudy / container stuff takes over the less I use Ansible tbf.
Earlier quoted context omitted.
People mention pulumi but hashicorp are creating something similar with https://github.com/hashicorp/terraform-cdk . But all the existing terraform providers work with it afaik.
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.
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 this by renaming the state as well as the resource, but this is often a lot of work (and a bit of risk) just to rename an identifier so I don't bother. I suspect the CDK doesn't solve this problem either.
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.
The token system is broken in TF CDK still and it's not ready for adoption. I've built two stacks with it but I'm back at terraform for now. I intend to explore pulumi though when the opportunity presents itself. I think using a Turing-complete language like typescript with mature tooling to define cloud infrastructure feels very natural and makes things much more manageable than using HCL. One thing I absolutely can…
Fully agree. Not sure if any of the CDKs (or Pulumi) get the ergonomics right though. The ergonomics should feel like we're just generating YAML/JSON/etc, but the CDKs I've seen require inheritance, mutable state, etc.
> One thing I absolutely can't do without is the state management api terraform provides with its CLI. This is absent from terraform-cdk and aws's CDK, although many of the same APIs seem to exist for pulumi.
AWS's CDK is built on CloudFormation, so I don't think it has analogs for Terraform's state APIs. As for TF CDK, I would think you would just use Terraform's CLI state management directly? Maybe I'm confused about what you're trying to do?
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…
A proper repl, with the ability to actually manage a config would be a huge step forward - I spend more time trying to figure out what vars get populated and how I can get a value into another resource than anything else. It’s like I’m constantly fighting with the HCL syntax to get what I want to happen.
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…
Not sure what about terraforms performance is so bad. Seems hard to blame a tool who's main execution path is potentially 100's of network IO requests with 3rd party API's. Most of the "split stacks" I've seen is more for code organization and security reasons rather than performance. Seems safer to know 100% that deploying infra for my app isn't going to mess with my VPC settings and can be executed with a lower privileged role.
> Furthermore you can no longer effectively plan any change that affects the boundary between the two stacks.
That's fair -- you do end up with these "foundational" modules a lot of the time. Like an 'aws-account basics' module or something that other modules expect the account to be setup with that base for being able to query data objects for subnets ect... planning changes if that changes be difficult but not impossible. Good versioning is critical. Feels in the same vein as apps that need to manage framework updates and things like that. (though can be made more difficult or easier based on how you've broken up using your cloud provider -- multiple accounts by buisness unit or all in one).