Nekako sam u jednom trenutku odlučio da napišem članak o isporuci u obliku Docker kontejnera i deb paketa, ali kada sam počeo, iz nekog razloga sam se vratio u daleka vremena prvih personalnih računara, pa čak i kalkulatora. Općenito, umjesto suhoparnih poređenja docker-a i deb-a, dobili smo ova razmišljanja na temu evolucije, koje vam iznosim na razmatranje.
Svaki proizvod, bez obzira na to kakav je, mora nekako doći do servera proizvoda, mora se konfigurirati i pokrenuti. O tome će biti ovaj članak.
Razmišljaću u istorijskom kontekstu, „ono što vidim je ono o čemu pevam“, ono što sam video kada sam prvi put počeo da pišem kod i šta sada posmatram, šta mi sami koristimo u ovom trenutku i zašto. Članak ne pretenduje da bude punopravna studija, neke stvari su promašene, ovo je moj lični pogled na ono što je bilo i šta je sada.
Dakle, u dobra stara vremena... najraniji način isporuke koji sam pronašao su bile kasete sa kasetofona. Imao sam kompjuter BK-0010.01...
Era kalkulatora
Ne, bio je još raniji trenutak, bio je i kalkulator и .
Pa kad sam imao , tada je način prenosa programa bio običan komad papira u kutiji na kojoj je napisan program, koji je, po potrebi, za ručno pokretanje, upisan u kalkulator. Ako želite da igrate (da, čak je i ovaj pretpotopni kalkulator imao igrice) - sjednite i unesite program u kalkulator. Naravno, kada je kalkulator isključen, program je nestao u zaboravu. Pored kodova kalkulatora lično ispisanih na papiru, programi su objavljivani u časopisima „Radio” i „Tehnologija za mlade”, a objavljivani su i u knjigama tog vremena.
Sljedeća modifikacija je bio kalkulator , već ima neki privid nepromjenjivog skladištenja podataka. Sada se u igru ili program nije trebalo ručno unositi, već se nakon izvođenja nekih magičnih pasova pomoću dugmadi sam učitavao.
Veličina najvećeg programa u kalkulatoru bila je 105 koraka, a veličina trajne memorije u MK-52 bila je 512 koraka.
Inače, ako ima ljubitelja 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 (sa Wikipedije)
MK-52 je leteo u svemir na letelici Sojuz TM-7. Trebalo je da se koristi za izračunavanje putanje slijetanja u slučaju kvara na kompjuteru.
Od 52. godine, MK-1988 sa jedinicom za proširenje memorije Elektronika-Astro isporučuje se mornaričkim brodovima kao dio navigacijskog računarskog kompleta.
Prvi personalni računari
Vratimo se u vremena . Jasno je da je tu bilo više memorije, a kucanje koda s komada papira više nije bila opcija (iako sam u početku radio upravo to, jer jednostavno nije bilo drugog medija). Audio kasete za kasetofone postaju glavno sredstvo za skladištenje i isporuku softvera.
Skladištenje na kaseti obično je bilo 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 je također bilo razočaravajuće, a entuzijasti su eksperimentirali s različitim frekventnim kodiranjem kako bi prevazišli ove nedostatke. U to vrijeme, ja se još nisam bavio profesionalnim razvojem softvera (ne računajući jednostavne programe u BASIC-u), tako da vam, nažalost, neću detaljno govoriti kako je sve bilo posloženo unutra. Sama činjenica da je računar imao samo RAM najvećim delom odredila je jednostavnost šeme skladištenja podataka.
Pojava pouzdanih i velikih medija za pohranu podataka
Kasnije su se pojavile diskete, proces kopiranja je pojednostavljen, a pouzdanost povećana.
Ali situacija se dramatično mijenja tek kada se pojavi dovoljno velika lokalna pohrana u obliku HDD-a.
Vrsta isporuke se iz temelja mijenja: pojavljuju se programi za instalaciju koji upravljaju procesom konfiguracije sistema, kao i čišćenjem nakon uklanjanja, budući da se programi ne čitaju samo u memoriju, već se već kopiraju u lokalnu pohranu iz koje je potrebno biti u mogućnosti da očistite nepotrebne stvari ako je potrebno.
Istovremeno se povećava složenost isporučenog softvera.
Broj datoteka u isporuci raste sa nekoliko na stotine i hiljade, sukobi između verzija biblioteke i druge radosti počinju kada različiti programi koriste iste podatke.
U to vrijeme, postojanje Linuxa mi još nije bilo otvoreno; živio sam u svijetu MS DOS-a, a kasnije i Windows-a, i pisao u Borland Pascal-u i Delphiju, ponekad gledajući prema C++. Mnogi ljudi su tada koristili InstallShield za isporuku proizvoda. , koji je prilično uspješno riješio sve postavljene zadatke postavljanja i konfigurisanja softvera.
Internet era
Postepeno, složenost softverskih sistema postaje sve složenija, od monolitnih i desktop aplikacija dolazi do prelaska na distribuirane sisteme, 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, stigla je era cloud servisa. Do sada, samo u početnoj fazi, u vidu web stranica, niko nije posebno sanjao o uslugama. ali to je bila prekretnica kako u razvoju tako iu isporuci aplikacija.
Za sebe sam primijetio da je u tom trenutku došlo do promjene generacija programera (ili je to bilo samo u mom okruženju), a postojao je osjećaj da su svi dobri stari načini isporuke u jednom trenutku zaboravljeni i da je sve počelo od samog početka. početak: sva isporuka počela je da se radi po skriptama i ponosno je nazvala “Kontinuirana isporuka”. Zapravo, počeo je period haosa, kada se staro zaboravlja i ne koristi, a novo jednostavno ne postoji.
Sjećam se vremena kada su u našoj kompaniji u kojoj sam tada radio (neću to imenovati), umjesto da se gradi preko mrava (maven još nije bio popularan ili uopšte nije postojao), ljudi jednostavno skupljali tegle u IDE-u i spokojno predavali to u SVN. Shodno tome, implementacija se sastojala od preuzimanja datoteke iz SVN-a i kopiranja preko SSH-a na željenu mašinu. Tako je jednostavno i nespretno.
Istovremeno, isporuka jednostavnih sajtova u PHP-u obavljena je na veoma primitivan način jednostavnim kopiranjem ispravljene datoteke preko FTP-a na ciljnu mašinu. Ponekad to nije bio slučaj - kod se uređivao uživo na serveru proizvoda, a posebno je bilo šik ako negdje postoje rezervne kopije.
RPM i DEB paketi
S druge strane, razvojem interneta, sistemi nalik UNIX-u počeli su da dobijaju sve veću popularnost, posebno u to vreme sam otkrio RedHat Linux 6, otprilike 2000. godine. Naravno, postojala su i određena sredstva za isporuku softvera; prema Wikipediji, RPM se kao glavni menadžer paketa pojavio već 1995. godine, u verziji RedHat Linuxa 2.0. I od tada pa do danas sistem se isporučuje u obliku RPM paketa i prilično uspješno postoji i razvija se.
Distribucije Debian porodice su slijedile sličan put i implementirale isporuku u obliku deb paketa, koja je ostala nepromijenjena do danas.
Menadžeri paketa vam omogućavaju da sami isporučite softverske proizvode, konfigurišete ih tokom procesa instalacije, upravljate zavisnostima između različitih paketa, uklonite proizvode i očistite nepotrebne stavke tokom procesa deinstalacije. One. uglavnom, to je sve što je potrebno, zbog čega su trajale nekoliko decenija praktično nepromenjene.
Računarstvo u oblaku je dodalo instalaciju menadžerima paketa ne samo sa fizičkih medija, već i iz cloud repozitorija, ali se u osnovi malo toga promijenilo.
Vrijedi napomenuti da trenutno postoje neki pomaci prema udaljavanju od deb-a i prelasku na snap pakete, ali o tome kasnije.
Tako je i ova nova generacija cloud programera, koja nije poznavala ni DEB ni RPM, polako rasla, sticala iskustvo, proizvodi su postajali složeniji, a bili su potrebni neki razumniji načini isporuke od FTP-a, bash skripti i sličnih studentskih rukotvorina.
I tu se pojavljuje Docker, neka vrsta mješavine virtuelizacije, razgraničenja resursa i metode isporuke. Sada je moderno i mladalački, ali da li je potrebno za sve? Je li ovo panaceja?
Prema mojim zapažanjima, 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 sistemima pakovanja uglavnom šute – oni postoje i rade svoj posao tiho i neprimjetno. U takvoj situaciji zaista nema drugog izbora - izbor je očigledan - Docker.
Pokušat ću podijeliti svoje iskustvo o tome kako smo implementirali Docker i šta se dogodilo kao rezultat.
Samonapisane skripte
U početku su postojale bash skripte koje su postavljale jar arhive na potrebne mašine. Ovaj proces je vodio Dženkins. Ovo je uspješno funkcioniralo, budući da je sama jar arhiva već sklop koji sadrži klase, resurse, pa čak i konfiguraciju. Ako sve uložite maksimalno, onda to proširiti 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 scenario. To je olakšano činjenicom da je programer zainteresiran za brzu isporuku, a normalna skripta zahtijeva ulaganje pristojne količine resursa
- kao posljedica prethodne tačke, skripte ne sadrže procedure za deinstalaciju
- nema uspostavljene procedure nadogradnje
- Kada se pojavi novi proizvod, morate napisati novu skriptu
- bez podrške zavisnosti
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, uvijek nema dovoljno vremena.
Sve ovo očigledno ograničava opseg primjene ove metode implementacije samo na najjednostavnije sisteme. Došlo je vrijeme da se ovo promijeni.
doker
U nekom trenutku su nam počeli pristizati svježe iskovane sredine, kipteći idejama i buncajući se o dockeru. Pa, zastava u ruci - uradimo to! Bila su dva pokušaja. I jedni i drugi su bili neuspješni - recimo, zbog velikih ambicija, ali nedostatka pravog iskustva. Da li je to bilo potrebno forsirati i završiti na bilo koji način? Malo je vjerovatno - tim mora evoluirati do potrebnog nivoa prije nego što može koristiti odgovarajuće alate. Osim toga, kada smo koristili gotove Docker slike, često smo se susreli s činjenicom da mreža nije radila ispravno (što je možda bilo zbog vlage samog Dockera) ili je bilo teško proširiti tuđe kontejnere.
Na kakve smo neprijatnosti naišli?
- Problemi s mrežom u načinu rada mosta
- Nezgodno je pregledati dnevnike u kontejneru (ako nisu odvojeno pohranjeni u sistemu datoteka glavnog računala)
- ElasticSearch se povremeno čudno zamrzne unutar kontejnera, razlog nije utvrđen, kontejner je službeni
- Potrebno je koristiti školjku unutar kontejnera - sve je vrlo ogoljeno, nema uobičajenih alata
- Velika veličina sakupljenih kontejnera - skupo za skladištenje
- Zbog velike veličine kontejnera, teško je podržati više verzija
- Duže vrijeme izrade, 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? Da li je izolacija resursa zaista neophodna? Vrijedi li izgubiti prikladne alate operativnog sistema stavljanjem usluge u znatno smanjeni kontejner?
Kao što je praksa pokazala, u stvarnosti to nije potrebno, deb paket je dovoljan u 90% slučajeva.
Kada stari dobri deb propadne i kada nam zaista treba docker?
Za nas je ovo bilo postavljanje usluga u python-u. Mnogo biblioteka potrebnih za mašinsko učenje i koje nisu uključene u standardnu distribuciju operativnog sistema (a šta je bilo pogrešnih verzija), hakovi sa postavkama, potreba za različitim verzijama za različite usluge koje žive na istom host sistemu dovele su do toga da ovo, da je jedini razuman način za isporuku ove nuklearne mješavine bio doker. Intenzitet rada sastavljanja docker kontejnera pokazao se manjim od ideje da se sve to spakuje u zasebne deb pakete s ovisnostima, a zapravo se nitko pri zdravoj pameti ne bi za to poduzeo.
Druga tačka u kojoj planiramo da koristimo Docker je implementacija usluga koristeći plavo-zelenu šemu postavljanja. Ali ovdje želim postići postupno povećanje složenosti: prvo se grade deb paketi, a zatim se od njih pravi docker kontejner.
Snap paketi
Vratimo se na snap pakete. Prvi put su se zvanično pojavili u Ubuntu 16.04. Za razliku od uobičajenih deb paketa i rpm paketa, snap nosi sve zavisnosti. S jedne strane, ovo vam omogućava da izbjegnete konflikte u bibliotekama, s druge strane, rezultirajući paket je veće veličine. Osim toga, ovo također može utjecati na sigurnost sistema: u slučaju snap isporuke, sve promjene uključenih biblioteka mora pratiti programer koji kreira paket. Općenito, nije sve tako jednostavno i univerzalna sreća ne dolazi od njihovog korištenja. Ali, ipak, ovo je sasvim razumna alternativa ako se isti Docker koristi samo kao alat za pakovanje, a ne za virtualizaciju.
Kao rezultat toga, sada koristimo i deb pakete i docker kontejnere u razumnoj kombinaciji, koje ćemo, možda, u nekim slučajevima zamijeniti snap paketima.
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Šta koristite za dostavu?
-
Samonapisane skripte
-
Ručno kopirajte na FTP
-
deb paketi
-
rpm paketi
-
snap paketi
-
Docker slike
-
Slike virtuelne mašine
-
Klonirajte cijeli HDD
-
lutka
-
ansible
-
Ostalo
Glasalo je 109 korisnika. 32 korisnika je bila uzdržana.
izvor: www.habr.com