Обновления и резервное копирование

Сопровождение установки, созданной с помощью мастера#

Скрипт manage.sh установщика поддерживает команды status, logs, create-account, certificates и reload-tls. В нем нет команды update. Повторный запуск install.sh или возобновление прерванной установки не приводит к обновлению сервера.

В документированной версии инструменты выпуска оператора принимают имена проектов recorder-staging и recorder-production и выбирают собственные оверлеи Compose. Вместо этого мастер создает проект meetspace с автоматически сгенерированными переопределениями. Документированного автоматического адаптера между этими макетами не существует. План обновления должен сохранять фактический проект, тома, конфигурацию и поставщика хранилища. Не меняйте имя проекта, чтобы обойти ошибку проверки.

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

Обновление выпуска, управляемого оператором#

Развёртывание выполняется последовательно и может прервать работу сервиса на одном сервере. Обновление не гарантирует отсутствие простоя и не переносит активную встречу между SFU. Если истекает время ожидания завершения активной работы (drain), сервис остаётся в этом режиме, а операция останавливается без принудительного перезапуска.

Обновление базы данных, брокера и объектного хранилища - это отдельные операции по техническому обслуживанию. Не изменяйте образы PostgreSQL, Redis, RabbitMQ, MinIO или SeaweedFS в рамках обновления приложения. В частности, при смене поставщика хранилища требуется явная миграция данных.

Файлы миграции отслеживаются по SHA-256 их точного байтового представления. Никогда не редактируйте и не переименовывайте уже примененные SQL-миграции. При откате приложения не выполняются обратные миграции базы данных и не восстанавливаются данные.

1. Просмотрите целевой коммит, примечания к выпуску, изменения в миграциях и конфигурации. Подготовьте установленный манифест, образы и совместимую среду к возможному откату.
2. Один раз соберите и просканируйте целевой коммит. Для планового обновления приложения передайте пакету package.sh параметр --infrastructure-manifest с предыдущим проверенным файлом release.json, чтобы идентификаторы образов инфраструктуры остались неизменными.
3. Отрепетируйте миграцию, развертывание, проверку медиафайлов и откат в изолированной среде с репрезентативными данными.
4. Запланируйте окно обслуживания, запретите запуск новых встреч и записей, завершите текущую работу и остановите все операции изменения данных. Перед миграцией создайте и проверьте согласованную резервную копию.
5. Запустите release.sh validate и pull для получения точной копии целевого коммита, затем выполните миграцию перед развертыванием. Для внесения изменений в производственную среду требуется одобрение с привязкой к версии и подтверждение того, что все проверки были выполнены.
6. Сравните /version и /version.json с целевым манифестом, проверьте внутренние проверки готовности и журналы. До возобновления обычного трафика убедитесь, что работают вход, сообщения, медиасвязь и доступ к существующим записям.

Что должна содержать резервная копия#

Помощник по резервному копированию репозитория сохраняет логический дамп PostgreSQL и текущие версии объектов в настроенном сегменте S3 вместе с установленным манифестом релизов и метаданными о целостности. Копии базы данных и объектов не являются атомарными снимками: все операции записи должны быть остановлены на все время создания резервной копии.

При установке с помощью мастера сохраните /opt/meetspace/config, certs, secrets, installation.json и проверенный пакет в качестве материалов для восстановления, а также данные базы данных и объектов. Хранилище может находиться в именованных томах Docker, а не в папке /opt/meetspace.

Храните резервные копии в зашифрованном виде вне сервера и ограничьте к ним доступ. Помощник создает закрытые файлы, но не шифрует их самостоятельно. Определите сроки хранения, допустимую потерю данных и время восстановления для вашей организации; проект не устанавливает эти правила за вас.

Создайте согласованную резервную копию#

Следующий пример предназначен для уже подготовленной тестовой среды под управлением оператора. Он не подходит напрямую для проекта meetspace, созданного автономным мастером. Перед запуском переведите соответствующую среду в режим drain и обеспечьте полную остановку записи данных.

1. Запишите точный установленный манифест и конфигурацию. Исключите одновременное развертывание, миграцию и техническое обслуживание.
2. Не допускайте появления новых рабочих процессов в общедоступной точке входа. Дождитесь завершения совещаний, начала записи, финализации, загрузки и фоновых задач, пока еще доступны обычные средства остановки.
3. Переведите приложение в режим ожидания завершения активной работы (drain) и убедитесь, что активные операции и команды записи в очереди завершены. Остановите внешние процессы изменения данных, задания по расписанию, прямые изменения базы данных и незавершённые загрузки по подписанным ссылкам.
4. Только после подтверждения глобального запрета на запись установите RELEASE_BACKUP_QUIESCED=1 и запустите backup.sh в новом абсолютном каталоге для соответствующего проекта, управляемого оператором.
5. Убедитесь, что были созданы файлы postgres.dump, objects/manifest.json, объектные файлы, release.json и backup.json. Если после ошибки остался частично заполненный каталог, считайте его незавершённым.
6. Не снимайте запрет на запись до тех пор, пока не будут скопированы оба хранилища данных. После успешного резервного копирования возобновите работу с той же установленной версией или сохраните окно обслуживания для запланированной миграции.

export RELEASE_BACKUP_QUIESCED=1
bash scripts/release/backup.sh \
  --environment staging --project recorder-staging \
  --env-file /srv/meet/config/staging.env \
  --manifest /srv/meet/releases/INSTALLED_VERSION/release.json \
  --output /srv/meet/private-backups/NEW_BACKUP_DIRECTORY
unset RELEASE_BACKUP_QUIESCED

Проверьте возможность восстановления до того, как она вам понадобится#

Запустите restore-check.sh в выделенной локальной или промежуточной среде с независимыми данными PostgreSQL и S3. При этом создается новая база данных и корзина, а не выполняется восстановление поверх рабочих данных. Сначала подготовьте эту среду, так как помощник не запускает зависимые процессы.

Проверка сверяет хэши резервных копий, восстанавливает базу данных и журнал миграций, содержимое объектов и проверяет приватный доступ. После проверки остаются отчет, временная база данных и корзина, которые можно изучить, в том числе после частичного сбоя. Успешное резервное копирование само по себе не является гарантией успешного восстановления.

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

bash scripts/release/restore-check.sh \
  --environment staging --project recorder-staging-restore \
  --env-file /srv/meet/config/restore.env \
  --manifest /srv/meet/releases/INSTALLED_VERSION/release.json \
  --backup /srv/meet/private-backups/VERIFIED_BACKUP_DIRECTORY

Обновление TLS-сертификатов#

С помощью Let’s Encrypt мастер включает certbot.timer и хук развертывания, который копирует обновленные учетные данные, перезагружает Nginx и перезапускает Coturn. Обеспечьте доступность TCP-порта 80 для обновления. Перезапуск Coturn может привести к кратковременному прерыванию вызовов с использованием TURN.

Для существующего сертификата обновите файлы fullchain.pem и privkey.pem в исходном каталоге, выбранном при установке, а затем выполните команду certificates. Если другой инструмент уже заменил рабочие копии в каталоге certs, созданном при установке, используйте команду reload-tls.

# Скопируйте обновленные сертификаты из настроенного исходного каталога:
sudo /opt/meetspace/manage.sh certificates

# Или перезагрузите сертификаты, уже обновленные при установке:
sudo /opt/meetspace/manage.sh reload-tls