Conteneurs
Une alternative au cron Docker qui surveille aussi les CronJobs Kubernetes
Arrêtez de faire tourner des daemons cron dans des conteneurs. Laissez SteadyCron déclencher vos tâches depuis l'extérieur, ou gardez votre cron Docker/K8s existant et surveillez-le simplement avec un heartbeat.
Le problème
Le cron dans un conteneur est une source récurrente de problèmes : le daemon a besoin de sa propre supervision de processus dans une image autrement mono-processus, les journaux restent piégés dans le stdout du conteneur au lieu de votre agrégateur, et le fuseau horaire du conteneur dérive silencieusement de ce que vous attendez. Les CronJobs Kubernetes résolvent le problème du daemon mais pas celui de la visibilité — un CronJob qui arrête silencieusement de créer des Pods (un planning en pause, une mauvaise image, une limite de backoff épuisée) échoue de façon totalement silencieuse. Rien dans kubectl ne vous dit qu'une tâche aurait dû tourner il y a une heure.
Comment SteadyCron le résout
- 1 Option A — sortir complètement le déclencheur du conteneur : exposez un simple point de terminaison HTTP dans votre app et laissez SteadyCron l'appeler selon le planning, avec réessais et délai d'expiration. Pas de daemon cron, pas de processus supplémentaire, pas de surprise de fuseau horaire dans l'image.
- 2 Option B — garder votre cron Docker ou CronJob Kubernetes existant, et ajouter un heartbeat : la tâche ping l'URL de ping de SteadyCron en cas de succès (ou /fail en cas d'erreur) comme dernière étape.
- 3 Dans les deux cas, SteadyCron compare attendu vs. réel : si le ping (ou l'appel HTTP) n'arrive pas dans la période de grâce que vous avez définie, le check passe de à l'heure à manqué.
- 4 Vous êtes alerté au moment où un CronJob arrête de se déclencher — pas quand quelqu'un remarque que le rapport nocturne n'est jamais arrivé.
# À ajouter à un CronJob Kubernetes existant : ping en cas de succès, alerte si manqué/échoué
command: ["/bin/sh", "-c"]
args:
- >
./run-job.sh &&
curl -fsS https://ping.steadycron.com/$PING_TOKEN ||
curl -fsS https://ping.steadycron.com/$PING_TOKEN/fail
Jobs
| weekly-digest-email | HTTP | 0 9 * * 1 | in 2 days | 3 days ago | ||
| nightly-db-backup | Heartbeat | 0 2 * * * | in 19 h | 5 h ago | ||
| stripe-reconciliation | HTTP | 0 */4 * * * | in 38 min | 3 h ago | ||
| cache-warmup | HTTP | */15 * * * * | in 11 min | now | ||
| search-index-sync | Heartbeat | */30 * * * * | in 6 min | 24 min ago |
| seed-test-data | HTTP | 0 4 * * * | in 14 h | 10 h ago | ||
| preview-env-cleanup | Heartbeat | 0 */6 * * * | in 2 h | 4 h ago | ||
| trial-expiry-sweep | HTTP | 0 6 * * * | — | yesterday |
Statut, planning et dernière exécution de chaque tâche — en un coup d’œil.
Deux façons de corriger le cron en conteneur, selon ce que vous contrôlez
Si vous possédez le code de l’app : supprimez complètement le cron intra-conteneur. Ajoutez un point de terminaison HTTP qui exécute la logique de la tâche, et laissez SteadyCron l’appeler depuis l’extérieur selon le planning — avec son propre réessai/backoff et un journal de requêtes complet. Le conteneur revient à un seul processus, comme prévu, et le planning vit dans SteadyCron au lieu d’un fichier crontab qui doit survivre à chaque reconstruction d’image.
Si vous ne voulez pas toucher au déclencheur (un CronJob Kubernetes que
quelqu’un d’autre possède, un entrypoint Docker que vous préférez ne pas
refactoriser tout de suite) : laissez-le tourner et ajoutez un check
heartbeat. Un curl à la fin du script, et
SteadyCron sait si la tâche a tourné — et vous alerte au moment où ce n’est
pas le cas, au lieu que vous le découvriez via un symptôme en aval.
Pourquoi le cron en conteneur casse spécifiquement de cette façon
- Docker : un daemon cron dans un conteneur est un second processus de
longue durée qui rivalise avec le
PID 1que votre orchestrateur supervise réellement. Si le daemon meurt, le conteneur a toujours l’air sain —docker psaffiche « en cours » — alors que rien ne se déclenche plus à l’intérieur. - CronJobs Kubernetes : le planning lui-même est fiable (le contrôleur
fait partie du control plane), mais l’échec est invisible par conception.
Un CronJob qui atteint son
backoffLimit, unstartingDeadlineSecondstrop serré dans un cluster chargé, ou un mauvais tag d’image échouent tous de la même façon : pas de Pod, pas d’erreur dans vos tableaux de bord, juste une tâche qui a silencieusement arrêté de se produire.
Pour les détails spécifiques à la plateforme si vous déboguez en direct : cron Docker ne tourne pas · CronJob Kubernetes ne tourne pas.
Idéal pour
- Les tâches batch nocturnes, sauvegardes et générations de rapports actuellement déclenchées par un daemon cron intégré à une image Docker.
- Les CronJobs Kubernetes pour le nettoyage, la synchronisation ou la maintenance, où une exécution manquée passe facilement inaperçue jusqu’à s’accumuler.
- Les équipes qui évoluent vers un modèle où le planning vit hors du conteneur, pour que la mise à l’échelle, le redéploiement ou la migration de cluster ne fassent pas perdre le planning avec le Pod.
Documentation associée
Ne l’apprenez plus à vos dépens
Commencez avec l’offre gratuite — sans carte bancaire.
Commencer gratuitement