Si e menaxhoni konfigurimin e centralizuar dhe sekretet përgjatë shërbimeve?

Question

Accepted Answer

Me dhjetëra shërbime, nuk mund ta menaxhoni konfigurimin dhe sekretet ad hoc për çdo hapje. **Konfigurimi i centralizuar** mbajnë cilësimet në një burim të menaxhuar, dhe **menaxherët e sekreteve** ruajnë vlerat sensitive në mënyrë të sigurt.

## Konfigurimi i jashtëzuar

Konfigurimi jeton jashtë artefaktit të ndërtimit, kështu që e njëjta imazh punon në dev/staging/prod me cilësime të ndryshme.

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

## Qasjet e konfigurimit

| Qasja | Shembull |
|---|---|
| Serveri i konfigurimit | Spring Cloud Config, Consul |
| I zotëruar i orkestratorit | Kubernetes ConfigMaps |
| Menaxheri i sekreteve | HashiCorp Vault, AWS Secrets Manager |

## Sekretet — mbajini të ndara

Asnjë herë mos ruani sekretet në ConfigMaps të thjeshtë ose git.

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

## Praktikat e mira

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

## Pse është e rëndësishme

Konfigurimi i centralizuar ju lejon të ndryshoni sjelljen (kohëzgjatjet, flamujt e veçorive) dhe të rrotulloni kredencialet në shumë shërbime pa rindërtuar dhe ribashkëngjitje të secilit.

Ruajtja e sekreteve në një menaxher të vërtetë sekretesh — jo në imazhe ose git — është një kërkesë bazë e sigurisë që shkallëzohet me numrin e shërbimeve.

Qasja	Shembull
Serveri i konfigurimit	Spring Cloud Config, Consul
I zotëruar i orkestratorit	Kubernetes ConfigMaps
Menaxheri i sekreteve	HashiCorp Vault, AWS Secrets Manager