Aller au contenu
TypeNouvelle primitiveÉtapeProductionDifficultéSimpleTravailEnvironnement de branchePourDevs backendPourDevOps & infraPourConstructeurs d'IAServicesSnapshotsServicesContainersPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metal
TypeNouvelle primitiveÉtapeProductionDifficultéSimpleTravailEnvironnement de branchePourDevs backendPourDevOps & infraPourConstructeurs d'IAServicesSnapshotsServicesContainersPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metal
TypeNouvelle primitiveÉtapeProductionDifficultéSimpleTravailEnvironnement de branchePourDevs backendPourDevOps & infraPourConstructeurs d'IAServicesSnapshotsServicesContainersPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metal
TypeNouvelle primitiveÉtapeProductionDifficultéSimpleTravailEnvironnement de branchePourDevs backendPourDevOps & infraPourConstructeurs d'IAServicesSnapshotsServicesContainersPourquoi HoodyVoyage dans le temps par snapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyIsolation bare-metal
Retour aux cas d'utilisation
use-cases / branch-computers-like-git / hero
SNAPSHOTS · BUILD DEV ENVIRONMENTS

Branch computers like Git branches code

Un snapshot gèle un conteneur en cours d'exécution — système de fichiers, processus, mémoire, descripteurs de fichiers ouverts. Restauré en 5-15 secondes. Bifurcation vers un conteneur séparé avec un POST. Du branchement, mais pour la machine entière.

Docs des snapshots
use-cases / branch-computers-like-git / capture

Ce qui est réellement capturé

Deux modes, décidés par l'état du conteneur au moment du snapshot. Le mode stateful capture tout ; le stateless ne capture que le système de fichiers.

EN COURS D'EXÉCUTIONcréer 1–5 s · restaurer 5–15 s

Stateful — conteneur en cours d'exécution

  • Système de fichiers (delta CoW)Reflinks BTRFS ; les snapshots ultérieurs ne stockent que les blocs modifiés.
  • Arbre des processusLes démons de longue durée reprennent en cours d'exécution, pas au démarrage.
  • État de la mémoireHeap, pile, mmaps. ~4 Go de disque supplémentaire pour la sauvegarde RAM.
  • Descripteurs de fichiers ouvertsLes sockets locaux et les FD survivent ; les pairs distants non.
  • Historique du terminalLes sessions tmux/screen en direct reprennent en pleine ligne.
ARRÊTÉcréer 1–5 s · démarrage froid 5–15 s

Stateless — conteneur arrêté

  • Système de fichiers (delta CoW)Même modèle de stockage incrémental que le mode stateful.
  • Arbre des processusLe conteneur démarre à nouveau à partir du système de fichiers capturé.
  • État de la mémoireAucune RAM n'est sauvegardée — économise du disque et du temps.
  • Descripteurs de fichiers ouvertsRéouverts par les nouveaux processus au démarrage à froid.
  • Fichiers de base de donnéesPostgres / SQLite se récupèrent à partir du WAL capturé.
use-cases / branch-computers-like-git / branch

Le branchement c'est un appel HTTP

Les snapshots sont des points d'alias nommés. /copy lance un conteneur séparé à partir de n'importe lequel d'entre eux — mêmes données, timeline divergente.

iterm
# 1) Marquez le point de branche.
curl -X POST "https://api.hoody.com/api/v1/containers/$CID/snapshots" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -d '["alias": "pre-migration", "expiry": 30]'

# 2) Restaurez sur place — revenez ce conteneur au snapshot.
curl -X PATCH "https://api.hoody.com/api/v1/containers/$CID/snapshots/pre-migration" \
  -H "Authorization: Bearer $HOODY_TOKEN"

# 3) Bifurquez — lancez un conteneur SÉPARÉ à partir du même snapshot.
curl -X POST "https://api.hoody.com/api/v1/containers/$CID/copy" \
  -H "Authorization: Bearer $HOODY_TOKEN" \
  -d '["target_project_id":"prod","name":"experiment-a","source_snapshot":"pre-migration"]'

La restauration revient sur place. Copy crée un conteneur indépendant qui vit par lui-même — ID différent, timeline différente, votre original continue de fonctionner. De toute façon c'est limité ; le stockage est incrémental, donc bon marché.

Flux de restaurationFenêtre de restauration · 5 à 15 secondes
0110:00Snapshot pris
0210:14La migration explose
0310:14:08Restauré
use-cases / branch-computers-like-git / powers

Ce que le modèle de branche déverrouille

Trois workflows qui étaient peu pratiques avec les snapshots VM et impossibles avec docker commit.

  1. 01

    Expériences parallèles

    Lancez N conteneurs à partir du même snapshot via /copy — essayez trois stratégies de migration en parallèle, conservez la gagnante.

  2. 02

    Prévalidez chaque déploiement risqué

    POSTez un snapshot avant tout changement destructif. La restauration de sept secondes est votre bouton d'annulation pour la machine entière.

  3. 03

    Timeline durable

    Les alias sont des points de branche nommés. snapshot_count est dans l'API container. Le stockage est incrémental, donc bon marché pour en conserver des dizaines.

use-cases / branch-computers-like-git / replaces

Ce que cela remplace

Si vous utilisez l'un de ces outils pour vous remettre d'un mauvais changement, le modèle de snapshot fait le même travail en 5-15 secondes avec un appel HTTP.

  • vm-snapshotsMinutes pour créer, Go de disque par snapshot
  • vagrantBoîtes locales, pas d'état partagé, pas de restauration à distance
  • docker commitSystème de fichiers seulement, pas de processus / pas de mémoire
  • sauvegardes manuellesrsync + une page wiki que personne ne lit
  • cycles pg_dumpDB seulement, laisse le reste de la boîte en mauvais état
  • reconstruire à partir de zéro30+ minutes, casse votre session d'édition
use-cases / branch-computers-like-git / cta

Git vous a donné le branchement pour le code. Hoody vous donne le branchement pour des ordinateurs entiers.

Lire l'API snapshot
use-cases / branch-computers-like-git / related

Découvrez les autres