Обзор деплоя

Наша модель деплоя следует стратегии продвижения по веткам: каждая долгоживущая ветка Git напрямую соответствует окружению. GitLab CI обеспечивает сборку и деплой автоматически (или вручную, в случае продакшна), а HashiCorp Nomad оркестрирует работающие сервисы на отдельной виртуальной машине для каждого окружения.

Соответствие веток и окружений

Ветка	Окружение	Шаблон домена	Триггер
dev	Development	dev-*.amzhub.ai	Автоматический
stage	Staging	stage-*.amzhub.ai	Автоматический
main	Production	*.amzhub.ai	Ручной

Примеры доменов

Окружение	Домен приложения	Домен документации
Dev	dev.amzhub.ai	docs-dev.amztop.io
Stage	stage.amzhub.ai	docs-stage.amztop.io
Prod	amzhub.ai	docs.amztop.io

Процесс деплоя

flowchart LR
    A[Feature Branch] -->|merge| B[dev]
    B -->|auto deploy| C[Dev Environment]
    B -->|merge| D[stage]
    D -->|auto deploy| E[Stage Environment]
    D -->|merge| F[main]
    F -->|manual trigger| G[Production]

    style C fill:#4ade80,color:#000
    style E fill:#facc15,color:#000
    style G fill:#f87171,color:#000

Ключевые концепции

Общие шаблоны GitLab CI

Все проекты используют общие CI-шаблоны, определяющие стандартные этапы сборки и деплоя. Эти шаблоны обеспечивают единообразие между сервисами и сводят конфигурацию отдельных проектов к минимуму. Типичные этапы пайплайна:

1. Build — собирает контейнерный образ и отправляет его в registry.amztop.io.
2. Deploy — обращается к Nomad API напрямую с раннера и запускает джобу в namespace своего окружения.

Один кластер, три namespace

Кластер Nomad общий, окружения разделены на уровне namespace: dev, stage, prod. Каждый namespace приколочен к своей виртуальной машине — джоба содержит constraint по атрибуту meta.env, поэтому dev-задача не уедет на прод-ноду.

Окружение	Namespace	Нода
Development	dev	192.168.100.20
Staging	stage	192.168.100.30
Production	prod	192.168.100.40

Модель продвижения

Код движется в одном направлении через окружения:

feature branch --> dev --> stage --> main (prod)

TIP

Никогда не мержьте напрямую в main, минуя stage. Путь продвижения существует для того, чтобы выявлять проблемы до их попадания в продакшн.

WARNING

Деплой в продакшн требует ручного запуска в пайплайне GitLab CI. Одного мержа в main недостаточно для деплоя.

Далее

• Деплой на dev — быстрая итерация в процессе разработки
• Деплой на stage — предпродакшн-валидация
• Деплой на prod — процесс релиза в продакшн
• Решение проблем — типичные проблемы и отладка