Ti invito a prendere visione della trascrizione della relazione di Aleksandr Sigacev di Inventos "Il processo di sviluppo e testing con Docker + Gitlab CI"
Coloro che iniziano a implementare il processo di sviluppo e testing basato su Docker + Gitlab CI spesso pongono domande fondamentali. Da dove iniziare? Come organizzare? Come testare?
Questa relazione è interessante perché descrive in modo strutturato il processo di sviluppo e testing utilizzando Docker e Gitlab CI. La relazione risale al 2017. Penso che si possano trarre da essa le basi, la metodologia, l'idea e le esperienze di utilizzo.
Chi è interessato, prego di proseguire.
Mi chiamo Aleksandr Sigacev. Lavoro per l'azienda Inventos. Condividerò la mia esperienza nell'uso di Docker e come gradualmente lo stiamo implementando nei progetti dell'azienda.
Tema della relazione: Il processo di sviluppo utilizzando Docker e Gitlab CI.
Questa è la mia seconda relazione su Docker. Al momento della prima relazione, usavamo Docker solo in sviluppo sulle macchine degli sviluppatori. Il numero di dipendenti che utilizzavano Docker era di circa 2-3 persone. Gradualmente abbiamo accumulato esperienza e siamo progrediti. Ecco il link alla nostra .
Cosa ci sarà in questa relazione? Condivideremo le esperienze su quali ostacoli abbiamo incontrato e come abbiamo risolto i problemi. Non sempre è stato semplice, ma ci ha permesso di andare avanti.
Il nostro motto: dockerizza tutto ciò che riusciamo a toccare.
Quali problemi risolviamo?
Quando in un'azienda ci sono più team, il programmatore diventa una risorsa condivisa. Ci sono fasi in cui il programmatore viene estratto da un progetto e assegnato per un certo periodo a un altro progetto.
Per consentire al programmatore di orientarsi rapidamente, è necessario che scarichi il codice sorgente del progetto e avvii il più velocemente possibile un ambiente che gli permetta di avanzare risolvendo le attività di quel progetto.
Di solito, se si inizia da zero, la documentazione nel progetto è scarsa. Le informazioni su come configurare sono disponibili solo per i veterani. I dipendenti configurano autonomamente il proprio posto di lavoro in uno o due giorni. Per velocizzare questo processo, abbiamo utilizzato Docker.
Un altro motivo è la standardizzazione delle configurazioni in sviluppo. Dalla mia esperienza, gli sviluppatori sono sempre proattivi. In ogni quinto caso viene introdotto un dominio personalizzato, ad esempio vasya.dev. Vicino c'è l'amico Petya, che ha il dominio petya.dev. Sviluppano un sito o un componente del sistema utilizzando questo nome di dominio.
Quando il sistema cresce e questi nomi di dominio iniziano a comparire nelle configurazioni, sorge un conflitto negli ambienti di sviluppo e il percorso del sito viene riscritto.
Lo stesso accade con le impostazioni del database. Alcuni non si preoccupano della sicurezza e lavorano con una password root vuota. Qualcuno, durante l'installazione, ha richiesto una password MySQL e si è rivelata 123. Spesso accade che la configurazione del database cambi continuamente a seconda del commit dello sviluppatore. Qualcuno l'ha corretta, qualcun altro no. Ci sono stati artifici quando abbiamo estratto una configurazione di test in .gitignore e ogni sviluppatore doveva installare il database. Questo complicava il processo di partenza. Oltre a tutto il resto, è necessario tenere a mente il database. Il database deve essere inizializzato, è necessario specificare la password, è necessario specificare l'utente, creare una tabella e così via.
Un altro problema è rappresentato dalle diverse versioni delle librerie. Spesso succede che uno sviluppatore lavori su diversi progetti. C'è un progetto Legacy, iniziato cinque anni fa (dal 2017 – nota dell'editore). All'inizio si partì con MySQL 5.5. Ci sono anche progetti moderni in cui tentiamo di implementare versioni MySQL più recenti, come 5.7 o superiori (nel 2017 – nota dell'editore).
Chi lavora con MySQL sa che queste librerie portano con sé delle dipendenze. È abbastanza problematico far funzionare insieme 2 database. Almeno, è problematico collegare vecchi client a un nuovo database. Questo genera a sua volta diversi problemi.
Il problema successivo è quando lo sviluppatore lavora su una macchina locale, utilizza risorse locali, file locali, RAM locale. Tutta l'interazione durante lo sviluppo delle soluzioni avviene nell'ambito del funzionamento su una sola macchina. Un esempio può essere quando abbiamo in produzione 3 server backend, mentre lo sviluppatore salva i file nella cartella radice e nginx prende i file da lì per rispondere alle richieste. Quando questo codice arriva in produzione, si scopre che il file è presente su uno dei 3 server.
Attualmente si sta sviluppando la direzione dei microservizi. Quando dividiamo le nostre grandi applicazioni in piccole componenti che interagiscono tra loro. Questo consente di scegliere le tecnologie specifiche per un determinato stack di compiti. Inoltre, consente di suddividere il lavoro e l'area di responsabilità tra gli sviluppatori.
Lo sviluppatore Frontend, lavorando con JS, non influisce praticamente sul Backend. Lo sviluppatore Backend, a sua volta, sviluppa, nel nostro caso, Ruby on Rails e non interferisce con il Frontend. L'interazione avviene tramite API.
Come bonus, grazie a Docker siamo riusciti a ottimizzare le risorse su Staging. Ogni progetto, a causa della sua specificità, richiedeva impostazioni particolari. Era necessario dedicare un server virtuale oppure dividere un ambiente variabile, e i progetti potevano influenzarsi a vicenda a seconda della versione delle librerie.
Strumenti. Cosa usiamo?
- Direttamente Docker stesso. Nel Dockerfile vengono descritte le dipendenze di una applicazione.
- Docker-compose è il legame che unisce le nostre diverse applicazioni Docker.
- Utilizziamo GitLab per la conservazione del codice sorgente.
- Utilizziamo GitLab-CI per l'integrazione sistemica.
La presentazione è composta da due parti.
La prima parte parlerà di come abbiamo eseguito Docker sulle macchine degli sviluppatori.
La seconda parte parlerà di come interagire con GitLab, di come eseguiamo i test e di come distribuiamo su Staging.
Docker è una tecnologia che permette (utilizzando un approccio dichiarativo) di descrivere i componenti necessari. Questo è un esempio di Dockerfile. Qui dichiariamo che ereditiamo dall'immagine Docker ufficiale Ruby:2.3.0. Contiene Ruby versione 2.3 installato. Installiamo le librerie di compilazione necessarie e NodeJS. Descriviamo che stiamo creando una directory /app. Assegniamo la directory app come directory di lavoro. In questa directory posizioniamo il minimo necessario di Gemfile e Gemfile.lock. Successivamente eseguiamo la compilazione dei progetti che installano le dipendenze di questa immagine. Indichiamo che il contenitore sarà pronto ad ascoltare sulla porta esterna 3000. L'ultima comando è quello che avvia effettivamente la nostra applicazione. Se eseguiamo il comando di avvio del progetto, l'applicazione cercherà di avviarsi e di eseguire il comando specificato.
Questo è un esempio minimale di un file docker-compose. In questo caso mostriamo come avviene la connessione tra due contenitori. Si tratta direttamente del servizio del database e del servizio web. Le nostre applicazioni web in maggior parte dei casi richiedono un database per la memorizzazione dei dati come backend. Poiché utilizziamo MySQL, l'esempio è con MySQL, ma nulla vieta di usare un altro database (PostgreSQL, Redis).
Prendiamo dal sorgente ufficiale su Docker hub l'immagine di MySQL 5.7.14 senza modifiche. L'immagine che gestisce la nostra applicazione web viene costruita dalla directory corrente. Durante il primo avvio ci costruisce l'immagine. Dopodiché esegue il comando che stiamo qui eseguendo. Se torniamo indietro, vedremo che è stato definito un comando di avvio tramite Puma. Puma è un servizio scritto in Ruby. Nel secondo caso si può sovrascrivere. Questo comando può essere arbitrario a seconda delle nostre necessità o obiettivi.
Inoltre, descriviamo che è necessario inoltrare la porta sulla macchina host dello sviluppatore dalla porta 3000 alla porta 3000 del contenitore. Questo viene eseguito automaticamente tramite iptables e il suo meccanismo, che è direttamente integrato in Docker.
Lo sviluppatore può anche, come in precedenza, connettersi a qualsiasi IP disponibile, ad esempio, 127.0.0.1 per l'indirizzo IP locale o l'indirizzo IP esterno della macchina.
L'ultima riga indica che il contenitore web dipende dal contenitore db. Quando avviamo il contenitore web, prima docker-compose avvierà il nostro database. Solo una volta avviato il database (in realtà — dopo l'avvio del contenitore! La prontezza del DB non è garantita) avvierà la nostra applicazione, il nostro backend.
Questo permette di evitare errori quando il database non è attivo e consente di risparmiare risorse quando fermiamo il contenitore del database, liberando così risorse per altri progetti.
Cosa ci offre l'uso della containerizzazione del database nel progetto. Fissiamo la versione di MySQL per tutti gli sviluppatori. Questo permette di evitare alcuni errori che possono insorgere a causa di discrepanze nelle versioni, quando cambia la sintassi, la configurazione, le impostazioni predefinit. Questo consente di specificare hostname comuni per il database, login, password. Ci allontaniamo dalla giungla di nomi e conflitti nei file di configurazione che esisteva in precedenza.
Abbiamo la possibilità di utilizzare un config più ottimale per l'ambiente di sviluppo, che differirà da quello predefinito. MySQL è configurato per impostazione predefinita su macchine poco potenti e la sua performance out-of-the-box è molto bassa.
Docker consente di utilizzare l'interprete Python, Ruby, NodeJS, PHP nella versione richiesta. Ci liberiamo dalla necessità di utilizzare un gestore di versioni. In precedenza, per Ruby usavamo un pacchetto rpm, che consentiva di cambiare versione a seconda del progetto. Inoltre, grazie al container Docker, possiamo migrare il codice in modo fluido e versionarlo insieme alle dipendenze. Non abbiamo problemi a comprendere la versione sia per l'interprete sia per il codice. Per aggiornare la versione è necessario abbattere il vecchio container e alzare un nuovo container. Se qualcosa va storto, possiamo abbattere il nuovo container e ripristinare il vecchio container.
Dopo la creazione dell'immagine, i container sia in sviluppo che in produzione saranno identici. Questo è particolarmente rilevante per grandi installazioni.
Nel frontend utilizziamo JavaScript e NodeJS.
Attualmente, l'ultimo progetto è su ReactJS. Lo sviluppatore avviava tutti i container e sviluppava utilizzando il hot-reload.
Successivamente, viene avviato il processo di compilazione di JavaScript e il codice, compilato in statico, viene servito tramite nginx per risparmiare risorse.
Qui ho presentato lo schema del nostro ultimo progetto.
Quali problemi abbiamo risolto? Abbiamo avuto la necessità di costruire un sistema con cui interagiscono i dispositivi mobili. Essi ricevono dati. Una delle possibilità è inviare notifiche push a questo dispositivo.
Cosa abbiamo fatto per questo?
Abbiamo suddiviso l'applicazione in componenti come: parte admin in JS, backend che opera tramite interfaccia REST sotto Ruby on Rails. Il backend interagisce con il database. Il risultato generato viene restituito al cliente. L'amministrazione interagisce con il backend e il database tramite interfaccia REST.
Abbiamo anche avuto la necessità di inviare notifiche Push. Prima avevamo un progetto in cui era implementato un meccanismo che gestisce la consegna delle notifiche alle piattaforme mobili.
Abbiamo sviluppato il seguente schema: l'operatore dal browser interagisce con l'interfaccia di amministrazione, l'interfaccia di amministrazione interagisce con il backend e si imposta il compito di inviare notifiche Push.
Le notifiche push interagiscono con un altro componente, realizzato su NodeJS.
Si stanno formando delle code e continua il meccanismo di invio delle notifiche.
Qui sono disegnati due database. Attualmente utilizziamo due database indipendenti tramite Docker, che non sono in alcun modo collegati tra loro. A parte il fatto che condividono una rete virtuale, i dati fisici sono memorizzati in directory diverse sulla macchina dello sviluppatore.
Lo stesso ma in cifre. Qui è importante il riutilizzo del codice.
Se in precedenza parlavamo di riutilizzo del codice sotto forma di librerie, in questo esempio il nostro servizio che gestisce le notifiche Push viene riutilizzato come server completo. Fornisce un'API. E con essa interagisce il nostro nuovo sviluppo.
A quel tempo utilizzavamo la versione 4 di NodeJS. Attualmente (nel 2017 — nota dell'editore) nei nuovi sviluppi utilizziamo la versione 7 di NodeJS. Non ci sono problemi a utilizzare nuove versioni di librerie nei nuovi componenti.
Se necessario, possiamo effettuare il refactoring e aggiornare la versione di NodeJS per il servizio di notifiche Push.
E se riusciremo a mantenere la compatibilità con l'API, potremo sostituirlo in altri progetti utilizzati in precedenza.
Cosa serve per aggiungere Docker? Aggiungiamo al nostro repository un Dockerfile, che descrive le dipendenze necessarie. In questo esempio, i componenti sono suddivisi per logica. Questo è il set minimo per un sviluppatore backend.
Quando creiamo un nuovo progetto, creiamo un Dockerfile, descriviamo l'ecosistema necessario (Python, Ruby, NodeJS). In docker-compose, descriviamo la dipendenza necessaria: il database. Indichiamo che abbiamo bisogno di un database di una certa versione, per memorizzare i dati lì.
Utilizziamo un terzo container separato con nginx per servire statiche. È prevista la possibilità di caricare immagini. Il backend le memorizza in un volume predefinito, che è anche montato nel container con nginx, che serve i contenuti statici.
Per memorizzare la configurazione di nginx e mysql, abbiamo aggiunto una cartella Docker, in cui conserviamo le configurazioni necessarie. Quando uno sviluppatore esegue git clone del repository sulla propria macchina, ottiene già un progetto pronto per lo sviluppo locale. Non ci sono domande su quale porta o quali impostazioni applicare.
Successivamente, abbiamo diversi componenti: admin, inform-API, notifiche push.
Per far partire tutto questo, abbiamo creato un ulteriore repository, che abbiamo chiamato dockerized-app. Al momento, utilizziamo diversi repository per ogni componente. Si differenziano solo logicamente: in GitLab appare come una cartella, mentre sulla macchina dello sviluppatore è una cartella per il progetto specifico. A un livello inferiore si trovano i componenti che saranno uniti.
Questo è un esempio del contenuto di dockerized-app. Qui portiamo anche una directory Docker, in cui prepariamo le configurazioni richieste per le interazioni di tutti i componenti. C'è un README.md, in cui è descritto brevemente come avviare il progetto.
Qui abbiamo utilizzato due file docker-compose. Questo è stato fatto per avere la possibilità di avviare in modo graduale. Quando uno sviluppatore lavora con il core, non ha bisogno di notifiche push, quindi avvia semplicemente il file docker-compose e di conseguenza si risparmiano risorse.
Se è necessario integrare le notifiche push, si avviano docker-compose.yaml e docker-compose-push.yaml.
Poiché docker-compose.yaml e docker-compose-push.yaml si trovano nella cartella, viene automaticamente creata una rete virtuale unica.
Descrizione dei componenti. Questo è un file più dettagliato, che è responsabile della raccolta dei componenti. Cosa c'è di interessante qui? Introduciamo il componente bilanciatore.
Questo è un'immagine Docker pronta, in cui viene eseguito nginx e un'applicazione che ascolta il socket Docker. In modo dinamico, all'accensione e allo spegnimento dei container, rigenera la configurazione di nginx. La comunicazione con i componenti è distribuita su nomi di dominio di terzo livello.
Per l'ambiente di sviluppo utilizziamo il dominio .dev — api.informer.dev. Le applicazioni con dominio .dev sono accessibili sulla macchina locale dello sviluppatore.
Poi si trasferiscono le configurazioni per ogni progetto e vengono avviati tutti i progetti insieme contemporaneamente.
Se lo rappresentiamo graficamente, il cliente è il nostro browser o qualche strumento con cui facciamo richieste al bilanciatore.
Il bilanciatore, tramite il nome di dominio, determina a quale container deve indirizzarsi.
Questo può essere nginx, che fornisce l'admin panel JS. Può essere nginx, che fornisce l'API o file statici, che vengono forniti da nginx come immagini da scaricare.
Nello schema si vede che i container sono uniti in una rete virtuale e nascosti dietro un proxy.
Con l'auto dello sviluppatore è possibile accedere al contenitore conoscendo l'IP, ma in linea di massima non lo usiamo. Non si presenta praticamente mai la necessità di un accesso diretto.
Quale esempio guardare per dockerizzare la propria applicazione? A mio parere, un buon esempio è l'immagine ufficiale di Docker per MySQL.
È piuttosto complesso. Ci sono molte versioni. Ma la sua funzionalità consente di coprire molte esigenze che possono sorgere durante lo sviluppo successivo. Se dedichi del tempo a capire come interagisce tutto questo, penso che non avrai problemi nell'implementazione autonoma.
Su hub.docker.com ci sono di solito collegamenti a github.com, dove sono forniti i dati grezzi da cui puoi creare autonomamente l'immagine.
In questo repository c'è anche uno script docker-endpoint.sh, che si occupa dell'inizializzazione iniziale e della gestione successiva dell'avvio dell'applicazione.
In questo esempio c'è anche la possibilità di configurare tramite variabili d'ambiente. Definendo una variabile d'ambiente al momento dell'avvio di un singolo contenitore o tramite docker-compose, puoi dire che dobbiamo impostare una password vuota per Docker per l'utente root in MySQL o una qualsiasi password che preferiamo.
C'è la possibilità di creare una password casuale. Diciamo che abbiamo bisogno di un utente, dobbiamo impostare una password per l'utente e dobbiamo creare un database.
Nei nostri progetti abbiamo un po' uniformato il Dockerfile, che si occupa dell'inizializzazione. L'abbiamo modificato secondo le nostre esigenze per estendere semplicemente i diritti dell'utente utilizzato dall'applicazione. Questo ha permesso poi di creare facilmente un database dalla console dell'applicazione. Nelle applicazioni Ruby ci sono comandi per creare, modificare e cancellare database.
Questo è un esempio di come appare una versione specifica di MySQL su github.com. Puoi aprire il Dockerfile e vedere come avviene l'installazione.
Lo script docker-endpoint.sh è responsabile del punto d'ingresso. Durante l'inizializzazione iniziale sono necessarie alcune azioni di preparazione e tutte queste azioni sono state trasferite nello script di inizializzazione.
Passiamo alla seconda parte.
Per l'archiviazione dei codici sorgente siamo passati a GitLab. È un sistema piuttosto potente che ha un'interfaccia visiva.
Uno dei componenti di GitLab è GitLab CI. Consente di descrivere una sequenza di comandi che saranno successivamente utilizzati per organizzare il sistema di distribuzione del codice o l'esecuzione di test automatici.
Relazione su GitLab CI 2 — relazione del Ruby Russia club — è abbastanza dettagliata e potrebbe interessarti.
Ora esamineremo cosa è necessario per attivare GitLab CI. Per avviare GitLab CI, è sufficiente posizionare un file .gitlab-ci.yml nella radice del progetto.
Qui descriviamo cosa vogliamo eseguire in una sequenza di stati come test e deployment.
Eseguiamo script che invocano direttamente la build della nostra applicazione utilizzando docker-compose. Questo è un esempio di backend.
Poi indichiamo che è necessario eseguire le migrazioni per le modifiche del database e eseguire i test.
Se gli script vengono eseguiti correttamente e non restituiscono codici di errore, il sistema passa alla seconda fase del deployment.
Attualmente, la fase di deployment è implementata per lo staging. Non abbiamo organizzato un riavvio senza interruzioni.
Costringiamo a arrestare tutti i container e poi riavviamo tutti i container che sono stati creati nel primo passo durante il test.
Eseguiamo le migrazioni del database per l'attuale ambiente variabile che sono state scritte dagli sviluppatori.
C'è un'avvertenza che indica di applicarlo solo per il ramo master.
Non viene eseguito con altre modifiche di ramo.
C'è la possibilità di organizzare i rilasci per ramo.
Per procedere in tal senso, dobbiamo installare GitLab Runner.
Questo strumento è scritto in Golang. È un singolo file, come di consueto nel mondo di Golang, che non richiede dipendenze.
All'avvio registriamo GitLab Runner.
Riceviamo la chiave nell'interfaccia web di GitLab.
Poi invochiamo il comando di inizializzazione nella riga di comando.
Configuriamo GitLab Runner in modalità dialogo (Shell, Docker, VirtualBox, SSH)
Il codice su GitLab Runner verrà eseguito ad ogni commit in base alla configurazione di .gitlab-ci.yml.
Ecco come appare visivamente in GitLab nell'interfaccia web. Dopo aver collegato GitLab CI, appare una bandiera che indica lo stato attuale della build.
Vediamo che 4 minuti fa è stato effettuato un commit che ha superato tutti i test senza problemi.
Possiamo esaminare più dettagliatamente i build. Qui vediamo che sono già trascorsi due stati: lo stato di testing e lo stato di deploy su staging.
Se clicchiamo su un build specifico, vedremo l'output della console dei comandi che sono stati eseguiti nel processo secondo il file .gitlab-ci.yml.
Ecco come appare la storia del nostro prodotto. Possiamo vedere che ci sono stati tentativi riusciti. Quando i test falliscono, non si passa al passaggio successivo e il codice su staging non viene aggiornato.
Quali problemi abbiamo risolto su staging quando abbiamo implementato Docker? La nostra sistema è composta da diversi componenti e abbiamo dovuto riavviare solo alcune parti dei componenti che erano stati aggiornati nel repository, e non l'intero sistema.
Per questo abbiamo dovuto separare tutto in cartelle distinte.
Dopo aver fatto ciò, abbiamo riscontrato un problema: Docker-compose crea per ogni cartella un proprio spazio di rete e non riesce a vedere i componenti vicini.
Per aggirare questo, abbiamo creato manualmente una rete in Docker. Nel Docker-compose abbiamo specificato di utilizzare questa rete per il progetto.
In questo modo, ogni componente che avvia con questa rete vede i componenti in altre parti del sistema.
Il problema successivo è stata la separazione dello staging tra diversi progetti.
Poiché per far sembrare tutto elegante e il più vicino possibile alla produzione, è bene utilizzare le porte 80 o 443, che sono comuni nel WEB.
Come abbiamo risolto questo? Abbiamo assegnato un solo Gitlab Runner a tutti i grandi progetti.
Gitlab consente di avviare più Gitlab Runner distribuiti, che prenderanno semplicemente tutti i lavori in modo casuale e li eseguiranno.
Per evitare il caos, abbiamo limitato il gruppo dei nostri progetti a un solo Gitlab Runner, che riesce a gestire i nostri carichi senza problemi.
Abbiamo esternalizzato nginx-proxy in uno script di avvio separato e abbiamo descritto le reti di tutti i progetti in esso.
Il nostro progetto ha una rete, mentre il bilanciatore ha più reti denominate con i nomi dei progetti. Può fare proxy ulteriori per i nomi di dominio.
Le richieste arrivano per dominio sulla porta 80 e vengono gestite in un gruppo di contenitori che servono questo dominio.
Quali ulteriori problemi ci sono stati? Il fatto che per impostazione predefinita tutti i contenitori vengono eseguiti come utente root. Questo root è diverso dal root dell'host del sistema.
Tuttavia, se si entra nel contenitore, questo diventerà root e il file che creiamo in questo contenitore avrà i diritti di root.
Se uno sviluppatore è entrato nel contenitore e ha eseguito alcuni comandi che generano file, poi è uscito dal contenitore, nella sua directory di lavoro avrà un file a cui non ha accesso.
Come possiamo risolvere questo problema? Possiamo aggiungere utenti che saranno nel contenitore.
Quali problemi sono emersi quando abbiamo aggiunto un utente?
Creando un utente, spesso non coincidono l'ID del gruppo (UID) e l'ID dell'utente (GID).
Per risolvere questo problema nel contenitore utilizziamo utenti con ID 1000.
Nel nostro caso, questo coincide con il fatto che praticamente tutti gli sviluppatori utilizzano il sistema operativo Ubuntu. E su Ubuntu, il primo utente ha ID 1000.
Quali sono i nostri piani?
Rileggere la documentazione su Docker. Il progetto si sta sviluppando attivamente, la documentazione cambia. I dati ottenuti due-tre mesi fa stanno già cominciando a diventare obsoleti.
Alcuni dei problemi che abbiamo risolto sono già stati probabilmente risolti con strumenti standard.
Ho molta voglia di andare avanti e passare direttamente all'orchestrazione.
Uno dei esempi è il meccanismo integrato in Docker chiamato Docker Swarm, che è fornito di default. Vorrei avviare qualcosa in produzione basato sulla tecnologia Docker Swarm.
La generazione di contenitori rende scomodo lavorare con i log. Attualmente, i log sono isolati. Sono sparsi tra i contenitori. Una delle sfide è rendere l'accesso ai log semplice tramite un'interfaccia web.
Fonte: habr.com
