Operation Pushbutton

Launching SSL Certificates

Edison also contributes a ready-to-go Ansible role for Jira, but unlike the previous playbooks, you have to take an additional step: Several placeholders in the jira.yml file of the AiO playbook need to be replaced with actual values – in particular, the apache2_vhosts_server_name for the hswong3i.jira role and apache2_vhosts_server_name for the hswong3i.apache2_vhosts role (Figure 3).

Figure 3: The Jira and Confluence roles contain various entries that you need to adapt to local conditions before running.

Note that jira.yml calls a role named madkiss.certificate, which is a rudimentary role that I wrote myself; it drops the SSL certificate, the appropriate SSL key, and an SSL CA or SSL intermediate certificate into the correct place in the system. Before you can roll out jira.yml, you need to equip this role with the required files and configure them.

The madkiss.certificate role is based on three required files: key.pem.enc, an Ansible Vault file that contains the SSL key for the certificate; certificate.pem, the certificate itself; and intermediate.pem, which contains any certificates required to establish a direct trust path between the CA certificates in the browsers and a provider's certificate. Because most CAs now work with sub-signing keys, this step is essential.

The three files belong in the roles/madkiss.certificate/files folder in the AiO playbook. Entering

ansible-vault create key.pem.enc

creates the key file as described above; in doing so, be sure to use the same password as before when creating devops-secret.yml. The other two files are simply stored in plain text at the same location.

The rest works automatically: madkiss.certificate stores the three files in the standard configuration in /etc/ssl, and the other roles are configured by default to search for the certificate, intermediate certificate, and key in the same locations (Figure 4).

Figure 4: The madkiss.certificate role installs SSL certificates and keys on the target system.

Postfix as a Prerequisite

Confluence, Jira, and GitLab share one property: They all communicate heavily with registered users by email. Without a working mail setup, you can't even add user accounts, because the initial user access data is delivered by mail for all services.

The playbook thus contains a postfix.yml file that configures Postfix on the target host and allows mail dispatching through a mail relay. You should create the appropriate configuration and roll out the playbook with the ansible-playbook command in postfix.yml. The Postfix role in the playbook doesn't come from Edison, but from the Dutch provider Oefenweb.

Incidentally, the Postfix playbook configures Postfix to work as a relay host for local services, which allows GitLab, Jira, and Confluence to be configured as mail servers on 127.0.0.0.1. Authentication is not a prerequisite for the service, but it does require that the mail server is not accessible through the usual SMTP ports – a firewall prevents access.

Jira and Confluence

Once the three files for madkiss.certificate are placed and you have defined the appropriate parameters in jira.yml, run the familiar ansible-playbook call as shown earlier, but this time with jira.yml as the target. This may take some time: The playbook loads the Jira software, rolls it out, stores an account for the service in MySQL, and configures Apache.

Once the Jira setup is working, the confluence rollout is handled in the same way: In confluence.yml, replace the values for apache2_vhosts_server_name and apache2_vhosts_server_name, as for jira.yml, and then call ansible-playbook again.