Suddivisione del codice dell'applicazione e dei file di distribuzione della finestra mobile

2

Sto iniziando il processo di spostamento del mio stack di django in contenitori docker. La maggior parte degli esempi che ho visto inserisce i file Dockerfile e docker-compose.yml nello stesso repository del codice sorgente dell'applicazione.

Finora ho usato l'ansible per l'implementazione, mi è servito bene, e intendo mantenerlo mentre impacchetta gradualmente i vari servizi in contenitori. Tutti i miei file ansible sono nel loro repository git, separati dal codice sorgente dell'app, quindi tutte le mie configurazioni sono versionate. Questo ha funzionato molto bene finora.

La mia domanda riguarda la posizione dei file docker . Li ho messi con il codice dell'app, ma ora ritengo che questo mi costringa a inserire informazioni relative alla distribuzione nel codice dell'app, che ritengo sia sbagliato.

Un esempio: utilizzo Celery per vari processi, che si basa su rabbitmq per la messaggistica. Ognuno vive in un contenitore come sembra essere raccomandato. Devo passare a Celery la password per rabbitmq, che sto passando come variabile di ambiente in docker-compose.yml . Quindi, in breve, la mia password di implementazione è nel codice dell'app. Questo è solo uno dei numerosi esempi.

Qual è la migliore pratica per suddividere la configurazione e gli script di distribuzione del codice di applicazione VS in questo contesto? O più nello specifico, dove dovrebbero vivere i file della finestra mobile?

    
posta Laurent S 20.05.2017 - 12:54
fonte

1 risposta

5

Spesso ha senso eseguire la versione docker-compose.yml di file separatamente dalla tua applicazione, poiché sono specifici per diverse distribuzioni e fanno riferimento a più immagini di finestra mobile da diversi microservizi, che di solito sono conservati nei loro singoli repository. Anche se dovresti esaminare soluzioni come il comando segreto della finestra mobile per la gestione di cose come la tua password rabbitmq, piuttosto che cuocerlo nella tua app.

Tuttavia, Dockerfiles non riguarda la distribuzione. Sono molto più simili a uno script di costruzione. Se mantieni i tuoi Dockerfile con diversi script di distribuzione, corri il rischio di avere immagini diverse in ambienti diversi. Quello che vuoi è la stessa immagine in fase di sviluppo, debug, testing, staging e tutte le diverse configurazioni del cliente in produzione. Potresti personalizzarlo un po 'con le variabili di ambiente, ma mantenere l'immagine lo stesso ti compra molto e mantenere il Dockerfile con il codice è il modo più semplice per assicurarti che.

In sintesi, mantieni Dockerfiles con il codice, ma separa i file yaml se hai molti ambienti di distribuzione diversi da tenere traccia.

    
risposta data 21.05.2017 - 05:13
fonte

Leggi altre domande sui tag