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é
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYHTTP-natif
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURDevs backend
SERVICESCron
SERVICESConteneurs
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYHTTP-natif
SECTEURSaaS
use-cases / cron-per-customer / hero
SaaS multi-tenant / Planification par client
Un crontab séparé pour chaque client, automatiquement
votre SaaS laisse chaque client planifier sa propre génération de rapport. Le design naïf c'est un scheduler partagé, des customer IDs dans le payload du job, et on croise les doigts pour que personne n'affame personne. Le design Hoody donne à chaque tenant son propre conteneur et son propre service hoody-cron.
Avant tenant
Crontab
# aucune entrée pour l'instant
CPU0%
Tâches0
POST /users/root/entries
En cours
Planification
0 9 * * *digest.sh→ 04:32
*/15 * * * *sync.py
0 2 * * *backup.sh→ 14:02
CPU64%
Tâches3
tic cron dans 04:32
Après rotation
Planification
0 9 * * *digest.sh
*/15 * * * *sync.py
CPU3%
Tâches0
DELETE /entries/:id appelé
Trois états de cycle de vie, une API HTTP. PROVISION ajoute des entrées, le tic cron les exécute, DELETE suspend. Le cron de chaque tenant vit dans son propre conteneur — pas de file partagée, pas de risque de ressources partagées.
use-cases / cron-per-customer / mechanism
Trois appels API pilotent tout le cycle de vie tenant
Chaque conteneur client expose l'API HTTP hoody-cron. Provisionne avec POST, vérifie avec GET, suspends avec DELETE. Pas de file partagée, pas de voie prioritaire, pas de config scheduler à redéployer.
POST une entrée managée — crée un job cron avec UUID, état enabled, et champ schedule_human lisiblePOST /provisionner
request
# POST managed entry for acme-corp tenant
POST acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * *",
"command": "/usr/local/bin/digest.sh",
"comment": "daily digest",
"enabled": true
}response
HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "7d3f2a1b-8c4e-4f9a-b2d5",
"schedule": "0 9 * * *",
"schedule_human": "At 09:00",
"enabled": true,
"user": "root"
}201 Created. L'ID de l'entrée est retourné pour PATCH ou DELETE futur. schedule_human confirme que l'expression a été parsée correctement.
Chaque onglet montre l'appel API exact que votre control plane fait. L'API d'entrées managées utilise des UUID pour que vous puissiez cibler des jobs individuels sans remplacer tout le crontab. L'isolation par utilisateur fait que rien de la planification d'acme-corp n'est visible pour globex-saas.
use-cases / cron-per-customer / powers
Ce que le modèle de facturation rend évident
Un serveur forfaitaire. Soixante conteneurs tenants. Le calcul est brutalement simple.
Décomposition de la facturation de la flottecoût par tenant = serveur divisé par tenants
vos tenants
acme-corpSM
globex-saasMD
initech-incLG
+ 57 autres
Serveur forfaitaire / mois$29Un nœud bare-metal. 60 conteneurs. La facture reste plate.
÷tenants
Coût par tenant<$0.49Baisse à mesure que vous ajoutez des tenants
Les incidents de ressources partagées disparaissent
Quand le scrape.js d'initech-inc plante, le digest 9h d'acme-corp se déclenche quand même. Crontabs différents, arbres de processus différents, filesystems différents.
Les changements de planification se propagent instantanément
POST une nouvelle entrée et le service hoody-cron du tenant la prend immédiatement. Aucun scheduler central à recharger, aucun broadcast à envoyer.
Logs par tenant, un conteneur
Quand globex-saas demande pourquoi son rollup de 18h a tourné deux fois, vous lisez le log d'un conteneur — pas un grep de scheduler partagé sur neuf machines.
use-cases / cron-per-customer / compare
Scheduler partagé vs crontab par conteneur
Trois axes où le vieux design taxe votre équipe et où le design Hoody ne le fait juste pas.
AxeScheduler partagéPar conteneur
Isolation
tenant_id dans le payload du jobUne mauvaise ligne, la file de chaque tenant bloque
/etc/crontab séparé par conteneurLes blocages sont locaux. Toujours.
Provisionnement
INSERT INTO scheduled_jobsCouplage de migration, verrou de schéma
PUT /users/root/crontabUn seul appel HTTP, remplacement atomique
Audit
grep tenant_id=42 logs/*9 machines, 1 fichier de log chacune
GET ctr_8a3f1c/cron/logUn conteneur, un log, une vérité
La colonne ancienne, c'est ce que toute équipe écrit la première fois qu'elle livre une planification multi-tenant. La colonne nouvelle, c'est ce que vous livrez quand la plateforme donne à chaque tenant son propre conteneur par défaut.
use-cases / cron-per-customer / capacity
La capacité aux extrêmes
Ce qu'une seule box bare-metal Hoody fait quand chaque client a son propre crontab.
- Tenants par box60
Soixante conteneurs clients sur un nœud bare-metal, chacun avec son propre service hoody-cron. Pas de scheduler partagé qui sature.
- Propagation de planification<1s
De la requête PUT au premier tic de la nouvelle planification, observé sur une flotte de 60 conteneurs sur un nœud 64-cœurs typique.
- Files cross-tenant0
Il n'y a littéralement aucune file partagée, voie prioritaire ou thread scheduler pour lequel deux tenants se disputent. L'isolation est le substrat.
Les chiffres de capacité sont des valeurs typiques observées sur un nœud bare-metal 64-cœurs / 256GB faisant tourner la densité de conteneurs Hoody standard. La capacité réelle dépend des budgets CPU et mémoire par tenant et du travail que chaque job cron fait. Le zéro en files cross-tenant est structurel, pas un benchmark.
use-cases / cron-per-customer / punchline
Le cron d'un client ne peut pas affamer celui d'un autre parce qu'ils ne sont pas sur le même crontab.
Avant / scheduler partagéAprès / par conteneur
Partagéscheduled_jobs WHERE tenant_id = 42Une ligne dans une table que tout le monde lit
Par tenantPUT acme-cron.hoody.com/users/root/crontabUn appel HTTP, un conteneur, un crontab
use-cases / cron-per-customer / replaces
Ce que ça remplace
Les architectures que les équipes construisent pour partager un crontab entre tenants. Hoody met chaque tenant dans son propre crontab — pas de routeur, pas de file d'équité, pas de ressources partagées.
- Crontabs multi-tenant partagésUne mauvaise regex affame 400 clients
- Isolation tenant customUn scheduler avec tenant_id sur chaque ligne
- pg_cron PostgresLié à la base ; un upgrade et tout le monde casse
- Scheduler Quartz avec filtresUne JVM et une file shardée par région
- Files tenant SidekiqDouze files, douze fichiers de config
- CronJobs Kubernetes par tenantUn namespace, un rôle RBAC, un YAML, un pager
use-cases / cron-per-customer / cta
Arrêtez d'écrire tenant_id partout. Donnez à chaque client son propre conteneur et laissez cron faire ce que cron a toujours fait, en isolation.
use-cases / cron-per-customer / related