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.4 Passage à l’échelle difficile] 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+
  
-===== 1.5 Manque de traçabilité =====+Fichier : terminal
  
-Questions difficiles :+<sxh bash;gutter:false> 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-- Qui a modifié quoi ? +<WRAP round todo> 
-- Quand ? +Validation :
-- Pourquoi ?+
  
------+  * Ouvrir http://localhost:8081 
 +</WRAP>
  
-===== 1.6 Transition =====+==== Étape 2 ====
  
-L’infrastructure devient :+Fichier : terminal
  
-- trop complexe +<sxh bash;gutter:false> 
-- trop dynamique +echo "<h1>Version 1</h1>" > index.html 
-- trop critique+docker cp index.html test_nginx:/usr/share/nginx/html/index.html 
 +</sxh>
  
-=> Besoin d’automatisation et de standardisation+<WRAP round todo> 
 +Validation :
  
------+  * Rafraîchir la page 
 +</WRAP>
  
-===== 2. Concepts de l’Infrastructure as Code =====+==== Étape 3 ====
  
-===== 2.1 Définition =====+Fichier : terminal
  
-Infrastructure as Code :+<sxh bash;gutter:false> 
 +docker rm -f test_nginx 
 +docker run -d -p 8081:80 --name test_nginx nginx 
 +</sxh>
  
-Décrire l’infrastructure sous forme de code afin de pouvoir :+<WRAP round help> 
 +Questions :
  
-- versionner +  * Que s’est-il passé ? 
-- automatiser +  * Pourquoi la modification a disparu ? 
-- reproduire+</WRAP>
  
------+===== 4. Transition =====
  
-===== 2.2 Principes fondamentaux =====+Sans automatisation :
  
-==== Déclaratif vs procédural ====+  * les modifications sont perdues 
 +  * rien n’est tracé 
 +  * difficile à reproduire
  
-- Déclaratif : décrire l’état cible +<WRAP round help> 
-- Procédural : décrire les étapes+Question :
  
------+  * Comment éviter ce problème dans une équipe ? 
 +</WRAP>
  
-==== Idempotence ====+===== 5. Définition de l’Infrastructure as Code =====
  
-Appliquer plusieurs fois une configuration produit le même résultat+Principe :
  
------+  * décrire l’infrastructure avec du code 
 +  * versionner ce code (Git) 
 +  * exécuter automatiquement
  
-==== Versioning ====+Analogie :
  
-- Code stocké dans Git +  * avant : configuration "à la main" 
-- Historique des modifications +  * après : recette écrite et reproductible
-- rollback possible+
  
------+===== 6. Exemple simple =====
  
-==== Automatisation ====+Objectif :
  
-- Déploiement rapide +  * obtenir un serveur web fonctionnel
-- Réduction des erreurs humaines+
  
------+Sans IaC :
  
-==== Reproductibilité ====+  * commandes manuelles 
 +  * étapes non tracées
  
-- Même code = même infrastructure+Avec IaC :
  
------+  * fichier Terraform → crée le serveur 
 +  * playbook Ansible → configure le serveur
  
-===== 2.3 Cycle de vie =====+Résultat :
  
-- Écriture du code +  * reproductible 
-- Planification (diff) +  * automatisé 
-- Application +  * partagé avec l’équipe
-- Mise à jour +
-- Destruction+
  
------+===== 7. Déclaratif vs Impératif =====
  
-===== 3. Deux approches complémentaires =====+==== Approche impérative ====
  
-===== 3.1 Vision globale =====+On décrit les étapes :
  
-Deux grandes catégories d’outils :+  * installer nginx 
 +  * démarrer le service
  
-- Provisioning d’infrastructure +Limite :
-- Configuration des systèmes+
  
------+  * dépend de l’état initial
  
-===== 3.2 Terraform =====+==== Approche déclarative ====
  
-Rôle :+On décrit le résultat :
  
-- Provisionner l’infrastructure+  * "je veux un serveur web"
  
-Exemples :+L’outil gère les actions nécessaires
  
-- VM (EC2) +<WRAP round help> 
-- Réseau (VPC, subnets) +Question :
-- Load balancer +
-- Base de données+
  
-Caractéristiques :+  * Pourquoi cette approche est-elle adaptée au cloud ? 
 +</WRAP>
  
-- Approche déclarative +===== 8. Terraform vs Ansible =====
-- 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.1777075116.txt.gz
  • Dernière modification : il y a 12 jours
  • de jcheron