Installer overview for developers

The installer currently supports 3 scenarios:

• Scenario 1 - Existing Jenkins server and Bitbucket server (mostly used internally on our end, and the most complicated install scenario, with the largest set of installer inputs required)
• Scenario 2 - Spins up and configures a Jenkins container, and uses an existing Bitbucket server, using info gathered by the wizard (also mostly used internally, next-most complex option, not sure we need this one honestly)
• Scenario 3 - Spins up and configures a Jenkins and Gitlab container (simplest, best option for testing, quick spin ups).

Folder structure:

installer - Installer.py lives here. installer/cli - All the Python code/click modules that directly deal with collecting user input. installer/helpers - Shared helper routines. installer/terraform - Terraform scripts and all the resources they reference. installer/configurators - Python code that directly deals with configuring the various 3rd party components that Jazz relies on.

The installer is made up of 2 main layers, which are invoked in sequence:

Python wizard

This is what is invoked by the user by running Installer.py. This should consist entirely of Python3 code and no shell scripts.

This layer is where all user input is collected. We use the Click library for our CLI, so input can be passed in via CLI flags. If a CLI flag is not provided by the user in an interactive install, Click will prompt for the value. installer/terraform/terraform.tfvars is updated with the collected and computed inputs, and then Terraform is invoked.

• The Python wizard should always maintain support for non-interactive installs (e.g. no interactive-only prompts).
• The Python wizard should always maintain a clean internal separation between user input code and configuration update/prep tasks.
• The Python wizard should only ever touch or update one thing: The terraform.tfvars file. That is its sole output. Terraform should then take that one file as input and handle the rest.

Terraform

Terraform stands up all AWS resources, and invokes all post-install scripts and provisioning steps. Terraform also fetches the tmobile/jazz repo, pushes it to the configured SCM instance, bootstraps the core Jazz functions, and configures the Jenkins pipeline to deploy user functions to AWS.

• Terraform scripts should be logically separated.
• Everything to do with AWS should be handled with Terraform primitives, unless there is a very good reason not to.
• If it is necessary to drop out of Terraform and run a script, that script should be in Python.

Post-install config scripts

Since Terraform is a cloud resource provisioning platform, and not a config management platform, for the scenarios that rely on configuring existing Jenkins servers (Scenario 1), we need to SSH into that existing Jenkins server and run some configuration. We use Chef for this currently. Terraform copies the Chef cookbooks over to the Jenkins server and invokes it. For the other scenarios, the Chef step is skipped.