Kako upravljaš konfiguracija in skrivnosti v Node?

Question

IT Interview Practice · Accepted Answer

Konfiguracija (naslovi URL baz podatkov, ključi API, porti, zastavice funkcij) bi morala živeti **izven vašega koda** v spremenljivkah okolja — nikoli hardkodirane. To skrivnosti drži izven nadzora verzij in omogoča istemu kodu, da se izvaja v dev, staging in produkciji z različnimi nastavitvami.

## Zakaj je to pomenljivo

```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 sledi principu **twelve-factor app**: stroga ločitev konfiguracije od kode, zato poganjanje v novo okolje pomeni spreminjanje spremenljivk env, ne kode.

## Lokalni razvoj: datoteke .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;
```

Datoteka `.env` vsebuje lokalno konfiguracijo; morala bi biti **gitignored**. Prispevi `.env.example` (s ključi, vendar brez pravih vrednosti), da dokumentiraš, kaj je potrebno.

## Potvrdi konfiguracijo ob zagonu

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

Potrditev spremenljivk env ob zagonu (z zod/envalid) pomeni, da manjkajoča ali napačno oblikovana skrivnost takoj propade s jasnim sporočilom — veliko boljše kot zbegana napaka med izvajanjem globoko v zahtevi.

## Skrivnosti v produkciji

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

## Centraliziraj dostop

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

## Zakaj je to pomenljivo

Pravilno upravljanje konfiguracije in skrivnosti je tako **varnostna** kot **operacijska** nujnost.

Hardkodiranje skrivnosti jih procuri v nadzor verzij (resna, pogosta kršitev); mešanje konfiguracije v kodo naredi razporeditev po okoljah boleče.

Standardni pristop — spremenljivke env, gitignored `.env` za lokalni dev, `.env.example` za dokumentacijo, potrditev ob zagonu in upravljavci skrivnosti platforme v produkciji — skrivnosti drži varne, aplikacijo naredijo prenosljivo po okoljima in zgodnjo izpostavi napačno konfiguracijo.

Je temelj za odgovorno zaganjanje Node aplikacij.

Zakaj je to pomenljivo

Lokalni razvoj: datoteke .env

Potvrdi konfiguracijo ob zagonu

Skrivnosti v produkciji

Centraliziraj dostop

Zakaj je to pomenljivo

Povezana vprašanja