Server automation now plays an essential role in systems administration, due to the disposable nature of modern application environments. Configuration management tools such as Ansible are typically used to streamline the process of automating server setup by establishing standard procedures for new servers while also reducing human error associated with manual setups.

Ansible offers a simple architecture that doesn’t require special software to be installed on nodes. It also provides a robust set of features and built-in modules which facilitate writing automation scripts.

This guide explains how to use Ansible to automate the steps contained in our guide on How To Install WordPress with LAMP on Ubuntu 18.04. WordPress is the most popular CMS (content management system) on the internet, allowing users to set up flexible blogs and websites on top of a MySQL backend with PHP processing. After setup, almost all administration can be done through the web frontend.

Prerequisites

Source: xenonstack.com

In order to execute the automated setup provided by the playbook we’re discussing in this guide, you’ll need:

  • One Ansible control node: an Ubuntu 18.04 machine with Ansible installed and configured to connect to your Ansible hosts using SSH keys. Make sure the control node has a regular user with sudo permissions and a firewall enabled, as explained in our Initial Server Setup guide. To set up Ansible, please follow our guide on How to Install and Configure Ansible on Ubuntu 18.04.
  • One or more Ansible Hosts: one or more remote Ubuntu 18.04 servers previously set up following the guide on How to Use Ansible to Automate Initial Server Setup on Ubuntu 18.04.

Before proceeding, you first need to make sure your Ansible control node is able to connect and execute commands on your Ansible host(s). For a connection test, please check step 3 of How to Install and Configure Ansible on Ubuntu 18.04.

What Does this Playbook Do?

This Ansible playbook provides an alternative to manually running through the procedure outlined in our guide on How To Install WordPress with LAMP on Ubuntu 18.04.

Running this playbook will perform the following actions on your Ansible hosts:

  1. Install aptitude, which is preferred by Ansible as an alternative to the apt package manager.
  2. Install the required LAMP packages and PHP extensions.
  3. Create and enable a new Apache VirtualHost for the WordPress website.
  4. Enable the Apache rewrite (mod_rewrite) module.
  5. Disable the default Apache website.
  6. Set the password for the MySQL root user.
  7. Remove anonymous MySQL accounts and the test database.
  8. Create a new MySQL database and user for the WordPress website.
  9. Set up UFW to allow HTTP traffic on the configured port (80 by default).
  10. Download and unpack WordPress.
  11. Set up correct directory ownership and permissions.
  12. Set up the wp-config.php file using the provided template.

Once the playbook has finished running, you will have a WordPress installation running on top of a LAMP environment, based on the options you defined within your configuration variables.

How to Use this Playbook

Source: educba.com

The first thing we need to do is obtain the WordPress on LAMP playbook and its dependencies from the do-community/ansible-playbooks repository. We need to clone this repository to a local folder inside the Ansible Control Node. In case you have cloned this repository before while following a different guide, access your existing ansible-playbooks copy and run a git pull command to make sure you have updated contents:

If this is your first time using the do-community/ansible-playbooks repository, you should start by cloning the repository to your home folder with:

The files we’re interested in are located inside the wordpress-lamp_ubuntu1804 folder, which has the following structure:

wordpress-lamp_ubuntu1804
├── files
│   ├── apache.conf.j2
│   └── wp-config.php.j2
├── vars
│   └── default.yml
├── playbook.yml
└── readme.md

Here is what each of these files are:

  • files/apache.conf.j2: Template file for setting up the Apache VirtualHost.
  • files/wp-config.php.j2: Template file for setting up WordPress’s configuration file.
  • vars/default.yml: Variable file for customizing playbook settings.
  • playbook.yml: The playbook file, containing the tasks to be executed on the remote server(s).
  • readme.md: A text file containing information about this playbook.

We’ll edit the playbook’s variable file to customize its options. Access the wordpress-lamp_ubuntu1804 directory and open the vars/default.yml file using your command line editor of choice:

This file contains a few variables that require your attention:

The following list contains a brief explanation of each of these variables and how you might want to change them:

  • php_modules: An array containing PHP extensions that should be installed to support your WordPress setup. You don’t need to change this variable, but you might want to include new extensions to the list if your specific setup requires it.
  • mysql_root_password: The desired password for the root MySQL account.
  • mysql_db: The name of the MySQL database that should be created for WordPress.
  • mysql_user: The name of the MySQL user that should be created for WordPress.
  • mysql_password: The password for the new MySQL user.
  • http_host: Your domain name.
  • http_conf: The name of the configuration file that will be created within Apache.
  • http_port: HTTP port for this virtual host, where 80 is the default.

Once you’re done updating the variables inside vars/default.yml, save and close this file. If you used nano, do so by pressing CTRL + XY, then ENTER.

You’re now ready to run this playbook on one or more servers. Most playbooks are configured to be executed on every server in your inventory, by default. We can use the -l flag to make sure that only a subset of servers, or a single server, is affected by the playbook. We can also use the -u flag to specify which user on the remote server we’re using to connect and execute the playbook commands on the remote hosts.

To execute the playbook only on server1, connecting as sammy, you can use the following command:

You will get output similar to this:

Output
PLAY [all] *****************************************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************
ok: [server1]

TASK [Install prerequisites] ***********************************************************************************************************
ok: [server1]

…
TASK [Download and unpack latest WordPress] ********************************************************************************************
changed: [server1]

TASK [Set ownership] *******************************************************************************************************************
changed: [server1]

TASK [Set permissions for directories] *************************************************************************************************
changed: [server1]

TASK [Set permissions for files] *******************************************************************************************************
changed: [server1]

TASK [Set up wp-config] ****************************************************************************************************************
changed: [server1]

RUNNING HANDLER [Reload Apache] ********************************************************************************************************
changed: [server1]

RUNNING HANDLER [Restart Apache] *******************************************************************************************************
changed: [server1]

PLAY RECAP *****************************************************************************************************************************
server1          : ok=22   changed=18   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Note: For more information on how to run Ansible playbooks, check our Ansible Cheat Sheet Guide.

When the playbook is finished running, you can go to your web browser to finish WordPress’s installation from there.

Navigate to your server’s domain name or public IP address:

http://server_host_or_IP

You will see a page like this:

After selecting the language you’d like to use for your WordPress installation, you’ll be presented with a final step to set up your WordPress user and password so you can log into your control panel:

When you click ahead, you will be taken to a page that prompts you to log in:

Once you log in, you will be taken to the WordPress administration dashboard:

Some common next steps for customizing your WordPress installation include choosing the permalinks setting for your posts (can be found in Settings > Permalinks) and selecting a new theme (in Appearance > Themes).

The Playbook Contents

You can find the WordPress on LAMP server setup featured in this tutorial in the wordpress-lamp_ubuntu1804 folder inside the DigitalOcean Community Playbooks repository. To copy or download the script contents directly, click the Raw button towards the top of each script.

The full contents of the playbook as well as its associated files are also included here for your convenience.

vars/default.yml

The default.yml variable file contains values that will be used within the playbook tasks, such as the database settings and the domain name to configure within Apache.

files/apache.conf.j2

The apache.conf.j2 file is a Jinja 2 template file that configures a new Apache VirtualHost. The variables used within this template are defined in the vars/default.yml variable file.

files/wp-config.php.j2

The wp-config.php.j2 file is another Jinja template, used to set up the main configuration file used by WordPress. The variables used within this template are defined in the vars/default.yml variable file. Unique authentication keys and salts are generated using a hash function.

playbook.yml

The playbook.yml file is where all tasks from this setup are defined. It starts by defining the group of servers that should be the target of this setup (all), after which it uses become: true to define that tasks should be executed with privilege escalation (sudo) by default. Then, it includes the vars/default.yml variable file to load configuration options.