Руководство по миграции

Перенесите существующий проект, файлы, Docker-сервисы, базы данных, с традиционного сервера или локальной среды разработки в зашифрованный репозиторий Rediacc.

Предварительные требования

• Установленный CLI rdc (Установка)
• Добавленная и подготовленная машина (Настройка)
• Достаточно дискового пространства на сервере для вашего проекта (проверьте с помощью rdc machine status)

Шаг 1: Создание репозитория

Создайте зашифрованный репозиторий достаточного размера для вашего проекта. Выделите дополнительное пространство для Docker-образов и данных контейнеров.

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

Совет: Вы можете изменить размер позже с помощью rdc repo resize, но репозиторий сначала необходимо отмонтировать. Проще начать с достаточного объёма.

Шаг 2: Загрузка файлов

Используйте rdc repo sync upload для передачи файлов проекта в репозиторий.

# Предварительный просмотр того, что будет передано (без изменений)
rdc repo sync upload -m server-1 -r my-project --local ./my-project --dry-run

# Загрузка файлов
rdc repo sync upload -m server-1 -r my-project --local ./my-project

Перед загрузкой репозиторий должен быть смонтирован. Если он ещё не смонтирован:

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

Для последующих синхронизаций, когда удалённая копия должна точно соответствовать локальному каталогу:

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

Флаг --mirror удаляет файлы на удалённом сервере, которые не существуют локально. Сначала используйте --dry-run для проверки.

Шаг 3: Исправление владения файлами

Загруженные файлы приходят с UID вашего локального пользователя (например, 1000). Rediacc использует универсального пользователя (UID 7111), чтобы VS Code, терминальные сессии и инструменты имели единообразный доступ. Выполните команду изменения владельца:

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

Исключения с учётом Docker

Если Docker-контейнеры запущены (или были запущены), команда владения автоматически обнаруживает их записываемые каталоги данных и пропускает их. Это предотвращает повреждение контейнеров, которые управляют своими файлами с другими UID (например, MariaDB использует UID 999, Nextcloud использует UID 33).

Команда выводит отчёт:

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

Когда запускать

• После загрузки файлов, для преобразования вашего локального UID в 7111
• После запуска контейнеров, если вы хотите, чтобы каталоги Docker-томов были автоматически исключены. Если контейнеры ещё не были запущены, томов для исключения нет, и все каталоги будут изменены (это нормально, контейнеры пересоздадут свои данные при первом запуске)

Принудительный режим

Чтобы пропустить обнаружение Docker-томов и изменить владельца всего, включая каталоги данных контейнеров:

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

Предупреждение: Это может повредить работающие контейнеры. Сначала остановите их с помощью rdc repo down, если необходимо.

Пользовательский UID

Чтобы установить UID, отличный от стандартного 7111:

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

Шаг 4: Настройка Rediaccfile

Создайте Rediaccfile в корне вашего проекта. Этот Bash-скрипт определяет, как ваши сервисы запускаются и останавливаются.

#!/bin/bash

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

down() {
    renet compose -- down
}

Две функции жизненного цикла:

Функция	Назначение	Поведение при ошибке
up()	Запуск сервисов	Ошибка в корне критична; ошибки в подкаталогах логируются и продолжаются
down()	Остановка сервисов	Максимальное усилие: всегда пытается выполнить всё

Важно: Всегда используйте renet compose -- вместо docker compose в вашем Rediaccfile. Обёртка renet compose обеспечивает host-сеть, возможности CRIU checkpoint/restore, назначение IP и обнаружение сервисов, необходимые для renet-proxy. Прямое использование docker compose обходит всё это и будет отклонено при валидации.

Также никогда не используйте sudo docker, sudo сбрасывает переменные окружения, включая DOCKER_HOST, из-за чего контейнеры создаются в системном Docker-демоне, а не в изолированном демоне репозитория. Функции Rediaccfile уже выполняются с достаточными привилегиями.

Подробнее о Rediaccfile, многосервисных конфигурациях и порядке выполнения см. Сервисы.

Шаг 5: Настройка сети сервисов

Rediacc запускает изолированный Docker-демон для каждого репозитория. Сервисы используют network_mode: host и привязываются к уникальным loopback-IP, чтобы использовать стандартные порты без конфликтов между репозиториями.

Адаптация docker-compose.yml

До (традиционный подход):

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

После (Rediacc):

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

  redis:
    image: redis:7-alpine

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

Основные изменения:

1. Удалить маппинги ports: - renet compose использует host-сеть и автоматически удаляет маппинги портов
2. Удалить network_mode: host - renet compose добавляет это автоматически
3. Политики перезапуска можно оставить - renet автоматически удаляет их для совместимости с CRIU, а watchdog роутера автоматически восстанавливает остановленные контейнеры
4. Использовать имена сервисов для межсервисных соединений (например, postgres, redis) - renet инжектирует каждое имя сервиса как разрешаемое имя хоста. Не встраивайте сырые IP в строки подключений, хранящиеся в базах данных или конфигурационных файлах; используйте имя сервиса для сохранения изоляции форков
5. Привязка выполняется автоматически - ядро перезаписывает bind() на правильный loopback-IP. Сервисы могут использовать 0.0.0.0 или localhost

Переменные {SERVICE}_IP по-прежнему доступны при необходимости, но явная привязка больше не требуется. Соглашение об именовании: верхний регистр, дефисы заменяются подчёркиваниями, суффикс _IP. Например, listmonk-app становится LISTMONK_APP_IP.

Подробнее о назначении IP и .rediacc.json см. Сетевое взаимодействие сервисов.

Шаг 6: Запуск сервисов

Смонтируйте репозиторий (если ещё не смонтирован) и запустите все сервисы:

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

Это выполнит:

1. Монтирование зашифрованного репозитория
2. Запуск изолированного Docker-демона
3. Автоматическую генерацию .rediacc.json с назначением IP сервисов
4. Выполнение up() из всех Rediaccfile

Убедитесь, что ваши контейнеры запущены:

rdc machine containers --name server-1

Шаг 7: Включение автозапуска (необязательно)

По умолчанию репозитории необходимо монтировать и запускать вручную после перезагрузки сервера. Включите автозапуск, чтобы ваши сервисы запускались автоматически:

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

Вам будет предложено ввести парольную фразу репозитория.

Примечание о безопасности: Автозапуск сохраняет ключевой файл LUKS на сервере. Любой пользователь с root-доступом может смонтировать репозиторий без парольной фразы. Подробнее см. Автозапуск.

Типичные сценарии миграции

WordPress / PHP с базой данных

my-wordpress/
├── Rediaccfile
├── docker-compose.yml
├── app/                    # Файлы WordPress (UID 33 при работе)
├── database/data/          # Данные MariaDB (UID 999 при работе)
└── wp-content/uploads/     # Загрузки пользователей

1. Загрузите файлы проекта
2. Сначала запустите сервисы (rdc repo up), чтобы контейнеры создали свои каталоги данных
3. Выполните исправление владения, каталоги данных MariaDB и приложения автоматически исключаются

Node.js / Python с Redis

my-api/
├── Rediaccfile
├── docker-compose.yml
├── src/                    # Исходный код приложения
├── node_modules/           # Зависимости
└── redis-data/             # Персистентность Redis (UID 999 при работе)

1. Загрузите проект (рассмотрите исключение node_modules и получение их в up())
2. Выполните исправление владения после запуска контейнеров

Пользовательский Docker-проект

Для любого проекта с Docker-сервисами:

1. Загрузить файлы проекта
2. Адаптировать docker-compose.yml (см. Шаг 5)
3. Создать Rediaccfile с функциями жизненного цикла
4. Выполнить исправление владения
5. Запустить сервисы

Устранение неполадок

Отказ в доступе после загрузки

Файлы всё ещё имеют ваш локальный UID. Выполните команду изменения владельца:

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

Контейнер не запускается

Убедитесь, что сервисы запущены, и проверьте их логи:

# Проверить назначенные IP
rdc term connect -m server-1 -r my-project -c "cat .rediacc.json"

# Проверить логи контейнера
rdc term connect -m server-1 -r my-project -c "docker logs <container-name>"

Конфликт портов между репозиториями

Каждый репозиторий получает уникальные loopback-IP, и ядро автоматически перезаписывает вызовы bind() на правильный IP. Конфликты портов между репозиториями не должны возникать. Если вы наблюдаете неожиданное поведение, убедитесь, что сервисы запускаются через renet compose (не docker compose). При подключении к другим сервисам используйте имя сервиса (например, postgres) вместо сырых IP; имена сервисов правильно разрешаются в каждом форке.

Исправление владения повредило контейнеры

Если вы выполнили rdc repo ownership и контейнер перестал работать, файлы данных контейнера были изменены. Остановите контейнер, удалите его каталог данных и перезапустите, контейнер пересоздаст его:

rdc repo down --name my-project -m server-1
# Удалить каталог данных контейнера (например, database/data)
rdc repo up --name my-project -m server-1