Tarnevahendite evolutsioon või mõtted Dockerist, deb, jar ja muust

Kordagi hetkel otsustasin kirjutada artikli konteineri ja deb-pakettide tarnimisest, kuid kui ma alustasin, viibis mind kuidagi kaugesse aega, mil tekkisid esimesed personaalarvutid ja isegi kalkulaatorid. Kokkuvõttes said kuivade võrdsuste asemel dokkeri ja deb-i vahel sellised mõtisklused evolutsiooni teemal, mille ma teile esitan.

Iga toode, olgu see milline tahes, peab mingil viisil jõudma tootmisse, olema seadistatud ja käivitatud. Just sellest räägibki see artikkel.

Mõtlen ajaloolises kontekstis, "mida näen — seda laulan", mida ma nägin, kui hakkasin koodi kirjutama, ja mida ma praegu jälgin, mida me ise sel hetkel kasutame ja miks. Artikkel ei pretendeeri täielikule uurimisele, mõned aspektid on jäänud välja, see on minu isiklik vaade sellele, mis oli ja mis on praegu.

Nii et vanades heades aegades… kõige varasem tarnemood, mida ma kogesin, oli magnetofoni kassett. Mul oli arvuti BK-0010.01…

Kalkulaatorite ajastu

Ei, oli veel varasem hetk, oli ka kalkulaator MK-61 ja MK-52.

Nii et kui mul oli MK-61, oli tavaline ruuduline paberileht, millele oli kirjutatud programm, mida vajadusel manuaalselt kalkulaatorisse sisestada. Tahad mängida (jah, isegi selle vanamoodsa kalkulaatoriga olid mängud) — istud alla ja kirjutad programmi kalkulaatorisse. Loomulikult, kui kalkulaator välja lülitati, kadus programm eksistentsi. Peale enda käega kirjutatud koodide lehelt avaldati programa ajakirjades "Raadio" ja "Noorte Tehnika", samuti trükiti neid tolle aja raamatutes.

Järgmine modifikatsioon oli kalkulaator MK-52, millel oli juba mingi sarnasus energiat mitte nõudva andmete salvestamisega. Nüüd ei pidanud mängu või programmi enam käsitsi sisestama, vaid, tehes mõned maagilised näppimisliigutused nuppudega, laaditi see automaatselt.

Kalkulaatori suurima programmi maht oli 105 sammu, samas kui MК-52 püsimälu suurus oli 512 sammu.

Muide, kui on neid kalkulaatorite fännide, kes seda artiklit loevad — artiklit kirjutades leidsin ma ka kalkulaatori emulaatori Androidile ja programmid sellele. Edasi ajaloos!

• MK-61 emulaator Androidile
• Programmide kataloog MK-61 jaoks

Veidi tagasiminekut MK-52 kohta (Vikipeediast)

MK-52 lendas kosmoses laevaga „Sojuz TM-7“. Selle eesmärk oli arvutada maandumistrajektoore, kui pardaarvuti ebaõnnestub.

MK-52, millel on mälu laiendusplokk „Elektronika-Astro“, on alates 1988. aastast tarnitud laevadele, mis kuuluvad mereväe navigeerimisarvutite komplekti.

Esimesed isiklikud arvutid

Tagasi aegadesse BK-0010. Loomulikult on seal nüüd rohkem mälu ning koodi paberilt sisestamine ei olnud enam variant (kuigi alguses tegin just nii, sest teisi andmekandjaid polnud olemas). Peamine tarkvara hoiustamise ja levitamise vahend on magnetofonide helikassettid.

Kassettide hoidmine toimus tavaliselt ühe või kahe binaarfaili kujul, kõik muu sisaldus sisemuses. Usaldusväärsus oli väga madal, pidime hoidma 2-3 koopiat programmist. Laadimisaeg ei olnud samuti rahuldav, entusiastid katsetasid erineva sageduskodeerimisega, et neid puudusi ületada. Toona ei tegelenud ma veel professionaalse tarkvaraarendusega (välja arvatud mõned lihtsad programmid Basicus), seetõttu ei saa ma kahjuks detailselt rääkida, kuidas kõik sees tegelikult toimis. Ainult RAM-i olemasolu arvutis määras suuresti andmete salvestamise skeemi lihtsuse.

Usaldusväärsete ja suurte andmekandjate tulek

Hiljem tulevad välja diskettid, kopeerimisprotsess muutub lihtsamaks ja usaldusväärsus kasvab.
Aga olukord muutub kardinaalselt alles siis, kui ilmuvad piisavalt suured kohalikke ladustamise seadmed HDD-de kujul.

Oluliselt muutub tarnimise tüüp: ilmuvad installatsiooniprogrammid, mis haldavad süsteemi konfigureerimise protsessi ja ka eemaldamisejärgset puhastamist, kuna programmid mitte ainult ei loeta mällu, vaid kopeeritakse juba kohalikku salvestusse, kust peab oskama vajadusel eemaldada ebavajalikku.

Samaaegselt suureneb tarnitava tarkvara keerukus.
Failide arv tarnes kasvab ühest sadadeni ja tuhandeteni, algavad versioonikonfliktid raamatukogudes ja muud meeldivused, kui erinevad programmid kasutavad samu andmeid.

Sel ajal polnud ma veel teadlik Linuxi olemasolust, elasin MS DOS ja hiljem Windowsi maailmas, kirjutades Borland Pascalis ja Delphis, vahel piiludes C++ suunas. Toote tarnimiseks kasutasid paljud tol ajal InstallShieldi ru.wikipedia.org/wiki/InstallShield, mis lahendas edukalt kõik tarkvara juurutamise ja konfigureerimisega seotud ülesanded.

Internetiajastu

Programmi süsteemide keerukus kasvab pidevalt – monoliitsetest ja lauaarvuti rakendustest liigume edasi hajutatud süsteemide, õhukeste klientide ja mikroteenuste suunas. Nüüd tuleb konfigureerida mitte ühte programmi, vaid terve hulk, ja nii, et need kõik omavahel ühilduksid.

Kogu kontseptsioon on täielikult muutunud, Internet on saabunud ja pilveteenuste ajastu on alanud. Seni olid need veel vaid algstaadiumis, enamasti veebisaitide kujul, ja teenuste poole peale ei olnud keegi veel mõelnud. Kuid see oli pöördeline hetk nii arendus- kui ka rakenduste tarnimise valdkonnas.

Märkasin, et sel hetkel toimus põlvkondade vahetus arendajate seas (või vähemalt minu ringkonnas) ning tundus, et kõik vanad, head tarneviisid olid korraga unustatud ja kõik algas algusest peale: kogu tarne tehti improvisatsiooniliste skriptidega, mida hakati uhkelt nimetama 'Continuous delivery'. Tegelikult algas mingi segaduse periood, kus vana oli unustatud ja ei olnud midagi uut.

Mä mäletan aegu, mil firmas, kus ma tol ajal töötasin (ei hakka nimetama), ei ehitatud me kogunemist läbi ant'i (maven polnud siis veel populaarne või ei olnud seda üldse), vaid inimesed lihtsalt kogusid jar'i IDE's ja rahulikult commitiid seda SVN-i. Vastavalt sellele koosnes rakendamine faili välja võtmisest SVN-ist ja selle SSH kaudu vajaliku masinasse kopeerimisest. Nii lihtne ja toorelt.

Samas ajavahemikus tehti lihtsate PHP veebisaitide tarnimine täiesti primitiivse lihtsa faili kopeerimise kaudu FTP-le sihtmasinasse. Mõnikord ei olnud isegi seda — koodi muudeti otse tootmisserveris, ja see oli eriline luksus, kui kuskil olemas olid varukoopiad.

RPM- ja DEB-paketid

Teisest küljest, koos interneti arenguga, hakkasid üha suuremat populaarsust koguma UNIX-i sarnased süsteemid, eriti sel ajal avastasin ma enda jaoks RedHat Linux 6, umbes 2000. aastal. Loomulikult oli seal ka teatud vahendid tarkvara tarnimiseks, vastavalt vikipeediale, sai RPM peamiseks pakihalduriks 1995. aastal, RedHat Linux 2.0 versioonis. Ja alates sellest ajast on süsteem tarnitud RPM-pakettidena ja see eksisteerib ning areneb edukalt ka tänapäeval.

Debian-perekondade distributsioonid läbisid sarnase tee ja realiseerisid kohaletoimetamise deb-pakettide näol, mis on jäänud muutumatuks kuni tänaseni.

Pakettide haldurid võimaldavad mitte ainult tarkvaratooteid jõudma, vaid ka nende seadistamist installimise käigus, sõltuvuste haldamist erinevate pakettide vahel, toodete eemaldamist ning liigsete andmete puhastamist deinstallimise ajal. Ehkki põhimõtteliselt on see kõik, mida vajate, ongi see põhjus, miks nad on püsinud peaaegu muutumatuna juba mitu aastakümmet.

Pilvetehnoloogia on paketihalduritesse lisanud installatsioonid mitte ainult füüsilistelt andmekandjatelt, vaid ka pilvehoidlatest, kuid põhimõtteliselt on vähe muutunud.

Tuleb märkida, et hetkel on mõned katsetused eemalduda deb-paketist ja üleminek snap-paketidele, kuid sellest räägime hiljem.

Niisiis, see uus pilvearendajate põlvkond, kes ei teadnud ei DEB-i ega RPM-i, kasvas aeglaselt, kogus kogemusi, tooted muutusid keerukamaks ja vajati mõistlikumaid kohaletoimetamisviise kui FTP, bash-skripti ja sarnased üliõpilastooted.
Ja siin tuleb mängu Docker, virtuaalsuse, ressursside eristamise ja tarnimisviisi kombinatsioon. See on praegu moes ja nooruslik, kuid kas see on ikka vajalik? Kas see on igasuguste probleemide lahendaja?

Minu tähelepanekute põhjal pakutakse Dockerit sageli mitte kui mõistlikku valikut, vaid lihtsalt sellepärast, et sellest räägitakse kogukonnas, ja need, kes seda pakuvad, tunnevad seda ainult. Teisalt on vanad head pakkujad suurel määral tähelepanuta jäetud — need eksisteerivad ja teevad oma tööd vaikselt ja märkamatult. Sellises olukorras pole teist valikut — valik on ilmne — Docker.

Püüan jagada kogemusi meie Dockerisse rakendamise protsessist ja milline on tulemus.

Kohandatud skriptid

Alguses olid bash-skriptid, mis edastasid jar-arhiive õigetele masinatele. Selle protsessi juhtis Jenkins. See töötas edukalt, kuna jar-arhiiv on juba kogum, mis sisaldab klasse, ressursse ja isegi konfiguratsiooni. Kui panna sinna kõik maksimaalselt — siis on selle skripti abil jaotamine üks lihtsamaid asju.

Kuid skriptidel on mitmeid puudusi:

• Skriptid kirjutatakse sageli kiirusest, mistõttu on need äärmiselt primitiivsed ja sisaldavad vaid kõige lihtsamat stsenaariumi. Seda soodustab see, et arendaja soovib võimalikult kiiresti tarnida, samas kui korraliku skripti kirjutamine nõuab märkimisväärset ressursside investeeringut.
• Eelmise punkti tagajärjel ei sisalda skriptid eemaldamise protseduuri.
• Uuendamise protseduuri ei ole kehtestatud.
• Uue toote ilmumisel on vajalik kirjutada uus skript.
• Sõltuvuste tugi puudub.

Loomulikult on võimalik kirjutada keeruline skript, kuid nagu ma eelnevalt mainisin, on see arenduseks kuluv aeg, mis ei ole sugugi väike, ja aega, nagu teada, on alati vähe.

See piirab selgelt sellise juurutusmeetodi kasutusvõimaluste ringi vaid kõige lihtsamatele süsteemidele. On aeg seda muuta.

Docker

Mingil hetkedel hakkasid meile jõudma värskelt küpsetatud keskmise tasemega spetsialistid, kes olid tulvil ideid ja unistasid Dockerist. Nojah, lipp üles — teeme! Oli kaks katset. Mõlemad ebaõnnestusid — ütleme nii, et suurtest ambitsioonidest tingituna, kuid reaalsest kogemusest jäi puudu. Kas oleks pidanud kiirustama ja kõiki jõude kasutades lõpule viima? Vaevalt — meeskond peab evolutsiooniliselt kasvama vajalikule tasemele, enne kui suudab kasutada sobivaid tööriistu. Kõigele lisaks, kasutades valmis Dockerisid, seisime tihti silmitsi olukordadega, kus võrgu töö ei olnud korrektne (mis võis olla seotud ka Docker enda tooretsusega) või oli keeruline teiste konteinereid laiendada.

Milliste ebamugavustega me silmitsi seisime?

• Probleemid võrguühendusega bridge-režiimis
• Ebamugav logisid konteineris vaadata (kui need pole eraldi host-masina failisüsteemi välja tõstetud)
• Perioodiliselt kummaline hangumine ElasticSearchis konteineris, põhjust ei saanud selgeks, konteiner ametlik
• Konteineris shelli kasutamine on ebamugav — kõik on tugevalt piiratud, puuduvad tuttavad tööriistad
• Kogutud konteinerite suurus on suur — säilitamine on kallis
• Suure konteinerite tõttu on keeruline hallata mitmeid versioone.
• Kogumine kestab kauem kui teiste meetodite (skriptid või deb-pakid) puhul.

Miks on Springi teenuse jar-arhiva kaudu juurutamine kehvem deb-paki kaudu? Kas ressursside isolatsioon on tõesti vajalik? Kas tasub loobuda mugavatest operatsioonisüsteemi tööriistadest, surudes teenuse tugevasti piiratud konteinerisse?

Kogemus tõendab, et seda ei ole tegelikult vajalik, deb-pakist piisab 90% juhtudel.

Millal ei tööta vana hea deb ja millal on Docker tõeliselt vajalik?

Meie jaoks tähendas see teenuste juurutamist Pythoni abil. Palju teeke, mis olid vajalikud masinõppe jaoks ja puudusid operatsioonisüsteemi standardses komplektis (ja see, mis seal oli — ei olnud õigeid versioone), seadistamisega seotud hack'id, vajadus erinevate versioonide järele erinevates teenustes, mis elavad samas host-süsteemis, viisid selleni, et ainus mõistlik viis selle tuumsegu tarnimiseks osutus Dockeriks. Docker-konteineri koostamise töömaht oli väiksem kui idee pakkida kõik see eraldi deb-pakettidesse koos sõltuvustega, tegelikult ei oleks keegi normaalsetes mõtetes sellega järele võtnud.

Teine aspekt, kus on plaanis kasutada Dockerit, on teenuste juurutamine blue-green deploy skeemi järgi. Siin tahaks aga saavutada keerukuse järkjärgulist suurenemist: alguses koostatakse deb-paketid ja seejärel juba nende põhjal luuakse Docker-konteiner.

Snap-paketid

Tagasi snap-pakettide juurde. Need ilmusid esmakordselt ametlikult Ubuntu 16.04-s. Erinevalt tuttavatest deb-pakettidest ja rpm-pakettidest sisaldavad snap-pakid endas kõiki sõltuvusi. Ühest küljest võimaldab see vältida teegikonflikte, teisest küljest aga on lõpptootes suurused märksa suuremad. Lisaks võib see mõjutada ka süsteemi turvalisust: snap-paketiga seotud teegimuudatuste eest peab jälgima arendaja, kes paketti loob. Üldiselt ei ole kõik nii üheselt mõistetav ja nende kasutamise üleüldine rõõm ei pruugi saabuda. Kuid siiski on see igati mõistlik alternatiiv, kui Dockerit kasutatakse ainult pakendamise vahendina, mitte virtualiseerimiseks.

Kokkuvõttes kasutame praegu ratsionaalses kombinatsioonis nii deb-pakette kui ka Docker-konteinereid, mille mõned näited asendame vajadusel snap-pakettidega.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kuidas teie pakette tarnite?

• Kohandatud skriptid

• Kopeerime käsitsi FTP kaudu

• deb-pakettide kaudu

• rpm-pakettide kaudu

• snap-pakettide kaudu

• Docker-piltide kaudu

• Virtuaalmasinate piltide kaudu

• Kloonime HDD tervikuna

• puppet

• ansible

• Muu

Hääletas 109 kasutajat. 32 kasutajat jäid erapooletuks.

Allikas: habr.com