Why I chose Ansible for CM/CD

After weighing a lot of the pros and cons of Ansible, Chef and Puppet, here's my rationale for choosing Ansible.
Added by Steve Moyer almost 2 years ago

There are a lot of good articles written about the pros and cons of Chef versus Puppet, so why would I possibly consider any other Configuration Management (CM) / Continuous Delivery (CD) system? I think there are good arguments for both the popular contenders, but I also think that Ansible has a lot of benefits that are being overlooked. Here are my (non-prioritized) reasons for choosing the "lagging third-place contender".

  • Ansible doesn't require a client on the managed systems. Since Ansible communicates via SSH, it can move whatever modules, templates and resources it needs onto the client through its established secure connection. The only real dependency on the client is Python > 2.6 but you can run earlier versions of Python with a couple additional libraries. Since our systems will all be new deployments, they've already got Python > 2.6.
  • Ansible's Modules look familiar to system administrators who are used to issuing commands at a CLI's prompt. Collecting Ansible's Modules (commands) into a "Playbook" leaves them largely intact. You can read a YAML formatted playbook almost as though you were reading a shell script.
  • Ansible is written in Python as are most of its modules. I'm not saying that Python is better than Ruby, but I am definitely much more adept at programming in Python than Ruby. When it comes time to interact with the Ansible community, I won't be starting at a loss.
  • Another advantage of SSH is that it's considered "safe". Even when machines are behind firewalls, it's relatively easy to tunnel into the system in question. It also provides excellent key management facilities, so you can create the appropriate levels of trust between the Ansible server and the client machines.
  • Ansible can be run from my Jenkins CI system. In our set-up, Ansible configuration files will be stored in our SCM along with our software. Jenkins will detect changes to the Ansible repository and will execute the Playbooks required to make the configuration of our hosts match the configuration files.
  • Later I'll be able to spin up AWS and Linode instances automatically. Being able to automatically provision a server in response to increased load is a future goal.

The only real down-side to choosing Ansible seems to be that the community is smaller than that of Chef and Puppet. On the other hand, the documentation is excellent, the code is readable and there seems to be active discussion occurring on the Ansible Google Group. And as of today, that community has grown by at least one.

If you're looking at implementing a CM/CD system, I suggest you play with Ansible for a few hours.