Hizmetler arasında merkezi yapılandırmayı ve sırları nasıl yönetirsiniz?

Question

Accepted Answer

Düzinelerce hizmetle, yapılandırmayı ve sırları her dağıtım için ad hoc olarak yönetemezsiniz. **Merkezi yapılandırma** ayarları yönetilen bir kaynakta tutar ve **sır yöneticileri** hassas değerleri güvenli bir şekilde depolar.

## Dışsallaştırılmış yapılandırma

Yapılandırma yapı yapıtının dışında yaşar, bu nedenle aynı görüntü dev/staging/prod içinde farklı ayarlarla çalışır.

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

## Yapılandırma yaklaşımları

| Yaklaşım | Örnek |
|---|---|
| Yapılandırma sunucusu | Spring Cloud Config, Consul |
| Orchestrator-native | Kubernetes ConfigMaps |
| Sır yöneticisi | HashiCorp Vault, AWS Secrets Manager |

## Sırlar — onları ayrı tutun

Sırları düz ConfigMaps veya git'te depolamayın.

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

## İyi uygulamalar

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

## Neden önemli

Merkezi yapılandırma, davranışı (timeouts, özellik bayrakları) değiştirmenize ve her birini yeniden oluşturup yeniden dağıtmadan birçok hizmet arasında kimlik bilgilerini döndürmenize olanak tanır.

Sırları görüntülerde veya git'te değil, gerçek bir sır yöneticisinde depolamak, hizmet sayısıyla birlikte ölçeklenen temel bir güvenlik gereksinimidir.

Yaklaşım	Örnek
Yapılandırma sunucusu	Spring Cloud Config, Consul
Orchestrator-native	Kubernetes ConfigMaps
Sır yöneticisi	HashiCorp Vault, AWS Secrets Manager