Ниже — действия для уже созданного окружения. Для первого запуска выберите Prod-local, Source, Archive или Registry.
В примерах серверное окружение называется production: команды выбирают профиль production из UI с его custom-переопределениями; полный ручной JSON используется только при его наличии. Source выполняется на самом VPS, Archive/Registry — с управляющего компьютера.
Состояние и логи
bash ./deploy/control status --env production --json
bash ./deploy/control logs --env production --service backend
Для журналов доступны backend, frontend и postgres. В status смотрите current, завершение операции и готовность компонентов. ready: null означает, что готовность не подтверждена.
Остановить и снова запустить
bash ./deploy/control down --env production --confirm production
bash ./deploy/control up --env production --confirm production
Данные сохраняются. up запускает записанную версию. Для prod-local используйте --env local; у локальных up/down подтверждение не требуется.
Выпустить новый код или вернуть старый
Для нового кода нужны build и deploy — полный порядок в обновлении приложения. JSON релиза создаётся сборкой, вручную его не пишут.
Для возврата к ранее успешному релизу:
bash ./deploy/control rollback --env production --release RECORDED_RELEASE_ID --confirm production
Подставьте сохранённый ID релиза. Rollback возвращает образы приложения, но не откатывает БД. Для возврата данных используйте backup и restore.
Если команда прервалась
bash ./deploy/control status --env production --json
bash ./deploy/control reconcile --env production --json
Reconcile показывает состояние; сам ничего не исправляет. Из результата возьмите ID операции. Для поддерживаемой незавершённой операции можно продолжить её шаги:
bash ./deploy/control resume --env production --operation OPERATION_ID --confirm production
Либо закрыть операцию, если принято решение не продолжать её:
bash ./deploy/control abandon --env production --operation OPERATION_ID --confirm production
Abandon сохраняет данные и историю, но не отменяет выполненные миграции и не чинит приложение. Перед выбором действия откройте восстановление операций. У reconfigure свой способ повторного запуска, описанный ниже.
Изменить доставку или backup
reconfigure меняет доставку Source/Archive/Registry и настройки backup None/Local/S3 для существующего серверного окружения. Приложение остаётся запущенным; БД и медиа эта команда не переносит. Смену серверов, доменов, root, топологии и media выполняют отдельной процедурой, не через reconfigure.
1. Обновите инструменты до смены настроек
Текущий успешный релиз должен содержать поддержку reconfigure. Если он создан старым генератором, сначала выполните Generate, соберите и выпустите обновлённое приложение со старой доставкой и старым файлом окружения. Иначе команда сообщит, что текущему релизу не хватает инструментов.
2. Подготовьте новые настройки
Измените доставку или backup в профиле Generator UI, сохраните и выполните Generate. Для ручного дополнения используйте deploy/custom/environments/production.json. Проверьте Preview effective JSON; другие параметры оставьте прежними. Если проект всё ещё использует полный deploy/environments/production.json, изменяйте его либо сначала импортируйте его в UI по инструкции.
При переходе на Registry заполните три репозитория и подготовьте доступ к ним. Для S3 подготовьте хранилище и ключи. Новые секреты передаются файлом через DEPLOY_SECRETS_FILE, как в настройке окружения. Значения паролей не передаются аргументами команды.
3. Примените изменение
Обычно:
bash ./deploy/control reconfigure --env production --confirm production
Для перехода Source → Archive/Registry выполните команду на действующем VPS, добавив --on-host:
bash ./deploy/control reconfigure --env production --confirm production --on-host
Это позволяет применить новые SSH-настройки ещё до перехода к управлению с компьютера или CI. Deployment-пользователь должен уже иметь доступ к существующим каталогам окружения: команда не переносит права на другого пользователя.
Для обратного перехода Archive/Registry → Source нужен один VPS. Выполняйте команду на этом VPS из checkout проекта, с новым delivery.mode: source, без --on-host. Source сам выбирает локальное выполнение.
4. После завершения
Передайте обновлённые generated/custom-файлы через Git на управляющую машину и синхронизируйте настройки CI, если он используется. Для Source CI не применяется. Новые сборки выпускайте выбранным способом.
Если reconfigure прервался, сохраните тот же JSON, тот же файл секретов и повторите команду с ID из вывода:
bash ./deploy/control reconfigure --env production --confirm production --operation OPERATION_ID
Если первая команда использовала --on-host, добавьте его и при повторе. Не меняйте файлы между попытками. Обычный resume для этой операции не используется.
Backup, сертификаты и секреты
| Действие | Команда |
|---|---|
| Создать резервную копию | backup --env production --confirm production |
| Восстановить выбранную копию | restore --env production --recovery-point ID --confirm-restore production |
| Обслужить HTTPS-сертификаты | certificates --env production --confirm production |
| Сменить секрет | rotate-secrets --env production --kind KIND --confirm production |
Перед каждой строкой добавьте bash ./deploy/control. Для ротации доступны auth, postgres, media, backup, registry, db-leaf, db-ca. Полные инструкции: резервные копии и смена секретов.
При backup None копий не создаётся, backup/restore недоступны. Копия Local на том же сервере не защищает от потери самого сервера.
Все параметры собраны в справочнике deploy/control.
Проверить контейнеры и свободное место
docker ps -a на VPS показывает реальные контейнеры. Старый тег в docker image ls не означает, что старый контейнер работает. Для проверки назначений используйте руководство по Docker-образам, для кэша и архивов — очистку диска. У control пока нет команды автоматической очистки старых релизов.