Ниже — действия для уже созданного окружения. Для первого запуска выберите Prod-local, Source, Archive или Registry.
В командах ниже ENV_NAME — переменная оболочки с именем профиля из Deployment environments, а не именем проекта и не preset. В начале каждого блока замените значение production, local или dev своим именем, например ENV_NAME=test. Команды используют "$ENV_NAME", поэтому --env и подтверждение получают одно и то же значение. При переходе на другую машину или в новый терминал задайте переменную снова.
Начальное значение ENV_NAME=production — пример: подставьте имя своего серверного профиля. Контроллер читает его настройки из UI с custom-переопределениями; полный ручной JSON используется только при его наличии. Source выполняется на самом VPS, Archive/Registry — с управляющего компьютера.
Состояние и логи
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control status --env "$ENV_NAME" --json
bash ./deploy/control logs --env "$ENV_NAME" --service backend
Для журналов доступны backend, frontend и postgres. В status смотрите current, завершение операции и готовность компонентов. ready: null означает, что готовность не подтверждена.
Остановить и снова запустить
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control down --env "$ENV_NAME" --confirm "$ENV_NAME"
bash ./deploy/control up --env "$ENV_NAME" --confirm "$ENV_NAME"
Данные сохраняются. up запускает записанную версию. Для prod-local задайте в ENV_NAME имя своего локального профиля, например ENV_NAME=local; у локальных up/down подтверждение не требуется.
Выпустить новый код или вернуть старый
Для нового кода нужны build и deploy — полный порядок в обновлении приложения. JSON релиза создаётся сборкой, вручную его не пишут.
Для возврата к ранее успешному релизу:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control rollback --env "$ENV_NAME" --release RECORDED_RELEASE_ID --confirm "$ENV_NAME"
Подставьте сохранённый ID релиза. Rollback возвращает образы приложения, но не откатывает БД. Для возврата данных используйте backup и restore.
Если команда прервалась
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control status --env "$ENV_NAME" --json
bash ./deploy/control reconcile --env "$ENV_NAME" --json
Reconcile показывает состояние; сам ничего не исправляет. Из результата возьмите ID операции. Для поддерживаемой незавершённой операции можно продолжить её шаги:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control resume --env "$ENV_NAME" --operation OPERATION_ID --confirm "$ENV_NAME"
Либо закрыть операцию, если принято решение не продолжать её:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control abandon --env "$ENV_NAME" --operation OPERATION_ID --confirm "$ENV_NAME"
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. Примените изменение
Обычно:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME"
Для перехода Source → Archive/Registry выполните команду на действующем VPS, добавив --on-host:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME" --on-host
Это позволяет применить новые SSH-настройки ещё до перехода к управлению с компьютера или CI. Deployment-пользователь должен уже иметь доступ к существующим каталогам окружения: команда не переносит права на другого пользователя.
Для обратного перехода Archive/Registry → Source нужен один VPS. Выполняйте команду на этом VPS из checkout проекта, с новым delivery.mode: source, без --on-host. Source сам выбирает локальное выполнение.
4. После завершения
Передайте обновлённые generated/custom-файлы через Git на управляющую машину и синхронизируйте настройки CI, если он используется. Для Source доступен GitLab CI со сборкой на VPS; путь Git checkout задаётся в генераторе. Новые сборки выпускайте выбранным способом.
Если reconfigure прервался, сохраните тот же JSON, тот же файл секретов и повторите команду с ID из вывода:
ENV_NAME=production # замените на точное имя своего профиля в Deployment environments
bash ./deploy/control reconfigure --env "$ENV_NAME" --confirm "$ENV_NAME" --operation OPERATION_ID
Если первая команда использовала --on-host, добавьте его и при повторе. Не меняйте файлы между попытками. Обычный resume для этой операции не используется.
Backup, сертификаты и секреты
| Действие | Команда |
|---|---|
| Создать резервную копию | backup --env "$ENV_NAME" --confirm "$ENV_NAME" |
| Восстановить выбранную копию | restore --env "$ENV_NAME" --recovery-point ID --confirm-restore "$ENV_NAME" |
| Обслужить HTTPS-сертификаты | certificates --env "$ENV_NAME" --confirm "$ENV_NAME" |
| Сменить секрет | rotate-secrets --env "$ENV_NAME" --kind KIND --confirm "$ENV_NAME" |
Перед каждой строкой добавьте 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 пока нет команды автоматической очистки старых релизов.