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:57] – [Objectifs] 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+
  
------+Résultat :
  
-===== 1.2 Dérive de configuration (Configuration Drift) =====+  * environnements différents 
 +  * bugs difficiles à reproduire 
 +  * perte de temps
  
-Définition :+<WRAP round help> 
 +Question :
  
-Un système évolue au fil du temps et ne correspond plus à sa configuration initiale.+  * Quel est le principal problème ici ? 
 +</WRAP>
  
-Exemple :+===== 2. Problème : gestion manuelle =====
  
-- Un serveur en production a été modifié manuellement +En pratique, sans automatisation :
-- L’environnement de test n’est plus identique +
-- Bugs impossibles à reproduire+
  
------+  * actions manuelles (console, SSH) 
 +  * dépend de la personne 
 +  * pas versionné
  
-===== 1.3 Non reproductibilité =====+Exemples concrets :
  
-Sans automatisation :+  * un port ouvert "temporairement" jamais refermé 
 +  * configuration différente entre dev et prod 
 +  * perte d’informations lors d’un redéploiement
  
-- Impossible de recréer rapidement un environnement +<WRAP round help> 
-- Dépendance à des connaissances implicites +Question :
-- Documentation souvent obsolète+
  
------+  * Pourquoi ces problèmes sont difficiles à corriger ? 
 +</WRAP>
  
-===== 1.4 Passage à l’échelle difficile =====+===== 3. Micro-exercice : reproduction d’un environnement =====
  
-Exemple :+Objectif :
  
-- Créer 1 serveur → faisable à la main +Comprendre la difficulté de reproduire un environnement sans automatisation
-- Créer 50 serveurs → ingérable+
  
-Problèmes :+==== Étape 1 ====
  
-- Temps +Fichier : terminal
-- cohérence +
-- erreurs cumulées+
  
------+<sxh bash;gutter:false> 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-===== 1.5 Manque de traçabilité =====+<WRAP round todo> 
 +Validation :
  
-Questions difficiles :+  * Ouvrir http://localhost:8081 
 +</WRAP>
  
-- Qui a modifié quoi ? +==== Étape 2 ====
-- Quand ? +
-- Pourquoi ?+
  
------+Fichier : terminal
  
-===== 1.6 Transition =====+<sxh bash;gutter:false> 
 +echo "<h1>Version 1</h1>" > index.html 
 +docker cp index.html test_nginx:/usr/share/nginx/html/index.html 
 +</sxh>
  
-L’infrastructure devient :+<WRAP round todo> 
 +Validation :
  
-- trop complexe +  * Rafraîchir la page 
-- trop dynamique +</WRAP>
-- trop critique+
  
-=> Besoin d’automatisation et de standardisation+==== Étape 3 ====
  
------+Fichier : terminal
  
-===== 2. Concepts de l’Infrastructure as Code =====+<sxh bash;gutter:false> 
 +docker rm -f test_nginx 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-===== 2.1 Définition =====+<WRAP round help> 
 +Questions :
  
-Infrastructure as Code :+  * Que s’est-il passé ? 
 +  * Pourquoi la modification a disparu ? 
 +</WRAP>
  
-Décrire l’infrastructure sous forme de code afin de pouvoir :+===== 4. Transition =====
  
-- versionner +Sans automatisation :
-- automatiser +
-- reproduire+
  
------+  * les modifications sont perdues 
 +  * rien n’est tracé 
 +  * difficile à reproduire
  
-===== 2.2 Principes fondamentaux =====+<WRAP round help> 
 +Question :
  
-==== Déclaratif vs procédural ====+  * Comment éviter ce problème dans une équipe ? 
 +</WRAP>
  
-- Déclaratif : décrire l’état cible +===== 5. Définition de l’Infrastructure as Code =====
-- Procédural : décrire les étapes+
  
------+Principe :
  
-==== Idempotence ====+  * décrire l’infrastructure avec du code 
 +  * versionner ce code (Git) 
 +  * exécuter automatiquement
  
-Appliquer plusieurs fois une configuration produit le même résultat+Analogie :
  
------+  * avant : configuration "à la main" 
 +  * après : recette écrite et reproductible
  
-==== Versioning ====+===== 6. Exemple simple =====
  
-- Code stocké dans Git +Objectif :
-- Historique des modifications +
-- rollback possible+
  
------+  * obtenir un serveur web fonctionnel
  
-==== Automatisation ====+Sans IaC :
  
-- Déploiement rapide +  * commandes manuelles 
-- Réduction des erreurs humaines+  * étapes non tracées
  
------+Avec IaC :
  
-==== Reproductibilité ====+  * fichier Terraform → crée le serveur 
 +  * playbook Ansible → configure le serveur
  
-- Même code = même infrastructure+Résultat :
  
------+  * reproductible 
 +  * automatisé 
 +  * partagé avec l’équipe
  
-===== 2.3 Cycle de vie =====+===== 7. Déclaratif vs Impératif =====
  
-- Écriture du code +==== Approche impérative ====
-- Planification (diff) +
-- Application +
-- Mise à jour +
-- Destruction+
  
------+On décrit les étapes :
  
-===== 3. Deux approches complémentaires =====+  * installer nginx 
 +  * démarrer le service
  
-===== 3.1 Vision globale =====+Limite :
  
-Deux grandes catégories d’outils :+  * dépend de l’état initial
  
-- Provisioning d’infrastructure +==== Approche déclarative ====
-- Configuration des systèmes+
  
------+On décrit le résultat :
  
-===== 3.2 Terraform =====+  * "je veux un serveur web"
  
-Rôle :+L’outil gère les actions nécessaires
  
-- Provisionner l’infrastructure+<WRAP round help> 
 +Question :
  
-Exemples :+  * Pourquoi cette approche est-elle adaptée au cloud ? 
 +</WRAP>
  
-- VM (EC2) +===== 8. Terraform vs Ansible =====
-- Réseau (VPC, subnets) +
-- Load balancer +
-- Base de données +
- +
-Caractéristiques : +
- +
-- 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.1777075038.txt.gz
  • Dernière modification : il y a 14 jours
  • de jcheron