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ÉSimple
MÉTIERAutomatiser une tâche
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERAutomatiser une tâche
POURDevs backend
POURDevOps et infra
SERVICESCron
SERVICESSnapshots
POURQUOI HOODYVoyage temporel par snapshot
POURQUOI HOODYHTTP-natif
use-cases / snapshot-before-migration / hero
USE CASE / SNAPSHOT AVANT MIGRATION
Snapshot le conteneur juste avant la migration nocturne
Ajoute une entrée hoody-cron qui se déclenche cinq minutes avant le job de migration de 03:00. Elle curl l'URL des snapshots et marque l'artéfact comme point de rollback. Si la migration échoue, vous restaurez en 30 secondes avec un seul PATCH.
cron.containers.hoody.com/audit
https://cron.containers.hoody.com/audit?since=last-nighttout vert
- 02:55:00ZCRONentrée cron pre-migration-snap se déclencheschedule: 55 2 * * * - owner: ops@hoody
- 02:55:08ZSNAPsnapshot snap-2026-05-04 crééalias rollback-point - 8.2s - 412 MB delta
- 03:00:00ZMIGjob de migration 0094-add-billing-events démarreappliqué par migrator@2.14.0 sur postgres-primary
- 03:00:11ZDDLDDL: ALTER TABLE invoices ADD COLUMN billing_event_id BIGINT+ CREATE INDEX CONCURRENTLY idx_invoices_billing_event_id
- 03:01:42ZOKmigration committée, snapshot retenu 7jrollback-point résolvable jusqu'au 2026-05-11T02:55Z
artéfact snapshot
200 OK// POST /api/v1/containers/[id]/snapshots
{ "name": "snap-2026-05-04", "alias": "rollback-point", "created_at": "02:55:08Z" }
UNE NUIT, CINQ ÉVÉNEMENTS, ZÉRO ALERTE
use-cases / snapshot-before-migration / mechanism
Deux URLs, une habitude du soir
Le service cron planifie un curl. Le service snapshots gèle. Aucun ne sait pour le job de migration qui tourne cinq minutes plus tard, et c'est tout l'intérêt.
POST cron/entries
planificateur# enregistre le job snapshot récurrent (setup unique) curl -X POST \ cron.containers.hoody.com/users/root/entries \ -H "Content-Type: application/json" \ -d '{ "schedule": "55 2 * * *", "command": "curl -X POST $SNAP_URL -d '{\"alias\":\"rollback-point\"}'", "comment": "pre-migration snapshot" }'
DÉCLENCHE
POST containers/[id]/snapshots
congélateur# ce que l'entrée cron curl chaque nuit à 02:55 UTC curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "rollback-point", "expiry": 7}' # réponse du service snapshots → 200 OK · snap-2026-05-04 created in 8s
L'entrée cron est une row dans une table Postgres quelque part chez Hoody. L'URL snapshots écrit un blob content-addressed dans le backend de stockage du container. Les deux sont durables, les deux sont versionnés, et aucun ne demande un processus long sur votre laptop.
use-cases / snapshot-before-migration / anatomy
Anatomie de la nuit dernière
Quatre moments, quatre URLs et un écart de cinq minutes entre le filet de sécurité et le changement. La migration finit avant le premier réveil de la plupart des ingénieurs.
0102:55:00ZCron déclenchéschedule: 55 2 * * *
0202:55:08ZSnapshot atterritalias rollback-point
0303:00:00ZMigration tourneALTER TABLE invoices
0403:01:42ZAudit clossnapshot retenu 7j
Si l'étape 03 échoue, le rollback est `PATCH /snapshots/snap-2026-05-04` et te voilà à 02:55:08Z. La timeline d'audit ci-dessus est la même donnée, servie en JSON.
use-cases / snapshot-before-migration / powers
Ce que cette forme débloque
Pas le snapshot lui-même. La forme : un backup qui existe avant le changement, adressé par une URL, avec un nom qui inclut la date du jour.
01 / SÉCURITÉ
Le backup précède le changement, de cinq minutes pile
La plupart des post-mortems d'incident commencent par « on a oublié de prendre un backup ». Quand le backup est une entrée cron, vous ne peux pas oublier. Le snapshot de 02:55 est la première phrase du runbook, écrite à l'avance.
02 / VITESSE
Le rollback est un PATCH, pas un runbook de 40 étapes
Restaurer snap-2026-05-04 est un seul appel HTTP contre api.hoody.com. Le conteneur revient à son état 02:55:08Z en moins de 30 secondes. Pas de ticket, pas d'escalade d'astreinte, pas de « qui a la console AWS ».
03 / COÛT INACTIF
Si la migration réussit, le snapshot ne coûte rien
Les snapshots sont content-addressed et stockés en deltas. Un delta de 412 MB par-dessus un disque de base inchangé est ce que vous payez, et seulement pour la fenêtre de rétention de 7 jours. Les migrations réussies laissent presque aucune empreinte.
use-cases / snapshot-before-migration / rollback
Le rollback, avant vs après
Ce à quoi ressemblait le runbook, et ce en quoi il s'effondre quand le snapshot est nommé pour la date du jour et adressable comme une URL.
ANCIEN RUNBOOK9 étapes manuelles, 20-40 minutes, 1-2 humains
- 01Réveille le DBA d'astreinte, confirme que la migration a cassé la prodmédiane : 4 minutes pour acquitter
- 02Trouve le backup le plus récent dans la console AWSespère qu'il a moins de 24 heures
- 03Lancez une instance de restore, attendez qu'elle démarre8-15 minutes sur db.r6g.xlarge
- 04Inverse le ALTER TABLE manuellement avec un script DOWN écrit à la mainsi le script DOWN existe, ce qui n'est généralement pas le cas
- 05Redémarrez les serveurs d'app, flushez les caches, surveillez les taux d'erreuret écris le post-mortem
NOUVEAU RUNBOOK1 appel HTTP, ~30 secondes, 0 humain
# rollback la migration de la nuit dernièrecurl -X PATCH api.hoody.com/api/v1/containers/$ID/snapshots/snap-2026-05-04# réponse→ 200 OK · conteneur revenu à snap-2026-05-04 en 28s
PATCH est idempotent et réversible
La nouvelle colonne à droite n'est pas un outil. C'est une phrase dans un runbook. La phrase ne commence pas par « d'abord, prenez un backup » parce que le backup existe déjà.
use-cases / snapshot-before-migration / punchline
Le plan de rollback est une URL que vous avez planifiée pour exister.
AVANT : une page Notion que personne ne litAPRÈS : une row dans cron et un blob dans l'object storage
ANCIENd'abord, prenez un backupla première phrase du runbook, exécutée manuellement à 03:02 par un humain fatigué
NOUVEAUle backup existe déjà, nommé pour la date du jour, pris cinq minutes avant le changementla première phrase du runbook, écrite à l'avance par une entrée cron
use-cases / snapshot-before-migration / replaces
Ce que ça remplace
Le cargo-cult autour des backups pré-migration. Planifie le snapshot, dors avec la fenêtre de migration.
- Snapshots manuels pré-migrationVous réveiller à 02:54 pour cliquer sur le bouton backup
- Items de checklist runbookÉtape 1 sur 14 sur la page que personne ne trouve
- Astreinte standby pour rollbackPayer un ingénieur pour attendre rien
- pg_dump ad-hoc avant déploiementEspère que Vous vous en souvenez, espère qu'il a fini
- Releases « on va juste faire attention »L'optimisme qui livre des incidents
- Snapshots automatisés AWS RDSFenêtre fixe de 5 minutes, payée par GB-jour
use-cases / snapshot-before-migration / cta
Le plan de rollback est une URL que vous avez planifiée pour exister.
use-cases / snapshot-before-migration / related