One of the things that got me into ansible was simply doing<p><pre><code> ansible all -i ./ansible_hosts -m command -a "cat /etc/issue"
</code></pre>
From there I started going trough the possible options I could pass instead of each time doing a command, such as checking the network speed using a script etc..<p>As it might be useful for some I have next aliases set:<p><pre><code> export ANSIBLE_PATH="$HOME/web/clusters-servers/mycluster"
alias a="ansible -i $ANSIBLE_PATH/hosts"
alias ap="ansible-playbook -i $ANSIBLE_PATH/hosts"
# for vagrant testing machines where I test playbooks before deploying
alias atest="ansible -i $ANSIBLE_PATH/vagrant/hosts --private-key=~/.vagrant.d/insecure_private_key -u vagrant -s"
alias aptest="ansible-playbook -i $ANSIBLE_PATH/vagrant/hosts --private-key=~/.vagrant.d/insecure_private_key -u vagrant -s"
</code></pre>
On of the (slightly) annoying things is after bringing up a new node you have to "bootstrap" the node so you can issue ansible commands on it, I have a simple script [1] for doing so but I'd love to hear how others do it!<p>[1]: <a href="https://gist.github.com/larrybolt/85b59f47615be9fcb643" rel="nofollow">https://gist.github.com/larrybolt/85b59f47615be9fcb643</a>
Ansible is great, but could really have a better first time experience. The system itself is incredibly simple, but the docs and instructions are anything but, and seem to be modeled after Chef and Puppets which are frankly terrible. Instead, look at something like Vagrant as the shining example of how to do it right.<p>Just compare <a href="http://www.ansible.com/" rel="nofollow">http://www.ansible.com/</a> with the excellent <a href="http://www.vagrantup.com/" rel="nofollow">http://www.vagrantup.com/</a> when it comes to downloading and running your first commands. After clicking around for a good while on the Ansbile site you finally find "To install on a Mac, make sure you have Homebrew, then run... ", yeah, no thanks. Oh, there's a "pip" command, if I happen to have that installed (hint: nobody on Mac has by default), but at least there's some more magic commands I can run to install that first. After running the "Looks Totally Safe To Me! (TM)" command "sudo CFLAGS=-Qunused-arguments CPPFLAGS=-Qunused-arguments pip install ansible" it blows up on Mavericks with some error about something called paramiko and headers not being available. The attrition rate for newbies on Mac must be phenomenal, because you have to be really dedicated to give it another shot after this. What I'm getting at is, Python software distribution is an abysmal experience, always has been, and you should not subject your users to it. They're not Python developers, they're largely not even devs at all, they don't care about your pip's and brews.<p>Compare this with Vagrant: Double click this here DMG, run "vagrant init", "vagrant up" and done, in nice _big_ friendly letters on the web site.<p>Disclaimer: I use and love Ansible (on Linux), and want to see it succeed. Telling my Mac using ops team to check it out soured everyone's first impression right from the start. Rant over.
I've looked into devops tools for administering my personal collection of a dozen machines or so, and don't understand what they offer. Every one I've tried, I've come to the conclusion that it is primarily designed for dealing with large numbers of homogeneous machines, and only serve to add overhead (new syntax, a level of file name indirection) when dealing with individualized ones.<p>What I've ended up doing instead is keeping a simple tree of config files, which get run through a templating engine and then rsynced to the target host. For simple things there is zero overhead - etc/hosts is just the plain file that goes to all machines. But this system allows me to have eg one smartd.conf which contains all my disks, which is then split between machines.<p>A few things currently fall through the cracks (users,groups), but overall rebuilding a machine is a relatively painless process. I feel like there must be a better more standardized way though (which is why I keep looking at these tools). Any comments/experiences/etc ?
I've long been accustomed to setting up servers one-command-at-a-time with SSH. I tried Chef and some of the others, but they seemed too complicated to get setup.<p>Ansible's out of the box experience allows you to start with some simple but useful constructs then allow you to graduate to more and more complex usage.<p>I started with some of the one-liners here, then setting up inventory files, then roles, some simple tasks and then (what really sold me) was templates.<p>Even just having those configuration files in an SCM is a huge win, but I honestly squealed with joy when I was able to write a nginx configuration file that dynamically included backend servers given a particular role. And that provisioning a new backend server took a couple minutes and was automatically added to the load-balancing proxy! (not to mention was instantly sending metrics to a graphite/statsd backend because collectd was installed automatically too as part of a common role and configured to point to that log collecting server!)<p>Magic!
This speaks to me as I coincidentally decided to start automating my provisioning to standardize to the same vagrant environment.<p>I'm not a sysadmin or servers guy, but these days I happen to manage most of the devops and so getting servers and machines set up is my responsibility.<p>Ansible docs are not great for getting started, and I pretty much just learned by skimming through some Playbook, and figuring it out their — often intuitive — purpose.<p>After a few hours I got to a close to getting my machines set up with most of my Django stack: Nginx, Gunicorn, Redis, supervisor, celery, etc. The only thing that I couldn't properly set up was PostgreSQL. And here is something that most of these automation tools lack: debugging. When my postgres roles was failing, I had no clue how to even start debugging it, so after an hour or so, I just stepped back and went in to set it up manually.<p>I feel some of these tools need to be more friendly with devops that don't have quite the same knowledge and experience than the target audience of sysadmins and ops people. That said, I learned a ton starting to use Ansible and automated a big chunk of the process.