Registry — хранилище Docker-образов. Mac собирает приложение и отправляет туда образы, а VPS скачивает и запускает их. Репозиторий Git хранит исходники; registry хранит собранное приложение. Они могут находиться у разных провайдеров.
Ниже — ручной выпуск на один VPS с Docker Hub, локальными рабочими изображениями и отключёнными backup.
1. Создайте репозитории образов
В своём registry создайте три репозитория: для backend, admin и ops. Ops — служебный образ команд deployment. Для Docker Hub пример адресов:
docker.io/your-namespace/example-backend
docker.io/your-namespace/example-admin
docker.io/your-namespace/example-ops
your-namespace замените своим именем пользователя или организации в Docker Hub. Это не IP сервера, не домен приложения и не имя проекта Git. Названия трёх репозиториев выбираете вы; все три должны находиться на одном registry-хосте.
В настройках registry подготовьте токен для Mac с правами отправки образов. Токен — секрет доступа, которым заменяют пароль при Docker login. Для приватных репозиториев также нужен отдельный долговременный токен чтения для VPS. Он должен работать после окончания сборки или CI-job.
2. Создайте профиль в Generator UI
В Deployment включите Docker и Production deployment, выберите CI provider → None. В Deployment environments создайте профиль production с preset Single server. Внутри профиля выберите Image delivery → Pull from registry, заполните свои домены, TLS contact email и Runtime directory. В Backup destination выберите None; для рабочих изображений используется Local files, выбранный для проекта.
Подробное пояснение полей — в подготовке профиля. Нажмите Save deployment settings, затем Generate. Настройки появятся в deploy/generated/environments/production.json; пустой custom-файл рядом в deploy/custom/environments/ можно пока не менять. Копировать JSON в deploy/environments/ не требуется.
В профиле выберите Registry provider и заполните backend/admin/ops image repository адресами из первого шага. Закоммитьте сгенерированные файлы: registry-build требует чистые отслеживаемые исходники backend, admin и deploy.
3. Подготовьте VPS и SSH
Выполните подготовку сервера, затем настройте SSH на своём компьютере по подготовке окружения. В профиле должны быть заполнены Backend SSH target и Runtime directory этого VPS. Все три адреса образов задаются в UI; их не нужно повторно вписывать в JSON.
Для двух VPS используйте preset Separate frontend / backend, заполните оба SSH target и подготовьте одинаковый Runtime directory на обеих машинах. DNS admin направьте на frontend, API — на backend. Дальнейшие команды не меняются.
4. Разрешите Mac и VPS скачивать образы
На Mac войдите в registry. Для Docker Hub:
docker login docker.io --username YOUR_DOCKERHUB_LOGIN
Замените YOUR_DOCKERHUB_LOGIN логином своего пользователя Docker Hub. Если репозитории принадлежат организации, её namespace в адресах образов может отличаться от этого логина. В запрос пароля вставьте токен с правом отправки образов. Для другого registry меняются хост и логин.
Для приватных образов подготовьте на Mac файл доступа VPS вне Git:
mkdir -p "$HOME/.config/admingen/production"
chmod 700 "$HOME/.config/admingen/production"
umask 077
export DEPLOY_SECRETS_FILE="$HOME/.config/admingen/production/secrets.json"
nano "$DEPLOY_SECRETS_FILE"
Введите JSON, заменив оба примера реальными значениями:
{
"registry_username": "YOUR_REGISTRY_USER",
"registry_password": "YOUR_REGISTRY_READ_TOKEN"
}
registry_username — имя владельца токена по правилам вашего registry, registry_password — токен чтения. Сохраните файл и выполните:
chmod 600 "$DEPLOY_SECRETS_FILE"
Provision передаст эти данные серверу. Для публичных образов без требования авторизации файл серверных секретов не нужен. В обоих случаях PostgreSQL и ключи аутентификации создаются автоматически.
5. Выполните первый запуск
На Mac, из корня example-project, с работающим Docker Desktop и чистыми исходниками Git. В новом терминале экспортируйте пути:
export DEPLOY_SSH_KEY_FILE="$HOME/.config/admingen/production/id_ed25519"
export DEPLOY_KNOWN_HOSTS_FILE="$HOME/.config/admingen/production/known_hosts"
Если подготовили файл для приватного registry, в этом же терминале также экспортируйте DEPLOY_SECRETS_FILE из предыдущего шага.
bash ./deploy/control build --env production --output release-001.json
bash ./deploy/control provision --env production --release release-001.json --confirm production
bash ./deploy/control deploy --env production --release release-001.json --confirm production
bash ./deploy/control status --env production --json
Выполняйте команды по одной и переходите дальше только после успеха. Build собирает версию; provision проверяет окружение и готовит секреты, PostgreSQL и HTTPS; deploy применяет миграции и запускает приложение. После provision приложение ещё может показывать страницу обслуживания. Успешный deploy заканчивается status=complete; status должен показывать записанный текущий релиз, а проверка готовности — успешное состояние.
Build отправляет три образа в registry и записывает в JSON их точные идентификаторы. VPS скачивает эти версии; исходники там не собираются. Сохраняйте образы нужных релизов в registry: одного JSON для их восстановления недостаточно.
Откройте отдельный терминал backend-VPS через подготовленный SSH:
ssh -i "$DEPLOY_SSH_KEY_FILE" -o IdentitiesOnly=yes \
-o "UserKnownHostsFile=$DEPLOY_KNOWN_HOSTS_FILE" deploy@203.0.113.10
Создайте первого администратора
Для нового проекта без данных выполните на VPS под deploy или root:
docker ps --filter label=com.docker.compose.service=backend
Возьмите имя из столбца NAMES и замените им ИМЯ_BACKEND_КОНТЕЙНЕРА:
docker exec -it ИМЯ_BACKEND_КОНТЕЙНЕРА \
admin bootstrap-superadmin --if-needed --login owner
Введите и подтвердите пароль длиной 12–128 байт UTF-8; ввод скрыт. Откройте https://admin.example.com со своим доменом и войдите как owner. Если суперадминистратор уже существует, эта команда не заменяет его и не сбрасывает пароль.
Если переносите заполненную БД из разработки, после успешного первого deploy перейдите к переносу данных в Docker-окружение. Импорт заменит новую БД, включая созданный аккаунт; после него используйте аккаунты из перенесённой базы.
Обновите приложение
Снова на Mac, из корня example-project: подготовьте и закоммитьте код. Если берёте изменения из удалённого репозитория, выполните git pull --ff-only. Убедитесь, что Docker login ещё действует, а в терминале заданы два SSH-пути. Затем:
bash ./deploy/control build --env production --output release-002.json
bash ./deploy/control deploy --env production --release release-002.json --confirm production
bash ./deploy/control status --env production --json
Для каждого выпуска используйте новое имя JSON. Provision не повторяется; обычный deploy использует сохранённые серверные доступы. Успех — status=complete и новый текущий релиз. Если серверный токен истёк, обновите его через ротацию секретов.
В этом варианте backup отключён. Резервные копии, S3-медиа и CI можно настроить отдельно.
Если выпуск остановился
В том же месте, где запускали control:
bash ./deploy/control status --env production --json
bash ./deploy/control logs --env production --service backend
Сохраните сообщение об ошибке и operation ID. Продолжение — в восстановлении операции. Не удаляйте каталог данных или state для повторной попытки. Ошибка первого deploy после миграций также требует разбора операции, даже если текущий релиз ещё не записан.