Bagaimana anda menangani konfigurasi terpusat dan rahasia di seluruh layanan?

Question

Accepted Answer

Dengan puluhan layanan, anda tidak dapat mengelola konfigurasi dan rahasia secara ad hoc per penggelaran. **Konfigurasi terpusat** menyimpan pengaturan dalam satu sumber yang dikelola, dan **pengelola rahasia** menyimpan nilai sensitif dengan aman.

## Konfigurasi yang dieksternalisasi

Konfigurasi berada di luar artefak build, jadi gambar yang sama berjalan di dev/staging/prod dengan pengaturan yang berbeda.

```yaml
# values injected at runtime, not baked into the image
DATABASE_URL: ${DB_URL}        # per-environment
FEATURE_NEW_CHECKOUT: "true"   # toggle without redeploy
PAYMENT_TIMEOUT_MS: "3000"
```

## Pendekatan konfigurasi

| Pendekatan | Contoh |
|---|---|
| Server konfigurasi | Spring Cloud Config, Consul |
| Bawaan orkestrasi | Kubernetes ConfigMaps |
| Pengelola rahasia | HashiCorp Vault, AWS Secrets Manager |

## Rahasia — jaga agar tetap terpisah

Jangan pernah menyimpan rahasia di ConfigMaps biasa atau git.

```bash
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
```

## Praktik terbaik

```text
✓ Externalize config (12-factor): config in the environment
✓ Secrets in a dedicated manager with rotation + audit logs
✓ Dynamic refresh for non-secret toggles (no redeploy)
✗ Never commit secrets to source control
```

## Mengapa hal ini penting

Konfigurasi terpusat memungkinkan anda mengubah perilaku (timeout, bendera fitur) dan merotasi kredensial di banyak layanan tanpa membangun kembali dan menerapkan kembali masing-masing.

Menyimpan rahasia di pengelola rahasia nyata — bukan di gambar atau git — adalah persyaratan keamanan dasar yang diskalakan dengan jumlah layanan.

Pendekatan	Contoh
Server konfigurasi	Spring Cloud Config, Consul
Bawaan orkestrasi	Kubernetes ConfigMaps
Pengelola rahasia	HashiCorp Vault, AWS Secrets Manager