Come Docker e Ansible si incastrano per implementare la distribuzione continua/la distribuzione continua

Question

Sono nuovo agli strumenti di gestione e distribuzione della configurazione. Devo implementare uno strumento di distribuzione continua/distribuzione continua per uno dei progetti più interessanti su cui abbia mai messo le mani.

Prima di tutto, individualmente, mi trovo a mio agio con AWS, so che cos'è Ansible, la logica dietro di esso e il suo scopo. Non ho lo stesso livello di conoscenza di Docker ma ho avuto l'idea. Ho passato molte risorse Internet, ma non riesco a ottenere il quadro generale.

Quello che ho fatto fatica è il modo in cui si adattano. Usando Ansible, posso gestire la mia infrastruttura come codice; creazione di istanze EC2, installazione di pacchetti ... Posso persino distribuire un'applicazione completa estraendo il codice, modificando i file di configurazione e avviando il server web. Docker è, di per sé, uno strumento che pacchetta un'applicazione e garantisce che possa essere eseguito ovunque lo si distribuisca.

I miei problemi sono:

Come funziona Docker (o Ansible e Docker) estendono il processo di Continuous Integration !?

Supponiamo di disporre di un repository del codice sorgente, che i membri del team finiscano di lavorare su una funzione e che spingano il proprio lavoro. Jenkins lo rileva, esegue tutte le suite di test di accettazione/unità/integrazione e, se passano tutte, lo dichiara come una build stabile. Come si inserisce Docker qui? Voglio dire quando il team spinge il loro lavoro, Jenkins deve estrarre la sorgente del file Docker nell'app, creare l'immagine dell'applicazione, avviare il contenitore ed eseguire tutti i test o eseguire i test in modo classico e se tutto è buono allora costruisce l'immagine Docker dal file Docker e la salva in un luogo privato? Se Jenkins tagga l'immagine finale usando x.y.z per esempio !?

Docker configurazione contenitori:

Supponiamo di avere un'immagine costruita da Jenkins memorizzati da qualche parte, come gestire la distribuzione della stessa immagine in ambienti diversi, e anche, diversi parametri di configurazione (Vhosts config, host DB, code URL, endpoint S3, ecc.) Qual è il modo più flessibile per gestire questo problema senza rompere i principi Docker? Queste configurazioni sono supportate nell'immagine quando viene generata o quando viene avviato il contenitore basato su di esso, in caso affermativo come vengono iniettate?

Ansible e Docker:

Ansible fornisce un modulo Docker per gestire Docker contenitori. Supponendo di aver risolto i problemi sopra menzionati, quando voglio distribuire una nuova versione x.t.z della mia app, dico allo Ansible di estrarre l'immagine da dove era stata memorizzata, avviare il contenitore dell'app, quindi come iniettare le impostazioni di configurazione !? Ansible deve accedere all'immagine Docker, prima che sia in esecuzione (mi sembra assurdo) e usare i suoi modelli Jinja2 allo stesso modo con un host classico !? In caso contrario, come viene gestito ?!

Scusami se è stata una lunga domanda o se ho sbagliato a scrivere qualcosa, ma questo è il mio pensiero ad alta voce. Sono bloccato per le ultime due settimane e non riesco a capire il corretto flusso di lavoro. Voglio che questo sia un riferimento per i futuri lettori.

Per favore, sarebbe molto utile leggere le vostre esperienze e soluzioni perché questo sembra un flusso di lavoro comune. Grazie in anticipo. Ogni aiuto è molto apprezzato.

Answer 1

vorrei rispondere in parti

Come funziona Docker (o Ansible e Docker) estendere il processo di Continuous Integration !?

Poiché le immagini di ancoraggio sono uguali ovunque, si utilizzano le immagini di ancoraggio come se fossero immagini di produzione. Pertanto, quando qualcuno ha commesso un codice, si costruisce l'immagine della finestra mobile. Esegui test contro di esso. Quando passano tutti i test, tagghi quell'immagine di conseguenza. Poiché la finestra mobile è veloce, questo è un flusso di lavoro fattibile. Anche le modifiche della finestra mobile sono incrementali; pertanto, le tue immagini avranno un impatto minimo sull'archiviazione. Inoltre, quando i test falliscono, puoi anche scegliere di salvare anche quell'immagine. In questo modo, lo sviluppatore estrarrà quell'immagine e indagherà facilmente sul motivo per cui i test sono falliti. Lo sviluppatore può scegliere di eseguire test nella sua macchina anche perché le immagini docker in jenkins e la loro macchina non sono diverse.

Ciò significa che tutti gli sviluppatori avranno lo stesso ambiente, la stessa versione di tutto il software poiché si decide quale verrà utilizzato nelle immagini di ancoraggio. Mi sono imbattuto in bug che sono dovuti a differenze tra le macchine sviluppatore. Ad esempio nello stesso sistema operativo, le impostazioni Unicode possono influire sul codice. Ma nelle immagini docker tutti gli sviluppatori testeranno contro le stesse impostazioni, lo stesso software di versione.

Docker configurazione contenitori:

Se si utilizza un repository privato, e si dovrebbe utilizzare uno, poi le modifiche alla configurazione non influiranno molto spazio sul disco rigido. Pertanto, ad eccezione delle configurazioni di sicurezza, come le password db, è possibile applicare le modifiche di configurazione alle immagini della finestra mobile (Baking the Configuration into the Container). Quindi è possibile utilizzare ansible per applicare le configurazioni non memorizzate alle immagini distribuite prima/dopo l'avvio utilizzando variabili di ambiente o volumi Docker.

https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-application-configuration-into-my-docker-containers/

fa Ansible effettuare il log l'immagine Docker, prima che sia in esecuzione ( questo suona folle a me) e usare il suo Jinja2 modelli allo stesso modo con una serie classica !? In caso contrario, come viene gestito ?!

No, ansible non accederà all'immagine Docker, ma è possibile utilizzare ansible con i modelli Jinja2 per modificare il file docker. È possibile modificare file docker con modelli e inserire la configurazione in file diversi. Tagga i tuoi file di conseguenza e hai configurato le immagini da far ruotare.

Answer 2

Anche se non è una soluzione completa, ho suggerimenti per due dei vostri problemi. Anche se potrebbero non essere perfetti, queste sono le pratiche che stiamo usando nel nostro flusso di lavoro e si dimostrano così lontane.

1. Definire ambienti diversi - supponendo che hai scritto un ruolo Ansible diverso per ogni ambiente si avvia, si definisce una variabile di ambiente di impostazione l'ambiente che vogliamo il contenitore di appartenere a. Scarichiamo quindi il file di configurazione adatto da un bucket S3 utilizzando la variabile env impostata precedentemente nel contenitore (che dovrebbe essere possibile se fornisci credenziali AWS o assegni il tuo server a un ruolo IAM) e inserisci questi parametri nel codice al momento della creazione.

2. Ansible non ha bisogno di accedere all'app mobile, ma la soluzione è un po 'complicata. Ho provato due modi per affrontare questo problema, ed entrambi non sono ideali. Il primo consiste nel scaricare il file di configurazione come parte della riga di comando dell'immagine della finestra mobile e creare l'app all'avvio del contenitore. Mentre questa soluzione funziona, viola la filosofia di Docker e rende l'immagine molto incline a generare errori. Un'altra soluzione sta spingendo diverse immagini sul repository hub docker, quindi tirando l'immagine appropriata in base all'ambiente in questione.

In un colpo più ampio, ho provato lanciando la nostra applicazione completamente con Ansible ed è stato l'inferno, molti passaggi di configurazione sono difficili e ottenere più complicato quando si tenta di implementare loro come un playbook. Quando sono passato a mantenere i severs da solo con Ansible, e distribuendo l'app stessa con Docker le cose sono diventate molto più semplici.

Answer 3

Per quanto riguarda la tua domanda sulla gestione di più configurazioni di ambiente utilizzando la stessa immagine Docker, ho intenzione di utilizzare uno strumento di individuazione dei servizi come Consul come strumento di gestione centralizzata di configurazione/proprietà. Quindi, quando si avvia il contenitore, si imposta una variabile ENV che indica quale applicazione è (appID) e quale configurazione di ambiente deve utilizzare (ad esempio: MyApplication: Dev) e verrà estratta da Consul all'avvio. Devo ancora indagare sulla sicurezza attorno a Consul (come se stessimo memorizzando le credenziali di connessione DB, ad esempio, come limitiamo chi può interrogare/aggiornare quei valori). Non voglio usarlo solo per i contenitori, ma per tutte le app in generale. Un'altra funzionalità interessante è quella di modificare il valore di configurazione in Console e riavviarlo nella tua app per applicare immediatamente le modifiche (magari come un endpoint REST sull'app per spingere le modifiche verso il basso e applicarlo dinamicamente). Ovviamente la tua app deve essere scritta per supportare questo!

Potresti essere interessato a consultare gli articoli del blog di Martin Fowler su immutable infrastructure e su Phoenix servers.