
Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Scrape navigateur horaire, digest SQLite quotidien, archive de fichiers hebdomadaire. Trois rythmes s'imbriquent proprement dans un seul crontab — ce ne sont que trois lignes de `* * * * *` pointant vers trois scripts. Pas de service de planificateur, pas de file de jobs, pas de pool de workers.
un crontab · trois cadences · même conteneur
Le service Hoody Cron expose le crontab brut comme une ressource REST. Un PUT du fichier une fois et le noyau l'exécute pour toujours. Trois lignes, trois scripts — chacun un one-liner qui parle déjà HTTP.
# Remplace tout le crontab en un seul appel.
PUT /users/root/crontab
Content-Type: text/plain
@hourly bash /scripts/scrape.sh
0 9 * * * bash /scripts/digest.sh
0 0 * * 0 bash /scripts/archive.sh
HTTP/1.1 204 No Content# scrape.sh — toutes les heures, étaler une capture dans sqlite
curl -sS https://browser.containers.hoody.com/screenshot \
--data-urlencode "url=https://store.hoody.com/p/123" | sqlite3 /data/prices.db \
"INSERT INTO rows VALUES (?, ?, ?)"
# digest.sh — à 9h, calculer les deltas et envoyer le digest
sqlite3 /data/prices.db < /scripts/digest.sql \
> /tmp/digest.txt && curl -T /tmp/digest.txt \
https://pipe.hoody.com/api/v1/pipe/digest
# archive.sh — dimanche minuit, dump et stockage
sqlite3 /data/prices.db ".dump" | curl -T - \
https://files.containers.hoody.com/archives/$(date +%Y-w%V).sqlTrois scripts. Trois URLs qu'ils savent déjà appeler. Une requête PUT pour installer le planning. Il n'y a aucun service de planificateur devant tout ça — le crond du noyau lit le fichier que vous avez écrit et l'exécute.
Chaque cadence a une seule expression à 5 champs et une seule ligne shell derrière. Aucune n'a besoin de connaître les deux autres — elles partagent juste un disque et une horloge.
hoody-browser capture une liste d'URLs produits. Chaque ligne va directement dans une table SQLite sur le volume du conteneur. Pas de pool de workers de scraping — la ligne cron est le pool de workers.
À 9h, le script digest lit les 24 dernières heures de lignes, calcule les deltas de prix, et envoie le digest en curl vers une URL pipe. Votre boîte mail / tableau de bord lit depuis le même pipe.
Dimanche à minuit, le script archive fait un `.dump` de SQLite, nomme le fichier par semaine ISO, et l'envoie en PUT vers hoody-files. Les anciennes lignes sont élaguées. Le volume reste petit pour toujours.
Trois cadences dans un même conteneur n'est pas un hack — c'est la forme naturelle de cron. La plateforme vous a déjà donné un planificateur ; vous avez juste arrêté de payer trois fois pour ça.
Le scrape horaire écrit les lignes que le digest quotidien lit. Le digest quotidien écrit les deltas que l'archive hebdomadaire dump. Il n'y a pas d'IPC entre eux — ce ne sont que trois processus sur le même volume.
Quand vous redéployez, vous redéployez une image. Quand vous regardez les logs, vous suivez un fichier de log. Quand le disque se remplit, il se remplit une fois. Le rayon d'impact d'une cadence est le même que celui d'une autre.
Lambda/EventBridge facturent à l'invocation ; ECS Scheduled Tasks facture le cluster toujours allumé. Sur Hoody, cela s'exécute dans le serveur à tarif fixe que vous payez déjà. Trois cadences ne coûtent pas plus qu'une.
Le crontab est un fichier. Le fichier a une URL. Tout ce que vous feriez sur le fichier, vous pouvez le faire en HTTP.
Crée une entrée gérée avec un UUID et un commentaire optionnel. L'API injecte la ligne dans le crontab pour vous et vous donne une poignée pour l'activer, la désactiver ou la supprimer plus tard.
Mettez en pause une cadence pendant un incident sans perdre sa définition. Réactivez-la quand l'incident se ferme. La ligne reste dans le fichier, commentée comme managed-disabled.
Récupérez le crontab brut à tout moment, y compris toutes les entrées gérées. Comparez-le à votre dépôt. Envoyez-le dans le contrôle de version. Cron est un fichier, et maintenant le fichier est une URL.
Endpoints depuis l'API Hoody Cron : CRUD d'entrées gérées plus lecture/écriture brute du crontab par utilisateur. Expressions standards à 5 champs et macros (@hourly, @daily, @weekly).
Trois chiffres tirés du mécanisme réel. Les chiffres viennent des garanties de l'API Hoody Cron et du modèle de serveur à tarif fixe — pas de benchmarks inventés.
Les trois cadences s'exécutent dans le même serveur à tarif fixe. Un serveur d'entrée commence à 29 $ / mois ; des lignes cron supplémentaires n'ajoute pas de charge.
Une @hourly, une quotidienne à 9h, une hebdomadaire le dimanche. Trois lignes dans /users/root/crontab. Tout l'orchestrateur tient dans une requête PUT.
Pas de Lambda, pas d'EventBridge, pas de Sidekiq, pas de planificateur Airflow, pas de définition ECS scheduled task. L'API HTTP pour cron EST le planificateur.
Selon l'API Hoody Cron : entrées gérées via CRUD JSON, lecture/écriture brute du crontab, auto-expiration via expires_at, et isolation du crontab par utilisateur. Macros @hourly / @daily / @weekly acceptées aux côtés des expressions à 5 champs.
Trois cadences, trois lignes cron, un conteneur sur un serveur à tarif fixe commençant à 29 $ / mois.
Trois Lambdas, trois GitHub Actions, trois ECS scheduled tasks — les stacks standards qu'on attrape pour trois cadences. Chacun vous facture par cadence ou par invocation ; Hoody facture le serveur.
Arrêtez de louer un planificateur. Écrivez le planning dans un fichier. Le conteneur exécute déjà cron — trois lignes plus tard, vous avez livré tout le pipeline.