GUIDE TECHNIQUE · RUNDECK
Rundeck : Planification, notifications et reprise
Planifier et superviser un job Rundeck sans provoquer de chevauchement d'exécutions, avec notification, politique de reprise et escalade après échec.
L’ESSENTIEL EN BREF
Les étapes clés
Ce guide présente 4 étapes, de « Déterminer cadence et fenêtres de maintenance » à « Tester reprise et arrêt ».
Avant de commencer : Job de recette idempotent testé en exécution manuelle.
01 · CADRAGE
Périmètre et résultat visé
Résultat attendu : La planification correspond au fuseau attendu.
Public concerné : Responsables de production, ordonnanceurs et équipes RUN
Rundeck Jobs et exécutions planifiées ; fonctions avancées de calendriers et blackout windows réservées à certaines éditions commerciales.
Contrôlez les versions, les droits et les options disponibles dans votre environnement avant de suivre la procédure.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Job de recette idempotent testé en exécution manuelle.
- Fuseau horaire, fenêtre d'exploitation et propriétaire d'astreinte documentés.
- Canal d'alerte et politique de rejouabilité définis.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Suivez les étapes dans l’ordre et contrôlez chaque résultat avant de poursuivre. Renseignez les paramètres adaptés à votre environnement.
ÉTAPE 1 / 4
Déterminer cadence et fenêtres de maintenance
La fréquence doit servir un besoin opérationnel et respecter les fuseaux.
- Définir heure et timezone du projet.
- Identifier les plages pendant lesquelles le job ne doit pas s'exécuter.
# Exemple de cron standard pour tous les jours à 02:00
0 2 * * *À vérifier : Une fréquence et un fuseau uniques sont consignés.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 2 / 4
Empêcher les doublons d'exécution
Deux runs concurrents peuvent agir sur la même ressource et provoquer une collision.
- Régler les limites de concurrence et timeouts disponibles pour ce job.
- Définir un comportement explicite si la précédente exécution est encore active.
# Politique à valider :
# 1 exécution active au maximum
# timeout correspondant à la fenêtre RUNÀ vérifier : Une exécution longue ne provoque pas une deuxième écriture concurrente.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 3 / 4
Configurer la gestion des échecs
Un code retour non nul doit déclencher un diagnostic compréhensible.
- Ajouter un error handler adapté et documenter les conditions de reprise.
- Configurer une notification d'échec vers un canal exploité, sans exporter de secrets.
# Exemple de message attendu :
# JOB=verifier-hote-recette STATUS=FAILED EXECUTION_ID=...À vérifier : Le responsable reçoit une alerte exploitable et corrélable.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 4 / 4
Tester reprise et arrêt
La robustesse se mesure dans les scénarios non nominaux.
- Simuler un retour non nul sur le laboratoire et vérifier la notification.
- Tester une nouvelle exécution après correction et contrôler la traçabilité des deux runs.
# Step d'échec contrôlé sur recette :
exit 1À vérifier : L'échec est visible puis la reprise produit une nouvelle trace distincte.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
RÉFÉRENCES TECHNIQUES
Documentation officielle
Retrouvez les prérequis, les fonctionnalités et les versions prises en charge par Rundeck. Vérifiez les commandes sur un environnement de test avant leur utilisation en production.
05 · RECETTE
Comment vérifier que tout fonctionne ?
La planification correspond au fuseau attendu.
Le chevauchement d'exécution est limité ou interdit.
Un échec produit une alerte et un historique avec responsable identifié.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Le job ne démarre pas
Cause probable : Planification désactivée ou timezone incorrecte
Que faire : Vérifier les paramètres du job et les exclusions de calendrier.
Plusieurs runs simultanés
Cause probable : Concurrence non bornée ou jobs dupliqués
Que faire : Fixer une limite d'exécutions et identifier les autres déclencheurs.
Aucune notification
Cause probable : Destinataire ou plugin non configuré
Que faire : Tester le canal indépendamment puis reproduire un échec de recette.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Quand utiliser un retry ?
Uniquement si l'opération est rejouable, avec limites et temporisation explicites.
Quelle donnée doit figurer dans une alerte ?
Job, projet, exécution, cible, statut et lien de diagnostic ; jamais des secrets.
Le calendrier de maintenance est-il disponible partout ?
Non. Certaines fonctionnalités avancées sont propres aux éditions commerciales.
AUTRES TECHNOLOGIES
Guides complémentaires
VOTRE ENVIRONNEMENT
Besoin d’aller plus loin sur votre environnement ?
Automatisation, sécurité et exploitation : échangeons sur vos pratiques Rundeck.
Échanger avec ADN Consulting