Bagaimanakah anda menguruskan konfigurasi dan rahsia (secrets) dalam Node?

Question

Accepted Answer

Konfigurasi (URL pangkalan data, kunci API, port, feature flags) sepatutnya berada **di luar kod anda** dalam pembolehubah persekitaran — jangan sekali-kali dikodkan keras (hardcoded). Ini memastikan rahsia tidak berada dalam kawalan sumber dan membolehkan kod yang sama berjalan dalam dev, staging, dan pengeluaran dengan tetapan berbeza.

## Prinsipnya: konfigurasi daripada persekitaran

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

Ini mengikut prinsip **twelve-factor app**: pemisahan ketat konfigurasi daripada kod, supaya penggunaan ke persekitaran baharu bermakna menukar pembolehubah persekitaran, bukan kod.

## Pembangunan setempat: fail .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;
```

Fail `.env` menyimpan konfigurasi setempat; ia **mesti digitignore**. Commit `.env.example` (dengan kunci tetapi tanpa nilai sebenar) untuk mendokumenkan apa yang diperlukan.

## Sahkan konfigurasi semasa permulaan

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

Mengesahkan pembolehubah persekitaran semasa boot (dengan zod/envalid) bermakna rahsia yang hilang atau salah bentuk terhempas serta-merta dengan mesej yang jelas — jauh lebih baik daripada kegagalan masa jalan yang mengelirukan jauh di dalam sesuatu request.

## Rahsia dalam pengeluaran

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

## Pusatkan capaian

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

## Mengapa ia penting

Pengurusan konfigurasi dan rahsia yang betul adalah keperluan **keselamatan** dan juga **operasi**.

Mengkod keras rahsia membocorkannya ke dalam kawalan versi (pelanggaran serius yang biasa berlaku); mencampurkan konfigurasi ke dalam kod menjadikan penggunaan merentasi persekitaran menyakitkan.

Pendekatan standard — pembolehubah persekitaran, `.env` yang digitignore untuk dev setempat, `.env.example` untuk dokumentasi, pengesahan semasa permulaan, dan pengurus rahsia platform dalam pengeluaran — memastikan rahsia selamat, menjadikan aplikasi mudah alih merentasi persekitaran, dan mendedahkan salah konfigurasi lebih awal.

Ia asas untuk mengendalikan aplikasi Node secara bertanggungjawab.