Creazione di un Docker UAT / image di produzione

Solo una rapida domanda sulle pratiche migliori per la creazione di immagini Docker per ambienti critici. Come sappiamo nel mondo reale, spesso la squadra / società che distribuisce al test interno non è la stessa di chi sta implementando in ambienti di test client e produzione. Ci si presenta un problema perché tutte le informazioni sulla configuration di un'applicazione potrebbero non essere disponibili quando si crea l'image di Docker UAT / produzione, ad esempio con Jenkins. E poi c'è la domanda sulle password memorizzate nella configuration dell'app.

Quindi la mia domanda è, come "completamente configurato" dovrebbe essere l'image Docker? Il modo in cui lo vedo, in pratica non è ansible configurare completamente l'image Docker, ma alcune password per le app, ecc. Devono essere lasciate fuori. Ma poi questo leggermente sfida lo scopo di un'image Docker?

come "completamente configurato" dovrebbe essere l'image Docker? Il modo in cui lo vedo, in pratica non è ansible configurare completamente l'image Docker, ma alcune password per le app, ecc. Devono essere lasciate fuori. Ma poi questo leggermente sfida lo scopo di un'image Docker?

Ci sarà sempre compromessi tra comfort, sicurezza e flessibilità. Un'image che funziona con la configuration di runtime zero è molto comodo da eseguire, ma non molto flessibile e sensibile come le configurazioni delle password saranno esposte. Un'image che prende tutta la configuration in fase di esecuzione è molto flessibile e non espone informazioni sensibili, ma può risultare sconveniente da utilizzare se non vengono forniti valori predefiniti. Se un utente non conosce alcuni valori, potrebbe non essere in grado di utilizzare l'image affatto.

Informazioni sensibili come le password solitamente si trovano sul lato di runtime quando decidono quale configuration da cuocere in immagini e cosa richiedere in fase di runtime. Tuttavia, questo non è sempre il caso. Ad esempio, è ansible creare immagini di prova con configuration a runtime zero che indicano solo gli ambienti di prova. Ognuno ha accesso alle credenziali dell'ambiente di prova comunque, la configuration zero è più conveniente per i tester e nessuno può accidentalmente eseguire una build contro il database sbagliato.

Per la configuration diversa dalle credenziali (ad es. Proprietà app, loglevel, posizione del file di log), la struttura organizzativa e la dynamic del team potrebbero determinare la quantità di configuration in cui si cuoce. In un ambiente devops, apportre modifiche e build una nuova image può essere indolore. In questo caso ha senso cuocere nella configuration desiderata. Se gli ops e lo sviluppo sono separati, può richiedere alcuni giorni per apportre modifiche minori all'image. In questo caso è consigliabile consentire una configuration più runtime.

Tornando alla domanda originale, sono personalmente a favore di scegliere i valori predefiniti ragionevoli per tutto tranne le credenziali e permettere che runtime annullino solo se necessario (convenzione con configuration riluttante). La configuration di runtime è conveniente per gli ops, ma può rendere difficile il rilevamento di problemi per il team di sviluppo.