Kordagi mingil hetkel otsustasin kirjutada artikli konteinerite Docker ja deb-pakettide tarnimisest, kuid kui ma alustasin, viis mind mingil põhjusel tagasi kaugetesse aegadesse esimeste isiklike arvutite ja isegi kalkulaatorite juurde. Lühidalt, kuivadest võrdlustest Docker ja deb said hoopis sellised mõlgutused evolutsiooni teemal, mida ma esitan teie kohtusse.
Iga toode, ükskõik milline see ka ei oleks, peab kuidagi jõudma tootmisserveritesse, olema seadistatud ja käivitama. Just sellest räägibki see artikkel.
Mõlgutan mõtteid ajaloolises kontekstis, "mida näen – sellest ka räägin", mis jäi mulle silma, kui ma alles alustasin koodi kirjutamist ja mida ma praegu jälgin, mida me ise praegu kasutame ja miks. Artikkel ei pretendeeri täielikule uurimisele, mõned punktid on jäänud tähelepanuta, see on minu isiklik vaade sellele, mis oli ja mis on nüüd.
Nii et vanades heades aegades... varajaseim tarnimisviis, mida ma olen kogenud, olid magnetofonikassetid. Mul oli arvuti BK-0010.01...
Kalkulaatorite ajastu
Ei, oli veel varasemaid hetki, oli veel kalkulaator. ja .
Nii et kui mul oli , siis oli programmi edastamise viis tavaline ruuduline paberileht, millele oli kirja pandud programm, mille välja trükkimist esmal jõudis välja kirjutada käsitsi kalkulaatorisse. Tahad mängida (jah- jah, isegi selle eelajaloolise kalkulaatoriga oli mänge) – istud ja trükkid programmi kalkulaatorisse. Loomulikult, kui kalkulaator välja lülitati, kadus programm igavesse unustusse. Peale käsitsi välja kirjutatud kalkulaatorikoodide ilmusid programmid ajakirjades "Raadio" ja "Tehnika noortele" ning need trükiti ka tolle aja raamatutes.
Järgneva ümberkujundamise tegi kalkulaator , millel oli juba mingi sarnane energiat mitte sõltuv andmete salvestamine. Nüüd ei olnud mängu või programmi vaja enam käsitsi sisestada, vaid mõne nõia käeliigutusega nuppudel laadis see ennast automaatselt.
Kalkulaatori suurima programmi maht oli 105 sammu ja MK-52 pideva mälu suurus oli 512 sammu.
Muide, kui on neid kalkulaatorite fänne, kes seda artiklit loevad – artikli kirjutamise protsessi käigus leidsin ma ka Androidile kalkulaatori emulaatori ja programmid sellele. Edasi, minevikku!
Lühike kõrvalpõige MК-52-st (Vikipeediast)
MК-52 lendas kosmosesse laevaga „Soyuz TM-7“. Seda pidi kasutama maandumis trajektoori arvutamiseks, kui laeva arvuti ebaõnnestub.
MК-52 koos mälu laiendusplokiga „Elektronika-Astro“ tarniti alates 1988. aastast laevadele, kuhu kuulus ka navigatsiooni arvutuskompleks.
Esimesed personaalarvutid
Naaseme ajastutesse . Loomulikult on seal rohkem mälu ja koodi sisestamine paberilt enam ei tule kõne allagi (kuigi esialgu tegin ma just nii, sest teisi andmekandjaid polnud). Peamine tarkvara salvestamise ja tarnimise vahendiks saavad magnetofoni audiokassettid.
Kassettide peal salvestamine toimis tavaliselt ühe või kahe binaarfaili kujul, kõik muu oli sees. Usaldusväärsus oli väga madal, tuli hoida 2-3 koopiat programmist. Laadimisaeg oli samuti pettumustvalmistav, entusiastid katsetasid erinevate sageduskoodeerimistega, et neid puudusi ületada. Sel ajal ei tegelenud ma veel professionaalse tarkvara arendamisega (välja arvatud lihtsad programmid BASIC'is), seega ma ei oska kahjuks detaile selle kohta jagada, kuidas kõik sees toimis. Ainult see, et arvutis oli peamiselt ainult RAM, määras andmete salvestamise lihtsuse.
Usaldusväärsete ja suurte andmekandjate tulek
Hiljem ilmusid kõvakettad, lihtsustades kopeerimist ja parandades usaldusväärsust.
Aga olukord muutub kardinaalselt ainult siis, kui tekivad piisavalt suured kohalikud salvestusmahud kõvakettana.
Tarnimise tüüp muutub oluliselt: tekivad installatsiooniprogrammid, mis haldavad süsteemi seadistamise protsessi ja ka kustutamise järelpuhastust, kuna programme ei loeta enam lihtsalt mällu, vaid need kopeeritakse kohalikku salvestusse, millelt tuleb vajadusel eemaldada ka mittevajalik.
Samaaegselt suurenevad tarnitava tarkvara keerukus.
Failide arv tarnimises tõuseb ühelt sadadele ja tuhandetele, hakkavad tekkima versioonikonfliktide probleemid ja muud rõõmud, kui mitmed programmid kasutavad samu andmeid.
Toll, kui ma veel ei teadnud Linuxist, elasin MS DOSi ja hiljem Windowsi maailmas, kirjutades Borland Pascalis ja Delphies, aeg-ajalt pilguga C++ poole. Tooteid tarnides kasutasid paljud sel ajal InstallShieldi. , mis lahendas edukalt kõik tarkvara juurutamise ja konfigureerimise ülesanded.
Interneti ajastu
Taas toimus tarkvarasüsteemide keerukuse suurenemine, monoliitsetelt ja töölaua rakendustelt liikusime hajusate süsteemide, õhukeste klientide ja mikroteenuste suunas. Nüüd on vaja konfigureerida mitte üht rakendust, vaid nende kogumit, ja nii, et need kõik omavahel tööle hakkaksid.
Kogu kontseptsioon on täielikult muutunud, tuli Internet ja algas pilveteenuste ajastu. Alles oli see algstaadium, veebilehtede kujul, ja kedagi ei tülitanud teenustega unistada. Kuid see oli pöördepunkt tööstuses nii arendamise kui ka rakenduste tarnimise osas.
Märkasin ise, et sel hetkel toimus arendajate põlvkondade vahetus (või oli see vaid minu keskkonnas), ning tekkis tunne, et kõik vanad head tarnimise viisid unustati hetkega ja kõik algas otsast peale: kogu tarnimine hakkas toimuma käsitsi kirjutatud skriptide abil ning seda nimetati uhkelt "Jätkuv tarnimine". Tegelikkuses algas mingi kaostee, kui vana oli unustatud ja ei kasutatud, aga uut ei olnud lihtsalt olemas.
Mäletan aegu, mil meie ettevõttes, kus ma siis töötasin (ei nimeta seda), inimesed lihtsalt kogusid jar-faile IDE-s ja vaikisid rahulikult SVN-i, selle asemel et teha kogumist ant'i kaudu (maven ei olnud siis veel populaarne või polnud üldse). Vastavalt sellele koosnes juurutamine faili tõmbamisest SVN-ist ja selle SSH kaudu sihtmasinasse kopeerimisest. Nii lihtsalt ja totralt.
Samal ajal tehti lihtsate PHP-veebilehtede tarnimine täiesti primitiivsel viisil, kopeerides parandatud faili FTP kaudu sihtmasinasse. Mõnikord polnud isegi sellist jõudmist - koodi muudeti otse produtseeriva serveri peal, ja oli eriline luksus, kui kuskil olid varukoopiad.
RPM- ja DEB-paketid
Teisest küljest on Interneti arengu käigus üha populaarsemaks saanud UNIX-i sarnased süsteemid. Just sel ajal avastasin ma RedHat Linux 6, umbes aastal 2000. Loomulikult olid ka seal olemas teatud vahendid tarkvara tarnimiseks. Vastavalt Vikipeedia andmetele ilmus RPM peamine paketihaldur juba 1995. aastal RedHat Linux 2.0 versioonis. Sellest ajast alates ja kuni tänaseni tarnitakse süsteem RPM-pakettidena, mis edukalt eksisteerivad ja arenevad.
Debiani perekonna distributsioonid järgnesid sarnasele teele ning rakendasid tarnimist deb-pakettide vormis, mis kehtib ka tänapäevani.
Paketihaldurid võimaldavad tarnida tarkvaratooteid, konfigureerida neid installatsiooni käigus, hallata erinevate pakettide vahelisi sõltuvusi, eemaldada tooteid ja koristada üleliigset deinstalleerimise käigus. Peaaegu kõik vajalik on selles, seetõttu on nad püsinud mitmeid aastakümneid praktiliselt muutumatuna.
Pilvetehnoloogia lisas paketihalduritesse paigaldamise mitte ainult füüsilistelt andmekandjatelt, vaid ka pilveerikutest, kuid põhimõtteliselt pole suurt midagi muutunud.
Tasub märkida, et praegu on teatud suundumused deb-pakettidest loobumise ja snap-pakettide suunas, kuid sellest räägime hiljem.
Seega kasvas see uus pilvearendajate põlvkond, kes ei teadnud DEB-st ega RPM-ist, tasapisi ning omandas kogemusi. Tooteid keerukamaks muudetakse ning vaja on loogilisemaid tarnimise viise, kui FTP, bash-skriptid ja sarnased üliõpilaste tegemised.
Siin tuleb mängu Docker, omamoodi virtualiseerimise, ressursside eraldamise ja tarnimise viis. See on praegu populaarne ja nooruslik, kuid kas on vaja kõigi jaoks? Kas see on imerohi?
Olen märganud, et väga tihti pakutakse Dockerit mitte kui mõistlikku valikut, vaid lihtsalt seetõttu, et sellest räägitakse kogukonnas ja ainult seda tunnevad need, kes seda pakuvad. Teisest küljest on vanade, headeks jäävate pakkimisse süsteemide kohta enamasti vaikimine — need on olemas ja teevad oma tööd vaikselt ja märkamatult. Sellises olukorras ei jää muud valikut, valik on ilmne — Docker.
Püüan jagada kogemusi, kuidas meie juures Dockerit juurutati ja mis selle tulemusena välja tuli.
Isetehitatud skriptid
Alguses olid meil bash-skriptid, mis panid jar-arhiivid õigetele masinatele tööd. Selle protsessi juhtis Jenkins. See töötas edukalt, sest jar-arhiiv ise on juba komplekt, mis sisaldab klasse, ressursse ja isegi konfiguratsiooni. Kui panna sinna kõik maksimaalselt - skripti dekompresseerimine ei ole kõige keerulisem, mida tuleb teha.
Aga skriptidel on mitu puudust:
- skriptid kirjutatakse tavaliselt kiiresti ja seetõttu on nad nii primitiivsed, et sisaldavad ainult ühte kõige õnnestunumat stsenaariumi. Sellele aitab kaasa asjaolu, et arendaja on huvitatud kiirest kohaletoimetamisest, samas kui normaalse skripti jaoks on vajalik märkimisväärne hulk ressursse.
- eelneva punkti tagajärjel skriptid ei sisalda desinstallatsiooniprotseduuri.
- puudub määratud uuendamisprotseduur.
- uue toote ilmudes tuleb kirjutada uus skript.
- puudub sõltuvuste tugi.
Muidugi, võiks kirjutada keeruka skripti, kuid nagu ma rääkisin varem - see on arendusaeg, ja mitte väike, kuid nagu teada, alati napp.
See piirab selgelt selle meetodi kasutamise ringi ainult kõige lihtsamatele süsteemidele. On aeg seda muuta.
Docker
Mõnes hetkes hakkasid meie juurde tulema värsked keskmised arendajad, kes pulbitsevad ideedest ja unistavad dockerist. Noh, lipp kätte — teeme! Olid kaks katset. Mõlemad ebaõnnestusid — ütleme nii, suurte ambitsioonide tõttu, kuid reaalse kogemuse puudumise tõttu. Kas oleks pidanud sundima ja mistahes jõududega lõpetama? Vaevalt — kollektiiv peab evolutsiooniliselt kasvama vajalikule tasemele, enne kui suudab kasutada vastavaid tööriistu. Kõigele lisaks, kasutades valmis dockeripilte, olenemata sellest, et tihti kohtusime olukordadega, kus seal ei töötanud võrguühendus õigesti (mis võib-olla oli seotud ka docker enda toore sisehaigusega) või oli võõraste konteinerite laiendamine keeruline.
Milliste ebamugavustega me silmitsi seisime?
- Probleemid võrguühenduses bridge-režiimis.
- Containeris logide jälgimine on ebamugav (kui need ei ole eraldi välja viidud host-masina failisüsteemi).
- Aeg-ajalt kummaline ElastSearch'i hangumine konteineris, põhjust ei suudetud kindlaks teha, konteiner on ametlik.
- Containeris shell'i kasutamine on ebamugav — kõik on tugevalt piiratud, tuttavaid tööriistu pole.
- Suur konteinerite suurus – kallis ladustada.
- Konteinerite suure suuruse tõttu on keeruline hallata mitmeid versioone.
- Pikem kogumisprotsess, võrreldes teiste meetoditega (skriptide või deb-pakettidega).
Aga miks on jar-arhiivina deployimine Spring-teenus halvem kui sama deb kaudu? Kas ressursside isoleerimine on tõeliselt vajalik? Kas tasub kaotada operatsioonisüsteemi mugavad tööriistad, surudes teenuse tugevalt piiratud konteinerisse?
Kogemus on näidanud, et see pole tegelikult vajalik, deb-paketist piisab 90% juhtudest.
Millal siis ikkagi vana hea deb ei tööta ja millal on tõeliselt vajalik Docker?
Meie jaoks oli see teenuste juurutamine Pythonis. Paljud masinõppe jaoks vajalikud teegid, mis pole operatsioonisüsteemi standardtootel (ja see, mis seal oli – ei olnud õigeid versioone), häkkimine seadistustega, vajadus erinevate versioonide järele eri teenuste jaoks, mis elavad samal host-süsteemil, viis selleni, et ainsaks mõistlikuks viisiks selle põhisegu tarnimiseks osutus Docker. Docker-konteineri koostamise töömahukus osutus madalamaks, kui idee pakkida kõik need eraldi deb-pakettidesse koos sõltuvustega, ja ausalt öeldes ei võtaks keegi arukalt seda ette.
Teine aspekt, kus plaanitakse Dockerit kasutada, on teenuste juurutamine blue-green deploy skeemi kaudu. Siin soovitakse aga järkjärgulist keerukuse suurenemist: esiteks koostatakse deb-paketid ja seejärel koostatakse neist Docker-konteiner.
Snap-paketid.
Tagasi snap-pakkide juurde. Need ilmusid esmakordselt ametlikult Ubuntu 16.04-s. Erinevalt tavapärastest deb-pakettidest ja rpm-pakettidest, sisaldavad snap-paketid kõiki sõltuvusi. Ühelt poolt aitab see vältida raamatukogude konflikte, teisalt on tulemuseks paketi suuruseks olulisem suurus. Lisaks võib see mõjutada süsteemi turvalisust: snapide tarnimisel peab iga kaasatud teegi muudatuste jälgimisega tegelema paketti koostav arendaja. Üldiselt ei ole kõik nii ühesugune ja igasugu õnn ei saabu nende kasutamisest. Siiski, see on mõistlik alternatiiv, kui Dockerit kasutatakse ainult pakendamise, mitte virtualiseerimise vahendina.
Kokkuvõtteks, meil on praegu mõistlikus kombinatsioonis nii deb-pakette kui ka Docker-konteinereid, mida me võib-olla teatud juhtudel asendame snap-pakettidega.
Ainult registreeritud kasutajad saavad küsitluses osaleda. , palun.
Mida teie tarnimiseks kasutate?
Isetehitatud skriptid
Kopeerime käsitsi FTP kaudu
deb-paketid
rpm-paketid
snap-paketid
Docker-pildid
Virtuaalmasinate pildid
Kloonime HDD täielikult
puppet
ansible
Teine
Hääletas 109 kasutajat. Hoidis tagasi 32 kasutajat.
Allikas: habr.com
