Foreword
Ansible started as a simple side project in February of 2012, and its rapid growth has been a pleasant surprise. It is now the work product of about a thousand people (and the ideas of many more than that), and it is widely deployed in almost every country. It’s not unusual in a computer meet-up to find a handful (at least) of people who use it.
Ansible is exciting perhaps because it really isn’t. Ansible doesn’t attempt to break new ground, but rather to distill a lot of existing ideas that other smart folks had already figured out and make them more accessible.
In creating Ansible, I sought a middle ground between somewhat computer-sciencey IT automation approaches (themselves a reaction to tedious large commercial suites) and hack-and-slash scripting that just gets things done. I also wondered, how can we replace a configuration management system, a deployment project, an orchestration project, and our library of arbitrary but important shell scripts with a single system? That was the idea.
Could we remove major architectural components from the IT automation stack? Eliminating management daemons and relying instead on OpenSSH meant the system could start managing a computer fleet immediately, without having to set up anything on the managed machines. Further, the system was apt to be more reliable and secure.
I had noticed that in trying to automate systems previously, things that should be simple were often hard, and that writing automation content could often create ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access