Rakenduse loomine, mis töötaks igasuguste jaotustega, on keeruline ülesanne. Veeam Agent for Linuxi töö tagamiseks Red Hati 6 ja Debian 6 jaotustes kuni OpenSUSE 15.1 ja Ubuntu 19.04-ni tuleb lahendada mitmeid probleeme, arvestades, et tarkvaratoote koosseisu kuulub ka tuumamoodul.
Artikkel on koostatud konverentsil esitatud materjalide põhjal .
Linux ei ole lihtsalt üks populaarseimaid ОС-e. Tegelikult on see platvorm, mille alusel saab luua midagi ainulaadset, midagi enda oma. Selle tulemusena on Linuxil palju jaotusi, mis erinevad tarkvarakomponentide komplekti poolest. Siit tuleb probleem: et toode töötaks igas jaotuses, tuleb arvestada igaühe eripäradega.
Pakettide haldurid. .deb vs .rpm
Alustame ilmsest probleemist toote levitamisel erinevate jaotuste jaoks.
Kõige tüüpilisem viis tarkvaratoodete levitamiseks on pakkida see repositooriumisse, et süsteemi sisseehitatud pakettide haldur saaks selle sealt installida.
Kuid meil on kaks populaarset pakettformaati: rpm ja deb. See tähendab, et tuleb toetada igaüht.
Deb-pakettide maailmas on ühilduvuse tase muljetavaldav. Üks ja sama pakett installitakse ja töötab sama hästi nii Debian 6-l kui ka Ubuntu 19.04-l. Pakettide loomise ja käsitlemise protsessi standardid, mis on omased vanadele Debian'i distributsioonidele, jäävad aktuaalseks ka uutmoodi Linux Mint'i ja elementary OS'i puhul. Seega on Veeam Agent for Linux'i jaoks piisav üks deb-pakett iga riistvaralise platvormi jaoks.
Aga rpm-pakettide maailmas on erinevused suured. Esiteks, kuna on olemas kaks täiesti sõltumatut distributsjonit: Red Hat ja SUSE, mille vahel ei ole ühilduvust vaja. Teiseks, neil distributsjonidel on toetatud ja eksperimentaalsed distributsioonid. Nende vahel ei ole ka ühilduvust vaja. Meil selgub, et el6, el7 ja el8 jaoks on oma paketid. Fedora jaoks on eraldi pakk. Pakettide jaoks SLES11 ja 12 ning eraldi openSUSE jaoks. Peamine probleem seisneb sõltuvustes ja pakettide nimedes.
Sõltuvuste probleem
Kahjuks on samad paketid sageli erinevate nimede all erinevates distributsioonides. Allpool on mittetäielik veeam-paketi sõltuvuste nimekiri.
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
Seetõttu on sõltuvuste loend distributsi jaoks ainulaadne.
Halvem on see, kui vana paketi nime alla hakkab peituma uuendatud versioon.
Näide:
Fedora 24-s uuendati paketti ncurses versioonist 5 versioonini 6. Meie toode on loodud just 5-ndas versioonis, et tagada ühilduvus vanade distributsioonidega. Vanema 5-nda versiooni raamatukogu kasutamiseks Fedora 24-s tuli kasutada paketti ncurses-compat-libs.
Seetõttu on Fedora jaoks saadaval kaks paketti, erinevate sõltuvustega.
Edasi huvitavam. Pärast järgmise distributsiooni uuendamist on pakett ncurses-compat-libs 5-nda versiooniga raamatukogu muutunud kättesaamatuks. Distributsioonitegija jaoks on kulukas vanade raamatukogude tõmbamine uude versiooni. Mõne aja pärast kordus probleem ka SUSE distributsioonides.
Seetõttu pidid mõned distributsioonid loobuma selgest sõltuvusest ncurses-libs, ja toode korrigeeriti nii, et see võiks töötada mis tahes raamatukogu versiooniga.
Muide, Red Hat 8-s ei ole enam meta-paketti python, mis viitas vanale headusele python 2.7. On python2 ja python3.
Alternatiiv paketihalduritele
Sõltuvuste probleem on vana ja juba ammu nähtav. Rääkimata näiteks sõltuvuste põrgust.
Erinevate raamatukogude ja rakenduste kombineerimine nii, et need kõik stabiilselt töötaksid ja ei konfliktiks, on ülesanne, millega iga Linuxi distributsioon püüab toime tulla.
Paketihaldur lahendab seda probleemi täiesti erinevalt Snappy Canonicalilt. Peamine idee: rakendus töötab peamisest süsteemist eraldatud ja kaitstud liivakastis. Kui rakendusele on vaja raamatukogusid, siis saadakse need koos rakendusega.
Flatpak lubab samuti rakendusi käivitada liivakastis, kasutades Linuxi konteinerite tehnoloogiat. Liivakasti ideed kasutab ka AppImage.
Need lahendused võimaldavad luua ühe paketi mis tahes distributsioonidele. Juhul kui Flatpak rakenduse installimine ja käivitamine on võimalik isegi ilma administraatori teadmiseta.
Põhiprobleem on see, et mitte kõik rakendused ei saa liivakastis töötada. Mõned vajavad otsest juurdepääsu platvormile. Ma ei räägi juba tuuma moodulitest, mis sõltuvad rangelt tuumast ja ei mahu kuidagi liivakasti kontseptsiooni.
Teine probleem on see, et Red Hati ja SUSE populaarsete ettevõtte keskkonnale mõeldud distributsioonid ei sisalda veel Snappy ja Flatpak tugi.
Seetõttu ei ole Veeam Agent for Linux ei ega .
Kokkuvõtlikult pakettide haldurite küsimuses mainin, et on võimalus loobuda täielikult paketihaldurist, ühendades binaarfailid ja nende installimise skripti üheks paketiks.
Selline komplekt võimaldab luua ühe üldise paketi erinevate distributsioonide ja platvormide jaoks, teostada interaktiivset installimisprotsessi ning teha vajalikku kohandamist. Olen selliste paketiga Linuxis kokku puutunud vaid VMware-i puhul.
Taasvärskendamise probleem
Isegi kui kõik sõltuvusprobleemid on lahendatud, võib programm töötada erinevalt isegi samas distributsioonis. Põhjus on värskendustes.
Värskendamiseks on 3 strateegiat:
- Lihtsaim on mitte kunagi värskendada. Seadsin serveri paika ja unustasin selle. Miks värskendada, kui kõik töötab? Probleemid algavad kohe, kui helistate tuge. Distributsiooni looja toetab ainult uuendatud versiooni.
- Usaldage distributorit ja seadistage automaatne uuendamine. Sellisel juhul võib tugi jaotisest helistamine juhtuda kohe pärast ebaõnnestumist.
- Käsitsi uuendamise variant, ainult pärast selle testimist katse infrastruktuuris – on kõige kindlam, kuid kallis ja töömahukas. Kaugelki mitte igaüks ei suuda seda endale lubada.
Kuna erinevad kasutajad rakendavad erinevaid uuendamisstrateegiaid, tuleb toetada nii kõige uuemat versiooni kui ka kõiki varem välja antud versioone. See keerustab nii arendamise kui ka testimise protsessi, lisades muret tugiteenusele.
Mitmekesised riistvaraplatvormid
Erinevad riistvaraplatvormid on probleem, mis on suuresti spetsiifiline just native-koodile. Vähemalt tuleb koostada binaarid iga toetatud platvormi jaoks.
Projekti Veeam Agent for Linux puhul ei ole me suutnud toetada ühtegi RISC-põhist platvormi.
Ma ei hakka sellele küsimusele pikemalt peatuma. Tahan vaid mainida põhiprobleeme: platvormist sõltuvad tüübid, nagu size_t, struktuuride ühtlustamine ja baitide järjekord.
Staatiline ja/või dünaamiline linkimine
Küsimus "Kuidas linkida raamatukogudega - dünaamiliselt või staatiliselt?" on arutamist väärt.
Tavaliselt kasutavad C/C++ rakendused Linuxis dünaamilist linkimist. See töötab suurepäraselt juhul, kui rakendus on koostatakse spetsiaalselt konkreetse distributsiooni jaoks.
Kui aga eesmärk on katta mitmekesised distributsioonid ühe binaarfailiga, siis tuleb orienteeruda kõige vanemale toetatud distributsioonile. Meie jaoks on see Red Hat 6. See sisaldab gcc 4.4, mis ei toeta isegi C++11 standardit. .
Me koondame oma projekti gcc 6.3 abil, mis toetab täielikult C++14. Loomulikult tuleb sel juhul Red Hat 6 puhul raamatukogud, nagu libstdc++ ja boost, endaga kaasa võtta. Lihtsaim on neid linkida staatiliselt.
Kahjuks ei saa kõiki raamatukogusid linkida staatiliselt.
Esiteks tuleb süsteemsete raamatukogusid, nagu libfuse, libblkid , linkida dünaamiliselt, et olla kindel nende ühilduvuses tuuma ja selle moodulitega.
Teiseks on litsentsidega seoses nüanss.
GPL-litsents lubab põhimõtteliselt linkida raamatukogusid ainult avatud lähtekoodiga koodiga. MIT ja BSD lubavad staatilist linkimist ja raamatukogude lisamist projekti. LGPL seevastu ei tundu vastuolus staatilise linkimisega, kuid nõuab, et jagatakse avalikult vajalikud failid linkimiseks.
Üldiselt aitab dünaamiline linkimine vältida vajadust midagi pakkuda.
C/C++ rakenduste koostamine
C/C++ rakenduste koostamiseks erinevate platvormide ja distributsioonide jaoks piisab sobiva versiooni gcc valimisest või koostamisest ning spetsiifiliste arhitektuuride jaoks ristkompilaatoritest kasutamisest, samuti kõigi raamatukogude kogumise lõpetamisest. See töö on täiesti teostatav, kuid üsna vaevarikas. Ja ei ole mingeid garantiisid, et valitud kompilaator ja raamatukogud tagavad töötava variandi.
Ilmselge eelis: infrastruktuur lihtsustub oluliselt, kuna kogu koostamisprotsessi saab teha ühel masinal. Lisaks piisab ühe arhitektuuri jaoks ühe komplekti binaarfailide koostamisest ja neid saab pakkida erinevate distributsioonide jaoks. Just nii koostatakse veeam pakette Veeam Agent for Linux jaoks.
Selle variandi asemele võib lihtsalt ette valmistada build-farmi, st mitu masinat, mis hoolitsevad kokkupaneku eest. Iga selline masin tagab rakenduse kompileerimise ja paketi koostamise konkreetseks distributsiooniks ja kindlaks arhitektuuriks. Sel juhul viiakse kompileerimine läbi nendega tööriistade abil, mida on ette valmistanud distributsioon. See tähendab, et kompilaatori ettevalmistamise etapp ja raamatukogude valimine jääb ära. Peale selle võib koostamisprotsessi lihtsalt paralleelseks muuta.
Kuid sellise lähenemise puhul on tõepoolest ka puudus: iga distributsiooni jaoks sama arhitektuuri raames tuleb kokku pannud oma binarfaile. Samuti on miinuseks see, et selliste masinate hulk vajab hooldust, mis nõuab suurt hulka kettaruumi jaRAMi.
Nii kogutakse KMOD pakette kernelimooduli veeamsnap jaoks Red Hati distributsioonide jaoks.
Open Build Service
SUSE kolleegid on proovinud rakendada teatud kuldset kesktee spetsiaalse teenuse näol rakenduste kompileerimiseks ja paketide kogumiseks — .
Tegemist on hüperviisoriga, mis loob virtuaalmasina, paigaldab sinna kõik vajalikud paketid, kompileerib rakenduse ja koostab paketi selles isoleeritud keskkonnas, pärast mida vabastatakse see virtuaalmasin.
OpenBuildService'is ellu viidud planeerija määrab automaatselt, kui palju virtuaalmasinaid saab tõhusate paketihangete kiirusest lähtudes käivitada. Sisseehitatud allkirjastamismehhanism allkirjastab paketid automaatselt ja paneb need sisseehitatud hoidlasse. Sisseehitatud versioonihaldussüsteem salvestab muudatuste ja väljakutsete ajaloo. Jääb vaid lisada oma lähtekood sellele süsteemile. Ei pea isegi serverit üles tõstma, võivad kasutama avatud lahendust.
Küll aga on siin probleem: selline kombain on olemasolevaga infrastruktuuri integreerimist keeruline. Näiteks versioonihaldust ei ole vaja, meil on juba oma lähtekoodide jaoks. Allkirjastamismehhanism erineb: kasutatakse spetsiaalset serverit. Hoidlat pole samuti vaja.
Lisaks on teiste distributsioonide, näiteks Red Hat, tugi üsna napp, mis on täiesti mõistetav.
Selle teenuse eeliseks on kiirus, millega toetatakse SUSE jaotiste uusima versiooni ilmumist. Enne ametlikku välja kuulutamist on vajalikud kogumise paketid avalikus hoidlas saadaval. Saadaval olevate jaotiste loendis OpenBuildService'is ilmub uus. Tõstame ruudu, ja see lisatakse kogumise plaani. Nii saab uue jaotise versiooni lisada praktiliselt ühe klõpsuga.
Meie infrastruktuuris, kasutades OpenBuildService'i, kogutakse kõik KMP pakettide mitmekesisus veeamsnapi tuumamooduli jaoks SUSE jaotises.
Edasi tahaksin peatuda küsimustel, mis on spetsiifilised just tuumamoodulitele.
kernel ABI
Linuxi tuumamooduleid on ajalooliselt levitatud allika koodina. Asi on selles, et tuuma loojad ei muretse tuumamoodulite stabiilse API toetamise pärast, veel vähem binaarset taset, tuntud ka kui kABI.
Tuumamooduli kogumiseks on vajalik selle tuuma headerid, ja see töötab ainult sellel tuumal.
DKMS võimaldab automatiseerida moodulite kokkupanemise protsessi tuumauuenduste ajal. Selle tulemusena kasutavad Debian'i (ja selle paljusid sugulasi) hoidla kasutajad kas tuumamooduleid, mis on saadaval jaotaja hoidlas, või allikakoodist DKMS-i abil kokku pandud mooduleid.
Kuid selline olukord ei rahulda eriti Enterprise-segmenti. Proprietaarse koodi levitajad soovivad tooteid levitada kokku pandud binaaridena.
Administratorid ei soovi hoida arendustööriistu tootmisserverites turvalisuse kaalutlustel. Enterprise Linuxi jaotajad – nagu Red Hat ja SUSE – on otsustanud, et nad saavad oma kasutajatele säilitada stabiilse kABI. Selle tulemusena tekkisid KMOD paketid Red Hatile ja KMP paketid SUSE jaoks.
Selle lahenduse olemus on üsna lihtne. Teatud jaotise versiooni jaoks külmutatakse tuuma API. Jaotaja kinnitab, et ta kasutab just tuuma, näiteks 3.10, ja rakendab ainult parandusi ja täiustusi, mis ei mõjuta tuuma liideseid; esimeseks tuumaks kokku pandud mooduleid saab kasutada kõikide järgneva versioonide jaoks ilma ümberkuulutamata.
Red Hat kinnitab kABI ühilduvust oma versioonide elu jooksul. See tähendab, et rhel 6.0 (novembri 2010 väljaanne) jaoks kokku pandud moodul peab töötama ka versioonis 6.10 (juuni 2018 väljaanne). See on peaaegu 8 aastat. Loomulikult on see üsna keeruline ülesanne.
Oleme registreerinud mitmeid juhtumeid, kus kABI ühilduvusprobleemide tõttu moodul veeamsnap lõpetas töötamise.
Pärast seda, kui RHEL 7.0 jaoks kokku pandud moodul veeamsnap osutus RHEL 7.5 tuumaga ühilduvaks, kuid laadis siiski ja garanteeris serveri kokku kukkumise, loobusime üldse kABI ühilduvuse kasutamisest RHEL 7 jaoks.
Praegu sisaldab KMOD pakett RHEL 7 jaoks iga väljaande versiooniks kokku pandud moodul ja skripti, mis tagab mooduli laadimise.
SUSE lähenes kABI ühilduvuse ülesandele ettevaatlikumalt. Nad tagavad kABI ühilduvuse ainult ühe teenuspaketi raames.
Näiteks ilmus SLES 12 septembris 2014. Aga SLES 12 SP1 juba detsembris 2015, mis tähendab, et vahe oli veidi rohkem kui aasta. Kuigi mõlemad väljalasked kasutavad tuuma 3.12, on nad kABI ühilduvad. On ilmne, et kABI ühilduvuse säilitamine vaid aasta jooksul on tunduvalt lihtsam. Aastane tuumamooduli uuendustsükkel ei tohiks moodulite loojatele mingeid probleeme põhjustada.
Selle SUSE poliitika tagajärjel ei ole me fikseerinud ühtegi kABI ühilduvuse probleemi meie veeamsnap mudeliga. Tõsi, SUSE jaoks on ka pakette peaaegu kümme korda rohkem.
Kohandused ja tagasiviimised
Kuigi distributsioonid püüavad tagada kABI ühilduvuse ja tuuma stabiilsuse, püüavad nad ka parandada jõudlust ja kõrvaldada defekte selles stabiilses tuumas.
Lisaks oma 'vigade parandamisele' jälgivad enterprise linuxi tuuma arendajad ka puhtas tuumas toimuvaid muudatusi ja viivad need oma 'stabiilsesse' edasi.
Mõnikord viib see uute .
Red Hat 6 viimases väljalaskes oli ühe minor uuenduse käigus esinenud viga. See põhjustas, et veeamsnap moodul vedas süsteemi kokku, kui snapshot'id vabastati. Võrreldes tuumakoodi enne ja pärast uuendust leidsime, et süüdlane oli backport. Sarnane parandamine tehti vanilje tuumas versioonis 4.19. Probleem aga tekkis sel juhul, kui see parandamine viidi 'stabiilsesse' 2.6.32, kus tekkis spin-lock'i probleem.
Muidugi, vigu esineb kõigil ja alati, kuid kas oli tõesti vajalik kanda koodi 4.19-lt 2.6.32-le, riskides stabiilsusega? ... Ma ei ole kindel...
Halvim on see, kui köievedu 'stabiilsus' 'moderniseerimine' hõlmab turundust. Turundusosakond vajab, et uuendatud jaotuse tuum oleks stabiilne, kuid samas ka parem jõudlus ja uued funktsioonid. See toob kaasa kummalisi kompromisse.
Kui proovisin SLES 12 SP3 põhjad'al põhinevat moodulit kokku panna, avastasin üllatusega, et seal on funktsioone, mis pärinevad puhtast 4.8 versioonist. Minu arvates sobib SLES 12 SP3 4.4 tuuma bloki sisendi- ja väljundi rakendus rohkem 4.8 tuumale kui eelnevale stabiilsele 4.4 versioonile SLES 12 SP2-st. Mis puudutab koodi osakaalu, mis on 4.8-st SP3-sse üle viidud, ei oska ma seda hinnata, kuid ma ei suuda endiselt nimetada seda tuuma stabiilseks 4.4-ks.
Kõige ebameeldivam on see, et mooduli kirjutamisel, mis töötab võrdselt hästi erinevatel tuumadel, ei saa enam toetuda tuuma versioonile. Tuleb arvestada ka distributsiooniga. Hea, et mõnikord saab tugineda defineerimisele, mis ilmub koos uue funktsionaalsusega, kuid selline võimalus ei ole alati olemas.
Tulemuseks on see, et kood muutub haruldaste konditsioonide kompileerimise direktiividega koormatud.
Tuleb ette ka patareid, mis muudavad dokumenteeritud tuuma API-d.
Kohustun distributsioonile 5.16 ja olin väga üllatunud, kui nägin, et lookup_bdev'i kutsumine selle versiooni tuumas on muutunud.
Kogumiseks pidi makefile'isse lisama skripti, mis kontrollib, kas funktsioonil lookup_bdev on maski parameeter.
Kernelimoodulite allkiri
Aga naaseme pakettide levitamise küsimuse juurde.
Üks stabiilse kABI eeliseid on see, et kernelimooduleid saab allkirjastada binaarfailina. Sel juhul võib arendaja olla kindel, et moodul ei ole juhuslikult kahjustatud ega tahtlikult muudetud. Seda saab kontrollida käsuga modinfo.
Red Hat ja SUSE distributsioonid võimaldavad mooduli allkirja kontrollimist ja selle laadimist ainult juhul, kui vastav sertifikaat on süsteemis registreeritud. Sertifikaat on avalik võti, millega moodul allkirjastatakse. Me jagame seda eraldi pakkina.
Probleem on selles, et sertifikaadid võivad olla kas sisseehitatud kerneli (mida kasutavad distributsioonid) või peavad olema salvestatud energia mitteoma mälusse EFI abil utiliidi mokutil. Tööriist mokutil sertifikaadi installimisel nõuab süsteemi taaskäivitamist ja enne operatsioonisüsteemi kernelit laadimist palub administraatoril lubada uue sertifikaadi laadimist.
Seega nõuab sertifikaadi lisamine administraatori füüsilist juurdepääsu süsteemile. Kui masin asub kuskil pilves või lihtsalt kaugel serveris ja juurdepääs on ainult võrgus (näiteks ssh kaudu), siis ei ole sertifikaadi lisamine võimalik.
EFI virtuaalmasinates
Kuigi viimastel aastatel on EFI toetamine peaaegu kõigi emaplaatide tootjate poolt laialdaselt levinud, ei pruugi administraator installimisel EFI vajadust arvesse võtta ning see võib olla välja lülitatud.
Kuid kõik hüpervizorid ei toeta EFI-d. VMWare vSphere toetas EFI-d alates versioonist 5.
Microsoft Hyper-V sai samuti EFI toe alates Hyper-V for Windows Server 2012R2.
Siiski on Linuxi masinate jaoks see funktsioon vaikimisi välja lülitatud, mis tähendab, et sertifikaati ei saa paigaldada.
vSphere 6.5-s saab valida valiku Secure Boot ainult vanas veebiliideses, mis töötab Flashi kaudu. HTML-5 põhine Web UI on siiski järelkäigul.
Eksperimendidistid
Viimase asjana vaatame eksperimenteerivaid ja ametlikult toetamata distributsioone. Ühelt poolt ei kohtu selliste distributsioonidega tõsiste organisatsioonide serverites. Neil puudub ametlik tugi. Seega ei saa sellistele distributsioonidele tehnilist tuge pakkuda.
Kuid sellised distributsioonid muutuvad mugavaks platvormiks uute eksperimentaalsete lahenduste proovimiseks. Näiteks Fedora, OpenSUSE Tumbleweed või Debian Unstable versioonid. Need on üsna stabiilsed. Neis on alati uusimad programmiversioonid ja uusim tuumik. Aasta pärast võib see eksperimentaalne funktsionaalsus ilmneda uuendatud RHEL-is, SLES-is või Ubuntu-s.
Nii et kui midagi ei tööta eksperimenteerivas distributsioonis, on see põhjus probleemi uurimiseks ja lahendamiseks. Tuleb olla valmis, et see funktsionaalsus võib peagi ilmuda kasutajate tootmisserveritesse.
Praegu on olemas ametlikult toetatud distributsioonide loetelu versioonile 3.0, mida saate uurida . Kuid tegelik loetelu distributsioonidest, millel meie toode suudab töötada, on palju laiem.
Isiklikult huvitab mind OS «Elbrus» katse. Pärast veeam paketi täiustamist installiti ja töötas meie toode. Kirjutasin sellest eksperimendist Habr's. .
Uute distributsioonide tugi jätkub. Ootame versiooni 4.0 välja tulekut. Peagi peaks ilmuma beetaversioon, nii et hoidke silmad lahti. !
Allikas: habr.com
