Résumé de section

  • Marqué
    • In this lab you will work in teams of 2 or 3. Each team will work on the same GitLab project "sandbox" in the Gitedu installation. To prepare your sandbox, please, do the following:

      1. All team members log in into Gitedu, with their AAI username and password through the "HES-SO Genève" tab. If you don't know your username, this is composed as "<name>.<surname>" where

        • <name> = your first name truncated to 8 characters OR the concatenation of your 1st, 2nd, etc. names to a max of 8 characters 

        • <surname> = (same as above with your family names)

      2. Your sandbox path is 

        /student-sandbox/sandbox/2023-2024/cloud-and-deployment-lab-iac_<your-group> (example: your-group = groupe-a)
      3. Proceed with your sandbox configuration as specified in the assignment instructions below.
      SUBMISSION

      All of your work and reporting must reside in your group's sandbox repository. As proof of your submission, please, note  in the submission text box:

      • your group's sandbox URL,
      • your full name

      Have fun!

      INSTRUCTIONS

      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