Перейти до вмісту
RailhookRailhookRailhook Docs
На сайт

Оновлення й резервні копії

Усе тут виконується з каталогу встановлення (типово ~/railhook) допоміжним скриптом railhook, який записав інсталятор.

Оновлення

Section titled “Оновлення”
Terminal window
cd ~/railhook
./railhook upgrade v2.16.6   # pin a release; with no version it keeps the tags already in .env

upgrade виконує кроки по черзі:

  1. Завантажує допоміжний скрипт і Caddyfile для цільового релізу.
  2. Закріплює API_IMAGE_TAG, WORKER_IMAGE_TAG і UI_IMAGE_TAG у .env.
  3. Робить резервну копію бази даних і зупиняється, якщо це не вдалося.
  4. Замінює docker-compose.yml копією з релізу, а ваш зберігає як docker-compose.yml.previous.
  5. Завантажує образи й перезапускає базу даних, кеш і панель керування.
  6. Замінює контейнери API по одному. Новий API виконує міграції релізу.
  7. Перезапускає воркер, щойно новий API почне обслуговувати запити.

Новий воркер не запускається на схемі без міграцій. Якщо він стартує раніше, ніж API завершить міграції (наприклад, ./railhook start після зміни тегів), він чекає до 15 хвилин і пише в лог Waiting for the API to migrate the schema.

З одним контейнером API клієнти бачать близько двадцяти секунд 502 під час заміни. API_REPLICAS=2 у .env прибирає цю перерву.

Відкат

Section titled “Відкат”

Відкат повертає образи, а не схему бази даних. Міграції виконуються лише вперед.

Terminal window
sed -i 's|^API_IMAGE_TAG=.*|API_IMAGE_TAG=2.16.5|' .env   # and WORKER_IMAGE_TAG, UI_IMAGE_TAG
./railhook start

Проблему в коді виправляють старі образи. Проблему в міграції виправляє резервна копія, яку зробило оновлення.

Перевірка встановлення

Section titled “Перевірка встановлення”
Terminal window
./railhook doctor

Повторно виконує перевірки машини й конфігурації з інсталятора для файлів на диску, тож помилку в .env, відредагованому вручну, видно до збою.

Резервна копія

Section titled “Резервна копія”
Terminal window
./railhook backup

Записує backup-<timestamp>.dump (формат custom PostgreSQL) у каталог встановлення. В інсталяціях, створених інсталятором, сервіс db-backup також робить дампи за розкладом:

Змінна Типово Значення
DB_BACKUP_INTERVAL_SECONDS 86400 Як часто робиться дамп
BACKUP_RETENTION_DAYS 30 Скільки зберігаються дампи
BACKUP_DIR ./backups Куди вони записуються

Відновлення

Section titled “Відновлення”

  1. Зупиніть API й воркер

    Terminal window
    cd ~/railhook
    set -a; . ./.env; set +a
    docker compose stop api worker

  2. Відновіть дамп

    Terminal window
    docker cp backup-20260913T020000Z.dump webhook-postgres:/tmp/restore.dump
    docker exec webhook-postgres pg_restore \
      -U "${POSTGRES_USER:-webhook_user}" -d "${POSTGRES_DB:-webhook_platform}" \
      --clean --if-exists --no-owner --no-privileges /tmp/restore.dump
    docker exec webhook-postgres rm -f /tmp/restore.dump

  3. Очистіть Redis

    Redis містить лише похідні дані, які відновлюються самі. Застарілий кеш гірший за порожній.

    Terminal window
    docker exec webhook-redis redis-cli -a "$REDIS_PASSWORD" FLUSHALL

  4. Запустіть стек

    Terminal window
    ./railhook start

Після відновлення доставки в стані очікування воркер забирає під час наступного опитування. Доставки, які були в роботі на момент дампу, воркер забирає знову, щойно мине час їх захоплення (WEBHOOK_CLAIM_TIMEOUT_SECONDS, типово 300), тож ендпоінт може отримати таку спробу двічі. Події, прийняті після дампу, втрачено.