Jednom sam odlučio napisati članak o isporuci u obliku Docker kontejnera i deb paketa, no kad sam počeo, nekako sam bio odveden u davna vremena prvih osobnih računala i čak kalkulatora. Umjesto suhoparnih usporedba između Dockera i deb-a, nastali su ovakvi razmišljanja o evoluciji, koja vam predstavljam na uvid.
Svaki proizvod, bez obzira na to kakav bio, mora na neki način stići do serverskih proizvoda, mora biti konfiguriran i pokrenut. O tome će govoriti ovaj članak.
Razmišljat ću u povijesnom kontekstu, "što vidim - o tom pjevam", o tome što sam vidio kada sam tek počeo pisati kod i što sada promatram, što sami trenutno koristimo i zašto. Članak ne pretendira na potpuno istraživanje, neki su aspekti propušteni, ovo je moj osobni pogled na ono što je bilo i što je sada.
Dakle, u dobra stara vremena… najraniji način isporuke kojeg se sjećam bili su kasete iz magnetofona. Imao sam računalni model BK-0010.01...
Era kalkulatora
Ne, bio je još jedan raniji trenutak, bio je još kalkulator i .
E pa, kada sam imao , način prijenosa programa bio je običan papir u kockicama, na kojem je bila zapisana programa koja se po potrebi ručno unosila u kalkulator. Želiš igrati (da-da, čak su i na ovom prastarom kalkulatoru bile igre) — sjedneš i unosiš program u kalkulator. Naravno, kad se kalkulator isključi, program odlazi u zaborav. Osim vlastoručno ispisanih kodova kalkulatora, programi su se objavljivali u časopisima "Radio" i "Tehnika mladih", te su se tiskali u knjigama toga vremena.
Sljedeća modifikacija bila je kalkulator , već je imao neku vrstu energetski neovisnog pohranjivanja podataka. Sada nije bilo potrebno program ili igru unositi ručno, već, izvedbom nekih magičnih pokreta dugmadi, ona se učitavala sama.
Obim najvećeg programa u kalkulatoru bio je 105 koraka, a veličina trajne memorije u MK-52 — 512 koraka.
Usput, ako ima obožavatelja tih kalkulatora koji čitaju ovaj članak — tijekom pisanja članka našao sam i emulator kalkulatora za Android, kao i programe za njega. Naprijed, u prošlost!
Malo odstupanje o MK-52 (iz wikipedije)
MK-52 je letio u svemir na brodu 'Soyuz TM-7'. Predviđeno je bilo da se koristi za izračunavanje putanje slijetanja u slučaju kvara brodskog računala.
MK-52 s blokom proširenja memorije 'Elektronika-Astro' isporučivan je na brodove VMF-a od 1988. godine kao dio navigatorovog računala.
Prvi osobni računala
Vratimo se u vremena . Očito je da je i memorije sada više, a upisivanje koda s papira više nije bila opcija (iako sam to isprva radio jer drugog sredstva nije bilo). Osnovno sredstvo pohrane i distribucije softvera postaju audio kasete za magnetofone.
Pohrana na kasetama obično je bila u obliku jednog ili dva binarna datoteka, dok je sve ostalo bilo unutar. Pouzdanost je bila vrlo niska, pa je bilo potrebno imati 2-3 kopije programa. Vrijeme učitavanja također nije bilo zadovoljavajuće, entuzijasti su eksperimentirali s različitim frekvencijskim kodiranjem kako bi prevazišli te nedostatke. Sam u to vrijeme još nisam se bavio profesionalnim razvojem softvera (osim jednostavnih programa na Basicu), tako da nažalost ne mogu detaljno opisati kako je sve bilo uređeno unutra. Samo postojanje RAM-a na računalu većinom je određivalo jednostavnost sheme pohrane podataka.
Pojava pouzdanih i velikih medija za pohranu
Kasnije se pojavljuju diskete, proces kopiranja postaje jednostavniji, pouzdanost raste.
No situacija se drastično menja tek kada se pojave dovoljno veliki lokalni uređaji za pohranu u obliku HDD-a.
Fundamentalno se menja tip isporuke: pojavljuju se instalacijski programi koji upravljaju procesom konfiguracije sistema, kao i čišćenjem nakon uklanjanja, pošto se programi ne samo učitavaju u memoriju, nego se kopiraju u lokalno skladište, iz kojeg treba znati očistiti nepotrebno po potrebi.
Paralelno se povećava složenost isporučenog softvera.
Broj datoteka u isporuci raste od jedne do stotina i tisuća, počinju sukobi verzija biblioteka i druge radosti kada različiti programi koriste iste podatke.
U to vrijeme nisam bio svjestan postojanja Linuxa, živio sam u svijetu MS DOS-a, a kasnije Windowsa, programirajući u Borland Pascalu i Delphiju, povremeno se zagledajući u C++. Mnogi su tada koristili InstallShield za distribuciju proizvoda. , koji je prilično uspješno rješavao sve postavljene zadatke vezane uz implementaciju i konfiguraciju softvera.
Era interneta
Postupno se složenost softverskih sustava dodatno povećavala, prelazeći s monolitnih i desktop aplikacija na distribuirane sustave, tanke klijente i mikroservise. Sada je potrebno konfigurirati ne samo jedan program, već čitav niz njih, tako da svi zajedno dobro funkcioniraju.
Potpuno se promijenila koncepcija, došao je Internet, nastupila je era oblaka. Iako je to još uvijek bilo u početnoj fazi, u obliku web stranica, nitko nije sanjao o stvarnim servisima. To je bio prekretnica u industriji, kako u razvoju, tako i u samom dostavljanju aplikacija.
Primijetio sam da je u tom trenutku došlo do promjene generacija programera (ili je to bilo samo u mom okruženju), i stekao sam dojam da su svi stari dobri načini distribucije u jednom trenutku zaboravljeni, a sve je počelo iznova: cijela distribucija počela se raditi s ad-hoc skriptama i to se ponosno nazvalo "Continuous delivery". U stvarnosti, započeo je period kaosa, kada je staro zaboravljeno i nije se koristilo, a novog jednostavno nije bilo.
Sjećam se vremena kada smo u kompaniji u kojoj sam tada radio (neću spominjati ime), umjesto da radimo gradnju preko ant-a (maven tada još nije bio poznat ili nije ni postojao), ljudi su jednostavno gradili jar u IDE-u i nesmetano ga komitirali u SVN. Tako je implementacija uključivala vađenje datoteke iz SVN-a i kopiranje preko SSH na željeni stroj. Tako jednostavno i grubo.
U to vrijeme, isporuka jednostavnih web stranica na PHP-u radila se na prilično primitivan način – jednostavnim kopiranjem ispravljenih datoteka preko FTP-a na ciljni stroj. Ponekad nije bilo ni toga – kod je mijenjan uživo na produkcijskom poslužitelju, a bilo je posebno cijenjeno ako je negdje postojala sigurnosna kopija.
RPM- i DEB-paketi
S druge strane, s razvojem interneta sve veću popularnost počinju stjecati UNIX-slični sustavi, osobito u to vrijeme otkrio sam RedHat Linux 6, otprilike 2000. godine. Naravno, i tamo su postojala određena sredstva za distribuciju softvera; prema Wikipediji, RPM kao glavni alat za upravljanje paketima pojavio se već 1995. godine u verziji RedHat Linux 2.0. Od tada pa do danas, sustav se isporučuje u obliku RPM paketa i uspješno postoji i razvija se.
Debian distribucije krenule su sličnim putem i realizirale distribuciju u obliku deb paketa, što također ostaje nepromijenjeno do danas.
Upravitelji paketa omogućuju distribuciju samih programskih proizvoda, konfiguraciju tijekom instalacije, upravljanje ovisnostima između različitih paketa, uklanjanje proizvoda i čišćenje viška tijekom deinstalacije. Drugim riječima, to je uglavnom sve što je potrebno, zbog čega su opstali nekoliko desetljeća gotovo bez promjena.
Oblačnost je dodala u upravljače paketa instalaciju ne samo s fizičkih medija, već i iz oblaka repozitorija, no suštinski se malo toga promijenilo.
Važno je napomenuti da u današnje vrijeme postoje neki pokušaji odlaska od deb paketa i prelaska na snap pakete, ali o tome kasnije.
Tako je ova nova generacija oblačnih programera, koja nije znala ni za DEB ni za RPM, također polako rasla, stjecala iskustvo, proizvodi su se komplicirali i trebali su neki razumljiviji načini distribucije nego FTP, bash skripte i slične studentske radove.
I ovdje na scenu ulazi Docker, svojevrsna mješavina virtualizacije, ograničenja resursa i načina distribucije. Sada je to moderno, atraktivno, ali da li je potrebno za sve? Je li to panaceja?
Prema mojim zapažanjima, vrlo često se Docker ne nudi kao razumna opcija, već samo zato što se o njemu, s jedne strane, govori u zajednici, a oni koji ga nude, samo to i znaju. S druge strane, o starim, dobrim sistemima pakiranja većinom se šuti - postoje i rade tiho i neprimjetno. U toj situaciji nema puno izbora - izbor je očit - Docker.
Pokušat ću podijeliti iskustvo o tome kako je kod nas prošla implementacija Dockera i što je na kraju ispalo.
Samospisani skripti
U početku su postojali bash skripti koje su instalirale jar arhive na potrebne mašine. Tim procesom je upravljao Jenkins. To je uspešno radilo, s obzirom da je sam jar arhiv već sastavni deo koji sadrži klase, resurse i čak konfiguraciju. Ako se u njega max. stavi sve — rasporediti to skriptom nije najteži zadatak.
Međutim, skripti imaju nekoliko nedostataka:
- skripti se obično pišu u žurbi i stoga su tako primitivni da sadrže samo jedan najuspješniji scenarij. To olakšava činjenica da je programer zainteresovan za brzu isporuku, a normalna skripta zahteva ulaganje značajnog broja resursa.
- kao posledica prethodne tačke, skripti ne sadrže postupak deinstalacije.
- nema definisanog postupka nadogradnje.
- pojavom novog proizvoda, treba pisati novu skriptu.
- nema podrške za zavisnosti.
Naravno, može se napisati složena skripta, ali, kao što sam već napisao — to je vreme za razvoj, a vremena, kao što se zna, uvek nedostaje.
Sve to očigledno ograničava primenu ovog načina širenja samo na najjednostavnije sisteme. Došao je trenutak za promene.
Docker
U nekom trenutku počeli su nam dolaziti sveži mid-level programeri, puni ideja i opsesija Dockerom. Pa, uzmi zastavu — idemo! Bilo je dva pokušaja. Obe neuspešne — recimo, zbog velikih ambicija, ali nedostatka stvarnog iskustva. Da li je trebalo forsirati i dovršiti to po svaku cenu? Verovatno ne — tim treba evolutivno da dostigne potreban nivo pre nego što bude mogao da koristi odgovarajuće alate. Pored svega, koristeći gotove Docker slike, često smo se suočavali s problemom nepravilnog rada mreže (što je možda bilo još povezano s nedovoljno zrelom verzijom Dockera) ili je bilo teško proširiti tuđe kontejnere.
S kojim smo se neugodnostima suočili?
- Problemi s mrežom u bridge režimu.
- Teško je pregledati logove unutar kontejnera (ako nisu odvojeno preneseni u datotečni sistem domaćina).
- Povremeno čudno zadržavanje ElasticSearch-a unutar kontejnera, razlog nikada nije utvrđen, kontejner je zvaničan.
- Teško je koristiti shell unutar kontejnera — sve je drastično skraćeno, nema poznatih alata.
- Velika veličina prikupljenih kontejnera — skupo ih je skladištiti
- Zbog velike veličine kontejnera teško je održavati više verzija
- Produženo vrijeme izrade, za razliku od drugih načina (skripte ili deb-paketi)
S druge strane, zašto je Spring usluga u obliku jar-arhive lošija za implementaciju nego putem istog deb-a? Treba li stvarno izolacija resursa? Vrijedi li se odricati praktičnih alata operativnog sustava stavljajući uslugu u jako ograničen kontejner?
Kako praksa pokazuje — to zapravo nije potrebno, deb-paket je dovoljan u 90% slučajeva.
Kada stari dobri deb ne uspije i kada nam je stvarno potreban Docker?
Za nas je to bilo implementacija usluga na Pythonu. Mnoge biblioteke potrebne za strojno učenje nisu prisutne u standardnoj isporuci operativnog sustava (a ono što je bilo — nije bilo pravih verzija), trikovi s postavkama, potreba za različitim verzijama za različite usluge koje rade na istom domaćinu doveli su do toga da je jedini razuman način isporuke ovog složenog skupa bio Docker. Radna opterećenja izrade Docker kontejnera bila su manja nego ideja o pakiranju svega u zasebne deb-pakete s zavisnostima, a zapravo se nitko s razumnom pameću nikada ne bi ni upustio u to.
Druga stvar gdje se planira koristiti Docker — za implementaciju usluga prema shemi blue-green deploy. No, ovdje želimo postupno povećanje složenosti: prvo se prikupljaju deb-paketi, a nakon toga se iz njih sastavlja Docker kontejner.
Snap-paketi
Vratimo se snap-paketicima. Prvi put su se službeno pojavili u Ubuntu 16.04. Za razliku od uobičajenih deb-paketa i rpm-paketa, snap sadrži sve zavisnosti. S jedne strane, to omogućuje izbjegavanje sukoba biblioteka, s druge strane — rezultirajući paket je veći. Također, to može utjecati na sigurnost sustava: u slučaju isporuke s naprednim promjenama u uključenim bibliotekama, sam programer koji stvara paket treba pratiti. Uglavnom, nije sve tako jednostavno i sveobuhvatna sreća od njihove upotrebe ne dolazi. Ali, unatoč tome, to je razumljiva alternativa ako se Docker koristi samo kao sredstvo pakiranja, a ne virtualizacije.
Kao rezultat, trenutno u razumnom omjeru koristimo i deb pakete i Docker kontejnere, koje ćemo, u određenim slučajevima, možda zamijeniti sa snap paketima.
Samo registrirani korisnici mogu sudjelovati u anketi. , molimo.
Što vi koristite za isporuku?
Samospisani skripti
Kopiramo ručno na FTP
deb paketi
rpm paketi
snap paketi
Docker slike
Slike virtualnih strojeva
Kloni HDD u cijelosti
puppet
ansible
Ostalo
Glasalo je 109 korisnika. 32 korisnika je bilo suzdržano.
Izvor: habr.com
