Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Conteneurs·Snapshots
TYPEDébloqué
ÉTAPEGain rapide
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEGain rapide
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEGain rapide
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEGain rapide
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevOps et infra
POURÉquipes de devs
SERVICESCron
POURQUOI HOODYHTTP-natif
use-cases / cron-that-expires-itself / hero
HOODY CRON / ENTRÉES AUTO-EXPIRANTES
Le job cron qui se supprime quand vous avez fini
vous chasses un bug intermittent ? Dump l'arbre de processus toutes les minutes pendant 48 heures, puis plus jamais. POST une entrée cron managée avec expires_at fixé, et la planification a une demi-vie — pas de rappel, pas de PR de cleanup, pas d'entrée obsolète six mois plus tard.
cron.containers.hoody.com
https://cron.containers.hoody.com/api/v1/cron/users/me/entriesactif
idplanificationcommandeexpirationstatut
- a1f2*/5 * * * *curl -fsS http://prod/healthjamaispermanent
- c4b90 3 * * */usr/local/bin/backup.shjamaispermanent
- e7d3* * * * *pgrep auth | tee -a tree.log2026-05-06T11:14:00Zexpire
- 9b21@hourlypsql -c 'VACUUM ANALYZE'jamaispermanent
- f0a80 9 * * 1-5/srv/cron/digest.sh2026-05-31T09:00:00Zactif
entrée e7d3expire dans 02:14:37
POST/users/me/entriescorps de requête
{ "schedule": "* * * * *", "command": "pgrep auth | tee -a tree.log", "expires_at": "2026-05-06T11:14:00Z" }
POST /users/me/entries avec expires_at — l'entrée tourne chaque minute, puis se retire à la deadline
use-cases / cron-that-expires-itself / lifecycle
Une planification avec une demi-vie
Trois moments. Créez l'entrée avec une deadline. La planification tourne toute seule. À expires_at, l'entrée se supprime — et votre crontab revient à ce qu'il était avant que vous commenciez à debug.
Cycle de vie d'une entrée auto-expirantecréer → exécuter → expirer
01 / CRÉER
POST avec expires_at
Envoyez une entrée cron managée à l'API avec schedule, command, et un timestamp expires_at à 48 heures. vous recevez en retour un id et une confirmation que l'entrée est enabled.
02 / EXÉCUTER
Tourne sur planification
L'entrée s'exécute à chaque tic de son expression cron — chaque minute, chaque heure, ce que vous avez réglé. Comportement identique à une entrée permanente, avec une discrète différence.
03 / EXPIRER
Se supprime à la deadline
Quand l'horloge dépasse expires_at, l'entrée est retirée. Pas de run final, pas de ligne zombie, pas de cleanup manuel. GET /entries renvoie la liste qu'il aurait renvoyée sans vous.
Pas de script de cleanup. Pas de rappel calendrier. Pas de thread d'équipe « qui possède ça ? » dans six mois. L'entrée savait quand elle devait mourir et elle l'a fait.
use-cases / cron-that-expires-itself / mechanism
Deux curls et une horloge
Crée l'entrée avec un POST. Vérifie qu'elle est partie avec un GET 49 heures plus tard. Tout le mécanisme c'est deux appels HTTP et un timestamp — pas de daemon cron à SSH, pas de /etc/crontab à éditer.
create.sh
POST# create a self-deleting cron entry curl -X POST \ https://cron.containers.hoody.com/users/me/entries \ -H "Content-Type: application/json" \ -d '["schedule":"* * * * *","command":"pgrep auth | tee -a tree.log","expires_at":"2026-05-06T11:14:00Z"]' # response HTTP/1.1 201 Created { "id":"e7d3", "expires_at":"2026-05-06T11:14:00Z", "enabled":true }
verify.sh
GET# 49 hours later — list is back to normal curl GET https://cron.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "expires_at":null, ... }, { "id":"c4b9", "expires_at":null, ... }, { "id":"9b21", "expires_at":null, ... } ] # e7d3 was here. e7d3 deleted itself.
Le champ expires_at est le contrat. vous n'avez pas à vous souvenir de nettoyer parce que se souvenir ne fait pas partie du protocole — la deadline, oui.
use-cases / cron-that-expires-itself / powers
Ce que la demi-vie débloque
Une fois que la planification a une date d'expiration, trois choses cessent d'être votre problème : la dérive, l'oubli et la fatigue d'audit. Le crontab reste propre par défaut.
PAS DE DÉRIVE
Le crontab ne peut pas s'accumuler
Chaque entrée « je vais juste temporairement… » a une deadline intégrée. Le crontab s'auto-purge — pas de balayage de cleanup trimestriel, pas de lignes obsolètes que personne ne veut supprimer parce que personne ne sait ce qu'elles font.
PAS D'OUBLI
Oublier, c'est ok
vous n'avez pas à vous souvenir de retirer l'entrée. vous n'avez pas à mettre un rappel calendrier. vous n'avez pas à filer une PR de cleanup. La deadline est le rappel — et elle se déclenche toujours.
AUDITABLE
Les logs survivent à l'entrée
L'entrée est partie mais les runs non. Chaque exécution garde sa ligne de log, son code de sortie et son timestamp — donc la trace de « ça a tourné 48 heures puis s'est arrêté » est entièrement reconstructible après coup.
use-cases / cron-that-expires-itself / capacity
Pas cher, rapide, pluriel
Les entrées auto-expirantes coûtent autant que les permanentes. Empile-en autant que vous voulez — l'API a été pensée pour le cas où chaque debugger de l'équipe a trois ou quatre jobs temporaires en cours.
- GRANULARITÉ MIN1 min
Expressions cron standard, jusqu'à la résolution d'une minute. Le champ expires_at accepte n'importe quel timestamp RFC 3339.
- PAR COMPTE100s
Largement de quoi loger une équipe de debuggers faisant tourner chacun une poignée de probes temporaires à côté des jobs permanents.
- ÉTAPES MANUELLES0 cleanup
Pas d'appel DELETE à se rappeler. Pas de ticket « nettoyer les vieux crons » sur le backlog. L'entrée gère sa propre fin de vie.
Les limites scalent avec le tier du service cron sur votre compte. Les logs sont conservés selon la fenêtre de rétention standard de Hoody Cron après l'expiration de l'entrée elle-même.
use-cases / cron-that-expires-itself / punchline
Le travail temporaire ne devrait pas laisser d'entrées crontab permanentes.
l'ancienne façonla façon demi-vie
SANS expires_atecho '* * * * * pgrep auth …' >> /etc/crontabet un rappel calendrier que vous allez ignorer
AVEC expires_atPOST /entries [ expires_at: "+48h" ]la planification se supprime à la deadline
use-cases / cron-that-expires-itself / replaces
Ce que ça remplace
Les patterns que les développeurs sortent quand ils ont besoin d'une ligne cron one-shot. Chacun laisse une trace. expires_at l'efface.
- Élagage manuel du crontabUn grep hebdo pour les commentaires « DELETE_AFTER »
- Notes « TODO: remove this »Collées sur l'écran. Disparaît après un sprint.
- Lifecycle cron TerraformDeux PR pour planifier un travail one-off
- Jobs janitor customUn second cron dont le seul job est de tuer le premier
- Threads de rappel SlackUn humain futur comme garbage collector
- Issue GitHub + auto-audit cronUne réunion hebdo pour parler de lignes cron
use-cases / cron-that-expires-itself / cta
Le travail temporaire ne devrait pas laisser d'entrées crontab permanentes.
use-cases / cron-that-expires-itself / related