Basis van cloud en containers
$ 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.2Zoals hierboven wordt het verbindingsdoel van de database niet in het image geschreven, maar bij het starten van de container als omgevingsvariabele doorgegeven. Wat is het belangrijkste voordeel van dit ontwerp?
- AWaarden in omgevingsvariabelen worden automatisch versleuteld; zelfs een wachtwoord kan dus niet door anderen worden gelezen
- BHetzelfde image kan in staging en productie worden gebruikt, waarbij alleen de instellingen veranderen en zonder opnieuw te bouwen; wat getest is, kan dus ongewijzigd naar productie
- CDe verbindingsgegevens komen niet in de lagen van het image terecht; het image heeft dus minder lagen en containers starten veel sneller
Antwoord en toelichting tonen
Antwoord: B. Hetzelfde image kan in staging en productie worden gebruikt, waarbij alleen de instellingen veranderen en zonder opnieuw te bouwen; wat getest is, kan dus ongewijzigd naar productie
Configuratie via omgevingsvariabelen doorgeven wordt ook aanbevolen door de methodologie The Twelve-Factor App, en het scheidt de code en het image van de omgeving waarin ze draaien. Hetzelfde image kan in staging en productie worden gebruikt; wat in productie komt, is dus precies wat getest is, en het image hoeft niet telkens opnieuw te worden gebouwd als het verbindingsdoel verandert. Omgevingsvariabelen zijn echter niet versleuteld; iedereen die de configuratie van de container of de procesinformatie kan zien, kan ze lezen. Vertrouwelijke waarden zoals wachtwoorden worden doorgegeven via mechanismen zoals Secrets van Kubernetes, die beperken wie ze mag lezen.