Від Git-репозиторію до production: посібник із деплою в Dockup

Переміщення Git-репозиторію в production — це більше, ніж підключення remote та натискання кнопки деплою. Платформа має знати цільовий сервіс, branch, спосіб збірки, start command, порт, на якому прослуховуються запити, оточення, health gate і шлях відновлення. Dockup робить ці рішення явними, підтримуючи як автоматичні збірки Nixpacks, так і Dockerfile, що зберігаються в репозиторії.

Цей посібник починається з репозиторію, який ще ніколи не деплоїли, і завершується перевіреною URL-адресою, історією деплоїв, логами та протестованою командою rollback.

Що потрібно перевірити перед першим production-деплоєм?

Переконайтеся, що репозиторій можна деплоїти без недокументованого локального стану. Чистий clone має містити все необхідне для встановлення залежностей і запуску застосунку, крім секретів.

Скористайтеся цим checklist:

Перевірка	Очікуваний результат
Default branch	Існує потрібна production-гілка
Dependency lockfile	Закомічений для відтворюваного встановлення залежностей
Start process	Прослуховує налаштований порт і 0.0.0.0
Health route	Повертає успішний результат без зовнішніх побічних ефектів
Database migrations	Мають чіткий безпечний план виконання
Secrets	Зберігаються поза Git
Persistent files	Використовують volume, а не файлову систему контейнера
Rollback	Попередній деплой можна повторно запустити

Встановіть 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 уже існує, продовжуйте, переглянувши його статус та історію деплоїв. Це допоможе не перетворити невизначений результат мережевого запиту на дубльований сервіс. Облікові дані для доступу до репозиторію зберігайте поза системою контролю версій і виводом команд.

Як Dockup обирає Nixpacks або Dockerfile?

Якщо в репозиторії є Dockerfile, Dockup використовує його. Якщо Dockerfile немає, Nixpacks автоматично визначає тип застосунку та збирає його. Завдяки такому порядку явне визначення контейнера в репозиторії має найвищий пріоритет.

Nixpacks — хороший перший вибір, якщо застосунок дотримується поширених conventions екосистеми й не потребує налаштування на рівні операційної системи. Dockerfile стане у пригоді, коли потрібні конкретний base image, системні пакети, multi-stage build, власний runtime user або точні межі копіювання файлів.

Не потрібно додавати порожній Dockerfile лише для того, щоб «мати production-ready вигляд». Некоректний Dockerfile може бути менш відтворюваним, ніж стандартна автоматична збірка. Скористайтеся алгоритмом вибору в матеріалі Nixpacks vs Dockerfile.

Перевірте сервіс після створення:

dockup info production/api --json

У відповіді містяться URL репозиторію, branch, тип деплою, порт, налаштування build і start, ключі environment, custom domains та дані про останній деплой.

Якщо визначені команди потребують перевизначення, скористайтеся задокументованими налаштуваннями:

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

Налаштування застосовуються під час наступного деплою.

Як налаштувати production-оточення та health?

Додавайте звичайні значення й секрети окремо:

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

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

Значення секретів маскуються під час перегляду списку environment. Їх можна встановити або замінити, але збережене значення не повертається.

Зміни environment потребують повторного деплою, оскільки запущений процес не може отримати нове оточення заднім числом. Повний життєвий цикл описано в матеріалі про environment variables and secrets.

Налаштуйте 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 має перевіряти, чи готовий процес застосунку обробляти запити. Не варто виконувати в ньому деструктивні перевірки або дорогі тести всієї системи. Глибокі перевірки залежностей можуть створювати хибні outages, якщо необов’язковий сервіс працює нестабільно.

Як виконати деплой, стежити за ним і перевірити production?

Запустіть release і дочекайтеся terminal state:

dockup deploy production/api --wait --json

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

Щоб переглядати збірку у форматі NDJSON:

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

Потік завершується після успішного завершення або помилки. Якщо збірка успішна, але контейнер аварійно завершує роботу, перегляньте runtime logs:

dockup logs production/api --json

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

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

Uptime probes запускаються щохвилини та повідомляють середній час відповіді й p95. Сканування безпеки перевіряє CVE образу та конфігурацію. Додайте smoke test, специфічний для застосунку, для фактичного business endpoint; готовність платформи необхідна, але недостатня.

Докладний підхід до роботи з логами описано в матеріалі build and runtime log debugging.

Як додати automatic deploys і previews?

Перший production release варто виконати вручну, щоб спостерігати за кожною межею процесу. Коли build, health gate і шлях rollback перевірено, увімкніть деплой після push:

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

Automatic deployment має працювати із protected branch і дотриманням code-review policy. Push — це production trigger, тому дозволи репозиторію стають дозволами інфраструктури.

Previews для pull request і branch надають ізольовані URL та оточення:

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

У проєкті з private networking previews підключаються до мережі проєкту. Вони можуть звертатися до тієї самої production database за адресою <slug>.internal, але Dockup автоматично створює для preview read-only database user. Preview може переглядати дані, подібні до production, не змінюючи їх.

Це не скасовує зобов’язань щодо приватності. Доступ до preview також потрібно обмежувати й аудіювати, а використовувати його слід лише там, де дозволено читати production-дані.

Як виконати rollback невдалого деплою?

Перед відновленням збережіть докази. Для помилки збірки перегляньте build logs, а для crash — runtime logs. Потім виведіть історію деплоїв:

dockup deployments production/api -n 20 --json

Виберіть deployment ID, статус і час якого відомі, а потім повторно запустіть його:

dockup rollback <deploymentId> production/api --json

Rollback має бути явною дією під час incident. Запишіть ID невдалого деплою, вибраний ID для відновлення, причину та подальше виправлення. Якщо database migration не має зворотної сумісності, одного rollback застосунку може бути недостатньо для відновлення сумісності; проєктування міграцій має бути частиною release plan.

Посібник із zero-downtime deployment пояснює перемикання трафіку, а Dockup CLI reference документує всі flags команд.

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

Наприкінці процесу переходу від Git-репозиторію до production зафіксуйте:

• Точний target project/service.
• Репозиторій і production branch.
• Метод збірки: Nixpacks або Dockerfile.
• Build і start commands, якщо їх перевизначали.
• Порт, на якому прослуховуються запити, і health path.
• Deployment ID та terminal status.
• Production URL і план щодо custom domain.
• Результати перевірок uptime та security.
• Deployment ID для rollback або правило його вибору.

Цей запис перетворює другий деплой на звичайну операцію, а не на ще одну дослідницьку процедуру.

Відокремлюйте стан застосунку від образу контейнера

До writable filesystem усередині контейнера сервісу слід ставитися як до ресурсу, який можна замінити. Новий деплой створює нову версію, а rollback повторно запускає старий образ; файли, записані лише всередині старого контейнера, не є надійною стратегією зберігання даних.

Для реляційних даних, документів або cache state використовуйте managed databases, а для файлів, які мають зберігатися між деплоями, підключайте volume. Перед першим production release перевірте шляхи монтування. Директорія для upload у контейнері, яку не змонтували, може здаватися справною, доки наступний деплой не видалить дані.

Перш ніж переносити файли, створені користувачами, перегляньте матеріал про persistent volumes and snapshots. Для database state використовуйте спеціалізовану систему backup бази даних, а не вважайте snapshot активного volume backup-копією, узгодженою з транзакціями.

Оцініть перший місяць, не вигадуючи фіксований рахунок за instance

Dockup вимірює споживання CPU, RAM і disk щохвилини та віднімає використання з балансу плану. Free plan містить стартовий кредит $10 і дозволяє до трьох деплоїв; рекомендований Pro plan коштує $20 на місяць і включає $20 кредиту на використання.

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

Перевірте чистий другий деплой

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

Тримайте target явним

Запишіть фінальний рядок project/service.

Збережіть URL release

Запишіть production URL поруч із deployment ID.

Підтвердьте наступний trigger

Зазначте, чи майбутні release будуть ручними, чи використовуватимуть optional deploy-on-push. Це допоможе зберегти узгодженість між дозволами репозиторію, branch protection та production-очікуваннями після першого деплою.

Почніть із деплою, який можна перевірити

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

Почніть безкоштовно на app.dockup.ai. Free plan коштує $0 на місяць, містить стартовий кредит $10 і підтримує один workspace, три databases та три deployments.

FAQ

Чи може Dockup деплоїти репозиторій без Dockerfile?

Так. Якщо Dockerfile відсутній, Dockup використовує Nixpacks для автоматичного визначення та збірки застосунку.

Що робить dockup create --link?

Команда записує link .dockup у поточний каталог, щоб наступні команди могли визначати пов’язаний target проєкту/сервісу.

Чому для першого деплою слід використовувати --wait?

Це залишає команду підключеною, доки деплой не завершиться успішно, з помилкою або timeout, і повертає код завершення, який точно відображає terminal result.

Чи застосовуються зміни environment variables негайно?

Ні. Вони застосовуються до нового контейнера під час наступного деплою, тому після зміни конфігурації environment потрібно повторно деплоїти сервіс.

Як Dockup виконує rollback застосунку?

Виведіть історію деплоїв, визначте відомий попередній deployment ID і використайте dockup rollback із цим ID та точним target сервісу.