D'alguna manera, en un moment donat, vaig decidir escriure un article sobre el lliurament en forma de contenidors Docker i paquets de deb, però quan vaig començar, per alguna raó, em vaig portar als temps llunyans dels primers ordinadors personals i fins i tot de les calculadores. En general, en comptes de comparacions seques de Docker i deb, tenim aquestes reflexions sobre el tema de l'evolució, que presento per a la vostra consideració.
Qualsevol producte, sigui quin sigui, ha d'arribar d'alguna manera als servidors del producte, s'ha de configurar i llançar. D'això tractarà aquest article.
Pensaré en un context històric, "el que veig és el que canto", el que vaig veure quan vaig començar a escriure codi i el que observo ara, el que estem utilitzant nosaltres mateixos en aquest moment i per què. L'article no pretén ser un estudi en tota regla, es perden alguns punts, aquesta és la meva visió personal del que va ser i del que és ara.
Per tant, en els bons vells temps... el primer mètode de lliurament que vaig trobar eren les cintes de casset de gravadores. Tenia un ordinador BK-0010.01...
L'era de les calculadores
No, hi va haver un moment encara més primerenc, també hi havia una calculadora и .
Així que quan vaig tenir , llavors la manera de transferir el programa era un full de paper normal en una caixa on s'havia escrit un programa, que, si calia, per executar-lo manualment, s'havia escrit a la calculadora. Si voleu jugar (sí, fins i tot aquesta calculadora antediluviana tenia jocs) - us asseieu i introduïu el programa a la calculadora. Naturalment, quan la calculadora es va apagar, el programa va desaparèixer en l'oblit. A més dels codis de calculadora escrits personalment en paper, els programes es publicaven a les revistes "Radio" i "Technology for Youth", i també es publicaven en llibres d'aquella època.
La següent modificació va ser una calculadora , ja té una aparença d'emmagatzematge de dades no volàtil. Ara el joc o el programa no s'havia d'introduir manualment, però després de fer unes passades màgiques amb els botons, es va carregar.
La mida del programa més gran de la calculadora era de 105 passos i la mida de la memòria permanent a MK-52 era de 512 passos.
Per cert, si hi ha fans d'aquestes calculadores que estan llegint aquest article, en el procés d'escriure l'article he trobat tant un emulador de calculadora per a Android com programes per a aquest. Endavant al passat!
Una breu digressió sobre MK-52 (de la Viquipèdia)
MK-52 va volar a l'espai amb la nau Soiuz TM-7. S'havia d'utilitzar per calcular la trajectòria d'aterratge en cas que l'ordinador de bord fallés.
Des de 52, el MK-1988 amb la unitat d'expansió de memòria Elektronika-Astro s'ha subministrat als vaixells de la Marina com a part d'un equip informàtic de navegació.
Els primers ordinadors personals
Tornem als temps . Està clar que hi havia més memòria, i escriure codi des d'un paper ja no era una opció (tot i que al principi vaig fer això, perquè simplement no hi havia cap altre mitjà). Els cassets d'àudio per a gravadores s'estan convertint en el principal mitjà d'emmagatzematge i lliurament de programari.
L'emmagatzematge en un casset sol ser en forma d'un o dos fitxers binaris, tota la resta estava continguda a l'interior. La fiabilitat era molt baixa, vaig haver de guardar 2-3 còpies del programa. Els temps de càrrega també van ser decebedors i els entusiastes van experimentar amb diferents codificacions de freqüència per superar aquestes mancances. Aleshores, jo mateix encara no estava involucrat en el desenvolupament professional de programari (sense comptar els programes senzills en BASIC), així que, malauradament, no us explicaré amb detall com estava tot disposat a dins. El fet mateix que l'ordinador només tingués RAM en la seva major part va determinar la simplicitat de l'esquema d'emmagatzematge de dades.
L'aparició de mitjans d'emmagatzematge fiables i grans
Més tard, van aparèixer els disquets, es va simplificar el procés de còpia i va augmentar la fiabilitat.
Però la situació canvia dràsticament només quan apareixen emmagatzematges locals prou grans en forma de disc dur.
El tipus de lliurament està canviant fonamentalment: apareixen programes instal·ladors que gestionen el procés de configuració del sistema, així com la neteja després de l'eliminació, ja que els programes no només es llegeixen a la memòria, sinó que ja es copien a l'emmagatzematge local, des del qual cal poder esborrar coses innecessàries si cal.
Al mateix temps, augmenta la complexitat del programari subministrat.
El nombre de fitxers al lliurament augmenta d'uns pocs a centenars i milers, els conflictes entre les versions de la biblioteca i altres alegries comencen quan diferents programes utilitzen les mateixes dades.
En aquell moment, l'existència de Linux encara no m'estava oberta; jo vivia al món de MS DOS i, més tard, de Windows, i escrivia en Borland Pascal i Delphi, de vegades mirant cap al C++. Moltes persones feien servir InstallShield per lliurar productes aleshores. , que va resoldre amb força èxit totes les tasques assignades de desplegament i configuració del programari.
Era d'Internet
A poc a poc, la complexitat dels sistemes de programari es fa encara més complexa; des del monòlit i les aplicacions d'escriptori es passa a sistemes distribuïts, clients lleugers i microserveis. Ara cal configurar no només un programa, sinó un conjunt d'ells, i perquè funcionin tots junts.
El concepte va canviar completament, va arribar Internet, va arribar l'era dels serveis al núvol. Fins ara, només en la fase inicial, en forma de llocs web, ningú ha somiat especialment amb serveis. però va ser un punt d'inflexió tant en el desenvolupament com en el lliurament d'aplicacions.
Per mi mateix, vaig observar que en aquell moment hi va haver un canvi en les generacions de desenvolupadors (o només va ser al meu entorn), i vaig tenir la sensació que tots els bons mètodes de lliurament antics s'havien oblidat en un moment i tot va començar des del mateix moment. començament: tot el lliurament es va començar a fer amb guions de genoll i amb orgull ho va anomenar "Enviament continu". De fet, ha començat un període de caos, quan el vell s'oblida i no s'utilitza, i el nou simplement no existeix.
Recordo les èpoques en què a la nostra empresa on treballava aleshores (no ho diré), en comptes de construir via formiga (maven encara no era popular o no existia gens), la gent simplement recollia pots a l'IDE i es comprometia serenament. en SVN. En conseqüència, el desplegament va consistir a recuperar el fitxer de SVN i copiar-lo mitjançant SSH a la màquina desitjada. És tan senzill i maldestre.
Al mateix temps, el lliurament de llocs senzills en PHP es va fer d'una manera molt primitiva simplement copiant el fitxer corregit mitjançant FTP a la màquina de destinació. De vegades no era així: el codi s'editava en directe al servidor del producte i era especialment elegant si hi havia còpies de seguretat en algun lloc.
Paquets RPM i DEB
D'altra banda, amb el desenvolupament d'Internet, els sistemes semblants a UNIX van començar a guanyar cada cop més popularitat, en particular, va ser en aquell moment quan vaig descobrir RedHat Linux 6, aproximadament l'any 2000. Naturalment, també hi havia certs mitjans per lliurar programari; segons la Viquipèdia, RPM com a gestor de paquets principal va aparèixer ja l'any 1995, a la versió de RedHat Linux 2.0. I des d'aleshores i fins avui, el sistema s'ha lliurat en forma de paquets RPM i ha existit i desenvolupant-se amb força èxit.
Les distribucions de la família Debian van seguir un camí similar i van implementar el lliurament en forma de paquets deb, que s'han mantingut sense canvis fins avui.
Els gestors de paquets us permeten lliurar els mateixos productes de programari, configurar-los durant el procés d'instal·lació, gestionar les dependències entre diferents paquets, eliminar productes i netejar els elements innecessaris durant el procés de desinstal·lació. Aquells. en la seva majoria, això és tot el que cal, i per això van durar diverses dècades pràcticament sense canvis.
La informàtica en núvol ha afegit la instal·lació als gestors de paquets no només des de mitjans físics, sinó també des de dipòsits en núvol, però fonamentalment poc ha canviat.
Val la pena assenyalar que actualment hi ha alguns moviments per allunyar-se de deb i canviar a paquets snap, però en parlarem més endavant.
Així doncs, aquesta nova generació de desenvolupadors de núvol, que no coneixien ni DEB ni RPM, també va créixer lentament, va adquirir experiència, els productes es van fer més complexos i es necessitaven alguns mètodes de lliurament més raonables que FTP, scripts bash i manualitats similars per a estudiants.
I aquí és on entra en escena Docker, una mena de barreja de virtualització, delimitació de recursos i mètode de lliurament. Ara està de moda i juvenil, però és necessari per a tot? Això és una panacea?
Segons les meves observacions, molt sovint es proposa Docker no com una opció raonable, sinó simplement perquè, d'una banda, se'n parla a la comunitat, i els qui en proposen només ho saben. D'altra banda, en la seva majoria callen sobre els bons sistemes d'envasament antics: existeixen i fan la seva feina en silenci i desapercebuts. En aquesta situació, realment no hi ha cap altra opció - l'elecció és òbvia - Docker.
Intentaré compartir la meva experiència de com vam implementar Docker i què va passar com a resultat.
Guions escrits per ells mateixos
Inicialment, hi havia scripts bash que desplegaven arxius jar a les màquines requerides. Aquest procés va ser gestionat per Jenkins. Això va funcionar correctament, ja que l'arxiu jar ja és un conjunt que conté classes, recursos i fins i tot configuració. Si ho poseu tot al màxim, expandir-lo en un guió no és el més difícil que necessiteu
Però els scripts tenen diversos desavantatges:
- Els guions solen escriure's amb pressa i, per tant, són tan primitius que només contenen un escenari òptim. Això es veu facilitat pel fet que el desenvolupador està interessat en un lliurament ràpid i un script normal requereix la inversió d'una quantitat decent de recursos
- com a conseqüència del punt anterior, els scripts no contenen procediments de desinstal·lació
- cap procediment d'actualització establert
- Quan apareix un producte nou, heu d'escriure un nou script
- sense suport a la dependència
Per descomptat, podeu escriure un guió sofisticat, però, com he escrit més amunt, aquest és temps de desenvolupament, i no menys important, i, com sabem, sempre no hi ha prou temps.
Tot això, òbviament, limita l'àmbit d'aplicació d'aquest mètode de desplegament només als sistemes més senzills. Ha arribat el moment de canviar això.
estibador
En algun moment, ens van començar a arribar mitjans acabats d'encunyar, bullint d'idees i entusiasmat amb l'estibador. Bé, bandera a la mà, fem-ho! Hi va haver dos intents. Tots dos no van tenir èxit, diguem-ne, per grans ambicions, però per manca d'experiència real. Calia forçar-lo i acabar-lo per qualsevol mitjà possible? És poc probable: l'equip ha d'evolucionar al nivell necessari abans de poder utilitzar les eines adequades. A més, quan s'utilitzava imatges de Docker ja fetes, sovint ens trobem amb el fet que la xarxa no funcionava correctament (cosa que pot ser degut a la humitat del mateix Docker) o que era difícil ampliar els contenidors d'altres persones.
Quins inconvenients ens hem trobat?
- Problemes de xarxa en mode pont
- És inconvenient veure els registres en un contenidor (si no s'emmagatzemen per separat al sistema de fitxers de la màquina amfitriona)
- ElasticSearch de tant en tant es congela estranyament dins del contenidor, el motiu no s'ha determinat, el contenidor és oficial
- Cal utilitzar una closca dins d'un contenidor: tot està molt depurat, no hi ha eines habituals
- Gran mida dels contenidors recollits: car d'emmagatzemar
- A causa de la gran mida dels contenidors, és difícil suportar diverses versions
- Temps de construcció més llarg, a diferència d'altres mètodes (scripts o paquets deb)
D'altra banda, per què és pitjor desplegar un servei Spring en forma d'arxiu jar a través del mateix deb? És realment necessari aïllar els recursos? Val la pena perdre les eines convenients del sistema operatiu introduint un servei en un contenidor molt reduït?
Com ha demostrat la pràctica, en realitat això no és necessari, el paquet deb és suficient en el 90% dels casos.
Quan falla el bon vell deb i quan necessitem realment Docker?
Per a nosaltres, això era desplegar serveis en Python. Moltes biblioteques necessàries per a l'aprenentatge automàtic i que no s'inclouen a la distribució estàndard del sistema operatiu (i què hi havia eren les versions incorrectes), pirates amb la configuració, la necessitat de diferents versions per a diferents serveis que vivien en el mateix sistema amfitrió van provocar això, que l'única manera raonable de lliurar aquesta barreja nuclear era el docker. La intensitat laboral de muntar un contenidor docker va resultar ser inferior a la idea d'empaquetar-ho tot en paquets de deb separats amb dependències i, de fet, ningú no ho faria.
El segon punt on volem utilitzar Docker és desplegar serveis mitjançant l'esquema de desplegament blau-verd. Però aquí vull obtenir un augment gradual de la complexitat: primer, es construeixen paquets deb i després es construeix un contenidor docker a partir d'ells.
Paquets ràpids
Tornem als paquets ràpids. Van aparèixer oficialment per primera vegada a Ubuntu 16.04. A diferència dels paquets deb i paquets rpm habituals, snap porta totes les dependències. D'una banda, això us permet evitar conflictes entre biblioteques, d'altra banda, el paquet resultant és més gran. A més, això també pot afectar la seguretat del sistema: en el cas del lliurament instantani, tots els canvis a les biblioteques incloses han de ser supervisats pel desenvolupador que crea el paquet. En general, no tot és tan senzill i la felicitat universal no prové d'usar-los. Però, tanmateix, aquesta és una alternativa completament raonable si el mateix Docker només s'utilitza com a eina d'embalatge i no per a la virtualització.
Com a resultat, ara fem servir tant paquets deb com contenidors docker en una combinació raonable que, potser, en alguns casos substituirem per paquets snap.
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Què utilitzeu per al lliurament?
-
Guions escrits per ells mateixos
-
Copia manualment a FTP
-
paquets deb
-
paquets rpm
-
paquets ràpids
-
Imatges de Docker
-
Imatges de màquines virtuals
-
Clonar tot el disc dur
-
titella
-
ansible
-
Un altre
Han votat 109 usuaris. 32 usuaris es van abstenir.
Font: www.habr.com