[vageli]

Curious about where you see ansible fit in while using Terraform, could you expand on that? Everywhere I have thought I would need ansible to scratch an itch it has turned out that terraform has that functionality in some way (through null_resource, runners).

[movedx]

Terraform is for managing infrastructure. Ansible is for managing configuration. You can argue they're the same thing, but I disagree.

I believe in one tool to do one job really well.

Terraform is excellent at provisioning and managing infrastructure due in part to its DAG and HCL. On the other hand Ansible has been tuned over the years for managing configuration and the state of anything and everything from the OS upwards.

I also believe in using building blocks to get to where you're going, and these two bad boys click together quite well.

[vageli]

I guess what I'm questioning is the place of configuration management tools in a world of increasingly managed services where the server is not patched by you. In those cases, it makes no sense to me to patch individual containers through automation versus updating the image and pushing out the artifact to the service so all containers everywhere are updated and there's no checking for variance in state since all are running the same (updated) image.

[wokwokwok]

personal experience only, but like Dockerfiles, terraform is only good for provisioning until its not.

Once your VM or container hits a complexity point above trivial, ansible is very much a useful tool for provisioning container states, and specifically for patching container images to, eg. include security updates.

...beyond that, as in, the intended use case of dynamically updating multiple live machines in parallel... dunno, I don’t use ansible for that... but it beats the hell of out having a single monolithic batch script to setup a container. I use it for that purpose all of the time.

[vageli]

I guess that's the disconnect for me. Why would I want to update individual containers when I can just push out a new image and have automation rotate my services? Individually applying security patches at the container level also means there's probably SSH access as well, something I am quick to remove in environments in which I encounter it.

For host based security patches (if I'm in an environment where the servers aren't managed), adding an item to the crontab in user data usually handles that, and again any fleet-wide changes would usually be propagated by updating the user data, pushing out the change and having automation rotate the fleet.