От Git-репозитория до production: руководство по деплою в Dockup

Перенос Git-репозитория в production — это не просто подключение remote и нажатие кнопки deploy. Платформа должна знать, какой сервис использовать, какую ветку и способ сборки выбрать, какую команду запуска выполнить, на каком порту слушать, какое окружение настроить, как проверять готовность и каким образом восстанавливаться после сбоя. Dockup делает эти решения явными и поддерживает как автоматическую сборку через Nixpacks, так и Dockerfile, который хранится в репозитории.

В этом руководстве мы начнём с репозитория, который ещё ни разу не деплоился, а закончим проверенным URL, историей деплоев, логами и протестированной командой отката.

Что нужно проверить перед первым production-деплоем?

Убедитесь, что репозиторий можно задеплоить без недокументированного локального состояния. Чистый clone должен содержать всё необходимое для установки зависимостей и запуска приложения, за исключением секретов.

Используйте этот чеклист:

Проверка	Ожидаемый результат
Ветка по умолчанию	Нужная production-ветка существует
Lock-файл зависимостей	Закоммичен для воспроизводимой установки
Процесс запуска	Слушает настроенный порт и 0.0.0.0
Health route	Возвращает успешный результат без побочных эффектов
Миграции базы данных	Для них предусмотрен явный безопасный план выполнения
Секреты	Хранятся вне Git
Постоянные файлы	Используют volume, а не файловую систему контейнера
Откат	Предыдущий деплой можно запустить повторно

Установите CLI и выполните аутентификацию:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Перед созданием нового сервиса выведите список существующих:

dockup services --json

Это поможет избежать создания дубликатов и подтвердить точное соглашение об именах workspace и target.

Как Dockup create поддерживает деплой из Git?

Обычно команда для первого деплоя создаёт сервис, выполняет его деплой, дожидается результата и связывает его с текущей директорией:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

В результате target будет иметь вид production/api. Ссылка .dockup позволяет последующим командам находить этот сервис при запуске из репозитория, однако в production-документации всё равно следует указывать полный target.

Если попытка provisioning была прервана, выведите список сервисов и проверьте точный target, прежде чем повторять создание:

dockup services --json

Если production/api уже существует, продолжите работу, просмотрев его статус и историю деплоев. Это позволит не превратить неопределённый результат сетевого запроса в дубликат сервиса. Храните credentials для доступа к репозиторию вне системы контроля версий и вывода команд.

Как Dockup выбирает Nixpacks или Dockerfile?

Если в репозитории есть Dockerfile, Dockup использует его. В противном случае Nixpacks определяет тип приложения и автоматически собирает его. Благодаря такому порядку явное описание контейнера в репозитории имеет приоритет.

Nixpacks — хороший вариант для первого деплоя, если приложение следует распространённым соглашениям своей экосистемы и не требует настройки на уровне операционной системы. Dockerfile пригодится, когда нужны конкретный base image, системные пакеты, multi-stage build, собственный runtime user или точные границы копирования файлов.

Не нужно добавлять пустой Dockerfile только ради того, чтобы «выглядеть готовым к production». Некорректный Dockerfile может быть менее воспроизводимым, чем стандартная автоматическая сборка. Используйте алгоритм выбора из статьи Nixpacks vs Dockerfile.

Проверьте сервис после создания:

dockup info production/api --json

Ответ содержит URL репозитория, ветку, тип деплоя, порт, настройки сборки и запуска, ключи окружения, custom domains и данные о последнем деплое.

Если обнаруженные команды требуют переопределения, используйте документированные настройки:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Настройки применяются при следующем деплое.

Как настроить production-окружение и проверку готовности?

Добавляйте обычные значения и секреты отдельно:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

При выводе списка окружения значения секретов маскируются. Их можно задать или заменить, но сохранённое значение не возвращается.

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

Настройте health gate, который отражает готовность приложения:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup использует blue-green flow без простоя и направляет трафик на новый деплой только после успешного прохождения проверки готовности. Если HTTP path не настроен, gate может использовать готовность TCP-порта.

Health route должен проверять, готов ли процесс приложения обрабатывать запросы. Не следует выполнять в нём разрушающие проверки или дорогие комплексные тесты всей системы. Глубокие проверки зависимостей могут создавать ложные сбои, если необязательный сервис работает нестабильно.

Как выполнить деплой, следить за ним и проверить production?

Запустите release и дождитесь конечного состояния:

dockup deploy production/api --wait --json

Таймаут по умолчанию составляет 900 секунд. Код выхода 0 означает успех. Результаты deploy_failed и deploy_timeout имеют ненулевой код выхода, поэтому shell-скрипты и CI-системы корректно останавливаются.

Чтобы наблюдать за сборкой в формате NDJSON:

dockup logs production/api --build -f --json

Поток завершается при успехе или ошибке. Если сборка завершилась успешно, но контейнер падает, проверьте runtime-логи:

dockup logs production/api --json

После успешного release проверьте состояние платформы и публичное поведение приложения:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime-пробы выполняются каждую минуту и показывают среднее время ответа и p95. Сканирование безопасности проверяет CVE в image и конфигурацию. Добавьте smoke test для конкретного приложения и нужного бизнес-эндпоинта: готовность платформы необходима, но сама по себе недостаточна.

Подробный способ работы с логами описан в статье отладка логов сборки и runtime.

Как внедрять automatic deploy и preview-окружения?

Первый production-release выполняйте вручную, чтобы успеть наблюдать за каждым этапом. Когда сборка, health gate и путь отката будут проверены, включите деплой по push:

dockup auto-deploy production/api --on --json

Automatic deployment должен работать через защищённую ветку и процесс code review. Push становится триггером production-деплоя, поэтому права доступа к репозиторию превращаются в права доступа к инфраструктуре.

Preview для pull request и веток предоставляют изолированные URL и окружения:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

В проекте с private networking preview-окружения подключаются к сети проекта. Они могут обращаться к той же production-базе данных по адресу <slug>.internal, однако Dockup автоматически создаёт для preview пользователя базы данных только для чтения. Preview может работать с данными, соответствующими production, не изменяя их.

Это не отменяет обязательств по защите персональных данных. Доступ к preview по-прежнему должен быть ограничен и проверяться, а чтение production-данных допускается только там, где это разрешено.

Как откатить неудачный деплой?

Перед восстановлением сохраните данные для анализа. При ошибке сборки изучите build-логи, а при падении приложения — runtime-логи. Затем выведите историю деплоев:

dockup deployments production/api -n 20 --json

Выберите deployment ID с известными статусом и временем, а затем запустите его повторно:

dockup rollback <deploymentId> production/api --json

Откат должен быть явным действием в рамках инцидента. Зафиксируйте ID неудачного деплоя, выбранный ID восстановления, причину и последующее исправление. Если миграция базы данных несовместима с предыдущей версией, одного отката приложения может быть недостаточно для восстановления совместимости; проектирование миграций должно быть частью плана release.

Руководство по деплою без простоя объясняет переключение трафика, а в справочнике Dockup CLI описаны все флаги команд.

Запись о завершении первого деплоя

В конце процесса переноса Git-репозитория в production зафиксируйте:

• Точный target project/service.
• Репозиторий и production-ветку.
• Способ сборки: Nixpacks или Dockerfile.
• Команды сборки и запуска, если они переопределялись.
• Порт прослушивания и health path.
• Deployment ID и конечный статус.
• Production URL и план настройки custom domain.
• Результаты проверки uptime и безопасности.
• Deployment ID для отката или правило его выбора.

Такая запись превращает второй деплой в стандартную операцию, а не в очередной этап исследования.

Отделяйте состояние приложения от container image

Записываемую файловую систему внутри контейнера сервиса следует считать заменяемой. Новый деплой создаёт новую версию, а rollback повторно запускает старый image; файлы, записанные только в старый контейнер, не являются надёжной стратегией хранения данных.

Используйте managed databases для реляционного состояния, документов или cache state, а для файлов, которые должны сохраняться между деплоями, подключайте volume. До первого production-release проверьте пути монтирования. Каталог загрузок в контейнере, который не был подключён к volume, может выглядеть исправным до следующего деплоя, после которого данные будут удалены.

Перед переносом пользовательских файлов ознакомьтесь со статьёй постоянные volumes и snapshots. Для состояния базы данных используйте специализированную систему backup, а не рассматривайте snapshot активного volume как транзакционно согласованную резервную копию.

Оцените первый месяц, не придумывая фиксированный счёт за instance

Dockup измеряет потребление CPU, RAM и диска поминутно и вычитает использованный объём из баланса плана. Free plan включает стартовый кредит $10 и до трёх деплоев; рекомендуемый Pro plan стоит $20 в месяц и включает кредит $20 на использование.

После появления реального трафика проверьте потребление CPU, RAM и диска сервисом в app.dockup.ai. Принимая решение о необходимости изменить параметры сервиса, базы данных или persistent disk, опирайтесь на фактическое потребление в минуту, а не на предполагаемый максимум.

Проверьте корректность второго деплоя

После первого release внесите небольшое безопасное изменение, прошедшее review, и выполните ещё один деплой. Это подтвердит, что ссылка на репозиторий, предположения о build cache, health gate, окружение и история деплоев работают как постоянный процесс, а не только как успешное разовое provisioning.

Всегда указывайте target явно

Зафиксируйте итоговую строку project/service.

Сохраните URL release

Запишите production URL рядом с deployment ID.

Подтвердите следующий триггер

Зафиксируйте, будут ли будущие release выполняться вручную или с использованием optional deploy-on-push. Это поможет сохранить согласованность прав доступа к репозиторию, защиты веток и ожиданий от production после первого деплоя.

Начните с проверяемого деплоя

Выберите небольшой репозиторий с понятной командой запуска и health route, а после первого успешного release задокументируйте точный target и ID для отката.

Начните бесплатно на app.dockup.ai. Free plan стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три деплоя.

FAQ

Может ли Dockup задеплоить репозиторий без Dockerfile?

Да. Если Dockerfile отсутствует, Dockup использует Nixpacks, чтобы автоматически определить тип приложения и собрать его.

Что делает dockup create --link?

Команда записывает ссылку .dockup в текущую директорию, чтобы последующие команды могли определить связанный target проекта и сервиса.

Почему для первого деплоя следует использовать --wait?

Команда остаётся подключённой до тех пор, пока деплой не завершится успехом, ошибкой или таймаутом, и возвращает код выхода, точно отражающий конечный результат.

Изменения переменных окружения применяются сразу?

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

Как Dockup откатывает приложение?

Выведите историю деплоев, определите известный ID предыдущего деплоя и используйте dockup rollback с этим ID и точным target сервиса.