L’isolation des forks en pratique
Le tutoriel sur le forking vous a montré les commandes. Celui-ci montre ce qu’elles signifient : une application de base de données en direct, copiée en quelques secondes, modifiée librement dans le navigateur, pendant que l’original ne s’aperçoit de rien.
Regarder le tutoriel
La mise en place
Un vrai PostgreSQL avec une interface pgAdmin, en direct sur le serveur. Un fork est une copie instantanée copy-on-write de tout cela : mêmes données à la naissance, vies totalement séparées ensuite.
Étape 1 : L’application en direct
rdc repo list --machine <machine-name>Partez d'un repository en direct : une base de données PostgreSQL avec pgAdmin en cours d'exécution sur la machine.
Étape 2 : La forker
rdc repo fork --parent demo-pgadmin --tag experiment --machine <machine-name> --up --detachForkez le repository avec --up --detach : le clone CoW est quasi instantané et les services du fork démarrent immédiatement.
La vidéo ouvre les deux pgAdmin dans le navigateur. L’original demande une connexion, car la production reste protégée. Le fork s’ouvre directement dans le workbench : les forks sont des sandboxes jetables, donc la barrière s’efface (le dépôt décide lui-même, selon qu’il s’agit ou non d’un fork).
Étape 3 : Deux mondes, un seul serveur
rdc repo list --machine <machine-name>Listez les repositories : l'original et le fork tournent côte à côte, complètement isolés.
Modifiez, supprimez, cassez n’importe quoi dans le fork. L’original continue de servir. Mêmes tables au moment du fork, indépendants pour toujours ensuite.
Étape 4 : Le jeter
rdc repo delete --name demo-pgadmin:experiment --machine <machine-name>Supprimez le fork quand vous avez terminé. Le repository original n'est pas affecté.
Des secondes pour créer, des secondes pour supprimer. C’est ce qui fait de “clonez la production, ne cassez rien” une habitude quotidienne plutôt qu’un événement exceptionnel.
Suivant : Gérer les secrets.