Forker un dépôt

Forkez un environnement de production entier (l’application, la base de données, les fichiers de configuration) en quelques secondes. Toute taille. Zéro disque supplémentaire. Forkez autant de fois que vous le souhaitez.

Le slogan : clonez la production, ne cassez rien.

Regarder le tutoriel

Créer quelque chose à perdre

Tout d’abord, donnez à l’application en cours d’exécution un fichier pour prouver l’isolation du fork. Ouvrez le dépôt dans VS Code, puis à l’intérieur du dépôt créez un fichier marqueur :

rdc vscode connect -m my-server -r my-app

Référence CLI : rdc vscode connect

echo "Hello from production" > index.html

Maintenant, forkez.

Fork

rdc repo fork --parent my-app -m <machine-name> --tag experiment --up

Une seule commande clone l'intégralité du repo : l'application, la base de données et les fichiers de configuration. Le temps de fork est constant quelle que soit la taille du repo, qu'il s'agisse d'un gigaoctet, cent gigaoctets ou un téraoctet.

Le parent se démultiplie en clones indépendants

Une seule commande. Tout a été cloné (l’application, la base de données, les fichiers de configuration) et cela s’est produit en quelques secondes. Relancez-la et vous obtenez un autre clone indépendant.

Pourquoi est-ce si rapide ?

Partager un lien de dossier prend le même temps quelle que soit la taille du dossier

La raison en est les reflinks btrfs. Un fork crée un nouvel arbre système de fichiers pointant vers les mêmes blocs de données que le parent. Aucune donnée n’est copiée au moment du fork. C’est purement une affaire de métadonnées, donc la taille du parent n’influe jamais sur le temps de création du fork.

1 Go, 100 Go, 1 To. Même temps, à chaque fois.

Le fork fonctionne de la même manière. 1 Go, 100 Go, 1 To. Même temps, à chaque fois.

Ce qui est partagé, ce qui vous appartient

Plusieurs miroirs, un soleil : base partagée, vos modifications vous appartiennent

Pensez au dépôt parent comme à une source fixe. Votre fork en est une vue copy-on-write. Écrivez dans le fork et les écritures restent dans le fork. Le parent ne bouge pas, peu importe combien de forks lui pointent dessus.

Vous ne pouvez pas tenir le soleil, mais vous pouvez le tenir dans un miroir.

Que se passe-t-il si le parent change ensuite ?

Un fork est une photographie figée ; le parent continue de couler comme une rivière

Pensez maintenant à un instantané. Quand vous forkez, vous figez le parent à ce moment précis. Le parent continue d’évoluer. Votre fork, non.

Si le dépôt parent change ensuite, votre fork reste là où il était.

Vous ne pouvez pas tenir une rivière, mais vous pouvez la tenir dans une photo.

L’utilisation du disque reste stable

Cinq forks d'un dépôt de 100 Go, toujours environ 100 Go au total

C’est pourquoi votre disque n’explose pas. Cinq forks d’un dépôt de 100 Go ? Toujours environ 100 Go au total. Vous ne payez en espace disque que ce que vous modifiez dans chaque fork.

Forkez cinq fois si vous le souhaitez. Votre disque ne le remarquera même pas.

Ce que les forks n’héritent pas : les secrets

Il y a une chose que le fork ne suit délibérément pas : les secrets. Un fork démarre sans clés API, sans mots de passe de base de données, sans tokens Stripe. C’est pourquoi “clonez la production, ne cassez rien” fonctionne vraiment. Votre sandbox ne peut pas facturer de vrais clients parce qu’il ne peut pas se faire passer pour vous. Nous configurons cela correctement dans le tutoriel Gérer les secrets.

Vérifier l’isolation

Listez les deux dépôts côte à côte :

rdc repo list -m <machine-name>

Les deux repos coexistent désormais sur la même machine et le même disque en tant qu'environnements entièrement indépendants.

Vous verrez my-app et my-app:experiment tournant simultanément. Dans l’original, le fichier marqueur est exactement là où vous l’avez laissé :

rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'

Vérifiez l'isolation en inspectant le repo original : le fichier marqueur est toujours en place. Créer un fork ne modifie pas le parent.

Maintenant effectuez un changement destructif, mais uniquement dans le fork :

rdc term connect -m <machine-name> --repository my-app:experiment --command 'rm index.html && echo removed'

Supprimez le fichier marqueur uniquement dans le fork. Il s'agit d'une modification destructive limitée au fork.

Revenez à l’original et vérifiez :

rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'

Revenez au repo original : le fichier marqueur est toujours intact. Le parent et le fork partagent la même image mais s'exécutent sur des Docker daemons distincts et des systèmes de fichiers séparés.

Le fichier marqueur est toujours là, intact. Les modifications du fork sont restées dans le fork. Mêmes images, daemons Docker séparés, systèmes de fichiers séparés.

Nettoyer

Quand vous avez terminé, supprimez simplement le fork :

rdc repo delete --name my-app:experiment -m <machine-name>

Supprimez le fork une fois terminé. Le repo original n'est pas affecté, ce qui permet un workflow sûr de fork, d'expérimentation et de suppression.

L’original reste exactement comme il était. Forkez, expérimentez, cassez des choses, supprimez. Aucun risque.

Suivant : L’isolation des forks en pratique.