it can’t tell a damn thing about current state of the system
This statement is strange. The author could not possibly have written a line of Ansible, apart from blindly chaining external commands. It is possible to use it like a bash script but that's not the intention. Serializing state is its primary use case, and also makes it different from "running commands over ssh".
- Terraform knows what changes it made, and knows how to revert them. Thanks to the fact it maintains its own state.
- Ansible is able to revert it but only after you explicitly tell it to revert it.
I'm always scared of removing things in Ansible (or any other automation tools) because I've to handle explicitly a case for removing of the things. That's where the statement "running commands over ssh" comes from.
Like if you have a resource in terraform, and remove that resource from the file - terraform will tell you that happend
If you have a task in ansible and remove it - good luck finding out what you need to clean up. You've to know it and know how to handle that case (using state: present or absent where possible).
So at the end - doing terraform destroy I feel pretty confident to have a clean state (and if APIs are not causing huge side effects, it's same state as before applying changes)
Removing resources with Ansible is additional effort and requires maintenance.
Like I said in the other comment - this title might not suite what I intended to say.
Indeed. Terraform is a single point of failure because it explicitly needs to keep state. For larger environments this is a headache.
Ansible can read the running state which is more robust. External modifications of state happens, if nothing else than as a result of failure modes not under your control. Setting and reading state explicitly is a feature. Code should be committed to git at all times.
For larger environments infrastructure drift is a much bigger headache then that Terraform has to store a json blob somewhere.
Having a combination of state and reading running state (like Terraform does) is crucial to have a tool that can scale for large environments.
Comments
This statement is strange. The author could not possibly have written a line of Ansible, apart from blindly chaining external commands. It is possible to use it like a bash script but that's not the intention. Serializing state is its primary use case, and also makes it different from "running commands over ssh".
I find it to be a huge difference in two systems:
- Terraform knows what changes it made, and knows how to revert them. Thanks to the fact it maintains its own state.
- Ansible is able to revert it but only after you explicitly tell it to revert it.
I'm always scared of removing things in Ansible (or any other automation tools) because I've to handle explicitly a case for removing of the things. That's where the statement "running commands over ssh" comes from.
Like if you have a resource in terraform, and remove that resource from the file - terraform will tell you that happend
If you have a task in ansible and remove it - good luck finding out what you need to clean up. You've to know it and know how to handle that case (using state: present or absent where possible).
So at the end - doing terraform destroy I feel pretty confident to have a clean state (and if APIs are not causing huge side effects, it's same state as before applying changes)
Removing resources with Ansible is additional effort and requires maintenance.
Like I said in the other comment - this title might not suite what I intended to say.
Indeed. Terraform is a single point of failure because it explicitly needs to keep state. For larger environments this is a headache.
Ansible can read the running state which is more robust. External modifications of state happens, if nothing else than as a result of failure modes not under your control. Setting and reading state explicitly is a feature. Code should be committed to git at all times.
For larger environments infrastructure drift is a much bigger headache then that Terraform has to store a json blob somewhere. Having a combination of state and reading running state (like Terraform does) is crucial to have a tool that can scale for large environments.