IT automation refers to delegating repetitive, slow, or cumbersome IT processes to scripts and automation tools. IT automation makes it simpler for DevOps engineers or system administrators to efficiently manage complex infrastructural tasks.
Ansible is a powerful open source IT automation language. It’s an application deployment tool, a configuration management tool, and a service orchestration tool.
Ansible is an IT automation tool or platform that can be used on Linux or UNIX servers to run builds, test, and deploy commands all at once.
A web application usually consists of the following services:
These services are tasks that Ansible’s simple playbooks can manage seamlessly. Its scripts contain easily understandable syntax, enabling its service to support cross-platform compatibility effortlessly. Moreover, Ansible playbooks are powerful enough to automate deployments of any scale.
Ansible was created according to several objectives. Each of these represents an inherent benefit to implementing its tools:
/etc/ansible/hosts directory or keep them version-controlled with Git. This results in enhanced flexibility.Ansible works via a system of modules, which provide a significantly more organized alternative to writing ad-hoc commands and scripts. Let’s explore how these modules form the basis for the overall Ansible architecture.
A substantial list of modules is included in the YAML file. These modules are reusable scripts or program resource models designed to perform specific tasks. We can invoke modules in two ways: via commands in the terminal or with an Ansible playbook.
Under the hood, we can see that Ansible modules are built-in Python code that can be called inside of playbooks. Let’s quickly review the following example, which demonstrates how to execute some modules on a host server in the terminal.
$ ansible host_server -m service
$ ansible host_server -m ping
$ ansible host_server -m command -a "/sbin/reboot -t now"
The keywords service, ping, and command are Ansible modules.
As we’ll soon discover, Ansible playbooks also enable us to use modules. With a playbook, the above example becomes far more straightforward.
- name: Restart the Host server
command: /sbin/reboot -t now
When using playbooks, Ansible executes each module in the order they appear. Then it removes them as it proceeds.
The entire list of modules available in Ansible can be found here. Ansible also allows developers to create custom modules and add them to the project as an open source tool. They provide helpful documentation for learning more about how to develop new modules.
Ansible works directly with the host services powering our applications. We can specify these hosts by creating inventory files. A straightforward way to define an Ansible inventory file is by creating a static text file that includes the names and addresses/URLs of the host servers.
Our manually created inventory files are designated as static because they must also be manually updated. In contrast, we can automatically create and update dynamic inventory by using shell scripting.
Consider the sample below, which creates the contents of an inventory file:
[webservers]
web01 web02
[database_servers]
db01 db02 Ansible automatically adds localhost to the list of hosts in the inventory file as it refers to our local machine. It also communicates with other host servers using SSH keys, which properly enforce SSH connection.
Ansible groups can have a particular host server common to them. Additionally, these groups can be members of other groups in an inventory. Ansible inventory groups are instrumental when handling several tasks that involve different instances of a single server.
As an example, here’s a typical inventory file for deploying a web application using Ansible inventory groups:
[production]
london.company-name.com stanford.company-name.com toronto.company-name.com berkeley.company-name.com san-jose.company-name.com
[staging_regions]
mpany-name.com rio.company-name.com
[db]
[stanford.company-name.com
[webserver]
toronto.company-name.com berkeley.company-name.com toronto.company-name.com berkeley.company-name.com san-jose.company-name.com san-jose.company-name.com
Ansible playbooks are the primary tools for automating IT tasks in Ansible. A playbook is a YAML-based text file that contains a list of tasks — or plays — that will run in a specified order against a server or a group of servers.
Consider the shell scripts below. Installing a dependency like NGINX requires a sequence of commands on the terminal:
# update system
$ sudo apt update
# install nginx
$ sudo apt install nginx
# enable Nginx HTTP on port 80
$ sudo ufw allow 'Nginx HTTP'
# check status
$ systemctl status nginx
# setup server block and start nginx server
$ sudo systemctl start nginx
However, using an Ansible playbook can relieve us of the stress of waiting to run additional commands until after prior commands have finished initializing.
We simply need to create a playbook and write the plays for Ansible to execute. For performing the above NGINX installation, a playbook might look something like this:
- hosts: webservers
become: yes
sudo: True
tasks:
- name: update
apt: update_cache=yes
- name: Install Nginx Server
apt: name=nginx state=latest
notify:
- restart nginx
handlers:
- name: restart nginx
service: name=nginx start=reloaded
To run the playbook, use the following command:
$ ansible-playbook nginx-server.yml
# verify that Nginx is running your target server:
$ sudo systemctl status nginx.service
The example above will install NGINX as expected. Of course, a programmer may likely include some additional instruction that can significantly improve this playbook.