Jira, Confluence, and GitLab
Operation Pushbutton
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).
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.
Buy this article as PDF
(incl. VAT)