Перейти к содержанию

Production-настройка

Чек-лист доработок над платформой, развёрнутой по Быстрому старту, перед её передачей в промышленную эксплуатацию. Большинство пунктов чек-листа сводятся к проверке: «выполнена ли соответствующая отдельная статья раздела». Сама эта статья — итоговый сборник, по которому удобно идти подряд при приёмке стенда.

1. Профиль backend

В .env блока backend переключить профиль Spring на prod:

SPRING_PROFILES_ACTIVE=prod

В профиле prod отключены Swagger UI и Swagger API spec, jpa-debug и развёрнутые логи. После правки перезапустить контейнер:

cd /etc/datahub/backend
sudo docker compose up -d --force-recreate

Подробности — в Сервер DataHUB / Профили.

2. TLS-сертификаты от доверенного CA

Self-signed-сертификаты, выпущенные на пилотном стенде, не подходят для production:

  • получить TLS-сертификаты от доверенного CA или выпустить через Let's Encrypt;
  • заменить файлы в /etc/datahub/nginx/certs/, проверить права (0644 для .crt, 0640 для .key, владелец — root);
  • настроить автоматическое обновление (cron-задача для Let's Encrypt);
  • перезагрузить nginx: sudo docker exec nginx nginx -s reload.

Подробности — в Настройке безопасности / TLS-сертификаты.

3. Уникальные секреты стенда

Все ключевые секреты должны быть выпущены отдельно для production-стенда — не переноситься с пилота:

  • POSTGRES_PASSWORD — выпустить новый, обновить согласованно в /etc/datahub/postgres/.env, /etc/datahub/backend/.env, /etc/datahub/flyway/.env. Подробности про смену пароля живой БД — в PostgreSQL / Конфигурация.
  • RABBITMQ_DEFAULT_PASS — то же для RabbitMQ.
  • Пароль администратора pgAdmin (/etc/datahub/pg-agmin/.env).
  • DATAHUB_ADMIN_PASSWORD (/etc/datahub/backend/.env).
  • AUTH_SECRET (/etc/datahub/frontend/.env).

Перевыпустить секреты Сервера DataHUB (pepper, JWT-ключи, service token) — они должны быть уникальными для каждого стенда:

cd /etc/datahub/backend/scripts
sudo ./generate_pepper.sh
sudo ./generate_keys.sh
sudo ./generate_service_token.sh

После — перезапустить backend. Подробности — в Сервер DataHUB / Секреты и Настройке безопасности / Секреты.

Генерация пароля:

head -c 32 /dev/urandom | base64

4. Парольная политика и rate-limiting

Проверить и при необходимости скорректировать параметры в .env блока backend под регламент заказчика:

  • PASSWORD_POLICY_HISTORY_SIZE (по умолчанию 24);
  • PASSWORD_POLICY_VALIDITY_DAYS (60);
  • RATE_LIMIT_LOGIN_ATTEMPTS (5);
  • RATE_LIMIT_LOGIN_LOCK_TIME (30 мин);
  • API_RATE_LIMIT_REQUESTS_CAPACITY (200/мин);
  • API_AUTH_RATE_LIMIT_REQUESTS_CAPACITY (20/мин).

Согласовать парольную политику с frontend (PASSWORD_MIN_LENGHT и другие в /etc/datahub/frontend/.env). Подробности — в Настройке безопасности / Парольная политика.

5. CORS

В .env блока backend указать публичный URL личного кабинета:

DATAHUB_PUBLIC_URL=https://lk.<your-domain>

Backend разрешит CORS только для запросов с этого origin'а. После правки — рестарт backend.

6. Email и (опционально) SMS

Заполнить параметры SMTP в .env блока backend. Без рабочей почты не будут работать: подтверждение регистрации, сброс пароля, смена email.

Проверка отправки — выполнить регистрацию тестового пользователя через UI.

Подробности — в Настройке уведомлений.

7. Ограничение доступа к административным портам

Порты 15432 (pgAdmin) и 15672 (RabbitMQ Management) опубликованы наружу. На production к ним должен иметь доступ только администратор — через ufw/iptables или удалив проброс портов в docker-compose.yml блока nginx.

Подробности — в Настройке безопасности / Firewall.

8. Ротация и сбор логов

Настроить logrotate для /etc/datahub/nginx/log/:

sudo tee /etc/logrotate.d/datahub-nginx >/dev/null <<'EOF'
/etc/datahub/nginx/log/*.log {
    daily
    rotate 30
    compress
    missingok
    notifempty
    sharedscripts
    postrotate
        docker exec nginx nginx -s reopen
    endscript
}
EOF

Если в инфраструктуре заказчика есть централизованный сбор логов — настроить отправку из /etc/datahub/nginx/log/ и docker logs штатными агентами. Подробности — в Мониторинг и логи.

9. Резервное копирование

Настроить регулярные бэкапы:

  • ежедневный pg_dump PostgreSQL с ротацией 30 дней;
  • еженедельный экспорт definitions RabbitMQ;
  • еженедельный архив /etc/datahub/.

Полная процедура — в Резервное копирование. Без рабочего бэкапа production-стенд считать неготовым.

Обязательно провести тестовое восстановление на отдельном стенде до открытия доступа.

10. Мониторинг

Настроить мониторинг минимум по следующим точкам:

  • healthcheck-эндпоинты (https://lk.<your-domain>/healthz, /api/actuator/health);
  • статус контейнеров (docker ps → все (healthy));
  • дисковое пространство (/etc/datahub/postgres/data, /etc/datahub/rabbitmq/data);
  • срок действия TLS-сертификатов (алерт за 30 дней);
  • длина очередей RabbitMQ (рост = отставание потребителя).

Подробный набор алертов — в Мониторинг и логи.

11. Тонкая настройка PostgreSQL

Базовые параметры postgresql.conf подходят для типовой нагрузки. Для крупных стендов имеет смысл настроить под фактический объём оперативной памяти и характер нагрузки:

  • shared_buffers ≈ 25% от RAM, выделенной контейнеру postgres;
  • effective_cache_size ≈ 50–75% от RAM;
  • work_mem, maintenance_work_mem — под нагрузку отчётов и vacuum;
  • max_connections — согласовать с суммарным maximum-pool-size всех экземпляров backend.

Точные значения уточняются с вендором по результатам нагрузочного тестирования. См. Архитектура / Масштабирование.

12. Инфраструктурные требования

  • Бесперебойное питание / UPS или гарантированный SLA по электропитанию ДЦ.
  • Автозапуск Docker daemon при старте сервера (systemctl enable docker).
  • Корректное время и синхронизация NTP — критично для JWT-токенов и логов с временными метками.

Финальный чек-лист готовности

  • [ ] SPRING_PROFILES_ACTIVE=prod в /etc/datahub/backend/.env.
  • [ ] TLS-сертификаты от доверенного CA, автоматическое обновление работает.
  • [ ] Все пароли уникальны для стенда и сгенерированы криптостойко.
  • [ ] Секреты Сервера DataHUB перевыпущены (pepper, JWT, service token).
  • [ ] CORS настроен на фактический домен.
  • [ ] Email (и при необходимости SMS) работает — проверено отправкой тестовому пользователю.
  • [ ] Доступ к административным портам (15432, 15672) ограничен на firewall или не публикуется.
  • [ ] Настроены ротация nginx-логов и (опционально) централизованный сбор.
  • [ ] Настроены и проверены резервные копии: восстановление PostgreSQL отработано на тестовом окружении.
  • [ ] Мониторинг healthcheck'ов, диска, сертификатов, очередей работает.
  • [ ] Платформа запущена под бесперебойным питанием / UPS, обеспечен автозапуск Docker daemon, NTP синхронизация.

Что дальше