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.
Containers·Snapshots
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailAutomatiser une tâchePourDevs backendPourDevOps & infraServicesCronServicesSnapshotsPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeProductionDifficultéSimpleTravailAutomatiser une tâchePourDevs backendPourDevOps & infraServicesCronServicesSnapshotsPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyHTTP-natif
use-cases / snapshot-before-migration / hero
CAS D'USAGE / SNAPSHOT AVANT MIGRATION
Snapshotter le conteneur juste avant la migration nocturne
Ajoutez une entrée hoody-cron qui se déclenche cinq minutes avant la tâche de migration de 03:00. Elle fait un curl sur l'URL des snapshots et marque l'artefact 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:00ZCRONl'entrée cron pre-migration-snap se déclencheschedule: 55 2 * * * - propriétaire : ops@hoody
- 02:55:08ZSNAPsnapshot snap-2026-05-04 crééalias rollback-point - 8.2s - 412 Mo de delta
- 03:00:00ZMIGla tâche de migration 0094-add-billing-events démarreappliquée par migrator@2.14.0 contre 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 validée, snapshot conservé 7jrollback-point reste résoluble jusqu'au 2026-05-11T02:55Z
artefact 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 URL, une habitude du soir
Le service cron planifie un curl. Le service de snapshots fait le gel. Aucun ne sait pour la migration qui tourne cinq minutes plus tard, et c'est tout l'intérêt.
POST cron/entries
scheduler# enregistre la tâche de snapshot récurrente (mise en place 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
freezer# 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 de snapshots → 200 OK · snap-2026-05-04 created in 8s
L'entrée cron est une ligne dans une table Postgres quelque part chez Hoody. L'URL des snapshots écrit un blob adressé par contenu vers le backend de stockage du conteneur. Les deux sont durables, versionnés, et aucun ne nécessite un processus longue durée sur votre laptop.
use-cases / snapshot-before-migration / anatomy
Anatomie de la nuit dernière
Quatre moments, quatre URL, et un écart de cinq minutes entre le filet de sécurité et le changement. La migration termine avant la première alarme de la plupart des ingénieurs.
0102:55:00ZLe cron se déclencheschedule: 55 2 * * *
0202:55:08ZLe snapshot atterritalias rollback-point
0303:00:00ZLa migration tourneALTER TABLE invoices
0403:01:42ZL'audit clôtsnapshot conservé 7j
Si l'étape 03 échoue, le rollback est `PATCH /snapshots/snap-2026-05-04` et vous êtes de retour à 02:55:08Z. La chronologie d'audit ci-dessus, c'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 : une sauvegarde qui existe avant le changement, adressée par une URL, avec un nom qui inclut la date du jour.
01 / SÉCURITÉ
La sauvegarde précède le changement, exactement de cinq minutes
La plupart des post-mortems d'incident commencent par « on a oublié de prendre une sauvegarde ». Quand la sauvegarde est une entrée cron, vous ne pouvez pas oublier. Le snapshot de 02:55 est la première phrase du runbook, écrite à l'avance.
02 / VITESSE
Le rollback est un seul 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 de 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 adressés par contenu et stockés en deltas. Un delta de 412 Mo par-dessus un disque de base inchangé, c'est ce que vous payez, et seulement pour la fenêtre de rétention de 7 jours. Les migrations réussies laissent presque aucune trace.
use-cases / snapshot-before-migration / rollback
Le rollback, avant et après
À quoi ressemblait le runbook auparavant, et en quoi il s'effondre quand le snapshot est nommé pour la date du jour et adressable par une URL.
ANCIEN RUNBOOK9 étapes manuelles, 20-40 minutes, 1-2 humains
- 01Bipper le DBA d'astreinte, confirmer que la migration a cassé la prodmédiane : 4 minutes pour acquitter
- 02Trouver la sauvegarde la plus récente dans la console AWSespérer qu'elle a moins de 24 heures
- 03Lancer une instance de restauration, attendre qu'elle soit en ligne8-15 minutes sur db.r6g.xlarge
- 04Inverser l'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émarrer les serveurs applicatifs, vider les caches, surveiller les taux d'erreuret écrire le post-mortem
NOUVEAU RUNBOOK1 appel HTTP, ~30 secondes, 0 humain
# rollback de 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 restauré à 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, prendre une sauvegarde » parce que la sauvegarde 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 ligne dans cron et un blob dans le stockage objet
AVANTd'abord, prendre une sauvegardela première phrase du runbook, exécutée manuellement à 03:02 par un humain fatigué
APRÈSla sauvegarde existe déjà, nommée pour la date du jour, prise 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 cela remplace
Le culte autour des sauvegardes pré-migration. Planifiez le snapshot, dormez pendant la fenêtre de migration.
- Snapshots manuels avant migrationSe réveiller à 02:54 pour cliquer sur le bouton sauvegarde
- Étapes de checklist runbookÉtape 1 sur 14 sur la page que personne ne trouve
- Astreinte en standby pour rollbackPayer un ingénieur à attendre rien
- pg_dump ad hoc avant les déploiementsEspérer que vous y avez pensé, espérer que ça a fini
- Releases « on fera juste attention »L'optimisme qui livre les incidents
- Snapshots automatisés AWS RDSFenêtre fixe de 5 minutes, payée au Go-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
Découvrez les autres
