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

Beyond these examples is the use of templates. We can build templates that reference variables, then call those templates from within Playbooks to construct files as we require. We might create a template file for an Apache configuration and place that configuration on our clients using variables specified in the Playbook:

template: src=/srv/templates/apache.conf dest=/etc/httpd/conf.d/{{ vhost }}.conf

Of course, we may need to restart services afterward, and we can do that with the notify and handler functions:

notify:

restart apache
handlers:
    - name: restart apache
      service: name=apache state=restarted

The combination of all of these commands in a Playbook would make sure the appropriate virtual host configuration file is in place on the client, then restart Apache afterward so that the configuration changes will be picked up.

As you might expect, we can include files in Playbooks. We could create a file with all of our necessary handlers, then include just that file in new Playbooks. Thus, we could keep all those handlers configured in one place and still make them available throughout all Playbooks.

Further, you can configure roles that allow for collections of handlers, tasks, and variables to be included in Playbooks that reference those roles. For instance, you might have a set of handlers and tasks just for database servers, so you would set up a database role containing those files, then add the role to a Playbook to have all of those elements included in the Playbook. You can also configure dependencies that reference other roles as required.

Thus, constructing Playbooks is not only straightforward, but also offers significant extensibility and natural organization. In addition, Playbooks are very simple to run:

[ansible@ansible1: ~]$ ansible-playbook myplaybook.yml -f 10

This command will run the Playbook myplaybook.yml with a parallelization of 10, meaning that the server will connect and run myplaybook.yml on 10 clients at once.

While Ansible uses paramiko, a Python SSH2 implementation, or native SSH to communicate with clients, there can be a scalability issue when moving into large numbers of clients. To address this, Ansible 1.3 offers an accelerate mode that launches a daemon over SSH that provides AES-encrypted communication directly with the client. This feature can speed up client communications substantially when measured in large-scale implementations as compared to paramiko or native SSH.

Ansible modules
Ansible includes a number of modules that allow for extended functionality, such as configuration and management of cloud services (say, Amazon EC2), as well as service-specific modules for popular database servers, file operations, and network devices. You can also create your own modules to handle site-specific requirements. Modules can be written in nearly any language, not just Python, so you could use Perl or Bash or C++ to create your modules.

Modules can be written to accept variables, and they are required to output JSON objects noting the status of the command along with any pertinent information that may be collected during runtime.