Use Ansible to automate your configuration tasks
In the first part, you learned about the context in which you would be working, and you set up a favorable technical environment to automate the deployment of MediaWiki using Ansible.
In this chapter, you’ll transpose and organize the operations required to install MediaWiki, using Ansible roles.
The node manager and node are now up and running. Your job will be to install the MediaWiki internal wiki manager on 2 servers, in order to make it usable by all employees of the company. To do this, we’re going to need to organize our operations, in order to run them sequentially with Ansible.

A role is a tree structure made up of directories and YAML configuration files, which will have the function of installing a particular system. Roles can be nested and interdependent on each other.
A role is therefore a set of files organized in a tree structure.
But what’s the point?
The purpose of roles is to be able to aggregate consistent operations (in YAML files), so that they can be reused in a modular way. You can think of a role as a set of operations that have a common role, such as the role to install Apache, or the role to configure MariaDB.
The directories are all optional, except for the tasks directory, which must contain the main.yml file. Ansible will process this file first when a role is called.
Some directories must contain a main.yml file to be taken into account.

A task is a statement described in YAML in a configuration file. Each task uses a module and a few additional arguments.
Schematically, you can remember that:
- A role contains one or more configuration files (YAML).
- A configuration file contains one or more tasks ;
- A task uses a module.
YAML (Yet Another Markup Language). YAML allows you to write data structures that can be specified in the form of lists.
Structure your deployment with Ansible roles
Identify the steps to install MediaWiki
You saw in the first part of this course that installing MediaWiki requires 6 steps that I repeat here:
- Install an Apache web server on the first server (http1).
- Install PHP also on the first server (http1).
- Install a MariaDB database on the second server (bdd1).
- Download the MediaWiki source files and upload them to the web server (http1).
- Configure the web server (http1) to point to the http://http1/mediawiki URL.
- Finalize the installation of MediaWiki via the installation script on http1.
These 6 steps consist of installation operations (steps 1 to 3) and configuration operations (steps 4 to 6).
Transpose Steps into Ansible Roles
Next, you’ll transpose this logic to Ansible using roles.
You’ll create 5 roles:
- A role to install Apache: apache.
- A role to install MariaDB: mariadb.
- A role to configure Apache for MediaWiki: confapache.
- A role to configure MariaDB for MediaWiki: confdb.
- A role that will contain global variables: common.
So you’ll follow this list to create each role one by one.
Create your first role
You’ll start by creating a configuration file tree that will allow you to walk through the steps for deploying MediaWiki, and then, in the next chapter, you’ll write the Ansible scripts in these configuration files. I purposely choose this approach so that you have a structural vision before you start writing the code.
Where should the roles be placed?
By default, Ansible will look for roles in the “roles” directory which is placed in the working directory (current directory): the one in which the Ansible commands are launched.
Create the directory that will contain all the roles
Start by creating the “roles” directory in your workspace. This directory will contain all the roles that you will create.
(ansible) user-ansible@node-manager:~$ mkdir roles ; cd roles (ansible) user-ansible@node-manager:~/roles$
However, it is entirely possible to tell Ansible a different path by changing the DEFAULT_ROLES_PATH environment variable, or by changing the “roles_path” option (default: ) in the Ansible configuration file (). /etc/ansible/roles/etc/ansible/ansible.cfg
To help you create a complete tree, you can use the ansible-galaxy command.
Ansible Galaxy refers to Galaxy’s website where users can share roles (similar to how GitHub allows developers to store and share, publicly or not, the code they create).
ansible-galaxy, on the other hand, is a command-line tool for uploading, creating, and managing Ansible roles. It would have been quite possible to use a Galaxy role to install Apache, for example.
Use ansible-galaxy to automatically create a role
Go ahead, now! Create your first role for installing Apache with the ansible-galaxy command and the init option:
$ ansible-galaxy init apache
Use the tree command to display the file tree:
$ tree apache
This results in the following:
(ansible) user-ansible@node-manager:~/roles$ tree
.
└── apache
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
9 directories, 8 filesThe tree contains the following directories:
- files: all files to be copied to the node;
- templates: all Jinja template files;
- tasks: list of instructions to execute (the main.yml file is required);
- handlers: same for handlers statements (the main.yml file is mandatory);
- vars: file containing variable declarations (the main.yml file is required); The variables defined here take precedence over the variables defined in the inventory;
- defaults: Default values (the main.yml file is required) with a lower priority;
- meta: Role dependencies and information (author, license, platforms, etc.) about the role (the main.yml file is mandatory).
When the tree is created, the files are empty! They will have to be supplemented according to the operations to be carried out. As you can see, a role is primarily a file tree that will contain Ansible actions.
Create your MediaWiki role tree
You’ll create, one by one, the structure of the 5 roles for deploying MediaWiki.
Create the Apache role
Make sure you are in the roles directory.
(ansible2.7.10) user-ansible@node-manager:~/roles$
You’ve already created the Apache role structure.
To install Apache and PHP, you need to install software packages on Linux and restart the Apache service for the changes to take effect.
You could have kept this tree as it is, but for your simple need to install Apache and PHP, you’re going to do a bit of grooming to keep only the necessary directories.
Only the handlers, meta and tasks directories will be kept:
- handlers: contains tasks to be executed after a notification (restart the Apache service);
- tasks: Contains the tasks that must be performed to install Apache.
After removing unnecessary directories with the command:
(ansible) user-ansible@node-manager:~/roles/apache$ rm -rf defaults/ files/ meta/ template/ tests/ vars/ README.md 'ansible) user-ansible@node-manager:~/roles/apache$
Here’s what the new tree looks like:
(ansible) user-ansible@node-manager:~/roles/apache$ tree . ├── handlers └── main.yml └── tasks └── main.yml
Create the mariadb role
For the mariadb role, you need to install software packages on Linux and start a service.
So you don’t need to use ansible-galaxy for the mariadb role, only one configuration file is needed here:
(ansible) user-ansible@node-manager:~/roles$ mkdir -p mariadb/tasks (ansible) user-ansible@node-manager:~/roles$ touch mariadb/tasks/main.yml
The main.yml file will contain the tasks that need to be performed to install MariaDB
Here’s the tree:
(ansible) user-ansible@node-manager:~/roles$ tree mariadb/mariadb/ └── tasks └── main.yml 1 directory, 1 file
Since configuration operations and variables are specific to MediaWiki deployment, the configuration and common roles will be placed specifically in a mediawiki directory.
So we create a directory:
$ mkdir mediawiki
This results at this stage:
(ansible) user-ansible@node-manager:~/role$ tree . ├── apache │ ├── handlers │ │ └── main.yml │ └── tasks │ └── main.yml ├── mariadb │ └── tasks │ └── main.yml └── mediawiki 6 directories, 3 files
Create the Common Role
The common role will contain variables that are shared between the confapache and confdb roles. So, instead of defining the same variables in two different places, it’s better to create a common role, and use a dependency with the other roles.
To do this, you need the defaults directory and the main.yml file that will contain the global variables:
$ mkdir -p mediawiki/commun/defaults/ $ touch mediawiki/commun/defaults/main.yml
This gives:
(ansible) user-ansible@node-manager:~/roles$ tree mediawiki/
mediawiki/
└── commun
└── defaults
└── main.yml
2 directories, 1 fileCreate the confdb role
For the confdb role, you need to create a database and assign rights to it.
And you’ll create a dependency with the common role to share global variables.
To do this, you need the meta and tasks directories:
$ mkdir -p mediawiki/confdb/meta mediawiki/confdb/tasks
and main.yml files that will contain the following actions:
$ touch mediawiki/confdb/tasks/main.yml $ touch mediawiki/confdb/meta/main.yml
This gives:
(ansible) user-ansible@node-manager:~/roles$ tree mediawiki/ mediawiki/ ├── commun │ └── defaults │ └── main.yml └── confdb ├── meta │ └── main.yml └── tasks └── main.yml 5 directories, 3 files
Create the confapache role
You’ll share global variables with the confdb role, so you’ll add a dependency with the common role.
You’ll also create the MediaWiki installation directory, download the MediaWiki files from the official website, run the installation script, and update the database.
To do this, you need the meta and tasks directories:
~/roles/mediawiki$ mkdir -p confapache/meta confapache/tasks
and main.yml files that will contain the following actions:
$ touch confapache/tasks/main.yml confapache/meta/main.yml
This results in the following tree:
(ansible) user-ansible@node-manager:~/roles$ tree mediawiki/ mediawiki/ ├── commun │ └── defaults │ └── main.yml ├── confapache │ ├── meta │ │ └── main.yml │ └── tasks │ └── main.yml └── confdb ├── meta │ └── main.yml └── tasks └── main.yml 8 directories, 5 files
Improve inventory for deployment
In keeping with the spirit of modularity, you’ll modify the inventaire.ini file to separate the two nodes into two separate groups.
This will then make it possible to address a group rather than the nodes directly. This way, if you want to add a node, you’ll just have to add the node to the right group in the inventory file, and replay your scripts without changing anything else. Magic!
Log in to the node manager:
$ ssh user-ansible@node-manager
Activate the virtual environment:
$ source ansible2.7.10/bin/activate
Edit the inventaire.ini file
$ vi inventaire.ini
[apache]
http1
[db]
bdd1
Here we have two bracketed groups that contain one node each.
A server group is declared by enclosing the group name in square brackets[].
The inventory file is very flexible, it allows interesting and surprising combinations: node[1:2] for 2 nodes or [linux:children] for a group that contains other groups.
Summary
In this chapter, you’ve organized automation operations with Ansible roles:
- You have spread your MediaWiki installation over two groups of servers, with the aim of being able to scale your infrastructure.
- You have understood how to create a role and identify the contents of a role tree.
- You have developed a global tree structure for predefined roles, with a view to making a structured and automated deployment of MediaWiki.
In the next chapter, we’ll look at how to control the execution of operations and chain several actions together by setting up roles.

And if you'd like to go a step further in supporting us, you can treat us to a virtual coffee ☕️. Thank you for your support ❤️!
We do not support or promote any form of piracy, copyright infringement, or illegal use of software, video content, or digital resources.
Any mention of third-party sites, tools, or platforms is purely for informational purposes. It is the responsibility of each reader to comply with the laws in their country, as well as the terms of use of the services mentioned.
We strongly encourage the use of legal, open-source, or official solutions in a responsible manner.


Comments