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 →