3 ms·
> Not trying to be too snarky, but why can't people just use shell scripts for automation? This is why I love Ansible. Unlike many of the alternatives, Ansibl
by chimeracoder 11y ago
> Not trying to be too snarky, but why can't people just use shell scripts for automation?
This is why I love Ansible.
Unlike many of the alternatives, Ansible doesn't try to invent a radically different DSL. Instead, ansible uses YAML playbooks that degrade very nicely to shell commands[0]. You can literally take almost any shell script and turn it into an Ansible playbook with a series of Vim regexes - or heck, write a simple sed script to translate it automatically.
Of course, if you use Ansible modules instead of the `command` directive, you get a lot of performance benefits and guarantees of idempotency. But it doesn't try to reinvent the wheel; it just builds on top of it.
It makes it really easy to hack together an Ansible script that is immediately understood by anyone who's used bash/sh and it makes it possible to improve upon it incrementally by replacing shell commands with the relevant Ansible modules.
I've used other automation tools, and the thing that I really disliked about them was that it was so difficult to migrate an existing workflow to a new paradigm. In 2015, systems work is still very imperative, so while declarative syntax is philosophically attractive, I still find it way more practical to use the tools that require smaller mental leaps.
[0] e.g., this thing was hacked together from a shell script, and I never bothered to clean it up, but it's still already more readable than the equivalent shell script: https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/master/addswap.yml https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/ma...
- falcolas 11y agoMy biggest problem, well two problems with Ansible: The maintainer is unusually hostile to user contributions, especially when compared to, say, Salt. A colleague of mine tried to contribute a (fully functional, tested, and documented) change to the MySQL user module to support passing in hashes for user creation - the pull request was closed with a comment like "this can go in a community module". Nevermind that the MySQL user module is a core module... It's also horrendously slow when your playbooks grow. The constant copying back and forth over SSH can be downright crippling. Just running a "green" (the server is in the target state and no changes need to be made) playbook against a local vagrant instance can take over a minute for my current monitoring server playbook. As a point of comparison, Salt completes in about 5 seconds. That said, it's still one of the best "no setup" tools, for the cases where you can't install a minion of one flavor or another. (Yes, theoretically the salt-ssh command line tool exists, but it requires NOPASSWORD sudo on the target server to run)
- chimeracoder 11y agoI haven't had any interactions with the maintainer(s), but I absolutely agree with the point on performance from SSH[0]. That said, I do like that Ansible makes no assumptions about your target server's initial state except that it is accessible over SSH (the rest can be bootstrapped from Ansible). My use case is admittedly much simpler than what Ansible allows for: I use it almost exclusively to provision a host for containers (and then to initialize/start those containers). As a result, my playbooks tend to remain small. I don't think this use case is realistic for everyone yet, but I think that's the direction we're headed (more containerization), and that it won't be too long before this becomes the norm in devops. [0] Seriously, the "copy" command is the best illustration of this - thank God that "synchronize" also exists!
- falcolas 11y agoIt's my belief that as our experience with containers grows, we will quickly out-grow the capabilities of a "RUN and COPY" CM paradigm. At that point, we will fall back to more traditional configuration management tools and create containers out of the results created by those CM tools.