From a3b279f03d3e675f8e91e3082c26703d6e050142 Mon Sep 17 00:00:00 2001 From: Istarengwa <44943929+istarengwa@users.noreply.github.com> Date: Wed, 23 Jul 2025 17:15:25 +0200 Subject: [PATCH] =?UTF-8?q?Corriger=20la=20num=C3=A9rotation=20et=20suppri?= =?UTF-8?q?mer=20les=20exercices?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 14 ++-- week_01/day_03/project_01.md | 2 +- week_05/day_01/day_title.txt | 2 +- week_05/day_01/lesson_01.md | 4 +- week_05/day_02/day_title.txt | 2 +- week_05/day_02/lesson_01.md | 40 ++++++++--- week_05/day_02/project_01.md | 27 +++++--- week_05/day_03/day_title.txt | 2 +- week_05/day_03/lesson_01.md | 44 +++++++++--- week_05/day_03/project_01.md | 23 ++++--- week_05/day_04/day_title.txt | 2 +- week_05/day_04/lesson_01.md | 34 +++++++--- week_05/day_04/project_01.md | 23 ++++--- week_05/day_05/day_title.txt | 2 +- week_05/day_05/lesson_01.md | 34 +++++++--- week_05/day_05/project_01.md | 23 ++++--- week_06/day_01/day_presentation.txt | 2 +- week_06/day_01/day_title.txt | 2 +- week_06/day_01/lesson_01.md | 40 +++++++---- week_06/day_01/lesson_02.md | 31 +++++---- week_06/day_01/lesson_03.md | 59 ++++++++++++++++ week_06/day_01/project_01.md | 23 ++++--- week_06/day_02/day_presentation.txt | 2 +- week_06/day_02/day_title.txt | 2 +- week_06/day_02/lesson_01.md | 34 ++++++---- week_06/day_02/project_01.md | 21 +++--- week_06/day_03/day_presentation.txt | 2 +- week_06/day_03/day_title.txt | 2 +- week_06/day_03/lesson_01.md | 36 ++++++---- week_06/day_03/project_01.md | 21 +++--- week_06/day_04/day_presentation.txt | 2 +- week_06/day_04/day_title.txt | 2 +- week_06/day_04/lesson_01.md | 34 ++++++---- week_06/day_04/project_01.md | 21 +++--- week_06/day_05/day_presentation.txt | 2 +- week_06/day_05/day_title.txt | 2 +- week_06/day_05/lesson_01.md | 34 ++++++---- week_06/day_05/project_01.md | 21 +++--- week_06/week_presentation.txt | 2 +- week_06/week_title.txt | 2 +- week_07/day_01/day_presentation.txt | 1 + week_07/day_01/day_title.txt | 1 + week_07/day_01/lesson_01.md | 100 ++++++++++++++++++++++++++++ week_07/day_01/lesson_02.md | 57 ++++++++++++++++ week_07/day_01/project_01.md | 23 +++++++ week_07/day_02/day_presentation.txt | 1 + week_07/day_02/day_title.txt | 1 + week_07/day_02/lesson_01.md | 38 +++++++++++ week_07/day_02/lesson_02.md | 65 ++++++++++++++++++ week_07/day_02/project_01.md | 20 ++++++ week_07/day_03/day_presentation.txt | 1 + week_07/day_03/day_title.txt | 1 + week_07/day_03/lesson_01.md | 39 +++++++++++ week_07/day_03/project_01.md | 20 ++++++ week_07/day_04/day_presentation.txt | 1 + week_07/day_04/day_title.txt | 1 + week_07/day_04/lesson_01.md | 36 ++++++++++ week_07/day_04/project_01.md | 19 ++++++ week_07/day_05/day_presentation.txt | 1 + week_07/day_05/day_title.txt | 1 + week_07/day_05/lesson_01.md | 34 ++++++++++ week_07/day_05/project_01.md | 20 ++++++ week_07/week_presentation.txt | 3 + week_07/week_title.txt | 1 + week_08/day_01/day_presentation.txt | 2 + week_08/day_01/day_title.txt | 1 + week_08/day_01/lesson_01.md | 34 ++++++++++ week_08/day_01/project_01.md | 19 ++++++ week_08/day_02/day_presentation.txt | 1 + week_08/day_02/day_title.txt | 1 + week_08/day_02/lesson_01.md | 36 ++++++++++ week_08/day_02/project_01.md | 19 ++++++ week_08/day_03/day_presentation.txt | 1 + week_08/day_03/day_title.txt | 1 + week_08/day_03/lesson_01.md | 36 ++++++++++ week_08/day_03/project_01.md | 18 +++++ week_08/day_04/day_presentation.txt | 1 + week_08/day_04/day_title.txt | 1 + week_08/day_04/lesson_01.md | 32 +++++++++ week_08/day_04/project_01.md | 19 ++++++ week_08/day_05/day_presentation.txt | 1 + week_08/day_05/day_title.txt | 1 + week_08/day_05/lesson_01.md | 34 ++++++++++ week_08/day_05/project_01.md | 19 ++++++ week_08/week_presentation.txt | 2 + week_08/week_title.txt | 1 + week_09/day_01/day_presentation.txt | 1 + week_09/day_01/day_title.txt | 1 + week_09/day_01/lesson_01.md | 32 +++++++++ week_09/day_01/lesson_02.md | 34 ++++++++++ week_09/day_01/project_01.md | 17 +++++ week_09/day_02/day_presentation.txt | 2 + week_09/day_02/day_title.txt | 1 + week_09/day_02/lesson_01.md | 57 ++++++++++++++++ week_09/day_02/project_01.md | 17 +++++ week_09/day_03/day_presentation.txt | 1 + week_09/day_03/day_title.txt | 1 + week_09/day_03/lesson_01.md | 35 ++++++++++ week_09/day_03/project_01.md | 15 +++++ week_09/day_04/day_presentation.txt | 1 + week_09/day_04/day_title.txt | 1 + week_09/day_04/lesson_01.md | 33 +++++++++ week_09/day_04/project_01.md | 16 +++++ week_09/day_05/day_presentation.txt | 1 + week_09/day_05/day_title.txt | 1 + week_09/day_05/lesson_01.md | 42 ++++++++++++ week_09/day_05/project_01.md | 14 ++++ week_09/week_presentation.txt | 2 + week_09/week_title.txt | 1 + week_10/day_01/day_presentation.txt | 1 + week_10/day_01/day_title.txt | 1 + week_10/day_01/lesson_01.md | 36 ++++++++++ week_10/day_01/project_01.md | 15 +++++ week_10/day_02/day_presentation.txt | 1 + week_10/day_02/day_title.txt | 1 + week_10/day_02/lesson_01.md | 28 ++++++++ week_10/day_02/project_01.md | 14 ++++ week_10/day_03/day_presentation.txt | 1 + week_10/day_03/day_title.txt | 1 + week_10/day_03/lesson_01.md | 29 ++++++++ week_10/day_03/project_01.md | 14 ++++ week_10/day_04/day_presentation.txt | 1 + week_10/day_04/day_title.txt | 1 + week_10/day_04/lesson_01.md | 29 ++++++++ week_10/day_04/project_01.md | 14 ++++ week_10/day_05/day_presentation.txt | 1 + week_10/day_05/day_title.txt | 1 + week_10/day_05/lesson_01.md | 29 ++++++++ week_10/day_05/project_01.md | 16 +++++ week_10/week_presentation.txt | 1 + week_10/week_title.txt | 1 + week_11/day_01/day_presentation.txt | 1 + week_11/day_01/day_title.txt | 1 + week_11/day_01/lesson_01.md | 29 ++++++++ week_11/day_01/project_01.md | 16 +++++ week_11/day_02/day_presentation.txt | 1 + week_11/day_02/day_title.txt | 1 + week_11/day_02/lesson_01.md | 29 ++++++++ week_11/day_02/project_01.md | 15 +++++ week_11/day_03/day_presentation.txt | 1 + week_11/day_03/day_title.txt | 1 + week_11/day_03/lesson_01.md | 29 ++++++++ week_11/day_03/project_01.md | 15 +++++ week_11/day_04/day_presentation.txt | 1 + week_11/day_04/day_title.txt | 1 + week_11/day_04/lesson_01.md | 29 ++++++++ week_11/day_04/project_01.md | 15 +++++ week_11/day_05/day_presentation.txt | 1 + week_11/day_05/day_title.txt | 1 + week_11/day_05/lesson_01.md | 29 ++++++++ week_11/day_05/project_01.md | 16 +++++ week_11/week_presentation.txt | 1 + week_11/week_title.txt | 1 + week_12/day_01/day_presentation.txt | 1 + week_12/day_01/day_title.txt | 1 + week_12/day_01/lesson_01.md | 30 +++++++++ week_12/day_01/project_01.md | 15 +++++ week_12/day_02/day_presentation.txt | 1 + week_12/day_02/day_title.txt | 1 + week_12/day_02/lesson_01.md | 28 ++++++++ week_12/day_02/project_01.md | 14 ++++ week_12/day_03/day_presentation.txt | 1 + week_12/day_03/day_title.txt | 1 + week_12/day_03/lesson_01.md | 27 ++++++++ week_12/day_03/project_01.md | 14 ++++ week_12/day_04/day_presentation.txt | 1 + week_12/day_04/day_title.txt | 1 + week_12/day_04/lesson_01.md | 29 ++++++++ week_12/day_04/project_01.md | 15 +++++ week_12/day_05/day_presentation.txt | 1 + week_12/day_05/day_title.txt | 1 + week_12/day_05/lesson_01.md | 29 ++++++++ week_12/day_05/project_01.md | 14 ++++ week_12/week_presentation.txt | 1 + week_12/week_title.txt | 1 + 175 files changed, 2238 insertions(+), 227 deletions(-) create mode 100644 week_06/day_01/lesson_03.md create mode 100644 week_07/day_01/day_presentation.txt create mode 100644 week_07/day_01/day_title.txt create mode 100644 week_07/day_01/lesson_01.md create mode 100644 week_07/day_01/lesson_02.md create mode 100644 week_07/day_01/project_01.md create mode 100644 week_07/day_02/day_presentation.txt create mode 100644 week_07/day_02/day_title.txt create mode 100644 week_07/day_02/lesson_01.md create mode 100644 week_07/day_02/lesson_02.md create mode 100644 week_07/day_02/project_01.md create mode 100644 week_07/day_03/day_presentation.txt create mode 100644 week_07/day_03/day_title.txt create mode 100644 week_07/day_03/lesson_01.md create mode 100644 week_07/day_03/project_01.md create mode 100644 week_07/day_04/day_presentation.txt create mode 100644 week_07/day_04/day_title.txt create mode 100644 week_07/day_04/lesson_01.md create mode 100644 week_07/day_04/project_01.md create mode 100644 week_07/day_05/day_presentation.txt create mode 100644 week_07/day_05/day_title.txt create mode 100644 week_07/day_05/lesson_01.md create mode 100644 week_07/day_05/project_01.md create mode 100644 week_07/week_presentation.txt create mode 100644 week_07/week_title.txt create mode 100644 week_08/day_01/day_presentation.txt create mode 100644 week_08/day_01/day_title.txt create mode 100644 week_08/day_01/lesson_01.md create mode 100644 week_08/day_01/project_01.md create mode 100644 week_08/day_02/day_presentation.txt create mode 100644 week_08/day_02/day_title.txt create mode 100644 week_08/day_02/lesson_01.md create mode 100644 week_08/day_02/project_01.md create mode 100644 week_08/day_03/day_presentation.txt create mode 100644 week_08/day_03/day_title.txt create mode 100644 week_08/day_03/lesson_01.md create mode 100644 week_08/day_03/project_01.md create mode 100644 week_08/day_04/day_presentation.txt create mode 100644 week_08/day_04/day_title.txt create mode 100644 week_08/day_04/lesson_01.md create mode 100644 week_08/day_04/project_01.md create mode 100644 week_08/day_05/day_presentation.txt create mode 100644 week_08/day_05/day_title.txt create mode 100644 week_08/day_05/lesson_01.md create mode 100644 week_08/day_05/project_01.md create mode 100644 week_08/week_presentation.txt create mode 100644 week_08/week_title.txt create mode 100644 week_09/day_01/day_presentation.txt create mode 100644 week_09/day_01/day_title.txt create mode 100644 week_09/day_01/lesson_01.md create mode 100644 week_09/day_01/lesson_02.md create mode 100644 week_09/day_01/project_01.md create mode 100644 week_09/day_02/day_presentation.txt create mode 100644 week_09/day_02/day_title.txt create mode 100644 week_09/day_02/lesson_01.md create mode 100644 week_09/day_02/project_01.md create mode 100644 week_09/day_03/day_presentation.txt create mode 100644 week_09/day_03/day_title.txt create mode 100644 week_09/day_03/lesson_01.md create mode 100644 week_09/day_03/project_01.md create mode 100644 week_09/day_04/day_presentation.txt create mode 100644 week_09/day_04/day_title.txt create mode 100644 week_09/day_04/lesson_01.md create mode 100644 week_09/day_04/project_01.md create mode 100644 week_09/day_05/day_presentation.txt create mode 100644 week_09/day_05/day_title.txt create mode 100644 week_09/day_05/lesson_01.md create mode 100644 week_09/day_05/project_01.md create mode 100644 week_09/week_presentation.txt create mode 100644 week_09/week_title.txt create mode 100644 week_10/day_01/day_presentation.txt create mode 100644 week_10/day_01/day_title.txt create mode 100644 week_10/day_01/lesson_01.md create mode 100644 week_10/day_01/project_01.md create mode 100644 week_10/day_02/day_presentation.txt create mode 100644 week_10/day_02/day_title.txt create mode 100644 week_10/day_02/lesson_01.md create mode 100644 week_10/day_02/project_01.md create mode 100644 week_10/day_03/day_presentation.txt create mode 100644 week_10/day_03/day_title.txt create mode 100644 week_10/day_03/lesson_01.md create mode 100644 week_10/day_03/project_01.md create mode 100644 week_10/day_04/day_presentation.txt create mode 100644 week_10/day_04/day_title.txt create mode 100644 week_10/day_04/lesson_01.md create mode 100644 week_10/day_04/project_01.md create mode 100644 week_10/day_05/day_presentation.txt create mode 100644 week_10/day_05/day_title.txt create mode 100644 week_10/day_05/lesson_01.md create mode 100644 week_10/day_05/project_01.md create mode 100644 week_10/week_presentation.txt create mode 100644 week_10/week_title.txt create mode 100644 week_11/day_01/day_presentation.txt create mode 100644 week_11/day_01/day_title.txt create mode 100644 week_11/day_01/lesson_01.md create mode 100644 week_11/day_01/project_01.md create mode 100644 week_11/day_02/day_presentation.txt create mode 100644 week_11/day_02/day_title.txt create mode 100644 week_11/day_02/lesson_01.md create mode 100644 week_11/day_02/project_01.md create mode 100644 week_11/day_03/day_presentation.txt create mode 100644 week_11/day_03/day_title.txt create mode 100644 week_11/day_03/lesson_01.md create mode 100644 week_11/day_03/project_01.md create mode 100644 week_11/day_04/day_presentation.txt create mode 100644 week_11/day_04/day_title.txt create mode 100644 week_11/day_04/lesson_01.md create mode 100644 week_11/day_04/project_01.md create mode 100644 week_11/day_05/day_presentation.txt create mode 100644 week_11/day_05/day_title.txt create mode 100644 week_11/day_05/lesson_01.md create mode 100644 week_11/day_05/project_01.md create mode 100644 week_11/week_presentation.txt create mode 100644 week_11/week_title.txt create mode 100644 week_12/day_01/day_presentation.txt create mode 100644 week_12/day_01/day_title.txt create mode 100644 week_12/day_01/lesson_01.md create mode 100644 week_12/day_01/project_01.md create mode 100644 week_12/day_02/day_presentation.txt create mode 100644 week_12/day_02/day_title.txt create mode 100644 week_12/day_02/lesson_01.md create mode 100644 week_12/day_02/project_01.md create mode 100644 week_12/day_03/day_presentation.txt create mode 100644 week_12/day_03/day_title.txt create mode 100644 week_12/day_03/lesson_01.md create mode 100644 week_12/day_03/project_01.md create mode 100644 week_12/day_04/day_presentation.txt create mode 100644 week_12/day_04/day_title.txt create mode 100644 week_12/day_04/lesson_01.md create mode 100644 week_12/day_04/project_01.md create mode 100644 week_12/day_05/day_presentation.txt create mode 100644 week_12/day_05/day_title.txt create mode 100644 week_12/day_05/lesson_01.md create mode 100644 week_12/day_05/project_01.md create mode 100644 week_12/week_presentation.txt create mode 100644 week_12/week_title.txt diff --git a/README.md b/README.md index b8277cf..a292529 100644 --- a/README.md +++ b/README.md @@ -269,11 +269,15 @@ Voici l'arborescence de notre dossier : Chaque semaine sera un dossier à la racine : -- `week_01/` pour la semaine 1 -- `week_02/` pour la semaine 2 -- `week_06/` pour la semaine 6 -- `week_10/` pour la semaine 10 -- and so on + - `week_01/` pour la semaine 1 + - `week_02/` pour la semaine 2 + - `week_06/` découverte Docker et Kubernetes + - `week_07/` Infrastructure as Code avec Terraform + - `week_08/` Observabilité et monitoring + - `week_09/` Sécurité DevOps + - `week_10/` containerisation avancée + - `week_11/` automatisation avancée + - `week_12/` projet final Chaque semaine aura : diff --git a/week_01/day_03/project_01.md b/week_01/day_03/project_01.md index 400d224..19347c7 100644 --- a/week_01/day_03/project_01.md +++ b/week_01/day_03/project_01.md @@ -11,7 +11,7 @@ Avec ta prise d'initiative d'hier sur la mise en place d'un script de création Le CTO a de nouveau regardé ton CV afin d'estimer ton vrai potentiel. En parcourant ton CV, cette fois-ci attentivement, il remarque tu as des connaissances en virtualisation. -Ça tombe bien s'exclame-t-il ! J'avais justement besoin de faire quelques testes sur une application avant sa mise en production. +Ça tombe bien s'exclame-t-il ! J'avais justement besoin de faire quelques tests sur une application avant sa mise en production. Tout joyeux, il se met à rédiger des instructions concernant le test qu'il veut que tu réalises. diff --git a/week_05/day_01/day_title.txt b/week_05/day_01/day_title.txt index bc29caf..8d0a22d 100644 --- a/week_05/day_01/day_title.txt +++ b/week_05/day_01/day_title.txt @@ -1 +1 @@ -Découvrir de Github Actions. \ No newline at end of file +Découvrir GitHub Actions diff --git a/week_05/day_01/lesson_01.md b/week_05/day_01/lesson_01.md index 807a215..1de4610 100644 --- a/week_05/day_01/lesson_01.md +++ b/week_05/day_01/lesson_01.md @@ -8,7 +8,7 @@ Depuis longtemps les devs ont voulu maitriser ce processus et quand je dis longt Depuis le début des années 90, pour être précis. Mais avant de rentrer dans les détails, il nous faut d'abord comprendre précisément -la signification du terme `Contiuous Integration` en abrégé ,`CI`, et `Continuous Delivery`, `Continuous Deployement` qui en abrégé se prononcent/s'écrivent, `CD`. +la signification du terme `Continuous Integration` en abrégé ,`CI`, et `Continuous Delivery`, `Continuous Deployment` qui en abrégé se prononcent/s'écrivent, `CD`. Je sais, c'est peut-être un peu flou pour toi, mais ces trois termes ne veulent pas dire la même. Mais je vais t'expliquer chaque terme un par un 😃. @@ -202,7 +202,7 @@ D'autres champs existent, mais je vais te laisser les découvrir toi-même leurs D'un point de vue globale chaque `job`, représente la machine virtuelle sur laquelle le workflow va se lancer. Tu peux définir l'OS de ces VMs (ubuntu, windows, debian, etc.) avec le champ `runs-on`, il est également possible de lancer des VMs des customs avec plus de RAM, CPU, Os avec license, etc. -Les VMs de base de Github viennent tous avec des logiciels (git, npm, yarn, pip, ...) et langages (ruby, pyton, Go, Nodejs..) préinstallés afin de nous faciliter la vie, mais libre à toi d'en rajouter d'autres. :smiley: +Les VMs de base de Github viennent tous avec des logiciels (git, npm, yarn, pip, ...) et langages (ruby, python, Go, Nodejs..) préinstallés afin de nous faciliter la vie, mais libre à toi d'en rajouter d'autres. :smiley: Voici la [liste](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software) des logiciels préinstallés. diff --git a/week_05/day_02/day_title.txt b/week_05/day_02/day_title.txt index f00790e..7289957 100644 --- a/week_05/day_02/day_title.txt +++ b/week_05/day_02/day_title.txt @@ -1 +1 @@ -Les variables dans Github Actions : Notions avancées. \ No newline at end of file +Variables avancées dans GitHub Actions diff --git a/week_05/day_02/lesson_01.md b/week_05/day_02/lesson_01.md index d883990..0108db9 100644 --- a/week_05/day_02/lesson_01.md +++ b/week_05/day_02/lesson_01.md @@ -1,17 +1,39 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Variables avancées dans GitHub Actions -## 1. Introduction/Historique et contexte +## 1. Introduction +Tu sais désormais lancer un workflow basique. Aujourd'hui, on va pousser un peu plus loin afin de le rendre vraiment dynamique. Pour cela, GitHub Actions met à ta disposition un grand nombre de variables que tu peux exploiter pour adapter ton pipeline à toutes les situations. +## 2. Historique et contexte +GitHub Actions a été lancé en 2018. Les variables, secrets et contextes sont apparus pour personnaliser les workflows tout en restant sécurisés. -## 2. La ressource -### 2.1. ... +## 3. La ressource +### 2.1. Les variables d'environnement +Dans un fichier de workflow, la clé `env` permet de définir des variables accessibles dans toutes les étapes. Elles sont très utiles pour partager un chemin ou une option entre plusieurs actions. +```yaml +env: + APP_ENV: production + PACKAGE_VERSION: 1.0.0 +``` -### 2.2. ... +Ces variables sont ensuite disponibles dans chaque `run` ou action avec la syntaxe `${{ env.APP_ENV }}`. -## 3. Points importants à retenir +### 2.2. Les secrets +GitHub propose un coffre-fort pour stocker des informations sensibles comme des clés API. Les secrets sont appelés avec `${{ secrets.NOM_DU_SECRET }}` et ne sont jamais affichés en clair dans les logs. +### 2.3. Les contextes +Lorsque tu as besoin de données spécifiques au repo ou au job, les contextes entrent en jeu. Le contexte `github` te donne par exemple accès au nom de la branche ou du dépôt. Combine-les avec des expressions pour créer des conditions plus intelligentes. -## 4. Pour aller plus loin -Pas besoin pour l'instant +### 2.4. Stratégies d'environnements +Depuis la console GitHub, tu peux définir des variables et secrets propres à un environnement. Cela permet d'avoir des valeurs différentes en fonction de la branche ou du contexte de déploiement (`staging`, `production`, etc.). + +### 2.5. Utiliser les variables de sortie +Certaines actions retournent des valeurs au moyen de la commande `set-output`. Tu peux récupérer ces résultats dans les étapes suivantes pour chaîner intelligemment tes jobs ou déclencher des déploiements conditionnels. + +## 4. Points importants à retenir +- `env` partage des variables simples entre toutes les étapes. +- Les secrets sont chiffrés et cachés dans les logs. +- Les contextes fournissent une multitude d'informations utiles sur ton workflow. + +## 5. Pour aller plus loin +La [documentation officielle](https://docs.github.com/fr/actions) regorge d'exemples. Jette aussi un oeil à l'article "Environment variables" dans la doc pour découvrir toutes les possibilités. diff --git a/week_05/day_02/project_01.md b/week_05/day_02/project_01.md index d883990..3c0e3ed 100644 --- a/week_05/day_02/project_01.md +++ b/week_05/day_02/project_01.md @@ -1,17 +1,22 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Projet : pipeline avec variables -## 1. Introduction/Historique et contexte +## 1. Introduction +L'objectif est de manipuler les variables et les secrets dans un workflow concret. - -## 2. La ressource -### 2.1. ... - - -### 2.2. ... +## 2. Tâches +- Initialise un dépôt GitHub et ajoute un simple fichier Python ou Node. +- Crée un workflow déclenché sur chaque push qui: + - installe les dépendances, + - exécute une commande de test, + - affiche la valeur d'une variable définie dans la section `env`. +- Ajoute un secret appelé `SUPER_TOKEN` et affiche les dix premiers caractères dans une étape dédiée. + - Utilise également une variable de sortie d'une action officielle pour récupérer la version de Node installée et affiche-la. + - Ajoute enfin un environnement `staging` et associe un second secret à cet environnement pour simuler un déploiement sécurisé. ## 3. Points importants à retenir +Ce projet te montre comment passer des informations à tes jobs et comment sécuriser les données sensibles. +Tu comprendras aussi comment distinguer plusieurs environnements et chaîner intelligemment les étapes grâce aux sorties d'actions. +### Pour aller plus loin +Lis l'article [Using environments for deployment](https://docs.github.com/fr/actions/deployment/targeting-different-environments/using-environments-for-deployment) afin de découvrir toutes les options offertes par GitHub pour isoler tes secrets. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_03/day_title.txt b/week_05/day_03/day_title.txt index bb389e9..075e2cb 100644 --- a/week_05/day_03/day_title.txt +++ b/week_05/day_03/day_title.txt @@ -1 +1 @@ -Jouer avec les conteneurs dans Github Actions. \ No newline at end of file +Jouer avec les conteneurs dans GitHub Actions diff --git a/week_05/day_03/lesson_01.md b/week_05/day_03/lesson_01.md index d883990..2d0ba38 100644 --- a/week_05/day_03/lesson_01.md +++ b/week_05/day_03/lesson_01.md @@ -1,17 +1,43 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Jouer avec les conteneurs dans GitHub Actions -## 1. Introduction/Historique et contexte +## 1. Introduction +GitHub Actions permet d'exécuter tes jobs dans des conteneurs Docker. C'est pratique pour maîtriser ton environnement et partager des images communes entre plusieurs workflows. +## 2. Historique et contexte +L'utilisation de Docker s'est généralisée dès 2013 et GitHub l'a intégré à ses workflows pour garantir des environnements identiques. -## 2. La ressource -### 2.1. ... +## 3. La ressource +### 2.1. Utiliser une image officielle +Dans la section `jobs..container`, indique simplement l'image Docker à utiliser. GitHub téléchargera celle-ci depuis Docker Hub ou ton registry préféré. +```yaml +jobs: + tests: + runs-on: ubuntu-latest + container: node:20 + steps: + - uses: actions/checkout@v4 + - run: npm test +``` -### 2.2. ... +### 2.2. Construire sa propre image +Pour plus de contrôle, tu peux builder ton image à la volée grâce à l'action `docker/build-push-action`. Elle est utile lorsque ton projet nécessite des dépendances spécifiques. -## 3. Points importants à retenir +### 2.3. Matrices de conteneurs +Combine la stratégie `matrix` avec différents conteneurs pour tester plusieurs versions d'un langage ou outil en parallèle. +### 2.4. Services additionnels +Un job peut utiliser plusieurs conteneurs "services" pour simuler une base de données ou un cache. Déclare-les dans `services:` et relie-les au conteneur principal via un réseau virtuel. + +### 2.5. Partage de données +Pense à monter un volume pour partager des fichiers entre plusieurs étapes ou pour mettre en cache les dépendances et accélérer les builds suivants. + +## 4. Points importants à retenir +- Les conteneurs garantissent une exécution cohérente de tes jobs. +- Builder l'image au sein du workflow permet de tester exactement ce qui sera déployé. +- Les matrices multiplient les environnements de test sans configuration complexe. + +## 5. Pour aller plus loin +Rends-toi sur le dépôt `docker/build-push-action` pour voir tous les paramètres disponibles. Expérimente aussi avec GitHub Packages pour héberger tes propres images. +N'hésite pas à coupler ces conteneurs avec [Docker Compose](https://docs.docker.com/compose/) pour reproduire un environnement complet lors des tests. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_03/project_01.md b/week_05/day_03/project_01.md index d883990..6462524 100644 --- a/week_05/day_03/project_01.md +++ b/week_05/day_03/project_01.md @@ -1,17 +1,18 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Projet : tests en conteneur -## 1. Introduction/Historique et contexte +## 1. Introduction +L'objectif est de faire tourner ton outil de test dans une image Docker dédiée. - -## 2. La ressource -### 2.1. ... - - -### 2.2. ... +## 2. Tâches +- Prépare un `Dockerfile` qui installe toutes les dépendances de ton application. +- Dans le workflow, utilise cette image via la clé `container` pour exécuter les tests. +- Paramètre une matrice avec deux versions de Node ou Python pour t'assurer que ton code fonctionne partout. +- Configure un service de base de données dans `services:` pour tester l'intégration complète de ton application. +- Stocke les rapports de tests en artefacts pour pouvoir les consulter après exécution. ## 3. Points importants à retenir +En emballant ton environnement dans une image, tu garantis des résultats identiques en local et dans ton pipeline. +### Pour aller plus loin +Lis la documentation [GitHub Actions: using containerized services](https://docs.github.com/fr/actions/using-containerized-services) pour comprendre comment chaîner plusieurs images dans un même workflow. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_04/day_title.txt b/week_05/day_04/day_title.txt index 84535f8..73d107c 100644 --- a/week_05/day_04/day_title.txt +++ b/week_05/day_04/day_title.txt @@ -1 +1 @@ -Rendre tes workflow performantes et event-driven. \ No newline at end of file +Des workflows performants et event-driven diff --git a/week_05/day_04/lesson_01.md b/week_05/day_04/lesson_01.md index d883990..a3c3446 100644 --- a/week_05/day_04/lesson_01.md +++ b/week_05/day_04/lesson_01.md @@ -1,17 +1,33 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Des workflows performants et event-driven -## 1. Introduction/Historique et contexte +## 1. Introduction +Les workflows peuvent rapidement devenir longs et coûteux s'ils sont mal optimisés. Nous allons voir comment les déclencher intelligemment et réduire leur durée. +## 2. Historique et contexte +Au départ limités au push, les workflows GitHub Actions se sont enrichis d'événements et d'un système de cache pour accélérer les CI. -## 2. La ressource -### 2.1. ... +## 3. La ressource +### 2.1. Les événements personnalisés +GitHub Actions supporte une grande liste d'événements : push, pull_request, mais aussi un simple appel HTTP grâce aux `workflow_dispatch` et `repository_dispatch`. Utilise-les pour lancer des tâches uniquement quand cela est nécessaire. +### 2.2. La mise en cache +L'action `actions/cache` permet de sauvegarder des dépendances ou des fichiers entre deux exécutions. Ton workflow gagne ainsi plusieurs minutes. -### 2.2. ... +### 2.3. Le parallélisme +Avec `strategy.matrix` et `max-parallel`, tu peux contrôler le nombre de jobs qui s'exécutent en même temps, évitant de saturer tes runners auto-hébergés. -## 3. Points importants à retenir +### 2.4. Les artefacts +Pense à sauvegarder tes binaires ou rapports de tests grâce à `actions/upload-artifact` pour les réutiliser dans d'autres jobs ou les partager avec ton équipe. +### 2.5. Les dépendances conditionnelles +Certaines étapes peuvent s'exécuter seulement si la précédente réussit via `if: success()`. Cela permet d'éviter des étapes inutiles en cas d'erreur. + +## 4. Points importants à retenir +- Choisis le bon événement pour limiter les déclenchements inutiles. +- Le cache réduit le temps d'installation des dépendances. +- Contrôler le parallélisme permet d'utiliser au mieux les ressources disponibles. + +## 5. Pour aller plus loin +Explore la documentation sur `repository_dispatch` pour déclencher un workflow depuis un autre dépôt ou un script externe. +Tu peux également regarder l'action [`actions/cache`](https://github.com/actions/cache) pour optimiser la durée de tes builds. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_04/project_01.md b/week_05/day_04/project_01.md index d883990..9b0e863 100644 --- a/week_05/day_04/project_01.md +++ b/week_05/day_04/project_01.md @@ -1,17 +1,18 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Projet : workflow déclenché à la demande -## 1. Introduction/Historique et contexte +## 1. Introduction +Nous allons créer un workflow qui ne s'exécute qu'à la demande et qui utilise un cache pour accélérer les dépendances. - -## 2. La ressource -### 2.1. ... - - -### 2.2. ... +## 2. Tâches +- Mets en place un workflow avec l'événement `workflow_dispatch`. +- Ajoute une étape pour installer tes dépendances (npm ou pip) en utilisant `actions/cache`. +- Prévoyez un job de build qui tourne uniquement si l'installation a réussi. +- Upload le binaire résultant en utilisant `actions/upload-artifact`. +- Définis une matrice de tests pour valider ta build sur plusieurs versions de Node ou Python. ## 3. Points importants à retenir +En déclenchant manuellement ton pipeline, tu maîtrises parfaitement quand tu consommes du temps de CI et l'usage du cache évite bien des temps morts. +### Pour aller plus loin +Lis la page [Events that trigger workflows](https://docs.github.com/fr/actions/using-workflows/events-that-trigger-workflows) pour comprendre toutes les possibilités offertes par GitHub Actions. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_05/day_title.txt b/week_05/day_05/day_title.txt index b8ded8c..b53c883 100644 --- a/week_05/day_05/day_title.txt +++ b/week_05/day_05/day_title.txt @@ -1 +1 @@ -Coder Actions et les utiliser sur Github Actions \ No newline at end of file +Coder ses propres Actions diff --git a/week_05/day_05/lesson_01.md b/week_05/day_05/lesson_01.md index d883990..1901642 100644 --- a/week_05/day_05/lesson_01.md +++ b/week_05/day_05/lesson_01.md @@ -1,17 +1,33 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Coder ses propres Actions -## 1. Introduction/Historique et contexte +## 1. Introduction +Parfois, aucune action existante ne répond exactement à ton besoin. Tu peux alors créer ta propre Action, soit avec Docker, soit en JavaScript. +## 2. Historique et contexte +Dès 2019 la communauté a partagé ses propres Actions, permettant d'automatiser des tâches spécifiques avec de simples dépôts. -## 2. La ressource -### 2.1. ... +## 3. La ressource +### 2.1. Action JavaScript +Une action JS est un dépôt contenant un script Node exécuté par GitHub. Avec quelques dépendances et un `action.yml`, tu peux publier une action réutilisable par la communauté. +### 2.2. Action Docker +Si tu préfères exécuter un binaire ou un outil en particulier, l'action Docker est idéale. Elle encapsule tout ce qu'il faut dans une image. -### 2.2. ... +### 2.3. Publication +Une fois ton action prête, crée un tag et publie-la sur la marketplace GitHub. Pense à rédiger un README clair pour expliquer son utilisation. -## 3. Points importants à retenir +### 2.4. Gérer les versions +Les utilisateurs d'une action s'appuient souvent sur un numéro de version. N'oublie pas de créer un tag Git puis de publier un `release` lorsque tu ajoutes une fonctionnalité majeure. +### 2.5. Tester son action +Avant de la rendre publique, écris un workflow dédié qui lance ton action sur différentes plateformes. Cela évite les mauvaises surprises une fois en production. + +## 4. Points importants à retenir +- Les actions permettent de factoriser du code réutilisable dans plusieurs workflows. +- Une action JavaScript s'exécute très vite, tandis qu'une action Docker offre plus de liberté sur l'environnement. +- Documente toujours les entrées et sorties de ton action pour faciliter son adoption. + +## 5. Pour aller plus loin +La [création d'une action](https://docs.github.com/fr/actions/creating-actions) est très bien détaillée par GitHub. Inspire-toi aussi des actions populaires pour comprendre les bonnes pratiques. +Pour voir un exemple complet, consulte le dépôt [`actions/setup-node`](https://github.com/actions/setup-node) qui illustre la gestion des versions et des tests automatisés. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_05/day_05/project_01.md b/week_05/day_05/project_01.md index d883990..d1f9a52 100644 --- a/week_05/day_05/project_01.md +++ b/week_05/day_05/project_01.md @@ -1,17 +1,18 @@ -# Monitorer des instances EC2 avec AWS CloudWatch -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Projet : créer une action personnalisée -## 1. Introduction/Historique et contexte +## 1. Introduction +Tu vas développer une petite action qui vérifie la présence d'un fichier et affiche son contenu. - -## 2. La ressource -### 2.1. ... - - -### 2.2. ... +## 2. Tâches +- Initialise un dépôt dédié à ton action avec `action.yml`. +- Écris un script JavaScript prenant en entrée le chemin d'un fichier à lire. +- Publie cette action et réutilise-la depuis un autre projet grâce au tag que tu auras créé. +- Configure un workflow de test pour valider ton action sur plusieurs systèmes d'exploitation. +- Documente clairement les paramètres dans le `README` et ajoute un exemple d'usage. ## 3. Points importants à retenir +Ce projet illustre le cycle complet de création et de partage d'une action sur la marketplace. +### Pour aller plus loin +Parcourez le guide [Publishing actions in GitHub Marketplace](https://docs.github.com/fr/actions/creating-actions/publishing-actions-in-github-marketplace) pour promouvoir au mieux votre travail. -## 4. Pour aller plus loin -Pas besoin pour l'instant diff --git a/week_06/day_01/day_presentation.txt b/week_06/day_01/day_presentation.txt index 1732891..80f8de2 100644 --- a/week_06/day_01/day_presentation.txt +++ b/week_06/day_01/day_presentation.txt @@ -1 +1 @@ -Description de la première journée au format texte et en un paragraphe. \ No newline at end of file +Premiers pas avec l'outil Docker et ses concepts. diff --git a/week_06/day_01/day_title.txt b/week_06/day_01/day_title.txt index f2fbc0a..2c7be52 100644 --- a/week_06/day_01/day_title.txt +++ b/week_06/day_01/day_title.txt @@ -1 +1 @@ -Titre de la première journée \ No newline at end of file +Découverte de Docker diff --git a/week_06/day_01/lesson_01.md b/week_06/day_01/lesson_01.md index c781976..40abe97 100644 --- a/week_06/day_01/lesson_01.md +++ b/week_06/day_01/lesson_01.md @@ -1,23 +1,39 @@ -# Titre de la première ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Découverte de Docker ## 1. Introduction -Une introduction sur la ressource. +Docker est aujourd'hui l'outil incontournable pour créer des conteneurs. L'objectif de ce premier jour est de comprendre son intérêt et d'apprendre à lancer ses premiers conteneurs. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Né en 2013 chez dotCloud, Docker a popularisé les conteneurs en les rendant simples à utiliser pour tous. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 2.1. Pourquoi Docker ? +Avant Docker, déployer une application signifiait souvent configurer des serveurs manuellement. Avec la conteneurisation, tout l'environnement est décrit dans une image et se lance de la même manière partout. -### 3.1. Première sous partie -blabla +### 2.2. Installer Docker +Rends-toi sur [docker.com](https://www.docker.com) et installe la version adaptée à ton système. Vérifie ensuite que la commande `docker` fonctionne dans ton terminal. -### 3.2. Deuxième sous partie -blabla +### 2.3. Lancer son premier conteneur +Essaye la commande suivante pour afficher un message : + +```bash +docker run hello-world +``` + +Docker va télécharger l'image `hello-world` et exécuter un petit programme qui confirme que tout fonctionne. + +### 2.4. Construire sa propre image +Crée un fichier `Dockerfile` minimal avec une instruction `FROM` puis `COPY` de ton code. Termine par un `CMD` lançant ton application. Exécute `docker build -t monapp .` pour générer l'image. + +### 2.5. Docker Compose +Lorsque ton application nécessite plusieurs services (base de données, cache), définis-les dans un `docker-compose.yml`. La commande `docker compose up` lancera l'ensemble facilement. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Docker simplifie grandement la livraison d'applications. +- Une image se comporte toujours de la même façon quel que soit l'hôte. +- La commande `docker run` permet de démarrer un conteneur à partir d'une image. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +Parcours la documentation officielle pour te familiariser avec les commandes de base `docker ps`, `docker stop`, `docker rm`. +Teste aussi [Play with Docker](https://labs.play-with-docker.com/) pour pratiquer rapidement sans rien installer sur ta machine. + diff --git a/week_06/day_01/lesson_02.md b/week_06/day_01/lesson_02.md index 7acab06..aead56c 100644 --- a/week_06/day_01/lesson_02.md +++ b/week_06/day_01/lesson_02.md @@ -1,23 +1,30 @@ -# Titre de la deuxième ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Docker Compose ## 1. Introduction -Une introduction sur la ressource. +Lorsqu'une application nécessite plusieurs services (base de données, cache, etc.), Docker Compose simplifie la mise en place de cet environnement. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Compose est un outil officiel de Docker apparu pour orchestrer plusieurs conteneurs à l'aide d'un simple fichier `docker-compose.yml`. Il est devenu incontournable pour développer en local. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 3.1. Définir un service +Chaque service se décrit par une image et quelques options : -### 3.1. Première sous partie -blabla +```yaml +services: + db: + image: postgres:16 + ports: + - "5432:5432" +``` -### 3.2. Deuxième sous partie -blabla +### 3.2. Lancer l'ensemble +Une fois le fichier rédigé, démarre tout simplement avec `docker compose up -d` puis arrête avec `docker compose down`. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Compose permet de décrire plusieurs conteneurs dans un seul fichier. +- Les ports et volumes se configurent aisément pour chaque service. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +Parcourez les exemples du site officiel pour découvrir d'autres options, notamment les réseaux et la variable `depends_on`. + diff --git a/week_06/day_01/lesson_03.md b/week_06/day_01/lesson_03.md new file mode 100644 index 0000000..22751b7 --- /dev/null +++ b/week_06/day_01/lesson_03.md @@ -0,0 +1,59 @@ +# Introduction à Kubernetes + +## 1. Pourquoi Kubernetes ? +Kubernetes est devenu l'orchestrateur de conteneurs de référence. Il permet de gérer le cycle de vie de milliers de conteneurs de manière déclarative. + +## 2. Historique et contexte +Créé chez Google sous le nom de Borg, Kubernetes a été rendu open source en 2014. Son adoption rapide est due à sa capacité à automatiser le déploiement, la montée en charge et la reprise après incident. + +## 3. La ressource +### 3.1. Notions de base +Avant toute chose, retiens que Kubernetes se compose de noeuds et d'un plan de contrôle. Les applications tournent dans des **pods**, groupements d'un ou plusieurs conteneurs. + +### 3.2. Installation locale +Pour débuter, installe Minikube ou Kind afin de disposer d'un cluster local. Tu pourras ensuite utiliser la commande `kubectl` pour communiquer avec le serveur. + +### 3.3. Déploiement d'un premier pod +Crée un fichier `pod.yaml` avec la structure suivante : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: hello +spec: + containers: + - name: app + image: nginx +``` + +Applique le manifest avec `kubectl apply -f pod.yaml`. Vérifie l'état avec `kubectl get pods`. + +### 3.4. Services et exposition +Un pod n'est pas accessible directement de l'extérieur. Définis un service de type `NodePort` pour exposer ton application. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: hello-svc +spec: + type: NodePort + selector: + app: hello + ports: + - port: 80 + targetPort: 80 +``` + +### 3.5. Mise à l'échelle +Avec les déploiements (`Deployment`), Kubernetes peut répliquer automatiquement ton application. Utilise le champ `replicas` pour définir le nombre de copies. + +## 4. Points importants à retenir +- Kubernetes fonctionne à l'aide de fichiers YAML décrivant l'état désiré. +- La CLI `kubectl` permet d'interroger et de modifier le cluster. +- Les services exposent les pods vers l'extérieur. + +## 5. Pour aller plus loin +- Explore les guides du site [kubernetes.io](https://kubernetes.io/) pour découvrir les ConfigMaps, les volumes persistants et l'autoscaling. +- Essaie d'installer un dashboard pour visualiser en temps réel ce qui se passe dans ton cluster. diff --git a/week_06/day_01/project_01.md b/week_06/day_01/project_01.md index 53d4bf9..332f8e1 100644 --- a/week_06/day_01/project_01.md +++ b/week_06/day_01/project_01.md @@ -1,17 +1,20 @@ -# Titre du projet -Description du projet au format texte et en 1 paragraphe max (pas plus) +# Projet : premier Dockerfile ## 1. Introduction -Introduction qui leur explique dans les grandes lignes le projet. +Tu vas créer une image Docker pour une petite application Node.js puis la lancer via Docker Compose. ## 2. Le projet -### 2.1. Première étape du projet -Ici expliquer la première étape du projet. +### 2.1. Dockerfile +Écris un `Dockerfile` qui installe Node.js, copie ton code et lance `npm start`. -### 2.2. Seconde étape du projet -Ici expliquer la seconde étape du projet. - -etc.. +### 2.2. Compose +Crée ensuite un fichier `docker-compose.yml` avec un service pour ton app et un service `db` en Postgres. +- Ajoute un volume pour persister les données de la base. +- Prévoyez un fichier `.env` pour centraliser les variables comme le port et le mot de passe de la base. ## 3. Rendu attendu -Un récapitulatif de ce que nous attendons du projet. +Une archive contenant le `Dockerfile`, le `docker-compose.yml` ainsi qu'un court README expliquant comment démarrer les conteneurs. + +### Pour aller plus loin +Teste ton image sur [Play with Docker](https://labs.play-with-docker.com/) afin de valider son fonctionnement sans installer Docker localement. + diff --git a/week_06/day_02/day_presentation.txt b/week_06/day_02/day_presentation.txt index 86f213e..1ede2c1 100644 --- a/week_06/day_02/day_presentation.txt +++ b/week_06/day_02/day_presentation.txt @@ -1 +1 @@ -Description de la deuxième journée au format texte et en un paragraphe. \ No newline at end of file +Apprendre à écrire un Dockerfile et construire des images. diff --git a/week_06/day_02/day_title.txt b/week_06/day_02/day_title.txt index c4c3ddf..84359a9 100644 --- a/week_06/day_02/day_title.txt +++ b/week_06/day_02/day_title.txt @@ -1 +1 @@ -Titre de la deuxième journée \ No newline at end of file +Dockerfile et images diff --git a/week_06/day_02/lesson_01.md b/week_06/day_02/lesson_01.md index 7acab06..ca575ed 100644 --- a/week_06/day_02/lesson_01.md +++ b/week_06/day_02/lesson_01.md @@ -1,23 +1,33 @@ -# Titre de la deuxième ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Dockerfile et images ## 1. Introduction -Une introduction sur la ressource. +Après avoir lancé quelques conteneurs, il est temps de créer tes propres images pour maîtriser l'environnement d'exécution de ton application. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Les premières commandes docker run et build ont rapidement évolué pour couvrir tous les besoins de déploiement. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 2.1. Structure d'un Dockerfile +Un Dockerfile se compose d'instructions telles que `FROM`, `RUN`, `COPY`. Chaque instruction génère une nouvelle couche dans l'image. -### 3.1. Première sous partie -blabla +### 2.2. Bonnes pratiques +Utilise une image de base officielle, évite d'installer trop de packages inutiles et pense à nettoyer les caches pour réduire la taille finale. -### 3.2. Deuxième sous partie -blabla +### 2.3. Construction de l'image +Lance la commande `docker build -t monapp .` depuis le dossier contenant le Dockerfile. Tu pourras ensuite exécuter `docker run monapp` pour tester. + +### 2.4. Multi-stage builds +Pour réduire encore la taille de l'image finale, tu peux réaliser une compilation dans une première étape puis copier uniquement les fichiers nécessaires dans une seconde étape. + +### 2.5. Le fichier `.dockerignore` +Liste dans ce fichier tous les dossiers inutiles (logs, `node_modules`, etc.) afin qu'ils ne soient pas envoyés lors du build. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Chaque ligne du Dockerfile crée une nouvelle couche immutable. +- Les images légères se déploient plus rapidement. +- Versionne ton Dockerfile avec le reste de ton code. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +Consulte la documentation officielle pour découvrir toutes les instructions disponibles et comment optimiser les couches. +Prends aussi le temps de parcourir le guide [Best practices for writing Dockerfiles](https://docs.docker.com/develop/dev-best-practices/) pour maîtriser les subtilités de la construction d'images. + diff --git a/week_06/day_02/project_01.md b/week_06/day_02/project_01.md index 53d4bf9..9e2afcc 100644 --- a/week_06/day_02/project_01.md +++ b/week_06/day_02/project_01.md @@ -1,17 +1,18 @@ -# Titre du projet -Description du projet au format texte et en 1 paragraphe max (pas plus) +# Projet : créer une image personnalisée ## 1. Introduction -Introduction qui leur explique dans les grandes lignes le projet. +Nous allons construire une image Docker capable de lancer un script Python simple. ## 2. Le projet -### 2.1. Première étape du projet -Ici expliquer la première étape du projet. +- Écris un `Dockerfile` basé sur `python:3.12`. +- Copie un petit script `app.py` qui affiche "Hello Docker". +- Construis l'image puis exécute le conteneur pour vérifier le résultat. +- Ajoute ensuite une étape de test dans un `docker-compose.yml` pour pouvoir lancer ton script et une base de données en même temps. +- Publie enfin l'image sur Docker Hub pour la partager avec tes camarades. -### 2.2. Seconde étape du projet -Ici expliquer la seconde étape du projet. +## 3. Rendu attendu +Le Dockerfile et le script doivent être versionnés et la commande utilisée pour lancer l'image doit être indiquée dans un README. -etc.. +### Pour aller plus loin +Regarde comment configurer un workflow GitHub Actions pour builder automatiquement ton image à chaque push. -## 3. Rendu attendu -Un récapitulatif de ce que nous attendons du projet. diff --git a/week_06/day_03/day_presentation.txt b/week_06/day_03/day_presentation.txt index c38e0c2..f59a477 100644 --- a/week_06/day_03/day_presentation.txt +++ b/week_06/day_03/day_presentation.txt @@ -1 +1 @@ -Description de la troisième journée au format texte et en un paragraphe. \ No newline at end of file +Démarrer, arrêter et persister des conteneurs. diff --git a/week_06/day_03/day_title.txt b/week_06/day_03/day_title.txt index 5c4a97f..7524f9c 100644 --- a/week_06/day_03/day_title.txt +++ b/week_06/day_03/day_title.txt @@ -1 +1 @@ -Titre de la troisième journée \ No newline at end of file +Gestion des conteneurs diff --git a/week_06/day_03/lesson_01.md b/week_06/day_03/lesson_01.md index 7acab06..c968516 100644 --- a/week_06/day_03/lesson_01.md +++ b/week_06/day_03/lesson_01.md @@ -1,23 +1,35 @@ -# Titre de la deuxième ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Gestion des conteneurs ## 1. Introduction -Une introduction sur la ressource. +Une fois tes images créées, il faut savoir lancer, arrêter et persister les données des conteneurs. C'est ce que nous allons voir aujourd'hui. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Au début, lancer un conteneur se faisait manuellement avec docker run. Les registres et orchestrateurs ont ensuite simplifié la distribution. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 2.1. Commandes essentielles +- `docker ps` : liste les conteneurs en cours d'exécution. +- `docker stop ` : arrête un conteneur. +- `docker rm ` : supprime un conteneur arrêté. -### 3.1. Première sous partie -blabla +### 2.2. Les volumes +Pour conserver des fichiers même après suppression d'un conteneur, on utilise les volumes Docker. Ils se créent avec `docker volume create` et se montent dans le conteneur via l'option `-v`. -### 3.2. Deuxième sous partie -blabla +### 2.3. Exposition de ports +La directive `-p 8080:80` lors d'un `docker run` permet d'exposer le port 80 du conteneur vers le port 8080 de ta machine, rendant ton service accessible depuis l'extérieur. + +### 2.4. Inspecter un conteneur +La commande `docker inspect` renvoie toutes les informations sur un conteneur : variables d'environnement, montages, réseau... C'est un outil précieux pour diagnostiquer un problème. + +### 2.5. Docker Compose pour gérer plusieurs conteneurs +Plutôt que de lancer manuellement chaque conteneur, tu peux définir l'ensemble de tes services dans un fichier `docker-compose.yml` et les démarrer avec `docker compose up`. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Un conteneur est éphémère, sauf si tu montes un volume. +- Les ports exposés autorisent l'accès aux services de l'extérieur. +- Nettoie régulièrement les conteneurs et volumes inutiles pour économiser de l'espace disque. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +Le tutoriel "Get Started" du site Docker contient un chapitre dédié à la gestion des données et des réseaux. +Découvre également l'outil [Portainer](https://www.portainer.io/) pour gérer tes conteneurs via une interface web conviviale. + diff --git a/week_06/day_03/project_01.md b/week_06/day_03/project_01.md index 53d4bf9..a6e9794 100644 --- a/week_06/day_03/project_01.md +++ b/week_06/day_03/project_01.md @@ -1,17 +1,18 @@ -# Titre du projet -Description du projet au format texte et en 1 paragraphe max (pas plus) +# Projet : persistance de données ## 1. Introduction -Introduction qui leur explique dans les grandes lignes le projet. +Nous allons créer un conteneur MySQL dont les données seront conservées sur ta machine hôte grâce aux volumes. ## 2. Le projet -### 2.1. Première étape du projet -Ici expliquer la première étape du projet. +- Lance un volume nommé `db-data`. +- Démarre un conteneur `mysql:8` en montant ce volume sur `/var/lib/mysql`. +- Connecte-toi au SGBD et crée une base de test. Redémarre le conteneur pour vérifier que la base est toujours présente. +- Expose le port 3306 et connecte-toi depuis un client local pour manipuler la base. +- Ajoute ce conteneur à un `docker-compose.yml` afin de simplifier le démarrage ultérieur. -### 2.2. Seconde étape du projet -Ici expliquer la seconde étape du projet. +## 3. Rendu attendu +Un court compte-rendu expliquant les commandes utilisées et la vérification de la persistance. -etc.. +### Pour aller plus loin +Pense à tester la solution [docker volume inspect](https://docs.docker.com/storage/volumes/#inspect-a-volume) pour voir comment sont stockées tes données. -## 3. Rendu attendu -Un récapitulatif de ce que nous attendons du projet. diff --git a/week_06/day_04/day_presentation.txt b/week_06/day_04/day_presentation.txt index f42f783..73696b0 100644 --- a/week_06/day_04/day_presentation.txt +++ b/week_06/day_04/day_presentation.txt @@ -1 +1 @@ -Description de la quatrième journée au format texte et en un paragraphe. \ No newline at end of file +Comprendre les bases de l'orchestration Kubernetes. diff --git a/week_06/day_04/day_title.txt b/week_06/day_04/day_title.txt index d9d6c65..8b6ad33 100644 --- a/week_06/day_04/day_title.txt +++ b/week_06/day_04/day_title.txt @@ -1 +1 @@ -Titre de la quatrième journée \ No newline at end of file +Introduction à Kubernetes diff --git a/week_06/day_04/lesson_01.md b/week_06/day_04/lesson_01.md index 7acab06..38a88d5 100644 --- a/week_06/day_04/lesson_01.md +++ b/week_06/day_04/lesson_01.md @@ -1,23 +1,33 @@ -# Titre de la deuxième ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Introduction à Kubernetes ## 1. Introduction -Une introduction sur la ressource. +Kubernetes est une plateforme d'orchestration de conteneurs très répandue. Elle permet de déployer et de gérer des applications à grande échelle. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Kubernetes a été open-sourcé par Google en 2014 et est vite devenu la référence pour gérer des grappes de conteneurs. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 2.1. Concepts de base +Un **pod** est l'unité minimale déployée par Kubernetes. Plusieurs pods sont regroupés dans un **deployment** qui en assure la mise à l'échelle. Un **service** expose tes pods sur le réseau. -### 3.1. Première sous partie -blabla +### 2.2. Installer Minikube +Pour tester en local, installe l'outil Minikube puis lance `minikube start`. Tu disposes ainsi d'un petit cluster Kubernetes prêt à l'emploi. -### 3.2. Deuxième sous partie -blabla +### 2.3. Premier déploiement +Crée un fichier `deployment.yaml` décrivant un pod nginx. Applique-le avec `kubectl apply -f deployment.yaml` et vérifie son état avec `kubectl get pods`. + +### 2.4. ConfigMaps et Secrets +Sépare la configuration de ton image grâce aux objets `ConfigMap` et `Secret`. Ils sont montés comme des volumes ou exportés en variables d'environnement dans tes pods. + +### 2.5. Namespaces +Organise ton cluster en plusieurs espaces logiques. Les namespaces permettent d'isoler les ressources d'une équipe ou d'un projet. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Kubernetes se base sur la description déclarative de ton infrastructure. +- Les deployments assurent le redémarrage automatique des pods. +- Les services permettent d'exposer les applications vers l'extérieur du cluster. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +La documentation de [kubernetes.io](https://kubernetes.io) contient un guide complet pour approfondir chaque objet. +Je te recommande également de suivre le tutoriel [Learn Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) pour manipuler les commandes essentielles pas à pas. + diff --git a/week_06/day_04/project_01.md b/week_06/day_04/project_01.md index 53d4bf9..2d19835 100644 --- a/week_06/day_04/project_01.md +++ b/week_06/day_04/project_01.md @@ -1,17 +1,18 @@ -# Titre du projet -Description du projet au format texte et en 1 paragraphe max (pas plus) +# Projet : déployer un service simple ## 1. Introduction -Introduction qui leur explique dans les grandes lignes le projet. +Ce projet consiste à déployer une image nginx sur ton cluster Minikube et à l'exposer via un service. ## 2. Le projet -### 2.1. Première étape du projet -Ici expliquer la première étape du projet. +- Rédige un fichier `deployment.yaml` pour lancer un pod nginx avec deux replicas. +- Crée également un `service.yaml` de type NodePort pour accéder au pod depuis ton navigateur. +- Vérifie que la page d'accueil de nginx est accessible une fois le service exposé. +- Ajoute ensuite un `ConfigMap` contenant une page d'accueil personnalisée et monte-le dans le pod. +- Teste le redéploiement pour observer la prise en compte de cette configuration. -### 2.2. Seconde étape du projet -Ici expliquer la seconde étape du projet. +## 3. Rendu attendu +Les fichiers YAML et un court texte expliquant la procédure pour accéder au service sur Minikube. -etc.. +### Pour aller plus loin +Regarde comment activer l'addon `ingress` de Minikube pour exposer ton service via un nom de domaine local. -## 3. Rendu attendu -Un récapitulatif de ce que nous attendons du projet. diff --git a/week_06/day_05/day_presentation.txt b/week_06/day_05/day_presentation.txt index c562051..9469f36 100644 --- a/week_06/day_05/day_presentation.txt +++ b/week_06/day_05/day_presentation.txt @@ -1 +1 @@ -Description de la cinquième journée au format texte et en un paragraphe. \ No newline at end of file +Mettre en ligne une application simple sur un cluster. diff --git a/week_06/day_05/day_title.txt b/week_06/day_05/day_title.txt index 8e07a0a..91fcb94 100644 --- a/week_06/day_05/day_title.txt +++ b/week_06/day_05/day_title.txt @@ -1 +1 @@ -Titre de la cinquième journée \ No newline at end of file +Déploiement sur Kubernetes diff --git a/week_06/day_05/lesson_01.md b/week_06/day_05/lesson_01.md index 7acab06..0563103 100644 --- a/week_06/day_05/lesson_01.md +++ b/week_06/day_05/lesson_01.md @@ -1,23 +1,33 @@ -# Titre de la deuxième ressource -Description de la ressource au format texte et en 1 paragraphe max (pas plus) +# Déploiement sur Kubernetes ## 1. Introduction -Une introduction sur la ressource. +Pour terminer la semaine, nous allons voir comment mettre en production une application conteneurisée sur Kubernetes. -## 2.Historique et contexte -Cette partie peut être plus ou moins longue. Elle explique l'histoire ou le contexte sur la notion que l'on veut enseigner. +## 2. Historique et contexte +Avec la croissance du cloud, orchestrer plusieurs services est devenu essentiel. Kubernetes fournit diverses stratégies de déploiement pour répondre à ces enjeux. ## 3. La ressource -Cette partie est le nerf de la ressource, elle expliquera les notions de cette ressource. +### 2.1. Manifeste complet +Combine les objets `deployment`, `service` et `ingress` pour exposer une application web. L'ingress nécessite un contrôleur, par exemple Nginx Ingress sur Minikube. -### 3.1. Première sous partie -blabla +### 2.2. Rolling update +Grâce au champ `strategy` d'un deployment, Kubernetes peut mettre à jour tes pods sans interruption de service. Teste une mise à jour d'image et observe le remplacement progressif des anciens pods. -### 3.2. Deuxième sous partie -blabla +### 2.3. Helm +Pour faciliter la réutilisation des manifestes, Helm permet de les templater et de versionner des "charts". Une piste à explorer pour tes futurs projets. + +### 2.4. Auto-scaling +En combinant `HorizontalPodAutoscaler` et `Metrics Server`, ton application peut automatiquement démarrer de nouveaux pods selon la charge CPU ou mémoire. + +### 2.5. Observabilité +Installe Prometheus et Grafana via Helm pour obtenir des tableaux de bord sur l'état de ton cluster et détecter rapidement les anomalies. ## 4. Points importants à retenir -La ressource en quelques points importants. +- Un ingress donne accès à ton application via un nom de domaine ou une URL conviviale. +- Les stratégies de déploiement évitent la coupure lors des mises à jour. +- Helm simplifie la maintenance de configurations complexes. ## 5. Pour aller plus loin -Quelques éléments en ligne pour aller plus loin +Essaie de déployer l'exemple [guestbook](https://kubernetes.io/docs/tutorials/stateless-application/guestbook/) proposé par la documentation officielle pour voir un cas concret plus complet. +Pour les passionnés, la série "Production Kubernetes" de Learnk8s approfondit la mise en place de clusters robustes et sécurisés. + diff --git a/week_06/day_05/project_01.md b/week_06/day_05/project_01.md index 53d4bf9..919c3a5 100644 --- a/week_06/day_05/project_01.md +++ b/week_06/day_05/project_01.md @@ -1,17 +1,18 @@ -# Titre du projet -Description du projet au format texte et en 1 paragraphe max (pas plus) +# Projet : mise en production ## 1. Introduction -Introduction qui leur explique dans les grandes lignes le projet. +Pour clôturer cette semaine, tu vas déployer l'application Node.js créée au jour 1 sur ton cluster Kubernetes en utilisant un ingress. ## 2. Le projet -### 2.1. Première étape du projet -Ici expliquer la première étape du projet. +- Package ton application dans une image Docker et pousse-la sur Docker Hub. +- Écris les manifestes Kubernetes nécessaires (deployment, service, ingress). +- Assure-toi que l'URL fournie par Minikube affiche bien la page de ton application. +- Active l'auto-scaling avec un `HorizontalPodAutoscaler` réglé sur 50% d'utilisation CPU. +- Ajoute un dashboard Grafana pour vérifier l'état du cluster après déploiement. -### 2.2. Seconde étape du projet -Ici expliquer la seconde étape du projet. +## 3. Rendu attendu +Le dépôt doit contenir tous les manifestes ainsi qu'un script ou un README détaillant les commandes à exécuter pour le déploiement. -etc.. +### Pour aller plus loin +Configure un pipeline GitHub Actions afin de builder et déployer automatiquement ton application sur ton cluster de test. -## 3. Rendu attendu -Un récapitulatif de ce que nous attendons du projet. diff --git a/week_06/week_presentation.txt b/week_06/week_presentation.txt index 8dfd3d1..cf3d982 100644 --- a/week_06/week_presentation.txt +++ b/week_06/week_presentation.txt @@ -1 +1 @@ -Description de la première semaine au format txt et en un paragraphe max. \ No newline at end of file +Cette semaine est consacrée à Docker et Kubernetes. Tu apprendras à créer des images, gérer des conteneurs et déployer une application sur un petit cluster. diff --git a/week_06/week_title.txt b/week_06/week_title.txt index 055fa3f..95cde9c 100644 --- a/week_06/week_title.txt +++ b/week_06/week_title.txt @@ -1 +1 @@ -Titre de la première semaine \ No newline at end of file +Découverte Docker et Kubernetes diff --git a/week_07/day_01/day_presentation.txt b/week_07/day_01/day_presentation.txt new file mode 100644 index 0000000..5a49dd4 --- /dev/null +++ b/week_07/day_01/day_presentation.txt @@ -0,0 +1 @@ +Installation de l'outil et création de ta première ressource. diff --git a/week_07/day_01/day_title.txt b/week_07/day_01/day_title.txt new file mode 100644 index 0000000..c75b561 --- /dev/null +++ b/week_07/day_01/day_title.txt @@ -0,0 +1 @@ +Premiers pas avec Terraform diff --git a/week_07/day_01/lesson_01.md b/week_07/day_01/lesson_01.md new file mode 100644 index 0000000..c27edd2 --- /dev/null +++ b/week_07/day_01/lesson_01.md @@ -0,0 +1,100 @@ +# Premiers pas avec Terraform + +## 1. Introduction +Terraform est un outil d'Infrastructure as Code. Tu vas découvrir comment il te +permet de décrire tes ressources cloud de manière déclarative. + +## 2. Historique et contexte +HashiCorp a lancé Terraform en 2014 pour décrire l'infrastructure dans du code. Il est aujourd'hui un pilier de l'IaC. + +## 3. La ressource +### 2.1. Installation +Commence par installer Terraform depuis le site officiel puis initialise un +nouveau dossier avec `terraform init`. + +### 2.2. Premier provider +Crée un fichier `main.tf` et déclare un provider comme `aws` ou `google` selon +ta préférence. Ajoute-y une ressource simple comme une instance ou un bucket. + +### 2.3. Plan et apply +Utilise `terraform plan` pour voir les changements puis `terraform apply` +pour les appliquer. Observe que Terraform conserve un fichier d'état pour suivre +ce qui a été créé. + +## 4. Points importants à retenir +- Terraform fonctionne en mode déclaratif. +- Le plan permet de vérifier les actions avant exécution. +- L'état local enregistre la configuration actuelle de ton infrastructure. + +### 2.4. Format HCL +Les fichiers Terraform sont écrits en HCL. La syntaxe est proche du JSON mais plus lisible. Chaque bloc commence par un type et un nom : + +```hcl +resource "aws_instance" "example" { + ami = "ami-123456" + instance_type = "t3.micro" +} +``` + +### 2.5. Initialiser un projet +Après avoir rédigé tes premiers fichiers, exécute `terraform init` pour récupérer les plugins nécessaires. Tu pourras ensuite lancer `terraform plan` pour vérifier la configuration. + +### 2.6. Modules +Regroupe les ressources communes dans des modules pour réutiliser facilement ton code. Un module se compose d'un ensemble de fichiers Terraform appelés depuis ta configuration principale. + +### 2.7. Backends distants +Pour travailler à plusieurs, stocke l'état dans un backend partagé comme Amazon S3 ou Terraform Cloud. Active le verrouillage pour éviter les modifications concurrentes. + +## 5. Pour aller plus loin +- Parcours la [documentation Terraform](https://developer.hashicorp.com/terraform/docs) pour explorer toutes les commandes. +- Le site [Terraform Registry](https://registry.terraform.io/) propose de nombreux modules prêts à l'emploi. + + +## 6. Exercice guidé +Pour bien comprendre, réalise un mini projet : +1. Crée un dossier `demo` et place-y un fichier `main.tf`. +2. Déclare le provider `local` qui permet de manipuler des fichiers sur ta machine. +3. Utilise la ressource `local_file` pour créer un fichier `hello.txt` contenant le texte "Hello Terraform". +4. Lance `terraform init` puis `terraform apply` et observe le fichier généré. +5. Détruis tout avec `terraform destroy`. + +Cette manipulation simple montre le cycle complet : écriture du code, initialisation, planification, application puis destruction. + +## 7. Conclusion +Avec ces premières commandes, tu peux déjà orchestrer des ressources basiques. Dans la prochaine leçon, nous verrons comment structurer des projets plus importants et collaborer efficacement. + +## 8. Syntaxe HCL détaillée +La syntaxe HCL ressemble au JSON mais se veut plus lisible. Chaque bloc est introduit par un type et un nom : + +```hcl +resource "aws_s3_bucket" "bucket_example" { + bucket = "demo-bucket" + acl = "private" +} +``` + +Les valeurs peuvent être de types variés : chaînes, nombres, booléens, listes ou maps. Les commentaires s'écrivent avec `#` ou `//`. + +## 9. Gestion des versions +Pense à verrouiller la version de Terraform dans un fichier `.terraform-version` ou via le bloc `required_version`. + +```hcl +terraform { + required_version = ">= 1.6.0" +} +``` + +Cela garantit que tout le monde utilise une version compatible. + +## 10. Documentation +Chaque bloc ou variable peut être commenté pour faciliter la prise en main par les autres membres de l'équipe. Les commentaires bien placés évitent de mauvaises surprises lors de modifications futures. + +## 11. Ressources complémentaires +- Le guide "[Learn Terraform](https://learn.hashicorp.com/collections/terraform/aws-get-started)" présente un tutoriel pas à pas. +- Le livre *Terraform: Up & Running* détaille des exemples concrets d'architecture. + +Avec ces ressources et un peu de pratique, tu disposeras d'une base solide pour décrire n'importe quelle infrastructure sous forme de code. + +N'hésite pas à expérimenter et à versionner ton code dans Git. Terraform se prête très bien aux revues de code, ce qui facilite la collaboration. + +La suite de la journée t'apprendra à mettre en place un backend distant et à structurer ton projet en modules pour préparer la collaboration en équipe. diff --git a/week_07/day_01/lesson_02.md b/week_07/day_01/lesson_02.md new file mode 100644 index 0000000..ac93128 --- /dev/null +++ b/week_07/day_01/lesson_02.md @@ -0,0 +1,57 @@ +# Gestion de l'état et premiers modules + +## 1. Introduction +Tu maîtrises les bases de Terraform, passons maintenant à la structuration de ton code. Cette leçon t'explique comment partager des variables et organiser tes ressources en modules réutilisables. + +## 2. Historique et contexte +Au fil des versions, Terraform a introduit des mécanismes pour permettre le travail en équipe. Le stockage de l'état sur un backend distant et l'usage de modules sont devenus essentiels lorsque plusieurs personnes contribuent. + +## 3. La ressource +### 3.1. Stocker l'état à distance +Par défaut, Terraform écrit l'état dans un fichier `terraform.tfstate`. Pour éviter les conflits, configure un backend comme Amazon S3 : + +```hcl +terraform { + backend "s3" { + bucket = "mon-etat-tf" + key = "global/state.tfstate" + region = "eu-west-3" + } +} +``` + +Cette configuration se place dans un fichier `backend.tf` séparé. Une fois en place, chaque `terraform apply` mettra à jour l'état dans S3. + +### 3.2. Variables et fichiers tfvars +Centralise tes variables dans `variables.tf` : + +```hcl +variable "region" { + description = "Région AWS" + type = string + default = "eu-west-3" +} +``` + +Crée ensuite un fichier `terraform.tfvars` pour les valeurs concrètes. + +### 3.3. Découper en modules +Un module est un dossier contenant des fichiers Terraform. Appelle-le depuis ton code principal : + +```hcl +module "reseau" { + source = "./modules/network" + vpc_cidr = var.vpc_cidr +} +``` + +Chaque module possède son propre `variables.tf` et peut être versionné séparément. C'est la clé pour maintenir de gros projets. + +## 4. Points importants à retenir +- Le backend S3 ou Terraform Cloud évite de versionner l'état. +- Les fichiers `*.tfvars` contiennent les valeurs propres à chaque environnement. +- Les modules favorisent la réutilisabilité du code. + +## 5. Pour aller plus loin +- Explore le [Terraform Registry](https://registry.terraform.io/) pour importer des modules publics. +- Lis la documentation sur les [workspaces](https://developer.hashicorp.com/terraform/docs/language/state/workspaces) afin de gérer plusieurs environnements. diff --git a/week_07/day_01/project_01.md b/week_07/day_01/project_01.md new file mode 100644 index 0000000..bc26664 --- /dev/null +++ b/week_07/day_01/project_01.md @@ -0,0 +1,23 @@ +# Déployer une instance simple + +## 1. Introduction +Pour t'entraîner, tu vas décrire une machine virtuelle basique avec Terraform +et la créer dans le cloud de ton choix. + +## 2. Le projet +1. Initialise un répertoire et ajoute un provider. +2. Déclare une ressource `instance` ou équivalent avec l'image et la taille + que tu souhaites. +3. Lance `terraform apply` et récupère l'adresse IP publique. +4. Ajoute une sortie (`output`) pour afficher automatiquement cette adresse. +5. Détruis la ressource avec `terraform destroy` une fois le test terminé pour éviter des frais inutiles. + +## 3. Rendu attendu +Un dépôt contenant tes fichiers `.tf` et un petit `README` expliquant la +commande utilisée pour créer l'instance. +N'oublie pas d'indiquer la version de Terraform et du provider utilisés pour faciliter la reproduction du projet. + +### Pour aller plus loin +Teste d'autres providers (par exemple `azurerm` ou `google`) pour comparer les options disponibles. +4. Pense à détruire la ressource avec `terraform destroy` une fois le test terminé pour éviter des frais inutiles. + diff --git a/week_07/day_02/day_presentation.txt b/week_07/day_02/day_presentation.txt new file mode 100644 index 0000000..8f3b2da --- /dev/null +++ b/week_07/day_02/day_presentation.txt @@ -0,0 +1 @@ +Découvre comment paramétrer tes configurations et conserver l'état à distance. diff --git a/week_07/day_02/day_title.txt b/week_07/day_02/day_title.txt new file mode 100644 index 0000000..e1a2266 --- /dev/null +++ b/week_07/day_02/day_title.txt @@ -0,0 +1 @@ +Variables et état diff --git a/week_07/day_02/lesson_01.md b/week_07/day_02/lesson_01.md new file mode 100644 index 0000000..6a88f68 --- /dev/null +++ b/week_07/day_02/lesson_01.md @@ -0,0 +1,38 @@ +# Variables et gestion de l'état + +## 1. Introduction +Maintenant que tu sais créer une ressource, il faut apprendre à rendre ton code +réutilisable et à suivre l'infrastructure créée. + +## 2. Historique et contexte +La gestion de l'état et des variables est apparue pour suivre les ressources et partager des paramètres entre modules. + +## 3. La ressource +### 2.1. Les variables +Déclare des variables dans un fichier `variables.tf` pour éviter de dupliquer les +valeurs. Utilise les blocs `variable` et la syntaxe `${var.nom}` dans tes +ressources. + +### 2.2. L'état Terraform +Terraform stocke l'état dans un fichier `terraform.tfstate`. Tu peux le placer +à distance via un backend S3 ou GCS afin de travailler en équipe sans conflit. + +### 2.3. Outputs +Les sorties te permettent d'afficher les informations clés après l'apply. +Déclare-les dans `outputs.tf` puis consulte-les avec `terraform output`. + +## 4. Points importants à retenir +- Ne versionne jamais le fichier `tfstate`. +- Les variables rendent tes configurations dynamiques. +- Les outputs facilitent l'intégration avec d'autres outils. + +### 2.4. Fichiers de variables +Place tes valeurs dans un fichier `terraform.tfvars` et charge-le avec l'option `-var-file`. C'est pratique pour séparer les environnements (dev, prod). + +### 2.5. Verrouillage de l'état +Lorsque plusieurs personnes appliquent des changements, un verrou sur le backend évite les conflits. Assure-toi de configurer ce verrouillage si tu stockes l'état à distance. + +## 5. Pour aller plus loin +- Découvre les backends distants comme [Terraform Cloud](https://app.terraform.io/) pour partager ton état sans te soucier de l'infrastructure. +- La commande `terraform console` permet d'explorer les valeurs et de tester tes expressions avant l'apply. + diff --git a/week_07/day_02/lesson_02.md b/week_07/day_02/lesson_02.md new file mode 100644 index 0000000..c64bb3b --- /dev/null +++ b/week_07/day_02/lesson_02.md @@ -0,0 +1,65 @@ +# Boucles et conditions dans Terraform + +## 1. Introduction +Pour générer plusieurs ressources similaires ou adapter une configuration, Terraform propose les expressions `for` et les blocs `count` ou `for_each`. Voyons comment les utiliser. + +## 2. Historique et contexte +Les versions récentes de Terraform ont enrichi le langage HCL pour couvrir un maximum de scénarios sans recourir à un autre langage de programmation. + +## 3. La ressource +### 3.1. Utiliser `count` +Si tu dois déployer plusieurs instances identiques, ajoute le paramètre `count` : + +```hcl +resource "aws_instance" "web" { + count = 3 + ami = var.web_ami + instance_type = "t3.micro" +} +``` + +L'attribut `count.index` permet de différencier les ressources lors de la création de noms ou d'étiquettes. + +### 3.2. Utiliser `for_each` +Lorsque les valeurs ne sont pas simplement un nombre mais une liste ou un map, préfère `for_each` : + +```hcl +resource "aws_security_group" "example" { + for_each = var.sg_ports + name = "sg-${each.key}" + ingress { + from_port = each.value + to_port = each.value + protocol = "tcp" + cidr_blocks = ["0.0.0.0/0"] + } +} +``` + +### 3.3. Les expressions `for` +Dans un bloc `locals` ou lors de l'assignation d'une variable, tu peux transformer une liste : + +```hcl +locals { + port_strings = [for p in var.sg_ports : "port-${p}"] +} +``` + +### 3.4. Conditions +HCL permet aussi les conditions simples : + +```hcl +resource "aws_instance" "api" { + ami = var.api_ami + instance_type = var.debug ? "t3.small" : "t3.micro" +} +``` + +## 4. Points importants à retenir +- `count` et `for_each` servent à créer plusieurs ressources. +- Les expressions `for` transforment des valeurs sans recourir à un autre langage. +- Les conditions permettent d'adapter la configuration selon les variables. + +## 5. Pour aller plus loin +- Découvre les fonctions [built-in](https://developer.hashicorp.com/terraform/language/functions/) pour manipuler les chaînes et les listes. +- Combine `count` et `for_each` avec des modules pour déployer des architectures plus complexes. diff --git a/week_07/day_02/project_01.md b/week_07/day_02/project_01.md new file mode 100644 index 0000000..2eb3246 --- /dev/null +++ b/week_07/day_02/project_01.md @@ -0,0 +1,20 @@ +# Paramétrer l'instance + +## 1. Introduction +Nous allons reprendre le projet précédent pour y intégrer des variables et un +état stocké à distance. + +## 2. Le projet +1. Ajoute un fichier `variables.tf` pour définir la région et le type d'instance. +2. Configure un backend `s3` ou équivalent pour stocker le `tfstate`. +3. Affiche l'adresse IP de l'instance via un output. +4. Utilise un fichier `terraform.tfvars` pour séparer les valeurs propres à ton environnement. + +## 3. Rendu attendu +Un dépôt mis à jour contenant la configuration complète et un exemple du fichier +backend utilisé. +4. Teste le verrouillage de l'état en exécutant un `terraform plan` depuis deux terminaux différents et observe le comportement. + +### Pour aller plus loin +Ajoute un module réutilisable pour la création d'instances afin de simplifier les prochains projets. + diff --git a/week_07/day_03/day_presentation.txt b/week_07/day_03/day_presentation.txt new file mode 100644 index 0000000..b837b55 --- /dev/null +++ b/week_07/day_03/day_presentation.txt @@ -0,0 +1 @@ +Apprends à structurer ton code et réutiliser des briques communes. diff --git a/week_07/day_03/day_title.txt b/week_07/day_03/day_title.txt new file mode 100644 index 0000000..7c8c5db --- /dev/null +++ b/week_07/day_03/day_title.txt @@ -0,0 +1 @@ +Modules et organisation diff --git a/week_07/day_03/lesson_01.md b/week_07/day_03/lesson_01.md new file mode 100644 index 0000000..93b9e90 --- /dev/null +++ b/week_07/day_03/lesson_01.md @@ -0,0 +1,39 @@ +# Utiliser des modules Terraform + +## 1. Introduction +Quand les infrastructures grossissent, il est indispensable de factoriser le +code. Les modules t'aident à réutiliser des blocs communs. + +## 2. Historique et contexte +Les modules Terraform permettent de factoriser le code, une pratique encouragée depuis les premières versions de l'outil. + +## 3. La ressource +### 2.1. Créer un module +Un module est simplement un dossier contenant des fichiers `.tf`. Place-y les +ressources que tu veux rendre réutilisables, comme un réseau ou une base de +données. + +### 2.2. Appeler un module +Dans ton `main.tf`, utilise la ressource `module` pour appeler le code du +module. Tu peux passer des variables d'entrée et récupérer des outputs. + +### 2.3. Workspaces +Les workspaces permettent de garder plusieurs environnements avec le même code +(source, staging, production). Ils se gèrent avec `terraform workspace new` et +`select`. + +## 4. Points importants à retenir +- Les modules améliorent la lisibilité et la maintenance. +- Organise tes variables et outputs pour faciliter la réutilisation. +- Les workspaces sont pratiques pour séparer les environnements. + +### 2.4. Sources de modules +Les modules peuvent provenir d'un chemin local, d'une URL Git ou du Registry officiel. Versionne-les avec un tag pour garantir la reproductibilité. + +### 2.5. Composition +Rien n'empêche d'utiliser un module à l'intérieur d'un autre pour construire des architectures complexes tout en conservant une structure claire. + +## 5. Pour aller plus loin +- Parcours le [Terraform Registry](https://registry.terraform.io/) pour trouver des modules maintenus par la communauté. +- Le guide officiel "Module Development" détaille les bonnes pratiques pour écrire tes propres modules. + diff --git a/week_07/day_03/project_01.md b/week_07/day_03/project_01.md new file mode 100644 index 0000000..461764e --- /dev/null +++ b/week_07/day_03/project_01.md @@ -0,0 +1,20 @@ +# Créer ton premier module + +## 1. Introduction +Nous allons extraire la création de l'instance dans un module dédié afin de +pouvoir la réutiliser. + +## 2. Le projet +1. Déplace la ressource de l'instance dans un dossier `modules/instance`. +2. Déclare des variables pour l'image et la taille. +3. Appelle ce module depuis ton `main.tf`. +4. Publie ce module dans un dépôt séparé afin de pouvoir le versionner comme une dépendance. + +## 3. Rendu attendu +Ton dépôt doit contenir le dossier `modules/instance` et l'appel correspondant +avec un exemple de variables personnalisées. +4. Ajoute un `output` renvoyant l'adresse IP pour que le module soit vraiment complet. + +### Pour aller plus loin +Regarde comment utiliser la directive `source` d'un module pour pointer vers une version taggée sur GitHub. + diff --git a/week_07/day_04/day_presentation.txt b/week_07/day_04/day_presentation.txt new file mode 100644 index 0000000..836b08f --- /dev/null +++ b/week_07/day_04/day_presentation.txt @@ -0,0 +1 @@ +Apprends à exécuter Terraform dans une pipeline et découvre Terraform Cloud. diff --git a/week_07/day_04/day_title.txt b/week_07/day_04/day_title.txt new file mode 100644 index 0000000..4f9d7bf --- /dev/null +++ b/week_07/day_04/day_title.txt @@ -0,0 +1 @@ +Automatisation CI et Terraform Cloud diff --git a/week_07/day_04/lesson_01.md b/week_07/day_04/lesson_01.md new file mode 100644 index 0000000..3b64844 --- /dev/null +++ b/week_07/day_04/lesson_01.md @@ -0,0 +1,36 @@ +# Automatiser les plans Terraform + +## 1. Introduction +À grande échelle, on ne lance plus les commandes Terraform à la main. Les +pipelines de CI prennent le relais et Terraform Cloud peut gérer l'état et les +workspaces pour toi. + +## 2. Historique et contexte +L'automatisation des plans s'est développée avec l'intégration de Terraform dans les chaînes CI/CD. + +## 3. La ressource +### 2.1. Utiliser un pipeline +Crée un job dans ton outil préféré (GitHub Actions, GitLab CI...) pour exécuter +`terraform fmt`, `terraform plan` puis `terraform apply` après validation. + +### 2.2. Terraform Cloud +Terraform Cloud héberge ton état et propose des workspaces distants. Tu peux +aussi y stocker tes variables sensibles et lancer les plans depuis l'interface +web ou l'API. + +### 2.3. Policy as Code +Avec Sentinel ou d'autres outils, tu peux définir des règles qui empêchent un +apply si certaines conditions ne sont pas remplies. + +## 4. Points importants à retenir +- Automatise tes plans pour éviter les erreurs manuelles. +- Stocke l'état de manière sécurisée. +- Les politiques de validation renforcent la qualité de ton infrastructure. + +### 2.4. Gestion des accès +Pense à limiter les droits sur l'état et les variables en utilisant des rôles dédiés. Un accès trop large peut entraîner des modifications non contrôlées. + +## 5. Pour aller plus loin +- Le guide [CLI-driven workflow](https://developer.hashicorp.com/terraform/cloud-docs/cli-driven-workflows/overview) détaille l'utilisation de Terraform Cloud avec la ligne de commande. +- Explore l'outil `tflint` pour analyser la qualité de tes configurations avant le plan. + diff --git a/week_07/day_04/project_01.md b/week_07/day_04/project_01.md new file mode 100644 index 0000000..4fc25bb --- /dev/null +++ b/week_07/day_04/project_01.md @@ -0,0 +1,19 @@ +# Pipeline Terraform + +## 1. Introduction +Mettons en place une automatisation basique pour valider et appliquer ton code. + +## 2. Le projet +1. Crée un fichier de pipeline (GitHub Actions ou autre) exécutant `terraform fmt`. +2. Ajoute une étape de `terraform plan`. +3. Ajoute enfin un `terraform apply` conditionné à une validation manuelle. +4. Stocke les variables sensibles dans le gestionnaire de secrets de ta plateforme CI. + +## 3. Rendu attendu +Ton dépôt doit contenir le fichier de pipeline et la configuration nécessaire +pour lancer automatiquement les plans. +4. Utilise un backend à distance afin de partager l'état entre tes exécutions de pipeline. + +### Pour aller plus loin +Intègre un outil de lint comme `tflint` dans ton pipeline pour détecter les erreurs avant l'exécution du plan. + diff --git a/week_07/day_05/day_presentation.txt b/week_07/day_05/day_presentation.txt new file mode 100644 index 0000000..9dd47a2 --- /dev/null +++ b/week_07/day_05/day_presentation.txt @@ -0,0 +1 @@ +Réalise un mini-projet mêlant modules, variables et automatisation. diff --git a/week_07/day_05/day_title.txt b/week_07/day_05/day_title.txt new file mode 100644 index 0000000..99ad123 --- /dev/null +++ b/week_07/day_05/day_title.txt @@ -0,0 +1 @@ +Atelier d'infrastructure complète diff --git a/week_07/day_05/lesson_01.md b/week_07/day_05/lesson_01.md new file mode 100644 index 0000000..553c842 --- /dev/null +++ b/week_07/day_05/lesson_01.md @@ -0,0 +1,34 @@ +# Synthèse Terraform + +## 1. Introduction +Pour terminer la semaine, tu vas revoir l'ensemble des fonctionnalités et +assembler une infrastructure plus complète à l'aide des modules créés. + +## 2. Historique et contexte +Terraform a beaucoup évolué au fil des ans, cette journée fait la synthèse de ces pratiques courantes. + +## 3. La ressource +### 2.1. Architecture exemple +Construis une petite architecture contenant un réseau, une instance et un bucket +pour stocker des fichiers. Chaque composant doit être déclaré via un module. + +### 2.2. Variables globales +Centralise les variables communes comme la région ou les tags pour éviter les +répétitions. Utilise un fichier `terraform.tfvars` pour stocker des valeurs. + +### 2.3. Validation automatique +Profite du pipeline mis en place pour lancer `terraform plan` à chaque commit et +ne permettre l'apply qu'après revue de code. + +## 4. Points importants à retenir +- Combine modules et variables pour écrire du code clair. +- Versionne tes modules dans des dépôts dédiés si nécessaire. +- Une automatisation basique suffit souvent à sécuriser tes changements. + +### 2.4. Documentation +N'oublie pas de rédiger un `README` pour expliquer comment initialiser et déployer l'infrastructure. C'est précieux quand ton projet grandira. + +## 5. Pour aller plus loin +- Teste la génération automatique de documentation avec l'outil `terraform-docs`. +- Explore les modules officiels pour t'inspirer de leur organisation. + diff --git a/week_07/day_05/project_01.md b/week_07/day_05/project_01.md new file mode 100644 index 0000000..29e9b17 --- /dev/null +++ b/week_07/day_05/project_01.md @@ -0,0 +1,20 @@ +# Projet de fin de semaine + +## 1. Introduction +Mets en pratique tout ce que tu as vu pour déployer une architecture simple mais +réaliste. + +## 2. Le projet +1. Utilise tes modules pour créer un réseau, une instance et un stockage. +2. Paramètre l'ensemble via des variables et un fichier `tfvars`. +3. Active le pipeline CI pour exécuter `plan` et `apply` automatiquement. +4. Ajoute un module réseau distinct pour gérer les sous-réseaux et les règles de pare-feu. + +## 3. Rendu attendu +Un dépôt complet prêt à être utilisé pour reproduire l'infrastructure en une +commande. +4. Documente dans un README comment détruire proprement l'infrastructure avec `terraform destroy`. + +### Pour aller plus loin +Expérimente la mise en place d'un backend distant pour partager l'état de ce projet avec d'autres personnes. + diff --git a/week_07/week_presentation.txt b/week_07/week_presentation.txt new file mode 100644 index 0000000..3970ff6 --- /dev/null +++ b/week_07/week_presentation.txt @@ -0,0 +1,3 @@ +Cette semaine, tu vas apprendre à décrire ton infrastructure avec Terraform. +Jour après jour tu manipuleras les commandes de base, les variables et les modules +pour obtenir des déploiements reproductibles et faciles à maintenir. diff --git a/week_07/week_title.txt b/week_07/week_title.txt new file mode 100644 index 0000000..8f3b973 --- /dev/null +++ b/week_07/week_title.txt @@ -0,0 +1 @@ +Infrastructure as Code avec Terraform diff --git a/week_08/day_01/day_presentation.txt b/week_08/day_01/day_presentation.txt new file mode 100644 index 0000000..dd11bcf --- /dev/null +++ b/week_08/day_01/day_presentation.txt @@ -0,0 +1,2 @@ +Découvre les notions de métriques, de logs et de traces pour mieux comprendre ce +qui se passe dans tes applications. diff --git a/week_08/day_01/day_title.txt b/week_08/day_01/day_title.txt new file mode 100644 index 0000000..2743eb3 --- /dev/null +++ b/week_08/day_01/day_title.txt @@ -0,0 +1 @@ +Principes de la supervision diff --git a/week_08/day_01/lesson_01.md b/week_08/day_01/lesson_01.md new file mode 100644 index 0000000..c9c31bd --- /dev/null +++ b/week_08/day_01/lesson_01.md @@ -0,0 +1,34 @@ +# Comprendre l'observabilité + +## 1. Introduction +Surveiller une application ne se limite pas à afficher quelques logs. +L'observabilité regroupe la collecte de métriques, de traces et d'évènements +pour diagnostiquer rapidement les problèmes. + +## 2. Historique et contexte +L'observabilité regroupe logs, métriques et traces, un concept appliqué aux systèmes distribués depuis les années 2000. + +## 3. La ressource +### 2.1. Métriques +Les métriques sont des valeurs chiffrées mesurées dans le temps : utilisation CPU +ou nombre de requêtes par exemple. Elles permettent de suivre les tendances. + +### 2.2. Logs +Les logs enregistrent des évènements textuels. Ils sont utiles pour comprendre le +contexte exact d'une erreur ou d'une action utilisateur. + +### 2.3. Traces +Les traces suivent l'exécution d'une requête à travers plusieurs services. C'est +indispensable pour les architectures micro‑services. + +### 2.4. Outils populaires +Parmi les solutions open source les plus utilisées, on trouve Prometheus pour les métriques et Grafana pour la visualisation. Jaeger ou Zipkin sont quant à eux spécialisés dans les traces. + +## 4. Points importants à retenir +- Combine métriques et logs pour avoir une vision complète. +- Les traces facilitent la recherche des goulots d'étranglement. +- Une bonne observabilité accélère la résolution des incidents. + +## 5. Pour aller plus loin +- Le livre [Distributed Systems Observability](https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/) propose une vue d'ensemble très complète. +- Teste les [Playground Prometheus](https://prometheus.io/docs/prometheus/latest/getting_started/) pour découvrir rapidement l'outil. diff --git a/week_08/day_01/project_01.md b/week_08/day_01/project_01.md new file mode 100644 index 0000000..9f673b4 --- /dev/null +++ b/week_08/day_01/project_01.md @@ -0,0 +1,19 @@ +# Collecte de premières métriques + +## 1. Introduction +Avant de mettre en place des outils complexes, commence par récupérer quelques +informations système. + +## 2. Le projet +1. Installe un petit exporter comme `node_exporter` ou écris un script qui envoie + l'utilisation CPU dans un fichier. +2. Stocke ces valeurs régulièrement puis affiche-les sous forme de graphique + simple (par exemple via `gnuplot`). + +## 3. Rendu attendu +Un dossier contenant ton script ou l'outil utilisé et le graphique généré à +partir des données collectées. +4. Partage ton travail sur GitHub avec un bref mode d'emploi. + +### Pour aller plus loin +Teste l'installation d'un serveur Prometheus local pour stocker tes métriques de manière durable. diff --git a/week_08/day_02/day_presentation.txt b/week_08/day_02/day_presentation.txt new file mode 100644 index 0000000..adf7f16 --- /dev/null +++ b/week_08/day_02/day_presentation.txt @@ -0,0 +1 @@ +Mets en place Prometheus pour collecter automatiquement les métriques de tes services. diff --git a/week_08/day_02/day_title.txt b/week_08/day_02/day_title.txt new file mode 100644 index 0000000..53c79f8 --- /dev/null +++ b/week_08/day_02/day_title.txt @@ -0,0 +1 @@ +Installer Prometheus diff --git a/week_08/day_02/lesson_01.md b/week_08/day_02/lesson_01.md new file mode 100644 index 0000000..f4424c4 --- /dev/null +++ b/week_08/day_02/lesson_01.md @@ -0,0 +1,36 @@ +# Déployer Prometheus + +## 1. Introduction +Prometheus est un serveur de collecte de métriques très populaire. Il interroge +régulièrement des cibles pour stocker leurs mesures dans une base temporelle. + +## 2. Historique et contexte +Prometheus est né chez SoundCloud en 2012 et s'est imposé comme référence pour la collecte de métriques. + +## 3. La ressource +### 2.1. Installation rapide +Le plus simple est d'utiliser Docker : `docker run -p 9090:9090 prom/prometheus`. +Crée un fichier `prometheus.yml` pour déclarer les cibles à scrapper. + +### 2.2. Exporters +Chaque service expose ses métriques via un exporter spécifique. Le `node_exporter` +permet de surveiller l'OS. Beaucoup d'applications possèdent leur propre exporter. + +### 2.3. Interroger Prometheus +L'interface web propose une barre de recherche avec le langage PromQL. Essaie par +exemple `up` ou `process_cpu_seconds_total` pour voir tes premières valeurs. + +### 2.4. Alertmanager +Connecté à Prometheus, Alertmanager envoie des notifications (mail, Slack...) lorsqu'une règle est déclenchée. + +### 2.5. Dashboards +Associe Prometheus à Grafana pour créer des graphiques percutants et suivre l'évolution de tes métriques dans le temps. + +## 4. Points importants à retenir +- Prometheus collecte en mode pull via la configuration du scrape. +- Les exporters convertissent les métriques dans un format compatible. +- PromQL offre une grande puissance pour créer des alertes et des dashboards. + +## 5. Pour aller plus loin +- Parcours le [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) si tu utilises Kubernetes. +- Le site [Awesome Prometheus](https://github.com/prometheus/awesome-prometheus) liste de nombreux exporters et outils complémentaires. diff --git a/week_08/day_02/project_01.md b/week_08/day_02/project_01.md new file mode 100644 index 0000000..b3e31ab --- /dev/null +++ b/week_08/day_02/project_01.md @@ -0,0 +1,19 @@ +# Mettre en route Prometheus + +## 1. Introduction +Tu vas installer Prometheus en local et configurer un premier scrape d'exporter. + +## 2. Le projet +1. Lance Prometheus via Docker en montant un fichier `prometheus.yml`. +2. Installe également `node_exporter` et ajoute-le à la configuration. +3. Vérifie depuis l'UI que les métriques remontent correctement. +4. Configure une règle d'alerte simple via Alertmanager. + +## 3. Rendu attendu +Les fichiers de configuration et un court `README` expliquant comment lancer +Prometheus et accéder à l'interface. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. + +### Pour aller plus loin +Connecte Grafana à ton instance Prometheus et réalise un premier dashboard. diff --git a/week_08/day_03/day_presentation.txt b/week_08/day_03/day_presentation.txt new file mode 100644 index 0000000..a3d0252 --- /dev/null +++ b/week_08/day_03/day_presentation.txt @@ -0,0 +1 @@ +Crée tes premiers tableaux de bord à partir des données collectées dans Prometheus. diff --git a/week_08/day_03/day_title.txt b/week_08/day_03/day_title.txt new file mode 100644 index 0000000..483e20a --- /dev/null +++ b/week_08/day_03/day_title.txt @@ -0,0 +1 @@ +Visualiser avec Grafana diff --git a/week_08/day_03/lesson_01.md b/week_08/day_03/lesson_01.md new file mode 100644 index 0000000..2750930 --- /dev/null +++ b/week_08/day_03/lesson_01.md @@ -0,0 +1,36 @@ +# Dashboards Grafana + +## 1. Introduction +Grafana est l'outil incontournable pour visualiser des métriques. Il se connecte +à Prometheus et permet de créer des graphes interactifs en quelques clics. + +## 2. Historique et contexte +Grafana, créé en 2014, fournit des tableaux de bord attractifs pour visualiser ces données. + +## 3. La ressource +### 2.1. Installation +Tu peux lancer Grafana avec Docker : `docker run -p 3000:3000 grafana/grafana`. +Connecte-toi ensuite sur `localhost:3000` avec les identifiants par défaut +`admin/admin`. + +### 2.2. Ajouter une source de données +Depuis l'interface, ajoute Prometheus comme source. Indique l'URL de ton serveur +et sauvegarde. + +### 2.3. Créer un tableau de bord +Crée un nouveau dashboard puis ajoute un panneau en utilisant une requête PromQL. +Teste différents types de graphiques pour représenter les valeurs. + +### 2.4. Importer un dashboard +La communauté partage de nombreux modèles sur [grafana.com/dashboards](https://grafana.com/grafana/dashboards). Tu peux les importer pour gagner du temps. + +### 2.5. Alertes intégrées +Grafana permet désormais de définir des règles d'alerte directement depuis un panneau. Configure un canal Slack ou email pour être notifié. + +## 4. Points importants à retenir +- Grafana peut se connecter à de nombreuses bases de données. +- L'édition des panels se fait en quelques clics. +- N'hésite pas à partager tes dashboards avec ton équipe. + +### Pour aller plus loin +Consulte la documentation officielle pour approfondir. Explore également les plugins pour ajouter de nouveaux types de graphiques. diff --git a/week_08/day_03/project_01.md b/week_08/day_03/project_01.md new file mode 100644 index 0000000..7a20fce --- /dev/null +++ b/week_08/day_03/project_01.md @@ -0,0 +1,18 @@ +# Premier dashboard + +## 1. Introduction +Tu vas connecter Grafana à Prometheus et réaliser un tableau de bord montrant +l'utilisation CPU de ta machine. + +## 2. Le projet +1. Lance Grafana en local et configure Prometheus comme source. +2. Crée un dashboard avec au moins un graphique présentant la métrique `node_load1` provenant de `node_exporter`. +3. Sauvegarde ce dashboard et exporte sa configuration au format JSON. +4. Ajoute une alerte pour être averti si la charge CPU dépasse 80%. + +## 3. Rendu attendu +Un dossier contenant le fichier JSON du dashboard et les instructions pour le charger dans Grafana. +4. Partage ton travail sur GitHub avec un bref mode d'emploi. + +### Pour aller plus loin +Explore la galerie officielle de dashboards pour comparer ton travail et t'inspirer des meilleures pratiques. diff --git a/week_08/day_04/day_presentation.txt b/week_08/day_04/day_presentation.txt new file mode 100644 index 0000000..a68760c --- /dev/null +++ b/week_08/day_04/day_presentation.txt @@ -0,0 +1 @@ +Mets en place la suite Elasticsearch, Logstash et Kibana pour regrouper tes logs. diff --git a/week_08/day_04/day_title.txt b/week_08/day_04/day_title.txt new file mode 100644 index 0000000..ba5a13f --- /dev/null +++ b/week_08/day_04/day_title.txt @@ -0,0 +1 @@ +Centraliser les logs avec ELK diff --git a/week_08/day_04/lesson_01.md b/week_08/day_04/lesson_01.md new file mode 100644 index 0000000..ffac8b2 --- /dev/null +++ b/week_08/day_04/lesson_01.md @@ -0,0 +1,32 @@ +# La stack ELK + +## 1. Introduction +Pour centraliser les logs provenant de plusieurs services, on utilise souvent la +stack ELK composée d'Elasticsearch, Logstash et Kibana. + +## 2. Historique et contexte +La stack ELK a popularisé l'analyse de logs à grande échelle dans les années 2010. + +## 3. La ressource +### 2.1. Elasticsearch +C'est la base de données dans laquelle seront stockés les logs. Elle offre des +capacités de recherche très rapides. + +### 2.2. Logstash +Logstash collecte et transforme les messages avant de les envoyer vers +Elasticsearch. On définit des pipelines pour parser les différents formats. + +### 2.3. Kibana +Kibana permet de consulter et de visualiser les logs via une interface web. +Il propose aussi la création d'alertes sur certains patterns. + +### 2.4. Beats +Les Beats sont de petits agents qui expédient directement les logs ou métriques vers Logstash ou Elasticsearch. Filebeat est le plus connu pour suivre les fichiers de log locaux. + +## 4. Points importants à retenir +- ELK est une solution complète pour le logging centralisé. +- Veille à contrôler le volume de données stockées. +- Les filtres Logstash facilitent l'analyse des formats complexes. + +### Pour aller plus loin +Consulte la documentation officielle pour approfondir. Teste aussi le projet [`elastic/logstash`](https://github.com/elastic/logstash) pour découvrir des configurations avancées. diff --git a/week_08/day_04/project_01.md b/week_08/day_04/project_01.md new file mode 100644 index 0000000..2e0a7f8 --- /dev/null +++ b/week_08/day_04/project_01.md @@ -0,0 +1,19 @@ +# Centraliser les logs + +## 1. Introduction +Tu vas déployer rapidement une stack ELK et y envoyer les logs de ton système. + +## 2. Le projet +1. Utilise Docker Compose pour lancer Elasticsearch, Logstash et Kibana. +2. Configure Logstash pour lire un fichier de logs système (par exemple `/var/log/syslog`). +3. Vérifie dans Kibana que les messages apparaissent et crée un premier tableau de bord. +4. Ajoute Filebeat sur ta machine pour envoyer de nouveaux fichiers de log dans la stack. + +## 3. Rendu attendu +Un `docker-compose.yml` fonctionnel et quelques captures d'écran de Kibana +montrant les logs importés. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. + +### Pour aller plus loin +Teste la création d'une alerte Kibana pour être notifié lorsqu'un mot clé spécifique apparaît dans les logs. diff --git a/week_08/day_05/day_presentation.txt b/week_08/day_05/day_presentation.txt new file mode 100644 index 0000000..696cee7 --- /dev/null +++ b/week_08/day_05/day_presentation.txt @@ -0,0 +1 @@ +Apprends à recevoir des alertes et à réagir efficacement lorsqu'un problème est détecté. diff --git a/week_08/day_05/day_title.txt b/week_08/day_05/day_title.txt new file mode 100644 index 0000000..829afcc --- /dev/null +++ b/week_08/day_05/day_title.txt @@ -0,0 +1 @@ +Alerting et gestion des incidents diff --git a/week_08/day_05/lesson_01.md b/week_08/day_05/lesson_01.md new file mode 100644 index 0000000..31b8781 --- /dev/null +++ b/week_08/day_05/lesson_01.md @@ -0,0 +1,34 @@ +# Mettre en place l'alerting + +## 1. Introduction +Une fois les métriques et les logs collectés, il est temps d'être prévenu en cas +de comportement anormal. Pour cela nous allons utiliser Alertmanager ou les +fonctionnalités d'alerte de Grafana. + +## 2. Historique et contexte +L'alerting s'est imposé pour détecter rapidement les problèmes. Alertmanager est aujourd'hui un outil clé de cet écosystème. + +## 3. La ressource +### 2.1. Alertmanager +Couplé à Prometheus, Alertmanager gère l'envoi des notifications par mail ou via +Slack. On définit des règles dans un fichier YAML puis on lie le tout à +Prometheus. + +### 2.2. Alertes Grafana +Grafana propose également un système d'alertes intégré aux dashboards. C'est +pratique pour notifier l'équipe directement depuis l'outil de visualisation. + +### 2.3. Webhooks personnalisés +Si aucun connecteur n'existe pour ton outil de messagerie interne, tu peux envoyer les alertes vers une URL de webhook et traiter la notification toi-même. + +### 2.3. Réponse aux incidents +Définis une procédure simple : qui reçoit l'alerte, comment escalader et où +noter l'incident résolu. Cela évite bien des confusions lors d'une panne. + +## 4. Points importants à retenir +- Teste régulièrement tes règles d'alerte. +- Les notifications doivent être claires et actionnables. +- Une bonne gestion des incidents améliore la fiabilité du service. + +### Pour aller plus loin +Consulte la documentation officielle pour approfondir. Jette aussi un œil à l'outil [`amtool`](https://github.com/prometheus/alertmanager/blob/main/doc/alertmanager.md#amtool) pour tester et gérer Alertmanager en ligne de commande. diff --git a/week_08/day_05/project_01.md b/week_08/day_05/project_01.md new file mode 100644 index 0000000..babeafb --- /dev/null +++ b/week_08/day_05/project_01.md @@ -0,0 +1,19 @@ +# Simuler une alerte + +## 1. Introduction +Pour clore la semaine, tu vas déclencher une alerte volontairement et vérifier +que la notification est bien reçue. + +## 2. Le projet +1. Configure une règle Prometheus ou Grafana pour surveiller le taux d'usage CPU. +2. Provoque une charge artificielle afin de dépasser le seuil configuré. +3. Assure-toi de recevoir l'alerte et note les actions prises pour la résoudre. +4. Documente la procédure d'escalade pour qu'un autre membre de l'équipe puisse reproduire la résolution. + +## 3. Rendu attendu +Une description de la règle utilisée, la preuve de réception de l'alerte et un +petit rapport d'incident résolu. +4. Partage ton travail sur GitHub avec un bref mode d'emploi. + +### Pour aller plus loin +Teste d'autres types d'alertes, par exemple sur la quantité de mémoire consommée. diff --git a/week_08/week_presentation.txt b/week_08/week_presentation.txt new file mode 100644 index 0000000..c4c0905 --- /dev/null +++ b/week_08/week_presentation.txt @@ -0,0 +1,2 @@ +Cette semaine tu mettras en place un système complet de supervision. +Métriques, logs et alertes n'auront plus de secrets pour toi. diff --git a/week_08/week_title.txt b/week_08/week_title.txt new file mode 100644 index 0000000..18c7184 --- /dev/null +++ b/week_08/week_title.txt @@ -0,0 +1 @@ +Observabilité et monitoring diff --git a/week_09/day_01/day_presentation.txt b/week_09/day_01/day_presentation.txt new file mode 100644 index 0000000..3056f02 --- /dev/null +++ b/week_09/day_01/day_presentation.txt @@ -0,0 +1 @@ +Découvre pourquoi la sécurité doit être prise en compte dès le développement. diff --git a/week_09/day_01/day_title.txt b/week_09/day_01/day_title.txt new file mode 100644 index 0000000..e47830e --- /dev/null +++ b/week_09/day_01/day_title.txt @@ -0,0 +1 @@ +Introduction au DevSecOps diff --git a/week_09/day_01/lesson_01.md b/week_09/day_01/lesson_01.md new file mode 100644 index 0000000..9e1e71b --- /dev/null +++ b/week_09/day_01/lesson_01.md @@ -0,0 +1,32 @@ +# Les bases du DevSecOps + +## 1. Introduction +Intégrer la sécurité dans un cycle DevOps permet de détecter les failles très tôt +et d'automatiser une partie des contrôles. + +## 2. Historique et contexte +Le mouvement DevSecOps, apparu vers 2015, vise à intégrer la sécurité tout au long du cycle de développement. + +## 3. La ressource +### 3.1. Shift left +L'idée est d'amener les tests de sécurité le plus tôt possible dans le cycle de +développement afin de réduire les coûts de correction. + +### 3.2. Modélisation des menaces +Avant de coder, il est utile de réfléchir aux scénarios d'attaque possibles. +Cet exercice aide à prioriser les mesures de protection à mettre en place. + +### 3.3. Outils courants +Des solutions comme SonarQube, Trivy ou Snyk analysent ton code et tes images +de conteneurs à la recherche de vulnérabilités. + +### 3.4. Gestion des secrets +Stocke tes secrets dans un coffre-fort comme HashiCorp Vault ou les secrets GitHub plutôt que dans le code source. + +## 4. Points importants à retenir +- La sécurité fait partie intégrante du pipeline. +- Les analyses doivent être automatisées pour chaque commit. +- La sensibilisation de l'équipe reste indispensable. + +### Pour aller plus loin +Consulte la documentation officielle pour approfondir. Le guide [OWASP DevSecOps](https://owasp.org/www-project-devsecops-guideline/) est une excellente ressource. diff --git a/week_09/day_01/lesson_02.md b/week_09/day_01/lesson_02.md new file mode 100644 index 0000000..294b259 --- /dev/null +++ b/week_09/day_01/lesson_02.md @@ -0,0 +1,34 @@ +# Sécuriser les conteneurs + +## 1. Introduction +Pour compléter la découverte du DevSecOps, intéressons-nous aux conteneurs. Un conteneur vulnérable peut compromettre l'ensemble d'une infrastructure. + +## 2. Historique et contexte +Au fur et à mesure que Docker s'est imposé, les scanners de sécurité tels que Clair ou Trivy sont apparus pour analyser les images et détecter les dépendances périmées. + +## 3. La ressource +### 3.1. Utiliser un scanner +Installe Trivy et lance une analyse sur une image : + +```bash +trivy image nginx:latest +``` + +L'outil liste les CVE (vulnérabilités) connues. Mets régulièrement à jour tes images pour éviter ces failles. + +### 3.2. Les bonnes pratiques +- Privilégie des images officielles ou maintenues. +- Exécute les conteneurs avec l'utilisateur le moins privilégié possible. +- Garde le nombre de dépendances au strict minimum. + +### 3.3. Signer ses images +Pour garantir qu'une image provient de toi, utilise la signature avec Notary ou Cosign. Cette étape empêche qu'une image modifiée soit déployée par erreur. + +## 4. Points importants à retenir +- Analyse chaque image avant son déploiement. +- Mets en place un suivi des CVE pour corriger rapidement les failles. +- La signature renforce la chaîne de confiance. + +## 5. Pour aller plus loin +- Découvre les conseils du [CIS Docker Benchmark](https://docs.cisecurity.org/) pour configurer un moteur Docker sécurisé. +- Renseigne-toi sur les outils de policy comme OPA Gatekeeper pour valider les manifestes Kubernetes. diff --git a/week_09/day_01/project_01.md b/week_09/day_01/project_01.md new file mode 100644 index 0000000..fb9665b --- /dev/null +++ b/week_09/day_01/project_01.md @@ -0,0 +1,17 @@ +# Analyser un dépôt + +## 1. Introduction +Pour commencer doucement, tu vas passer un projet existant au crible des outils +d'analyse statique. + +## 2. Le projet +1. Choisis une petite application open source. +2. Lance un scan avec SonarQube ou un outil équivalent pour lister les + vulnérabilités détectées. +3. Classe les alertes par ordre de priorité et propose des pistes de correction. + +## 3. Rendu attendu +Un rapport succinct contenant les principaux problèmes trouvés et tes conseils +pour les corriger. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_09/day_02/day_presentation.txt b/week_09/day_02/day_presentation.txt new file mode 100644 index 0000000..8252f4b --- /dev/null +++ b/week_09/day_02/day_presentation.txt @@ -0,0 +1,2 @@ +Apprends à stocker et distribuer les secrets de façon sécurisée dans tes +applications et ton infrastructure. diff --git a/week_09/day_02/day_title.txt b/week_09/day_02/day_title.txt new file mode 100644 index 0000000..a0abd5d --- /dev/null +++ b/week_09/day_02/day_title.txt @@ -0,0 +1 @@ +Gestion des secrets diff --git a/week_09/day_02/lesson_01.md b/week_09/day_02/lesson_01.md new file mode 100644 index 0000000..8985745 --- /dev/null +++ b/week_09/day_02/lesson_01.md @@ -0,0 +1,57 @@ +# Protéger ses secrets + +## 1. Introduction +Les secrets (mots de passe, clés API...) doivent être stockés avec soin pour +éviter toute fuite compromettante. + +## 2. Historique et contexte +La protection des secrets existe depuis longtemps ; des outils comme Vault ont été pensés pour centraliser ces données sensibles. + +## 3. La ressource +### 3.1. Vault +HashiCorp Vault permet de centraliser les secrets et de contrôler précisément qui +y accède. Il peut également générer des identifiants temporaires. + +### 3.2. Variables d'environnement +Pour des besoins simples, les variables d'environnement restent une bonne option. +Pense à les injecter dans tes conteneurs via ton outil CI sans les commiter. + +### 3.3. Chiffrement des fichiers +Lorsque tu dois conserver un fichier de configuration sensible, chiffre-le avec +GnuPG ou age et partage la clé de déchiffrement uniquement avec les personnes +habilitées. + +### 3.4. Intégration dans la CI +Pour que les secrets restent confidentiels, définis-les au niveau de ton outil CI. +Les variables "secrètes" ne s'affichent jamais dans les logs et se transmettent +aux jobs de manière sécurisée. +### 3.5. Exemple GitHub Actions +Voici un exemple de workflow qui récupère un secret et l'utilise pour se connecter à une base de données : +```yaml +name: CI +on: [push] +jobs: + build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v3 + - run: psql ${{ secrets.DB_URL }} -c 'SELECT 1;' +``` +L'URL de la base est stockée du côté de GitHub et n'apparaît pas dans le code ni dans les logs du job. +### 3.6. Secrets Kubernetes +Si tu déploies sur Kubernetes, stocke les informations sensibles dans un objet `Secret` et monte-les sous forme de variable d'environnement ou de fichier. +```bash +kubectl create secret generic db-creds --from-literal=username=demo --from-literal=password=pass +``` +Pense à utiliser un namespace spécifique aux secrets et à restreindre les droits d'accès. +### 3.7. Bonnes pratiques supplémentaires +- Active l'audit sur l'accès aux secrets pour savoir qui les a consultés. +- Renouvelle périodiquement les clés d'accès. +- Utilise un chiffrement de disque lorsque des fichiers sensibles sont stockés localement. +## 4. Points importants à retenir +- Ne stocke jamais les secrets en clair dans le dépôt git. +- Préfère un gestionnaire dédié dès que possible. +- Renouvelle régulièrement les clés et les mots de passe. + +## 5. Pour aller plus loin +Consulte la [documentation officielle de Vault](https://developer.hashicorp.com/vault/) ou celle de ton outil CI pour approfondir. diff --git a/week_09/day_02/project_01.md b/week_09/day_02/project_01.md new file mode 100644 index 0000000..3cdd857 --- /dev/null +++ b/week_09/day_02/project_01.md @@ -0,0 +1,17 @@ +# Sécuriser une application + +## 1. Introduction +Nous allons mettre en pratique la gestion des secrets avec Vault ou une solution +équivalente. + +## 2. Le projet +1. Installe Vault en mode développement. +2. Stocke un mot de passe d'application et récupère-le via la CLI dans un script + de démarrage. +3. Assure-toi que le mot de passe n'apparaît pas dans le dépôt ni dans les logs. + +## 3. Rendu attendu +Le script d'exemple et les commandes pour lancer Vault et récupérer le secret +lors du démarrage. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_09/day_03/day_presentation.txt b/week_09/day_03/day_presentation.txt new file mode 100644 index 0000000..4a64142 --- /dev/null +++ b/week_09/day_03/day_presentation.txt @@ -0,0 +1 @@ +Découvre les bonnes pratiques pour construire des images sûres et limiter les risques d'exécution. diff --git a/week_09/day_03/day_title.txt b/week_09/day_03/day_title.txt new file mode 100644 index 0000000..ca52cea --- /dev/null +++ b/week_09/day_03/day_title.txt @@ -0,0 +1 @@ +Sécuriser les conteneurs diff --git a/week_09/day_03/lesson_01.md b/week_09/day_03/lesson_01.md new file mode 100644 index 0000000..871183c --- /dev/null +++ b/week_09/day_03/lesson_01.md @@ -0,0 +1,35 @@ +# Sécurité des conteneurs + +## 1. Introduction +Les conteneurs offrent une isolation légère mais il faut tout de même appliquer +des règles pour éviter les failles. + +## 2. Historique et contexte +Avec l'essor des conteneurs, des scanners comme Clair ou Trivy sont apparus pour contrôler les images. + +## 3. La ressource +### 3.1. Images minimalistes +Utilise des images de base petites (Alpine, Debian slim) pour réduire la surface +d'attaque et les dépendances inutiles. + +### 3.2. Droits utilisateur +Évite de lancer tes applications en tant que `root` dans le conteneur. Crée un +utilisateur dédié avec les permissions minimales nécessaires. + +### 3.3. Analyse des images +Des outils comme Trivy ou Clair scannent les images et listent les +vulnérabilités connues. Intègre ces scans à ta CI. + +### 3.4. Utiliser des conteneurs non privilégiés +La plupart des images officielles proposent une exécution sous un utilisateur spécifique. Adapte ton `Dockerfile` pour créer cet utilisateur et travaille sans privilèges élevés. +### 3.5. Signer les images +La signature numérique garantit l'authenticité de l'image. Des outils comme cosign permettent de vérifier qu'aucun tiers n'a modifié l'image poussée sur le registre. +### 3.6. Surveillance +Combine des outils comme Falco ou Sysdig pour détecter les comportements suspects en temps réel et alerter l'équipe de sécurité. +## 4. Points importants à retenir +- Les images officielles sont régulièrement mises à jour. +- Limite au maximum les privilèges accordés aux conteneurs. +- Automatise les scans pour rester informé des failles publiées. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir, et regarde les conseils de la [CIS Docker Benchmark](https://docs.cisecurity.org/) pour renforcer la configuration. diff --git a/week_09/day_03/project_01.md b/week_09/day_03/project_01.md new file mode 100644 index 0000000..d8b2766 --- /dev/null +++ b/week_09/day_03/project_01.md @@ -0,0 +1,15 @@ +# Scanner une image Docker + +## 1. Introduction +Nous allons vérifier qu'une image ne contient pas de vulnérabilités connues. + +## 2. Le projet +1. Choisis une image publique sur Docker Hub. +2. Lance un scan avec Trivy et analyse le rapport généré. +3. Corrige ou signale au moins une vulnérabilité trouvée (par exemple en mettant + à jour l'image ou un paquet). + +## 3. Rendu attendu +Le fichier de rapport et une courte note expliquant la correction appliquée. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_09/day_04/day_presentation.txt b/week_09/day_04/day_presentation.txt new file mode 100644 index 0000000..7f6d6e5 --- /dev/null +++ b/week_09/day_04/day_presentation.txt @@ -0,0 +1 @@ +Comprends comment protéger ton infrastructure et définir des règles réseau adaptées. diff --git a/week_09/day_04/day_title.txt b/week_09/day_04/day_title.txt new file mode 100644 index 0000000..92f5e9e --- /dev/null +++ b/week_09/day_04/day_title.txt @@ -0,0 +1 @@ +Sécurité réseau et infrastructure diff --git a/week_09/day_04/lesson_01.md b/week_09/day_04/lesson_01.md new file mode 100644 index 0000000..54c924f --- /dev/null +++ b/week_09/day_04/lesson_01.md @@ -0,0 +1,33 @@ +# Sécuriser l'infrastructure + +## 1. Introduction +La configuration réseau et système joue un rôle crucial pour éviter les +intrusions et limiter les dégâts en cas de compromission. + +## 2. Historique et contexte +Automatiser la sécurité de l'infrastructure est une pratique héritée des audits classiques dès le début de l'IaC. + +## 3. La ressource +### 3.1. Pare-feu et groupes de sécurité +Mets en place des règles restrictives : n'ouvre que les ports nécessaires et +seulement depuis les sources attendues. + +### 3.2. Mise à jour et correctifs +Maintiens tes serveurs à jour pour bénéficier des derniers patchs de sécurité. +Automatise ce processus si possible. + +### 3.3. Chiffrement des données +Utilise TLS/SSL pour sécuriser les communications et chiffre les disques qui +contiennent des informations sensibles. + +### 3.4. Automatisation de la conformité +Utilise des outils comme Ansible ou Terraform pour appliquer des règles de sécurité identiques sur l'ensemble de tes serveurs. Tu limites ainsi les erreurs humaines. +### 3.5. Supervision continue +Prometheus et Grafana permettent de détecter rapidement des comportements anormaux (pique d'utilisation de CPU, connexion suspecte). Il devient alors plus facile de réagir. +## 4. Points importants à retenir +- Moins de ports exposés = surface d'attaque réduite. +- Surveille régulièrement les annonces de vulnérabilités. +- Le chiffrement est indispensable pour protéger les données au repos et en transit. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_09/day_04/project_01.md b/week_09/day_04/project_01.md new file mode 100644 index 0000000..18722cf --- /dev/null +++ b/week_09/day_04/project_01.md @@ -0,0 +1,16 @@ +# Mettre en place un pare-feu + +## 1. Introduction +Tu vas configurer un pare-feu simple pour filtrer l'accès à une machine. + +## 2. Le projet +1. Utilise `ufw` ou `firewalld` pour autoriser uniquement le port SSH et celui de + ton application. +2. Teste l'accès depuis une autre machine et vérifie que les ports non autorisés + sont bien bloqués. + +## 3. Rendu attendu +Un court tutoriel décrivant la configuration appliquée et les commandes de test +utilisées. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_09/day_05/day_presentation.txt b/week_09/day_05/day_presentation.txt new file mode 100644 index 0000000..d2af691 --- /dev/null +++ b/week_09/day_05/day_presentation.txt @@ -0,0 +1 @@ +Intègre des outils de scan dans ta CI pour contrôler en continu la sécurité de ton code. diff --git a/week_09/day_05/day_title.txt b/week_09/day_05/day_title.txt new file mode 100644 index 0000000..1e95ded --- /dev/null +++ b/week_09/day_05/day_title.txt @@ -0,0 +1 @@ +Automatiser les scans de sécurité diff --git a/week_09/day_05/lesson_01.md b/week_09/day_05/lesson_01.md new file mode 100644 index 0000000..eca0e9b --- /dev/null +++ b/week_09/day_05/lesson_01.md @@ -0,0 +1,42 @@ +# Scans automatisés + +## 1. Introduction +Les analyses manuelles ne suffisent plus lorsque l'équipe grandit. Les outils de +scan s'intègrent dans la CI pour vérifier chaque modification. + +## 2. Historique et contexte +Les scans automatisés s'appuient sur des outils de sécurité traditionnels adaptés aux pipelines modernes. + +## 3. La ressource +### 3.1. SAST +Les scanners de code (SAST) inspectent les sources à la recherche de patterns +dangereux. Ils s'exécutent généralement avant la compilation. + +### 3.2. DAST +Les scanners dynamiques (DAST) testent l'application déployée comme le ferait un +attaquant externe. + +### 3.3. Intégration continue +Configure ton pipeline pour lancer ces outils à chaque push et produire un +rapport facilement consultable. + +### 3.4. Intégration dans la CI +Les outils SAST et DAST se greffent facilement à GitLab CI ou GitHub Actions. Définis des jobs spécifiques et fail le pipeline en cas de détection critique. +### 3.5. Exemple de script +```yaml +scan: + stage: test + image: docker:latest + script: + - trivy fs . > trivy.log + artifacts: + paths: + - trivy.log +``` +## 4. Points importants à retenir +- Automatise les scans pour réagir plus vite en cas de faille. +- Combine plusieurs approches pour une meilleure couverture. +- Les rapports doivent être clairs et partagés avec toute l'équipe. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_09/day_05/project_01.md b/week_09/day_05/project_01.md new file mode 100644 index 0000000..43beb34 --- /dev/null +++ b/week_09/day_05/project_01.md @@ -0,0 +1,14 @@ +# Pipeline de sécurité + +## 1. Introduction +Pour finir cette semaine, ajoute un job de scan à un pipeline CI existant. + +## 2. Le projet +1. Choisis un outil de SAST ou DAST compatible avec ton langage. +2. Crée un job dans la CI qui exécute ce scan et stocke le rapport en artefact. +3. Fails le build si une vulnérabilité critique est trouvée. + +## 3. Rendu attendu +Le fichier de pipeline modifié et un exemple de rapport généré lors d'un scan. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_09/week_presentation.txt b/week_09/week_presentation.txt new file mode 100644 index 0000000..95d71ce --- /dev/null +++ b/week_09/week_presentation.txt @@ -0,0 +1,2 @@ +Cette semaine est dédiée à la sécurité dans un contexte DevOps. +Nous verrons comment intégrer les bonnes pratiques à chaque étape de ton pipeline. diff --git a/week_09/week_title.txt b/week_09/week_title.txt new file mode 100644 index 0000000..e863e9f --- /dev/null +++ b/week_09/week_title.txt @@ -0,0 +1 @@ +Sécurité DevOps diff --git a/week_10/day_01/day_presentation.txt b/week_10/day_01/day_presentation.txt new file mode 100644 index 0000000..83bb733 --- /dev/null +++ b/week_10/day_01/day_presentation.txt @@ -0,0 +1 @@ +Découvre les options avancées des Dockerfile et la gestion des images. diff --git a/week_10/day_01/day_title.txt b/week_10/day_01/day_title.txt new file mode 100644 index 0000000..2641ed1 --- /dev/null +++ b/week_10/day_01/day_title.txt @@ -0,0 +1 @@ +Docker avancé diff --git a/week_10/day_01/lesson_01.md b/week_10/day_01/lesson_01.md new file mode 100644 index 0000000..f7820a2 --- /dev/null +++ b/week_10/day_01/lesson_01.md @@ -0,0 +1,36 @@ +# Techniques Docker avancées + +## 1. Introduction +Après avoir vu les bases de Docker, il est temps d'optimiser la création de tes +images et de gérer un registre privé. + +## 2. Historique et contexte +Les fonctionnalités avancées de Docker, telles que les multi-stage builds, ont émergé pour optimiser la taille des images. + +## 3. La ressource +### 3.1. Multi-stage builds +Les multi-stage builds permettent de réduire la taille des images en séparant les +étapes de compilation et d'exécution. + +### 3.2. Gestion du cache +Utilise intelligemment l'ordre des instructions pour profiter du cache Docker et +accélérer tes builds. + +### 3.3. Registries +Stocke tes images dans un registre privé (Harbor, GitHub Container Registry...). +Configure l'authentification pour pousser et tirer les images. + +### 3.4. Optimiser les couches +En ordonnant intelligemment les instructions, tu profites mieux du cache. +Par exemple, installe d'abord les dépendances stables, puis copie ton code. +### 3.5. Docker Buildx +L'outil `buildx` permet de générer des images multi-architectures. Idéal pour préparer une diffusion sur différents environnements, y compris ARM. +### 3.6. Registry miroir +Pour éviter de télécharger plusieurs fois les mêmes images depuis Docker Hub, monte un miroir local comme Harbor ou Sonatype Nexus. +## 4. Points importants à retenir +- Des images légères se déploient plus vite. +- Pense à nettoyer les dépendances inutiles durant le build. +- Un registre privé sécurise la diffusion de tes images. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_10/day_01/project_01.md b/week_10/day_01/project_01.md new file mode 100644 index 0000000..8cf6035 --- /dev/null +++ b/week_10/day_01/project_01.md @@ -0,0 +1,15 @@ +# Construire une image optimisée + +## 1. Introduction +Tu vas créer un Dockerfile multi-stage pour builder et exécuter une application +simple. + +## 2. Le projet +1. Prends une petite application (par exemple un serveur Node.js). +2. Écris un Dockerfile multi-stage où la première étape compile l'application. +3. Pousse l'image finale dans un registre privé ou sur Docker Hub. + +## 3. Rendu attendu +Le Dockerfile et la commande pour construire/pousser l'image. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_10/day_02/day_presentation.txt b/week_10/day_02/day_presentation.txt new file mode 100644 index 0000000..1476c55 --- /dev/null +++ b/week_10/day_02/day_presentation.txt @@ -0,0 +1 @@ +Découvre l'architecture de Kubernetes et déploie ton premier pod. diff --git a/week_10/day_02/day_title.txt b/week_10/day_02/day_title.txt new file mode 100644 index 0000000..8b6ad33 --- /dev/null +++ b/week_10/day_02/day_title.txt @@ -0,0 +1 @@ +Introduction à Kubernetes diff --git a/week_10/day_02/lesson_01.md b/week_10/day_02/lesson_01.md new file mode 100644 index 0000000..1826b0b --- /dev/null +++ b/week_10/day_02/lesson_01.md @@ -0,0 +1,28 @@ +# Premiers pas avec Kubernetes + +## 1. Introduction +Kubernetes est la plateforme de référence pour orchestrer des conteneurs en +production. Nous allons l'utiliser via Minikube pour commencer. + +## 2. Historique et contexte +Kubernetes, publié en 2014, a rapidement gagné en stabilité pour gérer des déploiements de plus en plus complexes. + +## 3. La ressource +### 3.1. Architecture +Un cluster Kubernetes est composé d'un noeud maître et de noeuds workers où sont +lancés les pods. L'API server centralise les commandes. + +### 3.2. Objet Pod +Le pod est l'unité de base contenant un ou plusieurs conteneurs partageant le +même réseau. Il est décrit dans un fichier YAML. + +### 3.3. Services +Les services exposent les pods et assurent la découverte entre eux. + +## 4. Points importants à retenir +- Kubectl est l'outil en ligne de commande principal. +- Les fichiers YAML décrivent l'état désiré du cluster. +- Minikube permet de tester Kubernetes en local facilement. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_10/day_02/project_01.md b/week_10/day_02/project_01.md new file mode 100644 index 0000000..64a325d --- /dev/null +++ b/week_10/day_02/project_01.md @@ -0,0 +1,14 @@ +# Déployer un pod simple + +## 1. Introduction +Appliquons la théorie en créant un premier pod sur Minikube. + +## 2. Le projet +1. Installe Minikube et démarre un cluster local. +2. Écris un manifeste YAML décrivant un pod avec un conteneur Nginx. +3. Lance `kubectl apply -f` sur ton fichier et vérifie que le pod est `Running`. + +## 3. Rendu attendu +Le fichier YAML et les commandes pour créer et vérifier le pod. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_10/day_03/day_presentation.txt b/week_10/day_03/day_presentation.txt new file mode 100644 index 0000000..9aafd0e --- /dev/null +++ b/week_10/day_03/day_presentation.txt @@ -0,0 +1 @@ +Apprends à mettre à jour une application sans interruption grâce aux déploiements Kubernetes. diff --git a/week_10/day_03/day_title.txt b/week_10/day_03/day_title.txt new file mode 100644 index 0000000..8d1a57b --- /dev/null +++ b/week_10/day_03/day_title.txt @@ -0,0 +1 @@ +Déploiements et mises à jour diff --git a/week_10/day_03/lesson_01.md b/week_10/day_03/lesson_01.md new file mode 100644 index 0000000..41d8682 --- /dev/null +++ b/week_10/day_03/lesson_01.md @@ -0,0 +1,29 @@ +# Déploiements Kubernetes + +## 1. Introduction +Les déploiements gèrent la mise à jour déclarative des pods. Ils garantissent +qu'un certain nombre de réplicas est toujours disponible. + +## 2. Historique et contexte +Les stratégies de déploiement comme le rolling update ou le canary ont été développées pour assurer des mises à jour sans interruption. + +## 3. La ressource +### 3.1. Créer un Deployment +Décris un objet `Deployment` avec le nombre de réplicas souhaité et le template +de pod à utiliser. + +### 3.2. Rolling update +Les mises à jour progressives remplacent les anciennes versions sans temps +d'arrêt. Tu peux ajuster le pourcentage de pods mis à jour à chaque étape. + +### 3.3. Rollback +En cas de problème, `kubectl rollout undo deployment/nom` permet de revenir à la +révision précédente. + +## 4. Points importants à retenir +- Les déploiements simplifient la gestion des versions. +- Surveille l'état du rollout pour détecter les erreurs. +- Les labels sont essentiels pour cibler les pods correctement. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_10/day_03/project_01.md b/week_10/day_03/project_01.md new file mode 100644 index 0000000..6ffe714 --- /dev/null +++ b/week_10/day_03/project_01.md @@ -0,0 +1,14 @@ +# Mettre à jour une application + +## 1. Introduction +Nous allons déployer une application puis la mettre à jour sans coupure. + +## 2. Le projet +1. Crée un `Deployment` pour exécuter une image Nginx taguée `v1` avec deux réplicas. +2. Modifie l'image pour utiliser la version `v2` et observe le déroulement du rolling update. +3. Utilise `kubectl rollout undo` pour revenir à la version précédente. + +## 3. Rendu attendu +Les manifestes YAML utilisés et une courte explication du résultat des commandes. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_10/day_04/day_presentation.txt b/week_10/day_04/day_presentation.txt new file mode 100644 index 0000000..c9f2442 --- /dev/null +++ b/week_10/day_04/day_presentation.txt @@ -0,0 +1 @@ +Découvre Helm pour gérer des packages Kubernetes réutilisables. diff --git a/week_10/day_04/day_title.txt b/week_10/day_04/day_title.txt new file mode 100644 index 0000000..e3a8282 --- /dev/null +++ b/week_10/day_04/day_title.txt @@ -0,0 +1 @@ +Helm et templates diff --git a/week_10/day_04/lesson_01.md b/week_10/day_04/lesson_01.md new file mode 100644 index 0000000..bfc36e5 --- /dev/null +++ b/week_10/day_04/lesson_01.md @@ -0,0 +1,29 @@ +# Helm pour Kubernetes + +## 1. Introduction +Helm simplifie le déploiement d'applications complexes en regroupant tous les +manifestes dans un package appelé chart. + +## 2. Historique et contexte +Helm, apparu en 2016, a apporté une couche de templating qui simplifie la distribution d'applications Kubernetes. + +## 3. La ressource +### 3.1. Installation +Installe Helm sur ta machine puis ajoute un dépôt de charts public tel que +`bitnami`. + +### 3.2. Créer un chart +La commande `helm create monchart` génère la structure d'un chart. Les fichiers +`values.yaml` permettent de personnaliser facilement les variables. + +### 3.3. Déployer un chart +Un simple `helm install` suffit à installer l'application. Tu peux ensuite +mettre à jour les valeurs avec `helm upgrade`. + +## 4. Points importants à retenir +- Helm rend la réutilisation et la mise à jour plus faciles. +- Les charts doivent rester versionnés comme n'importe quel code. +- Les valeurs par défaut se surchargent très simplement via un fichier YAML. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_10/day_04/project_01.md b/week_10/day_04/project_01.md new file mode 100644 index 0000000..de72a7a --- /dev/null +++ b/week_10/day_04/project_01.md @@ -0,0 +1,14 @@ +# Packager une application avec Helm + +## 1. Introduction +Transformons notre déploiement précédent en chart Helm pour en faciliter la gestion. + +## 2. Le projet +1. Utilise `helm create` pour générer un nouveau chart. +2. Déplace les manifestes créés lors du jour précédent dans ce chart. +3. Personnalise `values.yaml` pour rendre l'image, le nombre de réplicas et le port configurables. + +## 3. Rendu attendu +Le chart complet prêt à être installé avec `helm install`. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_10/day_05/day_presentation.txt b/week_10/day_05/day_presentation.txt new file mode 100644 index 0000000..5f348c0 --- /dev/null +++ b/week_10/day_05/day_presentation.txt @@ -0,0 +1 @@ +Automatise la construction et le déploiement de tes images avec un pipeline. diff --git a/week_10/day_05/day_title.txt b/week_10/day_05/day_title.txt new file mode 100644 index 0000000..afe83a6 --- /dev/null +++ b/week_10/day_05/day_title.txt @@ -0,0 +1 @@ +CI/CD pour conteneurs diff --git a/week_10/day_05/lesson_01.md b/week_10/day_05/lesson_01.md new file mode 100644 index 0000000..482c796 --- /dev/null +++ b/week_10/day_05/lesson_01.md @@ -0,0 +1,29 @@ +# Pipeline de déploiement + +## 1. Introduction +Pour finir cette semaine, voyons comment enchaîner la construction de l'image et +de son déploiement sur Kubernetes dans un pipeline unique. + +## 2. Historique et contexte +Automatiser l'ensemble du pipeline est devenu essentiel avec l'adoption massive des microservices et de la conteneurisation. + +## 3. La ressource +### 3.1. Build automatisé +Configure ton outil CI pour lancer `docker build` et pousser l'image dans ton +registre après chaque merge sur la branche principale. + +### 3.2. Déploiement continu +Avec `kubectl` ou Helm, déploie directement la nouvelle image sur le cluster. +Pense à versionner les manifests utilisés par la CI. + +### 3.3. Gestion des secrets +Le pipeline doit pouvoir s'authentifier au registre et au cluster sans exposer +les identifiants. Utilise des variables protégées. + +## 4. Points importants à retenir +- Un pipeline unifié réduit le temps entre le code et la production. +- Sépare bien les environnements de test et de prod. +- Surveille l'exécution pour réagir vite en cas d'échec. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_10/day_05/project_01.md b/week_10/day_05/project_01.md new file mode 100644 index 0000000..8b57997 --- /dev/null +++ b/week_10/day_05/project_01.md @@ -0,0 +1,16 @@ +# Automatiser la livraison d'une image + +## 1. Introduction +Mets en place un pipeline complet construisant l'image de l'application et la +déployant sur ton cluster. + +## 2. Le projet +1. Crée un fichier de pipeline qui build l'image puis la pousse dans ton registre. +2. Ajoute un job qui utilise `kubectl` ou Helm pour mettre à jour le déploiement + sur le cluster. +3. Teste le pipeline sur une branche de test avant de le lancer en production. + +## 3. Rendu attendu +Le fichier de pipeline et un bref retour d'expérience sur son exécution. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_10/week_presentation.txt b/week_10/week_presentation.txt new file mode 100644 index 0000000..ceecc56 --- /dev/null +++ b/week_10/week_presentation.txt @@ -0,0 +1 @@ +Nous approfondirons la containerisation avec Docker puis nous aborderons Kubernetes pour orchestrer tes services à l'échelle. diff --git a/week_10/week_title.txt b/week_10/week_title.txt new file mode 100644 index 0000000..8105668 --- /dev/null +++ b/week_10/week_title.txt @@ -0,0 +1 @@ +Containerisation avancée diff --git a/week_11/day_01/day_presentation.txt b/week_11/day_01/day_presentation.txt new file mode 100644 index 0000000..eb14431 --- /dev/null +++ b/week_11/day_01/day_presentation.txt @@ -0,0 +1 @@ +Écris des scripts Bash et Python plus poussés pour automatiser tes tâches quotidiennes. diff --git a/week_11/day_01/day_title.txt b/week_11/day_01/day_title.txt new file mode 100644 index 0000000..470a072 --- /dev/null +++ b/week_11/day_01/day_title.txt @@ -0,0 +1 @@ +Scripting avancé diff --git a/week_11/day_01/lesson_01.md b/week_11/day_01/lesson_01.md new file mode 100644 index 0000000..726e5e8 --- /dev/null +++ b/week_11/day_01/lesson_01.md @@ -0,0 +1,29 @@ +# Scripts avancés + +## 1. Introduction +Les scripts deviennent vite indispensables pour automatiser les déploiements ou +les tâches récurrentes. Aujourd'hui nous allons améliorer leur structure. + +## 2. Historique et contexte +Les scripts Shell sont utilisés depuis les débuts d'Unix pour automatiser les tâches récurrentes. + +## 3. La ressource +### 3.1. Organisation en fonctions +Découpe ton script Bash en fonctions claires, chacune réalisant une étape +spécifique. Cela facilite la maintenance et les tests. + +### 3.2. Gestion des erreurs +Utilise `set -euo pipefail` et des blocs `trap` pour capter les erreurs et +nettoyer proprement l'environnement en cas d'échec. + +### 3.3. Python pour les tâches complexes +Lorsque le shell atteint ses limites, Python permet d'écrire des scripts plus +lisibles et de profiter des bibliothèques existantes. + +## 4. Points importants à retenir +- Un script bien structuré est plus facile à faire évoluer. +- Loggue les actions importantes pour faciliter le débogage. +- Les tests unitaires existent aussi pour les scripts ! + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_11/day_01/project_01.md b/week_11/day_01/project_01.md new file mode 100644 index 0000000..d4a13c2 --- /dev/null +++ b/week_11/day_01/project_01.md @@ -0,0 +1,16 @@ +# Script de sauvegarde + +## 1. Introduction +Réalise un script qui sauvegarde automatiquement des fichiers importants et les +archive avec une date. + +## 2. Le projet +1. Le script doit accepter en paramètre la liste des dossiers à sauvegarder. +2. Les archives seront nommées avec la date et stockées dans un dossier dédié. +3. Ajoute une option pour pousser l'archive vers un stockage distant (S3 par + exemple). + +## 3. Rendu attendu +Le script documenté ainsi qu'un exemple d'utilisation. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_11/day_02/day_presentation.txt b/week_11/day_02/day_presentation.txt new file mode 100644 index 0000000..0fbeb36 --- /dev/null +++ b/week_11/day_02/day_presentation.txt @@ -0,0 +1 @@ +Découvre Ansible pour décrire et appliquer la configuration de tes serveurs. diff --git a/week_11/day_02/day_title.txt b/week_11/day_02/day_title.txt new file mode 100644 index 0000000..e5fa255 --- /dev/null +++ b/week_11/day_02/day_title.txt @@ -0,0 +1 @@ +Configuration management avec Ansible diff --git a/week_11/day_02/lesson_01.md b/week_11/day_02/lesson_01.md new file mode 100644 index 0000000..7760e17 --- /dev/null +++ b/week_11/day_02/lesson_01.md @@ -0,0 +1,29 @@ +# Ansible pour l'automatisation + +## 1. Introduction +Ansible est un outil simple et puissant pour gérer la configuration des serveurs +via des playbooks écrits en YAML. + +## 2. Historique et contexte +Ansible a vu le jour en 2012 afin de gérer la configuration des serveurs via SSH de manière déclarative. + +## 3. La ressource +### 3.1. Inventaire +L'inventaire liste les hôtes cibles. Il peut être statique (fichier) ou dynamique +(via un script ou un plug‑in cloud). + +### 3.2. Playbooks +Un playbook contient une suite de tâches à exécuter sur les hôtes. Chaque tâche +utilise un module Ansible (copy, package, service...). + +### 3.3. Idempotence +Les actions d'Ansible sont idempotentes : relancer un playbook ne change rien si +l'état est déjà atteint. + +## 4. Points importants à retenir +- Ansible s'utilise sans agent à installer sur les cibles. +- Organise tes rôles pour réutiliser ton code. +- Teste tes playbooks sur une machine de staging avant la production. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_11/day_02/project_01.md b/week_11/day_02/project_01.md new file mode 100644 index 0000000..f8bb5b8 --- /dev/null +++ b/week_11/day_02/project_01.md @@ -0,0 +1,15 @@ +# Premier playbook + +## 1. Introduction +Écrivons un playbook Ansible pour installer et configurer un serveur web simple. + +## 2. Le projet +1. Crée un inventaire contenant une machine locale ou distante. +2. Écris un playbook installant Nginx et déployant une page statique. +3. Exécute-le puis vérifie que la page est servie correctement. + +## 3. Rendu attendu +Le fichier d'inventaire, le playbook et une capture montrant la page dans le +navigateur. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_11/day_03/day_presentation.txt b/week_11/day_03/day_presentation.txt new file mode 100644 index 0000000..cc3a183 --- /dev/null +++ b/week_11/day_03/day_presentation.txt @@ -0,0 +1 @@ +Exploite les fonctionnalités avancées de ton outil CI pour optimiser les pipelines. diff --git a/week_11/day_03/day_title.txt b/week_11/day_03/day_title.txt new file mode 100644 index 0000000..e239997 --- /dev/null +++ b/week_11/day_03/day_title.txt @@ -0,0 +1 @@ +Intégration continue avancée diff --git a/week_11/day_03/lesson_01.md b/week_11/day_03/lesson_01.md new file mode 100644 index 0000000..e596f6a --- /dev/null +++ b/week_11/day_03/lesson_01.md @@ -0,0 +1,29 @@ +# Optimiser les pipelines CI + +## 1. Introduction +Les outils d'intégration continue offrent de nombreuses options pour réduire le +temps d'exécution et améliorer la fiabilité. + +## 2. Historique et contexte +L'optimisation des pipelines CI passe par des techniques éprouvées comme le cache ou la parallélisation. + +## 3. La ressource +### 3.1. Parallélisation +Lance plusieurs jobs en parallèle pour exploiter toutes les ressources et aller +plus vite, par exemple des matrices de tests. + +### 3.2. Cache et artifacts +Mets en cache les dépendances afin d'éviter de les télécharger à chaque run et +partage des artifacts entre les étapes du pipeline. + +### 3.3. Environnements éphémères +Crée automatiquement un environnement de test pour chaque branche afin de +valider les changements dans des conditions réalistes. + +## 4. Points importants à retenir +- Mesure régulièrement la durée de tes pipelines pour les améliorer. +- Les environnements temporaires facilitent les revues de code. +- Un pipeline bien pensé est un atout majeur pour la productivité. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_11/day_03/project_01.md b/week_11/day_03/project_01.md new file mode 100644 index 0000000..e5bfbab --- /dev/null +++ b/week_11/day_03/project_01.md @@ -0,0 +1,15 @@ +# Pipeline optimisé + +## 1. Introduction +Nous allons créer un pipeline de test rapide grâce à la parallélisation et au cache. + +## 2. Le projet +1. Mets en place un pipeline exécutant les tests unitaires en parallèle sur + plusieurs versions de l'interpréteur ou de l'environnement. +2. Utilise un cache pour les dépendances et sauvegarde les rapports de tests + comme artifacts. + +## 3. Rendu attendu +Le fichier de pipeline ainsi qu'un bref compte rendu sur le temps gagné. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_11/day_04/day_presentation.txt b/week_11/day_04/day_presentation.txt new file mode 100644 index 0000000..c8c040c --- /dev/null +++ b/week_11/day_04/day_presentation.txt @@ -0,0 +1 @@ +Combine les outils vus jusque-là pour créer une infrastructure reproductible de bout en bout. diff --git a/week_11/day_04/day_title.txt b/week_11/day_04/day_title.txt new file mode 100644 index 0000000..8a09a40 --- /dev/null +++ b/week_11/day_04/day_title.txt @@ -0,0 +1 @@ +Provisionnement automatisé diff --git a/week_11/day_04/lesson_01.md b/week_11/day_04/lesson_01.md new file mode 100644 index 0000000..8b3b4cf --- /dev/null +++ b/week_11/day_04/lesson_01.md @@ -0,0 +1,29 @@ +# Chaîne d'automatisation complète + +## 1. Introduction +Il est temps d'orchestrer provisioning, configuration et déploiement via un +pipeline unique. + +## 2. Historique et contexte +Assembler ces outils en une chaîne cohérente permet un cycle de livraison continu inspiré des pionniers du DevOps. + +## 3. La ressource +### 3.1. Terraform + Ansible +Utilise Terraform pour créer les ressources (VM, réseau...) puis déclenche +Ansible afin de configurer les serveurs nouvellement créés. + +### 3.2. Pipeline orchestrateur +Un outil comme Jenkins ou GitLab CI peut piloter l'enchaînement des étapes : +création de l'infra, configuration, déploiement de l'application. + +### 3.3. Tests de bout en bout +Automatise des tests après le déploiement pour vérifier que l'ensemble fonctionne +correctement avant de valider. + +## 4. Points importants à retenir +- Sépare bien les rôles : Terraform pour l'infra, Ansible pour la config. +- Les tests automatisés garantissent un résultat fiable. +- Documente chaque étape pour faciliter la maintenance. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_11/day_04/project_01.md b/week_11/day_04/project_01.md new file mode 100644 index 0000000..59b2dfe --- /dev/null +++ b/week_11/day_04/project_01.md @@ -0,0 +1,15 @@ +# Provisionner et configurer + +## 1. Introduction +Nous allons lier Terraform et Ansible pour déployer une application complète. + +## 2. Le projet +1. Écris un plan Terraform créant une instance ou un cluster simple. +2. Une fois la création terminée, lance automatiquement un playbook Ansible + installant et configurant une application web. +3. Ajoute cette chaîne dans un pipeline CI. + +## 3. Rendu attendu +Les fichiers Terraform, le playbook Ansible et le pipeline orchestrant le tout. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_11/day_05/day_presentation.txt b/week_11/day_05/day_presentation.txt new file mode 100644 index 0000000..ee9e94b --- /dev/null +++ b/week_11/day_05/day_presentation.txt @@ -0,0 +1 @@ +Découvre comment piloter des actions depuis un chat grâce aux bots et aux webhooks. diff --git a/week_11/day_05/day_title.txt b/week_11/day_05/day_title.txt new file mode 100644 index 0000000..9dadb06 --- /dev/null +++ b/week_11/day_05/day_title.txt @@ -0,0 +1 @@ +ChatOps et automatisation diff --git a/week_11/day_05/lesson_01.md b/week_11/day_05/lesson_01.md new file mode 100644 index 0000000..1abd837 --- /dev/null +++ b/week_11/day_05/lesson_01.md @@ -0,0 +1,29 @@ +# Introduction au ChatOps + +## 1. Introduction +Le ChatOps consiste à contrôler son infrastructure directement depuis un outil de +messagerie (Slack, Mattermost...). Idéal pour simplifier les actions répétitives. + +## 2. Historique et contexte +Le terme ChatOps a été popularisé par GitHub en 2013 pour décrire l'utilisation de bots dans les salons de discussion. + +## 3. La ressource +### 3.1. Bots et webhooks +La plupart des messageries permettent d'ajouter des bots qui exécutent des +commandes via des webhooks ou une API. + +### 3.2. Sécurité +Vérifie toujours l'authentification des requêtes envoyées par le bot pour éviter +les commandes malveillantes. + +### 3.3. Cas d'usage +Déployer une application, relancer un service ou afficher l'état d'un cluster sont +autant d'actions possibles via ChatOps. + +## 4. Points importants à retenir +- Les bots offrent une grande flexibilité pour automatiser sans quitter le chat. +- Limite les commandes disponibles aux opérations courantes. +- Un historique des actions est utile pour tracer les changements. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_11/day_05/project_01.md b/week_11/day_05/project_01.md new file mode 100644 index 0000000..9294ae0 --- /dev/null +++ b/week_11/day_05/project_01.md @@ -0,0 +1,16 @@ +# Créer un bot simple + +## 1. Introduction +Pour clôturer la semaine, nous allons mettre en place un bot capable de lancer un +script depuis Slack. + +## 2. Le projet +1. Choisis un framework de bot (par exemple python-slack-sdk). +2. Programme une commande `/deploy` qui exécute un script de déploiement déjà + existant. +3. Restreins l'usage de cette commande à un canal ou à un groupe d'utilisateurs. + +## 3. Rendu attendu +Le code du bot et un court guide pour l'installer dans un espace de chat. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_11/week_presentation.txt b/week_11/week_presentation.txt new file mode 100644 index 0000000..012d57b --- /dev/null +++ b/week_11/week_presentation.txt @@ -0,0 +1 @@ +Place à l'automatisation avancée ! Scripts, configuration management et pipelines complexes seront au programme. diff --git a/week_11/week_title.txt b/week_11/week_title.txt new file mode 100644 index 0000000..6db706d --- /dev/null +++ b/week_11/week_title.txt @@ -0,0 +1 @@ +Automatisation avancée diff --git a/week_12/day_01/day_presentation.txt b/week_12/day_01/day_presentation.txt new file mode 100644 index 0000000..869ff0c --- /dev/null +++ b/week_12/day_01/day_presentation.txt @@ -0,0 +1 @@ +Choisis le sujet et prépare le dépôt Git qui accueillera ton projet final. diff --git a/week_12/day_01/day_title.txt b/week_12/day_01/day_title.txt new file mode 100644 index 0000000..d47fe66 --- /dev/null +++ b/week_12/day_01/day_title.txt @@ -0,0 +1 @@ +Kick-off du projet final diff --git a/week_12/day_01/lesson_01.md b/week_12/day_01/lesson_01.md new file mode 100644 index 0000000..338e091 --- /dev/null +++ b/week_12/day_01/lesson_01.md @@ -0,0 +1,30 @@ +# Démarrage du projet final + +## 1. Introduction +Le projet final est l'occasion de regrouper toutes les compétences acquises. +Choisis un sujet qui te motive et qui te permettra d'appliquer l'ensemble du +parcours. + +## 2. Historique et contexte +Ce projet s'inspire des pratiques DevOps combinant CI/CD et infrastructure cloud apparues ces dernières années. + +## 3. La ressource +### 3.1. Choisir un périmètre +Définis clairement les objectifs : type d'application, fonctionnalités, besoins +infra. Prévois un backlog initial avec les tâches principales. + +### 3.2. Mise en place du dépôt +Crée un dépôt Git propre avec un `README` décrivant le projet, les outils choisis +et la manière de contribuer. + +### 3.3. Organisation de l'équipe +Si tu travailles en groupe, répartis les rôles : responsable infra, responsable +CI/CD, etc. + +## 4. Points importants à retenir +- Un bon démarrage facilite la suite du projet. +- Documente dès le début pour garder une trace. +- Fixe des jalons réalistes pour la semaine. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_12/day_01/project_01.md b/week_12/day_01/project_01.md new file mode 100644 index 0000000..946f1c2 --- /dev/null +++ b/week_12/day_01/project_01.md @@ -0,0 +1,15 @@ +# Préparation du dépôt + +## 1. Introduction +Nous allons initialiser le projet final et créer la base du dépôt. + +## 2. Le projet +1. Crée le dépôt Git et ajoute-y un fichier `README.md` décrivant rapidement ton + objectif. +2. Mets en place une première structure de dossiers (`infra/`, `app/`, etc.). +3. Ouvre un tableau de suivi (GitHub Projects, Trello...) pour planifier la suite. + +## 3. Rendu attendu +Le lien vers le dépôt initialisé et une capture du tableau de suivi. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_12/day_02/day_presentation.txt b/week_12/day_02/day_presentation.txt new file mode 100644 index 0000000..fd47a12 --- /dev/null +++ b/week_12/day_02/day_presentation.txt @@ -0,0 +1 @@ +Prépare l'infrastructure et la CI nécessaires au projet. diff --git a/week_12/day_02/day_title.txt b/week_12/day_02/day_title.txt new file mode 100644 index 0000000..35097bc --- /dev/null +++ b/week_12/day_02/day_title.txt @@ -0,0 +1 @@ +Mise en place de l'environnement diff --git a/week_12/day_02/lesson_01.md b/week_12/day_02/lesson_01.md new file mode 100644 index 0000000..a66e214 --- /dev/null +++ b/week_12/day_02/lesson_01.md @@ -0,0 +1,28 @@ +# Mettre en place l'environnement + +## 1. Introduction +La réussite du projet repose sur une base solide. Commence par préparer +l'infrastructure et la chaîne CI/CD. + +## 2. Historique et contexte +Les laboratoires DevOps des grands acteurs du web ont montré l'intérêt de préparer l'environnement dès le début du projet. + +## 3. La ressource +### 3.1. Infrastructure minimale +Définis les ressources nécessaires avec Terraform ou un outil équivalent +(instances, bases de données, stockage...). + +### 3.2. Pipeline CI de base +Crée un pipeline qui construit l'application et lance les tests à chaque push. + +### 3.3. Secrets et configuration +Stocke les variables sensibles dans un gestionnaire de secrets et référence-les +dans ton pipeline. + +## 4. Points importants à retenir +- Mets en place un environnement de staging pour valider les changements. +- Versionne toute la configuration dans le dépôt. +- Automatiser dès maintenant évite les surprises plus tard. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_12/day_02/project_01.md b/week_12/day_02/project_01.md new file mode 100644 index 0000000..d4ea8e1 --- /dev/null +++ b/week_12/day_02/project_01.md @@ -0,0 +1,14 @@ +# Initialisation de l'infrastructure + +## 1. Introduction +Déploie l'infrastructure minimale et mets en place la CI du projet. + +## 2. Le projet +1. Crée les premières ressources (VM ou cluster, base de données). +2. Configure un pipeline qui teste et construit l'application à chaque commit. +3. Stocke les secrets nécessaires dans un gestionnaire sécurisé. + +## 3. Rendu attendu +Les fichiers Terraform ou équivalents et la configuration du pipeline initial. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_12/day_03/day_presentation.txt b/week_12/day_03/day_presentation.txt new file mode 100644 index 0000000..a2146b5 --- /dev/null +++ b/week_12/day_03/day_presentation.txt @@ -0,0 +1 @@ +Mets en ligne ton application sur l'infrastructure provisionnée. diff --git a/week_12/day_03/day_title.txt b/week_12/day_03/day_title.txt new file mode 100644 index 0000000..f294195 --- /dev/null +++ b/week_12/day_03/day_title.txt @@ -0,0 +1 @@ +Déploiement de l'application diff --git a/week_12/day_03/lesson_01.md b/week_12/day_03/lesson_01.md new file mode 100644 index 0000000..d9b88e5 --- /dev/null +++ b/week_12/day_03/lesson_01.md @@ -0,0 +1,27 @@ +# Déploiement applicatif + +## 1. Introduction +Passons à l'étape cruciale : rendre l'application accessible aux utilisateurs. + +## 2. Historique et contexte +Le déploiement applicatif utilise les méthodes introduites avec les premiers orchestrateurs de conteneurs. + +## 3. La ressource +### 3.1. Build de l'image +Si nécessaire, construis une image Docker finale et pousse-la dans ton registre. + +### 3.2. Déploiement automatisé +Utilise ton pipeline pour déployer automatiquement l'image sur le cluster ou la +machine cible. Pense à versionner les manifestes ou scripts utilisés. + +### 3.3. Tests post-déploiement +Une fois l'application en ligne, lance des tests basiques (ping d'URL, +connexion à la base de données) pour vérifier le succès du déploiement. + +## 4. Points importants à retenir +- Automatiser le déploiement évite les oublis manuels. +- Les tests post-déploiement donnent une première assurance que tout fonctionne. +- Note les étapes réalisées pour documenter le runbook. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_12/day_03/project_01.md b/week_12/day_03/project_01.md new file mode 100644 index 0000000..6c115a6 --- /dev/null +++ b/week_12/day_03/project_01.md @@ -0,0 +1,14 @@ +# Mettre en production + +## 1. Introduction +Il est temps de déployer l'application sur l'infrastructure que tu as créée. + +## 2. Le projet +1. Construis l'image finale si ce n'est pas déjà fait. +2. Déploie-la via ton pipeline ou manuellement sur l'environnement. +3. Vérifie que le service est accessible et fonctionne. + +## 3. Rendu attendu +Un court rapport expliquant comment tu as déployé et les tests effectués. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_12/day_04/day_presentation.txt b/week_12/day_04/day_presentation.txt new file mode 100644 index 0000000..c58d2ed --- /dev/null +++ b/week_12/day_04/day_presentation.txt @@ -0,0 +1 @@ +Ajoute la supervision et applique les bonnes pratiques de sécurité. diff --git a/week_12/day_04/day_title.txt b/week_12/day_04/day_title.txt new file mode 100644 index 0000000..a2316e3 --- /dev/null +++ b/week_12/day_04/day_title.txt @@ -0,0 +1 @@ +Monitoring et sécurité diff --git a/week_12/day_04/lesson_01.md b/week_12/day_04/lesson_01.md new file mode 100644 index 0000000..0c7fb17 --- /dev/null +++ b/week_12/day_04/lesson_01.md @@ -0,0 +1,29 @@ +# Observabilité et sécurité finale + +## 1. Introduction +Ton application tourne, mais il faut s'assurer de son bon fonctionnement et la +protéger des attaques. + +## 2. Historique et contexte +Les questions d'observabilité et de sécurité sont devenues centrales avec la multiplication des infrastructures cloud. + +## 3. La ressource +### 3.1. Monitoring +Installe des outils de monitoring (Prometheus, Grafana) pour suivre la santé de +l'application et créer des alertes. + +### 3.2. Sécurisation +Vérifie les accès, les règles réseau et la gestion des secrets. Ajoute un scan de +sécurité dans ton pipeline si besoin. + +### 3.3. Documentation +Note toutes les étapes de déploiement et les accès importants dans un dossier +`docs/` de ton dépôt. + +## 4. Points importants à retenir +- La supervision permet d'anticiper les incidents. +- Un projet bien documenté est plus facile à reprendre. +- La sécurité doit rester présente jusqu'au bout. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_12/day_04/project_01.md b/week_12/day_04/project_01.md new file mode 100644 index 0000000..04d72d5 --- /dev/null +++ b/week_12/day_04/project_01.md @@ -0,0 +1,15 @@ +# Ajouter la supervision + +## 1. Introduction +Complétons le projet en collectant des métriques et en sécurisant l'accès. + +## 2. Le projet +1. Installe Prometheus et Grafana ou utilise un service managé. +2. Configure au moins une alerte et un tableau de bord basique. +3. Vérifie les règles réseau et restreins les ports exposés uniquement à ce qui + est nécessaire. + +## 3. Rendu attendu +Des captures d'écran du dashboard et un résumé des réglages de sécurité appliqués. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_12/day_05/day_presentation.txt b/week_12/day_05/day_presentation.txt new file mode 100644 index 0000000..1449887 --- /dev/null +++ b/week_12/day_05/day_presentation.txt @@ -0,0 +1 @@ +Prépare la démonstration de ton projet et rédige un bilan de la semaine. diff --git a/week_12/day_05/day_title.txt b/week_12/day_05/day_title.txt new file mode 100644 index 0000000..1d1abaa --- /dev/null +++ b/week_12/day_05/day_title.txt @@ -0,0 +1 @@ +Présentation finale diff --git a/week_12/day_05/lesson_01.md b/week_12/day_05/lesson_01.md new file mode 100644 index 0000000..1080bf3 --- /dev/null +++ b/week_12/day_05/lesson_01.md @@ -0,0 +1,29 @@ +# Bilan et présentation + +## 1. Introduction +Dernier jour ! Il s'agit de finaliser le projet et de préparer la présentation +orale ou écrite de ton travail. + +## 2. Historique et contexte +Depuis les premières formations THP, la pratique et la présentation de projet sont restées au cœur de l'apprentissage. + +## 3. La ressource +### 3.1. Nettoyage du dépôt +Vérifie que le dépôt est clair : pas de fichiers inutiles, un README complet et +une documentation à jour. + +### 3.2. Préparation de la démo +Prévois un petit script ou une suite de commandes pour lancer rapidement +l'application et montrer les principales fonctionnalités. + +### 3.3. Rétrospective +Note ce qui a bien fonctionné et les points à améliorer. Cela te servira pour tes +futurs projets. + +## 4. Points importants à retenir +- Un projet bien présenté est plus valorisé. +- La documentation doit permettre à n'importe qui de reproduire ton travail. +- Profite de cette étape pour consolider tes apprentissages. + +## 5. Pour aller plus loin +Consulte la documentation officielle pour approfondir. diff --git a/week_12/day_05/project_01.md b/week_12/day_05/project_01.md new file mode 100644 index 0000000..8e769eb --- /dev/null +++ b/week_12/day_05/project_01.md @@ -0,0 +1,14 @@ +# Présentation du projet + +## 1. Introduction +Tu vas présenter ton travail à l'ensemble de la promo ou à ton équipe. + +## 2. Le projet +1. Prépare une courte démo montrant le déploiement et les fonctionnalités clés. +2. Explique brièvement les choix techniques et l'architecture mise en place. +3. Partage les difficultés rencontrées et ce que tu as appris. + +## 3. Rendu attendu +Un support de présentation ou une vidéo ainsi que le lien vers le dépôt finalisé. + +4. Partage ton travail sur GitHub avec un bref mode d'emploi. diff --git a/week_12/week_presentation.txt b/week_12/week_presentation.txt new file mode 100644 index 0000000..e0cd3f8 --- /dev/null +++ b/week_12/week_presentation.txt @@ -0,0 +1 @@ +Dernière ligne droite ! Cette semaine tu réalises un projet complet mettant en oeuvre toutes les notions vues jusqu'ici. diff --git a/week_12/week_title.txt b/week_12/week_title.txt new file mode 100644 index 0000000..bff1cf6 --- /dev/null +++ b/week_12/week_title.txt @@ -0,0 +1 @@ +Projet final DevOps