How to automate your infrastructure with Ansible

Use Ansible Playbooks to speed up your infrastructure configuration and deployment

Wordmark for the Ansible open source community project

Hands up if you've ever encountered this problem: you set up an environment on a server somewhere, and along the way, you made countless web searches to solve a myriad of small problems. By the time you're done, you've already forgotten most of the problems you encountered and what you did to solve them. In six months, you have to set it all up again on another server, repeating each painstaking step and relearning everything as you go.

Traditionally, sysadmins would write bash scripts to handle this stuff. Scripts are often brittle, requiring just the right environment to run in, and it takes extra code to ensure that they account for different edge cases without breaking. Scaling that up to dozens of servers is a daunting task, prone to error.

Ansible solves that problem. It's an IT automation tool that lets you describe what you want your environment to look like using simple files. The tool then uses those files to go out and make the necessary changes. The files, known as playbooks, support programming steps such as loops and conditionals, giving you lots of control over what happens to your environment. You can reuse these playbooks over time, building up a library of different scenarios.

Ansible is a Red Hat product, and while there are paid versions with additional support and services bolted on, you can install this open-source project for free. It's a Python-based program that runs on the box you want to administer your infrastructure from, which must be a Unix-like system (typically Linux). It can administer Linux and Windows machines (which we call hosts) without installing anything on them, making it simpler to use at scale. To accomplish this, it uses SSH certificates, or remote PowerShell execution on Windows.

We're going to show you how to create a simple Linux, Apache, MySQL and PHP (LAMP) stack setup in Ansible.

To start with, you'll need to install Ansible. That's simple enough; on Ubuntu, put the PPA for Ansible in your sources file and then tell the OS to go and get it:

$ sudo apt update

$ sudo apt install software-properties-common

$ sudo apt-add-repository --yes --update ppa:ansible/ansible

$ sudo apt install ansible

To test it out, you'll need a server that has Linux running on it, either locally or in the cloud. You must then create an SSH key for that server on your Ansible box and copy the public key up to the server.

Now we can get to the fun part. Ansible uses an inventory file called hosts to define many of your infrastructure parameters, including the hosts that you want to administer. Ansible reads information in key-value pairs, and the inventory file uses either the INI or YAML formats. We'll use INI for our inventory.

Make a list of the hosts that you're going to manage by putting them in the inventory file. Modify the default hosts file in your /etc/ansible/ folder, making a backup of the default one first. This is our basic inventory file:

# Ansible hosts



db_server ansible_host=

db_server ansible_become=yes

db_server ansible_become_user=root

The phrase in the square brackets is your label for a group of hosts that you want to control. You can put multiple hosts in a group, and a host can exist in multiple groups. We gave our host an alias of db_server. Replace the IP address here with the address of the host you want to control.

The next two lines enable Ansible to take control of this server for everything using sudo. ansible-become tells it to become a sudo user, while ansible-become-user tells it which sudoer account to use. Note that we haven't listed a password here.

You can use Ansible to run shell commands that influence multiple hosts, but it's better to use modules. These are native Ansible functions that replicate many Linux commands, such as copy (which replicates cp), user, and service to manage Linux services. Here, we'll use Ansible's apt module to install Apache on the host.

ansible db_server -m apt -a 'name=apache2 state=present update_cache=true' -u danny --ask-become-pass

The -m flag tells us we're running a module (apt), while -a specifies the arguments. update_cache=true tells Ansible to update the packages cache (the equivalent of apt-get upgrade), which is good practice. -u specifies the user account we're logging in as, while --ask-become-pass tells Ansible to ask us for the user password when elevating privileges.

state=present is the most interesting flag. It tells us how we want Ansible to leave things when it's done. In this case, we want the installed package to be present. You could also use absent to ensure it isn't there, or latest to install and then upgrade to the latest version.

Then, Ansible tells us the result (truncated here to avoid the reams of stdout text).

db_server | CHANGED => {

    "ansible_facts": {

        "discovered_interpreter_python": "/usr/bin/python3"


    "cache_update_time": 1606575195,

    "cache_updated": true,

    "changed": true,

    "stderr": "",

    "stderr_lines": [],

Run it again, and you'll see that changed = false. The script can handle itself whether the software is already installed or not. This ability to get the same result no matter how many times you run a script is known as idempotence, and it's a key feature that makes Ansible less brittle than a bunch of bash scripts.

Running ad hoc commands like this is fine, but what if we want to string commands together and reuse them later? This is where playbooks come in. Let's create a playbook for Apache using the YAML format. We create the following file and save it as /etc/ansible/lampstack.yml:


- hosts: lan

  gather_facts: yes


  - name: install apache

    apt: pkg=apache2 state=present update_cache=true

  - name: start apache

    service: name=apache2 state=started enabled=yes


    - restart apache


    - name: restart apache

      service: name=apache2 state=restarted

hosts tells us which group we're running this script on. gather_facts tells Ansible to interrogate the host for key facts. This is handy for more complex scripts that might take steps based on these facts.

Playbooks list individual tasks, which you can name as you wish. Here, we have two: one to install Apache, and one to start the Apache service after it's installed.

notify calls another kind of task known as a handler. This is a task that doesn't run automatically. Instead, it only runs when another task tells it to. A typical use for a handler is to run only when a change is made on a machine. In this case, we restart Apache if the system calls for it.

Run this using ansible-playbook lampstack.yml --ask-become-pass.

So, that's a playbook. Let's take this and expand it a little to install an entire LAMP stack. Update the file to look like this:


- hosts: lan

  gather_facts: yes



  - name: update apt cache

    apt: update_cache=yes cache_valid_time=3600


  - name: install all of the things

    apt: name={{item}} state=present


      - apache2

      - mysql-server

      - php

      - php-mysql

      - php-gd

      - php-ssh2

      - libapache2-mod-php

      - python3-pip


  - name: install python mysql library


      name: pymysql


  - name: start apache

    service: name=apache2 state=started enabled=yes


    - restart apache



    - name: restart apache

      service: name=apache2 state=restarted

Note that we've moved our apt cache update operation into its own task because we're going to be installing several things and we don't need to update the cache each time. Then, we use a loop. The {{item}} variable repeats the apt installation with all the package names indicated in the with_items group. Finally, we use Python's pip command to install a Python connector that enables the language to interact with the MySQL database.

Related Resource

The automated enterprise

Transform your business with an automation platform that unifies your people and processes

automated enterprise - how to automate your enterprise - Red Hat whitepaperDownload now

There are plenty of other things we can do with Ansible, including breaking out more complex Playbooks into sub-files known as roles. You can then reuse these roles to support different Ansible scripts.

When you're writing Ansible scripts, you'll probably run into plenty of errors and speed bumps that will send you searching for answers, especially if you're not a master at it. The same is true of general sysadmin work and bash scripting, but if you use this research while writing an Ansible script, you'll have a clear and repeatable recipe for future infrastructure deployments that you can handle at scale.

Featured Resources

The ultimate law enforcement agency guide to going mobile

Best practices for implementing a mobile device program

Free download

The business value of Red Hat OpenShift

Platform cost savings, ROI, and the challenges and opportunities of Red Hat OpenShift

Free download

Managing security and risk across the IT supply chain: A practical approach

Best practices for IT supply chain security

Free download

Digital remote monitoring and dispatch services’ impact on edge computing and data centres

Seven trends redefining remote monitoring and field service dispatch service requirements

Free download


The 9 best courses for R
programming languages

The 9 best courses for R

21 Oct 2021
Best Linux distros 2021
operating systems

Best Linux distros 2021

11 Oct 2021
Samsung unveils open source software for CXL Memory platform

Samsung unveils open source software for CXL Memory platform

7 Oct 2021
Hackers use open source tools to steal usernames and passwords
open source

Hackers use open source tools to steal usernames and passwords

8 Sep 2021

Most Popular

Alibaba unveils custom Arm-based server chip

Alibaba unveils custom Arm-based server chip

19 Oct 2021
Windows 11 has problems with Oracle VirtualBox
Microsoft Windows

Windows 11 has problems with Oracle VirtualBox

5 Oct 2021
What is cyber warfare?

What is cyber warfare?

15 Oct 2021