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).

Pressé ? Les patterns cron — avec sécurité

# Préférer /etc/cron.d/<projet> à crontab utilisateur (lisibilité + permissions explicites)
- ansible.builtin.cron:
    name: "Backup quotidien myapp"
    minute: "30"
    hour: "2"
    job: "/usr/local/bin/backup-myapp.sh"
    user: root
    cron_file: myapp-backup     # crée /etc/cron.d/myapp-backup
  become: true

# Variable d'env (MAILTO) — première tâche du fichier
- ansible.builtin.cron:
    name: MAILTO
    env: true
    value: ops@example.com
    cron_file: myapp-backup
  become: true

# Suppression d'un job obsolète (par name)
- ansible.builtin.cron:
    name: "Backup quotidien myapp"
    cron_file: myapp-backup
    state: absent
  become: true

Sécurité non négociable :

• name: unique et stable — c’est l’identité du job côté Ansible. Modifier le name: revient à supprimer + recréer ; ne jamais le rendre dynamique avec une variable qui change.
• Préférer cron_file: (/etc/cron.d/<nom>) à la crontab utilisateur — fichier visible en revue, permissions explicites root:root mode 0644, audit plus simple.
• Le script appelé doit être en 0755 root:root s’il tourne en root, et ne jamais accepter de variables d’env non maîtrisées — un cron lance dans un environnement minimal (PATH court).
• MAILTO non vide pour qu’un job qui échoue le signale plutôt que de mourir en silence.

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.

Lab d'accompagnement

Cette page est jumelée au lab labs/modules-services/cron/ dans stephrobert/ansible-training. Détails et commandes en bas de page : Pratiquer dans le lab.

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

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

À 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.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/modules-services/cron/ dans stephrobert/ansible-training.

Challenge — sur db1.lab :

1. Créer /etc/cron.d/lab-rhce avec :
   • MAILTO=admin@lab.local
   • Job Backup horaire à minute 0 de chaque heure.
   • Job Cleanup quotidien à 3h du matin.
2. Vérifier l’idempotence (pas de duplication au second run).

Validation pytest+testinfra :

ansible-playbook solution.yml
ansible-playbook solution.yml  # Doit etre ok=N, changed=0
pytest -v labs/modules-services/cron/challenge/tests/

5 tests vérifient l’existence du fichier, la variable MAILTO, les 2 jobs et les markers #Ansible:.

Prochaines étapes

Module systemd_service Démarrer et activer crond/cronie après installation

Module package Installer cronie sur RHEL ou cron sur Debian

Module file Pour ajuster les permissions du fichier cron généré (0644)

Module dnf — options RHEL enablerepo, security, exclude — opérations de patching à orchestrer via cron

×

📖 Voir la documentation →