Skip to content

Окружения

Инфраструктура использует три окружения. Каждое соответствует ветке Git, набору доменов и стратегии развёртывания.

Матрица окружений

ОкружениеВеткаШаблон доменаРазвёртываниеДатацентр Nomad
devdevelop*.meduza.dev.internalАвтоматически при pushdc1-dev
stagestaging*.meduza.stage.internalАвтоматически при pushdc1-stage
prodmain*.meduza.comРучное подтверждениеdc1-prod

TIP

Dev и stage развёртываются автоматически при обновлении соответствующих веток. Для prod требуется ручной запуск в пайплайне GitLab CI.

Настройка локальной разработки

1. Клонирование репозитория

bash
git clone git@gitlab.amzgit.com:meduza/platform_hub.git
cd platform_hub

2. Установка зависимостей

bash
# Backend (Fastify)
cd backend
npm install

# Frontend (Vue 3)
cd ../frontend
npm install

3. Настройка локального окружения

Скопируйте пример файла окружения и заполните локальные значения:

bash
cp .env.example .env

Файл .env используется только для локальной разработки. В развёрнутых окружениях конфигурация внедряется из Consul KV.

4. Запуск сервисов

bash
# Terminal 1 -- Backend
cd backend
npm run dev
# Fastify starts on http://localhost:3000

# Terminal 2 -- Frontend
cd frontend
npm run dev
# Vite dev server starts on http://localhost:5173

WARNING

Dev-сервер фронтенда проксирует запросы /api/* на localhost:3000 через конфигурацию Vite. Убедитесь, что бэкенд запущен, прежде чем тестировать API-вызовы из интерфейса.

5. Запуск тестов

bash
# Backend tests
cd backend
npm run test

# Frontend tests
cd frontend
npm run test

Переменные окружения и секреты

В развёрнутых окружениях вся конфигурация хранится в Consul KV и внедряется в контейнеры через станзу template Nomad. Никакие секреты не встраиваются в Docker-образы.

Структура Consul KV

meduza/
├── platform_hub/
│   ├── dev/
│   │   ├── DATABASE_URL
│   │   ├── REDIS_URL
│   │   ├── API_SECRET
│   │   └── ...
│   ├── stage/
│   │   └── ...
│   └── prod/
│       └── ...

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

Пример шаблона Nomad

В спецификации задания Nomad станза template извлекает значения из Consul KV:

hcl
template {
  data = <<-EOF
    {{ range ls "meduza/platform_hub/dev" }}
    {{ .Key }}={{ .Value }}
    {{ end }}
  EOF
  destination = "secrets/env.vars"
  env         = true
}

Управление секретами

Для чтения или записи значений в Consul KV:

bash
# Read a value
consul kv get meduza/platform_hub/dev/DATABASE_URL

# Write a value
consul kv put meduza/platform_hub/dev/DATABASE_URL "postgresql://user:pass@db:5432/meduza_dev"

DANGER

Никогда не коммитьте секреты в Git. Все конфиденциальные значения должны передаваться через Consul KV. Если секрет был случайно закоммичен, немедленно выполните его ротацию и принудительно отправьте очищенную историю.

Доступ к каждому окружению

Dev

  • URL: https://app.meduza.dev.internal
  • API: https://api.meduza.dev.internal/api/
  • Доступ: Доступен во внутренней сети или через VPN.
  • Nomad UI: https://nomad.dev.internal:4646

Stage

  • URL: https://app.meduza.stage.internal
  • API: https://api.meduza.stage.internal/api/
  • Доступ: Доступен во внутренней сети или через VPN. Используется для QA и предрелизной валидации.
  • Nomad UI: https://nomad.stage.internal:4646

Prod

  • URL: https://app.meduza.com
  • API: https://api.meduza.com/api/
  • Доступ: Публичный. Развёртывание требует ручного подтверждения пайплайна в GitLab.
  • Nomad UI: https://nomad.prod.internal:4646 (только внутренний доступ)

Проверка статуса развёртывания

Используйте Nomad CLI для проверки статуса работающего задания в любом окружении:

bash
# Point to the right cluster
export NOMAD_ADDR=https://nomad.dev.internal:4646

# Check job status
nomad job status platform_hub

# View recent allocations
nomad job allocs platform_hub

Рабочий процесс продвижения

Код проходит через окружения по порядку:

develop → staging → main
   ↓         ↓        ↓
  dev      stage     prod
  1. Влейте функциональные ветки в develop. CI собирает и развёртывает в dev автоматически.
  2. Когда dev проверен, влейте develop в staging. CI развёртывает в stage автоматически.
  3. После одобрения QA на stage влейте staging в main. CI собирает образ, но ожидает ручного подтверждения перед развёртыванием в prod.

TIP

Вы можете отслеживать прогресс пайплайна в GitLab по адресу gitlab.amzgit.com/meduza/platform_hub/-/pipelines.

Документация по инфраструктуре