My advice would be to avoid Ansible for that sort of thing like the plague. All the nice things like idempotency and having the same script for setting things up and tearing them down no longer function when using those modules.

Essentially you need to 1. do the checks to ensure your playbook won't just create a new set of VMs every time it's run if they already exist 2. maintain a teardown playbook alongside your setup one because Ansible is entirely procedural and the steps would be reversed in that case and 3. do queries first to determine what actually exists in the cloud and do lots of jinja manipulations to work on the right things. Did you know EC2 has default subnets and routing tables? Did you know that the Ansible module will error out if you try to delete those objects?

If only there was a thing like Terraform that could just rely on a single description of the setup you'd like. Seriously. There's an Ansible module that will run a Terraform .tf file, and there's a provider for terraform that will run Ansible on the servers it provisions.

I think you're exagerating.

I use Ansible to provision dev environments on each PR, it works fine, every time a deployment occurs Ansible will deploy if required, otherwise proceeded with the deployment.

Destroying the environment is done separate, triggered by a webhook once the PR is closed.

If you're just provisioning software on an individual server, then sure. I agree. It kinda works okay.

What I'm talking about is using the cloud modules to spin up servers, and god help you, entire VPC set ups.

Each PR will provision a new server and then configure/deploy.

So wait, you make a playbook per individual server instance? Why?

He didn't say that. He presumably uses one playbook that creates vms and provisions the software for every PR. With ansible this can be idempotent and creating vms is by default idempotent.

Yep it does indeed, Ansible also can talk to AWS, GCP etc, but that is not the point ;-) (And Terraform can SSH in to machines and execute commands just fine)

If someone is new to this, having a strong boundary makes it much easier to process how those systems are intended to be used and how they are built. There are certain assumptions made in both that make them work differently, i.e. being command centric vs. resource centric. That's interesting when someone is up to the point where you can apply what you know in a more general or generic sense, because then he systems themselves matter less.