ansible.builtin.fetch est l'inverse exact de copy:, il rapatrie un fichier depuis un managed node vers le control node. Il sert à collecter des logs, sauvegarder des configurations existantes avant migration, ou récupérer des rapports générés par les managed nodes.
fetch: gère deux modes d'organisation : arborescence par hôte (flat: false, défaut) ou fichier unique (flat: true). Le second nécessite d'interpoler inventory_hostname dans le dest: pour éviter les écrasements quand plusieurs hôtes sont concernés.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Le mode par défaut (arborescence par hôte) et le mode flat (fichier unique).
- Comment éviter les écrasements quand plusieurs hôtes envoient le même fichier.
- L'option
fail_on_missing: truepour échouer explicitement si le fichier manque. - Le piège des chemins relatifs dans
dest:(résolus depuisplaybook_dir, pas le cwd).
Prérequis
Section intitulée « Prérequis »- Connaître
copy:,fetch:est son miroir. - Comprendre le concept d'
inventory_hostname(cf. Magic vars).
Mode par défaut, arborescence par hôte (flat: false)
Section intitulée « Mode par défaut, arborescence par hôte (flat: false) »- name: Backup des sshd_config ansible.builtin.fetch: src: /etc/ssh/sshd_config dest: backup/Résultat sur le control node :
backup/├── web1.lab/etc/ssh/sshd_config├── web2.lab/etc/ssh/sshd_config└── db1.lab/etc/ssh/sshd_configAnsible reproduit l'arborescence absolue sous un dossier nommé d'après l'hôte. Pas de risque d'écrasement entre hôtes, chacun a son sous-dossier. Mode idéal pour des audits ou des collectes systématiques sur un parc.
Mode flat, fichier unique (flat: true)
Section intitulée « Mode flat, fichier unique (flat: true) »- name: Recuperer le rapport audit ansible.builtin.fetch: src: /tmp/audit-report.txt dest: ./reports/audit-{{ inventory_hostname }}.txt flat: trueRésultat :
reports/├── audit-web1.lab.txt├── audit-web2.lab.txt└── audit-db1.lab.txtflat: true demande à Ansible de placer le fichier directement dans dest:, sans recréer l'arborescence absolue. Mais sans interpolation de inventory_hostname dans le dest:, chaque hôte écrase le précédent, un seul fichier reste à la fin.
Règle : avec flat: true sur plusieurs hôtes, toujours interpoler inventory_hostname dans dest:.
Validation et sécurité
Section intitulée « Validation et sécurité »fetch: valide le checksum du fichier après transfert (option validate_checksum: true par défaut). Si le fichier est modifié pendant le transfert, l'opération échoue.
- name: Recuperer un fichier critique ansible.builtin.fetch: src: /etc/passwd dest: ./backups/ fail_on_missing: true # Echoue explicitement si /etc/passwd absentfail_on_missing: true est important pour les collectes critiques : sans cette option, un fichier absent côté managed node renvoie ok: skipped, et l'opérateur peut ne pas remarquer que les backups manquent pour certains hôtes.
Cas d'usage typiques
Section intitulée « Cas d'usage typiques »Le choix entre les deux modes ne dépend pas du volume collecté mais de ce qu'on veut faire des fichiers ensuite. Quand le chemin d'origine fait partie de l'information, sauvegarde avant migration ou comparaison croisée entre machines, l'arborescence par hôte est ce qu'il faut. Quand les fichiers doivent être lus, triés ou envoyés à un outil d'analyse, le mode plat évite de descendre trois niveaux à chaque consultation. La troisième ligne est le seul cas où l'interpolation de inventory_hostname est facultative, puisqu'un seul hôte est ciblé.
| Cas | Pattern |
|---|---|
| Backup config avant migration | flat: false, dest: backup-2026-04-25/ |
| Collecte de logs | flat: true + inventory_hostname dans dest: |
| Récupération de licences | flat: true, un seul hôte ciblé (pas de boucle) |
| Audit sécurité multi-hôtes | flat: false, exploite l'arborescence sortie pour diff croisé |
Pièges courants
Section intitulée « Pièges courants »Ce module inverse le sens habituel du transfert, et ses pièges suivent la même inversion : trois des quatre se jouent côté control node, pas sur la machine administrée. La destination qui ne distingue pas les hôtes, le chemin relatif résolu depuis playbook_dir, le dossier local non inscriptible relèvent tous du poste qui lance le playbook. Le quatrième, le fichier source absent, est le plus dangereux parce qu'il ne produit aucune erreur : la collecte manque et le recap ne le dit pas.
| Symptôme | Cause | Fix |
|---|---|---|
Un seul fichier dans dest: malgré 5 hôtes | flat: true sans {{ inventory_hostname }} dans dest: | Interpoler inventory_hostname |
Les fichiers atterrissent dans solution/<lab>/ | dest: relatif résolu depuis playbook_dir, pas le cwd | Utiliser {{ inventory_dir }}/../collected/ |
fetch: ignoré silencieusement | Fichier source absent + fail_on_missing: false (défaut) | Mettre fail_on_missing: true |
| Permission denied côté control node | Le dest: n'est pas writable par l'utilisateur qui lance Ansible | Vérifier les permissions du dossier local |
Différence avec slurp:
Section intitulée « Différence avec slurp: »slurp: (autre module Ansible) lit le contenu d'un fichier distant et le retourne en base64 dans une variable, sans écrire localement. À utiliser quand on veut inspecter le contenu en mémoire (vérifier une config, alimenter un template:), pas le sauvegarder. fetch: reste le bon choix dès qu'on veut un fichier persistant côté control node.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Profil de compétences
Quoi faire maintenant
Ressources pour progresser
Des indices pour retenter votre chance ?
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications
À retenir
Section intitulée « À retenir »fetch:= inverse decopy:, du managed node vers le control node.- Mode défaut : arborescence par hôte (sûr, jamais d'écrasement).
- Mode flat : fichier unique, mais toujours interpoler
inventory_hostnamesur multi-hôtes. fail_on_missing: truesur les collectes critiques (sinon les manques sont silencieux).- Chemin relatif
dest:est résolu depuisplaybook_dir, pas le cwd, préférerinventory_dir-relatif ou absolu.
Mettre en pratique
Section intitulée « Mettre en pratique »fetch inverse le sens habituel du transfert, et c'est ce renversement qui déroute. Ce lab vous fait rapatrier /etc/os-release depuis deux managed nodes vers le control node, en mode flat: true avec un nom de fichier construit sur inventory_hostname, puis collecter un fichier présent sur un seul hôte. La correction inspecte l'arborescence produite côté control node : c'est là que le résultat existe.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Module systemd_service : piloter le service dont vous venez de rapatrier la configuration ou les journaux.
- Module cron : déclencher côté machine la production périodique des fichiers que vous collectez.
- Module mount : quand le volume à récupérer dépasse ce que
fetchsait encaisser, un partage monté fait mieux.