AnsibleFest starts tomorrow so I thought I’d make a case why you should be using ansible.
First, in order to prevent a ton of hate-comments which usually follow such pronouncements, I should define who you are.
- You are a developer focused on the web or some web-based tool.
- You are not already very proficient in operations (e.g. in DevOps).
- You are responsible in some degree for a system that is not your own (e.g. live server upkeep, deploys, other development or testing machines)
- You are not in an organization large enough to already have operations/system administration as a distinct and separate organizational unit.
- You are working on a project or startup that has the potential to grow beyond its current state.
- You are not currently coding the project/startup mostly in Ruby.
If the above are **all** true for you, then I recommend you should learn and use ansible.
What is ansible?
According to Wikipedia, Ansible is a free software platform for configuring and managing computers.
As a developer, this statement means nothing to me. Here is how I saw all development:
- Develop.
- ???
- Profit!
But when I stop to think about the process in the real world, it went something like this:
- Join some startup.
- Make friends with someone in operations and have them hook me up with a development environment.
- Develop (step 1 before).
- Commit code.
- Convince someone to deploy my code or make a command that I can type to deploy my code.
- Go to step 3.
If step 2 or 5 ever were blockers, someone got bitched out until 2 or 5 ceased to be blockers.
But in the last nine years, startups no longer can necessarily afford resources to have the people responsible those steps be someone distinct from you, the developer. In fact, being a sysadmin is often a hat you as a developer who “knows that computer stuff” has to wear at an organization.
So putting on your “operations” hat, here is the process of web development from scratch:
- Get a working development machine.
- Do a system update on that machine.
- Get the software you need running on your computer.
- Get the software configured so that you have a working directory where you’ll start your project.
- Link that working directory with your development environment
- Commit the working directory to a code revision system.
- Start developing.
- Commit Code
- Repeat 1 on a live machine
- Repeat 2 on a live machine
- Repeat 3 on a live machine
- Repeat 4 on a live machine
- Purchase domain names.
- Point domain names to live machine.
- Deploy committed code through some process.
- Repeat step 6, 7, and 15 as needed.
- When on boarding someone repeat steps 1-5 as needed for them.
- Make any changes on both systems as needed.
So what does ansible do when it says “for configuring and managing computers?” It is software that you code to automate steps 2, 3, 4, 9, 10, 11, 12, 14, and 15 for you as well as help you do step 18. This covers everything that you don’t already know how to do except step 1 and 5.
Other choices
Of course, Ansible is nothing special. There are a lot of other choices out there for configuring and managing computers. As a class those choices are known as configuration management software. What I’ve hoped you learned is that whatever does configuration management can also do machine creation in cloud environments, deploys, and simple ad hoc changes.
Ansible is just one such choice.
So what are your other choices?
In order of decreasing popularity they are:
- Yourself, by hand, writing shell scripts as needed for automation.
- Puppet
- Chef
- (Ansible)
- Salt
- …others…
Why not yourself, by hand?
This is the default choice. It’s what most people are doing right now, every day, and it’s important to remember this because the argument against hand-crafting your system administration is not an argument for ansible, but rather an argument for any configuration manager at all.
The biggest advantage of doing things by hand is that any other option has a sunk cost. Anything you would do in any configuration management system requires you have done this at some level first. This is a huge argument for the default and should not be discounted.
Learning and using a configuration manager may justify its sunk cost at some point. That point depends on a number of outcomes unrelated to the choice of configuration managers.
If the project you are working on becomes successful then you will be hiring more developers (who need virtual or cloud machines, or development environment setup), deploying on more machines, or adding more steps to your process such as testing, or blue-green deploys.
For each of those machines the work of configuration management is repeated, after a set number of repetitions, you would probably start automating things through ad hoc shell scripts, which you’ve also already done for deployments. At some point that work becomes much greater than the savings generated by not bothering to learn a configuration manager.
Often before that point, your organization may become big enough to warrant a person (later a team) to specialize in operations, system administration, or DevOps. In addition, your organization has already been paying extra money in the form of some backup service because of snowflake servers. So while you personally wouldn’t have to directly pay the debt accrued by avoiding using a configuration management system, your organization will have in both backup services and work for your ops team to port an undocumented live infrastructure. A configuration management system avoids this cost because it acts as both a backup-restore system and a complete and consistent set of documentation of your machines’ states.
This is true even if the operations team chooses a configuration management system that’s different from the one you chose, though obviously if they’re the same, that’s even better.
Even if the project fails it is still possible to have positive returns to using a configuration management system.
- A configuration management is not tied to your cloud provider. So you are free to switch cloud providers from say Amazon Web Services to DigitalOcean with minimal hassle.
- Developer environment setup is manageable using the same system. At some point you may have gotten a return here even if you are the sole developer, if you are rebuilding your environment from scratch enough times. These scripts can be made identical to your production provision and deploy scripts.
- Deployment and testing can be automated through configuration management. So there is some return from avoiding writing custom scripts for this process.
- This is a skill needed in any internet-based startup. You have a skill-transfer directly to your next (hopefully successful this time) project.
- You may find configuration management interesting and find a career as an expert in DevOps as a specialty instead of as a general developer.
Why not something other than Ansible?
I’ve built out a simple LAMP stack in Puppet Apply, Chef Solo, and Ansible. Overall, I don’t find that large a difference between them for the things I’d need to do at this scale.
When deciding which configuration management system to chose as a developer, I weighed two criteria:
- I wanted the learning curve (necessary to be proficient enough to replace direct command-line operations on a machine) to be as small as possible.
- I wanted to mitigate the amount of lock-in created on a future operations team by this choice.
Puppet, being the oldest and most popular of the four, has the advantage of being the most likely to already be known by an experienced future DevOps hire in most scenarios.
However Puppet’s execution model is derived via dependencies. While I understand the reasoning, this adds a lot to the learning curve because manifests and modules are not like typing in the command line. Those who say that dependency-based management is easier to learn and use than sequential-ordering are the same idiots that a decade and a half ago told me SAX parsers were more intuitive than DOM ones: go fuck yourself. Furthermore, other CM systems have a sequential ordering so migrating away from Puppet to something like Chef is more costly than it would be from Ansible to Chef.
Finally, I find Puppet manifests and modules very intimidating to someone jumping in media res, which simply isn’t true of other configuration managers. This is a big deal because I, as a developer, I plan on pawning of site operations responsibility onto someone as soon as I can con them into thinking machine maintenance is fun.
I remember watching a core developer of Puppet scratch his head to try to figure why anyone would choose Chef over Puppet. Once, After someone shat on me for liking Ansible, I stared incredulously as they recommended Chef—as every argument just used they for Chef over Ansible could be used for using Puppet over Chef. Having said that, Chef does have two advantages over Puppet. The first is that Chef recipes and cookbooks has ordered execution like you’d expect, and the second is that those are written in Ruby. However, Ansible already does the first, and I only care to know enough Ruby to edit a Vagrantfile. Gaining proficiency in another programming language just to execute commands on a machine when I already know shell scripting is a waste. Also, I’d think having a programming language at the ready instead of a markup language is a recipe (pardon the pun) for encouraging a developer to rely on it instead of learning CM best practices. In the process an adept programmer/beginner DevOps is likely to break important features of good configuration management like idempotence.
However, if you are a Ruby developer, I’d recommend Chef because you already know the markup language and because it’s highly likely the DevOps you hire (or the Ruby shop you work at next) will be using Chef as their configuration management system. Sometimes life in the bubble is good, why burst it?
With Ansible you will have to learn YAML to write tasks and playbooks and Jinja2 is the templating system. Both are trivial. Tasks will resemble, almost exactly, a command you would type on the command line so the learning curve is quick. Once in a while, a command you type might be actually two separate tasks. Oh, the humanity! The sky is falling! It connects to the machines without a client just as you would if you were the ssh into a box. In fact, the biggest difficulties I’ve found were not with finding which ansible module task emulated the command line I wanted, but in navigating the idiosyncrasies of SSH.
Salt has a core focus on scalability and performance at the cost of an agentless model, which I’ve heard rumor does actually exist in Salt. Unfortunately, nearly every tutorial steered me away from this toward the server-client one because the magic pixie dust that powers Salt—it goes by the name ZeroMQ. This is a non-starter in terms of learning curve as a developer who suffers through, rather than enjoys, DevOps. Other than that, I think they’ve made better architectural choices at every turn than all the other CM systems, including Ansible.
The biggest B.S. argument against Ansible.
I remember over dinner one day, an ops engineer scoffed when I mentioned I was using ansible for my personal projects. When I asked him what I should use instead, he said, “puppet.” When I asked him why, he said, “Ansible doesn’t scale.” For about half of my career, Puppet didn’t exist, so I told him, “ I guess no website built before 2006 ever scaled.”
Cal Henderson is fond of saying, all programming languages scale, it’s architectures that do not. In mathematical terms, this is because all programming languages are Turing complete which means that they’re mathematically homomorphic (or equivalent) to each other.
In the same way, all configuration management systems are interchangeable—at the end of the day, they’re executing just commands on the target machine. Worst case scenario, you could make an ansible playbook whose only task is to make sure the puppet agent is up to pull from its master. That’ll scale just as well as any puppet client configuration.
If someone tells you that some sort of configuration management system doesn’t scale, what they’re really saying is, “I couldn’t get that configuration management system to scale.” Which really is more an indictment on their competence, rather than the software they’re disparaging.
How do I get started
Do a web search for “ansible”, “your favorite language”, “your favorite server”, and “your favorite flavor of operating system.”
As for me, I started with Phansible and before that, this tutorial on setting up vagrant to run an ansible playbook.
One last argument
So there you have it, my argument to encourage you to learn and use Ansible if you are an internet developer who does not program in Ruby or have a preferred CM system already but has to “wear an sysadmin hat” as part of their job which involves some sort of project that might reach scale.
Yes, that’s a pretty tight set of requirements. Change any one of those and there’s just not enough of a difference between CM systems to justify one as being definitive.
But if you are still going to shit on me for recommending ansible, because insert your favorite CM system is so much better, let’s take a moment to consider that the developer I’m addressing is probably not going to use your CM system, but rather none at all. And that person might be the person who hires you someday, to that future you I say, “Would you rather port some ansible playbooks to your clearly superior configuration manager or a bunch of random shells scripts and snowflake servers?”
You can thank me for making the future you’s life significantly less miserable. 🙂
