In qualche modo a un certo punto ho deciso di scrivere un articolo sulla consegna sotto forma di contenitori Docker e pacchetti deb, ma quando ho iniziato, per qualche motivo sono stato riportato ai tempi lontani dei primi personal computer e persino dei calcolatori. In generale, invece di aridi confronti tra docker e deb, abbiamo questi pensieri sul tema dell'evoluzione, che presento alla vostra considerazione.
Qualsiasi prodotto, qualunque esso sia, deve in qualche modo arrivare ai server del prodotto, deve essere configurato e avviato. Ecco di cosa parlerà questo articolo.
Penserò in un contesto storico, "ciò che vedo è ciò di cui canto", cosa ho visto quando ho iniziato a scrivere codice e cosa osservo ora, cosa stiamo usando noi stessi in questo momento e perché. L'articolo non pretende di essere uno studio a tutti gli effetti, mancano alcuni punti, questa è la mia visione personale di cosa era e cosa è adesso.
Quindi, ai bei vecchi tempi... il primo metodo di consegna che ho trovato erano le cassette dei registratori. Avevo un computer BK-0010.01...
L'era dei calcolatori
No, c'è stato un momento ancora precedente, c'era anche la calcolatrice и .
Quindi quando ho avuto , allora il modo per trasferire il programma era un normale pezzo di carta in una scatola su cui era scritto un programma, che, se necessario, per eseguirlo manualmente, veniva scritto nella calcolatrice. Se vuoi giocare (sì, anche questa calcolatrice antidiluviana aveva dei giochi), ti siedi e inserisci il programma nella calcolatrice. Naturalmente, quando la calcolatrice è stata spenta, il programma è scomparso nell'oblio. Oltre ai codici dei calcolatori scritti personalmente su carta, i programmi furono pubblicati sulle riviste “Radio” e “Technology for Youth”, e furono pubblicati anche in libri dell'epoca.
La modifica successiva è stata una calcolatrice , ha già una parvenza di archiviazione di dati non volatile. Ora il gioco o il programma non dovevano essere inseriti manualmente, ma dopo aver eseguito alcuni passaggi magici con i pulsanti, si caricavano da soli.
La dimensione del programma più grande nella calcolatrice era di 105 passi e la dimensione della memoria permanente dell'MK-52 era di 512 passi.
A proposito, se ci sono fan di queste calcolatrici che stanno leggendo questo articolo, durante la stesura dell'articolo ho trovato sia un emulatore di calcolatrice per Android che programmi per esso. Avanti nel passato!
Una breve digressione sull'MK-52 (da Wikipedia)
L'MK-52 volò nello spazio a bordo della navicella spaziale Soyuz TM-7. Doveva essere utilizzato per calcolare la traiettoria di atterraggio nel caso in cui il computer di bordo si fosse guastato.
Dal 52, l'MK-1988 con l'unità di espansione della memoria Elektronika-Astro viene fornito alle navi della Marina come parte di un kit di calcolo per la navigazione.
I primi personal computer
Torniamo ai tempi . È chiaro che lì c'era più memoria e digitare il codice da un pezzo di carta non era più un'opzione (anche se all'inizio lo facevo proprio, perché semplicemente non c'erano altri mezzi). Le cassette audio per registratori stanno diventando il mezzo principale per archiviare e distribuire software.
L'archiviazione su una cassetta era solitamente sotto forma di uno o due file binari, tutto il resto era contenuto all'interno. L'affidabilità era molto bassa, dovevo conservare 2-3 copie del programma. Anche i tempi di caricamento sono stati deludenti e gli appassionati hanno sperimentato diverse codifiche di frequenza per superare queste carenze. A quel tempo io stesso non ero ancora coinvolto nello sviluppo di software professionale (senza contare i semplici programmi in BASIC), quindi, purtroppo, non vi racconterò in dettaglio come era organizzato tutto all'interno. Il fatto stesso che il computer avesse per la maggior parte solo RAM ha determinato la semplicità dello schema di archiviazione dei dati.
L'emergere di supporti di memorizzazione affidabili e di grandi dimensioni
Successivamente sono comparsi i floppy disk, il processo di copia è stato semplificato e l'affidabilità è aumentata.
Ma la situazione cambia radicalmente solo quando compaiono archivi locali sufficientemente grandi sotto forma di HDD.
Il tipo di consegna sta cambiando radicalmente: compaiono programmi di installazione che gestiscono il processo di configurazione del sistema, nonché la pulizia dopo la rimozione, poiché i programmi non vengono solo letti in memoria, ma vengono già copiati nella memoria locale, dalla quale è necessario essere in grado di eliminare cose inutili, se necessario.
Allo stesso tempo aumenta la complessità del software fornito.
Il numero di file nella consegna aumenta da pochi a centinaia e migliaia, i conflitti tra le versioni della libreria e altre gioie iniziano quando diversi programmi utilizzano gli stessi dati.
A quel tempo l’esistenza di Linux non era ancora aperta per me; vivevo nel mondo di MS DOS e, più tardi, di Windows, e scrivevo in Borland Pascal e Delphi, a volte guardando al C++. All'epoca molte persone utilizzavano InstallShield per fornire prodotti. , che ha risolto con successo tutti i compiti assegnati di distribuzione e configurazione del software.
Era di Internet
A poco a poco, la complessità dei sistemi software sta diventando ancora più complessa; dalle applicazioni monolitiche e desktop si passa ai sistemi distribuiti, ai thin client e ai microservizi. Ora devi configurare non solo un programma, ma un insieme di essi e in modo che funzionino tutti insieme.
Il concetto è completamente cambiato, è arrivata Internet, è arrivata l’era dei servizi cloud. Finora, solo nella fase iniziale, sotto forma di siti web, nessuno ha particolarmente sognato servizi. ma è stato un punto di svolta sia nello sviluppo che nella distribuzione delle applicazioni.
Per quanto mi riguarda, ho notato che in quel momento c'era un cambiamento nelle generazioni di sviluppatori (o era solo nel mio ambiente), e c'era la sensazione che tutti i buoni vecchi metodi di consegna fossero stati dimenticati in un momento e tutto iniziò proprio dal inizio: tutta la consegna cominciò a essere eseguita con script in ginocchio e la chiamò con orgoglio "Consegna continua". In effetti, è iniziato un periodo di caos, in cui il vecchio viene dimenticato e non utilizzato, e il nuovo semplicemente non esiste.
Ricordo i tempi in cui nella nostra azienda dove lavoravo allora (non la nominerò), invece di costruire tramite formica (maven non era ancora popolare o non esisteva affatto), le persone semplicemente raccoglievano barattoli nell'IDE e si impegnavano serenamente in SVN. Di conseguenza, la distribuzione consisteva nel recuperare il file da SVN e copiarlo tramite SSH sulla macchina desiderata. È così semplice e goffo.
Allo stesso tempo, la consegna di siti semplici in PHP veniva effettuata in modo molto primitivo semplicemente copiando il file corretto tramite FTP sulla macchina di destinazione. A volte non era così: il codice veniva modificato in tempo reale sul server del prodotto ed era particolarmente elegante se da qualche parte c'erano dei backup.
Pacchetti RPM e DEB
D'altra parte, con lo sviluppo di Internet, i sistemi simili a UNIX iniziarono a guadagnare sempre più popolarità, in particolare fu in quel periodo che scoprii RedHat Linux 6, intorno al 2000. Naturalmente c'erano anche alcuni mezzi per la distribuzione del software; secondo Wikipedia RPM come principale gestore di pacchetti è apparso già nel 1995 nella versione RedHat Linux 2.0. E da allora fino ad oggi, il sistema è stato fornito sotto forma di pacchetti RPM ed è stato esistente e sviluppato con successo.
Le distribuzioni della famiglia Debian hanno seguito un percorso simile e hanno implementato la distribuzione sotto forma di pacchetti deb, che è rimasta invariata fino ad oggi.
I gestori di pacchetti consentono di fornire i prodotti software stessi, configurarli durante il processo di installazione, gestire le dipendenze tra diversi pacchetti, rimuovere prodotti ed eliminare elementi non necessari durante il processo di disinstallazione. Quelli. nella maggior parte dei casi è tutto ciò che serve ed è per questo che sono durati praticamente invariati per diversi decenni.
Il cloud computing ha aggiunto l’installazione ai gestori di pacchetti non solo da supporti fisici, ma anche da repository cloud, ma fondamentalmente è cambiato poco.
Vale la pena notare che attualmente ci sono alcuni passi avanti verso l'abbandono di deb e il passaggio ai pacchetti snap, ma ne parleremo più avanti.
Quindi, anche questa nuova generazione di sviluppatori cloud, che non conosceva né DEB né RPM, è cresciuta lentamente, ha acquisito esperienza, i prodotti sono diventati più complessi e sono stati necessari metodi di consegna più ragionevoli rispetto a FTP, script bash e simili attività studentesche.
Ed è qui che entra in gioco Docker, una sorta di mix di virtualizzazione, delimitazione delle risorse e metodo di consegna. È di moda e giovanile adesso, ma è necessario per tutto? È una panacea?
Dalle mie osservazioni, molto spesso Docker viene proposto non come una scelta ragionevole, ma semplicemente perché, da un lato, se ne parla nella comunità, e chi lo propone solo lo sa. D'altra parte, per la maggior parte tacciono sui buoni vecchi sistemi di imballaggio: esistono e svolgono il loro lavoro in silenzio e inosservati. In una situazione del genere non c'è davvero altra scelta: la scelta è ovvia: Docker.
Proverò a condividere la mia esperienza su come abbiamo implementato Docker e cosa è successo di conseguenza.
Sceneggiature autoprodotte
Inizialmente, c'erano script bash che distribuivano gli archivi jar sulle macchine richieste. Questo processo è stato gestito da Jenkins. Ciò ha funzionato con successo, poiché l'archivio jar stesso è già un assembly contenente classi, risorse e persino configurazione. Se ci metti tutto al massimo, espanderlo in uno script non è la cosa più difficile di cui hai bisogno
Ma gli script presentano diversi svantaggi:
- Gli script vengono solitamente scritti in fretta e sono quindi così primitivi da contenere solo uno scenario migliore. Ciò è facilitato dal fatto che lo sviluppatore è interessato a una consegna rapida e uno script normale richiede l'investimento di una discreta quantità di risorse
- in conseguenza del punto precedente gli script non contengono procedure di disinstallazione
- nessuna procedura di aggiornamento stabilita
- Quando viene visualizzato un nuovo prodotto, è necessario scrivere un nuovo script
- nessun supporto per le dipendenze
Certo, puoi scrivere una sceneggiatura sofisticata, ma, come ho scritto sopra, questo è tempo di sviluppo, e non ultimo, e, come sappiamo, non c'è sempre abbastanza tempo.
Tutto ciò limita ovviamente il campo di applicazione di questa modalità di implementazione ai soli sistemi più semplici. È giunto il momento di cambiare questa situazione.
docker
Ad un certo punto, i middles appena coniati cominciarono a venire da noi, ribollenti di idee e deliranti per il portuale. Bene, bandiera in mano: facciamolo! Ci sono stati due tentativi. Entrambi non hanno avuto successo, diciamo, a causa delle grandi ambizioni, ma della mancanza di vera esperienza. Era necessario forzarlo e finirlo con ogni mezzo possibile? È improbabile: il team deve evolversi al livello richiesto prima di poter utilizzare gli strumenti appropriati. Inoltre, quando si utilizzano immagini Docker già pronte, ci siamo spesso imbattuti nel fatto che la rete non funzionava correttamente (forse a causa dell'umidità del Docker stesso) o era difficile espandere i contenitori di altre persone.
Quali inconvenienti abbiamo riscontrato?
- Problemi di rete in modalità bridge
- È scomodo visualizzare i log in un contenitore (se non sono archiviati separatamente nel file system della macchina host)
- ElasticSearch occasionalmente si blocca in modo strano all'interno del contenitore, il motivo non è stato determinato, il contenitore è ufficiale
- È necessario utilizzare una shell all'interno di un contenitore: tutto è molto semplice, non ci sono gli strumenti abituali
- Contenitori raccolti di grandi dimensioni: costosi da immagazzinare
- A causa delle grandi dimensioni dei contenitori, è difficile supportare più versioni
- Tempo di compilazione più lungo, a differenza di altri metodi (script o pacchetti deb)
D'altra parte, perché è peggio distribuire un servizio Spring sotto forma di archivio jar tramite lo stesso deb? L’isolamento delle risorse è davvero necessario? Vale la pena perdere strumenti utili del sistema operativo inserendo un servizio in un contenitore notevolmente ridotto?
Come ha dimostrato la pratica, in realtà ciò non è necessario, il pacchetto deb è sufficiente nel 90% dei casi.
Quando fallisce il buon vecchio deb e quando abbiamo davvero bisogno di docker?
Per noi si trattava di distribuire servizi in Python. Molte librerie necessarie per l'apprendimento automatico e non incluse nella distribuzione standard del sistema operativo (e c'erano versioni sbagliate), hack con le impostazioni, la necessità di versioni diverse per servizi diversi che vivevano sullo stesso sistema host hanno portato a questo, che l'unico modo ragionevole per trasportare questa miscela nucleare era il portuale. L'intensità di lavoro necessaria per assemblare un contenitore docker si è rivelata inferiore rispetto all'idea di comprimere il tutto in pacchetti deb separati con dipendenze, e in effetti nessuno sano di mente si sarebbe impegnato in questa impresa.
Il secondo punto in cui prevediamo di utilizzare Docker è distribuire i servizi utilizzando lo schema di distribuzione blu-verde. Ma qui voglio ottenere un graduale aumento della complessità: prima vengono creati i pacchetti deb e poi da essi viene creato un contenitore docker.
Scatta pacchetti
Torniamo ai pacchetti snap. Sono apparsi ufficialmente per la prima volta in Ubuntu 16.04. A differenza dei soliti pacchetti deb e pacchetti rpm, snap trasporta tutte le dipendenze. Da un lato ciò consente di evitare conflitti di libreria, dall'altro il pacchetto risultante è di dimensioni maggiori. Inoltre, ciò può incidere anche sulla sicurezza del sistema: in caso di consegna immediata, tutte le modifiche alle librerie incluse devono essere monitorate dallo sviluppatore che crea il pacchetto. In generale, non tutto è così semplice e la felicità universale non deriva dal loro utilizzo. Si tratta tuttavia di un'alternativa del tutto ragionevole se lo stesso Docker viene utilizzato solo come strumento di packaging e non per la virtualizzazione.
Di conseguenza, ora utilizziamo sia i pacchetti deb che i contenitori docker in una combinazione ragionevole, che, forse, in alcuni casi sostituiremo con pacchetti snap.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Cosa usi per la consegna?
-
Sceneggiature autoprodotte
-
Copia manualmente su FTP
-
pacchetti deb
-
pacchetti giri/min
-
pacchetti a scatto
-
Immagini Docker
-
Immagini della macchina virtuale
-
Clona l'intero HDD
-
fantoccio
-
ansible
-
Altro
109 utenti hanno votato. 32 utenti si sono astenuti.
Fonte: habr.com