4 ms·
Automation is also my day job. I've got a ton of shell scripts and a ton of Ansible playbooks. No reason they can't work together. For some tasks, shell script
by skywhopper 12y ago
Automation is also my day job. I've got a ton of shell scripts and a ton of Ansible playbooks. No reason they can't work together.
For some tasks, shell scripts are better/clearer/easier, and you can call those scripts from Ansible. For other tasks, Ansible provides better tools, and hey, you can call Ansible from your shell scripts!
I've added a few ansible-friendly options to some of my shell scripts like adding an --ansible-mode flag that then outputs just a one-line "OK" or "Changed" message that then I have Ansible parse to determine if something changed during the run. Or if you're more ambitious you can just turn your shell scripts into Ansible modules by having them take arguments in a slightly different way and output JSON.
A free templating system (Jinja2) and cross-platform capabilities are nothing to shake a stick at either. Not to mention, Ansible does a good job of helping organize your hosts and parameters in one place, and forces you to modularize your "scripts" (in the form of playbooks and roles) in a beneficial way.
It's definitely worth a look. You can start small, and use it only for one thing, and grow from there. That's one of its biggest benefits over Puppet and Chef, which don't really have a way to go small-scale.
- duggan 12y agoI do like the "mass SSH" functionality that Ansible provides, it's something accomplished years ago with Capistrano, but I certainly prefer having it in Python (now that I've wrangled together a dynamic inventory interface to Terraform's tfstate files). Shell is not what you want to go to for orchestration, but, essential as it is, I think it's a separate concern from managing the configuration of the machine. You're absolutely right about being able to start small as a major point in its favour, though. Not enough infrastructure tooling accomplishes this.