Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Containers·Snapshots
TypeDéverrouilléÉtapeGain rapideDifficultéSimpleTravailAutomatiser une tâchePourDevOps & infraPourÉquipes de devServicesCronPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeGain rapideDifficultéSimpleTravailAutomatiser une tâchePourDevOps & infraPourÉquipes de devServicesCronPourquoi HoodyHTTP-natif
use-cases / cron-that-expires-itself / hero
HOODY CRON / ENTRÉES À AUTO-EXPIRATION
La tâche cron qui se supprime elle-même quand vous avez fini
Vous chassez un bug intermittent ? Dumpez l'arbre de processus chaque minute pendant 48 heures, puis plus jamais. POSTez une entrée cron managée avec expires_at fixé, et le planning a une demi-vie — pas de rappel, pas de PR de nettoyage, pas d'entrée orpheline six mois plus tard.
cron.containers.hoody.com
https://cron.containers.hoody.com/api/v1/cron/users/me/entrieslive
idplanningcommandeexpirestatut
- a1f2*/5 * * * *curl -fsS http://prod/healthjamaispermanente
- c4b90 3 * * */usr/local/bin/backup.shjamaispermanente
- e7d3* * * * *pgrep auth | tee -a tree.log2026-05-06T11:14:00Zexpire bientôt
- 9b21@hourlypsql -c 'VACUUM ANALYZE'jamaispermanente
- f0a80 9 * * 1-5/srv/cron/digest.sh2026-05-31T09:00:00Zactive
entrée e7d3expire dans 02:14:37
POST/users/me/entriescorps de la 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 supprime elle-même à l'échéance
use-cases / cron-that-expires-itself / lifecycle
Un planning à demi-vie
Trois moments. Créez l'entrée avec une échéance. Le planning tourne tout seul. À expires_at, l'entrée se supprime — et votre crontab redevient ce qu'il était avant que vous ne commenciez à déboguer.
Cycle de vie d'une entrée à auto-expirationcréer → tourner → expirer
01 / CRÉER
POST avec expires_at
Envoyez à l'API une entrée cron managée avec un planning, une commande et un timestamp expires_at à 48 heures. Vous recevez un id et la confirmation que l'entrée est activée.
02 / TOURNER
Tourne selon le planning
L'entrée s'exécute à chaque tick de son expression cron — chaque minute, chaque heure, comme vous le voulez. Comportement identique à une entrée permanente, à une discrète différence près.
03 / EXPIRER
Se supprime à l'échéance
Quand l'horloge dépasse expires_at, l'entrée est retirée. Pas d'exécution finale, pas de ligne zombie, pas de nettoyage manuel. GET /entries renvoie la liste qu'il aurait sans vous.
Pas de script de nettoyage. Pas de rappel calendrier. Pas de fil « qui possède ça ? » à l'échelle de l'équipe 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éez l'entrée avec un POST. Vérifiez qu'elle est partie avec un GET 49 heures plus tard. Tout le mécanisme tient en deux appels HTTP et un timestamp — pas de daemon cron à atteindre en SSH, pas de /etc/crontab à éditer.
create.sh
POST# create a self-deleting cron entry curl -X POST \ https://cron.containers.hoody.com/api/v1/cron/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/api/v1/cron/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 — l'échéance, si.
use-cases / cron-that-expires-itself / powers
Ce que la demi-vie débloque
Une fois que le planning a une date d'expiration, trois choses cessent d'être votre problème : la dérive, la surveillance 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… » porte une échéance intégrée. Le crontab s'auto-élague — pas de grand ménage trimestriel, pas de lignes orphelines que personne ne veut supprimer parce que personne ne sait à quoi elles servaient.
PAS DE SURVEILLANCE
Oublier ne pose pas de problème
Vous n'avez pas à vous souvenir de retirer l'entrée. Vous n'avez pas à poser un rappel calendrier. Vous n'avez pas à déposer une PR de nettoyage. L'échéance est le rappel — et elle se déclenche toujours.
AUDITABLE
Les logs survivent à l'entrée
L'entrée est partie mais pas les exécutions. Chaque exécution garde sa ligne de log, son code de sortie et son timestamp — la trace « ça a tourné 48 heures puis s'est arrêté » reste pleinement reconstituable après coup.
use-cases / cron-that-expires-itself / capacity
Bon marché, rapide, en grand nombre
Les entrées à auto-expiration coûtent autant que les permanentes. Empilez-en autant que nécessaire — l'API a été pensée pour le cas où chaque débogueur de l'équipe a trois ou quatre tâches temporaires en cours.
- GRANULARITÉ MIN1 min
Expressions cron standard, jusqu'à la résolution d'une minute. Le champ expires_at accepte tout timestamp RFC 3339.
- PAR COMPTE100s
De quoi voir venir : une équipe de débogueurs lançant chacun une poignée de sondes temporaires en plus des tâches permanentes.
- ÉTAPES MANUELLES0 nettoyage
Pas d'appel DELETE à mémoriser. Pas de ticket « nettoyer les vieux crons » dans le backlog. L'entrée gère sa propre fin de vie.
Les limites évoluent selon le palier du service cron de votre compte. Les logs sont conservés selon la fenêtre de rétention standard de Hoody Cron, après que l'entrée elle-même a expiré.
use-cases / cron-that-expires-itself / punchline
Un travail temporaire ne devrait pas laisser d'entrées crontab permanentes.
à l'anciennefaçon demi-vie
SANS expires_atecho '* * * * * pgrep auth …' >> /etc/crontabet un rappel calendrier que vous ignorerez
AVEC expires_atPOST /entries [ expires_at: "+48h" ]le planning se supprime à l'échéance
use-cases / cron-that-expires-itself / replaces
Ce que cela remplace
Les patterns que les développeurs sortent quand il leur faut une ligne cron à usage unique. Chacun laisse une trace. expires_at fait le ménage.
- Élagage manuel du crontabUn grep hebdomadaire pour les commentaires « DELETE_AFTER »
- Notes « TODO : retirer ça »Collées sur l'écran. S'effacent après un sprint.
- Cycle de vie cron TerraformDeux PR pour planifier un travail unique
- Tâches de nettoyage maisonUn second cron dont le seul boulot est de tuer le premier
- Fils de rappel SlackUn humain futur en guise de garbage collector
- Issue GitHub + auto-audit cronUne réunion hebdo pour parler des lignes cron
use-cases / cron-that-expires-itself / cta
Un travail temporaire ne devrait pas laisser d'entrées crontab permanentes.
use-cases / cron-that-expires-itself / related
Découvrez les autres
