eadl:bloc4:fm2:td2

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:td2 [2026/05/03 14:35] – [7. Compréhension] jcheroneadl:bloc4:fm2:td2 [2026/05/13 16:52] (Version actuelle) – [13.3 Création d’un composant réutilisable] jcheron
Ligne 1: Ligne 1:
-====== TD2 : Créer un module Terraform réutilisable ======+====== TD2 : Bases du provisionning ======
  
-===== Objectifs =====+===== Terraform et Modularisation =====
  
   * Comprendre l’intérêt des variables et des outputs   * Comprendre l’intérêt des variables et des outputs
Ligne 179: Ligne 179:
 </sxh> </sxh>
  
-<WRAP round help>+<WRAP round question>
 Questions : Questions :
  
Ligne 193: Ligne 193:
 </sxh> </sxh>
  
-<WRAP round help>+<WRAP round question>
 Question : Question :
  
Ligne 367: Ligne 367:
 Terraform crée une instance par entrée dans la map. Terraform crée une instance par entrée dans la map.
 </WRAP> </WRAP>
-<WRAP round help>+<WRAP round question>
 Question : Question :
  
Ligne 413: Ligne 413:
 ==== 11.5 Analyse ==== ==== 11.5 Analyse ====
  
-<WRAP round help>+<WRAP round question>
   * Si vous supprimez un environnement de la map, que va faire Terraform ?   * Si vous supprimez un environnement de la map, que va faire Terraform ?
   * Que se passe-t-il si vous renommez une clé ?   * Que se passe-t-il si vous renommez une clé ?
Ligne 419: Ligne 419:
 </WRAP> </WRAP>
  
-==== 11.6 Comparaison ====+==== 11.6 Limites ====
  
-<WRAP round help>+<WRAP round question>
 Question : Question :
  
-  * Dans un projet réel avec plusieurs dizaines d’environnements, quels seraient les avantages et les inconvénients de cette approche ?+  * Votre équipe utilise cette approche avec ''map + for_each''. 
 +Un développeur renomme la clé ''frontend'' en ''front''. 
 + 
 +  * Que va faire Terraform lors du prochain apply ? 
 +  * Pourquoi ce comportement peut-il être dangereux en production ? 
 +  * Comment éviter ce problème dans un projet réel ? 
 +</WRAP> 
 + 
 + 
 +===== 12. Extension — Terraform → Ansible ===== 
 + 
 +==== Objectifs ==== 
 + 
 +  * Réutiliser les outputs Terraform 
 +  * Introduire Ansible comme outil de configuration 
 +  * Comprendre l’intégration entre outils 
 +  * Comparer deux approches d’architecture 
 + 
 + 
 +==== 12.1 Contexte ==== 
 + 
 +Vous avez déployé plusieurs conteneurs nginx avec Terraform. 
 + 
 +Chaque conteneur est accessible via une URL différente : 
 + 
 +  * frontend → http://localhost:8080 
 +  * backend → http://localhost:8081 
 +  * data → http://localhost:8082 
 + 
 +Problème : 
 + 
 +  * toutes les pages nginx sont identiques 
 +  * impossible d’identifier facilement l’environnement 
 + 
 +Objectif : 
 + 
 +Configurer dynamiquement chaque conteneur avec Ansible. 
 + 
 + 
 +==== 12.2 Mise en place d’Ansible ==== 
 + 
 +Créer un dossier : 
 + 
 +<sxh bash;gutter:false> 
 +mkdir ansible 
 +cd ansible 
 +</sxh> 
 + 
 +Créer un fichier ''playbook.yml'' : 
 + 
 +<sxh yaml> 
 +- name: Configuration des conteneurs nginx 
 +  hosts: all 
 +  gather_facts: false 
 + 
 +  tasks: 
 +    - name: Copier une page HTML personnalisée 
 +      copy: 
 +        content: | 
 +          <h1>Environnement : {{ inventory_hostname }}</h1> 
 +          <p>URL : http://localhost:{{ ansible_port }}</p> 
 +        dest: /usr/share/nginx/html/index.html 
 +</sxh> 
 + 
 +<WRAP round info> 
 +Chaque conteneur aura une page différente en fonction de son nom. 
 + 
 +Vous utilisez ici les variables Ansible : 
 + 
 +  * inventory_hostname → nom de l’hôte 
 +  * ansible_port → port utilisé 
 +</WRAP> 
 + 
 +==== 12.3 Problème à résoudre ==== 
 + 
 +Ansible a besoin d’un **inventory** pour savoir : 
 + 
 +  * quelles machines cibler 
 +  * comment s’y connecter 
 + 
 +Or, ces informations sont connues par Terraform. 
 + 
 +Comment faire le lien entre les deux ? 
 + 
 + 
 +==== 12.4 Approche A — Génération via Terraform ==== 
 + 
 +Modifier Terraform pour générer un fichier ''inventory.ini''. 
 + 
 +Indice : 
 + 
 +  * utiliser ''templatefile'' 
 +  * utiliser ''local_file'' 
 + 
 +Exemple attendu : 
 + 
 +<sxh ini> 
 +[web] 
 +frontend ansible_host=localhost ansible_port=8080 
 +backend ansible_host=localhost ansible_port=8081 
 +data ansible_host=localhost ansible_port=8082 
 +</sxh> 
 + 
 + 
 +==== 12.5 Approche B — Approche découplée ==== 
 + 
 +Utiliser les outputs Terraform pour générer l’inventory avec un script externe. 
 + 
 +<sxh bash;gutter:false> 
 +terraform output -json > outputs.json 
 +</sxh> 
 + 
 +Transformer ce fichier en ''inventory.ini''. 
 + 
 +Langage au choix : 
 + 
 +  * bash 
 +  * python 
 +  * jq 
 + 
 +==== 12.6 Exécution ==== 
 + 
 +Lancer Ansible : 
 + 
 +<sxh bash;gutter:false> 
 +ansible-playbook -i inventory.ini playbook.yml 
 +</sxh> 
 + 
 +<WRAP round todo> 
 +Vérifier : 
 + 
 +  * chaque URL affiche un contenu différent 
 +</WRAP> 
 + 
 + 
 +==== 12.7 Analyse ==== 
 + 
 +<WRAP round question> 
 +Questions : 
 + 
 +  * Quelle approche est la plus simple à mettre en place ? 
 +  * Quelle approche est la plus maintenable ? 
 +  * Que se passe-t-il si vous ajoutez un nouvel environnement ? 
 +  * Quelle solution limite le couplage entre Terraform et Ansible ? 
 +  * Dans un projet réel, laquelle choisiriez-vous ? Pourquoi ? 
 +</WRAP> 
 + 
 + 
 +==== 12.8 Bonus ==== 
 + 
 +<WRAP round todo> 
 +  * Ajouter une variable Terraform ''env_type'' (dev, prod…) 
 +  * L’afficher dans la page HTML via Ansible 
 +</WRAP> 
 + 
 +<WRAP round info> 
 +Objectif : 
 + 
 +Comprendre comment une information définie dans Terraform 
 +peut être utilisée dans Ansible. 
 + 
 +C’est un cas réel fréquent en DevOps. 
 +</WRAP> 
 + 
 +===== 13. Extension : Alternative avec Pulumi (approche orientée développeur) ===== 
 + 
 +==== Objectifs ==== 
 + 
 +  * Découvrir une alternative à Terraform 
 +  * Comprendre la différence déclaratif vs programmation 
 +  * Réécrire une logique Terraform avec un langage classique 
 +  * Identifier avantages et limites 
 + 
 +==== 13.1 Principe ==== 
 + 
 +Contrairement à Terraform : 
 + 
 +  * Terraform → langage déclaratif (HCL) 
 +  * Pulumi → langage de programmation (TypeScript ici) 
 + 
 +Un module Terraform devient : 
 + 
 +  * une fonction 
 +  * ou une classe 
 + 
 +Un ''for_each'' devient : 
 + 
 +  * une boucle classique 
 + 
 +==== 13.2 Initialisation du projet ==== 
 + 
 +<sxh bash;gutter:false> 
 +mkdir pulumi-td2 
 +cd pulumi-td2 
 + 
 +pulumi new typescript 
 +</sxh> 
 + 
 +Choisir : 
 + 
 +  * project name : pulumi-td2 
 +  * stack : dev 
 + 
 +Installer le provider Docker : 
 + 
 +<sxh bash;gutter:false> 
 +npm install @pulumi/docker 
 +</sxh> 
 + 
 +==== 13.3 Création d’un composant réutilisable ==== 
 + 
 +Créer un fichier ''nginx.ts'' : 
 + 
 +<sxh ts> 
 +import * as docker from "@pulumi/docker"; 
 + 
 +export function createNginx(name: string, port: number) { 
 + 
 +  const image = new docker.RemoteImage(name, { 
 +    name: "nginx:latest", 
 +  }); 
 + 
 +  const container = new docker.Container(name, { 
 +    image: image.imageId, 
 +    ports: [ 
 +      { 
 +        internal: 80, 
 +        external: port, 
 +      }, 
 +    ], 
 +  }); 
 + 
 +  return { 
 +    url: `http://localhost:${port}`, 
 +  }; 
 +} 
 +</sxh> 
 + 
 +<WRAP round info> 
 +En Pulumi, on remplace les modules Terraform par du code réutilisable. 
 +</WRAP> 
 + 
 +==== 13.4 Utilisation (équivalent main.tf) ==== 
 + 
 +Modifier ''index.ts'' : 
 + 
 +<sxh ts> 
 +import { createNginx } from "./nginx"; 
 + 
 +const frontend = createNginx("frontend", 8080); 
 +const backend = createNginx("backend", 8081); 
 + 
 +export const frontendUrl = frontend.url; 
 +export const backendUrl = backend.url; 
 +</sxh> 
 + 
 +==== 13.5 Exécution ==== 
 + 
 +<sxh bash;gutter:false> 
 +pulumi up 
 +</sxh> 
 + 
 +==== 13.6 Version dynamique ==== 
 + 
 +Equivalent du ''for_each'' Terraform : 
 + 
 +<sxh ts> 
 +import { createNginx } from "./nginx"; 
 + 
 +const environments: Record<string, number> = { 
 +  frontend: 8080, 
 +  backend: 8081, 
 +  data: 8082, 
 +}; 
 + 
 +const urls: Record<string, string> = {}; 
 + 
 +for (const [name, port] of Object.entries(environments)) { 
 +  const nginx = createNginx(name, port); 
 +  urls[name] = nginx.url; 
 +} 
 + 
 +export { urls }; 
 +</sxh> 
 + 
 +==== 13.7 Validation des erreurs ==== 
 + 
 +<sxh ts> 
 +const ports = Object.values(environments); 
 + 
 +if (new Set(ports).size !== ports.length) { 
 +  throw new Error("Ports dupliqués détectés !"); 
 +} 
 +</sxh> 
 + 
 +<WRAP round info> 
 +Contrairement à Terraform, Pulumi permet d’ajouter des validations personnalisées 
 +avant même le déploiement. 
 +</WRAP> 
 + 
 +==== 13.8 Comparaison ==== 
 + 
 +<WRAP round question> 
 +Questions : 
 + 
 +  * Qu’est-ce qui est plus simple à écrire ? 
 +  * Qu’est-ce qui est plus lisible ? 
 +  * Où Pulumi est-il plus puissant ? 
 +  * Où Terraform est-il plus prévisible ? 
 +</WRAP> 
 + 
 +==== 13.9 Analyse ==== 
 + 
 +<WRAP round info> 
 +Pulumi permet : 
 + 
 +  * d’utiliser des structures natives (boucles, fonctions) 
 +  * de factoriser facilement le code 
 +  * d’ajouter des validations complexes 
 + 
 +Mais : 
 + 
 +  * nécessite des compétences en développement 
 +  * peut introduire de la complexité inutile 
 +</WRAP> 
 + 
 +==== 13.10 Conclusion ==== 
 + 
 +<WRAP round info> 
 +Terraform et Pulumi répondent au même besoin avec deux approches : 
 + 
 +  * Terraform → simplicité, standardisation, lisibilité 
 +  * Pulumi → flexibilité, puissance, approche développeur 
 + 
 +Dans un projet réel : 
 + 
 +  * Terraform est souvent utilisé côté Ops 
 +  * Pulumi est pertinent pour des équipes orientées développement
 </WRAP> </WRAP>
  
  • eadl/bloc4/fm2/td2.1777811706.txt.gz
  • Dernière modification : il y a 7 semaines
  • de jcheron