352 labs à rejouer chez vous, notés sur l'état réel de la machine et non sur les commandes tapées. Ils préparent 8 certifications, du RHCSA au CKS, et représentent environ 220 heures de pratique. Tout est gratuit et sans compte : les catalogues sont des dépôts publics, et la correction tourne sur votre machine.
Le champ de recherche accepte une commande, une
compétence ou un sigle de certification :
taper selinux ou CKA réduit la liste à ce qui vous
concerne. Chaque lab renvoie vers le guide qui enseigne la
compétence qu'il mesure.
Trois commandes pour jouer n'importe lequel
- Installez la CLI, puis ajoutez le catalogue du lab
qui vous intéresse. La commande exacte figure en tête de chaque
catalogue ci-dessous.
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training - Vérifiez votre machine. Cette commande annonce ce qui
manque, mémoire ou hyperviseur, avant que Terraform n'échoue.
dsoxlab doctor - Lancez le lab par son identifiant, celui qui
accompagne chaque ligne du catalogue.
startprépare l'environnement et ouvre une session dedans ;checklance les tests et calcule la note.dsoxlab start l1-first-terminaldsoxlab check l1-first-terminal
Installer dsoxlab Dimensionner sa machine Toutes les commandes
- 352labs
- 5catalogues
- 8certifications
- 220heures de pratique
Linux, RHCSA et LFCS
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training
Fondamentaux
-
Premiers pas dans le terminal
Exécutez les commandes de base (whoami, pwd, hostname, date) et capturez leur sortie dans un fichier.
dsoxlab start l1-first-terminal -
Cartographier Linux : noyau, distribution et répertoires clés
Explorez les composants de Linux en exécutant de vraies commandes sur votre propre système : identifiez le noyau, votre distribution et le rôle de /etc, /var/log et /proc. Remplissez une carte des notions.
dsoxlab start l1-discover-linux-map -
Choisir sa distribution Linux de référence
Comparez Debian/Ubuntu et les distributions RHEL, comprenez les critères de choix, et documentez votre choix pour trois scénarios concrets.
dsoxlab start l1-choose-distro -
Identifier sa machine Linux
Exécutez des commandes pour collecter le nom d'hôte, la distribution, la version du noyau et l'adresse IP de votre système. Produisez une fiche d'identité machine dans vm-info.txt.
dsoxlab start l1-prepare-vm -
Lire et décoder une commande
Décomposez 5 commandes Linux en parties commande/options/arguments et corrigez 3 commandes cassées.
dsoxlab start l1-read-a-command -
Obtenir de l'aide en ligne de commande
Utilisez man, --help et apropos pour trouver les bonnes options sans chercher sur le web.
dsoxlab start l1-get-help -
Hiérarchie du système de fichiers Linux (FHS)
Associez les répertoires Linux standard à leur rôle et classifiez des fichiers par emplacement.
dsoxlab start l1-linux-filesystem -
Naviguer dans le système de fichiers
Utilisez cd, ls, mkdir, cp, mv, rm pour construire une arborescence cible de zéro.
dsoxlab start l1-navigate-filesystem -
Chemins absolus et relatifs
Copiez un fichier avec un chemin absolu et avec un chemin relatif, puis résolvez 5 puzzles de navigation.
dsoxlab start l1-paths-absolute-relative -
Rediriger les flux et chaîner des commandes avec des pipes
Redirige la sortie standard et la sortie d'erreur, fusionne-les, et enchaîne des commandes avec des pipes pour produire des artefacts exacts.
dsoxlab start l1-redirections-pipes -
Filtrer un journal avec grep et les expressions régulières
Utilise grep avec ancres, classes de caractères, invert-match et comptage pour extraire des faits précis d'un journal d'accès.
dsoxlab start l1-grep-regex -
Transformer et agréger du texte avec cut, sort, uniq, sed et awk
Découper des colonnes, dédoublonner, compter, sommer un champ et réécrire un séparateur pour transformer un fichier brut en faits précis.
dsoxlab start l1-text-processing -
Localiser des fichiers avec find par nom, taille et permissions
Extraire une arborescence de projet et utiliser find pour lister les fichiers par motif de nom, par taille et par permissions exactes , en produisant les résultats dans des fichiers vérifiés contre l'arbre réel.
dsoxlab start l1-find-files -
Archiver, compresser et extraire sélectivement avec tar, gzip et bzip2
Créer des archives gzip et bzip2, lister leur contenu et extraire un seul membre dans un répertoire cible.
dsoxlab start l1-tar-archives -
Poser les permissions exactes avec chmod (octal et symbolique)
Donner à chaque fichier les bons bits utilisateur/groupe/autres : un secret privé, un script exécutable, une note lisible par le groupe et un répertoire privé.
dsoxlab start l1-permissions-ugo -
Créer des liens physiques et symboliques et les distinguer
Faire un lien physique qui partage l'inode, un lien symbolique qui pointe par chemin, et un lien symbolique vers un répertoire , prouvés par inode, compteur de liens et cible.
dsoxlab start l1-links-hard-sym -
Écrire un premier script Bash : variables, boucle et condition
Écrire rapport.sh qui lit un fichier d'état passé en argument, compte les UP/DOWN avec une boucle, les affiche, et sort en erreur si un hôte est down.
dsoxlab start l1-bash-script -
Initialiser un dépôt Git : commit, historique et branche
Créer un dépôt, faire deux commits qui suivent de vrais fichiers, et ouvrir une branche feature , prouvé en inspectant l'état du dépôt lui-même.
dsoxlab start l1-git-basics -
Variables d'environnement : export, PATH et un fichier env sourcé
Écrire env.sh qui, une fois sourcé, exporte des variables, en réutilise une dans une autre, et ajoute un répertoire bin en tête de PATH , prouvé en le sourçant dans un sous-shell.
dsoxlab start l1-env-profiles -
Inspecter un certificat TLS avec openssl
Lire un certificat X.509 fourni : en extraire le sujet, les dates de validité, l'empreinte SHA-256 et la clé publique avec openssl x509.
dsoxlab start l1-ssl-certificates
Exploiter et maintenir
-
Ajouter et gérer le swap
Créer un swap file sécurisé, l'activer, le rendre persistant dans /etc/fstab et régler vm.swappiness.
dsoxlab start l2-swap-management -
Monter un filesystem de façon persistante par UUID dans /etc/fstab
Monter un disque additionnel déjà formaté sur /srv/data via /etc/fstab, référencé par UUID (pas par nom de périphérique) pour survivre à un reboot, et prouver la ligne avec mount -a ET findmnt --verify.
dsoxlab start l2-fstab-persist-uuid -
Créer des partitions GPT sur un disque avec parted
Poser une table GPT sur le disque supplémentaire et y découper deux partitions (512 Mio et 1 Gio), puis faire relire la table au noyau.
dsoxlab start l2-partition-gpt -
Créer et labelliser un filesystem XFS, puis le monter
Formater une partition préparée en XFS avec un label, créer un point de montage et le monter , prouvé par le type du filesystem, son label et le montage actif.
dsoxlab start l2-filesystem-create-xfs -
Diagnostiquer un filesystem plein et récupérer de l'espace
Un filesystem est plein. Trouve le coupable avec df/du, supprime le superflu sans effacer les données légitimes, et fais redescendre l'occupation.
dsoxlab start l2-disk-space-troubleshoot -
Optimiser un montage avec noatime (de façon persistante)
Un filesystem très sollicité en lecture gaspille des I/O à écrire les dates d'accès. Ajoute l'option noatime, rends-la active et persistante dans /etc/fstab.
dsoxlab start l2-storage-performance -
Étendre un volume logique et prouver que le montage survit au reboot
Étends un volume logique LVM, agrandis le filesystem XFS, et rends le montage persistant via /etc/fstab par UUID.
dsoxlab start l2-lvm-extend-persist -
Monter un export NFS de façon persistante depuis un serveur
Un second hôte exporte un partage NFS. Monte-le côté client sur /mnt/nfs, rends-le persistant dans /etc/fstab avec _netdev pour qu'il survive au reboot.
dsoxlab start l2-nfs-mount-persist -
Monter un filesystem à la demande avec autofs
Configurer autofs pour qu'accéder à /autofs/data monte automatiquement le disque supplémentaire, et le démonte après inactivité , une carte maître et une carte de montage.
dsoxlab start l2-autofs-ondemand -
Construire un RAID 1 logiciel avec mdadm
Assembler deux disques en un RAID 1 redondant avec mdadm, le formater, le monter et le rendre persistant.
dsoxlab start l2-raid-mdadm -
Chiffrer un disque avec LUKS
Chiffrer un périphérique bloc avec LUKS2, l'ouvrir, y poser un système de fichiers, le monter et le déverrouiller au boot via crypttab.
dsoxlab start l2-luks-encryption -
Créer un compte local avec UID, shell et groupes exacts
Intégrer un utilisateur avec un UID précis, un home, un shell de connexion, un groupe primaire et un groupe secondaire , l'exercice de création de compte RHCSA.
dsoxlab start l2-user-lifecycle -
Appliquer une politique d'expiration et de complexité des mots de passe
Régler l'expiration par compte avec chage, l'âge max par défaut du système dans login.defs, et une longueur minimale via pwquality.
dsoxlab start l2-password-policy -
Déléguer des droits sudo limités via un drop-in sudoers
Accorder au groupe operators un sudo sans mot de passe pour systemctl seulement, via un drop-in /etc/sudoers.d validé , moindre privilège, pas root complet.
dsoxlab start l2-sudo-delegation -
Accorder un accès fin avec les ACL POSIX
Aller au-delà d'ugo : donner à un utilisateur rw sur un fichier et à un groupe rx sur un répertoire, avec une ACL par défaut pour que les nouveaux fichiers en héritent , via setfacl/getfacl.
dsoxlab start l2-acl-posix -
Mettre en place un répertoire collaboratif avec le bit set-GID
Donner à un répertoire partagé le groupe devteam et le bit set-GID pour que les fichiers créés dedans héritent du groupe , prouvé par le mode du répertoire et un fichier créé par un membre.
dsoxlab start l2-collaborative-setgid -
Installer, supprimer et interroger des paquets avec dnf
Amener la machine à un état logiciel cible : installer un paquet nécessaire, retirer un paquet indésirable, et vérifier avec des requêtes dnf/rpm.
dsoxlab start l2-package-management -
Configurer un dépôt dnf avec un fichier .repo
Ajouter un dépôt logiciel sous /etc/yum.repos.d : un id, une baseurl, activé et vérifié GPG, puis confirmer que dnf le voit.
dsoxlab start l2-repo-configure
Services et dépannage
-
Régler la cible de démarrage systemd par défaut
Un serveur n'a rien à faire à démarrer en cible graphique. Règle le défaut sur multi-user.target et vérifie-le.
dsoxlab start l3-boot-target -
Ajouter un paramètre noyau persistant au démarrage
Ajouter un paramètre de ligne de commande noyau au noyau courant avec grubby et à /etc/default/grub pour les futurs noyaux, pour qu'il survive aux reboots et mises à jour , prouvé par grubby et la config grub.
dsoxlab start l3-grub-kernel-args -
Créer et activer un service systemd
Encapsuler un programme dans une unit .service systemd, le démarrer et l'activer au boot , prouvé par le service actif, activé et qui fait son travail.
dsoxlab start l3-service-create-unit -
Diagnostiquer et corriger un service systemd en crash loop
Un service systemd redémarre en boucle à cause d'un fichier de configuration manquant. Utilisez systemctl + journalctl pour trouver la cause racine et corriger durablement.
dsoxlab start l3-service-diagnose -
Rendre le journal systemd persistant au reboot
Par défaut les logs disparaissent au reboot. Active le stockage persistant de journald pour que /var/log/journal garde l'historique , prouvé par la config, le répertoire et un vrai fichier journal.
dsoxlab start l3-journald-persist -
Planifier une tâche récurrente avec cron
Lancer /usr/local/bin/report.sh chaque jour à 02:30 via une entrée cron , prouvé par la planification réelle qu'honorera le démon cron.
dsoxlab start l3-scheduling-cron -
Planifier une tâche ponctuelle avec at
Mettre en file une commande à exécuter une seule fois plus tard avec at, et prouver qu'elle est planifiée , le pendant ponctuel de cron.
dsoxlab start l3-scheduling-at -
Planifier une tâche récurrente avec un timer systemd
Créer un .service et son .timer (OnCalendar), l'activer, et prouver qu'il est actif et persistant , la façon systemd de planifier du travail récurrent.
dsoxlab start l3-scheduling-timers -
Régler les limites de ressources par utilisateur (fichiers ouverts) avec limits.d
Donner au compte appuser une limite de fichiers ouverts plus haute via /etc/security/limits.d , prouvé par le ulimit effectif dans une vraie session de login.
dsoxlab start l3-app-constraints -
Durcir des paramètres noyau durablement avec sysctl.d
Désactiver le routage IP et les redirections ICMP via /etc/sysctl.d, appliqué maintenant et persistant au reboot , prouvé par les valeurs sysctl actives.
dsoxlab start l3-sysctl-persist -
Abaisser la priorité d'ordonnancement d'un service avec Nice
Un worker batch monopolise le CPU. Donne à son service un nice de 10 pour qu'il cède la main au travail interactif , prouvé par la priorité live du processus et la config de l'unit.
dsoxlab start l3-process-signals-priority -
Appliquer un profil de performance tuned
Basculer le profil tuned actif sur throughput-performance et le rendre durable , prouvé par le profil actif que rapporte le démon tuned.
dsoxlab start l3-tuned-profile -
Récupérer un montage en lecture seule dû à un fstab cassé
Une mauvaise option dans /etc/fstab a laissé /srv/data monté en lecture seule. Corrige l'entrée, remonte en lecture-écriture, et rends mount -a de nouveau propre.
dsoxlab start l3-fs-readonly-recover -
Réparer une config sshd cassée avant qu'elle ne te verrouille dehors
Un drop-in a laissé une directive invalide : sshd -t échoue, donc le prochain reload ou reboot couperait l'accès distant. Corrige la config, garde le login root désactivé, et recharge proprement.
dsoxlab start l3-ssh-access-recovery
Réseau, sécurité et conteneurs
-
Synchroniser l'horloge avec chrony et fixer le fuseau, durablement
Activer et démarrer chronyd, activer le NTP et régler le fuseau sur Europe/Paris, de façon persistante au reboot, prouvé par l'état actif du service et timedatectl.
dsoxlab start l4-ntp-sync -
Configurer une IPv4 statique persistante avec NetworkManager
Créer une connexion NetworkManager avec une IPv4 statique (méthode manual) qui survit au reboot , prouvé par le profil sur disque et l'adresse active.
dsoxlab start l4-network-static-persist -
Diagnostiquer et rétablir une connexion réseau tombée
Une connexion NetworkManager est configurée mais reste inactive et ne démarre pas automatiquement. Diagnostique-la, active-la, et rends-la auto-connectable , prouvé par l'état actif et le drapeau autoconnect.
dsoxlab start l4-network-troubleshoot -
Ouvrir un service firewalld de façon permanente
Autoriser le service http à travers firewalld pour que ça tienne maintenant et après reload/reboot , prouvé par les listes de services runtime et permanent, sans jamais fermer ssh.
dsoxlab start l4-firewall-persist -
Mettre en place un accès SSH par clé durci pour un utilisateur de service
Donner à l'utilisateur deploy un accès SSH par clé avec le bon propriétaire et les bonnes permissions (.ssh 700, authorized_keys 600, appartenant à l'utilisateur) , le piège classique qui casse silencieusement l'auth par clé.
dsoxlab start l4-ssh-key-auth-harden -
Lancer un conteneur détaché avec Podman
Récupérer une image et lancer un conteneur nommé en détaché, et prouver qu'il tourne , les bases de Podman pour les conteneurs RHCSA.
dsoxlab start l4-podman-basic -
Faire tourner un conteneur en service systemd avec Quadlet (persistant au boot)
Définir une unité Quadlet .container pour qu'un conteneur démarre au boot sous systemd , prouvé par le service actif, le conteneur qui tourne et l'unité sur disque.
dsoxlab start l4-podman-systemd-persist -
Gérer les images de conteneurs : pull, tag, save et inspection
Récupérer une image depuis un registre, l'étiqueter, la sauvegarder dans une archive et inspecter cette archive avec skopeo , les compétences de gestion d'images pour les conteneurs RHCSA.
dsoxlab start l4-podman-images -
Autoriser un service avec SELinux : booléen persistant et port étiqueté
Activer un booléen SELinux de façon persistante et étiqueter un port non standard pour qu'un service soit autorisé sous SELinux enforcing , prouvé par getsebool et semanage port.
dsoxlab start l4-selinux-boolean-port -
Corriger le contexte SELinux d'un fichier, durablement
Donner à un répertoire web personnalisé le type httpd_sys_content_t avec semanage fcontext + restorecon pour que ça survive à un relabel/reboot , prouvé par ls -Z et la règle fcontext.
dsoxlab start l4-selinux-context-fix -
Diagnostiquer un refus SELinux (AVC) et le corriger proprement
Un fichier web a le mauvais label SELinux, donc httpd est refusé (403). Lis l'AVC dans le journal d'audit et restaure le contexte , sans désactiver SELinux. Prouvé par le contexte actif et une réponse 200.
dsoxlab start l4-selinux-diagnose-avc -
Mettre en place une redirection de port NAT persistante avec nftables
Activer le routage IP et ajouter une table nat nftables (DNAT redirection de port + masquerade) qui survit au reboot , prouvé par le ruleset actif, sysctl et les fichiers de persistance.
dsoxlab start l4-nat-portforward -
Authentifier Linux sur un annuaire LDAP avec SSSD
Configurer SSSD sur le client pour qu'un utilisateur de l'annuaire (alice) soit résolu et puisse se connecter, contre un 389 Directory Server , prouvé par getent, id et le profil authselect actif.
dsoxlab start l4-ldap-integration -
Répartir la charge d'un backend web avec HAProxy
Configurer HAProxy sur l'hôte frontal pour faire reverse-proxy et répartir la charge vers un serveur web backend, de façon persistante , prouvé par une requête à travers le proxy qui renvoie la page du backend.
dsoxlab start l4-reverse-proxy-lb -
Agréger des liens : un bond active-backup sous un bridge avec nmcli
Construire un bond active-backup sur deux interfaces esclaves et poser un bridge par-dessus, de façon persistante avec NetworkManager , prouvé par l'état du bonding et le port du bridge.
dsoxlab start l4-bridge-bonding
Variantes Debian et Ubuntu
-
Gérer les paquets Debian avec apt et dpkg
Installer un paquet avec apt, le figer avec un hold pour que les mises à jour l'ignorent, et identifier quel paquet possède un fichier , les compétences de gestion de paquets Debian pour LFCS.
dsoxlab start lfcs-package-apt -
Ouvrir un service dans le pare-feu avec ufw
Autoriser le service http et activer ufw pour qu'il filtre au boot, sans jamais couper SSH , le pendant Debian de firewalld, prouvé par ufw status.
dsoxlab start lfcs-firewall-ufw -
Gérer un profil AppArmor : le passer en mode complain
Passer un profil AppArmor chargé en mode complain (apprentissage) avec aa-complain et le prouver avec aa-status , le pendant Debian du contrôle d'accès obligatoire de SELinux.
dsoxlab start lfcs-apparmor -
Configurer une IP statique et une route avec netplan
Déclarer une adresse IPv4 statique et une route statique dans un fichier netplan et l'appliquer sur une interface dédiée , la configuration réseau Debian/Ubuntu, prouvée par l'adresse et la route actives.
dsoxlab start lfcs-netplan-static -
Activer les quotas utilisateur XFS et imposer une limite
Formater un disque dédié en XFS, le monter avec les quotas utilisateur activés de façon persistante, et imposer un quota de blocs à un utilisateur , prouvé par l'état des quotas et la limite appliquée.
dsoxlab start lfcs-storage-quotas -
Monter un partage SMB/CIFS de façon persistante et sûre
Un second hôte sert un partage SMB. Monte-le sur le client, rends-le persistant dans /etc/fstab avec _netdev, et garde le mot de passe hors du fstab lisible par tous grâce à un fichier credentials en 0600.
dsoxlab start lfcs-mount-cifs
Épreuves en conditions d'examen
-
Drill , commandes essentielles en conditions d'examen
5 tâches, 100 points, 20 minutes, aucun indice : chercher par taille, bâtir un rapport de fréquence, créer des liens, corriger propriétaire et permissions, et séparer stdout de stderr. Jouable sur RHEL ou Debian , ces compétences sont identiques.
dsoxlab start drill-essential-commands -
Drill , utilisateurs, groupes et délégation en conditions d'examen
5 tâches, 100 points, 20 minutes, aucun indice : créer un compte aux specs exactes, imposer le vieillissement du mot de passe, monter un répertoire collaboratif, déléguer sudo au plus juste, et verrouiller un compte qui part. Jouable sur RHEL ou Debian , la gestion des comptes est identique.
dsoxlab start drill-users-groups -
Drill , unités systemd, timers et planification en conditions d'examen
5 tâches, 100 points, 25 minutes, aucun indice : écrire une unité de service avec politique de redémarrage, planifier un timer hebdomadaire, ajouter une tâche cron, corriger la cible de démarrage, et masquer un service pour de bon. Jouable sur RHEL ou Debian , systemd est systemd.
dsoxlab start drill-systemd -
Drill , partitions, LVM et swap en conditions d'examen
5 tâches, 100 points, 25 minutes, aucun indice : partitionner un disque en GPT, monter une pile LVM, monter par UUID de façon persistante, ajouter du swap, et étendre un volume logique à chaud. Jouable sur RHEL ou Debian , parted, LVM et XFS sont identiques.
dsoxlab start drill-storage -
Drill , gestion des paquets en conditions d'examen
5 tâches, 100 points, 20 minutes, aucun indice : installer un paquet, le geler contre les mises à jour, trouver quel paquet fournit un fichier, lister ce qu'un paquet a installé, et en supprimer un. L'objectif est commun à RHCSA et LFCS , seul l'outil change (dnf ou apt), et tu emploies celui de ta distribution.
dsoxlab start drill-packages -
Drill , pare-feu en conditions d'examen
5 tâches, 100 points, 20 minutes, aucun indice : activer le pare-feu, ouvrir deux ports qui survivent à un rechargement, garder SSH vivant, et rejeter explicitement un port. L'objectif est commun à RHCSA et LFCS , seul l'outil change (firewalld ou ufw).
dsoxlab start drill-firewall -
Drill , SELinux en conditions d'examen
4 tâches, 100 points, 20 minutes, aucun indice : remettre SELinux en enforcing pour de bon, corriger un contexte de fichier qui survit à une relabellisation, basculer un booléen de façon persistante, et étiqueter un port non standard. RHCSA uniquement , Debian utilise AppArmor, voir drill-apparmor.
dsoxlab start drill-selinux -
Drill , AppArmor en conditions d'examen
4 tâches, 100 points, 15 minutes, aucun indice : confirmer qu'AppArmor tourne, mettre un profil en mode plainte, et ramener deux autres en mode application. LFCS uniquement , RHEL utilise SELinux, voir drill-selinux.
dsoxlab start drill-apparmor -
Drill , réseau statique en conditions d'examen
4 tâches, 100 points, 20 minutes, aucun indice : une adresse statique, une route statique et un MTU sur une interface dédiée, plus la résolution de noms locale. L'objectif est commun à RHCSA et LFCS , seul l'outil change (nmcli ou netplan).
dsoxlab start drill-network
Épreuves de synthèse
-
Mettre un serveur en production : une mission, neuf livrables, un redémarrage
Une VM neuve, une application livrée, et une mission : la mettre en service. Stockage sur LVM, compte de service, application sur le port 8080, étiquette de port et contexte SELinux, règle de pare-feu permanente, journal persistant, SSH durci, sauvegarde planifiée. Rien n'est noté sur les commandes tapées : chaque test lit un état observable, et le dernier redémarre la machine avant de regarder une seconde fois. Ce qui ne survit pas au redémarrage vaut zéro.
dsoxlab start capstone-mise-en-production -
Serveur cassé : le site ne répond plus, le symptôme ne dit rien
Un site interne qui marchait cesse de répondre. Le setup injecte UNE panne parmi six, tirée au sort, et ne dit jamais laquelle : service arrêté, mauvais port, pare-feu fermé, contexte SELinux, permissions du docroot, système de fichiers plein. Vous diagnostiquez, vous réparez, et la réparation doit survivre à un redémarrage. La notation porte uniquement sur l'état observable, avec trois contrôles qui refusent les réparations à la masse : SELinux doit rester enforcing, firewalld doit rester actif, et le docroot ne doit pas devenir accessible en écriture à tous.
dsoxlab start capstone-serveur-casse -
Examen blanc RHCSA EX200 , 20 tâches sur 2 VMs
Examen blanc RHCSA performance-based couvrant les 10 domaines RHCSA : stockage (LVM, swap, client NFS), script shell, réseau (IP statique, firewalld), utilisateurs/groupes, ACL, services (units systemd, timers, client de temps), SELinux (modes, contextes, booléens, ports), logiciel (DNF, Flatpak), boot recovery (rd.break reset root). 20 tâches notées sur 100 points réparties sur 2 VMs (serveur + client). 70/100 pour réussir. Aucun indice.
dsoxlab start rhcsa-mock-exam -
Examen blanc LFCS , 17 tâches sur Ubuntu 24.04
Examen blanc LFCS orienté performance, confronté tâche par tâche aux objectifs publiés des 5 domaines officiels : Essential Commands (20 % : Git, dépannage de service, espace disque, SSL), Operations Deployment (25 %), Users and Groups (10 % : comptes et ACL), Networking (25 %), Storage (20 % : LVM, automontage, swap). 17 tâches notées sur 100 points sur une seule VM Ubuntu. 70/100 pour réussir. Aucun indice.
dsoxlab start lfcs-mock-exam
Ansible et la RHCE EX294
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/ansible-training
Préparer l'environnement
-
Préparer les managed nodes Ansible
Converger les 5 prérequis d'un managed node (Python 3, SSH, sudo NOPASSWD, chrony, SELinux) via un playbook de bootstrap idempotent.
dsoxlab start bootstrap-prepare-managed-nodes
Découvrir Ansible
-
Déclaratif vs impératif : pourquoi Ansible ne dérive pas
Comparer un script Bash qui dérive à chaque run et un playbook qui converge, puis prouver l'idempotence par le changed=0 du second passage.
dsoxlab start decouvrir-declaratif-vs-imperatif -
Installation d'Ansible : vérifier son poste de contrôle
Identifier sa méthode d'installation, vérifier les 8 binaires du PATH, les modules accessibles via ansible-doc et les collections du dépôt.
dsoxlab start decouvrir-installation-ansible -
ansible.cfg : précédence et options critiques
Écrire un ansible.cfg projet, vérifier la config active avec ansible-config dump, surcharger par variable d'environnement et activer un callback.
dsoxlab start decouvrir-configuration-ansible -
CLI Ansible : les 8 commandes du quotidien
Enchaîner ad-hoc, ansible-doc, ansible-config, ansible-inventory, ansible-galaxy, ansible-vault et ansible-lint sur le lab.
dsoxlab start decouvrir-prise-en-main-cli
Premiers pas
-
Premier playbook : installer nginx sur les webservers
Écrire un playbook de 5 tâches (dnf, systemd, firewalld), lire le PLAY RECAP, capturer une sortie avec register et vérifier l'idempotence.
dsoxlab start premiers-pas-premier-playbook -
Premiers pas avec ansible-vault
Chiffrer un fichier de secrets avec ansible-vault, le consommer via vars_files et protéger la sortie avec no_log et un .vault_password en 0600.
dsoxlab start premiers-pas-ansible-vault
Écrire du code Ansible
-
Plays et tasks : anatomie et ordre d'exécution
Structurer un play avec pre_tasks, tasks, post_tasks et handlers, puis prouver l'ordre d'exécution réel par des fichiers marqueurs horodatés.
dsoxlab start ecrire-code-plays-et-tasks -
Handlers : le pattern restart-on-config-change
Notifier plusieurs handlers, les découpler avec listen, forcer meta: flush_handlers et combiner validate pour ne jamais appliquer une config invalide.
dsoxlab start ecrire-code-handlers -
Tags : cibler ou ignorer un sous-ensemble de tâches
Poser des tags, cibler avec --tags et exclure avec --skip-tags, inspecter le plan via --list-tasks et exploiter les tags spéciaux always et never.
dsoxlab start ecrire-code-tags -
Check mode et diff : dry-run et visualisation
Lancer un playbook en --check --diff, repérer les modules non compatibles, forcer check_mode: false et diagnostiquer un faux positif changed.
dsoxlab start ecrire-code-checkmode-diff -
Variables : déclaration et portées
Déclarer des variables via vars et vars_files, les surcharger avec --extra-vars et diagnostiquer une valeur inattendue liée au typage YAML.
dsoxlab start ecrire-code-variables-base -
Types collections : listes, dicts, structures imbriquées
Déclarer listes et listes de dicts en YAML, boucler dessus avec loop_control: label, filtrer par when et accéder aux champs imbriqués.
dsoxlab start ecrire-code-types-collections -
Facts et magic vars : ansible_facts, hostvars
Lire les facts système, exploiter inventory_hostname, groups et hostvars, puis réduire le coût de collecte avec gather_subset.
dsoxlab start ecrire-code-facts-magic-vars -
Custom facts : facts.d et ansible_local
Déposer un custom fact INI puis un script exécutable retournant du JSON dans /etc/ansible/facts.d, et les lire via ansible_local.
dsoxlab start ecrire-code-custom-facts -
Précédence des variables : les 22 niveaux
Superposer la même variable à plusieurs niveaux pour démontrer lequel gagne, du role defaults jusqu'à --extra-vars.
dsoxlab start ecrire-code-precedence-variables -
register et set_fact : capturer et créer des variables
Capturer la sortie d'un module avec register, la réutiliser dans when et loop, créer un fact au runtime et le persister avec cacheable: true.
dsoxlab start ecrire-code-register-set-fact -
Parallélisme : forks, serial, throttle, strategy
Distinguer forks de serial, jouer un rolling update en serial: 1, comparer les stratégies linear et free et limiter une tâche avec throttle.
dsoxlab start ecrire-code-parallelisme-strategies -
Async et poll : tâches longues sans bloquer SSH
Détacher une tâche longue en async + poll: 0, récupérer son résultat via async_status, faire du polling actif et diagnostiquer un job orphelin.
dsoxlab start ecrire-code-async-poll -
Délégation : delegate_to, run_once, local_action
Rediriger une tâche vers un autre hôte, ne l'exécuter qu'une fois dans un play multi-hôtes et cibler le control node avec local_action.
dsoxlab start ecrire-code-delegation -
Lookups : récupérer des données externes
Lire un fichier, une variable d'environnement ou la sortie d'une commande côté control node, générer un mot de passe et distinguer lookup de query.
dsoxlab start ecrire-code-lookups -
Jinja2 : interpolation, logique et whitespace
Interpoler des variables, boucler et conditionner dans un template, puis supprimer les sauts de ligne parasites par le whitespace control.
dsoxlab start ecrire-code-jinja2-base -
Filtres Jinja2 essentiels : default, combine, selectattr
Gérer les variables absentes avec default, manipuler des listes, filtrer une liste de dicts avec selectattr et map, fusionner des dicts avec combine.
dsoxlab start ecrire-code-filtres-jinja-essentiels -
Conditions when : opérateurs et tests Jinja
Conditionner une tâche sur un fact, combiner plusieurs conditions, tester la définition d'une variable et diagnostiquer un when qui matche faux.
dsoxlab start ecrire-code-conditions-when -
Boucles loop : itérer sur listes et dicts
Boucler sur une liste et une liste de dicts, rendre la sortie lisible avec loop_control: label, itérer sur un dict via dict2items.
dsoxlab start ecrire-code-boucles-loop -
Boucles legacy with_* : migrer vers loop
Reconnaître with_items, with_dict et with_subelements, les migrer vers loop plus filtres Jinja2 et automatiser avec ansible-lint --fix.
dsoxlab start ecrire-code-boucles-with-deprecated -
block, rescue, always : try/catch/finally
Grouper des tâches dans un block, capturer l'erreur avec rescue pour rollback, garantir le nettoyage avec always et lire ansible_failed_task.
dsoxlab start ecrire-code-block-rescue-always -
failed_when et changed_when : redéfinir succès et changement
Neutraliser le changed des commandes lecture-seule, définir changed_when sur la sortie et accepter certains codes retour comme succès.
dsoxlab start ecrire-code-failed-when-changed-when -
ignore_errors : usage légitime vs anti-pattern
Mesurer l'effet d'ignore_errors sur le PLAY RECAP, identifier ses rares cas légitimes et lui préférer failed_when ou block/rescue.
dsoxlab start ecrire-code-ignore-errors -
any_errors_fatal : arrêter le play à la première erreur
Activer any_errors_fatal sur un play multi-hôtes, le comparer au défaut et à max_fail_percentage, et le combiner avec serial.
dsoxlab start ecrire-code-any-errors-fatal -
Filtres Jinja2 avancés : regex, b64, password_hash
Extraire avec regex_search, encoder en base64, hacher un mot de passe en sha512, interroger un JSON avec json_query et manipuler des CIDR.
dsoxlab start ecrire-code-filtres-jinja-avances -
Tests Jinja2 : is defined, is mapping, is sequence
Tester la définition et le type d'une variable, matcher une regex avec is match et is search, et combiner ces tests dans when et {% if %}.
dsoxlab start ecrire-code-tests-jinja -
Module template : validate, backup, whitespace
Générer une config depuis un template Jinja2, rejeter une syntaxe invalide avec validate, sauvegarder l'ancienne et poser mode, owner et group.
dsoxlab start ecrire-code-module-template -
lineinfile vs template : quand utiliser quoi
Arbitrer entre lineinfile, blockinfile et template, les combiner (base plus overrides) et diagnostiquer un lineinfile qui empile faute de regexp.
dsoxlab start ecrire-code-lineinfile-vs-template -
Import vs include : statique ou dynamique
Choisir entre import_* parsé au démarrage et include_* résolu au runtime, et observer comment tags et when changent de comportement selon le cas.
dsoxlab start ecrire-code-import-include
Modules de fichiers
-
Module copy : transférer fichiers et contenu inline
Transférer un fichier avec src: ou écrire un contenu inline avec content:, en maîtrisant mode, owner, backup et validate.
dsoxlab start modules-fichiers-copy -
Module file : états, permissions et liens symboliques
Gérer l'état d'un fichier ou d'un répertoire (directory, absent, link, hard, touch), les permissions récursives et les liens symboliques.
dsoxlab start modules-fichiers-file -
Module blockinfile : bloc multi-lignes idempotent
Insérer et maintenir un bloc multi-lignes dans un fichier existant avec markers personnalisés, insertafter/insertbefore et idempotence.
dsoxlab start modules-fichiers-blockinfile -
Module lineinfile : modifier une ligne dans un fichier
Ajouter, remplacer par regexp ou supprimer une ligne d'un fichier de configuration, avec backrefs et validation de syntaxe avant écriture.
dsoxlab start modules-fichiers-lineinfile -
Module replace : remplacer un motif dans un fichier
Substituer un motif regex dans tout un fichier, borner la zone avec before/after et préserver une partie via groupes de capture.
dsoxlab start modules-fichiers-replace -
Module fetch : rapatrier des fichiers des managed nodes
Collecter logs et configurations des managed nodes vers le control node, en arborescence par hôte ou en mode flat avec inventory_hostname.
dsoxlab start modules-fichiers-fetch -
Modules archive et unarchive : compresser et extraire
Créer une archive tar.gz sur le managed node et extraire des tarballs locaux, distants ou déjà présents, de façon idempotente avec creates.
dsoxlab start modules-fichiers-archive-unarchive
Modules de paquets
-
Module package : installation agnostique multi-distro
Installer et désinstaller des paquets sans dépendre du gestionnaire de la distribution, en pesant state: present contre state: latest.
dsoxlab start modules-paquets-package -
Module dnf : enablerepo, security, exclude, autoremove
Activer un repo à la volée, patcher uniquement les CVE, exclure le kernel d'un upgrade massif et nettoyer les dépendances orphelines.
dsoxlab start modules-paquets-dnf-options -
Module yum_repository : déclarer un dépôt RPM
Déclarer un dépôt yum/dnf avec gpgcheck, importer sa clé GPG via rpm_key et désactiver un dépôt sans le supprimer.
dsoxlab start modules-paquets-yum-repository
Modules de services
-
Module systemd_service : gérer les services systemd
Démarrer, activer, recharger et masquer des services, déposer un unit file custom avec daemon_reload et notifier un service depuis un handler.
dsoxlab start modules-services-systemd -
Module cron : planifier des jobs idempotents
Planifier des jobs cron idempotents via crontab user ou /etc/cron.d, avec variables d'environnement et désactivation propre.
dsoxlab start modules-services-cron
Modules d'utilisateurs
-
Module user : créer, modifier et supprimer des comptes
Créer des comptes avec home, shell et groupes secondaires, hasher un mot de passe, forcer un UID et supprimer un compte avec son home.
dsoxlab start modules-utilisateurs-user -
Module group : gérer les groupes Linux
Créer des groupes avec GID forcé, distinguer groupe système et groupe utilisateur, et créer le groupe avant les utilisateurs qui le référencent.
dsoxlab start modules-utilisateurs-group -
Module authorized_key : clés SSH des utilisateurs
Provisionner des clés SSH publiques, forcer une liste exclusive, restreindre une clé avec key_options et traiter plusieurs users avec subelements.
dsoxlab start modules-utilisateurs-authorized-key -
Module sudoers : gérer les droits sudo sans risque
Créer des règles dans /etc/sudoers.d/ avec validation visudo, limiter les commandes autorisées et gérer nopassword sur un groupe.
dsoxlab start modules-utilisateurs-sudoers
Modules RHEL
-
Module firewalld : gérer le pare-feu RHEL
Autoriser services prédéfinis et ports custom par zone, avec le piège permanent + immediate et la recharge du pare-feu.
dsoxlab start modules-rhel-firewalld -
Module sysctl : paramètres kernel persistés
Modifier des paramètres kernel (ip_forward, tcp_syncookies, swappiness) avec application immédiate et persistance via /etc/sysctl.d/.
dsoxlab start modules-rhel-sysctl -
Module selinux : modes, booléens et contextes
Passer SELinux en enforcing, modifier un booléen avec persistance et poser un contexte custom avec sefcontext puis restorecon.
dsoxlab start modules-rhel-selinux -
Module mount : gérer fstab et les montages
Gérer les 5 états de mount, monter un loop device, poser des options noatime/nodev/nosuid et faire survivre un montage au reboot.
dsoxlab start modules-rhel-mount -
Module parted : créer une partition disque
Créer des partitions alignées en MBR ou GPT de façon idempotente, poser des flags (lvm, boot, esp) et inspecter la table existante.
dsoxlab start modules-rhel-parted -
Module filesystem : créer un système de fichiers
Formater des partitions en ext4 et xfs, choisir le bon fstype selon l'usage et forcer une recréation avec force: true.
dsoxlab start modules-rhel-filesystem -
LVM : chaîner lvg, lvol, filesystem et mount
Construire un PV, un VG et un LV sur un disque secondaire, le formater, le monter via fstab et l'étendre à chaud avec resizefs.
dsoxlab start modules-rhel-lvm-storage
Modules réseau
-
Module get_url : télécharger un fichier HTTP/HTTPS
Télécharger un fichier sur le managed node de façon idempotente, vérifier son intégrité par checksum sha256 et authentifier la requête.
dsoxlab start modules-reseau-get-url -
Module uri : appels API REST
Appeler une API REST en GET/POST avec body JSON, accepter plusieurs status_code et boucler un healthcheck avec until/retries.
dsoxlab start modules-reseau-uri
Modules de diagnostic
-
Module stat : inspecter fichiers et dossiers
Vérifier existence, type, taille, mode et checksum d'un fichier sans le modifier, pour piloter une logique conditionnelle.
dsoxlab start modules-diagnostic-stat -
Module find : recherche multi-fichiers
Rechercher des fichiers par glob, regex, âge, taille et type, puis enchaîner loop et file pour un cleanup ciblé et idempotent.
dsoxlab start modules-diagnostic-find -
Modules assert et fail : validation défensive
Valider les prérequis en début de play, personnaliser fail_msg et success_msg, et échouer explicitement sur une branche d'erreur.
dsoxlab start modules-diagnostic-assert-fail -
Modules wait_for et pause : synchronisation
Attendre l'ouverture ou la fermeture d'un port TCP, l'apparition d'un fichier ou d'une regex, et marquer une pause simple ou interactive.
dsoxlab start modules-diagnostic-wait-for-pause
Inventaires
-
Écrire un inventaire statique de zéro : groupes, enfants et variables de groupe
Rédiger un inventaire statique Ansible à la main : déclarer des groupes d'hôtes, un groupe parent avec enfants, et des variables de groupe, puis prouver l'inventaire résolu avec ansible-inventory et ansible -m ping.
dsoxlab start inventaires-statiques -
group_vars et host_vars : structurer les variables
Répartir les variables d'inventaire entre all, groupe et host, puis vérifier la valeur résolue avec ansible-inventory --host.
dsoxlab start inventaires-group-vars-host-vars -
Patterns d'hôtes : wildcards et opérateurs :, &, !
Cibler exactement les hôtes voulus avec --limit et les opérateurs union, intersection et exclusion, sans toucher au playbook.
dsoxlab start inventaires-patterns-hotes -
Inventaire dynamique KVM avec community.libvirt
Découvrir automatiquement les VMs libvirt via le plugin d'inventaire, créer des groupes Jinja et keyed_groups, sans inventaire manuel.
dsoxlab start inventaires-dynamique-kvm
Rôles
-
Créer son premier rôle avec ansible-galaxy role init
Générer la structure d'un rôle webserver, remplir tasks, defaults, handlers et meta, puis l'appeler depuis un playbook avec roles:.
dsoxlab start roles-creer-premier-role -
Variables d'un rôle : defaults/ vs vars/ et précédence
Répartir les variables entre defaults/ (surchargeables) et vars/ (internes), les brancher aux tâches et à un template Jinja2, puis vérifier la précédence.
dsoxlab start roles-variables-defaults-vars -
Handlers et meta d'un rôle : notify et galaxy_info
Écrire plusieurs handlers (service et non-service), les déclencher avec notify, arbitrer restarted vs reloaded, puis compléter meta/main.yml pour Galaxy.
dsoxlab start roles-handlers-meta -
argument_specs : valider les variables d'entrée d'un rôle
Écrire meta/argument_specs.yml pour typer, contraindre et documenter les variables d'entrée, puis observer le rejet automatique d'une entrée invalide.
dsoxlab start roles-argument-specs -
Consommer un rôle : roles:, import_role, include_role
Appeler un même rôle des trois façons possibles et choisir entre statique et dynamique, notamment quand un when: entre en jeu.
dsoxlab start roles-consommer-role -
Dépendances entre rôles via meta/main.yml
Chaîner des rôles avec dependencies:, leur passer des variables, maîtriser l'ordre d'exécution et éviter le piège du diamant avec allow_duplicates.
dsoxlab start roles-dependencies -
Rôles système RHEL : converger la synchronisation horaire avec timesync
Consommer un rôle éditeur de linux-system-roles : piloter chronyd sur db1.lab par les variables de timesync, sans écrire chrony.conf à la main.
dsoxlab start roles-system-roles
Tests avec Molecule
-
Molecule : anatomie d'un scénario de test
Lire un scénario molecule/default/ : molecule.yml, converge.yml, verify.yml, driver, plateformes, verifier, puis dérouler le cycle complet.
dsoxlab start molecule-introduction -
Molecule : enrichir un scénario au-delà du minimum
Ajouter prepare.yml et requirements.yml, personnaliser les instances via host_vars, définir une test_sequence avec idempotence, activer profile_tasks.
dsoxlab start molecule-installation-config -
Molecule : développer un rôle users par les tests
Écrire verify.yml et argument_specs.yml avant la moindre tâche, puis itérer converge jusqu'au vert et refactorer sans casser les tests.
dsoxlab start molecule-tdd-cycle -
Molecule : tester un rôle sur plusieurs distributions
Étendre la matrice Molecule à trois distributions, charger vars/<os_family>.yml et absorber les écarts de paquets et de chemins avec le module package.
dsoxlab start molecule-scenarios-multi-distro
Tests Python et lint
-
Molecule + testinfra : assertions Python sur un rôle
Basculer le verifier sur testinfra, écrire des assertions avec la fixture host, paramétrer les cas avec parametrize, et arbitrer face à verify.yml.
dsoxlab start tests-testinfra -
tox : tester un rôle sur plusieurs versions d'ansible-core
Écrire un tox.ini qui épingle une version d'ansible-core par environnement et lance molecule test sur toute la matrice en une commande.
dsoxlab start tests-tox-multiversion -
ansible-lint profil production avec pre-commit
Configurer .ansible-lint en profil production et un .yamllint strict, puis les câbler dans pre-commit avec un hook anti-fuite de secrets.
dsoxlab start tests-ansible-lint-production
Intégration continue
-
GitHub Actions : workflow CI pour un rôle
Écrire un workflow lint + molecule avec une matrice distros x versions d'ansible-core, cache pip, permissions minimales et persist-credentials désactivé.
dsoxlab start ci-github-actions -
GitLab CI : pipeline parallel:matrix pour un rôle
Écrire un .gitlab-ci.yml en stages lint, test et release, décliner la matrice avec parallel:matrix et réserver la publication Galaxy aux tags Git via rules:.
dsoxlab start ci-gitlab
Galaxy et publication
-
CLI ansible-galaxy : init, install, list, build, publish
Initialiser un rôle et une collection, installer depuis Galaxy ou Git, lister l'existant, builder un tarball et publier avec un token API.
dsoxlab start galaxy-ansible-galaxy-cli -
Installer rôles et collections depuis Galaxy ou Git
Écrire un requirements.yml mêlant rôles Galaxy, sources Git et collections, épingler chaque version et vendoriser un rôle pour un projet reproductible.
dsoxlab start galaxy-installer-roles -
Auditer un rôle Galaxy avant de l'adopter
Noter un rôle tiers sur six axes (mainteneur, qualité, sécurité, tests), repérer les anti-patterns et trancher : adopter, forker ou refuser.
dsoxlab start galaxy-auditer-role-existant -
Versionner et publier un rôle : semver, tags Git, Galaxy
Appliquer le semver à un rôle, tenir un CHANGELOG.md, poser un tag Git annoté et automatiser la publication Galaxy depuis la CI.
dsoxlab start galaxy-versionner-publier
Ansible Vault
-
Ansible Vault : chiffrer un premier fichier de secrets
Chiffrer un fichier YAML avec ansible-vault, le consulter, l'éditer, le consommer dans un playbook, puis le rekey et le déchiffrer.
dsoxlab start vault-introduction -
encrypt_string ou chiffrement du fichier entier
Chiffrer une valeur isolée avec encrypt_string, la mêler à des variables en clair via le tag !vault, et arbitrer entre inline et fichier complet.
dsoxlab start vault-chiffrer-fichier-variable -
Vault-ids multiples : isoler dev, staging et prod
Chiffrer chaque environnement avec un vault-id étiqueté, déchiffrer plusieurs vault-ids dans un même run et organiser les group_vars par environnement.
dsoxlab start vault-id-multiples -
Playbooks mixtes : main.yml et vault.yml par groupe
Séparer variables publiques et secrets dans chaque group_vars, adopter la convention vault_*, et vérifier qu'Ansible fusionne les deux fichiers sans effort.
dsoxlab start vault-playbooks-mixtes -
Vault dans un rôle : defaults en clair, vars chiffré
Exposer dans defaults/main.yml des variables publiques qui pointent vers des vault_* d'un vars/main.yml chiffré, et les surcharger depuis le playbook.
dsoxlab start vault-dans-roles -
Récupérer des secrets depuis HashiCorp Vault ou OpenBao
Démarrer un Vault local, y stocker un secret, le lire depuis Ansible avec community.hashi_vault, et comparer les auth token, AppRole et JWT.
dsoxlab start vault-integration-hashicorp -
Récupérer des secrets depuis Passbolt
Démarrer un Passbolt CE local, l'authentifier par clé OpenPGP, lire un secret depuis Ansible et comparer le modèle Passbolt à HashiCorp Vault.
dsoxlab start vault-integration-passbolt
Execution Environments
-
Premier playbook dans un Execution Environment
Tirer une image EE avec Podman, la déclarer par défaut dans ansible-navigator.yml, y lancer un playbook et comparer avec un ansible-playbook classique.
dsoxlab start ee-hello -
Inspecter un Execution Environment et choisir le bon
Lister le contenu d'un EE avec ansible-navigator, comparer community-ansible-dev-tools, awx-ee et community-ee-minimal, puis choisir selon le cas d'usage.
dsoxlab start ee-inspection -
Construire un EE sur mesure avec ansible-builder v3
Écrire un execution-environment.yml v3, épingler ansible-core et les dépendances, builder avec Podman, tester l'image et la pousser sur un registre.
dsoxlab start ee-builder-custom -
Pipeline CI/CD pour Execution Environments
Builder un EE en CI, le scanner avec Trivy en mode bloquant, le signer avec cosign keyless et le publier, actions épinglées par SHA et permissions minimales.
dsoxlab start ee-ci-pipeline -
Déboguer un Execution Environment cassé
Diagnostiquer un EE qui build sans erreur mais reste vide : version de schéma oubliée, collection ou version PyPI inexistante, puis corriger et vérifier.
dsoxlab start ee-debug
Dépannage
-
Niveaux de verbosité et callback plugins
Choisir le niveau -v adapté au symptôme, activer profile_tasks et la sortie YAML (callback_result_format), et constater ce qu'un no_log manquant laisse fuiter.
dsoxlab start troubleshooting-verbosite -
Débogueur interactif : debugger: on_failed
Activer le débogueur sur échec, inspecter task, task_vars et result dans le REPL, corriger les arguments à chaud puis rejouer la tâche avec redo.
dsoxlab start troubleshooting-debugger -
Réparer l'idempotence cassée et optimiser les performances
Rendre idempotent un shell avec creates ou changed_when, mesurer un baseline avec profile_tasks, puis activer pipelining, forks et ControlPersist.
dsoxlab start troubleshooting-idempotence-perfs
Collections
-
Explorer les collections Ansible : FQCN et structure
Lister et inspecter les collections installées, lire un galaxy.yml, parcourir la structure plugins/roles/playbooks et retrouver un module par son FQCN.
dsoxlab start collections-decouvrir -
Automation content navigator : découvrir un module dans une collection et l'utiliser
Utiliser ansible-navigator pour trouver un module dans une collection installée, l'appliquer pour produire un état kernel vérifiable sur db1.lab, puis valider un inventaire avec ansible-navigator inventory.
dsoxlab start collections-navigator -
requirements.yml multi-sources et signatures GPG
Déclarer quatre sources dans un requirements.yml, épingler chaque version, vérifier l'intégrité et cibler plusieurs serveurs Galaxy.
dsoxlab start collections-requirements -
Construire sa propre collection avec un module Python custom
Initialiser une collection, renseigner galaxy.yml et meta/runtime.yml, y ajouter un rôle et un module Python documenté, puis builder le tarball.
dsoxlab start collections-creer-custom -
Matrice CI pour une collection : ansible-core x Python
Croiser les versions d'ansible-core et de Python dans une matrice, lancer ansible-test sanity et units en conteneur, épingler les actions par SHA.
dsoxlab start collections-ci-tests -
Migrer un rôle standalone vers une collection
Déplacer un rôle et son module custom dans une collection, configurer plugin_routing.redirect, et vérifier que l'ancien nom marche avec un warning.
dsoxlab start collections-migration-role
Pratiques avancées
-
Versionner ses playbooks avec Git
Initialiser un dépôt Git pour ses playbooks, les suivre et les committer, puis les pousser vers un dépôt bare local : le geste exact attendu à l'EX294, sans forge à monter.
dsoxlab start pratiques-versionner-git -
ansible-pull : pattern GitOps et Edge
Lancer ansible-pull contre un dépôt Git, le planifier par cron ou timer systemd, l'amorcer via cloud-init, puis arbitrer push ou pull selon le cas d'usage.
dsoxlab start pratiques-ansible-pull-gitops
Examen RHCE EX294
-
Examen blanc RHCE EX294 : 18 tâches en 4 heures
Traiter sous chrono 18 tâches couvrant inventaires, variables, vault, fichiers, paquets, services, rôles, gestion d'erreur, déploiement par vagues, délégation, tags, tâches planifiées et facts personnalisés, chacune validée par pytest.
dsoxlab start rhce-mock-ex294 -
Examen blanc RHCE EX294 #2
Un second examen blanc EX294 complet et chronométré : les 19 mêmes catégories que le mock #1, mais toutes les valeurs concrètes changent (pile Apache/valkey, autres utilisateurs, autre découpage LVM, autres ports, autre booléen SELinux, autre horaire de cron, autre collection). Rien ne se recopie de mémoire. Chaque tâche est prouvée par pytest.
dsoxlab start rhce-mock-ex294-2
Terraform, Associate et Professional
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/terraform-dsoxlab-training
Découvrir Terraform
-
Prouver que Terraform a une mémoire
Un débutant croit que Terraform relit ses fichiers `.tf` et interroge l'infrastructure à chaque commande, le state n'étant qu'un cache accessoire. Démontez cette idée sur une configuration purement locale : prouvez qu'une seconde application ne change rien, qu'une dérive provoquée hors de Terraform est détectée sans perdre l'identité des ressources intactes, qu'une donnée seulement lue n'est pas une ressource gérée, et qu'un objet que personne n'a déclaré reste invisible.
dsoxlab start getting-started-terraform-overview -
Prouver l'idempotence là où le script impératif diverge
Un script de provisionnement est fourni, et il diverge dès qu'on le rejoue : un identifiant différent à chaque appel, un rapport qui s'empile au lieu d'être remplacé. Obtenez le même résultat en Terraform, puis établissez par le plan qu'un second passage est un non-événement, et corrigez une dérive externe sans toucher à votre code.
dsoxlab start getting-started-declarative-vs-imperative -
Prouver la compatibilité Terraform / OpenTofu, et où elle s'arrête
« Les deux outils sont compatibles » se répète partout et personne ne le vérifie. Rendez une configuration portable en déclarant la source et la contrainte de version de chaque provider, puis établissez par l'état structuré que les deux binaires lisent le même state, résolvent les mêmes versions sur deux registres différents, et que le fichier de verrouillage est exactement l'endroit où la portabilité s'arrête.
dsoxlab start getting-started-terraform-vs-opentofu -
Contraindre la version de la CLI et verrouiller les providers
Installer le binaire ne prouve presque rien. Contraignez la version de la CLI depuis la configuration elle-même, épinglez les trois providers, faites refuser une contrainte impossible, et prouvez que le verrou fait autorité : effacez `.terraform/`, relancez `init`, les versions retenues ne doivent pas bouger.
dsoxlab start getting-started-install-terraform -
Mettre d'accord fmt, validate et les outputs
Trois défauts sont posés : un fichier hors format canonique, une référence orpheline qui fait échouer `validate`, et des outputs absents. Corrigez les trois sans changer ce que la configuration produit, puis prouvez qu'une expression se recalcule hors du state.
dsoxlab start getting-started-cli-terraform -
Lire un plan avant de l'appliquer
Une configuration déjà appliquée doit évoluer. Avant de toucher quoi que ce soit, dites lesquelles de ses ressources seront modifiées en place et lesquelles seront détruites puis recréées. La sortie humaine du plan annonce les deux cas dans le même bloc de texte : la seule lecture fiable est le champ des actions du plan converti en JSON. Appliquez ensuite exactement le plan que vous avez relu, depuis un plan enregistré.
dsoxlab start getting-started-terraform-workflow -
Ce que Terraform gère, ce qu'il se contente de lire
Un mot sépare les deux natures de blocs : `resource` crée et gère, `data` lit. Le prouver dans le champ `mode` du state, puis constater les deux conséquences : un `destroy` ne touche pas ce qu'il n'a pas créé, et une data source est relue à chaque plan.
dsoxlab start getting-started-providers-resources-data-sources -
Découper un monolithe sans bouger le plan
Le nom des fichiers n'a aucun effet fonctionnel : Terraform lit tous les `.tf` comme un seul document. Découper un monolithe en six fichiers thématiques et prouver, en comparant deux plans JSON, que rien n'a changé. Puis constater quelle source de valeur l'emporte.
dsoxlab start getting-started-terraform-project-structure
Premières infrastructures
-
Première infrastructure : le cycle complet, prouvé
Déroulez le cycle Terraform sur une ressource RÉELLE plutôt que de le réciter, et découvrez au passage que `~> 0.8` n'interdit pas `0.9.x` : l'opérateur pessimiste incrémente le composant le plus à droite, et la branche 0.9 a réécrit le schéma des ressources.
dsoxlab start first-infra-first-infrastructure -
Variables, locals et l'ordre de précédence réel
Quatre marches, vérifiées dans l'ordre : `default`, `TF_VAR_`, `terraform.tfvars`, `*.auto.tfvars`, `-var`. La décisive est la deuxième : un fichier de valeurs BAT la variable d'environnement, rang que presque tout le monde place trop haut.
dsoxlab start first-infra-variables-outputs -
La dépendance que Terraform ne peut pas deviner
Terraform construit son graphe à partir des RÉFÉRENCES qu'il trouve dans les expressions. Neuf fois sur dix, un `depends_on` écrit à la main signale une référence manquante. Ce lab porte sur la dixième : un bloc qui consomme une variable et ne référence rien, où Terraform est libre d'agir dans le mauvais ordre.
dsoxlab start first-infra-virtual-network -
Mise à jour en place ou remplacement : le lire dans le plan
Sur une machine virtuelle, certains attributs se modifient en place et d'autres détruisent puis recréent la machine. Le plan dit lequel, avant l'apply, à condition de savoir où regarder. Vérifiez ensuite que le plan disait vrai, en l'appliquant.
dsoxlab start first-infra-vm-libvirt -
Produire un inventaire Ansible depuis le state
Terraform sait ce qu'il a créé ; Ansible doit le savoir aussi. Construisez le pont, et rendez-le FIABLE plutôt que seulement fonctionnel : une variable typée, des adresses calculées par une fonction HCL, un fichier sérialisé, et un inventaire qui disparaît avec le parc qu'il décrit.
dsoxlab start first-infra-ansible -
Reprendre après un apply qui a échoué, sans refaire le travail
Un apply qui échoue en cours de route laisse un state PARTIEL. Ce n'est pas un accident à effacer : c'est le point de départ de la réparation. Corrigez la cause dans la configuration, et prouvez que les ressources déjà créées ont gardé leurs identifiants.
dsoxlab start first-infra-debug-apply -
Détruire proprement, et les quatre choses que cela recouvre
Détruire n'est pas une seule opération. Constatez-en quatre qui ne se ressemblent pas : le destroy global qu'un garde-fou peut REFUSER, le destroy ciblé, le retrait d'une ressource DU CODE, et le destroy complet qui vide le state sans supprimer son fichier.
dsoxlab start first-infra-clean-destroy
Écrire du code Terraform
-
Source explicite et alias de provider
Déclarer les providers correctement : une adresse source explicite qui se résout en registry.terraform.io/hashicorp/random, une seconde configuration du même provider distinguée par un alias, et une ressource rattachée avec provider =. Prouvé par version -json et le provider_config du plan JSON. Associate 5b.
dsoxlab start write-code-providers -
Lire le cycle de vie d'une ressource dans le plan
Construire quatre ressources ordonnées par les seules références, puis prouver dans le plan JSON les quatre opérations du cycle de vie : mise à jour en place, remplacement, création avant destruction, et destruction. Sous-objectif Pro 1c.
dsoxlab start write-code-declare-resources -
Variables, typage, validation et précédence
Typer correctement les variables et maîtriser leurs pièges : une map d'objets avec des defauts optional(), une validation qui rejette avant tout provider, un null explicite qui retombe sur le defaut avec nullable=false, la vraie précédence des sources (auto.tfvars au-dessus de TF_VAR_, -var au-dessus de tout), et sensitive comme masque d'affichage, pas comme protection du state. Associate 2e et 2f.
dsoxlab start write-code-variables -
Le secret que l'output ne cache pas
Maîtriser le vrai bloc output : une contrainte de type (object), la propagation de la sensibilité (un output qui référence un secret doit être sensible, et sensitive n'est qu'un masque d'affichage, le clair reste dans le state, -json et -raw), nonsensitive() pour exposer un hash volontairement, et un precondition qui bloque le plan. Associate 2e et 2f.
dsoxlab start write-code-outputs -
Le local qui ne se calcule pas au plan
Centraliser les expressions dans des blocs locals : normaliser par des fonctions HCL, garder un ternaire typé, générer une liste par expression for, dériver d'un attribut de ressource (inconnu au plan), et hériter de la sensibilité d'une variable. Sous-objectif Pro 2c.
dsoxlab start write-code-locals -
À quel moment Terraform lit-il une data source ?
Construire trois data sources dont le moment de lecture est délibéré : l'une lue pendant le plan, l'autre reportée à l'apply parce que la ressource dont elle dépend change, la troisième portant un depends_on explicite qui ne la reporte PAS. Prouver chaque cas dans le plan JSON. Sous-objectif Pro 2b.
dsoxlab start write-code-data-sources -
Ce que les expressions calculent vraiment
Écrire des expressions Terraform correctes : référencer une ressource gérée sans préfixe, savoir que == ne convertit pas les types (3 n'est pas "3") alors que l'arithmétique convertit, respecter la précédence des opérateurs, et utiliser null pour omettre un argument plutôt qu'une chaîne vide. Associate 2e.
dsoxlab start write-code-expressions -
Composer des valeurs avec les fonctions HCL
Dedupliquer une collection pour for_each, maitriser element() hors bornes, le repli de lookup(), l'arrondi de ceil(), l'echappement des templates et une fonction de provider. Objectif Pro 2c.
dsoxlab start write-code-functions -
Fonctions définies par les providers
Utiliser les fonctions exposées par un provider via la syntaxe provider::. Objectifs Pro 2c et 5a.
dsoxlab start write-code-provider-defined-functions -
La configuration qui refuse les valeurs absurdes
Calculer des valeurs par expression conditionnelle, puis placer chaque garde au bon niveau : validation, precondition, postcondition et bloc check. Objectif Pro 2a.
dsoxlab start write-code-conditionals -
Conditions personnalisées : precondition, postcondition et blocs check
Valider une configuration avec les fonctionnalités du langage prévues pour cela. Objectif Pro 2a.
dsoxlab start write-code-validation-check-preconditions -
count indexé par position, et la position ment
Choisir count ou for_each pour chaque ressource et le prouver : indexer un ensemble par nom avec for_each, migrer une ressource count vers for_each sans rien detruire grace aux blocs moved, garder count pour des copies interchangeables, et exposer une ressource conditionnelle avec one(). Objectif Associate 4b et la migration moved du niveau Professional.
dsoxlab start write-code-count -
Ajouter une instance sans détruire les autres
Migrer count vers for_each avec des blocs moved sur une configuration deja appliquee, puis ajouter un service en prouvant zero destruction. Objectif Pro 2d.
dsoxlab start write-code-for-each -
Transformer un catalogue avec les expressions for
Dériver quatre collections depuis une seule map de serveurs avec des expressions for : un tuple filtré, un objet groupé par rôle via l'ellipsis, un croisement à deux niveaux aplati, et un for_each filtré. Éviter le piège du splat sur une map. Sous-objectif Pro 2c.
dsoxlab start write-code-for-loops -
Générer des blocs, et savoir ne pas le faire
Générer des parties cloudinit avec un bloc dynamic filtré dans le for_each et nommé depuis la clé, garder la partie fixe littérale, et buter sur le mur : un bloc de méta-arguments lifecycle ne se génère pas par dynamic. Sous-objectif Pro 2d.
dsoxlab start write-code-dynamic-blocks -
depends_on ne se pose que là où une référence ne peut aller
Supprimer un depends_on redondant qu'une référence couvre déjà, remplacer un chemin en dur par une référence, garder le seul depends_on qu'aucune référence ne peut exprimer, et prouver le graphe dans le plan JSON. Sous-objectif Pro 2d.
dsoxlab start write-code-depends-on -
Le bloc lifecycle décide de l'ordre, pas vous
Poser create_before_destroy et constater que sa propagation descend vers les dépendances, buter sur la limite documentée de prevent_destroy, limiter ignore_changes à un seul attribut, déclencher un remplacement depuis une valeur nue via terraform_data, et refuser une entrée invalide au plan. Sous-objectif Pro 2d.
dsoxlab start write-code-lifecycle -
La faute de frappe qui ne casse rien
Deux pièges des tfvars : une variable non déclarée dans un .tfvars n'est qu'un avertissement, la vraie variable reste donc silencieusement à son défaut (corriger la faute de frappe), et terraform.tfvars.json l'emporte sur terraform.tfvars (un niveau de précédence distinct). Associate 3c.
dsoxlab start write-code-tfvars-files -
Contraintes de version et lock file
Écrire des contraintes de version correctes : un required_version littéral (le bloc terraform n'accepte aucune variable), un pin exact de provider qui se résout à cette version, et le pessimiste ~> qui autorise la 3.x mais pas la 4.0. Prouvé par version -json et les empreintes h1 du lock file. Associate 3a.
dsoxlab start write-code-version-constraints -
La configuration qui marche mais qu'aucune CI n'accepte
Reprendre une configuration fonctionnelle mais non conforme et la rendre acceptable en CI : passer terraform fmt, corriger la référence orpheline qui fait échouer validate, renommer les ressources en snake_case, typer et décrire variables et outputs, marquer le jeton sensible, typer l'output nombre (1.15), et écrire un .gitignore qui exclut le state mais garde le lock file. Associate 2a et 2e.
dsoxlab start write-code-style-guide -
Quand la sensibilité casse for_each
Un effet de bord de sensitive rarement enseigné : une valeur sensible ne peut pas être une clé for_each (Invalid for_each argument), il faut donc itérer sur un ensemble non sensible. L'attribut de ressource contaminé est marqué dans sensitive_values, et un hash s'expose avec nonsensitive(). Professional 2f.
dsoxlab start write-code-sensitive-data-sensitive-values -
La valeur qui ne touche jamais le state
Déclarer une valeur éphémère, générée pendant l'opération mais jamais écrite dans le state ni le plan : le bloc ephemeral (random 3.7+), le contraste avec un random_password persisté, l'exposer sans risque au root avec ephemeralasnull(), et les deux erreurs qu'elle lève si on la laisse fuiter. Professional 2f.
dsoxlab start write-code-sensitive-data-ephemeral-values -
Arguments write-only : un secret qui n'atterrit jamais dans le state
Transmettre un secret au provider sans jamais le persister dans le state Terraform, grâce aux arguments write-only, contre un émulateur AWS local.
dsoxlab start write-code-sensitive-data-write-only-arguments -
Lire des secrets depuis Vault
Récupérer des secrets depuis HashiCorp Vault avec le provider vault et les consommer sans les figer en clair dans le state. Objectif Pro 2f.
dsoxlab start write-code-sensitive-data-vault-secrets
Le state Terraform
-
Reprendre un secret déjà en service, sans le régénérer
Un `apply` ordinaire tirerait un mot de passe neuf. Rattacher l'existant par un bloc `import`, puis constater que le secret est en clair dans le state tout en étant marqué `sensitive_attributes` : le masquage est un affichage, pas un chiffrement.
dsoxlab start state-understand-state -
Migrer le state sans casser sa lignée
Un bloc backend n'accepte aucune valeur nommée. Passer d'un backend local implicite à un backend paramétré par configuration partielle et `-backend-config`, et prouver que le state a migré plutôt que d'être recréé : même `lineage`, deux ressources toujours gérées.
dsoxlab start state-backends -
Verrouillage du state, ce qu'il bloque vraiment
Mesurer le périmètre exact du verrou sur un backend local, et énoncer ce qui l'active sur S3.
dsoxlab start state-state-locking -
terraform state list, l'adresse est l'identité
Retrouver l'adresse d'une instance dont on ne connaît que l'identifiant réel, et compter les ressources gérées sans se faire piéger par un module.
dsoxlab start state-terraform-state-list -
terraform state show, ce que la fiche cache
Extraire du state une valeur sensible et des attributs nuls, que la sortie humaine de state show caviarde ou omet.
dsoxlab start state-terraform-state-show -
terraform state mv et le bloc moved, refactorer sans détruire
Rattacher trois objets existants à leurs nouvelles adresses, en impératif puis en déclaratif, et prouver que rien n'a été recréé.
dsoxlab start state-terraform-state-mv -
terraform state rm et le bloc removed, cesser de gérer sans détruire
Sortir deux ressources du state sans supprimer les fichiers, et comprendre pourquoi un bloc removed détruit tant qu'on n'écrit pas destroy = false.
dsoxlab start state-terraform-state-rm -
Le bloc removed : léguer une infrastructure sans la détruire
Sortir des ressources du state en décidant pour chacune si l'objet réel survit, et découvrir où le bloc removed déclare forfait. Objectifs Pro 1e et 4c.
dsoxlab start state-removed-block -
Restaurer un state amputé : choisir la bonne sauvegarde, prouver que rien n'a été recréé
Un state rm a mal tourné et le backup est écrasé. Trois sauvegardes candidates, une seule restaurable, départagées par lineage et serial, puis poussée sans toucher aux fichiers réels.
dsoxlab start state-backup-restore-state -
Diagnostiquer une dérive et adopter une orpheline, sans perdre sa valeur
Prouver une dérive par un plan refresh-only enregistré, la réconcilier, puis adopter un jeton préexistant avec un bloc import, sans que Terraform le regénère.
dsoxlab start state-diagnose-state
Modules Terraform
-
Un module réutilisable ne configure aucun provider
Vider un module enfant de sa configuration de provider, lui faire déclarer la configuration aliasée qu'il attend, la lui passer depuis la racine, et l'instancier trois fois avec un seul for_each.
dsoxlab start modules-create-modules -
Refactorer un monolithe vers la structure standard
Éclater un fichier .tf unique selon la structure officielle, ajouter un module imbriqué appelé par chemin relatif, un exemple autonome, et prouver que override.tf est le seul nom de fichier à avoir un effet.
dsoxlab start modules-module-structure -
L'interface d'un module est un contrat, pas seulement des types
Rendre un attribut d'objet facultatif, refuser un null explicite, rejeter une valeur hors bornes, garder une sortie sous precondition, et ré-exporter un secret sans casser le plan.
dsoxlab start modules-module-variables-outputs -
Un module local se lit sur place, il ne s'installe pas
Brancher deux projets racine sur un seul module local partagé, et prouver depuis modules.json quel dossier chaque appel lit vraiment : chemin relatif contre chemin absolu.
dsoxlab start modules-module-local -
Un module de registre est téléchargé, versionné, et jamais verrouillé
Épingler un module de registre, résoudre une contrainte souple, et prouver depuis modules.json et le JSON du plan quelle version a été installée : le fichier de verrouillage ne couvre jamais un module.
dsoxlab start modules-module-registry -
Publier et consommer des versions de module avec des tags Git
Publier trois versions d'un module partagé, puis les consommer depuis trois projets : une référence immuable, un tag mineur et un tag majeur, sans jamais employer l'argument version.
dsoxlab start modules-version-modules -
Prouver un module avec terraform test, mutations comprises
Écrire la suite .tftest.hcl d'un module, couvrant son défaut, ses options et son refus d'une entrée invalide : chaque comportement est contrôlé en mutant le module.
dsoxlab start modules-test-module -
Rendre un module composable, et le prouver depuis le JSON du plan
Debarrasser un module legacy de sa configuration de provider, inverser sa dependance et le documenter, puis lire la preuve dans provider_config et module_calls.
dsoxlab start modules-module-best-practices -
Refactorer un projet copié-collé sans rien détruire
Extraire deux ressources copiees-collees dans un module type appele une seule fois, et prouver depuis les identifiants du state que rien n'a ete detruit en chemin.
dsoxlab start modules-module-anti-patterns
Environnements
-
Decouper une configuration monolithique, et prouver que le plan n'a pas bouge
Decouper un main.tf de quatre-vingts lignes selon le socle officiel, puis prouver en comparant deux plans que rien n'a change : un validate vert ne prouve rien ici.
dsoxlab start environments-organize-terraform-repo -
Deux racines, deux états, un seul module partagé
Brancher deux configurations racine sur un module partage avec un backend partiel, puis prouver en detruisant dev que prod n'a pas bouge.
dsoxlab start environments-separate-environments -
Quelle valeur gagne, et comment le prouver
Servir trois environnements depuis une seule configuration, retablir le garde-fou qu'un terraform.tfvars avait neutralise, et prouver quelle source gagne par le JSON du plan.
dsoxlab start environments-per-environment-variables -
Un seul répertoire, trois états qui ne se voient pas
Piloter trois instances d'etat depuis une seule configuration grace a terraform.workspace, puis retirer un workspace herite sans laisser d'objet orphelin.
dsoxlab start environments-workspace -
Workspaces ou configurations separees, et ce que coute la decoupe
Decider ce qui releve encore des workspaces, decouper le reste en deux racines, et rebrancher leur dependance par terraform_remote_state sans dupliquer une valeur.
dsoxlab start environments-when-to-use-workspaces -
Decouper un monorepo en deux stacks qui se parlent
Re-exporter a la racine la sortie d'un module imbrique, la consommer depuis une stack aval par terraform_remote_state, et garder le secret de la plateforme hors de l'etat partage.
dsoxlab start environments-monorepo-vs-repo-per-stack -
Exécuter Terraform en automation (CI/CD)
Batir une chaine Terraform non interactive jugee sur ses seuls codes de retour, puis consigner ce qu'un plan sauvegarde fige vraiment, ce que fait un verrou, et ou fuit un secret.
dsoxlab start environments-terraform-in-automation
Terraform sur AWS, via Floci
-
Provider AWS : authentification, endpoints et tags par defaut
Configurer un provider AWS epingle pour qu'il dialogue avec une API locale, puis prouver que l'instance tourne reellement.
dsoxlab start aws-provider-aws-first-ec2 -
Security group : règles dédiées, for_each et subnet déterministe
Construire un security group dont toutes les regles sont des ressources dediees, factoriser les regles d'entree par for_each, et poser une instance dans un subnet designe par son tag.
dsoxlab start aws-sg-subnet-instance -
Composer la chaîne IAM, et nommer ses deux policies correctement
`aws_iam_policy_document` est une data source LOCALE : elle n'interroge rien, elle fabrique du JSON. Composez la chaîne policy, rôle, instance profile, instance, et prouvez dans l'état structuré que la trust policy et les permissions empruntent deux chemins distincts jusqu'au rôle.
dsoxlab start aws-iam-role-policy-instance-profile -
Un state distant, verrouillé, et lu par une autre stack
Reparer un bloc backend piege, rendre le verrou S3 reellement effectif, et faire consommer les outputs par une seconde configuration sans recopier une valeur.
dsoxlab start aws-backend-s3-remote-state -
Lire un remplacement dans le plan, avant qu'il n'arrive
Un ASG qui référence `version = "$Latest"` ne déclenche jamais d'instance refresh, et un `create_before_destroy` posé sur le launch template ne protège rien du tout. Lisez ces deux vérités dans le plan converti en JSON, sans jamais appeler AWS.
dsoxlab start aws-launch-template-autoscaling -
Import, moved et dérive : les trois pièges qu'un tutoriel ne montre jamais
Placez sous contrôle de Terraform une instance EC2 créée en dehors de lui, changez son adresse logique sans que l'objet réel soit recréé, puis réconciliez une dérive en ACCEPTANT la réalité plutôt qu'en l'écrasant.
dsoxlab start aws-import-moved-drift
HCP Terraform
-
Le workflow d'un run : joué en deux temps, puis qualifié
Un run est un plan, puis un apply de CE plan. Reproduire cette division en local avec les plans enregistrés, constater ce que refusent un plan périmé et une variable figée, puis qualifier six runs décrits et remettre les onze étapes dans l'ordre que la documentation donne.
dsoxlab start hcp-terraform-hcp-terraform-overview -
Workspaces : un mot, deux sens, deux stratégies de rattachement
Un workspace CLI est un état de plus dans le même répertoire ; un workspace HCP Terraform est une unité d'exécution, avec ses variables, ses droits et son historique. Réparer deux blocs `cloud`, rattacher l'un par nom et l'autre par étiquettes, et établir ce que `terraform validate` ne voit pas.
dsoxlab start hcp-terraform-hcp-workspaces -
Le flux qu'un run renvoie, et les trois façons de le lancer
Ce qu'une CLI reçoit d'un run distant est le flux structuré que `terraform apply -json` produit aussi en local. L'enregistrer, l'analyser en HCL, avec deux `change_summary` dont un seul dit ce qui s'est passé, et établir ce que chacun des trois workflows autorise.
dsoxlab start hcp-terraform-remote-runs -
Quinze niveaux de précédence, et une inversion
Chez les variable sets prioritaires, la portée la plus large gagne, alors que chez les sets normaux c'est la plus étroite. Construire la table complète des quinze niveaux, puis résoudre des cas que les tests génèrent et qu'aucune réponse écrite cas par cas ne traite.
dsoxlab start hcp-terraform-variable-sets -
Les identifiants ne vivent ni dans le code, ni dans le state
`sensitive` masque une valeur à l'écran, et le state la porte quand même en clair. Sortir les clés du provider de la configuration, remplacer un jeton posé en étiquette par son empreinte, et établir comment fonctionnent les identifiants dynamiques.
dsoxlab start hcp-terraform-shared-credentials -
Les permissions s'additionnent, elles ne s'écrasent pas
Une permission posée au niveau organisation peut l'emporter sur celle du workspace, et l'inverse est vrai aussi : c'est le plus permissif qui gagne, jamais le plus spécifique. Écrire la règle qui calcule l'accès effectif de six équipes, et établir deux échelles qui ne sont pas la même.
dsoxlab start hcp-terraform-projects-teams -
Policy as code : qui bloque un run, et qui peut passer outre
Un `hard-mandatory` n'est pas indépassable : c'est le réglage du policy set qui tranche, croisé avec la permission de l'utilisateur. Qualifier sept runs, établir les niveaux des trois frameworks, et écrire une règle qui refuse un plan non conforme et accepte l'autre.
dsoxlab start hcp-terraform-policy-as-code -
Le premier run distant, pour de vrai (optionnel, demande un compte)
Le seul lab du catalogue qui demande un compte HCP Terraform. Provisionner la plateforme avec le provider `tfe` (projet, workspace, réglages, une variable sensible), rattacher une configuration par un bloc `cloud`, et voir un run s'exécuter sur l'infrastructure de HashiCorp.
dsoxlab start hcp-terraform-premier-run-distant
Certification Associate (004)
-
Les commandes que l'examen attend, faites plutôt que récitées
Huit gestes qu'un candidat doit savoir FAIRE : `validate`, `fmt`, la cascade de précédence, `moved`, `import`, `removed` sans détruire, `-replace`, et ce que `sensitive` protège vraiment. Les codes de retour se consignent au moment où ils sont observés : ils ne se reconstituent pas après coup.
dsoxlab start certifications-associate-essential-commands -
Associate 004 : examen blanc
Examen blanc de l'Associate 004, validé par pytest.
dsoxlab start certifications-associate-mock-004
Certification Professional
-
Pro · Objectif 1 : cycle de vie, import et réconciliation de drift
Importer dans le state une EC2 créée hors Terraform (aws cli sur Floci), puis détecter et réconcilier un drift. Objectif d'examen 1.
dsoxlab start certifications-professional-capstone1-resource-lifecycle -
Pro · Objectif 2 : configuration dynamique et troubleshooting
Data sources, fonctions HCL, meta-arguments (count/for_each/dynamic), types complexes, données sensibles et Vault. Objectif d'examen 2.
dsoxlab start certifications-professional-capstone2-dynamic-config -
Pro · Objectif 3 : workflows collaboratifs
Remote state (backend S3 sur Floci), version constraints, workflow en automation et partage de données via terraform_remote_state. Objectif d'examen 3.
dsoxlab start certifications-professional-capstone3-collaborative-workflows -
Pro · Objectif 4 : créer, maintenir et utiliser des modules
Créer un module, le consommer, le refactorer et le versionner ; refactorer une configuration plate en modules. Objectif d'examen 4.
dsoxlab start certifications-professional-capstone4-modules -
Pro · Objectif 5 : configurer et utiliser les providers
Architecture plugin, aliasing, versioning/sourcing/upgrades, authentification et troubleshooting d'erreurs provider (sur Floci). Objectif d'examen 5.
dsoxlab start certifications-professional-capstone5-providers -
Pro · Objectif 6 : HCP Terraform, là où les sous-objectifs se croisent
L'objectif 6 est évalué en QCM, et ne demande aucun compte. Six situations qui croisent chacune deux sous-objectifs, un bloc `cloud` à écrire, et un secret qui ne doit pas atteindre le state. Six situations, six issues différentes : aucune réponse constante ne passe.
dsoxlab start certifications-professional-capstone6-hcp -
Pro · Examen blanc intégratif : les six objectifs d'une traite
Une répétition générale, pas une leçon : six tâches, une par objectif, à jouer d'un trait une fois les six capstones réussis. Réconciliation d'une dérive, configuration dynamique, deux états qui communiquent, un module qui ne recrée rien, deux configurations d'un provider, et un QCM de douze questions noté par sous-objectif.
dsoxlab start certifications-professional-mock-pro
Kubernetes, CKA, CKAD et CKS
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training
CKA, Certified Kubernetes Administrator
-
Poser un Pod statique sur un worker, sans passer par l'API
Faire tourner un Pod que le kubelet du worker gère seul, à partir d'un manifeste déposé sur le nœud, et le voir apparaître dans l'API sous son nom de miroir. Le fichier doit être au bon endroit, celui que la configuration du kubelet désigne, et le runtime du worker doit réellement exécuter le conteneur.
dsoxlab start cka-static-pod -
Un agent sur chaque nœud, control plane compris
Déployer un DaemonSet qui pose un agent sur tous les nœuds du cluster, y compris le control plane, protégé par son taint. Les tests comptent un Pod par nœud, vérifient que le taint est toujours là et que l'agent y tourne quand même, et lisent ses logs pour prouver qu'il fait son travail.
dsoxlab start cka-daemonset-all-nodes -
Donner une identité à une application : ServiceAccount, Role, RoleBinding
Une application refuse de démarrer parce que son ServiceAccount n'existe pas. Le créer, lui accorder le droit de lire les Pods de son namespace et rien d'autre, puis prouver depuis l'intérieur du Pod, avec son propre jeton, que lister passe et que supprimer, lire les Secrets ou regarder ailleurs sont refusés.
dsoxlab start cka-rbac-serviceaccount -
Réserver un nœud : taint, tolérance et nodeSelector
Réserver le worker à la production par un taint et un label, puis placer un Pod qui doit y aller, tolérance et nodeSelector, et un Pod qui ne doit pas y aller. Les tests lisent le nœud, le placement réel de chaque Pod et les mécanismes déclarés : un Pod épinglé par nodeName contourne le taint et ne passe pas.
dsoxlab start cka-taints-tolerations-placement -
Placer avec nodeAffinity : contrainte obligatoire et préférence
Placer un Deployment par une affinité de nœud obligatoire sur un label à plusieurs valeurs, y ajouter une préférence pondérée, puis débloquer un Pod qui attend un nœud qui n'existe pas encore en posant le label qu'il exige. Les tests lisent les labels des nœuds, les affinités déclarées et le nœud réel de chaque Pod.
dsoxlab start cka-node-affinity -
Isoler la base de données : seul le backend y accède
Écrire la NetworkPolicy qui ne laisse entrer vers la base que le backend de son namespace, sur son port, et rien d'autre. Les tests tentent les connexions : celle qui doit passer, celle du frontend qui doit être bloquée, celle d'un Pod au bon label mais dans un autre namespace, et vérifient que la base peut encore sortir.
dsoxlab start cka-networkpolicy-isolate-db -
Router deux applications sur un seul hôte, et prouver que chacune reçoit la sienne
Deux applications, un seul nom d'hôte, et aucune règle disant laquelle est laquelle. Routez par le chemin, et prouvez-le de la seule façon qui compte : chaque chemin répond le nom de son application, et un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-ingress-path-routing -
Router avec la Gateway API, et voir la Gateway se déclarer programmée
Les deux mêmes applications, le même nom d'hôte unique, et le successeur de l'Ingress. Déclarez une Gateway, attachez-lui une route, et prouvez le routage : chaque chemin répond le nom de son application, un chemin non déclaré ne répond ni l'une ni l'autre.
dsoxlab start cka-gateway-api-httproute -
Un volume persistant : PersistentVolume, PersistentVolumeClaim et un Pod qui écrit
Sur un cluster sans provisionnement dynamique, créer un PersistentVolume sur le disque d'un nœud, le réclamer par un PersistentVolumeClaim, le monter dans un Pod qui y écrit. Les tests lisent le volume, la liaison, le montage, le fichier dans le Pod, puis le même fichier sur le disque du nœud : c'est là que se prouve la persistance.
dsoxlab start cka-pv-pvc-storageclass -
Obtenir un volume sans qu'un administrateur l'ait créé, et voir ce qu'il devient
Une revendication bloquée en attente parce que personne n'a préparé de volume à la main. Laissez le cluster le provisionner à la demande, puis observez ce que la classe décide quand la revendication disparaît : le volume la suit.
dsoxlab start cka-storageclass-provisionnement-dynamique -
Revenir en arrière sur un déploiement bloqué, puis livrer la bonne version
Une mise à jour est partie avec un nom d'image faux et le déploiement est bloqué. Revenir à la révision qui marchait par l'historique du Deployment, puis livrer l'image correcte avec une cause de changement. Les tests lisent les ReplicaSets et leurs numéros de révision : ils racontent ce qui s'est passé, et un Deployment recréé de zéro ne raconte rien.
dsoxlab start cka-deployment-rollout-rollback -
Vider un worker pour une maintenance, sans couper le service
Protéger une application par un PodDisruptionBudget, retirer le worker du scheduling, l'évacuer en respectant ce budget et les DaemonSets, puis le remettre en service et tracer l'opération. Les tests prouvent que les Pods ont réellement été recréés ailleurs, que le nœud est revenu, et que le DaemonSet du CNI n'a pas bougé.
dsoxlab start cka-node-drain-cordon -
Faire monter en charge automatiquement avec un HorizontalPodAutoscaler
Poser un HPA sur un Deployment, générer de la charge, voir la montée en replicas, puis couper la charge. Les tests lisent le HPA, ses métriques courantes, et l'event de redimensionnement que le contrôleur a émis : un HPA qui n'a jamais redimensionné n'est pas un HPA validé.
dsoxlab start cka-hpa-autoscaling -
Plafonner un namespace sans bloquer ceux qui oublient de se déclarer
Un namespace sans plafond ni valeurs par défaut : une équipe peut prendre tout le cluster, et un Pod sans `requests` est placé à l'aveugle. Posez les deux, et prouvez chacun : un Pod qui demande trop est refusé, un Pod qui ne demande rien est accepté et complété.
dsoxlab start cka-resourcequota-limitrange -
Sortir un Pod de l'ImagePullBackOff
Un Pod ne démarre pas parce que son image ne se télécharge pas. Lire le message exact du runtime dans les events, corriger la référence d'image, et prouver que le serveur répond.
dsoxlab start cka-troubleshoot-imagepullbackoff -
Sortir un Deployment du CrashLoopBackOff
Les Pods d'un Deployment redémarrent en boucle depuis la dernière livraison. Lire ce que le processus a dit avant de mourir, comprendre ce qui lui manque, corriger le Deployment, et prouver que l'application sert à nouveau.
dsoxlab start cka-troubleshoot-crashloopbackoff -
Entrer dans un conteneur sans shell avec kubectl debug
Un Pod dont l'image ne contient aucun shell n'offre rien à kubectl exec. Lui adjoindre un conteneur éphémère qui partage ses processus, atteindre le système de fichiers du nœud par un Pod de débogage, et en laisser la preuve.
dsoxlab start cka-kubectl-debug -
Rétablir la résolution DNS du cluster
Plus aucun Pod ne résout de nom de service. Trouver pourquoi le DNS du cluster ne répond plus, le remettre en service, et prouver qu'un Pod client résout et joint à nouveau un Service par son nom.
dsoxlab start cka-troubleshoot-dns -
Rétablir le trafic vers un Service
Un Service ne dessert plus ses Pods : selector faux, port faux, et une politique réseau qui ferme tout. Remettre le Service d'aplomb, rouvrir exactement ce qu'il faut sans retirer la politique de sécurité, et prouver qu'un client joint le Service par son nom.
dsoxlab start cka-troubleshoot-networking -
Ramener un nœud NotReady dans le cluster
Un worker est passé NotReady, et l'application qui lui est réservée est dégradée. Trouver sur le nœud pourquoi il ne parle plus au control plane, remettre son agent en service de façon durable, et prouver que l'application est revenue.
dsoxlab start cka-troubleshoot-node-notready -
Réparer un kubelet qui refuse de démarrer
Le kubelet d'un worker s'arrête aussitôt lancé, et le nœud est NotReady. Lire dans le journal ce qu'il reproche à sa configuration, corriger le fichier sans rien casser d'autre, et prouver que le nœud et son application sont revenus.
dsoxlab start cka-troubleshoot-kubelet -
Remettre l'API server en service
kubectl ne répond plus : l'API server du control plane sort en erreur au démarrage. Sans API, diagnostiquer sur le nœud, dans les conteneurs et les journaux du kubelet, corriger le manifeste statique, et prouver que l'API répond sans avoir affaibli son autorisation.
dsoxlab start cka-troubleshoot-apiserver -
Sauvegarder etcd, puis restaurer le cluster depuis un instantané
Un namespace a disparu. Prendre d'abord une sauvegarde fraîche de l'état courant, puis restaurer le cluster depuis l'instantané de la veille, sans arrêter le mauvais composant et sans laisser l'API server sur un cache périmé. Les tests prouvent qu'etcd tourne sur un répertoire produit pendant le lab, que les objets reviennent avec leur UID d'origine, et que ce qui a été écrit après la sauvegarde a disparu.
dsoxlab start cka-etcd-backup-restore -
Monter un cluster d'une version mineure, sans interrompre ce qui tourne
Un cluster en retard d'une version mineure, une application qui doit continuer à servir, et la montée à conduire : le plan de contrôle d'abord, le nœud ensuite, chacun avec sa propre commande. Les tests lisent les versions et vérifient que rien n'a été laissé vidé.
dsoxlab start cka-kubeadm-upgrade -
Capstone : remettre le portail en service, sans personne à qui demander
Un namespace laissé par une équipe partie, un portail qui ne répond rien, et aucun ticket pour dire pourquoi. Trois défauts indépendants à trouver, deux exigences qui n'ont jamais été satisfaites, et une seule mesure de réussite : le portail répond sur chaque nœud du cluster.
dsoxlab start cka-capstone-portail
CKAD, Certified Kubernetes Application Developer
-
Un Pod à deux conteneurs, avec budgets, labels et annotation
Écrire à la main un Pod à deux conteneurs, chacun avec ses requests et ses limits, avec des labels et une annotation, et prouver depuis l'intérieur de chaque conteneur que la limite de mémoire est celle que le noyau applique.
dsoxlab start ckad-pod-resources-labels -
Injecter configuration et secrets dans un Pod
Donner à une application sa configuration par des variables d'environnement et par un fichier monté, et ses identifiants par un Secret, sans jamais écrire un mot de passe dans le manifeste du Pod. Prouver, de l'intérieur du conteneur, que tout est arrivé.
dsoxlab start ckad-configmap-secret-injection -
Sortir un mot de passe d'un manifeste, sans que l'application s'en aperçoive
Un mot de passe est écrit en clair dans un manifeste de Deployment, que quiconque peut lire le lit aussi. Déplacez-le dans un Secret, injectez-le à la fois en variable d'environnement et en fichier monté, et laissez l'application tourner.
dsoxlab start ckad-secret-injection-protection -
Trois sondes sur un Pod : startup, liveness, readiness
Équiper une application des trois sondes, avec des réglages qui ont un sens : un démarrage lent toléré, une vivacité surveillée, un trafic qui n'arrive qu'une fois prête. Prouver que les sondes agissent : le Pod n'est Ready que parce qu'elles répondent.
dsoxlab start ckad-probes-all-types -
Attendre une dépendance avec un init container
Empêcher une application de démarrer avant que le Service dont elle dépend ne réponde, avec un init container qui attend. Observer le Pod bloqué en Init, poser la dépendance, et voir l'application partir toute seule.
dsoxlab start ckad-init-container -
Un sidecar natif qui suit les logs de l'application
Faire lire par un second conteneur les logs qu'une application écrit dans un fichier, avec un sidecar natif, déclaré comme init container à restartPolicy Always, et un volume partagé. Prouver que le sidecar transmet réellement les lignes.
dsoxlab start ckad-multi-container-sidecar -
Faire lire à un conteneur ce qu'un autre écrit, et pas le reste
Deux conteneurs dans un Pod, l'un qui écrit et l'autre qui lit, et rien de partagé entre eux. Donnez-leur un volume dont la durée de vie est celle du Pod, et prouvez-le dans les deux sens : ce qui est écrit dans le volume passe, ce qui est écrit à côté ne passe pas.
dsoxlab start ckad-volumes-partage-entre-conteneurs -
Exposer un Deployment par un Service ClusterIP
Déployer trois replicas d'un serveur et les exposer par un Service interne. Prouver depuis un client que le Service répond par son nom, et qu'il répartit réellement les requêtes entre les trois Pods.
dsoxlab start ckad-expose-service -
Durcir un Pod avec un securityContext
Faire tourner un serveur web sans privilège : utilisateur non root, aucune escalade, racine en lecture seule, toutes les capabilities retirées. Et lui donner quand même de quoi écrire là où il en a besoin, sinon il ne démarre pas. Prouver, de l'intérieur, que le confinement agit et que l'application sert.
dsoxlab start ckad-security-context-hardened -
Donner un accès en lecture seule aux Pods avec RBAC
Permettre à une utilisatrice de lire les Pods d'un namespace et leurs logs, et rien de plus : ni créer, ni supprimer, ni voir les autres namespaces. Prouver les deux côtés avec kubectl auth can-i, ce qui est permis et ce qui reste refusé.
dsoxlab start ckad-rbac-role-rolebinding -
Cloisonner trois tiers avec des NetworkPolicy ingress et egress
Frontend, backend, base de données : n'autoriser que les flux prévus, dans les deux sens, DNS compris, et interdire tout le reste. Prouver chaque règle par une vraie connexion, celle qui passe et celle qui est bloquée.
dsoxlab start ckad-networkpolicy-ingress-egress -
Régler une mise à jour progressive : maxSurge et maxUnavailable
Contraindre la façon dont un Deployment remplace ses Pods, jamais plus de deux en trop ni plus d'un indisponible, puis déclencher une mise à jour d'image et prouver qu'elle est allée au bout : ancienne révision à zéro, nouvelle au complet.
dsoxlab start ckad-rolling-update-strategy -
Basculer le trafic d'une version à l'autre : blue-green
Faire tourner deux versions d'une application côte à côte, et basculer tout le trafic de l'une à l'autre en changeant le selector d'un Service. Prouver la bascule depuis un client : toutes les requêtes atteignent la nouvelle version, aucune l'ancienne.
dsoxlab start ckad-blue-green-deployment -
Une base Kustomize et deux overlays, dev et prod
Décrire une application une seule fois, dans une base Kustomize, et la déployer dans deux namespaces avec des overlays qui changent le nombre de replicas, préfixent les noms et ajoutent un label d'environnement. Prouver que les deux environnements tournent et se ressemblent.
dsoxlab start ckad-kustomize-overlays -
Installer, mettre à jour et revenir en arrière avec Helm 4
Déployer un chart avec Helm, le mettre à jour avec de nouvelles valeurs, puis revenir à la première révision. Prouver par l'historique de la release et par l'état du Deployment que les trois opérations ont eu lieu, dans cet ordre.
dsoxlab start ckad-helm-install-upgrade -
Un Job à complétions parallèles et un CronJob
Exécuter un traitement quatre fois, deux à la fois, avec un Job, et prouver que les exécutions se sont bien chevauchées. Puis planifier un nettoyage toutes les cinq minutes avec un CronJob qui garde un historique borné.
dsoxlab start ckad-job-cronjob -
Redimensionner un Pod en place, sans le redémarrer
Augmenter le CPU et la mémoire d'un Pod qui tourne, sans le recréer ni redémarrer son conteneur, par la sous-ressource resize. Prouver que le noyau applique la nouvelle limite et que le conteneur est resté le même.
dsoxlab start ckad-in-place-pod-vertical-scaling -
Un Pod bloqué par un ConfigMap qui n'existe pas
Un Pod ne démarre pas et ne dit rien dans ses logs, parce qu'il n'a pas encore de conteneur : ce sont ses events qui parlent. Lire la cause, créer la ressource manquante avec le contenu attendu, et prouver que l'application sert.
dsoxlab start ckad-troubleshoot-missing-configmap -
Trois Pods en CrashLoopBackOff, trois causes
Trois Pods redémarrent en boucle pour trois raisons différentes : une commande qui n'existe pas, une variable d'environnement absente, une limite de mémoire trop basse. Lire pour chacun ce qui le tue, le corriger, et prouver que les trois tiennent.
dsoxlab start ckad-troubleshoot-crashloop -
Capstone : livrer la boutique, à partir du seul cahier des charges
Une livraison complète, donnée comme un cahier des charges et non comme un mode d'emploi. Six exigences à satisfaire dans un namespace : configuration, secret, sondes, identité, exposition et isolation. Rien ne dit quel objet créer, et le dernier test vérifie la seule chose qui compte : un Pod frontend joint la boutique, un Pod qui n'en est pas un ne la joint pas.
dsoxlab start ckad-capstone-boutique
CKS, Certified Kubernetes Security Specialist
-
Confiner un Pod avec un profil AppArmor
Charger un profil AppArmor sur le nœud, l'appliquer à un conteneur par le champ securityContext, et prouver que le confinement agit en constatant l'échec d'une écriture que le profil interdit.
dsoxlab start cks-apparmor-confiner-un-pod -
Interdire un appel système à un conteneur, et le prouver de l'intérieur
Un conteneur qui peut appeler tout ce que le noyau propose. Écrivez un profil seccomp qui refuse une famille d'appels système, appliquez-le, et prouvez que le confinement tient : l'appel interdit échoue depuis l'intérieur, et tout le reste continue de fonctionner.
dsoxlab start cks-seccomp-profile -
Refuser un Pod privilégié à l'admission, avec Pod Security Admission
Un namespace qui accepte tout, y compris un Pod qui partage le namespace PID de l'hôte et tourne en root. Activez le standard restricted pour que le cluster le refuse à l'admission, et prouvez le refus sans rien créer : un essai côté serveur traverse l'admission et n'écrit rien.
dsoxlab start cks-pod-security-admission -
Reprendre un Pod privilégié en production, sans le priver de son travail
Un Pod tourne avec le namespace de processus de l'hôte, en root, privilégié, depuis un tag flottant. Reconstruisez-le sans rien de tout cela, et prouvez la différence là où elle se voit : de l'intérieur, le conteneur ne voit plus l'hôte.
dsoxlab start cks-secure-existing-pod -
Rendre un conteneur immuable sans le faire tomber
Un Deployment qui tourne peut encore être modifié de l'intérieur. Rendez sa racine non inscriptible, retirez-lui toutes les capacités, interdisez l'escalade, et faites en sorte que l'application continue de servir : nginx a besoin de quelques chemins inscriptibles, et les trouver est l'exercice.
dsoxlab start cks-security-context-immutable -
Isoler un Pod du noyau de l'hôte, et le prouver en lisant sa version
Le nœud propose un second runtime de conteneurs, qui exécute un noyau applicatif à lui. Placez-y un Pod, et prouvez l'isolation de la seule façon qui ne se truque pas : de l'intérieur, la version du noyau n'est plus celle du nœud.
dsoxlab start cks-runtime-sandbox-gvisor -
Épingler une image par son digest, et prouver que le tag ne suffit pas
Un Deployment qui fait confiance à un tag mutable. Épinglez-le sur le digest immuable de l'image qu'il exécute réellement, et prouvez que l'épinglage tient : le digest déclaré doit correspondre à ce que le runtime a résolu, et pas seulement y ressembler.
dsoxlab start cks-image-pinned-digest -
Faire refuser une image non épinglée par le cluster lui-même, sans webhook
Un namespace accepte n'importe quelle image, tag compris. Faites refuser par l'API server celles qui ne sont pas épinglées par leur digest, avec une politique qu'il évalue lui-même : pas de webhook, pas de contrôleur, rien à maintenir en vie.
dsoxlab start cks-validating-admission-policy -
Remplacer une image criblée de failles, et le prouver par un second scan
Un Deployment tourne sur une image vieille de trois ans. Analysez-la, choisissez son remplacement, et prouvez ce choix : le test analyse les deux et exige strictement moins de failles critiques que l'original, ce qu'aucun seuil fixe ne pourrait mesurer honnêtement.
dsoxlab start cks-image-scanning-trivy -
Signer une image, et prouver la signature en faisant refuser une autre
Un registre local porte deux images, aucune signée. Signez-en une avec cosign, publiez la clé publique, et prouvez que la chaîne fonctionne : la même clé doit accepter l'image signée et refuser l'autre. Une vérification qui accepte tout ne prouve rien.
dsoxlab start cks-cosign-verify-image -
Corriger un Dockerfile que l'analyse statique refuse, sans changer l'application
Un Dockerfile qui construit et qui tourne, et que l'analyse statique refuse sur cinq points. Corrigez-les tous sans changer ce que fait l'image, et prouvez-le en relançant l'analyse : les cinq constats doivent avoir disparu, identifiés par leur numéro et non par un total qu'une nouvelle règle fausserait.
dsoxlab start cks-dockerfile-static-analysis -
Retirer cluster-admin à un compte de service, sans le priver de son travail
Un ServiceAccount détient cluster-admin parce que c'était plus rapide. Reprenez ce pouvoir et donnez-lui exactement ce dont son application a besoin, rien de plus. La preuve n'est pas dans le manifeste : elle est dans ce que l'API server répond quand ce compte demande.
dsoxlab start cks-rbac-least-privilege -
Fermer le profileur de l'API server, sans fermer l'API
L'API server expose son profileur Go à qui sait l'atteindre, et un cluster kubeadm le laisse actif. Fermez-le et relevez le plancher TLS, puis prouvez les deux moitiés : le profileur répond 404, et le cluster fonctionne toujours.
dsoxlab start cks-api-server-hardening -
Enregistrer qui lit les Secrets, et seulement les métadonnées du reste
Le cluster ne garde aucune trace de qui lit quoi. Donnez à l'API server une politique d'audit à deux niveaux, corps complets pour les Secrets et métadonnées pour le reste, et prouvez qu'elle agit en relisant le journal que le cluster vient d'écrire.
dsoxlab start cks-audit-log-policy -
Tout interdire, puis rouvrir le strict nécessaire, DNS compris
Un namespace où tout parle à tout. Fermez-le entièrement dans les deux directions, puis rouvrez exactement deux choses : le seul flux dont l'application a besoin, et la résolution de noms, qu'une sortie fermée par défaut casse sans que rien ne vous prévienne.
dsoxlab start cks-networkpolicy-default-deny -
Exiger le mTLS dans un maillage, et le prouver par un client qui reste dehors
Un maillage de services accepte du trafic en clair, de n'importe qui, du maillage ou du dehors. Exigez le TLS mutuel, et prouvez-le de la seule façon qui compte : un Pod muni d'un sidecar joint toujours le service, un Pod qui n'en a pas ne le joint plus.
dsoxlab start cks-istio-mtls-lockdown -
Servir un site en HTTPS avec son propre certificat, et non celui du contrôleur
Le site répond déjà en HTTPS, et c'est précisément le piège : le contrôleur Ingress sert son propre certificat par défaut à qui le demande. Terminez le TLS avec un certificat qui nomme vraiment l'hôte.
dsoxlab start cks-ingress-tls -
Faire baisser le compte d'un audit CIS, et le prouver par un second audit
kube-bench audite le control plane contre le référentiel CIS et échoue à dix contrôles sur un cluster kubeadm sorti de l'installation. Corrigez les trois qui partagent une même cause, puis prouvez-le de la seule façon honnête : relancez l'audit et comptez.
dsoxlab start cks-cis-benchmark-remediate -
Capstone : ouvrir une enclave pour une équipe qui n'est pas de confiance
Une équipe extérieure a besoin de place dans votre cluster. Donnez-lui un espace qui reste sûr même si elle ne l'est pas : le cluster doit refuser lui-même ce qu'elle ne devrait pas déployer, son identité ne doit presque rien pouvoir, et rien hors de l'enclave ne doit atteindre ce qui y tourne.
dsoxlab start cks-capstone-enclave
GitHub Actions
Ajouter ce catalogue dsoxlab catalog add https://github.com/stephrobert/github-actions-training
Écrire son premier workflow
-
Premier workflow : les tests tournent à chaque push, et un test cassé fait échouer le pipeline
Une petite bibliothèque Python avec neuf tests que personne ne lance avant de fusionner. Écrivez le workflow qui les joue à chaque push et à chaque pull request, avec des permissions minimales et des actions épinglées, et prouvez-le en cassant un test.
dsoxlab start fondations-premier-workflow
Aucun lab ne correspond à cette recherche.
Comment jouer un lab
Les labs s'exécutent avec dsoxlab, une CLI qui installe le catalogue, prépare l'environnement, pose la mission puis lance les tests de validation. Trois commandes suffisent pour démarrer :
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training
dsoxlab doctor
dsoxlab start l1-first-terminal 218 des 352 labs provisionnent de
vraies machines virtuelles : on ne prouve pas dans un
conteneur qu'on sait réparer un service systemd ou poser
une règle SELinux. Les autres se contentent d'un
terminal. L'étiquette figure sur chaque ligne du catalogue, et
dsoxlab doctor annonce ce qui manque sur votre machine avant
le premier lancement.
153 labs portent la mention attesté : leur dépôt contient un relevé où chaque lab a été rejoué de bout en bout et noté dans les deux sens, zéro avant le travail, cent après. Les autres se jouent aussi, mais leur attestation reste à produire, et la page le dit plutôt que de promettre la même chose partout.
Installer dsoxlab et comprendre un lab Dimensionner sa machine Toutes les commandes Les formations qui utilisent ces labs