Avec des dizaines de services, vous ne pouvez pas gérer la configuration et les secrets de manière ad hoc par déploiement. La configuration centralisée garde les paramètres dans une source gérée unique, et les gestionnaires de secrets stockent les valeurs sensibles de manière sécurisée.
La configuration vit en dehors de l'artefact de build, donc la même image s'exécute en dev/staging/prod avec des paramètres différents.
| Approche | Exemple |
|---|---|
| Serveur de configuration | Spring Cloud Config, Consul |
| Natif de l'orchestrateur | Kubernetes ConfigMaps |
| Gestionnaire de secrets | HashiCorp Vault, AWS Secrets Manager |
Ne stockez jamais les secrets en clair dans les ConfigMaps ou git.
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
✓ 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
La configuration centralisée vous permet de modifier le comportement (timeouts, feature flags) et de faire tourner les credentials entre de nombreux services sans reconstruire et redéployer chacun d'eux.
Garder les secrets dans un vrai gestionnaire de secrets — pas dans les images ou git — est une exigence de sécurité de base qui s'adapte au nombre de services.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don