Propongo di leggere la trascrizione del rapporto di Alexander Sigachev di Inventos "Processo di sviluppo e test con Docker + Gitlab CI"
Coloro che stanno appena iniziando a implementare il processo di sviluppo e test basato su Docker + Gitlab CI spesso pongono domande di base. Da dove cominciare? Come organizzare? Come testare?
Questo rapporto è utile perché parla in modo strutturato del processo di sviluppo e test utilizzando Docker e Gitlab CI. Il rapporto stesso è del 2017. Penso che da questo rapporto si possano apprendere le basi, la metodologia, l'idea, l'esperienza d'uso.
Chi se ne frega, per favore sotto il gatto.
Mi chiamo Alexander Sigachev. Lavoro per Inventos. Ti racconterò della mia esperienza nell'uso di Docker e di come lo stiamo gradualmente implementando sui progetti in azienda.
Argomento della presentazione: Processo di sviluppo utilizzando Docker e Gitlab CI.
Questo è il mio secondo discorso su Docker. Al momento della prima segnalazione, abbiamo utilizzato Docker solo in fase di sviluppo sui computer degli sviluppatori. Il numero di dipendenti che utilizzava Docker era di circa 2-3 persone. A poco a poco, l'esperienza è stata acquisita e ci siamo spostati un po' oltre. Collegati al nostro .
Cosa ci sarà in questo rapporto? Condivideremo la nostra esperienza su quale rastrello abbiamo raccolto, quali problemi abbiamo risolto. Non dappertutto era bello, ma permetteva di andare avanti.
Il nostro motto è: attracca tutto ciò su cui riusciamo a mettere le mani.
Quali problemi stiamo risolvendo?
Quando ci sono più team in un'azienda, il programmatore è una risorsa condivisa. Ci sono fasi in cui un programmatore viene ritirato da un progetto e assegnato per un po 'di tempo a un altro progetto.
Affinché il programmatore possa capire rapidamente, deve scaricare il codice sorgente del progetto e avviare l'ambiente il prima possibile, il che gli consentirà di andare oltre risolvendo i problemi di questo progetto.
Di solito, se inizi da zero, c'è poca documentazione nel progetto. Le informazioni su come impostare sono disponibili solo per i veterani. I dipendenti installano il proprio posto di lavoro da soli in uno o due giorni. Per velocizzare questo processo, abbiamo utilizzato Docker.
Il motivo successivo è la standardizzazione delle impostazioni in Sviluppo. Nella mia esperienza, gli sviluppatori prendono sempre l'iniziativa. In ogni quinto caso, viene inserito un dominio personalizzato, ad esempio vasya.dev. Seduto accanto a lui c'è il suo vicino Petya, il cui dominio è petya.dev. Sviluppano un sito Web o qualche componente del sistema utilizzando questo nome di dominio.
Quando il sistema cresce e questi nomi di dominio iniziano a entrare nelle configurazioni, si verifica un conflitto dell'ambiente di sviluppo e il percorso del sito viene riscritto.
Lo stesso accade con le impostazioni del database. Qualcuno non si preoccupa della sicurezza e lavora con una password di root vuota. In fase di installazione, MySQL ha chiesto a qualcuno una password e la password si è rivelata 123. Accade spesso che la configurazione del database cambi costantemente a seconda del commit dello sviluppatore. Qualcuno ha corretto, qualcuno non ha corretto la configurazione. Ci sono stati dei trucchi quando abbiamo inserito una sorta di configurazione di prova .gitignore e ogni sviluppatore doveva installare il database. Questo ha reso difficile iniziare. È necessario, tra le altre cose, ricordare del database. Il database deve essere inizializzato, deve essere inserita una password, deve essere registrato un utente, deve essere creata una tabella e così via.
Un altro problema sono le diverse versioni delle librerie. Accade spesso che uno sviluppatore lavori con progetti diversi. C'è un progetto Legacy che è partito cinque anni fa (dal 2017 - ndr). Al momento del lancio, abbiamo iniziato con MySQL 5.5. Esistono anche progetti moderni in cui cerchiamo di implementare versioni più moderne di MySQL, ad esempio 5.7 o precedenti (nel 2017 - ndr)
Chiunque lavori con MySQL sa che queste librerie portano con sé delle dipendenze. È piuttosto problematico eseguire 2 basi insieme. Almeno, i vecchi client sono problematici per connettersi al nuovo database. Questo a sua volta crea diversi problemi.
Il problema successivo è quando uno sviluppatore lavora su una macchina locale, utilizza risorse locali, file locali, RAM locale. Tutta l'interazione al momento dello sviluppo di una soluzione ai problemi viene effettuata nell'ambito del fatto che funziona su una macchina. Un esempio è quando abbiamo server back-end in Production 3 e lo sviluppatore salva i file nella directory principale e da lì nginx prende i file per rispondere alla richiesta. Quando un tale codice entra in Produzione, si scopre che il file è presente su uno dei 3 server.
La direzione dei microservizi si sta sviluppando ora. Quando dividiamo le nostre grandi applicazioni in alcuni piccoli componenti che interagiscono tra loro. Ciò consente di selezionare le tecnologie per uno specifico stack di attività. Consente inoltre di condividere il lavoro e le responsabilità tra gli sviluppatori.
Lo sviluppatore di Frondand, che sviluppa su JS, non ha quasi alcuna influenza su Backend. Lo sviluppatore di backend, a sua volta, sviluppa, nel nostro caso, Ruby on Rails e non interferisce con Frendend. L'interazione viene eseguita utilizzando l'API.
Come bonus, con l'aiuto di Docker, siamo stati in grado di riciclare le risorse su Staging. Ogni progetto, per le sue specificità, richiedeva determinate impostazioni. Fisicamente, era necessario allocare un server virtuale e configurarli separatamente, oppure condividere una sorta di ambiente variabile e i progetti potevano, a seconda della versione delle librerie, influenzarsi a vicenda.
Utensili. Cosa usiamo?
- Docker stesso. Il Dockerfile descrive le dipendenze di una singola applicazione.
- Docker-compose è un pacchetto che riunisce alcune delle nostre applicazioni Docker.
- Usiamo GitLab per archiviare il codice sorgente.
- Utilizziamo GitLab-CI per l'integrazione di sistema.
Il rapporto si compone di due parti.
La prima parte parlerà di come Docker è stato eseguito sulle macchine degli sviluppatori.
La seconda parte parlerà di come interagire con GitLab, come eseguiamo i test e come passiamo a Staging.
Docker è una tecnologia che consente (utilizzando un approccio dichiarativo) di descrivere i componenti necessari. Questo è un Dockerfile di esempio. Qui dichiariamo che stiamo ereditando dall'immagine Docker ufficiale di Ruby:2.3.0. Contiene Ruby versione 2.3 installata. Installiamo le librerie di build richieste e NodeJS. Descriviamo che creiamo una directory /app. Imposta la directory dell'app come directory di lavoro. In questa directory inseriamo il Gemfile minimo richiesto e Gemfile.lock. Quindi creiamo i progetti che installano questa immagine di dipendenza. Indichiamo che il contenitore sarà pronto per l'ascolto sulla porta esterna 3000. L'ultimo comando è il comando che avvia direttamente la nostra applicazione. Se eseguiamo il comando di avvio del progetto, l'applicazione tenterà di eseguire ed eseguire il comando specificato.
Questo è un esempio minimo di file docker-compose. In questo caso, mostriamo che esiste una connessione tra due contenitori. Questo è direttamente nel servizio di database e nel servizio web. Le nostre applicazioni web nella maggior parte dei casi richiedono una sorta di database come back-end per l'archiviazione dei dati. Poiché stiamo utilizzando MySQL, l'esempio è con MySQL, ma nulla ci impedisce di utilizzare qualche altro database (PostgreSQL, Redis).
Prendiamo dalla fonte ufficiale dell'hub Docker l'immagine di MySQL 5.7.14 senza modifiche. Raccogliamo l'immagine responsabile della nostra applicazione web dalla directory corrente. Raccoglie un'immagine per noi durante il primo lancio. Quindi esegue il comando che stiamo eseguendo qui. Se torniamo indietro, vedremo che è stato definito il comando di lancio tramite Puma. Puma è un servizio scritto in Ruby. Nel secondo caso, eseguiamo l'override. Questo comando può essere arbitrario a seconda delle nostre esigenze o attività.
Descriviamo anche che dobbiamo inoltrare una porta sulla nostra macchina host per sviluppatori da 3000 a 3000 sulla porta del contenitore. Questo viene fatto automaticamente usando iptables e il suo meccanismo, che è direttamente incorporato in Docker.
Lo sviluppatore può anche, come prima, accedere a qualsiasi indirizzo IP disponibile, ad esempio 127.0.0.1 è l'indirizzo IP locale o esterno della macchina.
L'ultima riga dice che il contenitore web dipende dal contenitore db. Quando chiamiamo l'inizio del contenitore Web, docker-compose avvierà prima il database per noi. Già all'avvio del database (anzi, dopo il lancio del contenitore! Questo non garantisce la prontezza del database) lancerà l'applicazione, il nostro backend.
Ciò evita errori quando il database non è attivo e risparmia risorse quando fermiamo il contenitore del database, liberando così risorse per altri progetti.
Cosa ci dà l'uso della dockerizzazione del database sul progetto. Correggiamo la versione di MySQL per tutti gli sviluppatori. Questo evita alcuni errori che possono verificarsi quando le versioni divergono, quando la sintassi, la configurazione, le impostazioni predefinite cambiano. Ciò consente di specificare un nome host comune per il database, il login e la password. Ci stiamo allontanando dallo zoo di nomi e conflitti nei file di configurazione che avevamo in precedenza.
Abbiamo l'opportunità di utilizzare una configurazione più ottimale per l'ambiente di sviluppo, che differirà da quella predefinita. MySQL è configurato per macchine deboli per impostazione predefinita e le sue prestazioni sono molto scarse.
Docker ti consente di utilizzare l'interprete Python, Ruby, NodeJS, PHP della versione desiderata. Eliminiamo la necessità di utilizzare una sorta di gestore di versione. In precedenza, Ruby utilizzava un pacchetto rpm che permetteva di modificare la versione a seconda del progetto. Consente inoltre, grazie al contenitore Docker, di migrare senza problemi il codice e la versione insieme alle dipendenze. Non abbiamo problemi a capire la versione sia dell'interprete che del codice. Per aggiornare la versione, abbassare il vecchio contenitore e sollevare il nuovo contenitore. Se qualcosa è andato storto, possiamo abbassare il nuovo container, alzare il vecchio container.
Dopo aver creato l'immagine, i contenitori in Sviluppo e Produzione saranno gli stessi. Ciò è particolarmente vero per le grandi installazioni.
Sul Frontend utilizziamo JavaScipt e NodeJS.
Ora abbiamo l'ultimo progetto su ReacJS. Lo sviluppatore ha eseguito tutto nel contenitore e sviluppato utilizzando il ricaricamento a caldo.
Successivamente, viene avviata l'attività di assemblaggio JavaScipt e il codice compilato in statica viene fornito tramite il salvataggio delle risorse di nginx.
Qui ho riportato lo schema del nostro ultimo progetto.
Quali compiti sono stati risolti? Avevamo bisogno di creare un sistema con cui interagire con i dispositivi mobili. Ricevono dati. Una possibilità è inviare notifiche push a questo dispositivo.
Cosa abbiamo fatto per questo?
Abbiamo suddiviso nell'applicazione componenti come: la parte amministrativa su JS, il backend, che funziona tramite l'interfaccia REST sotto Ruby on Rails. Il back-end interagisce con il database. Il risultato generato viene fornito al client. Il pannello di amministrazione interagisce con il backend e il database tramite l'interfaccia REST.
Avevamo anche la necessità di inviare notifiche push. Prima di allora, avevamo un progetto che implementava un meccanismo responsabile della consegna delle notifiche alle piattaforme mobili.
Abbiamo sviluppato il seguente schema: un operatore dal browser interagisce con il pannello di amministrazione, il pannello di amministrazione interagisce con il backend, il compito è inviare notifiche push.
Le notifiche push interagiscono con un altro componente implementato in NodeJS.
Le code vengono create e quindi le notifiche vengono inviate in base al loro meccanismo.
Qui vengono disegnati due database. Al momento, con l'aiuto di Docker, utilizziamo 2 database indipendenti che non sono in alcun modo correlati tra loro. Inoltre, dispongono di una rete virtuale comune e i dati fisici vengono archiviati in diverse directory sulla macchina dello sviluppatore.
Lo stesso ma in numeri. È qui che il riutilizzo del codice è importante.
Se prima abbiamo parlato del riutilizzo del codice sotto forma di librerie, in questo esempio il nostro servizio che risponde alle notifiche push viene riutilizzato come un server completo. Fornisce un'API. E il nostro nuovo sviluppo interagisce già con esso.
A quel tempo, stavamo usando la versione 4 di NodeJS. Ora (nel 2017 - ndr) nei recenti sviluppi utilizziamo la versione 7 di NodeJS. Non c'è alcun problema nei nuovi componenti per coinvolgere nuove versioni di librerie.
Se necessario, puoi eseguire il refactoring e aumentare la versione di NodeJS dal servizio di notifica push.
E se riusciamo a mantenere la compatibilità dell'API, sarà possibile sostituirla con altri progetti precedentemente utilizzati.
Di cosa hai bisogno per aggiungere Docker? Aggiungiamo un Dockerfile al nostro repository, che descrive le dipendenze necessarie. In questo esempio, i componenti sono suddivisi in modo logico. Questo è il set minimo di uno sviluppatore back-end.
Quando creiamo un nuovo progetto, creiamo un Dockerfile, descriviamo l'ecosistema desiderato (Python, Ruby, NodeJS). In docker-compose, descrive la dipendenza necessaria: il database. Descriviamo che abbiamo bisogno di un database di tale e tale versione, memorizzare i dati qua e là.
Usiamo un terzo contenitore separato con nginx per servire statico. È possibile caricare immagini. Il backend li inserisce in un volume pre-preparato, anch'esso montato in un contenitore con nginx, che fornisce la staticità.
Per archiviare la configurazione di nginx, mysql, abbiamo aggiunto una cartella Docker in cui archiviamo le configurazioni necessarie. Quando uno sviluppatore esegue un clone git di un repository sulla sua macchina, ha già un progetto pronto per lo sviluppo locale. Non c'è dubbio su quale porta o quali impostazioni applicare.
Successivamente, abbiamo diversi componenti: admin, inform-API, notifiche push.
Per iniziare tutto questo, abbiamo creato un altro repository, che abbiamo chiamato dockerized-app. Al momento utilizziamo diversi repository prima di ogni componente. Sono solo logicamente diversi: in GitLab sembra una cartella, ma sulla macchina dello sviluppatore, una cartella per un progetto specifico. Un livello in basso sono i componenti che verranno combinati.
Questo è un esempio dei soli contenuti di dockerized-app. Portiamo qui anche la directory Docker, in cui compiliamo le configurazioni richieste per le interazioni di tutti i componenti. C'è un file README.md che descrive brevemente come eseguire il progetto.
Qui abbiamo applicato due file docker-compose. Questo viene fatto per poter eseguire i passaggi. Quando uno sviluppatore lavora con il core, non ha bisogno di notifiche push, avvia semplicemente un file di composizione docker e, di conseguenza, la risorsa viene salvata.
Se è necessario integrare con le notifiche push, vengono avviati docker-compose.yaml e docker-compose-push.yaml.
Poiché docker-compose.yaml e docker-compose-push.yaml si trovano in una cartella, viene creata automaticamente una singola rete virtuale.
Descrizione dei componenti. Questo è un file più avanzato che è responsabile della raccolta di componenti. Cosa c'è di straordinario qui? Qui introduciamo il componente bilanciatore.
Si tratta di un'immagine Docker già pronta che esegue nginx e un'applicazione in ascolto sul socket Docker. Dinamico, quando i contenitori vengono attivati e disattivati, rigenera la configurazione di nginx. Distribuiamo la gestione dei componenti tramite nomi a dominio di terzo livello.
Per l'ambiente di sviluppo, utilizziamo il dominio .dev - api.informer.dev. Le applicazioni con un dominio .dev sono disponibili sul computer locale dello sviluppatore.
Inoltre, le configurazioni vengono trasferite a ciascun progetto e tutti i progetti vengono avviati insieme contemporaneamente.
Graficamente, risulta che il client è il nostro browser o qualche strumento con cui facciamo richieste al bilanciatore.
Il bilanciatore del nome di dominio determina quale contenitore contattare.
Può essere nginx, che fornisce all'amministratore JS. Questo può essere nginx, che fornisce l'API, o file statici, che vengono forniti a nginx sotto forma di caricamenti di immagini.
Il diagramma mostra che i contenitori sono connessi da una rete virtuale e nascosti dietro un proxy.
Sulla macchina dello sviluppatore, puoi accedere al contenitore conoscendo l'IP, ma in linea di principio non lo usiamo. Non è praticamente necessario un accesso diretto.
Quale esempio guardare per dockerizzare la tua applicazione? A mio parere, un buon esempio è l'immagine docker ufficiale per MySQL.
È piuttosto impegnativo. Ci sono molte versioni. Ma la sua funzionalità consente di coprire molte esigenze che possono sorgere nel processo di ulteriore sviluppo. Se dedichi del tempo e capisci come tutto interagisce, allora penso che non avrai problemi nell'auto-implementazione.
Hub.docker.com di solito contiene collegamenti a github.com, che contiene dati grezzi direttamente dai quali è possibile creare l'immagine da soli.
Inoltre in questo repository è presente uno script docker-endpoint.sh, che è responsabile dell'inizializzazione iniziale e dell'ulteriore elaborazione dell'avvio dell'applicazione.
Anche in questo esempio, c'è la possibilità di configurare utilizzando le variabili di ambiente. Definendo una variabile di ambiente durante l'esecuzione di un singolo contenitore o tramite docker-compose, possiamo dire che dobbiamo impostare una password vuota per docker per eseguire il root su MySQL o qualsiasi altra cosa vogliamo.
C'è un'opzione per 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 leggermente unificato il Dockerfile, che è responsabile dell'inizializzazione. Lì l'abbiamo corretto in base alle nostre esigenze per renderlo solo un'estensione dei diritti utente utilizzati dall'applicazione. Questo ci ha permesso di creare semplicemente un database dalla console dell'applicazione in un secondo momento. Le applicazioni Ruby hanno un comando per creare, modificare ed eliminare i database.
Questo è un esempio di come appare una versione specifica di MySQL su github.com. Puoi aprire il Dockerfile e vedere come sta andando l'installazione lì.
docker-endpoint.sh è lo script responsabile del punto di ingresso. Durante l'inizializzazione iniziale, sono necessarie alcune fasi di preparazione e tutte queste azioni vengono eseguite solo nello script di inizializzazione.
Passiamo alla seconda parte.
Per memorizzare i codici sorgente, siamo passati a gitlab. Questo è un sistema abbastanza potente che ha un'interfaccia visiva.
Uno dei componenti di Gitlab è Gitlab CI. Ti consente di descrivere una sequenza di comandi che verranno successivamente utilizzati per organizzare un sistema di consegna del codice o eseguire test automatici.
Discussione su Gitlab CI 2 - rapporto del club Ruby Russia - abbastanza dettagliato e forse ti interesserà.
Ora vedremo cosa è necessario per attivare Gitlab CI. Per avviare Gitlab CI, dobbiamo solo inserire il file .gitlab-ci.yml nella root del progetto.
Qui descriviamo che vogliamo eseguire una sequenza di stati come un test, deploy.
Eseguiamo script che chiamano direttamente docker-compose per costruire la nostra applicazione. Questo è solo un esempio di back-end.
Successivamente, diciamo che è necessario eseguire le migrazioni per modificare il database ed eseguire i test.
Se gli script vengono eseguiti correttamente e non restituisce un codice di errore, il sistema procede alla seconda fase della distribuzione.
La fase di distribuzione è attualmente implementata per la gestione temporanea. Non abbiamo organizzato un riavvio senza tempi di inattività.
Spegniamo con la forza tutti i contenitori, quindi solleviamo nuovamente tutti i contenitori, raccolti nella prima fase durante i test.
Stiamo eseguendo per la variabile di ambiente corrente le migrazioni del database che sono state scritte dagli sviluppatori.
C'è una nota che questo si applica solo al ramo principale.
Quando si cambiano altri rami non viene eseguito.
È possibile organizzare i rollout per filiali.
Per organizzarlo ulteriormente, dobbiamo installare Gitlab Runner.
Questa utilità è scritta in Golang. È un singolo file, come è comune nel mondo Golang, che non richiede dipendenze.
All'avvio, registriamo Gitlab Runner.
Otteniamo la chiave nell'interfaccia web di Gitlab.
Quindi chiamiamo il comando di inizializzazione sulla riga di comando.
Configura Gitlab Runner in modo interattivo (Shell, Docker, VirtualBox, SSH)
Il codice su Gitlab Runner verrà eseguito a ogni commit, a seconda dell'impostazione .gitlab-ci.yml.
Come appare visivamente in Gitlab nell'interfaccia web. Dopo aver connesso GItlab CI, abbiamo un flag che mostra lo stato della build al momento.
Vediamo che 4 minuti fa è stato effettuato un commit, che ha superato tutti i test e non ha causato alcun problema.
Possiamo dare un'occhiata più da vicino alle build. Qui vediamo che due stati sono già passati. Stato del test e stato della distribuzione durante la gestione temporanea.
Se facciamo clic su una build specifica, ci sarà un output della console dei comandi che sono stati eseguiti nel processo secondo .gitlab-ci.yml.
Ecco com'è la storia del nostro prodotto. Vediamo che ci sono stati tentativi riusciti. Quando i test vengono inviati, non si procede al passaggio successivo e il codice di staging non viene aggiornato.
Quali compiti abbiamo risolto durante lo staging quando abbiamo implementato la finestra mobile? Il nostro sistema è composto da componenti e abbiamo avuto la necessità di riavviare, solo una parte dei componenti che sono stati aggiornati nel repository e non l'intero sistema.
Per fare questo, abbiamo dovuto distruggere tutto in cartelle separate.
Dopo averlo fatto, abbiamo riscontrato un problema con il fatto che Docker-compose crea il proprio spazio di rete per ogni papà e non vede i componenti del vicino.
Per spostarci, abbiamo creato manualmente la rete in Docker. È stato scritto in Docker-compose che utilizzi una tale rete per questo progetto.
Pertanto, ogni componente che inizia con questa mesh vede componenti in altre parti del sistema.
Il problema successivo è la suddivisione dello staging su più progetti.
Poiché affinché tutto ciò appaia bello e il più vicino possibile alla produzione, è bene utilizzare la porta 80 o 443, che viene utilizzata ovunque nel WEB.
Come l'abbiamo risolto? Abbiamo assegnato un Gitlab Runner a tutti i progetti principali.
Gitlab ti consente di eseguire diversi Gitlab Runner distribuiti, che prenderanno semplicemente tutte le attività a turno in modo caotico e le eseguiranno.
Per non avere una casa, abbiamo limitato il gruppo dei nostri progetti a un Gitlab Runner, che affronta senza problemi i nostri volumi.
Abbiamo spostato nginx-proxy in uno script di avvio separato e aggiunto griglie per tutti i progetti in esso contenuti.
Il nostro progetto ha una griglia e il bilanciatore ha diverse griglie in base ai nomi dei progetti. Può delegare ulteriormente i nomi di dominio.
Le nostre richieste arrivano attraverso il dominio sulla porta 80 e vengono risolte in un gruppo di contenitori che serve questo dominio.
Quali altri problemi c'erano? Questo è ciò che tutti i contenitori vengono eseguiti come root per impostazione predefinita. Questo è root diverso dall'host root del sistema.
Tuttavia, se entri nel contenitore, sarà root e il file che creiamo in questo contenitore ottiene i diritti di root.
Se lo sviluppatore è entrato nel contenitore e ha eseguito alcuni comandi che generano file, quindi ha lasciato il contenitore, allora ha un file nella sua directory di lavoro a cui non ha accesso.
Come può essere risolto? Puoi aggiungere utenti che saranno nel contenitore.
Quali problemi sono sorti quando abbiamo aggiunto l'utente?
Quando creiamo un utente, spesso non abbiamo lo stesso ID gruppo (UID) e ID utente (GID).
Per risolvere questo problema nel contenitore, utilizziamo gli utenti con ID 1000.
Nel nostro caso, ciò ha coinciso con il fatto che quasi tutti gli sviluppatori utilizzano il sistema operativo Ubuntu. E su Ubuntu, il primo utente ha un ID di 1000.
Abbiamo piani?
Leggi la documentazione di Docker. Il progetto si sta sviluppando attivamente, la documentazione sta cambiando. I dati ricevuti due o tre mesi fa stanno già lentamente diventando obsoleti.
Alcuni dei problemi che abbiamo risolto sono molto probabilmente già risolti con mezzi standard.
Quindi voglio già andare oltre per andare direttamente all'orchestrazione.
Un esempio è il meccanismo integrato di Docker chiamato Docker Swarm, che esce dalla scatola. Voglio eseguire qualcosa in produzione basato sulla tecnologia Docker Swarm.
La generazione di contenitori rende scomodo lavorare con i registri. Ora i tronchi sono isolati. Sono sparsi in contenitori. Uno dei compiti è rendere comodo l'accesso ai registri tramite l'interfaccia web.
Fonte: habr.com