Comment by larrybolt | Hacker News Reader

Comment by larrybolt | Hacker News Reader

Parent Full thread

One of the things that got me into ansible was simply doing

  ansible all -i ./ansible_hosts -m command -a "cat /etc/issue"

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..

As it might be useful for some I have next aliases set:

  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"

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!

[1]: https://gist.github.com/larrybolt/85b59f47615be9fcb643

For testing ansible playbooks/roles in a vagrant VM, I find a simpler way is to use Vagrant's built-in support for Ansible as a provisioner.

This way, launching your test VM is just a `vagrant up` and running ansible against it (repeatedly, if needed) is `vagrant provision`. No need to pass inventory/key parameters at the shell this way - Vagrant calls Ansible with the right settings.

One thing that's easy to miss is to make Ansible use sudo when running against the Vagrant VM, since the vagrant user by convention has passwordless sudo rights (ansible.sudo = true in the Vagrantfile).

http://docs.vagrantup.com/v2/provisioning/ansible.html is a helpful reference doc.

The raw command. Doesn't require anything to be installed on the target host, so you can set up a common playbook which will bootstrap the rest of Ansible.

For Cloud services, SSH is "cloud native" meaning authorized keys are automatically injected by the cloud provider.

If using metal installs, you can also set this up in your preseed or kickstart.

However, you should never have to bootstrap a machine with another script to install things like python-apt, as you can just use the "raw" command to do this for anything that is not part of the box, see http://docs.ansible.com/raw_module.html - so it's still self-bootstrapping.

disclaimer: creator of project.

Thanks! Didn't knew about this, or just read over it. I'm mostly using ansible for learning how to use it, don't have huge clusters yet to manage. Most of the hosts I have come from LEB (LowEndBox) offerings so therefor no way to deploy my own base image.

And thank you for the work you put into ansible sir!

You can point to the hosts file in ~/.ansible.cfg

    hostfile = ~/.ansible/hosts

Or, if you run more than one project with multiple servers each, ansible will also read an ansible.config file in the current directory. You can have a separate hosts list, options, and playbooks for each set of servers. Then just cd ~/projects/whatever and ansible will work accordingly.

You can put any given set of playbooks and configs into git and share with your team so that everyone is using ansible the same way. And that repo won't even carry any auth info.

For a more low-tech solution, I've found cssh / csshX ("Cluster SSH") quite the timesaver. It pops up a bunch of xterms/Terminal.app windows and lets you type in one window while sending the keystrokes to all of the ssh sessions simultaneously.

The problem with cluster SSH is it's not declarative, so if one server already has a package, and another does not, your servers will not behave the same if typing into all of them.

This is why Ansible modules (and most other config tools) instead describe the desired end state, and perform the commands needed to get you to those states.

Basically all config tools arose out of a need for solutions to replace parallel scripting with something more robust that accounted for potential variance between systems, and also to make things more push-button.

I can see that for some kinds of admin tasks, but why package management? At least on Debian, the package manager is already declarative: There's an install/upgrade planner that figures out how to get from the current system state to the final desired state, given constraints such as packages' declared Requires/Conflicts/etc. lines. If the system is already at that state, it does nothing.

How often is setting up a package just running apt-get? There is an overwhelming majority of times where you have to change something in the config file somewhere. Ansible can do anything you want to provision your boxes.

Indeed, cssh is great for getting a quick visual on a few servers, but you're pretty much limited to what will fit on your screen. Ansible really shines when you scale it up a bit further, and it grows well, allowing you to add bits and pieces as needed.

The hosts/inventory in ansible as a source of truth for your infrastructure is also a nice feature. You could use a selection from your ansible inventory to open a cssh with 'top' running on all your webservers, for example.

Reply on news.ycombinator.com