4 ms·
Ansible looks fine when you start, but gets painful. You need to write idempotent ansible from the start. No excuses. Then you would implement a retry logic i
by weitzj 5y ago
Ansible looks fine when you start, but gets painful.
You need to write idempotent ansible from the start. No excuses.
Then you would implement a retry logic in ansible since your cloud APIs will fail for weird reasons or you really must wait that a resource in AWS is truly ready before you run another task. ( for example vpn gateway in AWS must be ready and then you can attach a vpn connection, or a route53 zone record has to propagate before you do something with it. But in the meantime your other tasks can continue in parallel. Only the vpn tasks needs to wait)
Then after a while with all your resources created with your idempotency implemented in ansible, your code will roughly first check ( with timeouts, retries) if you actually can skip tasks since there is nothing to do. The checks increase, your playbook takes longer and longer to execute. Maybe you try to parallelize it in some way.
In the meantime a colleague of yours executes the same playbook in their machine or pipelines, and now you see weird side effects. Maybe you start implementing some locking behavior.
At this point we did not do any code reviews yet and we did not answer the question: “how should the infrastructure look like?”
This especially means: how do you actually delete resources with Ansible? So you Start to introduce a kind of “state” for your resource.
So, if you squint hard enough, idempotent, resilient, parallelizable, thread-safe, fast ansible with a state is what terraform solves.
If you look at tools like terratest you even get to do unit/integration testing for your infrastructure code.
So as soon as you are more than 1 person handling infrastructure following best practices like code review and testing, without getting insane, use terraform.
If you are alone and don’t want to follow the above best practices, you still have to be very good in writing idempotent, resilient ansible code.
My hypothesis is that the intersection of people who write high quality (idempotent, resilient) ansible code but people who do not care about code review/testing, is quite small.
Once you do not work in isolation any more, either in a team or as a consultant who needs to hand over their work (and Teach people how idempotent ansible works), I would favor terraform any time.
You could even call ansible from terraform if you need some ansible integration, where ansible has a nicer api for you. But let terraform handle the retries, state management and ansible could just be the executing part. So ansible is more like a fancy bash script/function which you call in an orderly manner.
- apple4ever 5y agoThank you for this. I've been hemming and hawing over straight Ansible or Ansible + Terraform and you made it clear why the later makes sense.
- aprdm 5y ago> You need to write idempotent ansible from the start. No excuses. Absolutely. And code reviews, etc. just like code. > Then you would implement a retry logic in ansible since your cloud APIs will fail for weird reasons or you really must wait that a resource in AWS is truly ready before you run another task. ( for example vpn gateway in AWS must be ready and then you can attach a vpn connection, or a route53 zone record has to propagate before you do something with it. But in the meantime your other tasks can continue in parallel. Only the vpn tasks needs to wait) Yes, Ansible modules have a retry built in or a wait_for statement. You can also control the serialization serialize: (or was it parallel), or run_once or when. You have a couple of tools at your disposal. > At this point we did not do any code reviews yet and we did not answer the question: “how should the infrastructure look like?” Why not? We usually start with some diagram in README.md or Confluence or a Design Proposal before the code. Code never gets released without a merge request. > This especially means: how do you actually delete resources with Ansible? So you Start to introduce a kind of “state” for your resource. state: absent, you can use in about every module. > So, if you squint hard enough, idempotent, resilient, parallelizable, thread-safe, fast ansible with a state is what terraform solves. If you look at tools like terratest you even get to do unit/integration testing for your infrastructure code. I believe terraform hides way too much and is too magic. Troubleshooting when terraform goes wrong is really really hard. You have two states to look on -- the cloud state and the TF state. And now you need to know two tools too, since you will likely need Ansible anyways to configure and operator the hosts later. > So as soon as you are more than 1 person handling infrastructure following best practices like code review and testing, without getting insane, use terraform. Beg to differ, 100s of engineers sharing ansible galaxy roles with semantic versioning and whatnot in a very good way at my org. > Once you do not work in isolation any more, either in a team or as a consultant who needs to hand over their work (and Teach people how idempotent ansible works), I would favor terraform any time. Maybe you're right. If I'm doing freelance I will likely use Terraform to interact with Cloud. IMO Ansible, just like coding, requires a bit of a community around it with best practices, reviews and etc.