Anyone who works in information technology spends a fair amount of their day automating simple tasks. I always say if it can be done once, twice, in the same way, it can be automated. Technology should do some of our tactical work for us.
Configuration Management (CM) is arguably one of the best fits for automation in this context, specifically in the form of repeatable and consistent deployment of servers and services in both local and cloud environments. CM is also a primary ingredient to successful DevOps cultures because application deployment can be difficult to manage without it.
Currently, there are three big “bands” or players in this space:
Puppet: Pros
I started working with Puppet soon after its inception in 2005. It’s been around the longest, so naturally many have experience with it in some capacity. It also has a friendly way of describing its components, such as “Package”, “Service”, “User”, which make it simple to read, easy to understand, and – most importantly – agnostic. Data stores: YAML. No database required.
Installing it requires Ruby and the Enterprise release is even easier, designed with administrators in mind more than developers, with a nice graphical user interface for those less comfortable at the command line.
PuppetLabs maintain their own package repositories with most of the dependencies required, which may not exist in some standard Linux distributions. That’s definitely a pro and the community is, too, as lots of modules have been built for everyone using it to add to make life ever better using it.
It has a cool story, too. Originally invented by Luke Kanies, who wanted to give administrators access to the kinds of powerful tools Google insiders have, which empowers them to do things better and with less effort. So he created Puppet.
Puppet: Cons
Ruby. Not my first choice. Things in this realm get complicated pretty fast, which makes it challenging to offer it to clients for merits of simplicity due to so many resource dependencies. For example: service A needs package B and configuration C). You can only define a ‘resource’ in one place (i.e. an httpd service), which can be confusing without good documentation of your environment.
It doesn’t scale as well as some alternatives. While it can be run as a client-server architecture, for larger inventories, it makes more sense from a performance perspective to put all manifests into git, for example, and check them out on each host. SSH is a reliable transport mechanism and the application of the configuration runs locally. Less infrastructure, less things to maintain, less load on a centralized master and simply lighter, faster, cheaper to use cron, with a random timing element to solve any other performance issues risen by host attempting to SSH all at once.
Chef: Pros
Chef came about shortly after Puppet, which influenced it: Ruby. This is a great decision for cultures where developers are developing in Ruby and responsible for also managing infrastructure, but makes things tricky for all others less fluent in such things.
Chef: Cons
Overly complex, even in its own internal nomenclature. Workstation, Server and Clients. Knife, chef-client, chef-solo. Data structures: JSON. Database: Postgres. It’s not unlike a Volkswagen bus. If you like constantly working on stuff, you will love it. If you just want something to work, that’s friendly for a broad audience of users and ability levels, it may not be your best choice.
Very little about Chef makes sense in contrast to other solutions.
Had I been exposed to Chef prior to Puppet, perhaps I’d feel differently. Instead, I’ve used something similar, just as powerful but much simpler and more friendly to a bigger audience.
Puppet vs. Chef
The biggest differences are:
- Puppet is a language and a set of tools while Chef is a Ruby Domain Specific Language (DSL) and a set of tools.
- Puppet requests dependencies are declared between resources which Puppet satisfies.
- Chef satisfies all resources in the order in which they appear in the file. This may be a disadvantage for some as Puppet must be run multiple times to solve or converge this issue, which means if it ever takes two runs there is a bug in your manifest.
Ansible: Pros
No Ruby. Ansible is all Python, which we can almost always count on being installed on pretty much everything these days. Great choice.
Ansible works quite differently from the way Chef and Puppet do. No agent. No overhead. Ansible uses push, requires no additional installs on the end points and by default uses SSH for transport. For data, it uses YAML. Better, faster, lighter, faster, faster, faster, lighter, faster.
Arguably, Ansible achieves all that Puppet can do in simpler, more elegant ways. For example, YAML playbooks run through tasks right in front of you without cataloging or other schwack. No remote installs with odd transports or ports to have to open on firewall configurations, or complex SSL certificate management or database servers.
The developers of Ansible have thought of most things, including a commercial offering, Ansible Tower, which offers some nice features, like REST API and more.
Ansible: Cons?
I don’t know of any. If up to me, this is the choice I’d make for the vast majority of environments. Scalable, simple, extensible, lightweight and pretty decently future-proof (for the time being lol).
Synthesis
If you work with someone who doesn’t like using Python or SSH but loves learning new DSLs, using Ruby and installing agents on every instance of a machine they manage, including Windows, pick Puppet.
If you’re a Ruby developer who has no engineering team to help you with infrastructure, that may be good reason to choose Chef. Still, it’s a lot of complexity for the same return as Puppet.
I’ll stick to Ansible.