Как организовать конфигурацию приложения, если путь деплоя неизвестен заранее?

Проблема неизвестного пути деплоя типична для современных облачных и контейнерных сред, где приложение может быть развёрнуто на разных доменах или в разных кластерах. Жёстко прописанные URL или пути в коде делают приложение нефлексибельным и небезопасным. Решение заключается в отделении конфигурации от кода и использовании среды выполнения для её определения.

Ключевые принципы

• Переменные окружения (Environment Variables): Самый распространённый и простой способ. Параметры вроде API_BASE_URL, DATABASE_URL задаются в операционной системе или контейнере. Приложение читает их при запуске.
• Файлы конфигурации, зависящие от среды: Можно иметь несколько файлов (например, config.development.json, config.production.json) и выбирать нужный на основе переменной окружения NODE_ENV.
• Внешние конфигурационные сервисы: Для сложных распределённых систем настройки могут храниться в специализированных сервисах (HashiCorp Consul, AWS Parameter Store, Kubernetes ConfigMaps/Secrets), откуда приложение их запрашивает.

Практический пример на Node.js

Рассмотрим простой подход с переменными окружения и файлом-заглушкой.

// config.js
const path = require('path');

// Чтение переменных окружения с fallback-значениями для разработки
const config = {
  // Базовый URL API. Если не задан, используется локальный для разработки.
  apiBaseUrl: process.env.API_BASE_URL || 'http://localhost:3000/api',
  // Путь для статических ассетов. Может быть абсолютным URL на продакшене.
  publicPath: process.env.PUBLIC_PATH || '/',
  // Режим работы приложения
  nodeEnv: process.env.NODE_ENV || 'development',
  // Секретные ключи ДОЛЖНЫ задаваться только через окружение
  secretKey: process.env.SECRET_KEY,
};

// Валидация критичных параметров
if (!config.secretKey && config.nodeEnv === 'production') {
  throw new Error('SECRET_KEY must be set in production environment!');
}

module.exports = config;

В коде приложения вы просто импортируете этот объект config. На сервере, перед запуском приложения, вы устанавливаете необходимые переменные. В Docker это делается через docker run -e API_BASE_URL=... или в Dockerfile. В Kubernetes — через ConfigMap и Secrets.

Где и как применяется

Такой подход является стандартом для 12-Factor App и широко используется в микросервисных архитектурах, контейнеризации (Docker) и оркестрации (Kubernetes). Он позволяет:

• Использовать один и тот же образ Docker для всех сред.
• Безопасно хранить секреты (пароли, токены) вне репозитория.
• Легко масштабировать и изменять настройки без пересборки приложения.

Вывод: Используйте переменные окружения как основной механизм для параметров, зависящих от пути деплоя и среды. Это делает приложение переносимым, безопасным и готовым к работе в современных CI/CD-пайплайнах и облачных провайдерах.