Guide de migration

Migrez un projet existant, fichiers, services Docker, bases de données, depuis un serveur traditionnel ou un environnement de développement local vers un dépôt chiffré Rediacc.

Prérequis

• CLI rdc installé (Installation)
• Une machine ajoutée et provisionnée (Configuration)
• Suffisamment d’espace disque sur le serveur pour votre projet (vérifiez avec rdc machine status)

Étape 1 : Créer un dépôt

Créez un dépôt chiffré dimensionné pour votre projet. Prévoyez de l’espace supplémentaire pour les images Docker et les données des conteneurs.

rdc repo create --name my-project -m server-1 --size 20G

Astuce : Vous pouvez redimensionner plus tard avec rdc repo resize si nécessaire, mais le dépôt doit d’abord être démonté. Il est plus simple de commencer avec suffisamment d’espace.

Étape 2 : Téléverser vos fichiers

Utilisez rdc repo sync upload pour transférer les fichiers de votre projet dans le dépôt.

# Aperçu de ce qui sera transféré (aucune modification effectuée)
rdc repo sync upload -m server-1 -r my-project --local ./my-project --dry-run

# Téléverser les fichiers
rdc repo sync upload -m server-1 -r my-project --local ./my-project

Le dépôt doit être monté avant le téléversement. S’il ne l’est pas encore :

rdc repo mount --name my-project -m server-1

Pour les synchronisations suivantes où vous souhaitez que le distant corresponde exactement à votre répertoire local :

rdc repo sync upload -m server-1 -r my-project --local ./my-project --mirror

L’option --mirror supprime les fichiers sur le serveur distant qui n’existent pas en local. Utilisez d’abord --dry-run pour vérifier.

Étape 3 : Corriger la propriété des fichiers

Les fichiers téléversés arrivent avec l’UID de votre utilisateur local (par ex. 1000). Rediacc utilise un utilisateur universel (UID 7111) afin que VS Code, les sessions terminal et les outils aient un accès cohérent. Exécutez la commande de propriété pour convertir :

rdc repo ownership --name my-project -m server-1

Exclusion compatible Docker

Si des conteneurs Docker sont en cours d’exécution (ou ont été exécutés), la commande de propriété détecte automatiquement leurs répertoires de données accessibles en écriture et les ignore. Cela évite de casser des conteneurs qui gèrent leurs propres fichiers avec des UIDs différents (par ex. MariaDB utilise l’UID 999, Nextcloud utilise l’UID 33).

La commande affiche un rapport :

Excluding Docker volume: database/data
Excluding Docker volume: redis/data
Ownership set to UID 7111 (245 changed, 4 skipped, 0 errors)

Quand exécuter

• Après le téléversement des fichiers, pour convertir votre UID local en 7111
• Après le démarrage des conteneurs, si vous souhaitez que les répertoires de volumes Docker soient automatiquement exclus. Si les conteneurs n’ont pas encore été démarrés, il n’y a pas de volumes à exclure et tous les répertoires sont modifiés (ce qui est normal, les conteneurs recréeront leurs données au premier démarrage)

Mode forcé

Pour ignorer la détection des volumes Docker et modifier la propriété de tout, y compris les répertoires de données des conteneurs :

rdc repo ownership --name my-project -m server-1

Avertissement : Cela peut casser les conteneurs en cours d’exécution. Arrêtez-les d’abord avec rdc repo down si nécessaire.

UID personnalisé

Pour définir un UID autre que l’UID par défaut 7111 :

rdc repo ownership --name my-project -m server-1 --uid 1000

Étape 4 : Configurer votre Rediaccfile

Créez un Rediaccfile à la racine de votre projet. Ce script Bash définit comment vos services sont démarrés et arrêtés.

#!/bin/bash

up() {
    renet compose -- up -d
}

down() {
    renet compose -- down
}

Les trois fonctions du cycle de vie :

Fonction	Objectif	Comportement en cas d’erreur
up()	Démarrer les services	L’échec racine est critique ; les échecs dans les sous-répertoires sont journalisés et continuent
down()	Arrêter les services	Meilleur effort : tente toujours tout

Important : Utilisez toujours renet compose -- au lieu de docker compose dans votre Rediaccfile. Le wrapper renet compose impose le réseau hôte, les capacités de checkpoint/restore CRIU, l’allocation d’IP et la découverte de services requises par renet-proxy. L’utilisation directe de docker compose contourne tout cela et sera rejetée lors de la validation.

N’utilisez jamais sudo docker non plus, sudo réinitialise les variables d’environnement, y compris DOCKER_HOST, ce qui entraîne la création des conteneurs sur le daemon Docker du système au lieu du daemon isolé du dépôt. Les fonctions du Rediaccfile s’exécutent déjà avec des privilèges suffisants.

Voir Services pour tous les détails sur les Rediaccfiles, les configurations multi-services et l’ordre d’exécution.

Étape 5 : Configurer le réseau des services

Rediacc exécute un daemon Docker isolé par dépôt. Les services utilisent network_mode: host et se lient à des IPs de loopback uniques afin de pouvoir utiliser les ports standard sans conflits entre les dépôts.

Adapter votre docker-compose.yml

Avant (traditionnel) :

services:
  postgres:
    image: postgres:16
    ports:
      - "5432:5432"
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: secret

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  app:
    image: my-app:latest
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgresql://postgres:secret@postgres:5432/mydb
      REDIS_URL: redis://redis:6379

Après (Rediacc) :

services:
  postgres:
    image: postgres:16
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: secret
    command: -c listen_addresses=${POSTGRES_IP} -c port=5432

  redis:
    image: redis:7-alpine
    command: redis-server --bind ${REDIS_IP} --port 6379

  app:
    image: my-app:latest
    environment:
      DATABASE_URL: postgresql://postgres:secret@${POSTGRES_IP}:5432/mydb
      REDIS_URL: redis://${REDIS_IP}:6379
      LISTEN_ADDR: ${APP_IP}:8080

Modifications principales :

1. Supprimer les mappages ports:, renet compose utilise le réseau hôte et supprime automatiquement les mappages de ports
2. Supprimer network_mode: host, renet compose l’ajoute automatiquement
3. Supprimer restart: always ou restart: unless-stopped, ils entrent en conflit avec CRIU checkpoint/restore (Docker démarre automatiquement les conteneurs avant que le checkpoint restore ne puisse s’exécuter). Utilisez restart: on-failure si vous avez besoin d’un comportement de redémarrage, ou omettez-le entièrement, Rediaccfile up()/down() gère le cycle de vie des conteneurs
4. Lier les services aux variables d’environnement ${SERVICE_IP} (injectées automatiquement par Rediacc)
5. Référencer les autres services par leur IP au lieu des noms DNS Docker (par ex. ${POSTGRES_IP} au lieu de postgres)

Les variables {SERVICE}_IP sont automatiquement générées à partir des noms de services de votre fichier compose. Convention de nommage : majuscules, tirets remplacés par des underscores, suffixe _IP. Par exemple, listmonk-app devient LISTMONK_APP_IP.

Voir Réseau des services pour les détails sur l’attribution des IP et .rediacc.json.

Étape 6 : Démarrer les services

Montez le dépôt (s’il n’est pas déjà monté) et démarrez tous les services :

rdc repo up --name my-project -m server-1 --mount

Cela va :

1. Monter le dépôt chiffré
2. Démarrer le daemon Docker isolé
3. Générer automatiquement .rediacc.json avec les attributions d’IP des services
4. Exécuter up() de tous les Rediaccfiles

Vérifiez que vos conteneurs sont en cours d’exécution :

rdc machine containers server-1

Étape 7 : Activer le démarrage automatique (Optionnel)

Par défaut, les dépôts doivent être montés et démarrés manuellement après un redémarrage du serveur. Activez le démarrage automatique pour que vos services se lancent automatiquement :

rdc repo autostart enable --name my-project -m server-1

Vous serez invité à saisir la phrase de passe du dépôt.

Note de sécurité : Le démarrage automatique stocke un fichier de clé LUKS sur le serveur. Toute personne ayant un accès root peut monter le dépôt sans la phrase de passe. Voir Démarrage automatique pour plus de détails.

Scénarios de migration courants

WordPress / PHP avec base de données

my-wordpress/
├── Rediaccfile
├── docker-compose.yml
├── app/                    # Fichiers WordPress (UID 33 en exécution)
├── database/data/          # Données MariaDB (UID 999 en exécution)
└── wp-content/uploads/     # Fichiers uploadés par les utilisateurs

1. Téléversez les fichiers de votre projet
2. Démarrez d’abord les services (rdc repo up) pour que les conteneurs créent leurs répertoires de données
3. Exécutez la correction de propriété, les répertoires de données MariaDB et de l’application sont automatiquement exclus

Node.js / Python avec Redis

my-api/
├── Rediaccfile
├── docker-compose.yml
├── src/                    # Code source de l'application
├── node_modules/           # Dépendances
└── redis-data/             # Persistance Redis (UID 999 en exécution)

1. Téléversez votre projet (envisagez d’exclure node_modules et de les récupérer dans up())
2. Exécutez la correction de propriété après le démarrage des conteneurs

Projet Docker personnalisé

Pour tout projet avec des services Docker :

1. Téléverser les fichiers du projet
2. Adapter docker-compose.yml (voir Étape 5)
3. Créer un Rediaccfile avec les fonctions du cycle de vie
4. Exécuter la correction de propriété
5. Démarrer les services

Dépannage

Permission refusée après le téléversement

Les fichiers ont encore votre UID local. Exécutez la commande de propriété :

rdc repo ownership --name my-project -m server-1

Le conteneur ne démarre pas

Vérifiez que les services se lient à leur IP attribuée, pas à 0.0.0.0 ou localhost :

# Vérifier les IPs attribuées
rdc term connect -m server-1 -r my-project -c "cat .rediacc.json"

# Vérifier les logs du conteneur
rdc term connect -m server-1 -r my-project -c "docker logs <container-name>"

Conflit de ports entre les dépôts

Chaque dépôt reçoit des IPs de loopback uniques. Si vous rencontrez des conflits de ports, vérifiez que votre docker-compose.yml utilise ${SERVICE_IP} pour la liaison au lieu de 0.0.0.0. Les services liés à 0.0.0.0 écoutent sur toutes les interfaces et entreront en conflit avec d’autres dépôts.

La correction de propriété casse les conteneurs

Si vous avez exécuté rdc repo ownership et qu’un conteneur a cessé de fonctionner, les fichiers de données du conteneur ont été modifiés. Arrêtez le conteneur, supprimez son répertoire de données et redémarrez, le conteneur le recréera :

rdc repo down --name my-project -m server-1
# Supprimer le répertoire de données du conteneur (par ex. database/data)
rdc repo up --name my-project -m server-1