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.
L'export de métriques horaire échoue depuis trois jours. vous êtes d'astreinte ce soir. PATCH l'entrée cron managée avec enabled:false — le schedule, la commande, le commentaire restent. Le job est dans un état défini : présent et muté, attendant qu'on vienne le réparer.
{ "enabled": false, "comment": "reindex flaking — see thread" }
le toggle est juste un PATCH · l'entrée ne quitte jamais la liste
Les entrées managées de Hoody Cron sont une ressource JSON : chaque ligne a un id, un schedule, une commande, un commentaire et un flag enabled. Passer enabled à false est un seul PATCH. L'entrée reste dans le crontab pour que la prochaine personne puisse la lire et décider quoi faire.
# mute the flaky entry — entry stays in the crontab curl -X PATCH \ https://cron.containers.hoody.com/users/me/entries/e7d3 \ -H "Content-Type: application/json" \ -d '["enabled": false, "comment": "flake le lundi avec prod-db — voir #pager"]' # response HTTP/1.1 200 OK { "id":"e7d3", "enabled":false, "schedule":"0 * * * *", "command":"/srv/cron/metrics-export.sh", ... }
# the entry is still on the list — just not running curl GET https://cron.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "enabled":true, ... }, { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" }, { "id":"9b21", "enabled":true, ... } ] # present and muted — the on-call hand-off has somewhere to point
Le PATCH ne supprime pas, ne réécrit pas et ne déplace pas l'entrée — il bascule un booléen. La passation tient en une ligne : 'l'entrée metrics-export e7d3 est mutée, voir hoody-cron, jetez un œil.'
Une entrée sur un crontab Hoody est toujours dans exactement un de trois états. Chaque état a des conséquences différentes pour ce que sait l'équipe le lendemain matin.
L'entrée est dans le crontab et le daemon cron du kernel la prend toutes les heures. Les échecs réveillent l'astreinte. C'est le défaut pour les jobs en bonne santé.
enabled:false. L'entrée est toujours dans le crontab pour que l'équipe puisse lire son schedule, sa commande et son commentaire. Le daemon cron la saute. Pas de page à 2h du matin demain, personne n'oublie qu'elle existe.
Une fois que vous DELETE, le schedule, la commande, le commentaire, la raison — tout quitte le crontab. Le prochain d'astreinte n'a rien à grep. Mute est le choix qui garde la mémoire.
Mute est l'état du milieu que la plupart des schedulers n'ont pas de nom pour. Hoody Cron en a un, parce qu'enabled est un champ first-class sur l'entrée managée.
Quand vous ne peux pas réparer un job ce soir, la question est quelle forme prend son absence demain. Mute rend cette forme lisible.
Au lieu de coller un thread Slack ou une PR avec une ligne supprimée, le message est l'id de l'entrée. L'astreinte de demain ouvre l'URL cron, lit le commentaire, et sait par où commencer.
GET /entries renvoie enabled:false à côté du commentaire. Construis un panneau d'audit en filtrant. Qui a muté, pourquoi, et il y a combien de temps est dans le JSON, pas dans les DM de quelqu'un.
Quand le problème sous-jacent est réglé, un PATCH de plus avec enabled:true remet l'entrée sur schedule. Pas de réécriture de l'expression cron, pas de risque de coquille, pas de cycle commit-and-deploy.
Les chiffres viennent de la surface des entrées managées de Hoody Cron, pas de benchmarks inventés.
PATCH /users/[user]/entries/[id] accepte un body partiel. Envoyez ["enabled":false] seul — schedule, commande et commentaire restent intouchés.
Les 5 champs du schedule, la commande, le commentaire, expires_at, et l'id persistent à travers le mute. Le crontab kernel reflète toujours l'entrée — juste commentée par le service cron.
Pas d'édition de fichier, pas de PR, pas de déploiement. L'aller-retour mute est un seul appel HTTP depuis n'importe quel terminal, y compris celui sur votre téléphone.
D'après l'API Hoody Cron Managed Entries : chaque entrée porte un booléen enabled à côté du schedule, de la commande, du commentaire et d'un expires_at optionnel. PATCH accepte des bodies partiels.
Disabled n'est pas deleted — l'entrée attend qu'on vienne la réparer.
Les façons habituelles dont les équipes 'parquent temporairemenvous une ligne cron instable. Chacune est destructive, perd de l'info, ou se trouve à deux PRs de la production.
Arrêtez de supprimer les jobs instables à 2h du matin. Mutez-les, laissez une note, et laissez l'astreinte de demain lire le JSON.