Cumva, într-un moment, am decis să scriu un articol despre livrarea în containere Docker și pachete deb, dar când am început, dintr-un motiv oarecare, m-am dus cu gândul la vremurile îndepărtate ale primelor computere personale și chiar calculatoare. În general, în loc de comparații seci între Docker și deb, au ieșit aceste reflecții despre evoluție, pe care le supun judecății dumneavoastră.
Orice produs, indiferent de natură, trebuie să ajungă în vreun fel la serverele de producție, trebuie configurat și pornit. Despre asta va fi acest articol.
Voi gândi în context istoric, „ce văd — despre asta cânt”, ceea ce am văzut când am început să scriu cod și ce observ acum, ce folosim noi în prezent și de ce. Articolul nu pretinde a fi o cercetare completă, unele momente sunt omise, acesta este punctul meu de vedere personal asupra a ceea ce a fost și ce este acum.
Așadar, în vremurile de demult... cea mai timpurie modalitate de livrare pe care am întâlnit-o eran casetele pentru magnetofon. Am avut un computer BK-0010.01...
Epoca calculatoarelor
Nu, a fost un moment și mai timpuriu, a existat un alt calculator și .
Așa că, când aveam , metoda de transfer a programului era o simplă foaie de hârtie pătrată, pe care era scris programul, care, la nevoie, era introdus manual în calculator. Vrei să te joci (da, da, chiar și pe acest calculator demodat erau jocuri) — te așezi și scrii programul în calculator. Evident, odată cu oprirea calculatorului, programul se ducea în neant. Pe lângă codurile scrise de mână pe hârtie, programele erau publicate în revistele „Radio” și „Tehnica Tineretului”, precum și tipărite în cărțile vremii.
Următoarea modificare a fost calculatorul , care deja avea o formă de stocare a datelor fără alimentare. Acum, deja nu era nevoie să introduci manual jocul sau programul, ci, făcând câteva mișcări magice cu butoanele, acesta se încărca singur.
Dimensiunea celei mai mari programe în calculator era de 105 pași, iar dimensiunea memoriei permanente în MK-52 era de 512 pași.
Apropo, dacă sunt fani ai acestor calculatoare care citesc acest articol — în timp ce scriam articolul, am descoperit un emulator de calculator pentru Android și programele pentru el. Să mergem înapoi în trecut!
O mică digresiune despre MK-52 (din Wikipedia)
MK-52 a zburat în spațiu la bordul navei „Soyuz TM-7”. Era destinat să fie folosit pentru calcularea traiectoriei de aterizare în cazul în care computerul de bord s-ar defecta.
MK-52 cu modulul de extindere a memoriei „Electronica-Astro” era livrat pe navele Marinei Militare începând din 1988, ca parte a complexului de calcul pentru navigatori.
Primele calculatoare personale
Să ne întoarcem la vremurile . E clar că a crescut și capacitatea de memorie, iar introducerea codului de pe hârtie nu mai era o opțiune (deși la început am făcut acest lucru, deoarece nu exista un alt suport disponibile). Principalul mediu de stocare și livrare a software-ului au devenit casetele audio pentru magnetofon.
Stocarea pe casetă era de obicei sub forma unuia sau două fișiere binare, tot restul fiind inclus. Fiabilitatea era foarte scăzută, era necesar să păstrezi 2-3 copii ale programului. Timpul de încărcare nici el nu era satisfăcător; pasionații experimentau cu diverse codificări de frecvență pentru a depăși aceste deficiențe. Eu, în acea perioadă, nu mă ocupam de dezvoltarea profesională a software-ului (cu excepția unor programe simple în BASIC), așa că, din păcate, nu pot povesti în detaliu cum era organizat totul înăuntru. Faptul că pe computer exista doar RAM determina, în mare parte, simplitatea schemei de stocare a datelor.
Apariția suporturilor de informație fiabile și mari
Apoi au apărut dischetele, procesul de copiere s-a simplificat, iar fiabilitatea a crescut.
Dar situația se schimbă radical doar când apar stocări locale destul de mari sub formă de HDD.
Se schimbă în principiu tipul livrării: apar programe de instalare care gestionează procesul de configurare a sistemului, precum și curățarea după eliminare, deoarece programele nu sunt doar citite în memorie, ci deja copiate în stocarea locală, din care trebuie să știi cum să elimini ceea ce nu mai este necesar.
Paralel, complexitatea software-ului livrat crește.
Numărul de fișiere livrate crește de la unul la sute și mii, încep conflictele versiunilor bibliotecilor și alte neplăceri, când diverse programe folosesc aceleași date.
În acele vremuri, nu-mi era încă cunoscută existența Linux-ului; trăiam în lumea MS DOS și, mai târziu, Windows, scriind în Borland Pascal și Delphi, aruncând ocazional o privire către C++. Pentru livrarea produselor, mulți foloseau atunci InstallShield , care rezolva cu succes toate sarcinile legate de desfășurarea și configurarea software-ului.
Era internetului
Treptat, complexitatea sistemelor software a crescut, trecând de la monolit și aplicații desktop la sisteme distribuite, clienți subțiri și microservicii. Acum trebuie să configurăm nu doar o singură aplicație, ci un set de aplicații, astfel încât toate să colaboreze.
Conceptul s-a schimbat complet; Internetul a venit și a început era serviciilor cloud. În acel moment, erau încă doar la început, sub forma site-urilor, nimeni nu visa la servicii. Dar acesta a fost un moment de cotitură în industrie, atât în dezvoltare, cât și în livrarea de aplicații.
Am observat că în acest moment a avut loc o schimbare de generații în rândul dezvoltatorilor (sau a fost doar în cercul meu), iar senzația era că toate metodele vechi de livrare au fost uitate dintr-o dată și totul a început de la zero: întreaga livrare a început să se facă prin scripturi improvizate și a fost denumită cu mândrie „Livrare continuă”. De fapt, a început o perioadă de haos, când vechiul a fost uitat și nu a fost folosit, iar noul pur și simplu nu exista.
Îmi amintesc vremurile când, în compania unde lucram atunci (nu voi numi), în loc să facem o compilare prin ant (maven nu era prea popular atunci sau nu apăruse deloc), oamenii pur și simplu compilau jar în IDE și îl comiteau fără grijă în SVN. Astfel, desfășurarea consta în a scoate fișierul din SVN și a-l copia prin SSH pe mașina dorită. Așa de simplu și rudimentar.
În aceeași perioadă, livrarea simplă a site-urilor PHP se făcea într-un mod și mai primitiv, prin copierea pur și simplu a fișierului corectat prin FTP pe mașina țintă. Uneori nu exista nici măcar asta — codul era corectat direct pe serverul de producție, și era un adevărat lux să existe backup-uri undeva.
Pachete RPM și DEB
Pe de altă parte, odată cu dezvoltarea internetului, sistemele de tip UNIX au început să câștige din ce în ce mai multă popularitate, iar în acel timp am descoperit RedHat Linux 6, aproximativ în 2000. Desigur, și acolo existau anumite metode de livrare a software-ului; conform Wikipediei, RPM, ca principal manager de pachete, a apărut încă din 1995, în versiunea RedHat Linux 2.0. Și de atunci și până în prezent, sistemul este livrat sub formă de pachete RPM și funcționează și se dezvoltă cu succes.
Distribuțiile din familia Debian au parcurs o cale similară și au implementat livrarea sub formă de pachete deb, ceea ce, de asemenea, a rămas neschimbat până în prezent.
Managerii de pachete permit livrarea propriilor produse software, configurarea acestora în timpul instalării, gestionarea dependențelor între diferite pachete, realizarea dezinstalării produselor și curățarea excesului în timpul procesului de dezinstalare. Cu alte cuvinte, în mare parte, acestea sunt toate lucrurile necesare, motiv pentru care au rămas timp de câteva decenii practic fără modificări.
Cloud computing a adăugat managerilor de pachete posibilitatea de a instala nu doar de pe medii fizice, ci și din depozite cloud, dar fondamental, puține lucruri s-au schimbat.
Merită menționat că, în prezent, există anumite tendințe de a părăsi formatele deb și a trece la pachetele snap, dar despre asta mai târziu.
Astfel, această nouă generație de dezvoltatori cloud, care nu cunoștea nici DEB, nici RPM, a crescut treptat, acumulând experiență; produsele au devenit mai complexe și erau necesare modalități mai raționale de livrare decât FTP, scripturi bash și astfel de lucruri de studenți.
Și aici intră în scenă Docker, un fel de amestec de virtualizare, delimitare a resurselor și modalitate de livrare. Acum este popular, modern, dar este necesar pentru toate? Este o panacee?
Din observațiile mele, foarte adesea Docker este oferit nu ca o alegere rațională, ci pur și simplu pentru că se vorbește despre el în comunitate, iar cei care îl propun, doar asta cunosc. Pe de altă parte, despre vechile sisteme de ambalare, în cea mai mare parte, se tace — ele există și își fac treaba în liniște și fără zgomot. Într-o astfel de situație, nu prea mai există alte opțiuni — alegerea este evidentă — Docker.
Voi încerca să împărtășesc experiența noastră de implementare a Docker și ce rezultat a avut.
Scripturi personalizate
La început, existau scripturi bash care implementau arhive jar pe mașinile necesare. Procesul era gestionat de Jenkins. Aceasta a funcționat cu succes, deoarece arhiva jar este deja o construcție care conține clase, resurse și chiar configurații. Dacă le adunăm pe toate în maximul său — atunci desfășurarea prin script nu este cel mai dificil lucru pe care trebuie să-l facem.
Dar scripturile au câteva dezavantaje:
- scripturile sunt de obicei scrise în grabă și, prin urmare, sunt atât de primitive încât conțin doar un singur scenariu de succes. Acest lucru este favorizat de faptul că dezvoltatorul este interesat să livreze cât mai repede posibil, iar un script normal necesită o investiție considerabilă de resurse.
- ca urmare a punctului anterior, scripturile nu conțin proceduri de dezinstalare.
- nu există o procedură stabilită de actualizare.
- la apariția unui nou produs trebuie să scriem un nou script.
- nu există suport pentru dependențe.
Desigur, se poate scrie un script complex, dar, așa cum am menționat mai sus — acesta va necesita timp de dezvoltare, iar timpul, după cum știm, este întotdeauna insuficient.
Acest lucru limitează evident utilizarea acestei metode de desfășurare la cele mai simple sisteme. A sosit momentul să facem o schimbare.
Docker
La un moment dat, au început să vină la noi proaspăt absolvenți, plini de idei și visând la Docker. Ce să facem, avansăm! Au fost două încercări. Ambele nereușite — să spunem așa, din cauza ambițiilor mari, dar a lipsei de experiență reală. Trebuia să forțăm și să finalizăm cu orice preț? Probabil că nu — echipa trebuie să evolueze odată cu necesitățile înainte de a putea folosi instrumentele potrivite. Pe deasupra, folosind imagini Docker deja existente, ne-am confruntat adesea cu probleme de funcționare a rețelei (ceea ce, s-ar putea, era legat de instabilitatea Docker-ului în sine) sau era complicat să extindem containerele altora.
Cu ce inconveniente ne-am confruntat?
- Probleme cu rețeaua în modul bridge.
- Incomod să vezi jurnalele în container (dacă nu sunt transferate separat în sistemul de fișiere al mașinii gazdă).
- Ocazional, o suspendare ciudată a ElasticSearch în interiorul containerului, cauza nu a fost stabilită, containerul era oficial.
- Incomod să folosești shell-ul în interiorul containerului — totul este foarte restricționat, lipsesc instrumentele obișnuite.
- Dimensiunea mare a containerelor adunate - costisitor de stocat
- Din cauza dimensiunii mari a containerelor, este greu să menții versiuni multiple
- Construire mai lungă, spre deosebire de alte metode (scripturi sau pachete deb)
Pe de altă parte, ce este rău în a desfășura un serviciu Spring sub formă de arhivă jar prin același deb? Este cu adevărat necesară izolarea resurselor? Merită să renunți la uneltele convenabile ale sistemului de operare, înfingând serviciul într-un container foarte restrâns?
Așa cum a arătat practica - în realitate, acest lucru nu este necesar, pachetul deb este suficient în 90% din cazuri.
Când nu funcționează vechiul pachet deb și când am avut cu adevărat nevoie de Docker?
Pentru noi, aceasta a fost desfășurarea serviciilor în Python. Multe biblioteci necesare pentru învățarea automată și lipsă în distribuția standard a sistemului de operare (iar cele care existau nu erau versiunile corecte), hack-uri cu setările, necesitatea diferitelor versiuni pentru diferite servicii care trăiesc pe aceeași sistem gazdă au dus la concluzia că singura modalitate rațională de livrare a acestei amestecuri a fost Docker. Greutatea de a construi un container Docker a fost mai mică decât ideea de a împacheta totul în pachete deb separate cu dependențe, iar nimeni, în mintea lui sănătoasă, nu ar fi încercat asta.
Al doilea moment în care se preconizează utilizarea Docker - pentru desfășurarea serviciilor în schema blue-green deploy. Dar aici se dorește o creștere treptată a complexității: mai întâi se construiesc pachetele deb, iar apoi din acestea se construiește containerul Docker.
Pachete Snap
Să revenim la pachetele snap. Acestea au apărut oficial pentru prima dată în Ubuntu 16.04. Spre deosebire de pachetele deb și rpm uzuale, snap-urile includ toate dependențele. Pe de o parte, acest lucru permite evitarea conflictelor între biblioteci, pe de altă parte - dimensiunea rezultată a pachetului este mai semnificativă. În plus, aceasta poate influența și securitatea sistemului: în cazul livrării unui snap, toate modificările bibliotecilor incluse trebuie monitorizate de către dezvoltatorul care creează pachetul. În general, nu este totul atât de simplu și fericirea universală din utilizarea lor nu apare. Cu toate acestea, este o alternativă rezonabilă, dacă același Docker este utilizat doar ca un instrument de ambalare, și nu de virtualizare.
În concluzie, acum utilizăm într-o combinație rațională atât pachete deb, cât și containere Docker, pe care, în anumite cazuri, le-am putea înlocui cu pachete snap.
Numai utilizatorii înregistrați pot participa la sondaj. , vă rugăm.
Ce folosiți pentru livrare?
Scripturi personalizate
Copiem manual pe FTP
pachete deb
pachete rpm
pachete snap
imagini Docker
Imagini ale mașinilor virtuale
Clonăm HDD-ul în întregime
puppet
ansible
Altele
109 utilizatori au votat. 32 utilizatori s-au abținut.
Sursa: habr.com
