3 ms·

Ansible has been nice for replacing a bunch of ad-hoc shell scripts for my Digital Ocean boxes for personal projects. I have a bunch of simple provisioning scri

Ansible has been nice for replacing a bunch of ad-hoc shell scripts for my Digital Ocean boxes for personal projects. I have a bunch of simple provisioning scripts I can re-run as many times as I want, and I have simple deploy scripts that automatically skip unnecessary steps. Cannot imagine a better tool for single-host devops, really - if I were putting together a list of "how to run your own small infrastructure" it'd be higher priority than anything else. I am curious, as a bit of a devops outsider, how it fits into the toolset of a modern application. From what I can tell, a lot of the aspects of Ansible are made redundant in a world of _hosted_ containers - you don't need Ansible if you're, say, deploying container images to EKS/ECS/whatever - but if you were to self-host your Docker hosts (or... whatever the Kubernetes is equivalent is called), Ansible still seems to me to be the best tool around for standing up and maintaining those hosts.

Spivak 6y ago
Ansible is one of those tools that is so general that it can just absorb whatever operational complexity you throw at it. It might not be pretty, and you might want to tattoo the Jinja and YAML specs on your arm but even in the world of hosted containers I still use it to act as the glue for the disparate systems I have to coordinate. Having Ansible actually completely manage our hosted k8s environment has been really nice since Ansible has gone through the effort of gritting their teeth on templating and manipulating YAML in a semi-sane way. I've tried and tried to like Helm but you just hit the ceiling of what's possible so fast. Being able to add new filters, expose new/dynamic data to templates, pull data from outside sources, and have both Ansible-lang and Python as escape-hatches is something I don't want to give up.
escardin 6y ago
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.

Spivak 6y ago

Ansible is one of those tools that is so general that it can just absorb whatever operational complexity you throw at it. It might not be pretty, and you might want to tattoo the Jinja and YAML specs on your arm but even in the world of hosted containers I still use it to act as the glue for the disparate systems I have to coordinate. Having Ansible actually completely manage our hosted k8s environment has been really nice since Ansible has gone through the effort of gritting their teeth on templating and manipulating YAML in a semi-sane way. I've tried and tried to like Helm but you just hit the ceiling of what's possible so fast. Being able to add new filters, expose new/dynamic data to templates, pull data from outside sources, and have both Ansible-lang and Python as escape-hatches is something I don't want to give up.

escardin 6y ago

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.