Cloud & Deployment 2023 - 2024
Aperçu des sections
-
-
-
Session 11: Exoscale presentation + IT automation: Configuration Management and DevOps, Lab 4: exercise 1/3: infra provisioning with Terraform
-
Pedagogical objectives
- Become familiar with a Cloud provisioning/orchestration tool
- Provision Cloud resources in an automated fashion
Exercise material
The exercise is available on this link.
You will work individually on SwitchEngines VM. Please, have your credentials ready.
Even though this exercise won't be evaluated, it is mandatory! You will have to give notice of completion by writing your name in the submission text box.
-
Session 12: Lab 4 exercise 2/3: service stack deployment with Ansible, exercise 3/3: DevOps code delivery with GitLab CI/CD
-
Pedagogical objectives
- Become familiar with a configuration management tool
- Deploy a web application in an automated fashion
- Become familiar with Desired State Configuration
Exercise material
The exercise is available on this link.
You will work individually on a group-shared SwitchEngines VM. Please, have your credentials ready.
Even though this exercise won't be evaluated, it is mandatory! You will have to give notice of completion by writing your name in the submission text box.
-
PEDAGOGICAL OBJECTIVES
- Become familiar with DevOps practices
- Learn how to automatically deploy things via GitLab CI/CD
EXERCISE MATERIAL
The exercise is available on this link.
You will work individually on a group-shared SwitchEngines VM. Please, have your credentials ready.
Even though this exercise won't be evaluated, it is mandatory! You will have to give notice of completion by writing your name in the submission text box.
-
-
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:
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)
Your sandbox path is
/student-sandbox/sandbox/2023-2024/cloud-and-deployment-lab-iac_<your-group> (example: your-group = groupe-a)
- 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):
Infrastructure provisioning: a cloud computing instance (asset) is provisioned via Terraform. The recipe is an HCL “plan” file.
Configuration management: a simple packaged Web app stack is deployed on an existing cloud instance via Ansible. The recipe is a YAML “playbook” file.
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:
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,
Whenever a recipe update is pushed to the feature branch:
A merge request (MR) is opened by a developer, then
It is reviewed and approved by a maintainer (a.k.a. release manager).
A CI/CD pipeline is automatically triggered which performs the following sequential stages:
Provision. If the Terraform plan has changed, then (re)provision an infrastructure instance. This corresponds to scenario #1.
Test. If the Web app’s source code has changed, run unit tests. This corresponds to the test step of scenario #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:
Configure your assigned GitLab project sandbox as explained in the related README file.
Create a “feature” branch and switch to it.
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).
Test the whole workflow as described above at points 2.{1,2,3} of section “Workflow overview” above. In particular, verify that:
Any change affecting the Terraform plan triggers a (re)provisioning of the instance.
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:
The pipeline file “.gitlab-ci.yml”.
The Terraform plan file “main.tf” and any accessory variable/output files and scripts.
The Ansible inventory "hosts.yml" and playbook "webapp-IaC.yml" files
The “README.md”, as a report of your work, including:
A detailed diagram of your pipeline and its description.
Any issue encountered and how you solved it
-