Module get_url Ansible : télécharger un fichier HTTP/HTTPS

ansible.builtin.get_url: télécharge un fichier depuis une URL HTTP/HTTPS/FTP directement sur le managed node (pas de passage par le control node). C'est le module n°1 RHCE 2026 pour récupérer un binaire upstream, une release applicative, un dépôt RPM custom, ou un fichier de config externe.

Options critiques : url:, dest:, mode:, checksum: (vérification d'intégrité), force: true (override), headers: (auth API), validate_certs: (TLS strict).

Ce que vous allez apprendre

• Télécharger un fichier idempotent (Ansible vérifie ETag/Last-Modified par défaut).
• Vérifier l'intégrité avec checksum: sha256:... (mandatory en prod).
• Authentifier un download avec Basic Auth ou Bearer token.
• Désactiver TLS strict avec validate_certs: false (à proscrire en prod).
• Choisir entre get_url: (download fichier) et uri: (appel API).

Prérequis

• Connaître la structure HTTP/HTTPS de base (URL, headers, status code).
• Savoir générer un checksum SHA256 (sha256sum file.tar.gz).

Téléchargement basique

- name: Telecharger un binaire
  ansible.builtin.get_url:
    url: https://example.com/myapp-1.0.0.tar.gz
    dest: /opt/myapp.tar.gz
    mode: "0644"

À la première exécution, Ansible télécharge le fichier. Au second passage, il interroge le serveur et compare les en-têtes ETag ou Last-Modified : rien n'est récupéré si le contenu publié n'a pas bougé, et la tâche ressort sans changement.

Idempotence : get_url ne re-télécharge que si nécessaire. Pratique pour des artefacts versionnés où l'URL contient déjà la version.

Vérification d'intégrité (checksum:)

- name: Telecharger node_exporter avec verification SHA256
  ansible.builtin.get_url:
    url: https://github.com/prometheus/node_exporter/releases/download/v1.11.1/node_exporter-1.11.1.linux-amd64.tar.gz
    dest: /opt/node_exporter.tar.gz
    checksum: sha256:9f5ea48e5bc7b656f8a91a32e7d7deb89f70f73dabd0d974418aca15f37d6810
    mode: "0644"

Comportement :

• Fichier téléchargé avec SHA256 différent de celui spécifié → tâche failed.
• SHA256 identique → idempotent, pas de re-download.

Formats supportés :

• sha256:<hex>, recommandé (collision-résistant).
• sha512:<hex>, plus fort (overkill généralement).
• sha1:<hex>, déprécié (cassé).
• md5:<hex>, ne pas utiliser.
• sha256:https://example.com/SHA256SUMS, récupère depuis URL et matche le filename.

Pattern production : toujours spécifier un checksum pour des binaires critiques. Sans, un MITM ou un repo compromis pousserait n'importe quoi.

Authentification

# Basic Auth (HTTP)
- name: Télécharger private.tar.gz
  ansible.builtin.get_url:
    url: https://repo.private.com/files/private.tar.gz
    dest: /opt/private.tar.gz
    url_username: "{{ vault_repo_user }}"
    url_password: "{{ vault_repo_password }}"
    mode: "0600"

# Bearer Token (API moderne)
- name: Télécharger release-meta.json
  ansible.builtin.get_url:
    url: https://api.github.com/repos/myorg/myapp/releases/latest
    dest: /opt/release-meta.json
    headers:
      Authorization: "Bearer {{ vault_github_token }}"
      Accept: application/vnd.github+json
    mode: "0600"

Stockage des secrets : toujours dans Ansible Vault (vault_* par convention), jamais hardcodé dans le playbook.

force: true (override l'idempotence)

- name: Télécharger dynamic.txt
  ansible.builtin.get_url:
    url: https://example.com/dynamic-content.txt
    dest: /opt/dynamic.txt
    force: true
    mode: "0644"

Par défaut, get_url est idempotent. force: true force le download à chaque run.

Cas d'usage : endpoint qui retourne du contenu dynamique (token CSRF, snapshot horaire), ou rotation d'un artefact.

validate_certs: false (DANGER)

- name: Télécharger file.tar.gz
  ansible.builtin.get_url:
    url: https://internal-dev.lab/file.tar.gz
    dest: /opt/file.tar.gz
    validate_certs: false   # DESACTIVE LE CHECK TLS - DANGER
    mode: "0644"

Désactive la vérification TLS, risque MITM. Cas légitimes : lab interne avec PKI self-signed, test temporaire en dev.

Jamais en prod : si vous voyez validate_certs: false en code de production, c'est une faille de sécurité, corrigez le truststore ou utilisez un certif valide (Let's Encrypt, internal CA).

URL dynamique vs contenu identique

# La query string change a chaque run, mais le contenu serveur est identique
- name: Télécharger static.zip
  ansible.builtin.get_url:
    url: "https://example.com/static.zip?cache_buster={{ ansible_date_time.epoch }}"
    dest: /opt/static.zip
    checksum: sha256:abc123...   # Compare le contenu, pas l URL
    mode: "0644"

Si l'URL change à chaque run mais que le contenu est identique, Ansible ne peut pas savoir via ETag/Last-Modified. Le checksum sauve la mise : Ansible compare le contenu local au checksum attendu, si match, skip même si l'URL diffère.

Combiner avec unarchive:

- name: Telecharger et extraire node_exporter
  block:
    - name: Télécharger node_exporter.tar.gz
      ansible.builtin.get_url:
        url: https://github.com/prometheus/node_exporter/releases/download/v1.11.1/node_exporter-1.11.1.linux-amd64.tar.gz
        dest: /tmp/node_exporter.tar.gz
        checksum: sha256:9f5ea48e5bc7b656f8a91a32e7d7deb89f70f73dabd0d974418aca15f37d6810
        mode: "0644"

    - name: Déployer l'archive opt
      ansible.builtin.unarchive:
        src: /tmp/node_exporter.tar.gz
        dest: /opt/
        remote_src: true
        creates: /opt/node_exporter-1.11.1.linux-amd64/node_exporter

Alternative plus directe : le module de déploiement d'archives accepte une URL avec remote_src: true. Il ne sait en revanche pas vérifier une empreinte : dès que l'intégrité compte, les deux tâches se séparent, un get_url: contrôlé puis un unarchive: qui travaille sur le fichier local.

Pièges courants

Les deux premiers symptômes tiennent au même manque, une empreinte absente : sans elle, le module dépend des en-têtes que le serveur veut bien annoncer, et rien ne détecte un fichier corrompu. Le troisième rappelle une limite connue, l'absence de reprise sur un téléchargement interrompu, qui se contourne par un autre outil sur les très gros fichiers. Le dernier n'est pas un défaut de confort mais une faille.

Symptôme	Cause	Fix
Re-download à chaque run sur URL stable	Pas d'ETag/Last-Modified côté serveur	Utiliser checksum: pour idempotence
Tâche failed silencieusement	Fichier corrompu sans checksum:	Toujours checksum: en prod
Téléchargement de 5Go reprend à 0	get_url ne supporte pas le resume	Utiliser community.general.* ou wget direct
MITM ne déclenche pas d'erreur	validate_certs: false	Ne jamais désactiver TLS sauf cas dev

Glissez pour voir

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

6 questions

6 min.

70% requis

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

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• get_url: télécharge côté managed node (pas via control node).
• Idempotent par défaut via ETag / Last-Modified HTTP.
• checksum: sha256:... mandatory en prod pour vérification d'intégrité.
• headers: pour Bearer tokens et API keys.
• validate_certs: false = DANGER, uniquement en dev avec PKI interne.
• URL dynamique → utiliser checksum: pour idempotence sur le contenu.

Mettre en pratique

Un téléchargement qui se rejoue sans rien changer, c'est la seule façon de vérifier que l'idempotence tient vraiment. Ce lab vous fait poser un fichier sur le managed node, contrôler son intégrité par checksum: sha256:..., puis authentifier une requête protégée avec headers:. Le second passage doit afficher changed=0, et un checksum faux doit faire échouer la tâche plutôt que d'installer un fichier douteux.

Lab pratique

Module get_url : télécharger un fichier HTTP/HTTPS

$ dsoxlab run modules-reseau-get-url

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-reseau-get-url
dsoxlab check modules-reseau-get-url

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• Module stat : Conditionner un téléchargement à l'état réel du fichier déjà présent, checksum compris.
• Module find : Retrouver et nettoyer les archives que get_url dépose au fil des exécutions.
• Modules assert et fail : Arrêter le play proprement quand le fichier récupéré ne correspond pas à ce qui était attendu.

×

📖 Voir la documentation →