eadl:bloc4:fm2:intro

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
eadl:bloc4:fm2:intro [2026/04/25 01:58] – [1.1 Gestion manuelle des infrastructures] jcheroneadl:bloc4:fm2:intro [2026/04/30 01:58] (Version actuelle) – jcheron
Ligne 1: Ligne 1:
-====== Introduction à l’Infrastructure as Code (IaC) ======+====== Introduction à l'Infrastructure as Code (IaC) ====== 
 + 
 +<jumbotron> 
 +On apprend à déployer une infra de façon reproductible, versionnée, sécurisée et automatisée. 
 +</jumbotron>
  
 ===== Objectifs ===== ===== Objectifs =====
  
-  * Comprendre les limites des approches traditionnelles +À la fin de cette séance, vous serez capable de :
-  * Identifier les problématiques résolues par l’IaC +
-  * Découvrir les principes fondamentaux de l’IaC +
-  * Distinguer les rôles de Terraform et Ansible+
  
-===== 1. Problèmes sans Infrastructure as Code =====+  * Comprendre les limites de la gestion manuelle d’infrastructure 
 +  * Expliquer le concept d’Infrastructure as Code 
 +  * Distinguer approche déclarative et impérative 
 +  * Comprendre le rôle de Terraform et Ansible dans un workflow réel
  
-===== 1.1 Gestion manuelle des infrastructures =====+===== 1. Mise en situation =====
  
-Dans une approche classique :+Vous arrivez dans une entreprise.
  
-  * Création manuelle des machines (console cloud) +Un développeur vous dit :
-  * Configuration à la main (SSH, scripts) +
-  * Déploiements non standardisés+
  
-Problèmes :+  "Pour lancer l’environnement : 
 +   - démarre un conteneur 
 +   - ouvre le port 8080 
 +   - copie les fichiers à la main"
  
-  * Erreurs humaines fréquentes +Un autre développeur fait différemment.
-  * Temps de déploiement long +
-  * Difficulté à reproduire un environnement+
  
-===== 1.2 Dérive de configuration (Configuration Drift) =====+Résultat :
  
-Définition :+  * environnements différents 
 +  * bugs difficiles à reproduire 
 +  * perte de temps
  
-Un système évolue au fil du temps et ne correspond plus à sa configuration initiale.+<WRAP round help> 
 +Question :
  
-Exemple :+  * Quel est le principal problème ici ? 
 +</WRAP>
  
-- Un serveur en production a été modifié manuellement +===== 2. Problème : gestion manuelle =====
-- L’environnement de test n’est plus identique +
-- Bugs impossibles à reproduire+
  
------+En pratique, sans automatisation :
  
-===== 1.3 Non reproductibilité =====+  * actions manuelles (console, SSH) 
 +  * dépend de la personne 
 +  * pas versionné
  
-Sans automatisation :+Exemples concrets :
  
-- Impossible de recréer rapidement un environnement +  * un port ouvert "temporairement" jamais refermé 
-- Dépendance à des connaissances implicites +  * configuration différente entre dev et prod 
-- Documentation souvent obsolète+  * perte d’informations lors d’un redéploiement
  
------+<WRAP round help> 
 +Question :
  
-===== 1.4 Passage à l’échelle difficile =====+  * Pourquoi ces problèmes sont difficiles à corriger ? 
 +</WRAP>
  
-Exemple :+===== 3. Micro-exercice : reproduction d’un environnement =====
  
-- Créer 1 serveur → faisable à la main +Objectif :
-- Créer 50 serveurs → ingérable+
  
-Problèmes :+Comprendre la difficulté de reproduire un environnement sans automatisation
  
-- Temps +==== Étape 1 ====
-- cohérence +
-- erreurs cumulées+
  
------+Fichier : terminal
  
-===== 1.5 Manque de traçabilité =====+<sxh bash;gutter:false> 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-Questions difficiles :+<WRAP round todo> 
 +Validation :
  
-- Qui a modifié quoi ? +  * Ouvrir http://localhost:8081 
-- Quand ? +</WRAP>
-- Pourquoi ?+
  
------+==== Étape 2 ====
  
-===== 1.6 Transition =====+Fichier : terminal
  
-L’infrastructure devient :+<sxh bash;gutter:false> 
 +echo "<h1>Version 1</h1>" > index.html 
 +docker cp index.html test_nginx:/usr/share/nginx/html/index.html 
 +</sxh>
  
-- trop complexe +<WRAP round todo> 
-- trop dynamique +Validation :
-- trop critique+
  
-=> Besoin d’automatisation et de standardisation+  * Rafraîchir la page 
 +</WRAP>
  
------+==== Étape 3 ====
  
-===== 2. Concepts de l’Infrastructure as Code =====+Fichier : terminal
  
-===== 2.1 Définition =====+<sxh bash;gutter:false> 
 +docker rm -f test_nginx 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-Infrastructure as Code :+<WRAP round help> 
 +Questions :
  
-Décrire l’infrastructure sous forme de code afin de pouvoir :+  * Que s’est-il passé ? 
 +  * Pourquoi la modification a disparu ? 
 +</WRAP>
  
-- versionner +===== 4. Transition =====
-- automatiser +
-- reproduire+
  
------+Sans automatisation :
  
-===== 2.2 Principes fondamentaux =====+  * les modifications sont perdues 
 +  * rien n’est tracé 
 +  * difficile à reproduire
  
-==== Déclaratif vs procédural ====+<WRAP round help> 
 +Question :
  
-- Déclaratif : décrire l’état cible +  * Comment éviter ce problème dans une équipe ? 
-- Procédural : décrire les étapes+</WRAP>
  
------+===== 5. Définition de l’Infrastructure as Code =====
  
-==== Idempotence ====+Principe :
  
-Appliquer plusieurs fois une configuration produit le même résultat+  * décrire l’infrastructure avec du code 
 +  * versionner ce code (Git) 
 +  * exécuter automatiquement
  
------+Analogie :
  
-==== Versioning ====+  * avant : configuration "à la main" 
 +  * après : recette écrite et reproductible
  
-- Code stocké dans Git +===== 6. Exemple simple =====
-- Historique des modifications +
-- rollback possible+
  
------+Objectif :
  
-==== Automatisation ====+  * obtenir un serveur web fonctionnel
  
-- Déploiement rapide +Sans IaC :
-- Réduction des erreurs humaines+
  
------+  * commandes manuelles 
 +  * étapes non tracées
  
-==== Reproductibilité ====+Avec IaC :
  
-- Même code = même infrastructure+  * fichier Terraform → crée le serveur 
 +  * playbook Ansible → configure le serveur
  
------+Résultat :
  
-===== 2.3 Cycle de vie =====+  * reproductible 
 +  * automatisé 
 +  * partagé avec l’équipe
  
-- Écriture du code +===== 7. Déclaratif vs Impératif =====
-- Planification (diff) +
-- Application +
-- Mise à jour +
-- Destruction+
  
------+==== Approche impérative ====
  
-===== 3. Deux approches complémentaires =====+On décrit les étapes :
  
-===== 3.1 Vision globale =====+  * installer nginx 
 +  * démarrer le service
  
-Deux grandes catégories d’outils :+Limite :
  
-- Provisioning d’infrastructure +  * dépend de l’état initial
-- Configuration des systèmes+
  
------+==== Approche déclarative ====
  
-===== 3.2 Terraform =====+On décrit le résultat :
  
-Rôle :+  * "je veux un serveur web"
  
-- Provisionner l’infrastructure+L’outil gère les actions nécessaires
  
-Exemples :+<WRAP round help> 
 +Question :
  
-- VM (EC2) +  * Pourquoi cette approche est-elle adaptée au cloud ? 
-- Réseau (VPC, subnets) +</WRAP>
-- Load balancer +
-- Base de données+
  
-Caractéristiques : +===== 8. Terraform vs Ansible =====
- +
-- Approche déclarative +
-- Gestion d’un état (state) +
-- Interaction via API cloud +
- +
------ +
- +
-===== 3.3 Ansible ===== +
- +
-Rôle : +
- +
-- Configurer les systèmes +
-- Déployer des applications +
- +
-Exemples : +
- +
-- Installer NGINX +
-- Configurer un service +
-- Déployer une application +
- +
-Caractéristiques : +
- +
-- Approche orientée tâches +
-- Exécution séquentielle +
-- Idempotence +
- +
------ +
- +
-===== 3.4 Comparaison =====+
  
 Terraform : Terraform :
  
-- Déclaratif +  * crée l’infrastructure 
-- Orienté infrastructure +  * maintient un état (state)
-- Gère un état global+
  
 Ansible : Ansible :
  
-- Orienté tâches +  * configure les systèmes 
-- Configuration logicielle +  * exécute des tâches 
-- Pas de state central+ 
 +Exemple :
  
------+  * Terraform → crée un conteneur 
 +  * Ansible → modifie son contenu
  
-===== 3.5 Complémentarité =====+===== 9. Workflow DevOps =====
  
-Dans un workflow réel :+  * Terraform → infrastructure 
 +  * Ansible → configuration 
 +  * pipeline → déploiement applicatif
  
-- Terraform crée l’infrastructure +Chaîne :
-- Ansible configure les serveurs+
  
------+  Code → Infrastructure → Configuration → Application
  
-===== 4. Conclusion =====+===== 10. Transition vers le TD =====
  
-L’Infrastructure as Code permet :+Dans le TD suivant :
  
-- d’industrialiser les déploiements +  * vous allez automatiser ce que vous venez de faire manuellement 
-- de fiabiliser les environnements +  * créer un service avec Terraform 
-- de gagner en rapidité et en reproductibilité+  * le modifier avec Ansible
  
-Terraform et Ansible ne sont pas concurrents mais complémentaires.+Objectif :
  
------+  * comprendre la complémentarité des outils
  
-===== 5. Question de réflexion =====+===== 11. À retenir =====
  
-Pourquoi est-il risqué de modifier une infrastructure manuellement en production ?+  * IaC = infrastructure gérée comme du code 
 +  * objectif : reproductibilité et fiabilité 
 +  * Terraform → provisioning 
 +  * Ansible → configuration
  
  • eadl/bloc4/fm2/intro.1777075081.txt.gz
  • Dernière modification : il y a 2 semaines
  • de jcheron