Hur hanterar du centraliserad konfiguration och hemligheter över tjänster?

Question

Accepted Answer

Med dussintals tjänster kan du inte hantera konfiguration och hemligheter ad hoc per distribution. **Centraliserad konfiguration** håller inställningar i en hanterad källa, och **hemlighetschefer** lagrar känsliga värden säkert.

## Externaliserad konfiguration

Konfigurationen ligger utanför byggartefakten, så samma avbild körs i dev/staging/prod med olika inställningar.

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

## Konfigurationsmetoder

| Metod | Exempel |
|---|---|
| Konfigurationsserver | Spring Cloud Config, Consul |
| Orkestratorinfött | Kubernetes ConfigMaps |
| Hemlighetschef | HashiCorp Vault, AWS Secrets Manager |

## Hemligheter — håll dem åtskilda

Lagra aldrig hemligheter i vanliga ConfigMaps eller git.

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

## God praxis

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

## Varför det spelar roll

Centraliserad konfiguration låter dig ändra beteende (timeout, funktionsflaggor) och rotera autentiseringsuppgifter över många tjänster utan att bygga om och distribuera om var och en.

Att lagra hemligheter i en verklig hemlighetschef — inte i avbilder eller git — är ett grundläggande säkerhetskrav som skalas med antalet tjänster.

Metod	Exempel
Konfigurationsserver	Spring Cloud Config, Consul
Orkestratorinfött	Kubernetes ConfigMaps
Hemlighetschef	HashiCorp Vault, AWS Secrets Manager