Cas pratiques Ansible

Contexte : Un playbook modifie la configuration Nginx sur un serveur. Le Problème : Le service n'est pas redémarré après modification du fichier de configuration. Contraintes : Utiliser un handler déclenché uniquement si la tâche de modification change réellement le fichier. Livrable attendu : Adapter le playbook pour inclure un handler permettant de redémarrer Nginx uniquement en cas de modification.

Contexte : Un playbook tente de créer un fichier de configuration personnalisé. Le Problème : Le module utilisé ne permet pas de créer correctement le fichier. Extrait actuel : - name: Create config file command: touch /etc/app.conf Contraintes : Utiliser un module Ansible adapté garantissant idempotence. Livrable attendu : Remplacer l'utilisation de command par un module approprié permettant une gestion propre et idempotente du fichier.

Contexte : Une équipe utilise Ansible pour installer Nginx sur un serveur Ubuntu. Le Problème : L'exécution du playbook échoue immédiatement avec une erreur YAML indiquant une mauvaise indentation. Contraintes : Corriger uniquement la syntaxe YAML sans modifier la logique des tâches. Extrait actuel : - hosts: web tasks: - name: Install nginx apt: name: nginx state: present Livrable attendu : Fournir une version corrigée du playbook avec indentation correcte permettant une exécution sans erreur.

Contexte : Un playbook déploie une application en utilisant une variable app_port. Le Problème : L'exécution échoue avec une erreur indiquant que la variable app_port est undefined. Extrait actuel : - hosts: web tasks: - name: Print port debug: msg: "Application runs on port {{ app_port }}" Contraintes : Déclarer correctement la variable sans modifier la tâche debug. Livrable attendu : Ajouter la déclaration de variable appropriée afin que le playbook s'exécute correctement.

Contexte : Une équipe doit gérer deux serveurs web et un serveur base de données. Le Problème : Aucun fichier d'inventaire n'est encore défini pour organiser les hôtes. Contraintes : Créer un inventaire statique structuré avec un groupe web et un groupe db. Livrable attendu : Fournir un exemple de fichier inventory.ini correctement structuré permettant de cibler les différents groupes d'hôtes.

Contexte : Une équipe souhaite automatiser l'installation de Git sur plusieurs serveurs Linux. Le Problème : Aucune configuration Ansible n'existe actuellement. Contraintes : Utiliser un playbook simple ciblant le groupe all et installer le paquet git via le module apt. Livrable attendu : Fournir un playbook minimal permettant d'installer Git sur tous les hôtes définis dans l'inventaire.

Contexte : Une équipe souhaite structurer son code Ansible pour installer Apache sur plusieurs serveurs. Le Problème : Toutes les tâches sont actuellement dans un seul playbook difficile à maintenir. Contraintes : Créer un rôle simple avec la structure standard roles/apache/tasks/main.yml. Livrable attendu : Proposer une structure de rôle minimale et montrer comment l'inclure dans un playbook principal.

Contexte : Plusieurs valeurs sont actuellement définies en dur dans un playbook. Le Problème : Cela rend la configuration difficile à maintenir et à adapter selon les environnements. Contraintes : Déplacer les variables dans un fichier vars externe. Livrable attendu : Adapter le playbook pour utiliser un fichier vars.yml séparé et référencer correctement les variables.

Contexte : Une tâche de maintenance doit être exécutée uniquement sur les serveurs du groupe web. Le Problème : Le playbook actuel cible tous les hôtes de l'inventaire. Contraintes : Modifier uniquement la directive hosts dans le playbook. Livrable attendu : Adapter le playbook afin qu'il cible exclusivement le groupe web défini dans l'inventaire.

Contexte : Un playbook doit installer un paquet uniquement sur les serveurs Ubuntu. Le Problème : La tâche s'exécute actuellement sur tous les hôtes, y compris ceux non compatibles. Contraintes : Utiliser une condition when basée sur ansible_os_family ou ansible_distribution. Livrable attendu : Adapter le playbook pour exécuter la tâche uniquement sur les systèmes Ubuntu.

Contexte : L'infrastructure cloud évolue fréquemment et les hôtes ne sont plus statiques. Le Problème : L'inventaire statique devient obsolète et nécessite des mises à jour manuelles constantes. Contraintes : Mettre en place un inventaire dynamique via plugin AWS EC2 ou équivalent. Livrable attendu : Décrire une configuration d'inventaire dynamique permettant la découverte automatique des hôtes cloud.

Contexte : Une équipe souhaite exécuter uniquement certaines tâches d'un playbook volumineux. Le Problème : Chaque exécution applique l'ensemble des tâches, même non nécessaires. Contraintes : Ajouter des tags aux tâches critiques pour permettre une exécution ciblée via la CLI. Livrable attendu : Adapter le playbook afin d'utiliser des tags permettant un déploiement partiel contrôlé.

Contexte : Plusieurs tâches modifient des fichiers de configuration liés au même service. Le Problème : Le service est redémarré plusieurs fois inutilement dans un même run. Contraintes : Utiliser correctement les handlers pour éviter les redémarrages multiples. Livrable attendu : Structurer le playbook afin que le service ne soit redémarré qu'une seule fois même si plusieurs tâches déclenchent une notification.

Contexte : Une application doit être configurée différemment en environnement dev et production. Le Problème : Les paramètres sont actuellement codés en dur dans les tâches. Contraintes : Utiliser des variables spécifiques par environnement et conditions when adaptées. Livrable attendu : Adapter la configuration Ansible pour charger des variables différentes selon l'environnement et appliquer des tâches conditionnelles appropriées.

Contexte : Un rôle application dépend d'un rôle nginx pour fonctionner correctement. Le Problème : L'ordre d'inclusion des rôles n'est pas garanti et provoque des erreurs. Contraintes : Déclarer la dépendance dans meta/main.yml du rôle application. Livrable attendu : Proposer une configuration de rôle incluant des dépendances explicites via le fichier meta/main.yml.

Contexte : Une application nécessite des mots de passe base de données stockés actuellement en clair dans les fichiers vars. Le Problème : Les secrets sont visibles dans le repository. Contraintes : Utiliser Ansible Vault pour chiffrer les variables sensibles sans modifier la logique des tâches. Livrable attendu : Décrire une configuration utilisant Ansible Vault pour protéger les variables sensibles tout en permettant leur utilisation dans le playbook.

Contexte : Une application dépend d'une base de données devant être installée et configurée avant le déploiement applicatif. Le Problème : Les tâches sont exécutées sans ordre logique clair entre groupes d'hôtes. Contraintes : Structurer le playbook pour garantir l'ordre d'exécution correct entre groupes db et web. Livrable attendu : Proposer un playbook organisé en plusieurs plays garantissant l'installation préalable de la base de données avant le déploiement applicatif.

Contexte : Une infrastructure comprend plusieurs composants (nginx, application, base de données) actuellement définis dans un seul playbook volumineux. Le Problème : Le code est difficile à maintenir et toute modification impacte l'ensemble du déploiement. Contraintes : Refactoriser en plusieurs rôles distincts avec une structure standard (tasks, handlers, vars, defaults). Aucun changement fonctionnel. Livrable attendu : Proposer une architecture de projet Ansible modulaire avec plusieurs rôles réutilisables et un playbook principal orchestrant leur exécution.

Contexte : Un fichier de configuration d'application doit être généré dynamiquement selon les variables d'hôte. Le Problème : Le fichier est actuellement copié statiquement, sans adaptation aux environnements. Contraintes : Utiliser le module template avec un fichier Jinja2. Garantir l'idempotence et notifier un handler en cas de modification. Livrable attendu : Proposer un exemple d'utilisation du module template avec variables dynamiques et handler associé.

Contexte : Plusieurs paquets doivent être installés sur un ensemble de serveurs. Le Problème : Le playbook duplique les tâches pour chaque paquet. Contraintes : Utiliser loop ou with_items pour itérer sur une liste de paquets définie dans une variable. Livrable attendu : Adapter le playbook afin d'utiliser une boucle Ansible permettant l'installation dynamique de plusieurs paquets sans duplication de code.

Contexte : Une organisation gère plusieurs environnements (dev, staging, prod) avec des exigences de configuration très différentes. Le Problème : Les variables sont mélangées et certaines valeurs de production ont déjà été appliquées par erreur en environnement de test. Contraintes : Mettre en place une structure claire utilisant group_vars, host_vars et éventuellement des inventaires séparés. Aucune duplication excessive autorisée. Livrable attendu : Proposer une architecture Ansible robuste garantissant une isolation stricte des variables par environnement tout en conservant une base de rôles commune.

Contexte : Une application doit être déployée sur plusieurs dizaines de serveurs simultanément. Le Problème : Le déploiement séquentiel est trop lent et impacte la disponibilité. Contraintes : Utiliser strategy free ou linear et contrôler serial pour limiter le nombre d'hôtes traités simultanément. Livrable attendu : Décrire une configuration Ansible optimisée permettant un déploiement parallèle contrôlé avec limitation de l'impact en production.

Contexte : Un déploiement applicatif peut échouer partiellement, laissant le système dans un état incohérent. Le Problème : Aucun mécanisme de rollback ou de gestion avancée des erreurs n'est prévu. Contraintes : Utiliser block, rescue et always pour gérer les erreurs et restaurer un état stable si nécessaire. Livrable attendu : Proposer un playbook utilisant block/rescue permettant un rollback contrôlé en cas d'échec critique.

Contexte : Une entreprise impose des règles strictes (packages obligatoires, configurations de sécurité, permissions systèmes). Le Problème : Aucune vérification automatique ne garantit la conformité des serveurs. Contraintes : Mettre en place des tâches idempotentes permettant d'assurer la conformité continue. Livrable attendu : Décrire une stratégie Ansible assurant la conformité automatisée des systèmes via playbooks robustes et vérifications répétables.

Contexte : Une infrastructure critique nécessite des secrets dynamiques générés à la volée (credentials base de données temporaires). Le Problème : Les secrets sont actuellement statiques et stockés via Ansible Vault. Contraintes : Intégrer HashiCorp Vault comme source dynamique via lookup plugin sans exposer les secrets dans les logs. Livrable attendu : Proposer une architecture Ansible permettant la récupération sécurisée de secrets dynamiques via Vault avec minimisation des risques d'exposition.

Contexte : Une organisation déploie des ressources sur AWS et Azure simultanément. Le Problème : Les inventaires statiques ne permettent pas une gestion efficace des hôtes multi-cloud. Contraintes : Mettre en place des inventaires dynamiques pour chaque cloud tout en conservant une segmentation claire par groupes. Livrable attendu : Proposer une architecture d'inventaire dynamique multi-cloud permettant une gestion cohérente et sécurisée des hôtes.

Contexte : Une infrastructure existante a été configurée manuellement sur plusieurs serveurs critiques. Le Problème : Une automatisation brutale pourrait provoquer des interruptions de service. Contraintes : Mettre en place une stratégie progressive d'automatisation, incluant audit préalable et tâches non destructives. Livrable attendu : Décrire un plan détaillé de migration vers Ansible permettant une adoption progressive et sans interruption des services existants.

Contexte : Une application distribuée s'appuie sur plusieurs clusters (load balancer, web, base de données) répartis sur différents groupes d'hôtes. Le Problème : Les déploiements échouent car certaines dépendances inter-clusters ne sont pas correctement synchronisées. Contraintes : Structurer le playbook en plusieurs plays ordonnés, utiliser des variables globales et gérer les dépendances sans scripts externes. Livrable attendu : Décrire une orchestration Ansible complète garantissant l'ordre logique de configuration entre les différents clusters.

Contexte : Les rôles Ansible sont modifiés régulièrement sans validation automatisée. Le Problème : Des erreurs sont découvertes tardivement en production. Contraintes : Intégrer Molecule pour tester automatiquement les rôles dans un environnement isolé (Docker). Livrable attendu : Proposer une architecture de tests automatisés avec Molecule permettant la validation continue des rôles Ansible.

Contexte : Un projet Ansible historique contient des playbooks volumineux non structurés et difficilement maintenables. Le Problème : Les équipes ont du mal à réutiliser les composants et les modifications introduisent régulièrement des régressions. Contraintes : Refactoriser vers des rôles modulaires versionnés, compatibles avec Ansible Galaxy interne. Livrable attendu : Décrire une stratégie de migration vers une architecture modulaire réutilisable avec versionnement clair des rôles.