Rakenduse loomine, mis varundab igasugustel jaotustel, on keeruline ülesanne. Veeam Agent for Linuxi töötagamiseks Red Hat 6 ja Debian 6 jaotustel kuni OpenSUSE 15.1 ja Ubuntu 19.04 tuleb lahendada mitmeid probleeme, eriti kui arvestada, et toote koosseisus on ka kernelimoodul.
Artikkel on koostatud konverentsi ettekande materjalide alusel. .
Linux ei ole lihtsalt üks populaarsemaid operatsioonisüsteeme. Tegelikult on see platvorm, millel saab luua midagi ainulaadset, midagi oma. Seetõttu on Linuxi põhjal palju jaotuseid, mis erinevad oma programmikomponentide kogumi poolest. Ja siin tekib probleem: et tarkvara toode töötaks igasugustel jaotustel, tuleb arvesse võtta igaühe omadusi.
Pakettide haldajad. .deb vs .rpm
Alustame ilmsest probleemist toote jaotamise osas erinevatele jaotustele.
Kõige tavalisem viis tarkvaratootesid levitada on paketi panemine repo, et süsteemi sisse ehitatud pakettide haldaja saaks selle sealt installida.
Kuid populaarseid pakettformaate on meil kaks: rpm ja deb. Seega tuleb toetada igaüht neist.
Deb-pakettide maailmas on ühilduvuse tase hämmastav. Üks ja sama pakett installitakse ja töötab sama hästi nii Debian 6-l kui ka Ubuntu 19.04-l. Pakettide loomise ja nendega töötamise standardid, mis on paika pandud vanades Debian jaotustes, jäävad asjakohaseks ka moodsates Linux Mint ja elementary OS jaotustes. Seetõttu on Veeam Agent for Linuxi jaoks piisav üks deb-pakett iga riistvara platvormi jaoks.
Kuid rpm-pakettide maailmas on erinevused suured. Esiteks, kuna on kaks täiesti sõltumatut tootjat — Red Hat ja SUSE — kellele ühilduvus üldse ei ole vajalik. Teiseks, neil tootjatel on jaotused tehnilise toe ja eksperimentaalsete versioonidega. Nende vahel ei ole ühilduvus vajalik. Tulemuseks on see, et el6, el7 ja el8 jaoks on oma paketid. Eraldi pakett Fedora jaoks. Paketid SLES11 ja 12 jaoks ning eraldi openSUSE jaoks. Peamine probleem on sõltuvustes ja paketide nimedes.
Sõltuvuste probleem
Kahjuks on samad paketid tihti erinevates jaotustes erinevate nimedega. Allpool on mittetäielik nimekiri veeam paketi sõltuvustest.
EL7 jaoks:
SLES 12 jaoks:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- fuse-libs
- file-libs
- veeamsnap = 3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp = 3.0.2.1185
Tulemuseks on sõltuvuste loend, mis osutub distributsioonile ainulaadseks.
Halvem on see, kui vana paketi nime all hakkab peituma uuendatud versioon.
Näide:
Fedora 24-s on pakett uuendatud ncurses versioonilt 5 versioonile 6. Meie toode oli üles ehitatud just 5. versioonile, et tagada ühilduvus vanade distributsioonidega. Fedora 24-s vana 5. versiooni raamatukogu kasutamiseks tuli kasutada paketti ncurses-compat-libs.
Tulemuseks on Fedora jaoks kaks paketti, erinevate sõltuvustega.
Edasi läheb huvitavamaks. Pärast järjekordset distributsiooni uuendamist on pakett ncurses-compat-libs 5. versiooniga raamatukogu kättesaamatu. Jagajale on koormav uue distributsiooni alla vanade raamatukogude vedamine. Mõne aja pärast kordus probleem ka SUSE distributsioonides.
Tulemuseks on see, et mõnede distributsioonide puhul tuli loobuda otsesest sõltuvusest ncurses-libs, ning toodet kohandada nii, et see saaks töötada iga raamatukogu versiooniga.
Üldse, 8. versioonis Red Hat'is ei ole enam meta-paketti python, mis viitas vanale headusele python 2.7. On olemas python2 ja python3.
Alternatiiv pakihalduritele
Sõltuvuste probleem on vana ja ammu nähtud. Mõtle näiteks Dependency hell'ile.
Erinevaid raamatukogusid ja rakendusi tuleb ühendada nii, et nad kõik stabiilselt töötaksid ja ei konfliktiks — tegelikult just seda probleemi püüab lahendada iga Linuxi jagaja.
Teistmoodi püüab seda probleemi lahendada paketihaldur Snappy Canonicalilt. Peamine idee: rakendus töötab isoleeritud ja põhisüsteemi kaitstud liivakasti keskkonnas. Kui rakendusele on vajalikud raamatukogud, siis tuuakse need koos rakendusega.
Flatpak lubab samuti rakendusi käivitada liivakastis, kasutades Linuxi konteinerite süsteemi. Liivakasti ideed kasutab ka AppImage.
Need lahendused võimaldavad luua ühe paketi igasuguste distributsioonide jaoks. Juhtum ilmselgelt Flatpak rakenduse installimine ja käivitamine on võimalik isegi ilma administraatori teadmata.
Peamine probleem on see, et mitte kõik rakendused ei saa töötada liivakastis. Mõned vajavad vahetut juurdepääsu platvormile. Ma ei hakka räägima kernelimoodulitest, mis on tugevalt sõltuvad kernelist ja mis ei sobi üldse liivakasti kontseptsiooni.
Teine probleem on see, et ettevõttekeskkonnas populaarsed distributsioonid Red Hat ja SUSE ei ole Snappy ja Flatpak'i toe osas veel arendustööd teinud.
Seoses sellega ei ole Veeam Agent for Linux ei ega .
Kokkuvõtteks pakettide haldurite küsimusest tahan märkida, et on võimalus loobuda täielikult pakettide halduritest, ühendades üheks paketiks binaarfailid ja installatsiooniskripti.
Selline bundle võimaldab luua ühe ühise paketi erinevate jaotuste ja platvormide jaoks, viies läbi interaktiivse installatsiooniprotsessi, rakendades vajalikku kohandamist. Olen selliste pakettidega Linuxi jaoks kokku puutunud vaid VMware'i kaudu.
Uuenduste probleem
Isegi kui kõik sõltuvusprobleemid on lahendatud, võib programm samas jaotuses üsna erinevalt töötada. Probleem on uuendustes.
On 3 uuendamisstrateegiat:
- Kõige lihtsam on mitte kunagi uuendada. Seadistasin serveri ja unustasin. Miks uuendada, kui kõik töötab? Probleemid algavad kohe, kui helistad tugiteenusesse. Jaotuse looja toetab ainult värskendatud väljaannet.
- Saab usaldada jaotajat ja seadistada automaatse värskendamise. Sel juhul on tõenäoline, et helistamine tugiteenusesse toimub kohe pärast ebaõnnestunud värskendust.
- Manuaalse värskendamise võimalus pärast seda, kui see on testitud katse infrastruktuuris – on kõige usaldusväärsem, kuid kallis ja tööintensiivne. Kaugelki mitte kõik ei saa seda endale lubada.
Kuna erinevad kasutajad rakendavad erinevaid uuendamisstrateegiaid, tuleb toetada nii kõige värskemat väljaannet kui ka kõiki varem välja antud versioone. See keerustab nii arendusprotsessi kui ka testimisprotsessi, lisades peavalu tugiteenusele.
Mitmekesisus riistvaraplatvormides
Erinevad riistvaraplatvormid on probleem, mis on suuresti spetsiifiline just native-koodile. Vähemalt tuleb koguda binaarfaile iga toetatud platvormi jaoks.
Veeam Agent for Linux projektis ei suuda me mingil moel toetada midagi RISC-iga seotud.
Ei hakka sellele küsimusele süvitsi laskuma. Tahan vaid välja tuua peamised probleemid: platvormispetsiifilised tüübid, nagu size_t, struktuuride joondamine ja byte order.
Statiline ja/ või dünaamiline lingimine
Kuid küsimus, "Kuidas lingida raamatukogudega - dünaamiliselt või staatiliselt?" vajab arutamist.
Tavaliselt kasutavad C/C++ rakendused Linuxis dünaamilist linkimist. See töötab suurepäraselt, kui rakendus on spetsiaalselt koostatud konkreetse jaotise jaoks.
Kui aga on eesmärk haarata erinevaid jaotisi ühe binaarfailiga, tuleb orienteeruda kõige vanemale toetatud jaotisele. Meie jaoks on see Red Hat 6. See sisaldab gcc 4.4, mis ei toeta isegi C++11 standardit. .
Me koostame oma projekti gcc 6.3 abil, mis toetab täielikult C++14. Loomulikult tuleb sellisel juhul Red Hat 6 jaoks raamatukogud libstdc++ ja boost endaga kaasa võtta. Lihtsaim on nendega staatiliselt linkida.
Kahjuks ei ole kõikide raamatukogudega võimalik staatiliselt linkida.
Esiteks, süsteemi raamatukogud, nagu libfuse, libblkid peavad olema dünaamiliselt linkitud, et olla kindel, et need on ühilduvad tuuma ja selle moodulitega.
Teiseks, litsentsidega on mõned eripärad.
GPL litsents lubab raamatukogusid linkida ainult avatud lähtekoodiga koodiga. MIT ja BSD lubavad staatilist linkimist ja võimaldavad raamatukogusid projektis kasutada. LGPL seevastu ei paista olevat vastu staatilisele linkimisele, kuid nõuab, et tugifailid, mis on vajalikud linkimiseks, oleksid üldiselt kergesti kätte saadavad.
Üldiselt kaitseb dünaamiline linkimine vajadusest midagi esitada.
C/C++ rakenduste koostamine
C/C++ rakenduste koostamiseks erinevatele platvormidele ja jaotistele piisab sobiva versiooniga gcc leidmisest või koostamisest ning spetsiifiliste architektuuride jaoks ristkompilaatorite kasutamisest, samuti kõikide raamatukogude kogumi koostamisest. See töö on täiesti teostatav, kuid üsna vaevaline. Ja ei ole mingit garantiid, et valitud kompilaator ja raamatukogud tagavad töökõlbuliku variandi.
Ilmselge pluss: infrastruktuur lihtsustub märgatavalt, kuna kogu koostamisprotsessi saab teha ühel masinal. Lisaks piisab ühe arhitektuuri jaoks ühe komplekti binaarfailide kogumisest, et neid saab pakendada erinevate jaotiste pakettidesse. Just nii koostatakse veeam pakette Veeam Agent for Linux jaoks.
Selle asemel võite lihtsalt ette valmistada build-farm, see tähendab mitu masinat kogumise jaoks. Iga selline masin tagab rakenduse kompileerimise ja paketi koostamise konkreetse jaotuse ja teatud arhitektuuri jaoks. Sellisel juhul toimub kompileerimine nende vahenditega, mille on ette valmistanud jaotaja. Seega etapp kompilaatori ettevalmistamisest ja raamatukogude valimisest langeb ära. Lisaks saab kogumisprotsessi hõlpsasti paralleelseks muuta.
Kuid sellise lähenemise puhul on üks puudus: iga jaotuse jaoks ühe arhitektuuri raames tuleb koostada oma binaarfailide komplekt. Samuti on puuduseks see, et selline masinate hulk vajab hooldamist, samuti peab olema eraldatud suur hulk kettaruumi ja operatiivmälu.
Nii koostatakse KMOD pakette veeamsnap tuuma mooduli jaoks Red Hat jaotuste jaoks.
Open Build Service
Kolleegid SUSE-st on proovinud ellu viia mingi kuldse kesktee spetsiaalse teenuse näol rakenduste kompileerimiseks ja pakettide koostamiseks — .
Sisuliselt on see hüperviisor, mis loob virtuaalse masina, installib sinna kõik vajalikud paketid, viib läbi rakenduse kompileerimise ja paketi koostamise selles isoleeritud keskkonnas, pärast mida selline virtuaalne masin vabastatakse.
OpenBuildService'i ellu viidud ajastaja määrab ise, kui palju virtuaalseid masinaid ta võib käivitada pakettide koostamise optimaalsete kiirusede jaoks. Sisseehitatud allkirjastamise mehhanism allkirjastab paketid ja laadib need sisseehitatud hoidlasse. Sisseehitatud versioonihalduse süsteem salvestab muudatuste ja koostamiste ajaloo. Jääb vaid lisada sellesse süsteemi oma allikakoodid. Isegi serverit tõstatama pole tingimata vajalik, võib kasutada avatud lahendust.
Siin on siiski probleem: selline kombain on raske olemasolevasse infrastruktuuri sobitada. Näiteks versioonihaldust ei ole vaja, meil on juba oma allikate jaoks olemas. Allkirjastamise mehhanism on meil erinev: kasutatakse spetsiaalset serverit. Hoidlat ka pole vaja.
Lisaks on teiste jaotuste tugi — näiteks Red Hat — üsna napilt teostatav, mis on täiesti mõistetav.
Sellise teenuse eeliseks on kiire toewus uue SUSE jaotuse versiooni jaoks. Enne ametlikku välja kuulutamist laaditakse koostamiseks vajalikud paketid avalikku reposse. Nimekirjas saadaolevatest jaotustest OpenBuildService'is ilmub uus. Paneme linnukese ja see lisatakse koostamisplaani. Seega toimub uue jaotuse versiooni lisamine praktiliselt ühe klikiga.
Meie infrastruktuuris, kus kasutatakse OpenBuildService'i, koostatakse kõik KMP pakettide mitmekesisus veeamsnap mooduli tuumaks SUSE jaotustele.
Edasi soovin peatuda küsimustel, mis on spetsiifilised just tuummoodulitele.
kernel ABI
Linuxi tuummoodulid on ajalooliselt jaotatud allika tekstidena. Fakt on see, et tuuma loojad ei koorma end tuumamoodulite stabiilse API toega, rääkimata binaartasemest, kABI-st.
Et koostada moodul virtuaalse tuuma jaoks, on hädasti vajalik just selle tuuma päised, ja see töötab ainult sellel tuumal.
DKMS võimaldab automatiseerida moodulite koostamisprotsessi tuuma uuendamisel. Tulemusena kasutavad Debian'i (ja tema mitu sugulast) reposte moodulite kasoe või tootja repostest või näiteks DKMSi abil allika tekstidest koostatud mooduleid.
Kuid see olukord ei rahulda Enterprise-segmenti eriti. Erakoodide levitajad soovivad tooteid jaotada koostatuna binaaridena.
Administraatorid ei taha production-serverites hoida arendustööriistu turvalisuse kaalutlustel. Enterprise Linuxi levitajad - nagu Red Hat ja SUSE - on otsustanud, et nad saavad oma kasutajatele stabiilse kABI pakkuda. Tulemuseks on ilmnenud KMOD paketid Red Hatile ja KMP paketid SUSE-le.
Selle lahenduse olemus on üsna lihtne. Konkreetse jaotuse versiooni jaoks API tuum külmutatakse. Levija kuulutab välja, et ta kasutab just tuuma, näiteks 3.10, ja toob sisse ainult parandused ja täiustused, mis ei mõjuta tuuma liideseid, ning esimeseks tuumaks koostatud mooduleid võib kasutada kõigi järgnevate jaoks ilma uuesti kokku panemata.
Red Hat teatavad kABI ühilduvusest oma distributsiooniga kogu elutsükli vältel. See tähendab, et rhel 6.0 (novembri 2010 väljaanne) kokkupandud moodul peaks töötama ka versioonis 6.10 (juuni 2018 väljaanne). Ja see on peaaegu 8 aastat. Loomulikult on see üsna keeruline ülesanne.
Oleme fikseerinud mitmeid juhtumeid, kus kABI ühilduvuse probleemide tõttu lakkas moodul veeamsnap töötamast.
Pärast seda, kui RHEL 7.0 jaoks kokku pandud moodul veeamsnap osutus RHEL 7.5 tuumaga ühilduvaks, kuid laaditi siiski sisse ja garanteeritult kukutas serveri, loobusime kABI ühilduvuse kasutamisest RHEL 7 puhul täiesti.
Praegu sisaldab KMOD pakett RHEL 7 iga versiooni väljaande ja skripti, mis tagab mooduli laadimise.
SUSE lähenes kABI ühilduvuse ülesandele ettevaatlikumalt. Nad tagavad kABI ühilduvuse ainult ühe teeninduspaketi piires.
Näiteks ilmus SLES 12 september 2014. Ja SLES 12 SP1 juba detsembris 2015, st möödus veidi üle aasta. Kuigi mõlemad väljaanded kasutavad tuuma 3.12, on nad kABI ühilduvad. On selge, et kABI ühilduvuse säilitamine ainult aasta jooksul on oluliselt lihtsam. Aasta jooksul uuendamise tsükkel ei tohiks moodulite loojaid häirida.
Tulemusena sellisest poliitikast SUSE, oleme oma mooduli veeamsnap osas kABI ühilduvuse probleeme fikseerinud. Tõsi, SUSE paketid on peaaegu kordades rohkem.
Patchid ja tagasitootmised
Kuigi jaotajad püüavad tagada kABI ühilduvust ja tuuma stabiilsust, püüavad nad ka parandada jõudlust ja kõrvaldada vigu selle stabiilse tuuma puhul.
Selles osas jälgivad enterprise linuxi tuuma arendajad oma «veaotsingus» vanilje tuuma muudatusi ja kantakse need üle oma «stabiilsesse».
Mõnikord toob see kaasa uusi .
Red Hati viimases 6. väljaandes oli ühe väiksema uuenduse tõttu viga. See põhjustas seda, et moodul veeamsnap garanteeritult kukutas süsteemi, kui snapshots vabastati. Võrdlesime tuuma lähtekoode enne ja pärast uuendust ning selgus, et kõik oli tingitud backportist. Sarnane parandamine tehti vanilje tuuma versioonis 4.19. Ainult et vanilje tuumas töötas see parandamine normaalselt, kuid selle üleviimisel «stabiilsesse» 2.6.32 tekkis probleem spin-lock'iga.
Muidugi, vigu juhtub kõigil ja alati, aga kas oli tõesti mõistlik tuua kood versioonist 4.19 versiooni 2.6.32, riskides stabiilsusega?.. Ma ei ole selles kindel...
Halvimal juhul, kui turundus tõmbab köit "stabiilsus" "uuendamine". Turundusosakonnale on vajalik, et uusima loodud jaotise tuum oleks stabiilne, samal ajal aga oleks parem jõudluses ja omaks uusi funktsioone. See viib kummaliste kompromissideni.
Kui proovisin koguda moodulit tuumal 4.4 SLES 12 SP3, avastasin üllatusega, et seal on funktsioone puhtast 4.8. Minu arvates sobib SLES 12 SP3 tuuma 4.4 plokkide sisenemine rohkem kokku tuumaga 4.8 kui eelneva stabiilse 4.4 tuumaga SLES 12 SP2. Milline oli protsent 4.8 tuumast tervikuna SLES 4.4 jaoks SP3, ma ei oska öelda, aga ma ei saa seda tuuma veel stabiilseks 4.4 nimetada.
Kõige ebameeldivam on see, et mooduli kirjutamisel, mis töötaks ühtemoodi erinevates tuumades, ei saa enam toetuda tuuma versioonile. Tuleb arvesse võtta ka jaotust. Hea, et mõnikord saab toetuda defineeringule, mis tuleb koos uue funktsionaalsusega, kuid selline võimalus ei ilmne alati.
Seetõttu kasvab kood kummaliste tingimuslike kompileerimise direktiivide hulka.
On ka patše, mis muudavad dokumenteeritud tuuma API-d.
Törmarinimega jaotusele 5.16 ja olin väga üllatunud, nähes, et lookup_bdev funktsiooni sissekannete nimekiri oli selles tuumas muutunud.
Kogumise nimel pidin makefile'i lisama skripti, mis kontrollib, kas lookup_bdev funktsioonil on maski argument.
Tuuma moodulite allkiri
Kuid naaseme pakettide levitamise küsimuse juurde.
Üks stabiilse kABI eeliseid on see, et tuuma mooduleid saab binaarfailina allkirjastada. Sellisel juhul võib arendaja olla kindel, et moodul ei ole olnud juhuslikult kahjustatud ega tahtlikult muudetud. Seda saab kontrollida käsuga modinfo.
Red Hati ja SUSE jaotused võimaldavad mooduli allkirja kontrollida ja laadida seda ainult siis, kui süsteemis on registreeritud vastav sertifikaat. Sertifikaat on avalik võtme, millega moodul allkirjastatakse. Me levitame seda eraldi paketina.
Probleem on selles, et sertifikaadid võivad olla kas sisse ehitatud (neid kasutavad distributsioonid) või peavad olema sisestatud energia sõltumatusse EFI mällu utiliidi kaudu. mokutil. Utiliit mokutil sertifikaadi installimisel eeldab süsteemi taaskäivitamist ja juba enne operatsioonisüsteemi tuvastamist palub administraatoril lubada uue sertifikaadi laadimist.
Seega, sertifikaadi lisamine nõuab administraatori füüsilist ligipääsu süsteemile. Kui masin asub mõnes pilves või lihtsalt eemal serveris ja juurdepääs on saadaval ainult võrgu kaudu (näiteks ssh), ei ole sertifikaadi lisamine võimalik.
EFI virtuaalmasinates
Kuigi EFI-d toetavad peaaegu kõik emaplaatide tootjad, ei pruugi süsteemi installimisel administraator mõelda EFI vajadusele ja see võib olla välja lülitatud.
Kuid mitte kõik hüperviisorid ei toeta EFI-d. VMWare vSphere toetab EFI-d alates versioonist 5.
Microsoft Hyper-V on samuti saanud EFI toe alates Hyper-V for Windows Server 2012R2.
Kuid vaikimisi on see funktsioon Linuxi masinate jaoks välja lülitatud, mistõttu sertifikaati ei ole võimalik installida.
vSphere 6.5-s saab seadistada valiku Secure Boot ainult vanas veebiliidese versioonis, mis töötab Flashis. HTML-5 põhine Web UI jääb veel alla.
Eksperimentaalsed distributsioonid
Ja lõpuks vaatame eksperimentaalsete distributsioonide ja ametliku toeta distributsioonide küsimust. Ühest küljest ei pruugi sellised distributsioonid tõsistes organisatsioonides levinud olla. Ametlikku tuge neil distributsioonidel ei ole. Seega ei saa sellise distributsiooni toodangule tehnilist tuge tagada.
Kuid sellised distributsioonid muutuvad mugavaks platvormiks uute eksperimentaalsete lahenduste proovimiseks. Näiteks, Fedora, OpenSUSE Tumbleweed või Debian Unstable versioonid. Need on üsna stabiilsed. Nendes on alati uued programmiversioonid ja alati uus kernel. Aasta pärast võib see eksperimentaalne funktsionaalsus ilmneda uuendatud RHEL-is, SLES-is või Ubuntus.
Nii et kui eksperimentaalses distributsioonis midagi ei tööta, on see põhjus probleemiga tegeleda ja see lahendada. Peame olema valmis, et see funktsionaalsus ilmub peagi kasutajate tootmisserveritesse.
Praegu keelatud versiooni 3.0 ametlikult toetatud distribuutide nimekirja saate uurida. . Kuid tegelik distribuutide nimekiri, millega meie toode suudab töötada, on palju laiem.
Isiklikult oli mul huvi katsetada OS-i „Elbrus”. Pärast veeam paketi täiendamist installisime meie toote ja see töötas. Sellest katsest kirjutasin Habr's. .
Uute distribuutide toetamine jätkub. Ootame versiooni 4.0 ilmumist. Peagi peaks beetaversioon välja tulema, nii et jälgige meie. !
Allikas: habr.com
