Как вы управляете конфигурацией и секретами в Node?

Question

Accepted Answer

Конфигурация (URL баз данных, ключи API, порты, флаги функций) должна находиться **вне вашего кода** в переменных окружения — никогда не жёсткокодирована. Это держит секреты вне системы контроля версий и позволяет одному коду работать в dev, staging и production с разными настройками.

## Почему это важно

```js
// ❌ NEVER hardcode secrets — they end up in git history forever
const dbUrl = "postgres://admin:password123@db.example.com";

// ✅ read from the environment
const dbUrl = process.env.DATABASE_URL;
const port = process.env.PORT || 3000;
```

Это следует принципу **twelve-factor app**: строгое разделение конфигурации и кода, поэтому развёртывание в новое окружение означает изменение переменных env, а не кода.

## Локальная разработка: файлы .env

```bash
# .env — local values, GITIGNORED (never committed)
DATABASE_URL=postgres://localhost/myapp_dev
JWT_SECRET=dev-secret
PORT=3000
```

```js
// load .env into process.env (older: dotenv; newer Node: --env-file flag)
import "dotenv/config";        // or: node --env-file=.env app.js
const secret = process.env.JWT_SECRET;
```

Файл `.env` хранит локальную конфигурацию; он **должен быть в gitignore**. Добавьте в репозиторий `.env.example` (с ключами, но без реальных значений), чтобы задокументировать требуемые переменные.

## Валидируйте конфигурацию при старте

```js
import { z } from "zod";

const env = z.object({
  DATABASE_URL: z.string().url(),
  JWT_SECRET: z.string().min(16),
  PORT: z.coerce.number().default(3000),
}).parse(process.env); // ❗ fail FAST at startup if config is missing/invalid
```

Валидация переменных env при загрузке (с zod/envalid) означает, что отсутствующий или некорректный секрет сразу же вызовет краш с понятным сообщением — намного лучше, чем запутанная ошибка runtime глубоко в обработке запроса.

## Секреты в production

```text
Dev:        .env file (gitignored)
Production: injected by the platform/orchestrator —
            cloud secret managers (AWS Secrets Manager, GCP Secret Manager, Vault),
            container/orchestrator env vars, CI/CD secrets.
Never put production secrets in .env files committed or shipped with the app.
```

## Централизуйте доступ

```js
// config.js — one validated config module the app imports (don't sprinkle process.env everywhere)
export const config = { dbUrl: env.DATABASE_URL, port: env.PORT };
```

## Почему это важно

Правильное управление конфигурацией и секретами — это одновременно **безопасность** и **операционная** необходимость.

Жёсткокодирование секретов приводит к их попаданию в систему контроля версий (серьёзный и частый взлом); смешивание конфигурации в коде усложняет развёртывание в разных окружениях.

Стандартный подход — переменные env, gitignore для `.env` в локальной разработке, `.env.example` для документации, валидация при старте и менеджеры секретов платформы в production — хранит секреты в безопасности, делает приложение портируемым между окружениями и выявляет ошибки конфигурации на ранней стадии.

Это основополагающий момент в ответственной разработке Node приложений.