Sukurti atsarginę programą, kuri veiktų su bet kokiu platinimu, nėra lengva užduotis. Kad „Veeam Agent for Linux“ veiktų platinimuose nuo „Red Hat 6“ ir „Debian 6“ iki „OpenSUSE 15.1“ ir „Ubuntu 19.04“, turite išspręsti daugybę problemų, ypač atsižvelgiant į tai, kad programinės įrangos gaminyje yra branduolio modulis.
Straipsnis sukurtas remiantis konferencijoje pasisakymo medžiaga .
Linux yra ne tik viena populiariausių operacinių sistemų. Iš esmės tai yra platforma, kurios pagrindu galite sukurti kažką unikalaus, kažką savo. Dėl šios priežasties „Linux“ turi daug platinimų, kurie skiriasi programinės įrangos komponentų rinkiniu. Ir čia iškyla problema: norint, kad programinės įrangos produktas veiktų bet kuriame platinime, turite atsižvelgti į kiekvieno iš jų savybes.
Paketo valdytojai. .deb ir .rpm
Pradėkime nuo akivaizdžios produkto paskirstymo skirtinguose paskirstymuose problemos.
Įprasčiausias programinės įrangos produktų platinimo būdas yra įdėti paketą į saugyklą, kad sistemoje integruota paketų tvarkyklė galėtų jį iš ten įdiegti.
Tačiau turime du populiarius paketų formatus: min и deb. Tai reiškia, kad visi turės palaikyti.
Deb paketų pasaulyje suderinamumo lygis yra nuostabus. Tas pats paketas įdiegiamas ir veikia vienodai gerai tiek Debian 6, tiek Ubuntu 19.04. Paketų kūrimo ir darbo su jais proceso standartai, nustatyti senuose Debian platinimuose, išlieka aktualūs naujoje „Linux Mint“ ir elementarioje OS. Todėl „Veeam Agent for Linux“ atveju pakanka vieno deb paketo kiekvienai aparatinės įrangos platformai.
Tačiau rpm paketų pasaulyje skirtumai yra dideli. Pirma, dėl to, kad yra du visiškai nepriklausomi platintojai „Red Hat“ ir „SUSE“, kuriems suderinamumas visiškai nereikalingas. Antra, šie platintojai turi paskirstymo rinkinius iš tų. parama ir eksperimentinė. Tarp jų taip pat nereikia suderinamumo. Paaiškėjo, kad el6, el7 ir el8 turi savo pakuotes. Atskiras Fedora paketas. SLES11 ir 12 paketai ir atskiras openSUSE. Pagrindinė problema yra priklausomybės ir paketų pavadinimai.
Priklausomybės problema
Deja, tie patys paketai skirtinguose platinimuose dažnai būna skirtingais pavadinimais. Žemiau pateikiamas dalinis „veeam“ paketo priklausomybių sąrašas.
EL7:
SLES 12:
- liblkid
- libgcc
- libstdc++
- ncurses-libs
- saugiklis-libs
- failas-libs
- veeamsnap=3.0.2.1185
- liblkid1
- libgcc_s1
- libstdc ++ 6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Dėl to priklausomybių sąrašas yra unikalus paskirstymui.
Dar blogiau, kai atnaujinta versija pradeda slėptis po senu paketo pavadinimu.
Pavyzdys:
Paketas buvo atnaujintas Fedora 24 auklės nuo 5 versijos iki 6 versijos. Mūsų produktas buvo sukurtas naudojant 5 versiją, kad būtų užtikrintas suderinamumas su senesniais platinimais. Norėdami naudoti seną 5-ąją bibliotekos versiją Fedora 24, turėjau naudoti paketą ncurses-compat-libs.
Dėl to yra du „Fedora“ paketai su skirtingomis priklausomybėmis.
Toliau įdomiau. Po kito platinimo atnaujinimo paketas ncurses-compat-libs su 5 bibliotekos versija ji nepasiekiama. Platintojui brangu perkelti senas bibliotekas į naują platinimo versiją. Po kurio laiko problema pasikartojo SUSE platinimuose.
Dėl to kai kurie platinimai turėjo atsisakyti aiškios priklausomybės ncurses-libs, ir pataisykite gaminį, kad jis veiktų su bet kuria bibliotekos versija.
Beje, „Red Hat“ 8 versijoje nebėra meta paketo pitonas, kuris nurodė seną gerą pitonas 2.7. Yra python2 и pitonas3.
Alternatyva paketų tvarkytojams
Priklausomybių problema yra sena ir jau seniai akivaizdi. Tiesiog prisimink priklausomybės pragarą.
Sujungti įvairias bibliotekas ir programas, kad jos visos veiktų stabiliai ir neprieštarautų – iš tikrųjų tai yra užduotis, kurią bando išspręsti bet kuris „Linux“ platintojas.
Paketų tvarkyklė šią problemą bando išspręsti visiškai kitaip. Snappy iš Canonical. Pagrindinė idėja: programa veikia smėlio dėžėje, izoliuotoje ir apsaugotoje nuo pagrindinės sistemos. Jei programai reikalingos bibliotekos, jos pateikiamos kartu su pačia programa.
Flatpak taip pat leidžia paleisti programas smėlio dėžėje naudojant Linux konteinerius. Taip pat naudojama smėlio dėžės idėja "AppImage".
Šie sprendimai leidžia sukurti vieną paketą bet kokiam platinimui. Tuo atveju Flatpak įdiegti ir paleisti programą galima net be administratoriaus žinios.
Pagrindinė problema yra ta, kad ne visos programos gali veikti smėlio dėžėje. Kai kuriems žmonėms reikia tiesioginės prieigos prie platformos. Aš net nekalbu apie branduolio modulius, kurie yra griežtai priklausomi nuo branduolio ir netelpa į smėlio dėžės koncepciją.
Antroji problema yra ta, kad įmonės aplinkoje populiarūs Red Hat ir SUSE platinimai dar nepalaiko Snappy ir Flatpak.
Šiuo atžvilgiu „Veeam Agent“, skirta „Linux“, nėra Neprijungtas .
Baigdamas klausimą apie paketų tvarkykles, norėčiau pažymėti, kad yra galimybė visiškai atsisakyti paketų tvarkytuvų, sujungiant dvejetainius failus ir jų diegimo scenarijų į vieną paketą.
Toks paketas leidžia sukurti vieną bendrą paketą skirtingiems platinimams ir platformoms, atlikti interaktyvų diegimo procesą, atlikti reikiamus pritaikymus. Su tokiais Linux paketais susidūriau tik iš VMware.
Atnaujinimo problema
Net jei visos priklausomybės problemos bus išspręstos, programa tame pačiame paskirstyme gali veikti skirtingai. Tai atnaujinimų klausimas.
Yra 3 atnaujinimo strategijos:
- Paprasčiausias yra niekada neatnaujinti. Sukūriau serverį ir pamiršau. Kam atnaujinti, jei viskas veikia? Problemos prasideda pirmą kartą susisiekus su palaikymo komanda. Platinimo kūrėjas palaiko tik atnaujintą leidimą.
- Galite pasitikėti platintoju ir nustatyti automatinius atnaujinimus. Tokiu atveju pagalbos skambutis greičiausiai bus iš karto po nesėkmingo atnaujinimo.
- Patikimiausia, tačiau brangiausia ir daug laiko reikalaujanti galimybė atnaujinti tik jį paleidus bandomojoje infrastruktūroje. Ne visi gali tai sau leisti.
Kadangi skirtingi vartotojai naudoja skirtingas atnaujinimo strategijas, būtina palaikyti ir naujausią, ir visus anksčiau išleistus. Tai apsunkina ir kūrimo, ir testavimo procesą, o palaikymo komandai sukelia galvos skausmą.
Įvairios techninės įrangos platformos
Skirtingos aparatinės įrangos platformos yra problema, kuri daugiausia būdinga vietiniam kodui. Bent jau turite rinkti dvejetainius failus kiekvienai palaikomai platformai.
„Veeam Agent for Linux“ projekte vis tiek negalime palaikyti nieko panašaus į šį RISC.
Smulkiau šiuo klausimu nesigilinsiu. Apibūdinsiu tik pagrindines problemas: nuo platformos priklausomi tipai, pvz size_t, struktūros lygiavimas ir baitų tvarka.
Statinis ir (arba) dinaminis susiejimas
Tačiau kyla klausimas: „Kaip susieti su bibliotekomis – dinamiškai ar statiškai? verta diskutuoti.
Paprastai C/C++ programos Linux sistemoje naudoja dinaminį susiejimą. Tai puikiai veikia, jei programa sukurta specialiai tam tikram platinimui.
Jei užduotis yra padengti įvairius paskirstymus vienu dvejetainiu failu, tuomet turite sutelkti dėmesį į seniausią palaikomą platinimą. Mums tai yra Red Hat 6. Jame yra gcc 4.4, kurio net C++11 standartas nepalaiko .
Savo projektą kuriame naudodami gcc 6.3, kuris visiškai palaiko C++14. Natūralu, kad šiuo atveju Red Hat 6 turite nešiotis libstdc++ ir padidinti bibliotekas. Lengviausias būdas yra susieti su jais statiškai.
Deja, ne visas bibliotekas galima susieti statiškai.
Pirma, sistemos bibliotekos, tokios kaip libfuse, liblkid būtina dinamiškai susieti, kad būtų užtikrintas jų suderinamumas su branduoliu ir jo moduliais.
Antra, yra subtilumas su licencijomis.
GPL licencija iš esmės leidžia susieti bibliotekas tik su atvirojo kodo kodu. MIT ir BSD leidžia statiškai susieti ir bibliotekas įtraukti į projektą. Tačiau neatrodo, kad LGPL prieštarautų statiniam susiejimui, bet reikalauja, kad būtų bendrinami susiejimui reikalingi failai.
Apskritai, naudojant dinaminį susiejimą, jums nereikės nieko pateikti.
C/C++ programų kūrimas
Norint sukurti C/C++ programas skirtingoms platformoms ir platinimams, pakanka pasirinkti arba sukurti tinkamą gcc versiją ir naudoti kryžminius kompiliatorius konkrečioms architektūroms ir surinkti visą bibliotekų rinkinį. Šis darbas yra gana įmanomas, bet gana varginantis. Ir nėra jokios garantijos, kad pasirinktas kompiliatorius ir bibliotekos pateiks veikiančią versiją.
Akivaizdus pranašumas: infrastruktūra labai supaprastinta, nes visą kūrimo procesą galima atlikti vienoje mašinoje. Be to, pakanka surinkti vieną dvejetainių failų rinkinį vienai architektūrai ir galite juos supakuoti į paketus skirtingiems paskirstymams. Taip kuriami veeam paketai, skirti Veeam Agent for Linux.
Priešingai nei ši parinktis, galite tiesiog paruošti statyti ūkį, tai yra, surinkti keletą mašinų. Kiekviena tokia mašina pateiks programų kompiliavimą ir paketų surinkimą konkrečiam platinimui ir konkrečiai architektūrai. Šiuo atveju kompiliavimas atliekamas naudojant platintojo paruoštas priemones. Tai yra, kompiliatoriaus parengimo ir bibliotekų parinkimo etapas yra pašalintas. Be to, kūrimo procesą galima lengvai sulyginti.
Tačiau šis metodas turi ir neigiamą pusę: kiekvienam paskirstymui toje pačioje architektūroje turėsite rinkti savo dvejetainių failų rinkinį. Kitas trūkumas – reikia prižiūrėti tokį didelį skaičių mašinų ir skirti daug vietos diske bei RAM.
Taip sukompiliuojami veeamsnap branduolio modulio KMOD paketai Red Hat paskirstymams.
Atidarykite „Build Service“.
Kolegos iš SUSE bandė įgyvendinti tam tikrą vidurį naudodamiesi specialia programų sudarymo ir paketų surinkimo paslauga - .
Iš esmės tai yra hipervizorius, kuris sukuria virtualią mašiną, įdiegia joje visus reikiamus paketus, sukompiliuoja aplikaciją ir sukuria paketą šioje izoliuotoje aplinkoje, po to virtuali mašina išleidžiama.
Planavimo priemonė, įdiegta OpenBuildService, nustatys, kiek virtualių mašinų jis gali paleisti, kad būtų optimalus paketų kūrimo greitis. Integruotas pasirašymo mechanizmas pasirašys paketus ir įkels juos į integruotą saugyklą. Integruota versijų valdymo sistema išsaugos pakeitimų ir versijų istoriją. Belieka tiesiog pridėti savo šaltinius prie šios sistemos. Jums net nereikia patiems nustatyti serverio; galite naudoti atvirą.
Tačiau yra problema: tokį kombainą sunku pritaikyti esamai infrastruktūrai. Pavyzdžiui, versijos valdymo nereikia, mes jau turime savo šaltinio kodams. Mūsų parašo mechanizmas kitoks: naudojame specialų serverį. Saugykla taip pat nereikalinga.
Be to, kitų platinimų, pavyzdžiui, „Red Hat“, palaikymas įgyvendinamas gana prastai, o tai suprantama.
Tokios paslaugos pranašumas yra greitas kitos SUSE platinimo versijos palaikymas. Prieš oficialų paskelbimą apie išleidimą, surinkimui reikalingi paketai yra patalpinti viešoje saugykloje. Galimų „OpenBuildService“ platinimų sąraše pasirodo naujas. Pažymime langelį ir jis pridedamas prie statybos plano. Taigi, naujos platinimo versijos pridėjimas atliekamas beveik vienu paspaudimu.
Mūsų infrastruktūroje, naudojant OpenBuildService, yra surenkama visa SUSE platinimui skirto veeamsnap branduolio modulio KMP paketų įvairovė.
Toliau norėčiau pasilikti ties branduolio moduliams būdingais klausimais.
branduolio ABI
Linux branduolio moduliai istoriškai buvo platinami šaltinio forma. Faktas yra tas, kad branduolio kūrėjai neapsunkina savęs susirūpinimu palaikyti stabilią API branduolio moduliams, ypač dvejetainiu lygiu, toliau vadinamu kABI.
Norint sukurti vanilinio branduolio modulį, būtinai reikia šio konkretaus branduolio antraštės ir jis veiks tik su šiuo branduoliu.
DKMS leidžia automatizuoti modulių kūrimo procesą atnaujinant branduolį. Dėl to Debiano saugyklos vartotojai (ir daugelis jos giminaičių) naudoja branduolio modulius iš platintojo saugyklos arba sukompiliuotus iš šaltinio naudojant DKMS.
Tačiau tokia situacija ne itin tinka įmonių segmentui. Patentuotų kodų platintojai nori platinti produktą kaip sudarytus dvejetainius failus.
Saugumo sumetimais administratoriai nenori laikyti kūrimo įrankių gamybos serveriuose. Įmonės Linux platintojai, tokie kaip Red Hat ir SUSE, nusprendė, kad gali palaikyti stabilų kABI savo vartotojams. Rezultatas buvo KMOD paketai, skirti „Red Hat“, ir KMP paketai, skirti SUSE.
Šio sprendimo esmė gana paprasta. Konkrečios platinimo versijos branduolio API yra užšaldyta. Platintojas teigia, kad naudoja branduolį, pavyzdžiui, 3.10, ir atlieka tik taisymus bei patobulinimus, kurie neturi įtakos branduolio sąsajoms, o pačiam pirmam branduoliui surinktus modulius galima naudoti visiems tolesniems be perkompiliavimo.
„Red Hat“ teigia, kad paskirstymas yra suderinamas su kABI per visą jo gyvavimo ciklą. Tai yra, surinktas rhel 6.0 modulis (2010 m. lapkričio mėn. išleistas) taip pat turėtų veikti 6.10 versijoje (2018 m. birželio mėn.). Ir tai yra beveik 8 metai. Žinoma, ši užduotis yra gana sudėtinga.
Užfiksavome keletą atvejų, kai „veeamsnap“ modulis nustojo veikti dėl kABI suderinamumo problemų.
Po to, kai „veeamsnap“ modulis, sudarytas RHEL 7.0, pasirodė esąs nesuderinamas su RHEL 7.5 branduoliu, tačiau jis buvo įkeltas ir garantuotai sugadins serverį, mes visiškai atsisakėme naudoti kABI suderinamumą su RHEL 7.
Šiuo metu RHEL 7 KMOD pakete yra kiekvienos leidimo versijos rinkinys ir scenarijus, įkeliantis modulį.
SUSE į kABI suderinamumo užduotį žvelgė atidžiau. Jie užtikrina kABI suderinamumą tik viename pakeitimų pakete.
Pavyzdžiui, SLES 12 išleidimas įvyko 2014 metų rugsėjį. O SLES 12 SP1 jau buvo 2015 metų gruodį, tai yra, praėjo kiek daugiau nei metai. Nors abiejuose leidimuose naudojamas 3.12 branduolys, jie yra nesuderinami kABI. Akivaizdu, kad išlaikyti kABI suderinamumą tik metus yra daug lengviau. Metinis branduolio modulio atnaujinimo ciklas neturėtų sukelti problemų modulių kūrėjams.
Dėl šios SUSE politikos mūsų „veeamsnap“ modulyje neužfiksavome nė vienos kABI suderinamumo problemos. Tiesa, SUSE paketų skaičius yra beveik eilės tvarka didesnis.
Patches ir backports
Nors platintojai stengiasi užtikrinti kABI suderinamumą ir branduolio stabilumą, jie taip pat stengiasi pagerinti šio stabilaus branduolio našumą ir pašalinti defektus.
Tuo pačiu metu, be savo „darbo su klaidomis“, įmonės „Linux“ branduolio kūrėjai stebi vanilinio branduolio pokyčius ir perkelia juos į „stabilų“.
Kartais tai veda prie naujų .
Naujausioje „Red Hat 6“ laidoje viename iš nedidelių atnaujinimų buvo padaryta klaida. Tai lėmė tai, kad „veeamsnap“ modulis garantuotai sugadins sistemą, kai buvo išleista momentinė nuotrauka. Palyginę branduolio šaltinius prieš ir po atnaujinimo, išsiaiškinome, kad dėl to kaltas backport. Panašus pataisymas buvo atliktas vanilės branduolio 4.19 versijoje. Tiesiog šis pataisymas puikiai veikė vanilės branduolyje, tačiau perkeliant jį į „stabilią“ 2.6.32, iškilo problema su „spinlock“.
Žinoma, visi visada turi klaidų, bet ar buvo verta vilkti kodą nuo 4.19 iki 2.6.32, rizikuoti stabilumu?.. Nežinau...
Blogiausia, kai rinkodara įsitraukia į virvės traukimą tarp „stabilumo“ ir „modernizacijos“. Viena vertus, rinkodaros skyriui reikia, kad atnaujinto platinimo branduolys būtų stabilus ir tuo pat metu būtų geresnis ir turėtų naujų funkcijų. Tai veda prie keistų kompromisų.
Kai bandžiau sukurti modulį 4.4 branduolyje iš SLES 12 SP3, nustebau, kad jame radau vanilla 4.8 funkcionalumą. Mano nuomone, SLES 4.4 SP12 3 branduolio blokinis I/O diegimas yra panašesnis į 4.8 branduolį nei ankstesnė stabilaus 4.4 branduolio iš SLES12 SP2 versija. Negaliu spręsti, kiek procentų kodo buvo perkelta iš branduolio 4.8 į SLES 4.4, skirtą SP3, bet aš net negaliu pavadinti branduolio tuo pačiu stabiliu 4.4.
Nemaloniausias dalykas yra tai, kad rašant modulį, kuris vienodai gerai veiktų skirtinguose branduoliuose, nebegalima pasikliauti branduolio versija. Taip pat reikia atsižvelgti į paskirstymą. Gerai, kad kartais galite įsitraukti į apibrėžimą, kuris atsiranda kartu su naujomis funkcijomis, tačiau tokia galimybė atsiranda ne visada.
Dėl to kodas apauga keistomis sąlyginio kompiliavimo direktyvomis.
Taip pat yra pataisų, pakeičiančių dokumentuotą branduolio API.
Aš susidūriau su platinimu 5.16 ir labai nustebau pamatęs, kad lookup_bdev iškvietimas šioje branduolio versijoje pakeitė įvesties parametrų sąrašą.
Kad jį surinkčiau, prie makefile turėjau pridėti scenarijų, kuris patikrina, ar funkcija lookup_bdev turi maskavimo parametrą.
Branduolio modulių pasirašymas
Bet grįžkime prie paketų platinimo klausimo.
Vienas iš stabilios kABI privalumų yra tas, kad branduolio modulius galima pasirašyti kaip dvejetainį failą. Tokiu atveju kūrėjas gali būti tikras, kad modulis nebuvo netyčia sugadintas ar tyčia modifikuotas. Tai galite patikrinti naudodami komandą modinfo.
Red Hat ir SUSE paskirstymai leidžia patikrinti modulio parašą ir jį įkelti tik tuo atveju, jei sistemoje yra užregistruotas atitinkamas sertifikatas. Sertifikatas yra viešasis raktas, kuriuo pasirašomas modulis. Ją platiname kaip atskirą pakuotę.
Problema ta, kad sertifikatai gali būti integruoti į branduolį (platintojai juos naudoja) arba turi būti įrašyti į EFI nepastovią atmintį naudojant programinę įrangą mokutil. Naudingumas mokutil Diegiant sertifikatą reikia iš naujo paleisti sistemą ir net prieš įkeliant operacinės sistemos branduolį, administratorius paragina leisti įkelti naują sertifikatą.
Taigi, norint pridėti sertifikatą, reikalinga fizinė administratoriaus prieiga prie sistemos. Jei mašina yra kur nors debesyje arba tiesiog nuotoliniame serverio kambaryje ir prieiga yra tik per tinklą (pavyzdžiui, per ssh), tada nebus įmanoma pridėti sertifikato.
EFI virtualiose mašinose
Nepaisant to, kad EFI jau seniai palaiko beveik visi pagrindinių plokščių gamintojai, diegdamas sistemą administratorius gali nepagalvoti apie EFI poreikį, jis gali būti išjungtas.
Ne visi hipervizoriai palaiko EFI. VMWare vSphere palaiko EFI nuo 5 versijos.
Microsoft Hyper-V taip pat gavo EFI palaikymą, pradedant Hyper-V, skirta Windows Server 2012R2.
Tačiau pagal numatytąją konfigūraciją ši funkcija išjungta Linux įrenginiuose, o tai reiškia, kad sertifikato įdiegti negalima.
„vSphere 6.5“ nustatykite parinktį Saugus Įkėlimo galima tik senoje žiniatinklio sąsajos versijoje, kuri veikia naudojant „Flash“. HTML-5 žiniatinklio vartotojo sąsaja vis dar atsilieka.
Eksperimentiniai paskirstymai
Ir galiausiai, panagrinėkime eksperimentinio platinimo ir platinimo be oficialaus palaikymo klausimą. Viena vertus, tokių platinimų vargu ar galima rasti rimtų organizacijų serveriuose. Tokiems platinimams oficialios paramos nėra. Todėl suteikite tuos. Tokio platinimo produktas negali būti palaikomas.
Tačiau tokie platinimai tampa patogia platforma išbandyti naujus eksperimentinius sprendimus. Pavyzdžiui, Fedora, OpenSUSE Tumbleweed arba nestabilios Debian versijos. Jie yra gana stabilūs. Jie visada turi naujas programų versijas ir naują branduolį. Po metų ši eksperimentinė funkcija gali atsidurti atnaujintame RHEL, SLES ar Ubuntu.
Taigi, jei kažkas neveikia naudojant eksperimentinį paskirstymą, tai yra priežastis išsiaiškinti problemą ir ją išspręsti. Turite būti pasirengę, kad ši funkcija netrukus pasirodys vartotojų gamybos serveriuose.
Galite ištirti dabartinį oficialiai palaikomų 3.0 versijos platinimų sąrašą . Tačiau tikrasis platinimų, kuriuose gali veikti mūsų produktas, sąrašas yra daug platesnis.
Asmeniškai mane domino eksperimentas su Elbrus OS. Užbaigus veeam paketą, mūsų produktas buvo įdiegtas ir veikia. Apie šį eksperimentą Habré rašiau m .
Na, naujų platinimų palaikymas tęsiamas. Laukiame, kol bus išleista 4.0 versija. Netrukus pasirodys beta versija, todėl stebėkite !
Šaltinis: www.habr.com