Part 1 of this blog provided a (very high) framework on how to build a lab, in multiple parts, so it builds on top of each other in each stage.
Now with enough info to be dangerous, here's the second part. After doing this for a while, a perfect example to nail the foundations, from automation in the cloud (i.e. via Terraform) to the "guest OS" (i.e. via Ansible), is standing up an Active Directory Domain Controller (DC). Standing up a DC, even with automation, can take 40-60 minutes of work, since promoting a Windows Server to a DC is resource intensive--for this reason, again, using our earlier framework, you can take snapshots of an already built/promo'd DC and do further downstream automation. But we digress...
Luckily, I ran into an existing blog that does a fantastic job speaking to the Domain Controller, via TF and Ansible.
Jose Helps Blog
The blog I'm referring to is here.
So, before reading on, please please please give Jose’s blog a read.
So, there are many ways to push this together. Ansible can be called in TF code local-exec. You can do this so all local-exec happens after all the TF work is done or inline, per resource, like above. For your needs, you'll know best.
But, to further demonstrate this point, here is a screenshot of the same code above, but more modular so you can see exactly what is going on to integrate:
Once you see this, it's pretty easy to repeat. As you can see, this Ansible code is executed within the same Terraform block for the resource itself. Again, you could of had multiple TF blocks and then drop to a local-exec, have that call ansible which could hit multiple endpoints, perhaps for simplicity to call the same playbook across resources.
This wraps up this very easy blog, thanks to Jose Helps. Again, take a step back and think to yourself, what is the experience of the end user? Could you stage the DC and do further automation for multiple labs? Yes, and again, that's exactly what we introduce in Part 1 of the lab creation process.