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é
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERAutomatiser une tâche
POURDevs backend
POURÉquipes de devs
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYHTTP-natif
use-cases / crontab-per-branch / hero
CRON · GIT · PLANIFICATIONS PAR BRANCHE
Un crontab par branche, déployé avec le code
Commit `.hoody/crontab` dans le repo, à côté de vos jobs. Quand le script de déploiement lance un conteneur pour `main`, `feature/billing-v2` ou n'importe quelle branche de preview, il PUT ce fichier sur la Cron API du nouveau container. La planification voyage avec la branche — et disparaît quand la branche disparaît.
billing/ · vscode
main·billing/.hoody/crontab
enregistré- billing/
- .git
- src
- jobs
- .hoody
- crontabouvrir
- deploy.json
- package.json
- README.md
.hoody/crontab
- 10 2 * * */srv/jobs/billing-rollup.sh# nightly invoices
- 2*/15 * * * */srv/jobs/sync-stripe.py
- 3@hourlycurl -fsS http://localhost/healthz
- 4# vit dans le même commit que les jobs ci-dessus
main · 3 entrées · committédéployé avec la branche
git push → conteneur de branche → PUT crontab
branches · aperçu cron
https://admin.hoody.com/branches/cron-overviewactif · 3 conteneurs
main
déployéctr_8a3f1cbilling-main.hoody.com
.hoody/crontab3 entrées
- 0 2 * * *billing-rollup.sh
- */15 * * * *sync-stripe.py
- @hourlycurl -fsS http://localhost/healthz
production crontab · 3 entries
feature/billing-v2
aperçuctr_4d72b9billing-v2.hoody.com
.hoody/crontab4 entrées
- 0 2 * * *billing-rollup-v2.sh
- */15 * * * *sync-stripe.py
- @hourlycurl -fsS http://localhost/healthz
- */5 * * * *diff-v1-v2.sh
preview crontab · 4 entries · QA diff added
experiment/llm-rollups
spikectr_e1b04fllm-rollups.hoody.com
.hoody/crontab1 entrée
- */30 * * * *llm-rollups.py
spike crontab · 1 entry
un fichier par branche · même chemin dans chaque repo · pas de serveur cron partagé
use-cases / crontab-per-branch / mechanism
Comment `.hoody/crontab` devient une vraie planification
Chaque conteneur de branche fait tourner Hoody Cron. Le script de déploiement lit le crontab committé et le PUT sur l'endpoint raw-crontab du nouveau container. Le conteneur exécute la planification décrite par le fichier — ni plus, ni moins.
deploy.sh · poussé par CI
shell · client#!/bin/sh
# Provisionne un conteneur neuf pour cette branche.
BRANCH=$(git branch --show-current)
CTR=$(hoody containers create --from main-snapshot)
# Remplace le crontab du conteneur par celui du repo.
curl -X PUT --data-binary @.hoody/crontab \
-H "Content-Type: text/plain" \
https://$CTR-cron-1.hoody.com/users/root/crontab
# Terminé. La planification de la branche vit dans son container.
echo "deployed $BRANCH → $CTR"PUT /users/root/crontab
cron · serveur# Endpoint raw-crontab Hoody Cron — remplace tout le fichier de manière atomique.
PUT /users/root/crontab HTTP/1.1
Host: ctr_4d72b9-cron-1.hoody.com
Content-Type: text/plain
0 2 * * * /srv/jobs/billing-rollup-v2.sh
*/15 * * * * /srv/jobs/sync-stripe.py
@hourly curl -fsS http://localhost/healthz
*/5 * * * * /srv/jobs/diff-v1-v2.sh
HTTP/1.1 200 OK
# 200 OK : le démon cron recharge, planification active en moins d'une seconde.Le crontab est une donnée que la branche transporte, pas un état que le serveur cron mémorise. Supprimez le conteneur, et il ne reste aucune entrée à nettoyer — le fichier est parti avec le disque.
use-cases / crontab-per-branch / powers
Trois choses que vous arrêtez de faire
Une fois la planification devenue un fichier dans le repo, trois catégories de travail disparaissent.
VERSIONING
Les planifications voyagent dans le même diff que le code
Quand vous passez `billing-rollup.sh` en v2, la nouvelle planification arrive dans la même pull request. Le reviewer voit la ligne cron juste à côté du script. Reverte un commit et la planification revient avec lui.
TEARDOWN
Supprimez la branche, le cron part avec elle
Les conteneurs de branche sont éphémères. Quand vous mergez ou fermez la branche, vous démontez le container. Le crontab vivait dedans, donc la planification disparaît sans concierge — aucun serveur cron partagé ne garde d'entrées obsolètes.
ISOLATION
L'expérience ne peut pas se déclencher en staging
Un job expérimental horaire sur `experiment/llm-rollups` tourne dans son propre conteneur avec son propre filesystem. Le démon cron de staging ne le voit jamais ; celui de production non plus. Pas de garde `if BRANCH_ENV` à l'intérieur des jobs.
use-cases / crontab-per-branch / compare
Crontab partagé vs crontab par branche
Le modèle standard « un crontab géré par les ops » et le modèle lié à la branche échouent dans des directions opposées. Même job, rayon d'impact très différent.
AXECRONTAB PARTAGÉCRONTAB PAR BRANCHE
Source de vérité
wiki ops + rôle ansiblela planification vit dans un repo différent du script
.hoody/crontab dans le repoà côté du script que la ligne cron invoque
Ajouter un job
merge code → ping ops → SSH sur l'hôte crondeux systèmes doivent s'accorder, manuellement
éditez le fichier, pushez, déployezun diff, un merge, un déploiement
Isolation par branche
if [ "$ENV" = staging ]; then …chaque job connaît tous les environnements
conteneur par branchepas de flag d'env dans le script
Nettoyage
se rappeler de retirer la ligneles entrées obsolètes s'empilent pendant des années
branche supprimée = cron suppriméle filesystem n'existe plus, la planification non plus
Expériences
le crontab de production est le seul qui existetout test risque de se déclencher en prod
branche spike = crontab spikene se déclenche que dans son conteneur
La différence n'est pas une feature — c'est l'endroit où vit la planification. Un fichier que la branche transporte, ou une ligne dans une table partagée que la branche emprunte.
use-cases / crontab-per-branch / capacity
Ce que Hoody Cron vous donne vraiment
Le Cron par conteneur est une vraie surface REST — trois familles d'endpoints, syntaxe cron standard, isolation totale par utilisateur. Chiffres tirés de la spec Cron API, pas de benchmarks inventés.
- CRONTAB PAR CONTAINER1
Chaque conteneur de branche a son propre crontab par utilisateur. PUT le fichier complet, GET en retour, remplace-le de manière atomique. Pas de table de planification partagée derrière.
- FAMILLES D'ENDPOINTS3
Crontab brut (GET/PUT), entrées gérées (POST/PATCH/DELETE avec UUID et `expires_at`), et listing par utilisateur. Choisis ce dont votre script de déploiement a besoin.
- EXPRESSIONS CRON À CHAMPS5
Standard `min hour day month dow` plus macros : `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. La même syntaxe que votre `.hoody/crontab` utilise déjà.
D'après la Hoody Cron API : GET/PUT /users/[user]/crontab et POST/PATCH/DELETE /users/[user]/entries sur l'URL du service cron de chaque container.
use-cases / crontab-per-branch / punchline
La planification vit à côté du code qui tourne dessus, dans le même conteneur, sur la même branche.
avant · deux systèmes à reteniraprès · un fichier dans le repo
CE QUE VOUS AVIEZplanification dans ops/ansible · code dans app/ · jamais d'accordmergez la PR, puis ouvrez un ticket pour mettre à jour l'hôte cron
CE QUE VOUS AVEZ MAINTENANTPUT @.hoody/crontab → cron-1.[branch].hoody.comun PUT, un conteneur, une planification, une branche
use-cases / crontab-per-branch / replaces
Ce que ça remplace
Six endroits où vivait la planification cron, aucun à côté du code. Le crontab lié à la branche les rend tous redondants.
- crontab de production partagéUn fichier sur un hôte cron autour duquel chaque équipe devait se coordonner
- synchro manuelle de la config cronRôle Ansible / manifest Puppet appliqué hors-bande de vos merges de code
- planifications GitHub Actions épinglées sur mainPlanifications liées à la branche par défaut, invisibles pour le travail sur features et previews
- « pensez à mettre à jour cron quand vous mergez »Une checklist humaine — la seule chose entre vous et une entrée obsolète
- repo de config cron séparéUn second repo dont le seul rôle était de retarder sur celui qui contient vraiment le code
- migrations planifiées Atlas/LiquibaseOutils de migration faisant office de planificateur faute de meilleur endroit
use-cases / crontab-per-branch / cta
Arrêtez de synchroniser des planifications entre systèmes. Commitez le crontab. Laissez la branche le porter.
use-cases / crontab-per-branch / related