A couple of months ago I wrote a blog introducing Ansible and explained the type of tasks that can be easily automated with Ansible. Here I provide an overview of the most important concepts and share useful tips learned from experience in the past few months.

Tasks: A task is the smallest unit of work. It can be an action like “Install a database”, “Install a web server”, “Create a firewall rule” or “Copy this configuration file to that server”.

Plays: A play is made up of tasks. For example, the play “Prepare a database to be used by a web server” is made up of tasks: 1) “Install the database package” 2) “Set a password for the database administrator” 3) “Create a database” and 4) “Set access to the database”.

Playbook: A playbook is made up of plays. A playbook could be “Prepare my web site with a database backend”, and the plays would be 1) “Set up the database server” and 2) “Set up the web server”.

Roles: Roles are used to save and organize playbooks and allows sharing and reuse of existing roles. Following the previous examples: if you need to fully configure a web server, you can use roles that others have written and shared. Since roles are highly configurable (if written correctly) they can be easily re-used to suit any given deployment requirements.

Ansible Galaxy: Ansible Galaxy is an online repository where roles are uploaded so they can be shared with others. It is integrated with GitHub, so roles can be organized into git repositories and then shared via Ansible Galaxy.

These definitions can be depicted as shown below:

Please note this is just one way to organize what we want to do. We could have split up installation of the database and the web server into separate playbooks and into different roles. Most roles in Ansible galaxy install and configure individual applications. For example, here is one for installing mysql and another one for installing httpd.

Tips for writing plays and playbooks

The best source for learning Ansible is the official documentation site. And as usual, online search is your friend. I recommend starting with simple tasks like installing applications or creating users. Once you are ready, follow these guidelines:

  • When testing, use a small subset of servers so that your plays execute faster. If they are successful in one server, they will be successful in others (assuming there aren’t any hardware dependencies in your playbooks).
  • Always do a dry run to make sure all commands are working (run with --check-mode flag).
  • Test as often as you need to without fear of breaking things. Tasks describe a desired state, so if a desired state is already achieved, it will simply ignore it.
  • Be sure all host names defined in /etc/ansible/hosts are resolvable.
  • Because communication to remote hosts is done using SSH, keys have to be accepted by the control machine, so either 1) exchange keys with remote hosts prior to starting or 2) be ready to type in “Yes” to accept SSH key exchange requests for each remote host you want to manage.
  • Although you can combine tasks for different Linux distributions in one playbook, it’s cleaner to write separate playbook for each distro.

Next up

In my next blog, I will share a role for adding the official Dell repositories for installing OpenManage Server Administrator and Dell System Update on RHEL and Ubuntu operating systems.