Note: this guide is intended to get you introduced to the Ansible and how to write playbooks to automate your daily operations. For a more introductory view of Ansible, including the steps necessary for installing and getting started with this tool, as well as how to run Ansible commands and playbooks, check our Ansible Quickstart
Getting Started
Before we can move to a more hands-on view of Ansible, it is important that we get to know important terminology and concepts introduced by this tool.
Terminology
The following list contains a quick overview of the most relevant terms used by Ansible:
- Control Node: the machine where Ansible is installed, responsible for running the provisioning on the servers you are managing.
- Inventory: an INI file that contains information about the servers you are managing.
- Playbook: a YAML file containing a series of procedures that should be automated.
- Task: a part of playbook that defines a single procedure to be executed, e.g.: install a package.
- Module: a module (usually written in python) abstracts a system task, like dealing with packages or creating and changing files. Ansible has a multitude of built-in modules, but you can also create custom ones. List of all available Ansible community modules can be found here
- Role: a set of related playbooks, templates and other files, organized in a pre-defined way to facilitate reuse and share.
- Play: a provisioning executed from start to finish is called a play.
- Facts: global variables containing information about the system, like network interfaces or operating system.
- Handlers: used to trigger service status changes, like restarting or reloading a service.
Task Format
A task defines a single automated step that should be executed by Ansible. It typically involves the usage of a module or the execution of a raw command. This is how a task looks:
- name: This is a task
apt: name=vim state=latest
The name part is actually optional, but recommended, as it shows up in the output of the provisioning when the task is executed. The apt part is a built-in Ansible module that abstracts the management of packages on Debian-based distributions. This example task tells Ansible that the package vim should have its state changed to latest, which will cause the package manager to install this package in case it is not installed yet.
Playbook Format
Playbooks are YAML files containing a series of directives to automate the provisioning of a server. The following example is a simple playbook that perform two tasks: updates the apt cache and installs vim afterwards:
---
- hosts: all
become: true
tasks:
- name: Update apt-cache
apt: update_cache=yes
- name: Install Vim
apt: name=vim state=latest
YAML relies on indentation to serialize data structures. For that reason, when writing playbooks and especially when copying examples, you need to be extra careful to maintain the correct indentation.
Before the end of this guide we will see a more real-life example of a playbook, explained in detail. The next section will give you an overview of the most important elements and features that can be used to write Ansible playbooks.
Writing Playbooks
Now that you are familiar with basic terminology and the overall format of playbooks and tasks in Ansible, we’ll learn about some playbook features that can help us creating more versatile automations.
Working with Variables
There are different ways in which you can define variables in Ansible. The simplest way is by using the vars section of a playbook. The example below defines a variable package that later is used inside a task:
---
- hosts: all
become: true
vars:
package: vim
tasks:
- name: Install Package
apt: name= state=latest
The package variable has a global scope, which means it can be accessed from any point of the provisioning, even from included files and templates. Working with variables could be a topic of a separate guide so I’ll refer You to great Ansible community documentation for that topic (this will be a recurring theme in this guide).
Using Loops
Loops are typically used to repeat a task using different input values. For instance, instead of creating 10 tasks for installing 10 different packages, you can create a single task and use a loop to repeat the task with all the different packages you want to install.
To create a loop within a task, include the option with_items with an array of values. The content can be accessed through the loop variable item, as shown in the example below:
- name: Install Packages
apt: name= state=latest
with_items:
- vim
- git
- curl
You can also use an array variable to define your items:
---
- hosts: all
become: true
vars:
packages: [ 'vim', 'git', 'curl' ]
tasks:
- name: Install Package
apt: name= state=latest
with_items: ""
For more in-depth examples check out Ansible community documentation on loops
Using Conditionals
Conditionals can be used to dynamically decide whether or not a task should be executed, based on a variable or an output from a command.
The following example will only shutdown Debian based systems:
- name: Shutdown Debian Based Systems
command: /sbin/shutdown -t now
when: ansible_os_family == "Debian"
The conditional when receives as argument an expression to be evaluated. The task only gets executed in case the expression is evaluated to true. In our example, we tested a fact to check if the operating system is from the Debian family.
A common use case for conditionals in IT automation is when the execution of a task depends on the output of a command. With Ansible, the way we implement this is by registering a variable to hold the results of a command execution, and then testing this variable in a subsequent task. We can test for the command’s exit status (if failed or successful). We can also check for specific contents inside the output.
The next example shows two conditional tasks based on the output from a php -v command. We will test for the exit status of the command, since we know it will fail to execute in case PHP is not installed on this server. The ignore_errors portion of the task is important to make sure the provisioning continues even when the command fails execution.
- name: Check if PHP is installed
register: php_installed
command: php -v
ignore_errors: true
- name: This task is only executed if PHP is installed
debug: var=php_install
when: php_installed|success
- name: This task is only executed if PHP is NOT installed
debug: msg='PHP is NOT installed'
when: php_installed|failed
The debug module used here is a useful module for showing contents of variables or debug messages. It can either print a string (when using the msg argument) or print the contents of a variable (when using the var argument).
For more information and more advanced examples please see Ansible documentation
Working with Templates
Templates are typically used to set up configuration files, allowing for the use of variables and other features intended to make these files more versatile and reusable. Ansible uses the Jinja2 template engine.
The following example is a template for setting up an Apache virtual host, using a variable for setting up the document root for this host:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot
<Directory >
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
The built-in module template is used to apply the template from a task. If you named the template file above vhost.tpl, and you placed it in the same directory as your playbook, this is how you would apply the template to replace the default Apache virtual host:
- name: Change default Apache virtual host
template:
src: vhost.tpl
dest: /etc/apache2/sites-available/000-default.conf
Defining and Triggering Handlers
Handlers are used to trigger a state change in a service, such as a restart or a stop. Even though they might look fairly similar to regular tasks, handlers are only executed when previously triggered from a notify directive in a task. They are typically defined as an array in a handlers section of the playbook, but they can also live in separate files.
Let’s take into consideration our previous template usage example, where we set up an Apache virtual host. If you want to make sure Apache is restarted after a virtual host change, you first need to create a handler for the Apache service. This is how handlers are defined inside a playbook:
handlers:
- name: restart apache
service: name=apache2 state=restarted
- name: other handler
service: name=other state=restarted
The name directive here is important because it will be the unique identifier of this handler. To trigger this handler from a task, you should use the notify option:
- name: Change default Apache virtual host
template:
src: vhost.tpl
dest: /etc/apache2/sites-available/000-default.conf
notify: restart apache
We’ve seen some of the most important features you can use to begin writing Ansible playbooks. In the next section, we’ll dive into a more real-life example of a playbook that will automate the installation and configuration of Apache on Ubuntu. Example Playbook
Now let’s have a look at a playbook that will automate the installation of an Apache web server on Ubuntu 18.04 system.
The complete example, including the template file for setting up Apache and an HTML file to be served by the web server, can be found on CE Github at: HERE_LINK
And again community user-guides for reference
Playbook Contents
The full contents of the playbook looks like :
playbook.yml:
---
- hosts: all
become: true
vars:
doc_root: /var/www/example
tasks:
- name: Update apt
apt: update_cache=yes
- name: Install Apache
apt: name=apache2 state=latest
- name: Create custom document root
file: path= state=directory owner=www-data group=www-data
- name: Set up HTML file
copy: src=index.html dest=/index.html owner=www-data group=www-data mode=0644
- name: Set up Apache virtual host file
template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
notify: restart apache
handlers:
- name: restart apache
service: name=apache2 state=restarted
Let’s examine each portion of this playbook in more detail:
-
hosts: all
The playbook starts by stating that it should be applied to all hosts in your inventory (hosts: all). It is possible to restrict the playbook’s execution to a specific host, or a group of hosts. This option can be overwritten at execution time. -
become: true
The become: true portion tells Ansible to use privilege escalation (sudo) for executing all the tasks in this playbook. This option can be overwritten on a task-by-task basis. -
vars
Defines a variable, doc_root, which is later used in a task. This section could contain multiple variables. tasks
Section where the actual tasks are defined.- The first task updates the apt cache
- The second task installs the package apache2.
- The third task uses the built-in module file to create a directory to serve as our document root. This module can be used to manage files and directories.
- The fourth task uses the module copy to copy a local file to the remote server. We’re copying a simple HTML file to be served as our website hosted by Apache.
handlers
Finally, we have the handlers section, where the services are declared. We define the restart apache handler that is notified from the fourth task, where the Apache template is applied.
Running a Playbook
Once you get the contents of this playbook downloaded to your Ansible control node, you can use ansible-playbook to execute it on one or more nodes from your inventory. The following command will execute the playbook on all hosts from your default inventory file, using SSH keypair authentication to connect as the current system user:
ansible-playbook playbook.yml
You can also use -l to limit execution to a single host or a group of hosts from your inventory:
ansible-playbook -l host_or_group playbook.yml
If you need to specify a different SSH user to connect to the remote server, you can include the argument -u user to that command:
ansible-playbook -l host_or_group playbook.yml -u remote-user
For more information on how to run Ansible commands and playbooks, please refer to our guide : LINK_TO_GUIDE_UG_HOWTORUNPLAYBOOKS and/or UG_HOWTORUNPLAYBOOKSUSINGTOWER
Conclusion
TODO- Add conclusion and further links , Add headers and disclaimers about IBM intellectual properties