Specifying Passwords

Before the Ansible roles start working, you must configure the required passwords. Naturally, the thought of storing passwords in the clear in text files, which could later be openly visible in an internal Git repository, should make your hair stand on end.

Luckily, Ansible offers an alternative: It can use Vault to store secret information on the disk in encrypted form. When running ansible-playbook, simply pass in two more parameters – the playbook and --ask-vault-pass: Ansible prompts for the Vault password and then decrypts the files automatically.

Vault works well, but with a minor limitation: If the content from different files has to be encrypted, all Vault files must be protected with exactly the same password, which is the case in this example: The role that rolls out the SSL certificate on the target system also saves the SSL key that belongs to the certificate as a Vault file. Remember the password used for the first Vault container, because you will need it later for the SSL key vault, too.

However, Vault is first used to create a file called devops-secret in the vars folder in the AiO playbook.yml folder:

ansible-vault create devops-secret.yml

After entering a password of your choice, the editor stored in the $EDITOR variable opens. The file should ultimately contain three lines:

apache2_vhosts_pass: "<secret>"
mysql_root_pass: "<secret>"
apache2_vhosts_hash_salt: "<secret>"

The <secret> placeholder has to be replaced by a sensible password. Once the file has been set up accordingly, just save it and close the editor. If you want to see or change the content of the file at a later time, use one of the following commands:

ansible-vault view devops-secret.yml
ansible-vault edit devops-secret.yml

(Figure 2).

Figure 2: With Ansible Vault, you can store confidential data on disk in an encrypted file instead of in the clear.

Basic Configuration

The Ansible playbook used here is based on the work of three developers: The majority was penned by Wong Hoi Sing Edison (hswong3i ), who mapped the entire installation of Jira and Confluence in Ansible [5]. It is the backbone of the AiO playbook with minor adjustments and not only covers Jira and Confluence, but also allows idempotent configuration of various basic system parameters.

The basic playbook uses many of Edison's roles: In addition to the basic Apt configuration, it also rolls out configuration files for the hostname and the locales to be used. It also switches the system's time zone to UTC and polls NTP to get a reliable source of time. Additionally, it installs a basic iptables configuration that, of the privileged ports below 1024, only opens port 22 for SSH. Other Ansible roles extend the firewall configuration later – if necessary.

Now check that you can connect to the target system via Ansible and test whether the execution of Ansible playbooks really works by calling the basics playbook:

ansible-playbook -i devops.hosts -e @vars/devops.yml -e @vars/devops-secret.yml --ask-vault-pass basics.yml

The command might take some time to execute because Ansible installs many packages on the future agile host when executing the roles in basics.yml. If the playbook runs without error, Ansible reports this at the end and outputs 0 as a return value. This completes the basic system configuration; the specific roles for Confluence, Jira, and GitLab are next.

Many Requirements

When installing Confluence, Jira, and GitLab manually, the various prerequisites expected by the tools are often overlooked. For example, Jira and Confluence require Java and MySQL, as well as the MySQL Java Connector. GitLab relies on PostgreSQL in the Omnibus edition, but at least it installs it itself.

SSL also plays a role: The three services usually run on the same host and can share the same IP but should, of course, support HTTPS on port 443. However, this setup can only be achieved by way of a web server with different virtual hosts that also serves as an SSL terminator. Manually installing Confluence, Jira, and GitLab with all their dependencies and the necessary configurations on top, often turns into a tedious task.

The present AiO playbook takes care of the dependencies and is also designed to set up Apache as a terminating SSL proxy. Jira, Confluence, and GitLab each configure their own virtual hosts via the Apache host role, which Edison also wrote.

After successfully rolling out the basics playbook, create the prerequisites for the three services by calling the java.yml, apache.yml, and mysql.yml playbooks with a command like the one used for the basics playbook. Afterward, Apache, MySQL, and Java should be running on the AiO host for Confluence, and Jira should be installed. After that, it's down to the nitty gritty – that is, the deployment of the desired services.