Ansible – rapid deployment of services

pan serwer Piotr Kmita

What is Ansible?

Ansible is a tool used to automate administrative processes, orchestration and configuration management. It is agentless, which means that no agent needs to be installed on client servers and they are not unnecessarily burdened by it. With its help, we can deploy hundreds of servers in a short period of time with software installed and configured to be fully defined by us. It can be a configured hosting server with cPanel or DirectAdmin, or even a single service installed on thousands of servers. The limitation in the use of this tool is only our imagination and the time we have to prepare the configuration of Ansible itself.

What kind of systems can we manage with Ansible?

We can manage both Linux and Windows systems. In addition, it is possible to use it in network devices, making it much easier to change a piece of configuration in switches.

How can we use Ansible?

We can use Ansible in two ways. The first is to issue ad-hoc commands directly from the console for individual servers from a predefined inventory. We can also use a playbook in which all the events to be executed are included. We mainly use Playbook when we want to deploy some configuration or install some services.

When we want to execute the same command on several servers, we will use the ad-hoc command directly for this. Below I demonstrate one of the simpler commands and a short playbook contained in a single file.

  • Example of an ad-hoc command
[email protected] ~ # ansible localhost -m shell -a "hostname"
localhost | SUCCESS | rc=0 >>
  • An example of a playbook that installs an Apache server
Instalacja httpd - playbook
- hosts: localhost
  - name: Install httpd
   yum: name=httpd state=latest
Wynik z uruchomienia playbooka
[[email protected] tmp]# ansible-playbook playbook.yml
PLAY [localhost] ****************************************************************************************************************************************************************************
TASK [Gathering Facts] **********************************************************************************************************************************************************************
ok: [localhost]
TASK [Install httpd] ************************************************************************************************************************************************************************
changed: [localhost]
PLAY RECAP **********************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0

Above I demonstrated only installations on a single host (specifically localhost). Later in this article I will show the use of Ansible using AWS servers. We can install on all defined hosts in our inventory, which can be static or dynamic to search for all instances in AWS EC2, for example. The static inventory by default is located in the /etc/ansible/hosts file.

For example, it might look like this:

[grupa-serwerow] ansible_port=2222 ansible_user=kylos


If the connection to the servers is made with the ssh key and we have root privileges, then we do not need to configure anything. If, on the other hand, we want to use a different user than the one we are currently using and an ssh port, we can use the parameters in inventory as for

What is Ansible-Galaxy?

Ansible-Galaxy is a public library of Ansibel roles written by the community. Its resources are generally available and can be used for a wide variety of administrative tasks. Unfortunately, in most cases, the roles included in it have a supporting function. Practice shows that the implementation of a comprehensive solution requires many modifications in them to meet all our expectations.
The library is located at If we use the search engine located at this link and type the word “apache”, it is likely that the following role may appear to us first in the search results:

Using her example, we will demonstrate the installation of an Apache-based web server later in the article.

Installation or download of such a role can be done by issuing the following command:

ansible-galaxy install geerlingguy.apache

You can also find this and other commands directly in the documentation of the role in the library.

Installing an Apache-based web server directly from a downloaded Ansible role From Ansible-Galaxy

In this part, he will use 3 servers running on AWS with Amazon Linux installed. On two of these servers we will install a web server, and on the third we will not include any changes

First we download the roles (unless we have done it before) geerlingguy.apache:

ansible-galaxy install geerlingguy.apache

# ansible-galaxy install geerlingguy.apache
- downloading role 'apache', owned by geerlingguy
- downloading role from
- extracting geerlingguy.apache to /root/.ansible/roles/geerlingguy.apache
- geerlingguy.apache (3.0.0) was installed successfull

Here we will use the predefined inventory and configured Ansibl so that it logs in directly after the key to the instances after the ec2-user and grants root user privileges.
For this in the ansible.cfg configuration I used:


Our inventory now looks like the following:


ansible00 ansible_host= ansible_user=ec2-user
ansible01 ansible_host= ansible_user=ec2-user
ansible02 ansible_host= ansible_user=ec2-user

Our playbook looks like this:

- hosts: all
   - role: geerlingguy.apache
     when: ( inventory_hostname == "ansible00" ) or ( inventory_hostname == "ansible01" )
   - name: Verify hosts with apache
     service: name=httpd state=running
     ignore_errors: yes

Now we can proceed to launch the playbook by issuing the command:

ansible-playbook -i ansible_inventory ansible-playbook.yml

Below is a screenshot of the latest information visible on the screen:

Pic. 1


The article includes only partial background information to help you get started with this tool. By default, at the end of the execution of the playbook you will not get information with the time of completion of each task. For this it uses the so-called. “callback_whitelist” with parameter “profile_tasks”. It greatly simplifies the ability to optimize individual tasks which is useful for large projects.


Do you have questions? Get in touch with us