Node'de konfigürasyon ve secrets'leri nasıl yönetirsiniz?

Question

Accepted Answer

Konfigürasyon (veritabanı URL'leri, API anahtarları, portlar, özellik bayrakları) kodunuzun **dışında** ortam değişkenlerinde bulunmalı — asla sabit kodlanmış olmamalı. Bu, secrets'leri kaynak kontrolü dışında tutar ve aynı kodun geliştirme, staging ve üretim ortamlarında farklı ayarlarla çalışmasını sağlar.

## Prensip: ortamdan konfigürasyon

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

Bu, **twelve-factor app** prensibini takip eder: konfigürasyonun koddan kesin ayrılması, böylece yeni bir ortama dağıtmak kod değil, env değişkenlerini değiştirmek anlamına gelir.

## Yerel geliştirme: .env dosyaları

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

Bir `.env` dosyası yerel konfigürasyonu tutar; **gitignore edilmesi gerekir**. Nelerin gerekli olduğunu belgelemek için (anahtarlarla ancak gerçek değerler olmadan) bir `.env.example` kaydedin.

## Başlangıçta konfigürasyonu doğrulayın

```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 değişkenlerini başlangıçta doğrulamak (zod/envalid ile) eksik veya yanlış biçimlendirilmiş bir secret'in hemen anlaşılır bir mesajla çökmesi anlamına gelir — bir isteğin derinliklerinde kafa karıştırıcı bir çalışma zamanı hatası çok daha iyidir.

## Üretimde secrets

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

## Erişimi merkezileştirin

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

## Neden önemli

Uygun konfigürasyon ve secret yönetimi hem bir **güvenlik** hem de bir **operasyonel** gerekliliktir.

Secrets'leri sabit kodlamak onları sürüm kontrolüne sızdırır (ciddi, yaygın bir ihlal); konfigürasyonu koda karıştırmak ortamlar arasında dağıtımı ağır hale getirir.

Standart yaklaşım — env değişkenleri, yerel geliştirme için gitignore edilmiş `.env`, belgeleme için `.env.example`, başlangıçta doğrulama ve üretimde platform secret yöneticileri — secrets'leri güvenli tutar, uygulamayı ortamlar arasında taşınabilir hale getirir ve yanlış konfigürasyonu erkende ortaya çıkarır.

Node uygulamalarını sorumlu bir şekilde çalıştırmanın temelini oluşturur.