You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.
What happens when you have to use something outside of AWS? How do you codify those changes?
71–80 of 315 posts
You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.
What happens when you have to use something outside of AWS? How do you codify those changes?
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.
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…
> these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY the last five words are a bit of a double negative; i think you mean "without the repetition" but I can't tell.
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…
It's better than CloudFormation (or a bunch of home grown bash scripts) and you can also modify providers beyond just the cloud host (ie: datadog alerts, database users and permissions, etc, etc.).
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…
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…
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…
The tool is ok, but developing plugins for it shows how inadequate Golang is for the job. There's so much repetition and boilerplate required. I wrote a FreeIPA plugin a few years back, it handled just registering a host and the executable weighed over 100 MB! WTF? Haven't looked at that side of things lately, I wonder if it's different nowadays.
It'll probably mostly depend on the libraries you use.
[0]:https://github.com/spacelift-io/terraform-provider-spacelift...
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 just recently wrote an article about my experience, including issues and workarounds, when migrating from Terraform to Pulumi: https://blog.ekik.org/my-experience-migrating-my-infrastruct...
Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform to Pulumi.
Just be careful with your state file when upgrading!
# to view the state file
$ aws s3 cp --quiet s3://terraform/production/terraform.tfstate /dev/stdout
# to backup the state file
$ aws s3 cp --quiet s3://terraform/production/terraform.tfstate > terraform.tfstate.bak
You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.
I turned down offers when I saw they use Terraform. I was lucky to find purely CloudFormation based infra development.
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…
> 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.