Our organization just started looking at Crossplane instead of Terraform. It apparently gets around the lock issues [1] and is better suited for K8S environments. Some folks I work with think the community will eventually adopt Crossplane over Terraform.
Anyone have any experience with it?
Terraform 0.15 General Availability
81–90 of 239 posts
Re: Terraform 0.15 General Availability
#82My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform
> we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform In my opinion if you're doing manual fixes you're doing it wrong. Let's say you do your manual fix in your Dev environment. Do you remember to do it in Prod/whatever other environments you have? Are you sure you did the EXACT same thing? Did you change 5 other things trying to fix it first? You end up with s…
I think there's a middle ground if you're not sure how to fix a mistake in Terraform but you know how to do it in the console:
* Make your changes by hand
* Right afterward, run "terraform plan" to see how Terraform would undo your changes
* Edit your Terraform config to reflect those changes, and run "terraform plan" again to make sure you caught everything. Repeat until it's a no-op.
Now you've got a log of what you've done in a Git-ready format, and you can repeat it elsewhere, and you've learned how to make that console change in code.
Re: Terraform 0.15 General Availability
#83Re: Terraform 0.15 General Availability
#84On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk
If you like CDK, then i highly recommend pulumi
Can second that. Pulumi with Typescript is just absolutely awesome.
Re: Terraform 0.15 General Availability
#85Earlier quoted context omitted.
If you like CDK, then i highly recommend pulumi
How do they differ?
+1 to Pulumi.
xyzzy123 already described the differences between Pulumi and terraform, but I want to add one key way in which they are similar:
Pulumi uses terraform under the hood. We get all of the reliability of terraform, but with a much more powerful runtime engine.
Re: Terraform 0.15 General Availability
#86Earlier quoted context omitted.
Terraform allows us to implement development practices into our sysadmin lives. Such as code reviews, etc. For example, at my work this is what i do to apply changes to our AWS setup: 1. Fetch the latest version of our git repo. 2. Create a new git branch named after the Jira ticket im working on. 3. Solve the jira ticket by modifying the terraform code accordingly. 4. Submit a pull request and assign one of my colle…
Reading the sister comments, I kind of understand the appeal of terraform for huge/multi cloud infra systems. Now, managing changes in code doesn’t look too far from dealing with kubernetes’ json/yml config and applying them to the current cluster, provided it would be trickier when expanding to multiple cluster or doing complex orchestrating. I guess TF makes a lot more sense for on-premise, bare metal VMs ?
> I guess TF makes a lot more sense for on-premise, bare metal VMs ?
No, not necessarily. If you have an API for orchestrating your on-premise infrastructure (openstack etc), then sure.
Where terraform shines is managing resources in your cloud provider.
I.E. creating the GCP project and GKE cluster that you need before you can apply your k8s YAML. Or creating the cloudsql databases, GCS buckets, etc that the apps running in your k8s cluster need.
Re: Terraform 0.15 General Availability
#87Earlier quoted context omitted.
If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…
Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.
> Who cares if there is a dangling dns records somewhere
You should care. This opens you up to subdomain takeovers, which have real security implications.
https://developer.mozilla.org/en-US/docs/Web/Security/Subdom...
Re: Terraform 0.15 General Availability
#88I do not like terraform and I believe it's a terrible tool.
Here is the error you get when it fails:
Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure.
If that error does not give you pause, I don't know what will. It's basically YOLO-ing it and in case it does not work you're on your own. It's also leaving you in whatever state and now you need to figure out what it managed to do, what didn't work and figure out how to 1) make it work 2) make terraform understand that it worked. Usually this happens at the worst time when you are deploying to production.
Do we want to talk about when plan "works" but it craps out on "apply"? Or about when it just loses tracks of resources.
HCL? A disaster. Why would you need to invent your own language? Why oh why? Hashicorp also knows better. Remember Vagrant? Vagrant got it right with the DSL + you could always drop down to Ruby if you did something not covered by the DSL.
My advice to you: use whatever the cloud you are using has built it (cloudformation, deployment manager, etc).
Re: Terraform 0.15 General Availability
#89My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform
> we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform
I find this to be the best advantage to Terraform. These small changes make your infrastructure harder to re-produce in the future; and unless you have strong documentation rules, you lost what is there in your infrastructure.
Re: Terraform 0.15 General Availability
#90I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…
Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.