Jak zarządzasz konfiguracją i sekretami w Node?

Question

Accepted Answer

Konfiguracja (adresy URL baz danych, klucze API, porty, flagi funkcji) powinna żyć **poza kodem** w zmiennych środowiskowych — nigdy hardkodowana. To utrzymuje tajniki poza kontrolą źródła i pozwala temu samemu kodowi działać w dev, staging i produkcji z różnymi ustawieniami.

## Dlaczego to ważne

```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;
```

To podąża za zasadą **twelve-factor app**: ścisłe rozdzielenie konfiguracji od kodu, więc wdrażanie w nowe środowisko oznacza zmianę zmiennych env, nie kodu.

## Lokalne opracowanie: pliki .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;
```

Plik `.env` zawiera lokalną konfigurację; musi być **gitignorowany**. Zatwierdź `.env.example` (z kluczami, ale bez rzeczywistych wartości), aby udokumentować, co jest wymagane.

## Waliduj konfigurację przy uruchomieniu

```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
```

Walidacja zmiennych env przy uruchomieniu (z zod/envalid) oznacza, że brakujący lub zniekształcony sekret natychmiast ulega awarii ze przejrzystym komunikatem — znacznie lepiej niż mylący błąd runtime głęboko w żądaniu.

## Tajniki w produkcji

```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.
```

## Centralizuj dostęp

```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 };
```

## Dlaczego to ważne

Prawidłowe zarządzanie konfiguracją i sekretami to zarówno wymóg **bezpieczeństwa**, jak i **operacyjny**.

Hardkodowanie sekretów wycieka je do kontroli wersji (poważne, powszechne naruszenie); mieszanie konfiguracji w kodzie utrudnia wdrażanie w różnych środowiskach.

Standardowe podejście — zmienne env, gitignorowany `.env` dla lokalnego dev, `.env.example` dla dokumentacji, walidacja przy uruchomieniu i menedżerowie tajników platformy w produkcji — utrzymuje tajniki bezpieczne, czyni aplikację przenośną w różnych środowiskach i ujawnia błędną konfigurację wcześnie.

To jest fundamentalne dla odpowiedzialnego uruchamiania aplikacji Node.