Kuidagi ühel hetkel otsustasin kirjutada tarneteemalise artikli Dockeri konteinerite ja deb-pakkide näol, aga alustades kandusin millegipärast tagasi esimeste personaalarvutite ja isegi kalkulaatorite kaugetesse aegadesse. Üldiselt saime dockeri ja debi kuivade võrdluste asemel need mõtted evolutsiooni teemal, mille ma teile kaalumiseks esitan.
Iga toode, olenemata sellest, mis see on, peab kuidagi jõudma tooteserveritesse, olema konfigureeritud ja käivitatud. Sellest see artikkel räägibki.
Ma mõtlen ajaloolises kontekstis, et "see, mida ma näen, on see, millest ma laulan", mida ma nägin koodi kirjutamist alustades ja mida ma praegu jälgin, mida me ise praegu kasutame ja miks. Artikkel ei pretendeeri täiemahulisele uurimusele, mõned punktid jäävad vahele, see on minu isiklik nägemus sellest, mis oli ja mis on praegu.
Nii et vanadel headel aegadel... varaseim kättetoimetamisviis, mille ma leidsin, olid magnetofonide kassetid. Mul oli arvuti BK-0010.01...
Kalkulaatorite ajastu
Ei, oli veel varasem hetk, oli ka kalkulaator и .
Nii et kui mul oli , siis programmi ülekandmise viis oli tavaline paber karbis, millele oli kirjutatud programm, mis vajadusel käsitsi käivitamiseks kirjutati kalkulaatorisse. Kui tahad mängida (jah, isegi sellel veevoolueelsel kalkulaatoril olid mängud) – istud maha ja sisestad programmi kalkulaatorisse. Loomulikult kadus programm kui kalkulaator välja lülitati. Lisaks isiklikult paberkandjal välja kirjutatud kalkulaatorikoodidele avaldati saateid ajakirjades “Raadio” ja “Tehnoloogia noortele” ning avaldati ka tolleaegsetes raamatutes.
Järgmine modifikatsioon oli kalkulaator , sellel on juba teatav püsiv andmesalvestus. Nüüd ei pidanud mängu ega programmi käsitsi sisestama, vaid pärast mõne maagilise käigu sooritamist nuppudega laadis see end ise.
Suurima programmi suurus kalkulaatoris oli 105 sammu ja MK-52 püsimälu suurus 512 sammu.
Muide, kui leidub nende kalkulaatorite fänne, kes seda artiklit loevad, leidsin artikli kirjutamise käigus nii Androidi jaoks mõeldud kalkulaatori emulaatori kui ka selle jaoks mõeldud programme. Edasi minevikku!
Lühike kõrvalepõige MK-52 kohta (Wikipediast)
MK-52 lendas kosmosesse kosmoseaparaadiga Sojuz TM-7. Seda pidi kasutama maandumistrajektoori arvutamiseks juhuks, kui pardaarvuti peaks üles ütlema.
Alates 52. aastast on MK-1988 koos Elektronika-Astro mälulaiendusmooduliga tarnitud mereväe laevadele navigatsiooniarvutuskomplekti osana.
Esimesed personaalarvutid
Lähme tagasi aegadesse . On selge, et seal oli rohkem mälu ja paberilt koodi sisestamine polnud enam valik (kuigi alguses tegin just seda, sest muud kandjat lihtsalt polnud). Magnetofonide helikassetid on muutumas peamiseks tarkvara salvestamise ja edastamise vahendiks.
Salvestus kassetil oli tavaliselt ühe või kahe binaarfailina, kõik muu oli sees. Töökindlus oli väga madal, pidin alles jätma 2-3 programmi koopiat. Laadimisajad valmistasid samuti pettumuse ja entusiastid katsetasid nende puuduste ületamiseks erinevate sageduste kodeeringutega. Sel ajal ma ise veel professionaalse tarkvaraarendusega ei tegelenud (kui mitte arvestada lihtsaid programme BASIC-is), nii et kahjuks ei räägi ma teile üksikasjalikult, kuidas kõik sees oli korraldatud. Ainuüksi asjaolu, et arvutil oli enamasti ainult RAM, määras andmete salvestamise skeemi lihtsuse.
Usaldusväärsete ja suurte andmekandjate tekkimine
Hiljem ilmusid disketid, paljundusprotsess lihtsustati ja töökindlus suurenes.
Kuid olukord muutub dramaatiliselt alles siis, kui HDD-de kujul ilmuvad piisavalt suured kohalikud salvestusruumid.
Kohaletoimetamise tüüp muutub põhjalikult: ilmuvad installiprogrammid, mis haldavad nii süsteemi konfigureerimise protsessi kui ka puhastamist pärast eemaldamist, kuna programme ei loeta lihtsalt mällu, vaid need kopeeritakse juba kohalikku salvestusruumi, kust peate oskama vajadusel mittevajalikud asjad ära koristada.
Samal ajal suureneb tarnitava tarkvara keerukus.
Failide arv tarnimisel kasvab mõnelt sadadele ja tuhandetele, konfliktid teegiversioonide vahel ja muud rõõmud algavad siis, kui erinevad programmid kasutavad samu andmeid.
Sel ajal ei olnud Linuxi olemasolu mulle veel avatud, elasin MS DOS-i ja hiljem Windowsi maailmas ning kirjutasin Borland Pascalis ja Delphis, mõnikord vaatasin C++ poole. Paljud inimesed kasutasid tollal toodete tarnimiseks InstallShieldi. , mis lahendas üsna edukalt kõik määratud tarkvara juurutamise ja konfigureerimise ülesanded.
Interneti ajastu
Järk-järgult muutub tarkvarasüsteemide keerukus veelgi keerukamaks, monoliit- ja töölauarakendustelt läheb üleminek hajussüsteemidele, õhukestele klientidele ja mikroteenustele. Nüüd peate konfigureerima mitte ainult ühe programmi, vaid nende komplekti ja nii, et need kõik koos töötaksid.
Kontseptsioon muutus täielikult, tuli internet, saabus pilveteenuste ajastu. Seni pole teenustest keegi eriti unistanud vaid algstaadiumis veebisaitide näol. kuid see oli pöördepunkt nii rakenduste arendamisel kui tarnimisel.
Enda jaoks märkisin, et sel hetkel toimus arendajate põlvkondade vahetus (või oli see ainult minu keskkonnas) ja tekkis tunne, et kõik vanad head tarneviisid unustati ühel hetkel ja kõik algas päris algusest. algus: kogu kohaletoimetamist hakati tegema põlveskripte ja nimetas seda uhkelt "pidevaks tarnimiseks". Tegelikult on alanud kaoseperiood, mil vana unustatakse ja seda ei kasutata ning uut lihtsalt ei eksisteeri.
Mäletan aegu, kui meie ettevõttes, kus ma siis töötasin (ma ei nimeta seda), selle asemel, et ehitada sipelgaga (maven polnud veel populaarne või seda polnud üldse olemas), kogusid inimesed lihtsalt IDE-sse purke ja pühendusid rahulikult. see SVN-is. Sellest lähtuvalt seisnes juurutamine faili hankimises SVN-ist ja kopeerimises SSH kaudu soovitud masinasse. See on nii lihtne ja kohmakas.
Samal ajal tehti lihtsate saitide edastamine PHP-s väga primitiivselt, lihtsalt kopeerides parandatud faili FTP kaudu sihtmasinasse. Mõnikord see nii ei olnud - koodi redigeeriti otse tooteserveris ja see oli eriti šikk, kui kuskil olid varukoopiad.
RPM ja DEB paketid
Teisest küljest hakkasid Interneti arenedes üha enam populaarsust koguma UNIX-i sarnased süsteemid, eriti just sel ajal avastasin RedHat Linux 6, umbes 2000. aastal. Loomulikult olid olemas ka teatud vahendid tarkvara kohaletoimetamiseks, Vikipeedia andmetel ilmus RPM põhipaketihaldurina juba 1995. aastal RedHat Linux 2.0 versioonis. Ja sellest ajast alates ja tänaseni on süsteem tarnitud RPM-pakettidena ning on üsna edukalt eksisteerinud ja arenenud.
Debiani perekonna levitamine järgis sarnast teed ja rakendas tarnimist deb-pakettide kujul, mis on püsinud muutumatuna tänapäevani.
Paketihaldurid võimaldavad teil tarkvaratooteid ise tarnida, installimisprotsessi käigus konfigureerida, hallata erinevate pakettide vahelisi sõltuvusi, eemaldada tooteid ja puhastada desinstallimise käigus mittevajalikud üksused. Need. Enamasti on see kõik, mida vaja, mistõttu need kestsid mitu aastakümmet praktiliselt muutumatuna.
Pilvandmetöötlus on lisanud paketihalduritele installimise mitte ainult füüsilisest andmekandjast, vaid ka pilvehoidlatest, kuid põhimõtteliselt on vähe muutunud.
Väärib märkimist, et praegu liigutakse deb-st eemaldumise ja snap-pakettidele ülemineku suunas, kuid sellest hiljem.
Niisiis, see uus pilvearendajate põlvkond, kes ei teadnud ei DEB-d ega RPM-i, kasvas ka aeglaselt, omandas kogemusi, tooted muutusid keerukamaks ja vaja oli mõningaid mõistlikumaid tarnemeetodeid kui FTP, bash-skriptid ja sarnased õpilaste käsitööd.
Ja siin tuleb pildile Docker, omamoodi segu virtualiseerimisest, ressursside piiritlemisest ja edastamismeetodist. See on praegu moes ja nooruslik, aga kas seda on kõigeks vaja? Kas see on imerohi?
Minu tähelepanekute põhjal pakutakse väga sageli Dockerit välja mitte kui mõistlikku valikut, vaid lihtsalt seetõttu, et ühelt poolt sellest kogukonnas räägitakse ja need, kes selle välja pakuvad, teavad seda ainult. Seevastu vanadest headest pakendisüsteemidest nad enamasti vaikivad - need on olemas ja teevad oma tööd vaikselt ja märkamatult. Sellises olukorras pole tegelikult muud valikut - valik on ilmne - Docker.
Püüan jagada oma kogemusi selle kohta, kuidas me Dockerit rakendasime ja mis selle tulemusena juhtus.
Ise kirjutatud stsenaariumid
Algselt olid bash-skriptid, mis juurutasid jar-arhiivid vajalikesse masinatesse. Seda protsessi juhtis Jenkins. See toimis edukalt, kuna jar-arhiiv ise on juba koost, mis sisaldab klasse, ressursse ja isegi konfiguratsiooni. Kui paned sellesse kõik maksimaalselt sisse, siis pole selle skriptiks laiendamine just kõige keerulisem asi, mida vajad
Kuid skriptidel on mitmeid puudusi:
- skriptid kirjutatakse tavaliselt kiirustades ja on seetõttu nii primitiivsed, et sisaldavad ainult ühte parimat stsenaariumi. Seda soodustab asjaolu, et arendaja on huvitatud kiirest kohaletoimetamisest ja tavaline skript nõuab korraliku hulga ressursside investeerimist
- eelmise punkti tulemusena ei sisalda skriptid desinstallimisprotseduure
- pole kehtestatud uuendamisprotseduuri
- Kui ilmub uus toode, peate kirjutama uue skripti
- sõltuvustoetust pole
Muidugi võite kirjutada keeruka stsenaariumi, kuid nagu ma eespool kirjutasin, on see arendusaeg ja mitte vähemtähtis ning nagu me teame, pole alati piisavalt aega.
Kõik see piirab ilmselgelt selle juurutusmeetodi rakendusala ainult kõige lihtsamatele süsteemidele. On saabunud aeg seda muuta.
laevalaadija
Mingil hetkel hakkasid meieni jõudma värskelt vermitud keskmikud, mis kihasid ideedest ja möllasid dokkerist. Noh, lipp käes – teeme ära! Katseid oli kaks. Mõlemad ebaõnnestusid – ütleme nii, et suurte ambitsioonide tõttu, aga reaalse kogemuse puudumise tõttu. Kas oli vaja seda sundida ja igal võimalikul viisil lõpetada? See on ebatõenäoline – meeskond peab arenema vajalikule tasemele, enne kui saab sobivaid tööriistu kasutada. Lisaks puutusime Dockeri valmiskujutisi kasutades sageli kokku tõsiasjaga, et võrk ei töötanud korralikult (mis võis olla tingitud Dockeri enda niiskusest) või oli keeruline teiste konteinereid laiendada.
Milliste ebameeldivustega me kokku puutusime?
- Võrguprobleemid sillarežiimis
- Logide vaatamine konteineris on ebamugav (kui neid pole hostmasina failisüsteemis eraldi salvestatud)
- ElasticSearch külmub aeg-ajalt kummaliselt konteineri sees, põhjus pole selgunud, konteiner on ametlik
- Konteineri sees on vaja kasutada kesta - kõik on väga kooritud, tavapäraseid tööriistu pole
- Suured kogutud konteinerid – kallis ladustada
- Konteinerite suure suuruse tõttu on mitut versiooni keeruline toetada
- Pikem ehitusaeg, erinevalt teistest meetoditest (skriptid või deb-paketid)
Teisest küljest, miks on hullem juurutada Spring-teenust jar-arhiivi kujul sama debi kaudu? Kas ressursside eraldamine on tõesti vajalik? Kas tasub kaotada mugavad operatsioonisüsteemi tööriistad, toppides teenuse oluliselt vähendatud konteinerisse?
Nagu praktika on näidanud, pole see tegelikkuses vajalik, deb-paketist piisab 90% juhtudest.
Millal vana hea deb ebaõnnestub ja millal me dokkerit tegelikult vajame?
Meie jaoks oli see teenuste juurutamine pythonis. Paljud masinõppeks vajalikud teegid, mis ei kuulu operatsioonisüsteemi standardsesse distributsiooni (ja mis seal olid, olid valed versioonid), seadistustega häkkimine, vajadus erinevate versioonide järele samas hostsüsteemis elavate teenuste jaoks tõi kaasa see, et ainus mõistlik viis selle tuumasegu tarnimiseks oli dokk. Dokkikonteineri kokkupanemise töömahukus osutus väiksemaks kui mõte pakkida see kõik sõltuvustega eraldi deb-pakettidesse ja tegelikult ei võtaks seda keegi täie mõistuse juures ette.
Teine punkt, kus kavatseme Dockerit kasutada, on teenuste juurutamine sini-rohelise juurutusskeemi abil. Kuid siin tahan saada järk-järgult keerukust: kõigepealt ehitatakse deb-paketid ja seejärel ehitatakse neist dokkeri konteiner.
Snap paketid
Pöördume tagasi kiirpakkide juurde. Esimest korda ilmusid nad ametlikult Ubuntu versioonis 16.04. Erinevalt tavalistest deb- ja rpm-pakettidest kannab snap kõiki sõltuvusi. Ühelt poolt võimaldab see vältida teegikonflikte, teisalt on tekkiv pakett mahult suurem. Lisaks võib see mõjutada ka süsteemi turvalisust: snap-edastuse puhul peab kõiki kaasatud teekide muudatusi jälgima paketi loov arendaja. Üldiselt ei ole kõik nii lihtne ja universaalne õnn ei tule nende kasutamisest. Kuid sellegipoolest on see täiesti mõistlik alternatiiv, kui sama Dockerit kasutatakse ainult pakendamise tööriistana, mitte virtualiseerimiseks.
Selle tulemusena kasutame nüüd mõistlikus kombinatsioonis nii deb-pakette kui ka dokkeri konteinereid, mida võib-olla mõnel juhul asendame snap-pakettidega.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Mida te kohaletoimetamiseks kasutate?
-
Ise kirjutatud stsenaariumid
-
Kopeerige käsitsi FTP-sse
-
deb paketid
-
rpm paketid
-
klõpsatavad pakendid
-
Docker-pildid
-
Virtuaalse masina pildid
-
Kloonige kogu HDD
-
nukk
-
ansible
-
muu
109 kasutajat hääletas. 32 kasutajat jäi erapooletuks.
Allikas: www.habr.com