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

FREE

Become An Insider

Sign up now and get free access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content from the best tech brands on the Internet: CIO, CSO, Computerworld, InfoWorld, IT World and Network World Learn more.

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

Many server automation and orchestration solutions, like Puppet and Chef, rely on a mixture of solution-specific coding, Web UIs, and command-line tools to make the magic happen. Ansible is different. Although a Web UI is available, Ansible plays very well on the Unix admin's home turf: general scripting and the command line.

Ansible is an extremely flexible open source toolkit that makes it very easy for Unix hands to get started with automated configuration management and orchestration. It uses a push method of configuring client systems, so everything stems from a master server. And to the powerful CLI, you can add a commercially licensed Web UI to provide for delegated administration and provisioning.

[ Review: Chef cooks up configuration management | Review: Puppet Enterprise 3.0 pulls more strings | Puppet or Chef: The configuration management dilemma | Subscribe to InfoWorld's Data Center newsletter to stay on top of the latest developments. ]

Installing Ansible

Installing Ansible is quite simple. You can either clone the Git repository and start from there, or you can use package management tools on your *nix of choice to download and install the packages. This will ensure that you have the required packages and Python 2.6 executables, and within a few minutes, you will have an Ansible master server configured.

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
}

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

AnsibleWorks AWX
A Web UI is available for Ansible in the form of AnsibleWorks AWX. This is a for-cost solution that offers a crisp and clean Web UI built around Ansible. However, the Web UI doesn't tie into an existing Ansible configuration by default; if you have an extensive Ansible installation on a server, adding AWX on top of it isn't going to immediately Web-ify that structure. You can use CLI tools to import existing Ansible inventories into AWX, then continually synchronize the two if you need to maintain CLI and AWX simultaneously.

Once you install and run AWX, you can configure users, teams, inventories, projects, and job templates based around your infrastructure. However, note that you're adding these as new; they are not based on existing configuration files that may already include all of your hosts and configurations. AWX also provides a RESTful API, as well as integration with LDAP and Active Directory for authentication and authorization. This integration can be handy for mapping users and groups to organizations within the UI.

The AWX Web UI is clean and relatively intuitive, and it allows for fairly fast implementation. The UI is based strictly on Playbooks, so there are no command-line functions to leverage. You construct Playbooks via the CLI for your desired actions, then place them in specific directories on the server. You can then access them in the UI under Job Templates, then attach them to Inventories, and those jobs can be run.

The Web UI is functional, but it is neither as complete nor as useful as the command-line interface. You can't schedule jobs through the Web UI, for example, whereas you can easily schedule jobs via cron on the command line. Playbooks can be run from either the Web UI or the CLI or both, so if you have a sizable CLI-based installation, your Playbooks will move over with little fuss. The rest of the structure will have to be duplicated via synchronization, however.

AnsibleWorks AWX also provides simple Web-based integration with various cloud services through various Ansible modules, so you can provide a Web UI for internal users and teams to provision public or private cloud services from a local management console, authenticated and authorized against your local LDAP or AD infrastructure. In this way, it can function as a self-service portal for internal customers.

To continue reading, please begin the free registration process or sign in to your Insider account by entering your email address:
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies