Bases du cloud et des conteneurs
$ docker run -d -e DB_HOST=db.staging.example.com web:1.4.2
$ docker run -d -e DB_HOST=db.prod.example.com web:1.4.2Comme ci-dessus, la destination de connexion à la base de données n'est pas écrite dans l'image, mais transmise sous forme de variable d'environnement au démarrage du conteneur. Quel est le principal avantage de cette conception ?
- ALes valeurs placées dans des variables d'environnement sont chiffrées automatiquement : même un mot de passe ne peut donc pas être lu par d'autres
- BLa même image peut servir en préproduction et en production, en changeant seulement les réglages et sans reconstruction : ce qui a été testé peut donc être mis en production tel quel
- CLes informations de connexion n'entrent pas dans les couches de l'image : l'image a donc moins de couches et les conteneurs démarrent beaucoup plus vite
Afficher la réponse et l'explication
Réponse : B. La même image peut servir en préproduction et en production, en changeant seulement les réglages et sans reconstruction : ce qui a été testé peut donc être mis en production tel quel
Transmettre la configuration par des variables d'environnement est aussi recommandé par la méthodologie appelée The Twelve-Factor App, et cela sépare le code et l'image de l'environnement qui les exécute. La même image peut servir en préproduction et en production : ce qui arrive en production est donc exactement ce qui a été testé, et il n'est pas nécessaire de reconstruire l'image chaque fois que la destination de connexion change. Les variables d'environnement ne sont toutefois pas chiffrées : quiconque peut voir la configuration du conteneur ou les informations sur les processus peut les lire. Les valeurs confidentielles comme les mots de passe sont transmises par des mécanismes comme les Secrets de Kubernetes, qui restreignent qui peut les lire.
Continuer : 9 autres questions sur Bases du cloud et des conteneurs