Preparatory Measures

Before beginning the Ansible playbook, a little preparation is necessary. For this article, I assume that a newly installed system with Ubuntu 16.04 LTS already exists (e.g., as a virtual machine in a public cloud). In the example, Ansible runs on the same host that later hosts Confluence, Jira, and GitLab, so it is an all-in-one (AiO) setup.

Because Ansible connects via SSH, but ideally not as the root user, a separate user account is required. The example assumes that this user's name is ubuntu . If you start a virtual machine (VM) for Confluence and its associates in an OpenStack cloud and use an official Ubuntu cloud image for this purpose, you will discover this account in the image and not have to create it yourself.

Allowing users to log in with an SSH key is also useful, because it is more secure than logging in with a password, and the admin does not have to type in the password every time the ubuntu user calls Ansible. As usual, you just need to store the public part of the respective SSH key in the .ssh/authorized_keys file in the ubuntu user's home directory.

As an AiO setup, Ansible and Ansible Vault must be present on the system. You can handle this task by installing the appropriate packages directly from the Ansible repositories for Ubuntu 16.04:

sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Once the three commands [3] have run successfully, you can use the ansible command to see whether everything worked: The Ansible help text should appear.

Finally, allowing the ubuntu user to execute all commands with sudo, without entering the user password, is helpful. If the playbook is used in a cloud VM, this is already the case out the box: In this case, ubuntu has no password at all, so password-free sudo is inevitably the default setting.

If you are not replicating the example in a cloud VM, you can become root and run visudo to allow the sudo group to run commands without a password, and if necessary, you can use

adduser ubduser ubuntu sudo

to make sure the user belongs to the sudo group.

One of the final preparatory steps is to create the required entries in the DNS zone of the target domain. These should be present and propagated in the DNS system before the rollout of Confluence, Jira, and GitLab is due. The example assumes that the three services each have their own DNS entry and subsequently have their own virtual hosts in Apache.

The Ansible Playbook

To download the AiO playbook for Ansible, you should install the git package, so you can then check out the playbook directly from GitHub:

git clone https://github.com/madkiss/ansible-playbook-agile-aio

If the checkout worked, the folder in which the command was executed will now contain the ansible-playbook-agile-aio directory. The folder follows the Ansible recommendations for directory structures [4].

You will thus find several playbooks whose file names end in .yml, along with the devops.hosts file, which Ansible uses as an inventory file. In the vars folder is a file that defines general variables for each playbook. You will later create another file named devops-secret.yml in this folder, which stores different passwords of the setup, after encryption by Ansible Vault. In the roles folder are the roles and, indirectly, the playbooks that roll out the respective services directly on the host.

The playbook.yml playbook contains links to all other playbooks, enabling you to use playbook.yml in Ansible to roll out all required services in a single action (Figure 1).

Figure 1: The playbook.yml file calls all other playbooks and serves as a wrapper for the entire setup.

In the rest of this article, I go through the individual playbooks, explain their meaning, and point out places where you have to adjust your local configuration.

Configuring the Inventory

Before working with the different playbook roles, you need to create a suitable inventory file for your setup. A template is already included in the AiO playbook in the devops.hosts file. The devops group contains a single host. In the first field of the file, enter the full hostname of the server on which the AiO setup will run.

The IP address of the target system belongs in ansible_host. The ansible_port and ansible_python_interpreter variables ideally remain unchanged: They cause Python to connect to the host on standard SSH port 22 and to use Python 3 when calling commands on the target system.

Next, check whether the devops.hosts setup has worked, and then check the admin with the ping command:

ansible devops -i devops.hosts -m ping

If the command executed successfully, Ansible is ready for use.