| Ansible is a good choice for maintaining the k8s infra itself, but IMO is not good at maintaining hardware or managing containers. The major problem with Ansible compared to container orchestrators is that Ansible has no concept of previously known state. It makes some things that are easy in Terraform (deletions) more difficult, as you have to write a new playbook to delete stuff. So can't say, "I don't want to run this nginx container on this host anymore" by just removing that host from the part of your inventory that gets nginx, or removing nginx from that hosts playbook. You have to explicitly remove it. This is not a huge problem if you're into immutable infrastructure, where you just wipe any host and redeploy, as it lets you go from known state to known state reliably. This kind of relgates Ansible to yaml shell scripts, but it's generally a lot tidier and gives you a nice framework for knowing where you are in your script. When trying to apply Ansible to more infrastructure related stuff, again, it can do it, but's not the right tool. You can write a playbook to deploy a host or scale your EC2, but you basically have to do that separate from the provisioning of the hosts you just deployed. For container orchestration, I found Ansible more of a hinderance than a help. Ansible is very imperative, and most orchestration tools are deliberately declarative. There's no particular reason to use it to deploy, scale, delete basically anything in k8s or swarm, as there is very little value add over using the tools themselves. Overall I find Ansible best suited to building the containers or vms that you will run on your cluster, as these are necessarily imperative steps that fit it well. This also applies to the hosts that make up your cluster, if you aren't able to prepare an immutable image for them or get them to auto join. |