| I'm a fan of Ansible, so let me reply to a few of your points :) 1. Playbooks are not a complete programming language for a good reason. You just get a simple linear flow of tasks with limited loops and conditions, so they're hard to make unreadable, unlike full-blown programming languages, like Python in Fabric or Ruby in Chef. 2. Yes, using shell commands for things that can be done using modules is frowned upon, but nobody is going to physically frown at you, so don't worry about it too much :) I drop down to shell/command/script modules whenever I need to without giving it a single thought. 3. Yes, the modules are often less powerful than the underlying tools. The other side is that they return nicely parsed data and changed/not changed status, so you can analyze their results more easily than shell commands. 4. Yes, ansible has immense advantages over shell scripting whenever one or more applies (generally the "manage a fleet of servers" scenario, not the "set up a dev box" one):
- you need to coordinate configuration between multiple machines (sshing back and forth is just clumsy in comparison)
- the playbook is to be used more than once (e.g. evolving configuration) -- I can't imagine my life right now without diffs and check mode. This also makes developing/debugging playbooks much easier than scripts, e.g. I recently wrote a hairy migration tool as a playbook and could easily see all the changes it would do without applying them
- some things are just easier in ansible (template and lineinfile come to the top of my head, plus everything is parsed for you into easily usable data structures) 5. I'd probably use ansible to set up my own machine if I ever got to automating the task, but you're right: learning ansible just for that makes little sense. |