Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoEstándarEtapaVictoria rápidaDificultadSimpleTrabajoAutomatizar tareaParaEquipos de desarrolloParaDevOps e infraServiciosCronPor qué HoodyHTTP nativo
TipoEstándarEtapaVictoria rápidaDificultadSimpleTrabajoAutomatizar tareaParaEquipos de desarrolloParaDevOps e infraServiciosCronPor qué HoodyHTTP nativo
use-cases / mute-flaky-job / hero
CRON · ENTRADAS GESTIONADAS · PATCH
Silencia el job inestable sin perderlo
La exportación de métricas horaria lleva tres días fallando. Esta noche estás de guardia. PATCH a la entrada de cron gestionada con enabled:false — el horario, el comando y el comentario se quedan. El job está en un estado definido: presente y silenciado, esperando a que alguien lo arregle.
cron.containers.hoody.com · entries
https://cron.containers.hoody.com/users/me/entrieslive
onidschedulecommandstatus
- a1f2*/5 * * * *curl -fsS http://prod/healthenabled
- c4b90 3 * * */usr/local/bin/backup.shenabled
- e7d30 * * * */srv/cron/metrics-export.shmuted · hace 2d · @alexsilenciado 2d ago · por @alex“flaking on monday with prod-db — see #pager-fri”
- 9b21@hourlypsql -c 'VACUUM ANALYZE'enabled
- f0a80 9 * * 1-5/srv/cron/digest.shenabled
- d3c7*/15 * * * */srv/cron/reindex-search.shpatching…
PATCH/users/me/entries/d3c7request body
{ "enabled": false, "comment": "reindex flaking — see thread" }
el toggle es solo un PATCH · la entrada nunca sale de la lista
use-cases / mute-flaky-job / mechanism
Silenciar es un solo PATCH
Las entradas gestionadas de Hoody Cron son un recurso JSON: cada fila tiene un id, un horario, un comando, un comentario y un flag enabled. Cambiar enabled a false es un PATCH. La entrada se queda en el crontab para que la siguiente persona pueda leerla y decidir qué hacer.
terminal · portátil de guardia
PATCH · silenciar# 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": "flaking on monday with prod-db — see #pager"]' # response HTTP/1.1 200 OK { "id":"e7d3", "enabled":false, "schedule":"0 * * * *", "command":"/srv/cron/metrics-export.sh", ... }
terminal · a la mañana siguiente
GET · verificar# 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
El PATCH no borra, no reescribe ni mueve la entrada — solo cambia un booleano. El traspaso es una línea: 'la entrada metrics-export e7d3 está silenciada, mira hoody-cron, échale un ojo, por favor.'
use-cases / mute-flaky-job / states
Tres estados, una entrada
Una entrada en un crontab de Hoody siempre está en exactamente uno de tres estados. Cada estado tiene consecuencias distintas para quién sabrá qué mañana por la mañana.
ENTRY · e7d3 · /srv/cron/metrics-export.shPATCH alterna entre estados — nunca destructivo
ENABLED
Se ejecuta según horario, avisa al fallar
La entrada está en el crontab y el daemon de cron del kernel la coge cada hora. Los fallos despiertan a quien está de guardia. Es el estado por defecto para jobs sanos.
MUTED
Presente, en pausa, anotado
enabled:false. La entrada sigue en el crontab para que el equipo pueda leer su horario, su comando y su comentario. El daemon de cron la salta. Sin avisos a las 2 de la madrugada, y nadie olvida que existe.
DELETED
Fuera — y el contexto también
Una vez que haces DELETE, el horario, el comando, el comentario, la razón — todo se va del crontab. La siguiente persona de guardia no tiene nada que buscar. Silenciar es la opción que mantiene la memoria.
Silenciar es el estado intermedio al que la mayoría de schedulers no le pone nombre. Hoody Cron sí, porque enabled es un campo de primera clase en la entrada gestionada.
use-cases / mute-flaky-job / powers
Por qué importa tener un estado silenciado definido
Cuando no puedes arreglar un job esta noche, la pregunta es qué forma toma su ausencia mañana. Silenciar hace esa forma legible.
TRASPASO
El mensaje a la guardia es una línea
En vez de pegar un hilo de Slack o una PR con líneas borradas, el mensaje es el id de la entrada. La guardia de mañana abre la URL de cron, lee el comentario y sabe por dónde empezar.
AUDITORÍA
Cada silencio es una fila, no un recuerdo
GET /entries devuelve enabled:false junto con el comentario. Construye un panel de auditoría filtrando. Quién la silenció, por qué y hace cuánto está en el JSON, no en los DMs de alguien.
REVERSIBLE
Quitar el silencio es el PATCH inverso
Cuando se arregle el problema de fondo, un PATCH más con enabled:true vuelve a poner la entrada en horario. Sin reescribir la expresión cron, sin riesgo de erratas, sin ciclo de commit-and-deploy.
use-cases / mute-flaky-job / capacity
Lo que te da la API de cron
Los números vienen de la superficie de entradas gestionadas de Hoody Cron, no de benchmarks inventados.
- UN MÉTODOPATCH
PATCH /users/[user]/entries/[id] acepta un body parcial. Manda ["enabled":false] solo — horario, comando y comentario quedan intactos.
- CAMPOS PRESERVADOS5+1
El horario de cinco campos, command, comment, expires_at e id persisten al silenciar. El crontab del kernel sigue reflejando la entrada — solo comentada por el servicio cron.
- REESCRITURAS0
Sin editar archivo, sin PR, sin deploy. El round-trip de silenciar es una llamada HTTP desde cualquier terminal, incluida la del móvil.
Según la API de Managed Entries de Hoody Cron: cada entrada lleva un booleano enabled junto a schedule, command, comment y un expires_at opcional. PATCH acepta bodies parciales.
use-cases / mute-flaky-job / punchline
Disabled no es deleted — la entrada espera a que alguien la arregle.
esta noche · de guardia · 23:14mañana · el equipo · 09:00
CÓMO ERA EL FLUJO ANTIGUOvim crontab → comentar línea → commit → PR → merge → deployseis pasos · pierde el contexto del comentario · arriesga una errata en una noche cansada
CÓMO ES AHORAcurl -X PATCH .../entries/e7d3 -d '["enabled":false]'un PATCH · la entrada se queda en la lista · la nota viaja con ella
use-cases / mute-flaky-job / replaces
Qué reemplaza esto
Las formas habituales en que los equipos 'aparcan temporalmente' una línea de cron inestable. Cada una es destructiva, pierde contexto, o está a dos PRs de producción.
- comentar líneas del crontab a manoPierde el flag enabled estructurado · fácil de olvidar
- borrar la entrada y 'acordarse'El horario, el comando y la razón se van con ella
- comentarios // FIXME a mano en el códigoVive en un repo, no en el horario que se ejecuta
- hilos de Slack como memoria de guardiaBuscable durante una semana · luego no es trabajo de nadie
- issues de GitHub para jobs silenciados-pero-no-borradosUna issue para algo que sigue en el crontab — estado duplicado
- config de cron gestionada con TerraformPlan, apply, deploy — para un único campo booleano
use-cases / mute-flaky-job / cta
Deja de borrar jobs inestables a las 2 de la madrugada. Siléncialos, deja una nota, y deja que la guardia de mañana lea el JSON.
use-cases / mute-flaky-job / related
Lee los otros
