L’Isolamento del Fork in Azione
Il tutorial sul fork ha mostrato i comandi. Questo mostra cosa significano: un’app database live, copiata in pochi secondi, modificata liberamente nel browser, mentre l’originale non si accorge di nulla.
Guarda il tutorial
La configurazione
Un PostgreSQL reale con un’interfaccia pgAdmin, live sul server. Un fork è una copia copy-on-write istantanea di tutto questo: stessi dati alla nascita, vite completamente separate dopo.
Passo 1: L’app live
rdc repo list --machine <machine-name>Inizia da un repository live: un database PostgreSQL con pgAdmin in esecuzione sulla macchina.
Passo 2: Fai il fork
rdc repo fork --parent demo-pgadmin --tag experiment --machine <machine-name> --up --detachEsegui il fork del repository con --up --detach: il clone CoW è quasi istantaneo e i servizi del fork si avviano immediatamente.
Il video apre entrambi i pgAdmin nel browser. L’originale chiede il login, perche la produzione rimane protetta. Il fork si apre direttamente nel workbench: i fork sono sandbox usa e getta, quindi il controllo di accesso si fa da parte (il repo lo decide da solo, in base al fatto che sia un fork o no).
Passo 3: Due mondi, un server
rdc repo list --machine <machine-name>Elenca i repository: l'originale e il fork girano fianco a fianco, completamente isolati.
Modifica, elimina, rompi qualsiasi cosa nel fork. L’originale continua a servire. Stesse tabelle al momento del fork, indipendenti per sempre dopo.
Passo 4: Buttalo via
rdc repo delete --name demo-pgadmin:experiment --machine <machine-name>Elimina il fork quando hai finito. Il repository originale rimane intatto.
Secondi per crearlo, secondi per eliminarlo. Questo è ciò che rende “clona la produzione, non rompere nulla” un’abitudine quotidiana invece di un evento speciale.
Successivo: Gestione dei Segreti.