Оновлення з 1.x до 2.0

SnapOtter 1.x зберігав усе в одному файлі SQLite і працював як один контейнер. SnapOtter 2.0 використовує PostgreSQL та Redis. Цей посібник проведе вас через перенесення встановлення 1.x до 2.0 без втрати даних.

Коротко: повторно використайте наявний том /data, і 2.0 автоматично імпортує вашу базу даних 1.x під час першого запуску. Ваші користувачі, збережені файли, налаштування, ключі API та конвеєри переносяться. Стара база даних ніколи не змінюється, тож ви завжди можете відкотитися.

Примітка для наших користувачів 1.x

Багато хто з вас довіряв SnapOtter із першого дня, і ваш відгук сформував цей реліз. 2.0 змінює багато чого під капотом, і цей посібник існує для того, щоб перехід не коштував вам нічого з того, що вам дороге. Ваші облікові записи, файли, налаштування, ключі API та конвеєри переносяться, а вашу стару базу даних ніколи не чіпають. Дякуємо, що оновлюєтеся разом із нами.

Перед початком: створіть резервну копію всього тому /data

Робіть це першим, щоразу. Створіть резервну копію всього тому /data, а не лише файлу snapotter.db.

Ось чому це важливо. 1.x запускає SQLite у режимі WAL, тож зупинений контейнер 1.x зазвичай залишає більшість своїх зафіксованих даних у snapotter.db-wal поруч із майже порожнім snapotter.db. Копіювання лише snapotter.db захоплює порожню базу даних і мовчки втрачає все. Том несе разом snapotter.db, snapotter.db-wal, snapotter.db-shm та ваш каталог files/, і вони мають подорожувати як єдиний набір.

# Adjust the volume name to match yours (see "Check your volume name" below).
docker run --rm -v SnapOtter-data:/data -v "$PWD":/backup \
  alpine tar czf /backup/snapotter-1x-data.tgz -C /data .

Спочатку оновіть до 1.17.2

Оновіть своє встановлення 1.x до останнього релізу 1.x (1.17.2) перед переходом на 2.0. Це дозволить 1.x виконати власні фінальні міграції схеми, тож 2.0 імпортуватиме з відомої, повної схеми. Оновлення зі старішого 1.x напряму до 2.0 не підтримується.

Перевірте назву свого тому

Імпортер бачить ваші дані лише якщо стек 2.0 монтує той самий том, який використовувало ваше встановлення 1.x. Назви томів Docker чутливі до регістру, а старіші фрагменти README використовували малими літерами snapotter-data, тоді як файли Compose використовують SnapOtter-data. Підтвердьте, який із них у вас:

docker volume ls | grep -i snapotter

Використовуйте саме цю назву у своїй конфігурації 2.0.

Шлях A: один контейнер (найшвидший)

Якщо ви запускаєте SnapOtter одним docker run, продовжуйте так робити. 2.0 запускає вбудований PostgreSQL та Redis усередині контейнера, коли ви не задаєте DATABASE_URL чи REDIS_URL, і автоматично виявляє та імпортує /data/snapotter.db під час першого запуску.

docker run -d --name snapotter -p 1349:1349 \
  -v SnapOtter-data:/data \
  snapotter/snapotter:latest

Стежте за логами на предмет рядка на кшталт:

Imported 1.x SQLite database: {"tables":{"users":2,"teams":1,...},"blobs":{"present":1,"missing":0}}

Ось і все. Увійдіть зі своїми наявними обліковими даними.

Шлях B: Compose (рекомендовано для продакшену)

Стек Compose у 2.0 запускає три сервіси (застосунок, Postgres, Redis). Повторно використайте свій том /data з 1.x для сервісу застосунку. Застосунок автоматично виявляє /data/snapotter.db та імпортує його в Postgres під час першого запуску.

services:
  SnapOtter:
    image: snapotter/snapotter:latest
    volumes:
      - SnapOtter-data:/data          # your existing 1.x volume
      - SnapOtter-workspace:/tmp/workspace
    environment:
      - DATABASE_URL=postgres://snapotter:snapotter@postgres:5432/snapotter
      - REDIS_URL=redis://:snapotter@redis:6379
    # ...

Якщо ви радше хочете явно вказати на стару базу даних, задайте SQLITE_MIGRATE_PATH=/data/snapotter.db. Явний шлях завжди має перевагу над автовиявленням.

Спочатку перегляньте імпорт (необов'язково)

Щоб побачити точно, що буде імпортовано, нічого не записуючи, виконайте пробний запуск проти файлу вашої бази даних:

pnpm --filter @snapotter/api migrate:sqlite -- /path/to/snapotter.db --dry-run

Він виводить кількість рядків по кожній таблиці, скільки файлів збереженої бібліотеки знайдено на диску, а також будь-які статуси завдань, які він нормалізуватиме. Йому не потрібен запущений Postgres.

Що переноситься, а що ні

Переноситься:

• Користувачі та можливість входу. Хеші паролів незмінні, тож ті самі ім'я користувача й пароль працюють.
• Команди, налаштування (зокрема ідентичність вашого екземпляра), ролі, ключі API (вони продовжують працювати) та збережені конвеєри.
• Записи історії завдань.
• Ваша бібліотека збережених файлів, як записи, так і самі файли, оскільки /data/files зберігається на томі.

Не переноситься:

• Сеанси входу. Кожен входить один раз після оновлення. Облікові дані незмінні, тож це один повторний вхід, не більше.
• Вхідні та вихідні файли старих завдань обробки. Вони жили в тимчасовому робочому просторі й зникли за задумом. Записи історії завдань залишаються.
• Прапорці згоди на аналітику для кожного користувача з 1.x, які не мають еквівалента в 2.0 (аналітика 2.0 - це налаштування на рівні екземпляра).

Вимкнення імпорту

Якщо ви навмисне хочете отримати чисту базу даних, навіть попри те, що snapotter.db присутній на томі, задайте SQLITE_MIGRATE_PATH=off.

Якщо у вас уже є дані в екземплярі 2.0

Імпортер працює лише з порожньою базою даних. Якщо ви запустили 2.0 з нуля (створивши дані), а потім змонтували старий snapotter.db, 2.0 виявить його, але не імпортуватиме, оскільки об'єднання двох наборів даних може призвести до колізій за ID. Ви побачите попередження в логах. Щоб імпортувати дані 1.x, вам потрібен порожній екземпляр:

• Якщо екземпляр 2.0 містить лише типового адміністратора (ви ним фактично не користувалися), зупиніть стек, видаліть том Postgres (SnapOtter-pgdata) та запустіть знову за наявності старого /data. Він імпортується чисто. Це стирає лише одноразові дані Postgres, а не вашу базу даних 1.x.
• Якщо екземпляр 2.0 містить реальні дані, які ви хочете зберегти, два набори даних не можна автоматично об'єднати. Експортуйте те, що потрібно, та імпортуйте дані 1.x в окреме чисте розгортання.

Відкат

Оновлення ніколи не змінює й не видаляє ваш snapotter.db з 1.x. Якщо вам потрібно повернутися до 1.x, повторно розгорніть образ 1.x проти того самого тому. Усе, що ви створили в 2.0 після оновлення, живе в Postgres і не буде в базі даних 1.x, тож відкочуйтеся оперативно, якщо збираєтеся це робити.