Module cron Ansible : planifier des jobs idempotents

ansible.builtin.cron gère les jobs cron avec idempotence garantie via le name:. Chaque job est identifié par son nom unique que Ansible inscrit en commentaire (#Ansible: <name>) au-dessus de la ligne du job. À chaque run, le job est mis à jour au lieu d'être empilé.

Le module sait gérer :

• la crontab utilisateur (crontab -l), défaut ;
• les fichiers /etc/cron.d/* via cron_file:, préférable pour la lisibilité ;
• les variables d'environnement (MAILTO, PATH) au-dessus des jobs (env: true) ;
• la désactivation (job commenté mais conservé pour référence).

Ce que vous allez apprendre

• La différence crontab user vs /etc/cron.d/, quand utiliser quoi.
• Le mécanisme du name:, pourquoi il est obligatoire et comment Ansible s'en sert.
• Comment poser des variables d'environnement (MAILTO, PATH) avec env: true.
• L'option disabled: true, désactiver sans supprimer.

Prérequis

• Connaître la syntaxe cron (5 champs : minute, hour, day, month, weekday).
• Avoir cronie (RHEL) ou cron (Debian) installé sur le managed node, généralement présent par défaut.

Mécanisme du name: et idempotence

name: est obligatoire et sert d'identifiant unique pour le job. Ansible l'inscrit en commentaire au-dessus de la ligne :

#Ansible: Backup horaire
0 * * * * root /usr/local/bin/backup.sh

Au prochain run, Ansible cherche #Ansible: Backup horaire, remplace la ligne juste en dessous par le job actualisé. Conséquence : idempotence garantie, jamais de duplication, jamais d'orphelin.

Ne jamais modifier le commentaire #Ansible: à la main, Ansible perdrait le repère et empilerait un nouveau job.

crontab utilisateur, usage par défaut

- name: Backup quotidien dans la crontab de root
  ansible.builtin.cron:
    name: "Backup base de donnees"
    minute: "0"
    hour: "2"
    job: "/usr/local/bin/backup-db.sh > /var/log/backup.log 2>&1"

Sans cron_file:, le job va dans crontab -l -u root (ou l'utilisateur spécifié via user:). C'est l'équivalent de crontab -e exécuté en idempotent.

Inconvénient : la crontab user n'est pas dans /etc/, donc pas de configuration as code visible avec un simple cat /etc/cron.d/. Préférer cron_file: pour la traçabilité.

/etc/cron.d/, pattern préféré pour les rôles

- name: Healthcheck monitoring (toutes les 5 min)
  ansible.builtin.cron:
    name: "Healthcheck monitoring"
    minute: "*/5"
    job: "/usr/local/bin/healthcheck.sh"
    cron_file: monitoring
    user: root

cron_file: monitoring crée le fichier /etc/cron.d/monitoring. Plusieurs jobs peuvent y être ajoutés via plusieurs tâches cron: avec le même cron_file: mais des name: différents.

Avantages :

• Fichier visible dans /etc/cron.d/, review facile.
• Spécifie le user: sur chaque ligne (contrairement à crontab user où tout est sous l'utilisateur courant).
• Versionnable proprement (un fichier par rôle).

Variables d'environnement, env: true

- name: Definir MAILTO pour les jobs lab
  ansible.builtin.cron:
    name: MAILTO
    env: true
    value: admin@lab.local
    cron_file: lab-rhce
    user: root

env: true change la sémantique : name: devient le nom de la variable, value: est sa valeur. La ligne générée est MAILTO="admin@lab.local" (Ansible quote automatiquement).

Variables utiles :

• MAILTO, destinataire des emails de cron (sortie stderr du job).
• PATH, défini par défaut très restrictif sur la plupart des systèmes (/usr/bin:/bin). Override si vos scripts ont besoin de /opt/myapp/bin.
• SHELL, défaut /bin/sh. Override si vos jobs ont besoin de bash.

Désactiver un job sans le supprimer

- name: Suspendre temporairement le backup
  ansible.builtin.cron:
    name: "Backup base de donnees"
    minute: "0"
    hour: "2"
    job: "/usr/local/bin/backup-db.sh"
    disabled: true

disabled: true commente la ligne du job dans la crontab/le fichier, le job est conservé pour référence mais ne s'exécute plus. Pour le réactiver, repasser disabled: false.

Cas d'usage : maintenance programmée, debugging d'un script qui plante, plans annulés.

Schedules courants, racourcis

Forme	Équivalent	Usage
special_time: hourly	0 * * * *	Toutes les heures
special_time: daily	0 0 * * *	Tous les jours à minuit
special_time: weekly	0 0 * * 0	Tous les dimanches à minuit
special_time: monthly	0 0 1 * *	Le 1er de chaque mois à minuit
special_time: reboot	@reboot	À chaque démarrage

Glissez pour voir

- name: Job hourly avec raccourci
  ansible.builtin.cron:
    name: "Healthcheck rapide"
    special_time: hourly
    job: "/usr/local/bin/healthcheck.sh"

special_time: exclut les options minute/hour/day/month/weekday, utiliser soit l'un, soit les autres.

Suppression, state: absent

- name: Supprimer l ancien job de migration
  ansible.builtin.cron:
    name: "Migration v1 vers v2"
    state: absent
    cron_file: lab-rhce
    user: root

Ansible cherche le commentaire #Ansible: Migration v1 vers v2 et supprime cette ligne + la ligne du job juste en dessous. Sans state: absent, un job renommé/déplacé devient orphelin, toujours faire le ménage explicite.

Pièges courants

La première ligne est la panne emblématique du module, et elle a toujours la même racine : le name: a changé, donc le marqueur d'idempotence aussi. Les trois suivantes ne sont pas des défauts du module mais de son environnement d'exécution, un service d'envoi de courrier absent, un chemin de recherche réduit, un fichier dont les permissions ne conviennent pas. La dernière rappelle qu'un fichier parfaitement écrit ne sert à rien si le service de planification ne tourne pas.

Symptôme	Cause	Fix
Jobs empilés à chaque run	name: modifié entre 2 runs	Ne jamais changer le name: (clé d'identification)
MAILTO=admin@lab.local n'envoie rien	Pas de MTA installé	Installer postfix ou rediriger les jobs avec > /dev/null 2>&1
PATH: non pris en compte	env: true oublié, name: PATH créé un job nommé "PATH"	Ajouter env: true
cron_file: créé mais perms incorrectes	Le module ne gère pas les permissions, Linux veut 0644	Combiner avec une tâche file: mode: "0644" post-création
Job ne tourne pas	Service crond arrêté	systemd_service: name=crond state=started enabled=true

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

• name: est obligatoire et sert de clé d'idempotence, ne jamais le modifier après création.
• cron_file: dans /etc/cron.d/ est préférable à la crontab user, review et versioning faciles.
• env: true pour les variables (MAILTO, PATH, SHELL), pas dans la même tâche que les jobs.
• disabled: true désactive sans supprimer, utile pour les maintenances.
• special_time: hourly|daily|weekly|monthly|reboot raccourcit les schedules courants.

Mettre en pratique

Un job cron dupliqué au second passage est le symptôme classique d'un name: mal compris. Le lab vous fait écrire dans /etc/cron.d/ un fichier portant une variable d'environnement et deux jobs planifiés, puis rejouer le playbook pour exiger changed=0. Les tests relisent le fichier déposé sur db1.lab et cherchent les marqueurs #Ansible: qui servent de clé d'idempotence, seule preuve qu'aucune ligne n'a été ajoutée deux fois.

Lab pratique

Module cron : planifier des jobs idempotents

$ dsoxlab run modules-services-cron

Environnement : VM·Durée : ~30 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-services-cron
dsoxlab check modules-services-cron

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 user : créer le compte sous lequel le job doit tourner, avec le bon shell et les bons groupes.
• Module sudoers : donner à ce compte les seuls privilèges dont son job a besoin, avec validation visudo.
• Module getent : vérifier que l'utilisateur existe réellement avant de lui attacher une crontab.

×

📖 Voir la documentation →