Обновление и резервное копирование
Актуально для: SimpleTwo 0.9.x · Проверено: 20.09.2026
1. Порядок обновления
Сначала координатор, потом роли. Бинарники ролей лежат внутри образа координатора: пока он не обновлён, «переустановить роль» поставит ту же версию, что стоит сейчас.
Шаг 1. Координатор — новый тег образа:
cd /opt/simpletwo
sed -i 's|:v[0-9.]*$|:v0.9.240|' .env # меняется только тег
docker compose pull && docker compose up -d
curl -fsS http://127.0.0.1/healthz
curl -fsS https://<адрес>/v1/version
Шаг 2. Роли — в консоли, Redeploy на каждом хосте. Роли можно обновлять по одной: установка идёт по тому же описанию, что и первичная, и повторный запуск ничего не ломает.
Шаг 3. Клиенты обновляются сами: macOS — по ленте обновлений, магазины — своим путём, APK — со страницы загрузок. Специально гнать парк не нужно; в консоли видно, у кого какая версия осталась.
Выкат не закончен, пока служба не ответила на /healthz, а /v1/version не показал ту
версию, которую вы выкатывали. Это не перестраховка: половина «загадочных» разборов начинается
с того, что в проде работает прошлая версия, а смотрят на новую.
2. Откат
Тот же файл с предыдущим тегом: прошлые образы остаются в реестре.
sed -i 's|:v[0-9.]*$|:v0.9.239|' .env && docker compose up -d
Роли откатываются так же — через Redeploy после отката координатора.
Откат не восстанавливает данные. Если версия успела изменить схему базы, откат вернёт код, но не строки: это случай для восстановления из копии, а не для отката тега.
3. Что копировать
Четыре вещи, и первые две — не одна:
| Что | Где | Чем |
|---|---|---|
| Том данных координатора | хост координатора | база плоскости управления, сертификаты, опубликованные сборки |
| Файл мастер-ключа | хост координатора, вне тома данных | единственное, чем открывается зашифрованная база |
| Базы Postgres | хост postgres или внешний кластер | pg_dump по расписанию |
| Объектное хранилище / вложения | роль s3, внешнее хранилище или диск messaging | средствами хранилища |
Копия тома данных без файла ключа не откроется. Копия тома данных вместе с ключом, лежащая в одном месте, означает, что одна украденная копия — это и данные, и ключ к ним. Поэтому ключ хранится вне каталога данных и копируется отдельно, со своим доступом. Лист восстановления, напечатанный при включении шифрования, — третий экземпляр этой же истины, и он должен лежать там, где лежат бумажные секреты организации.
4. Восстановление
Порядок обратный установке:
- поднять координатор той же версии, что снималась копия, и вернуть том данных;
- вернуть файл ключа на прежний путь (
ST_KEYSTORE_PATH) — до первого запуска служб; - восстановить базы Postgres;
- восстановить объектное хранилище;
- переустановить роли из консоли — они возьмут актуальное описание;
- проверить сценарием целиком, а не по одному
/healthz: вход, сообщение на второе устройство, звонок один на один, встреча с внешним участником, туннель.
Пока нет внешнего хранилища, минимум — ежедневная копия на другой хост и еженедельная выгрузка наружу. И проверьте восстановление один раз при запуске, а не в тот день, когда оно понадобится: невосстановленная копия — это предположение, а не резервная копия.