Kaip tvarkote centralizuotą konfigūraciją ir paslaptis skirtinguose servuose?

Question

Accepted Answer

Turint dešimtis paslaugų, negalite ad hoc valdyti konfigūracijos ir paslapčių kiekviename diegime. **Centralizuota konfigūracija** saugo nustatymus viename valdytame šaltinyje, o **paslapčių valdyklė** saugiai saugo jautrias reikšmes.

## Išorinė konfigūracija

Konfigūracija yra išorėje nuo darinio, todėl tas pats vaizdas veikia dev/staging/prod su skirtingais nustatymais.

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

## Konfigūracijos metodai

| Metodas | Pavyzdys |
|---|---|
| Config serveris | Spring Cloud Config, Consul |
| Orkestruotojo-gimimo | Kubernetes ConfigMaps |
| Paslapčių valdyklė | HashiCorp Vault, AWS Secrets Manager |

## Paslaptys — laikykite atskirai

Niekada nesaugokite paslapčių grynuose ConfigMaps arba git.

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

## Geroji praktika

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

## Kodėl tai svarbu

Centralizuota konfigūracija leidžia keisti elgesį (timeout'ai, savybių ženklius) ir suktis kredencialai per daugelį paslaugų, nereikėdami iš naujo kurti ir iš naujo diegti kiekvieno.

Paslapčių laikymas tikroje paslapčių valdiklėje — ne vaizduose ar git — yra bazinis saugumo reikalavimas, kuris augmėja didėjant paslaugų skaičiui.

Metodas	Pavyzdys
Config serveris	Spring Cloud Config, Consul
Orkestruotojo-gimimo	Kubernetes ConfigMaps
Paslapčių valdyklė	HashiCorp Vault, AWS Secrets Manager