In the three previous exercises we dealt with the following scenarios, whose “recipes” are the input to the adopted tool (Terraform, Ansible, GitLab CI/CD):

1. Infrastructure provisioning: a cloud computing instance (asset) is provisioned via Terraform. The recipe is an HCL “plan” file. 

2. Configuration management: a simple packaged Web app stack is deployed on an existing cloud instance via Ansible. The recipe is a YAML “playbook” file.

3. DevOps CI/CD: the same simple Web app is deployed to an existing cloud instance directly from its source code stored in Git(Lab); the deployment is triggered by a commit pushed to the main branch. The recipe is a CI/CD YAML “pipeline” file.

What if we want to both provision the assets and deploy the application in just one go, in the quickest, repeatable manner and at the lowest operation granularity?

To this purpose, in compliance with industry-accepted best practices, the recipes of points #1,2 should be under version control (Git) and a workflow should be defined to enact all operations in a verifiable and controlled fashion: namely, subjecting critical operations to review before being performed, while letting the rest to be done automatically. Take scenario #3 above, substitute the app’s source code with the recipes of scenarios #1,2 and you get the answer.

ASSIGNMENT

Your assignment is to develop a complete semi-automatic IaC workflow enacting both scenarios #1 and #3 above via a unique GitLab CI/CD pipeline.

WORKFLOW OVERVIEW

The workflow to implement leverages merge events of a feature branch into a main (or master) branch, in a Git repository. Here is an overview based on GitLab CI/CD:

1. The main branch hosts the production recipes, which are never changed directly, i.e., no explicit commit/push is ever done in the main branch. Instead,

2. Whenever a recipe update is pushed to the feature branch:

1. A merge request (MR) is opened by a developer, then 

2. It is reviewed and approved by a maintainer (a.k.a. release manager).

3. A CI/CD pipeline is automatically triggered which performs the following sequential stages:

1. Provision. If the Terraform plan has changed, then (re)provision an infrastructure instance. This corresponds to scenario #1.

2. Test. If the Web app’s source code has changed, run unit tests. This corresponds to the test step of scenario #3.

3. Deploy. If the changes can be merged (i.e., no conflict occurs), the merge is manually issued by the maintainer. Contextually, the app (re)deployment is triggered according to the strategy imposed by pipeline type (“branch” vs “merge request”). For “production” assets, this deployment stage would be manual. This corresponds to the deployment stage of scenario #3. 

IMPLEMENTATION

To make it simple:

• All code (infrastructure provisioning and app deployment recipes) shall reside in the same Git repository.

• You shall play both the developer and maintainer roles.

• All pipeline stages shall be automatic, except the last one (app deployment, point 2.3.3  above).

• A flat pipeline architecture shall be used – no parent/child hierarchy.

You shall:

1. Configure your assigned GitLab project sandbox as explained in the related README file.

2. Create a “feature” branch and switch to it.

1. Install a “.gitlab-ci.yml” pipeline file implementing the stages described at point 2.3 of section “Workflow overview” above. Assuming that your cloud instance’s IP address may vary, find a way to save the IP address as reported by stage 2.3.1 (provisioning) and make it available to stage 2.3.3 (deployment). 

3. Test the whole workflow as described above at points 2.{1,2,3} of section “Workflow overview” above. In particular, verify that:

1. Any change affecting the Terraform plan triggers a (re)provisioning of the instance.

2. Any change affecting the file "webapp/templates/index.html.j2" triggers a (re)deployment of the Web app.

DELIVERABLES

All inside your GitLab project sandbox:

1. The pipeline file “.gitlab-ci.yml”.

2. The Terraform plan file “main.tf” and any accessory variable/output files and scripts.

3. The Ansible inventory "hosts.yml" and playbook "webapp-IaC.yml" files

4. The “README.md”, as a report of your work, including:

1. A detailed diagram of your pipeline and its description.

2. Any issue encountered and how you solved it