Aller au contenu
TypeDéverrouilléÉtapeParcDifficultéModéréTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metalPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéModéréTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metalPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéModéréTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metalPourquoi HoodyHTTP-natifSecteurSaaS
TypeDéverrouilléÉtapeParcDifficultéModéréTravailSaaS multi-locatairePourÉquipes de devPourDevs backendServicesCronServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metalPourquoi HoodyHTTP-natifSecteurSaaS
Retour aux cas d'utilisation
use-cases / cron-per-customer / hero
SaaS multi-tenant / Planification par client

Un crontab distinct pour chaque client, automatiquement

Votre SaaS laisse chaque client planifier sa propre génération de rapports. Le design naïf : un seul scheduler partagé, des customer IDs dans le payload de la tâche, doigts croisés pour que personne n'affame personne. Le design Hoody donne à chaque locataire son propre conteneur et son propre service hoody-cron.

Lire la documentation

Trois états du cycle de vie, une API HTTP. PROVISION ajoute des entrées, les ticks cron les exécutent, DELETE les suspend. Le cron de chaque locataire vit dans son propre conteneur — pas de file partagée, pas de risque de voisin bruyant.

use-cases / cron-per-customer / mechanism

Trois appels API pilotent le cycle de vie complet du locataire

Chaque conteneur client expose l'API HTTP hoody-cron. Provisionner avec POST, vérifier avec GET, suspendre avec DELETE. Pas de file partagée, pas de voie prioritaire, pas de configuration scheduler à redéployer.

POST une entrée gérée — crée une tâche cron avec UUID, état enabled, et champ schedule_human lisible par humainPOST /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 d'entrée est retourné pour de futurs PATCH ou DELETE. schedule_human confirme que l'expression a été analysée correctement.

Chaque onglet affiche l'appel API exact que votre control plane effectue. L'API des entrées gérées utilise des UUID pour que vous puissiez cibler des tâches individuelles sans remplacer tout le crontab. L'isolation par utilisateur signifie que rien du planning 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 à tarif plat. Soixante conteneurs locataires. Les maths sont brutalement simples.

Répartition de la facturation de la flottecoût par locataire = serveur divisé par les locataires
Vos locataires
acme-corpSM
globex-saasMD
initech-incLG
+ 57 de plus
Serveur à tarif plat / mois29 €Un nœud bare-metal. 60 conteneurs. La facture reste plat.
÷locataires
Coût par locataire< 0,49 €Baisse à mesure que vous ajoutez des locataires

Les incidents de voisin bruyant disparaissent

Quand le scrape.js d'initech-inc reste bloqué, le digest de 9h d'acme-corp part toujours à l'heure. Crontabs différents, arbres de processus différents, systèmes de fichiers différents.

Les changements de planning se propagent instantanément

POST une nouvelle entrée et le service hoody-cron du locataire la récupère immédiatement. Pas de scheduler central à recharger, pas de broadcast à envoyer.

Logs par locataire, un conteneur

Quand globex-saas demande pourquoi leur rollup de 18h a tourné deux fois, vous lisez le log d'un seul conteneur — pas un grep sur un scheduler partagé sur neuf machines.

use-cases / cron-per-customer / compare

Scheduler partagé vs crontab lié au conteneur

Trois axes où l'ancien design taxe votre équipe et où le design Hoody ne le fait simplement pas.

AxeScheduler partagéLié au conteneur
Isolation
tenant_id dans le payload de la tâcheUne mauvaise ligne, la file de chaque locataire bloque
/etc/crontab séparé par conteneurLes blocages restent 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é

L'ancienne colonne, c'est ce que toute équipe écrit la première fois qu'elle livre une planification multi-tenant. La nouvelle colonne, c'est ce que vous livrez quand la plateforme donne par défaut son propre conteneur à chaque locataire.

use-cases / cron-per-customer / capacity

Capacité aux limites

Ce qu'une seule machine bare-metal Hoody encaisse quand chaque client a son propre crontab.

  1. Locataires par machine60

    Soixante conteneurs clients sur un seul nœud bare-metal, chacun avec son propre service hoody-cron en cours. Pas de scheduler partagé pour faire goulot.

  2. Propagation du planning<1s

    De la requête PUT au premier tick du nouveau planning, observé sur une flotte de 60 conteneurs sur un nœud 64 cœurs typique.

  3. Files cross-locataire0

    Il n'y a littéralement aucune file partagée, aucune voie prioritaire ni thread scheduler que deux locataires 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 / 256 Go en densité conteneur Hoody standard. La capacité réelle dépend des budgets CPU et mémoire par locataire et du travail que fait chaque tâche cron. Le zéro pour les files cross-locataire 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 / lié au conteneur
Partagéscheduled_jobs WHERE tenant_id = 42Une ligne dans une table que tout le monde lit
Par locatairePUT acme-cron.hoody.com/users/root/crontabUn appel HTTP, un conteneur, un crontab
Lire l'API cron
use-cases / cron-per-customer / replaces

Ce que cela remplace

Les architectures que les équipes construisent pour partager un seul crontab entre locataires. Hoody met chaque locataire dans son propre crontab — pas de routeur, pas de file d'équité, pas de voisin bruyant.

  • Crontabs multi-tenant partagésUne mauvaise regex affame 400 clients
  • Isolation locataire maisonUn scheduler avec tenant_id sur chaque ligne
  • pg_cron PostgresLié à la base ; une mise à jour et tout le monde casse
  • Scheduler Quartz avec filtresUne JVM et une file shardée par région
  • Files locataire SidekiqDouze files, douze fichiers de config
  • Kubernetes CronJobs par locataireUn 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.

Lire la documentation
use-cases / cron-per-customer / related

Découvrez les autres