Nekako sam u jednom trenutku odlučio napisati članak o isporuci u obliku Docker kontejnera i deb paketa, ali kada sam počeo, iz nekog razloga vratio sam se u daleka vremena prvih osobnih računala, pa čak i kalkulatora. Općenito, umjesto suhoparnih usporedbi dockera i deba, dobili smo ove misli na temu evolucije, koje vam predstavljam na razmatranje.
Svaki proizvod, bez obzira kakav je, mora nekako doći do poslužitelja proizvoda, mora se konfigurirati i pokrenuti. O tome će biti riječi u ovom članku.
Razmišljat ću u povijesnom kontekstu, "ono što vidim je ono o čemu pjevam", što sam vidio kad sam tek počeo pisati kod i što promatram sada, što mi sami koristimo u ovom trenutku i zašto. Članak se ne pretvara da je punopravna studija, neke točke su propuštene, ovo je moj osobni pogled na ono što je bilo i što je sada.
Dakle, u dobra stara vremena... najraniji način dostave koji sam pronašao bile su kazete s magnetofona. Imao sam kompjuter BK-0010.01...
Era kalkulatora
Ne, postojao je još raniji trenutak, postojao je i kalkulator и .
Pa kad sam imao , tada je način prijenosa programa bio običan komad papira u kutiji na kojem je bio napisan program, koji se, ako je potrebno, da bi se ručno pokrenuo, upisivao u kalkulator. Ako se želite igrati (da, i ovaj pretpotopni kalkulator je imao igrice) - sjednete i unesete program u kalkulator. Naravno, kada je kalkulator isključen, program je nestao u zaborav. Osim osobno ispisanih šifri kalkulatora na papiru, programi su objavljivani u časopisima “Radio” i “Tehnika za mlade”, a objavljeni su iu knjigama tog vremena.
Sljedeća modifikacija bio je kalkulator , već ima neki privid postojane pohrane podataka. Sada se igrica ili program nije morao unositi ručno, već se nakon izvođenja magičnih prolaza s tipkama sam učitao.
Veličina najvećeg programa u kalkulatoru bila je 105 koraka, a veličina stalne memorije u MK-52 bila je 512 koraka.
Usput, ako postoje ljubitelji ovih kalkulatora koji čitaju ovaj članak, u procesu pisanja članka pronašao sam i emulator kalkulatora za Android i programe za njega. Naprijed u prošlost!
Kratka digresija o MK-52 (iz Wikipedije)
MK-52 odletio je u svemir na letjelici Soyuz TM-7. Trebao je poslužiti za izračunavanje putanje slijetanja u slučaju kvara putnog računala.
Od 52. MK-1988 s jedinicom za proširenje memorije Elektronika-Astro isporučuje se brodovima mornarice kao dio navigacijskog računalnog kompleta.
Prva osobna računala
Vratimo se u vremena . Jasno je da je tu bilo više memorije, a upisivanje koda s papirića više nije bilo opcija (iako sam u početku samo to radio, jer drugog medija jednostavno nije bilo). Audio kasete za magnetofone postaju glavno sredstvo za pohranu i isporuku softvera.
Pohrana na kaseti obično je bila u obliku jedne ili dvije binarne datoteke, sve ostalo je bilo unutra. Pouzdanost je bila vrlo niska, morao sam zadržati 2-3 kopije programa. Vrijeme učitavanja također je bilo razočaravajuće, a entuzijasti su eksperimentirali s različitim frekvencijskim kodiranjem kako bi prevladali te nedostatke. U to vrijeme se još nisam bavio profesionalnim razvojem softvera (ne računajući jednostavne programe u BASIC-u), pa vam, nažalost, neću detaljno reći kako je sve bilo uređeno unutra. Sama činjenica da je računalo većim dijelom imalo samo RAM memoriju odredila je jednostavnost sheme pohrane podataka.
Pojava pouzdanih i velikih medija za pohranu
Kasnije su se pojavile diskete, proces kopiranja je pojednostavljen, a pouzdanost povećana.
Ali situacija se dramatično mijenja tek kada se pojave dovoljno velike lokalne memorije u obliku tvrdih diskova.
Vrsta isporuke se temeljito mijenja: pojavljuju se instalacijski programi koji upravljaju procesom konfiguracije sustava, kao i čišćenjem nakon uklanjanja, budući da se programi ne čitaju samo u memoriju, već su već kopirani u lokalnu pohranu, iz koje trebate moći očistiti nepotrebne stvari ako je potrebno.
Istodobno se povećava složenost isporučenog softvera.
Broj datoteka u isporuci raste s nekoliko na stotine i tisuće, sukobi između verzija knjižnica i druge radosti počinju kada različiti programi koriste iste podatke.
Tada mi još nije bilo jasno postojanje Linuxa; živio sam u svijetu MS DOS-a i, kasnije, Windowsa, i pisao u Borland Pascalu i Delphiju, ponekad gledajući prema C++. Mnogi su ljudi tada koristili InstallShield za isporuku proizvoda. , koji je prilično uspješno riješio sve postavljene zadatke postavljanja i konfiguriranja softvera.
Internet era
Složenost softverskih sustava postupno postaje još složenija, s monolitnih i desktop aplikacija prelazi se na distribuirane sustave, tanke klijente i mikroservise. Sada morate konfigurirati ne samo jedan program, već skup njih, i to tako da svi rade zajedno.
Koncept se potpuno promijenio, došao je internet, došla je era cloud servisa. Do sada, samo u početnoj fazi, u obliku web stranica, o uslugama nitko nije posebno sanjao. ali to je bila prekretnica i u razvoju i u isporuci aplikacija.
Za sebe sam primijetio da je u tom trenutku došlo do smjene generacija developera (ili je to bilo samo u mom okruženju), te je postojao osjećaj da su svi dobri stari načini isporuke u jednom trenutku zaboravljeni i da je sve krenulo od samog početak: sve su se isporuke počele obavljati knee skripte i ponosno su to nazvale “Kontinuirana isporuka”. Zapravo, počelo je razdoblje kaosa, kada se staro zaboravlja i ne koristi, a novo jednostavno ne postoji.
Sjećam se vremena kada su u našoj tvrtki u kojoj sam tada radio (neću je imenovati), umjesto gradnje putem mrava (maven još nije bio popularan ili uopće nije postojao), ljudi su jednostavno skupljali staklenke u IDE-u i spokojno predano to u SVN. U skladu s tim, implementacija se sastojala od dohvaćanja datoteke iz SVN-a i njenog kopiranja putem SSH-a na željeni stroj. Tako je jednostavno i nespretno.
U isto vrijeme, isporuka jednostavnih web stranica u PHP-u učinjena je na vrlo primitivan način jednostavnim kopiranjem ispravljene datoteke putem FTP-a na ciljni stroj. Ponekad to nije bio slučaj – kod se uređivao uživo na serveru proizvoda, a posebno je bilo šik ako su negdje postojale sigurnosne kopije.
RPM i DEB paketi
S druge strane, s razvojem Interneta, sustavi slični UNIX-u počeli su dobivati sve veću popularnost, konkretno, u to vrijeme sam otkrio RedHat Linux 6, otprilike 2000. godine. Naravno, postojala su i određena sredstva za isporuku softvera, RPM se, prema Wikipediji, kao glavni upravitelj paketa pojavio već 1995. godine, u verziji RedHat Linuxa 2.0. I od tada pa do danas sustav se isporučuje u obliku RPM paketa i dosta uspješno postoji i razvija se.
Distribucije Debian obitelji slijedile su sličan put i implementirale isporuku u obliku deb paketa, što je do danas ostalo nepromijenjeno.
Upravitelji paketa omogućuju vam da sami isporučite softverske proizvode, konfigurirate ih tijekom procesa instalacije, upravljate ovisnostima između različitih paketa, uklonite proizvode i očistite nepotrebne stavke tijekom procesa deinstalacije. Oni. uglavnom je to sve što je potrebno, zbog čega su izdržali nekoliko desetljeća gotovo nepromijenjeni.
Računalstvo u oblaku dodalo je instalaciju upraviteljima paketa ne samo s fizičkih medija, već i iz repozitorija u oblaku, ali bitno se malo toga promijenilo.
Vrijedno je napomenuti da trenutno postoje neki pomaci prema odmicanju od deb-a i prelasku na snap pakete, ali više o tome kasnije.
Dakle, i ta nova generacija cloud developera, koja nije poznavala ni DEB ni RPM, polako je rasla, stjecala iskustvo, proizvodi su postajali sve kompleksniji, pa su bile potrebne neke razumnije metode isporuke od FTP-a, bash skripti i sličnih studentskih zanata.
I tu na scenu stupa Docker, neka vrsta mješavine virtualizacije, razgraničenja resursa i načina isporuke. Sada je moderno i mladenački, ali je li potrebno za sve? Je li ovo lijek za sve?
Iz mojih zapažanja, vrlo često se Docker ne predlaže kao razuman izbor, već jednostavno zato što se, s jedne strane, o njemu priča u zajednici, a oni koji ga predlažu samo to znaju. S druge strane, o dobrim starim sustavima pakiranja uglavnom šute - oni postoje i tiho i neprimjetno rade svoj posao. U takvoj situaciji zapravo nema drugog izbora – izbor je očit – Docker.
Pokušat ću podijeliti svoje iskustvo o tome kako smo implementirali Docker i što se dogodilo kao rezultat.
Skripte koje sam napisao
U početku su postojale bash skripte koje su postavljale jar arhive na potrebna računala. Ovim procesom upravljao je Jenkins. Ovo je uspješno funkcioniralo, budući da je sama arhiva jar već sklop koji sadrži klase, resurse, pa čak i konfiguraciju. Ako u njega uložite sve do maksimuma, onda proširenje u skriptu nije najteža stvar koja vam treba
Ali skripte imaju nekoliko nedostataka:
- skripte se obično pišu na brzinu i stoga su toliko primitivne da sadrže samo jedan najbolji scenarij. To je olakšano činjenicom da je programer zainteresiran za brzu isporuku, a normalna skripta zahtijeva ulaganje pristojne količine resursa
- kao posljedica prethodne točke, skripte ne sadrže postupke deinstalacije
- nema utvrđenog postupka nadogradnje
- Kada se pojavi novi proizvod, morate napisati novu skriptu
- nema podrške ovisnosti
Naravno, možete napisati sofisticiranu skriptu, ali, kao što sam gore napisao, ovo je vrijeme za razvoj, i to ne najmanje važno, a, kao što znamo, vremena uvijek nema dovoljno.
Sve to očito ograničava raspon primjene ove metode postavljanja samo na najjednostavnije sustave. Došlo je vrijeme da se to promijeni.
Lučki radnik
U nekom trenutku počeli su nam dolaziti svježe iskovani srednji igrači, koji su kipjeli od ideja i divili se dockeru. Pa zastavu u ruke – idemo! Bila su dva pokušaja. Oba su bila neuspješna – recimo zbog velikih ambicija, ali nedostatka pravog iskustva. Je li ga bilo potrebno forsirati i dokrajčiti svim mogućim sredstvima? Malo je vjerojatno - tim se mora razviti do potrebne razine prije nego što može koristiti odgovarajuće alate. Osim toga, pri korištenju gotovih slika Dockera često smo se susreli s činjenicom da mreža ne radi ispravno (što je možda zbog vlage samog Dockera) ili je bilo teško proširiti tuđe spremnike.
Na koje smo sve neugodnosti naišli?
- Problemi s mrežom u načinu rada mosta
- Nezgodno je pregledavati zapisnike u spremniku (ako nisu odvojeno pohranjeni u datotečnom sustavu glavnog računala)
- ElasticSearch se povremeno čudno smrzava unutar spremnika, razlog nije utvrđen, spremnik je službeni
- Potrebno je koristiti školjku unutar spremnika - sve je vrlo ogoljeno, nema poznatih alata
- Velika veličina sakupljenih spremnika – skupo ih je skladištiti
- Zbog velike veličine spremnika, teško je podržati više verzija
- Dulje vrijeme izgradnje, za razliku od drugih metoda (skripte ili deb paketi)
S druge strane, zašto je gore implementirati Spring servis u obliku jar arhive kroz isti deb? Je li izolacija resursa doista potrebna? Isplati li se izgubiti praktične alate operativnog sustava trpanjem usluge u znatno smanjeni spremnik?
Kao što je praksa pokazala, u stvarnosti to nije potrebno, deb paket je dovoljan u 90% slučajeva.
Kada stari dobri deb zakaže i kada nam stvarno treba docker?
Za nas je ovo bila implementacija usluga u pythonu. Puno biblioteka potrebnih za strojno učenje, a koje nisu uključene u standardnu distribuciju operativnog sustava (a ono što je bilo bile su pogrešne verzije), hakiranja s postavkama, potreba za različitim verzijama za različite usluge koje žive na istom host sustavu doveli su do ovo, da je jedini razuman način za isporuku ove nuklearne smjese bio doker. Intenzitet rada sastavljanja docker kontejnera pokazao se manjim od ideje da se sve to pakira u zasebne deb pakete sa ovisnostima, a zapravo se nitko pri zdravoj pameti ne bi upustio u to.
Druga točka u kojoj planiramo koristiti Docker je implementacija usluga pomoću plavo-zelene sheme implementacije. Ali ovdje želim dobiti postupno povećanje složenosti: prvo se grade deb paketi, a zatim se od njih gradi docker spremnik.
Snap paketi
Vratimo se na snap pakete. Prvi put su se službeno pojavili u Ubuntu 16.04. Za razliku od uobičajenih deb paketa i rpm paketa, snap nosi sve ovisnosti. S jedne strane, to vam omogućuje izbjegavanje sukoba knjižnica, s druge strane, rezultirajući paket je veće veličine. Osim toga, to također može utjecati na sigurnost sustava: u slučaju brze isporuke, sve promjene uključenih biblioteka mora nadzirati programer koji kreira paket. Općenito, nije sve tako jednostavno i opća sreća ne dolazi od njihove uporabe. No, svejedno, ovo je sasvim razumna alternativa ako se isti Docker koristi samo kao alat za pakiranje, a ne za virtualizaciju.
Kao rezultat toga, sada koristimo i deb pakete i docker kontejnere u razumnoj kombinaciji, koju ćemo možda u nekim slučajevima zamijeniti snap paketima.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Što koristite za dostavu?
-
Skripte koje sam napisao
-
Kopiraj ručno na FTP
-
deb paketi
-
rpm paketi
-
snap paketi
-
Docker-slike
-
Slike virtualnog stroja
-
Klonirajte cijeli HDD
-
lutka
-
ansible
-
Drugi
Glasovalo je 109 korisnika. Suzdržana su bila 32 korisnika.
Izvor: www.habr.com