Деплой на prod

Деплой в production -- это двухэтапный процесс: мерж в main, затем ручной запуск задачи деплоя в GitLab CI. Этот намеренный шлюз предотвращает случайные релизы.

Параметр	Значение
Ветка	main
Триггер	Ручной (GitLab CI UI)
Домен	*.amzhub.ai
Цель Nomad	Prod-кластер / namespace

DANGER

Мерж в main НЕ запускает автоматический деплой в production. Вы должны вручную запустить задачу деплоя в пайплайне GitLab CI.

Чек-лист перед деплоем

Выполните эти проверки перед запуском деплоя в production:

• [ ] Изменения проверены на stage и работают корректно
• [ ] Эндпоинт health на stage возвращает 200 OK
• [ ] Нет открытых инцидентов или текущих окон обслуживания
• [ ] Команда уведомлена о предстоящем деплое
• [ ] Миграции базы данных (если есть) проверены и протестированы
• [ ] План отката понятен (см. Откат ниже)
• [ ] Деплой выполняется в рабочее время (избегайте деплоев в пятницу вечером)

WARNING

Если любой пункт этого чек-листа не подтвержден, отложите деплой.

Шаги деплоя

1. Смержите stage в main

git checkout main
git pull origin main
git merge stage
git push origin main

Или создайте merge request в GitLab из stage в main.

Это запустит CI-пайплайн, но задача деплоя будет приостановлена в ожидании ручного подтверждения.

2. Запустите деплой в интерфейсе GitLab

1. Перейдите в ваш проект в GitLab.
2. Откройте раздел CI/CD > Pipelines.
3. Найдите пайплайн для вашего merge-коммита в main.
4. Этап деплоя покажет кнопку запуска (ручная задача).
5. Нажмите кнопку запуска, чтобы начать деплой.

TIP

Ручную задачу можно также запустить из командной строки, если установлен GitLab CLI:

glab ci run --job deploy-prod

3. CI деплоит в Nomad

После запуска задача деплоя:

1. Обращается к Nomad API напрямую с раннера.
2. Отправляет задачу в namespace prod с -var-file=nomad/vars-prod.hcl.
3. Nomad размещает аллокацию на прод-ноде — по constraint с meta.env.
4. Нода тянет образ :prod, поднимает канареечную копию и переключает трафик только после успешных health-чеков. Если они не прошли — auto_revert возвращает прошлую версию.

4. Проверка после деплоя

Сразу после завершения деплоя:

# Проверка health-эндпоинта production
curl -s https://amzhub.ai/health | jq .

# Проверка задеплоенной версии/коммита
curl -s https://amzhub.ai/health | jq '.version'

# Проверка статуса задачи Nomad на prod-хосте
nomad job status my-service

# Просмотр логов в первые несколько минут
nomad alloc logs -f <alloc-id>

Мониторьте как минимум 10 минут после деплоя:

• [ ] Эндпоинт health возвращает 200 OK
• [ ] Нет всплеска количества ошибок
• [ ] Время ответа в норме
• [ ] Нет неожиданных перезапусков в Nomad

Откат

Если что-то пошло не так после деплоя в production, можно откатиться, перезапустив задачу деплоя из предыдущего успешного пайплайна.

Шаги отката

1. Перейдите в CI/CD > Pipelines в GitLab.
2. Найдите предыдущий успешный пайплайн в ветке main (тот, что был до текущего деплоя).
3. Откройте этот пайплайн.
4. Найдите задачу деплоя и нажмите Retry.
5. Это повторно задеплоит предыдущий образ в Nomad, фактически выполнив откат.

# Альтернативно, если у вас есть job-файл предыдущей версии:
nomad job run previous-version.nomad

DANGER

НЕ пытайтесь откатиться через revert Git-коммита и повторный деплой. Это создает ненужную сложность при мерже. Всегда используйте метод повторного запуска пайплайна.

Проверка после отката

После отката выполните те же шаги проверки, что и после деплоя:

curl -s https://amzhub.ai/health | jq .
nomad job status my-service

Убедитесь, что сервис работает корректно, прежде чем расследовать причину неудачного деплоя.

Лучшие практики деплоя в prod

Практика	Причина
Деплоить в рабочее время	Команда доступна для реагирования на проблемы
Избегать пятниц и предпраздничных дней	Снижает риск инцидентов на выходных
Один деплой за раз	Проще изолировать проблемы
Мониторить после деплоя	Обнаруживать проблемы на ранней стадии
Сообщать в канал команды	Все в курсе происходящего

TIP

Относитесь к каждому деплою в production как к командному событию, а не индивидуальной активности. Объявляйте, мониторьте, подтверждайте.