Как вы управляете централизованной конфигурацией и секретами для различных сервисов?

Question

Accepted Answer

Имея дюжины сервисов, вы не можете управлять конфигурацией и секретами для каждого развёртывания. **Централизованная конфигурация** хранит параметры в одном управляемом источнике, а **менеджеры секретов** безопасно хранят чувствительные значения.

## Экспортированная конфигурация

Конфигурация находится вне артефакта сборки, поэтому один и тот же образ работает в dev/staging/prod с разными параметрами.

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

## Подходы к конфигурации

| Подход | Пример |
|---|---|
| Сервер конфигурации | Spring Cloud Config, Consul |
| Встроенная в оркестратор | Kubernetes ConfigMaps |
| Менеджер секретов | HashiCorp Vault, AWS Secrets Manager |

## Секреты — храните их отдельно

Никогда не храните секреты в обычных ConfigMaps или git.

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

## Хорошие практики

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

## Почему это важно

Централизованная конфигурация позволяет изменять поведение (таймауты, feature flags) и ротировать учётные данные для многих сервисов без пересборки и повторного развёртывания каждого из них.

Хранение секретов в настоящем менеджере секретов — а не в образах или git — это базовое требование безопасности, которое масштабируется вместе с количеством сервисов.

Подход	Пример
Сервер конфигурации	Spring Cloud Config, Consul
Встроенная в оркестратор	Kubernetes ConfigMaps
Менеджер секретов	HashiCorp Vault, AWS Secrets Manager