Fork-Isolation in der Praxis

Das Forking-Tutorial hat die Befehle gezeigt. Dieses hier zeigt, was sie bedeuten: eine live laufende Datenbank-App, in Sekunden kopiert, im Browser frei bearbeitbar - während das Original nichts davon bemerkt.

Tutorial ansehen

Die Ausgangslage

Eine live Datenbank und ihr Zwilling

Ein echtes PostgreSQL mit pgAdmin-Oberfläche, live auf dem Server. Ein Fork ist ein sofortiger Copy-on-Write-Zwilling davon - gleiche Daten bei der Geburt, vollständig getrennte Leben danach.

Schritt 1: Die live App

rdc repo list --machine <machine-name>

Starte mit einem Live-Repository: eine PostgreSQL-Datenbank mit pgAdmin, die auf dem Rechner läuft.

Schritt 2: Forken

rdc repo fork demo-pgadmin --tag experiment --up --no-wait

Forke das Repository mit --up --detach: Der CoW-Klon ist nahezu sofort bereit und die Dienste des Forks starten umgehend.

Das Video öffnet beide pgAdmins im Browser. Das Original fordert einen Login - die Produktion bleibt geschützt. Der Fork öffnet direkt die Workbench: Forks sind wegwerfbare Sandboxen, daher tritt die Zugangskontrolle beiseite (das Repo entscheidet dies selbst, je nachdem ob es ein Fork ist).

Schritt 3: Zwei Welten, ein Server

rdc repo list --machine <machine-name>

Liste die Repositories auf: Das Original und der Fork laufen nebeneinander, vollständig isoliert.

Im Fork beliebig bearbeiten, löschen, kaputt machen - das Original läuft weiter. Gleiche Tabellen im Moment des Forkens, dauerhaft unabhängig danach.

Schritt 4: Wegwerfen

rdc repo delete demo-pgadmin:experiment --yes

Lösche den Fork, wenn du fertig bist. Das ursprüngliche Repository bleibt unberührt.

Sekunden zum Erstellen, Sekunden zum Verwerfen. Das ist es, was “Produktion klonen, nichts kaputt machen” zur täglichen Gewohnheit statt zu einem besonderen Ereignis macht.

Weiter: Secrets verwalten.