I’ve been using Ansible for several months now and thought I’d share my impressions so far. My site playbook is very large at this point so I have had a chance to use most of Ansible’s features.
There is a lot to like about Ansible. My impression, as a former developer, is that it is very well designed.
- Easy to use. Ansible can be installed and used very quickly. It does not require the same complex infrastructure and setup as Chef does due to its simple push mode. The YAML command format is also simple to use and to read. Ansible is a great way to learn IT automation because of this low barrier to entry. It is, of course, a good tool for advanced users as well.
- Excellent module set. Ansible has a large number of useful modules.
- Good templating engine. As I have written previously, the templating engine is very important and Ansible has a good one in jinja2. It is very well integrated with Ansible’s variables system. This makes it easy to set host specific variables and use them in templated configuration files. I only wish the jinja2 primary documentation was better but that isn’t Ansible’s fault.
- Good documentation. Kudos to Ansible’s developers for such good documentation. This is a rare quality in an open source project.
- Powerful features. Ansible’s ease of use doesn’t come at the expense of powerful features. Provisioning VMs is very challenging and Ansible frequently surprised me with useful features. The
delegatefeature that allows you to have a different host run part of the play is a great one. So is
wait forthat allows Ansible to pause while the system does something slow like reboot. I also like the conditional include feature since this allows a certain level of modularity.
There are a few things I do not like about Ansible; some major, some minor.
- Performance on CentOS. CentOS is my OS of choice so I use it for my workstation as well as my servers. Ansible is very slow on CentOS. It takes 15 minutes to run my full playbook of about 15 servers. This didn’t bother me until I stated running serverspec tests and saw them run in mere seconds. That changed my expectations. Apparently, I can use Fedora and it will run faster. I may have to do that but I really don’t like being forced into it. I prefer to use the same OS for all my systems.
- Language richness. One of the things that makes Ansible so easy to use also limits it. The YAML based syntax is simple, fairly powerful, and easy to read. However, as someone with a developer background I miss the full power of a programming language. For that reason I think using a DSL makes a lot of sense. There are times in my playbook when I need more complex logic than Ansible allows outside of a module. Perhaps the answer is to write small custom modules for these cases. I’m not sure.
- YAML. I like the simplicity of YAML but I do not like whitespace sensitive syntax. Unless the spaces are perfectly aligned I get error and this annoys me a lot.
- Python. I prefer Ruby to Python. This is entirely a personal preference. I like the Ruby ecosystem of gem, rspec, cucumber, rake, etc. over that provided by Python. Python also introduced a schism in its community by making 3.0 partially incompatible with previous versions. This means that some libraries are 2.0 compatible while others are 3.0 compatible. In practice it means avoiding 3.0 entirely. Since I use Ruby for infrastructure testing it would be nice to have a consistent language across my tool set. Not a major issue though.
I have invested a lot of time learning Ansible and overall I am pleased with how well it works. I can easily recommend it. I hope Ansible will fix the problem of speed on CentOS, if serverspec can run quickly then I don’t see why Ansible can’t also.
I still think I will try Chef for the sake of comparison. The point of my DevOps experiment is to experiment. And this means trying different tools even when one works. I will write about Chef in later posts. Now my focus is on infrastructure testing.