Review: Ansible orchestration is a veteran Unix admin's dream

Ansible and AnsibleWorks AWX bring simplicity and power to Linux and Unix server automation

1 2 3 4 Page 2
Page 2 of 4

Now, we can run a few other commands to investigate further:

[ansible@ansible1: ~]$ ansible all -m copy -a "src=/etc/myconf.conf dest=/etc/myconf.conf" -u ansible -sudo

ansiblecentos.iwlabs.net | success >> {

    "changed": true,
    "dest": "/etc/myconf.conf",
    "gid": 500,
    "group": "ansible",
    "md5sum": "e47397c0881a57e89fcf5710fb98e566",
    "mode": "0664",
    "owner": "ansible",
    "size": 200,
    "src": "/home/ansible/.ansible/tmp/ansible-1379430225.64-138485144147818/source",
    "state": "file",
    "uid": 500
}

ansibleubuntu.iwlabs.net | success >> {
    "changed": true,
    "gid": 1000,
    "group": "ansible",
    "mode": "0664",
    "owner": "ansible",
    "path": "/etc/myconf.conf",
    "size": 200,
    "state": "file",
    "uid": 1000
}

As you can see, these commands will cause the file /etc/myconf.conf to be copied to our two managed hosts. We will also get a JSON object returned with data on the copy, file ownership, and so forth. We can specify alternate ownership, permissions, and other variables on the command line as well.

We can also do things like make sure that a service is set to start at boot:

[ansible@ansible1: ~]$ ansible webservers -m service -a "name=httpd state=running" u ansible -sudo

Or we can reboot those hosts:

[ansible@ansible1: ~]$ ansible webservers -m command -a "/sbin/reboot -t now"

Or we can pull an inventory of each client:

[ansible@ansible1: ~]$ ansible  all -m setup  -u ansible --sudo

That last command will output JSON objects describing each client, including total RAM, used RAM, CPU, network, and disk information, the OS version, kernel version, and so forth.

As you can see, Ansible provides a way to execute commands, gather data, and copy files to the targets, based on command-line parameters.

This functionality, by itself, could be done with only SSH and some scripting. Executing commands via SSH on remote hosts is as old as the hills, after all. What Ansible adds is the ability to make all that happen with a shorthand parameter set, along with grouping, inventory, and other higher-level management of the hosts. Each Ansible command-line function offers many options, such as the ability to reference multiple groups or to run the commands on a subset, such as only the first 50 servers in a group.

These capabilities will be instantly usable by Unix admins, and working with Ansible's tools to script up quick and simple automation and orchestration tasks is ultimately very easy. Further, we can also build Playbooks to collect sets of commands and tasks for simple management.

Ansible Playbooks
Playbooks are constructed using YAML syntax, so they are generally easily readable and configurable. For instance, this simple Playbook will make sure that NTPD is running on all hosts, using the "ansible" user and sudo to connect:

---
- hosts: all
  remote_user: ansible
  tasks:
    - service: name=ntpd state=started
      sudo: yes

We can also use Playbooks to do file copies. This is the Playbook version of the file copy noted above, but specifying the owner and permissions of the file on the client:

---

- hosts: all

  remote_user: ansible

  tasks:

    - name: Copy file to client

      copy: src=/etc/myconf.conf dest=/etc/myconf.conf

            owner=root group=root mode=0644

We can also use variables in Playbooks: 

---

- hosts: webservers
  remote_user: root
  vars:
     ntp_service: 'ntpd'
  tasks:
    - service: name={{ ntp_service }} state=started
      sudo: yes

1 2 3 4 Page 2
Page 2 of 4