Varundusrakenduse loomine, mis töötab mis tahes distributsiooniga, pole lihtne ülesanne. Tagamaks, et Veeam Agent for Linux töötab distributsioonidel alates Red Hat 6 ja Debian 6 kuni OpenSUSE 15.1 ja Ubuntu 19.04, peate lahendama hulga probleeme, eriti kui arvestada, et tarkvaratoode sisaldab kerneli moodulit.
Artikkel valmis konverentsil peetud kõne materjalide põhjal .
Linux ei ole lihtsalt üks populaarsemaid operatsioonisüsteeme. Sisuliselt on see platvorm, mille põhjal saate teha midagi ainulaadset, midagi oma. Tänu sellele on Linuxil palju distributsioone, mis erinevad tarkvarakomponentide komplekti poolest. Ja siin tekib probleem: selleks, et tarkvaratoode töötaks mis tahes distributsioonis, peate arvestama nende omadustega.
Paketihaldurid. .deb vs .rpm
Alustame ilmselgest probleemist, mis seisneb toote levitamises erinevate distributsioonide vahel.
Kõige tüüpilisem viis tarkvaratoodete levitamiseks on panna pakett hoidlasse, et süsteemi sisseehitatud paketihaldur saaks selle sealt installida.
Meil on aga kaks populaarset paketivormingut: rpm и deb. See tähendab, et kõik peavad toetama.
Deb-pakettide maailmas on ühilduvuse tase hämmastav. Sama pakett installib ja töötab võrdselt hästi nii Debian 6 kui ka Ubuntu 19.04 puhul. Vanades Debiani distributsioonides sätestatud pakettide koostamise ja nendega töötamise protsessi standardid jäävad uudses Linux Mintis ja elementaarses OS-is asjakohaseks. Seetõttu piisab Veeam Agent for Linuxi puhul ühest deb-paketist iga riistvaraplatvormi kohta.
Kuid rpm pakettide maailmas on erinevused suured. Esiteks seetõttu, et on kaks täiesti sõltumatut turustajat, Red Hat ja SUSE, mille jaoks ühilduvus on täiesti ebavajalik. Teiseks on neil turustajatel nende jaotuskomplektid. tugi ja eksperimentaalne. Samuti pole vaja nende vahel ühilduvust. Selgus, et el6, el7 ja el8 on oma paketid. Fedora jaoks eraldi pakett. Paketid SLES11 ja 12 jaoks ning eraldi üks openSUSE jaoks. Peamine probleem on sõltuvused ja paketinimed.
Sõltuvusprobleem
Kahjuks satuvad samad paketid erinevates distributsioonides sageli erinevate nimede alla. Allpool on veeam paketi sõltuvuste osaline loend.
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
Selle tulemusena on sõltuvuste loend distributsiooni jaoks ainulaadne.
Hullemaks läheb siis, kui uuendatud versioon hakkab end vana paketinime alla peitma.
Näide:
Paketti on Fedora 24-s värskendatud nursused versioonist 5 kuni versioonini 6. Meie toode on ehitatud versiooniga 5, et tagada ühilduvus vanemate distributsioonidega. Teegi vana 5. versiooni kasutamiseks Fedora 24-s pidin kasutama paketti ncurses-compat-libs.
Selle tulemusena on Fedora jaoks kaks paketti, millel on erinevad sõltuvused.
Veelgi huvitavam. Pärast järgmist levitamise värskendust pakett ncurses-compat-libs raamatukogu versiooniga 5 selgub, et see pole saadaval. Leviajal on kulukas lohistada vanu teeke distributsiooni uude versiooni. Mõne aja pärast kordus probleem SUSE distributsioonides.
Selle tulemusena pidid mõned distributsioonid oma selgesõnalisest sõltuvusest loobuma ncurses-libsja parandage toode nii, et see töötaks koos teegi mis tahes versiooniga.
Muide, Red Hati versioonis 8 pole enam metapaketti püüton, mis viitas vanale heale püüton 2.7. On olemas python2 и püüton3.
Alternatiiv paketihalduritele
Sõltuvustega seotud probleem on vana ja juba ammu ilmne. Pidage lihtsalt meeles sõltuvuspõrgu.
Erinevate teekide ja rakenduste kombineerimine nii, et need kõik töötaksid stabiilselt ja ei oleks vastuolus - tegelikult on see ülesanne, mida iga Linuxi levitaja püüab lahendada.
Paketihaldur püüab seda probleemi lahendada hoopis teistmoodi. Vihane Canonicalist. Põhiidee: rakendus töötab põhisüsteemist eraldatud ja kaitstud liivakastis. Kui rakendus nõuab teeke, tarnitakse need koos rakenduse endaga.
Flatpak võimaldab käivitada rakendusi ka liivakastis, kasutades Linuxi konteinereid. Kasutatakse ka liivakasti ideed AppImage.
Need lahendused võimaldavad teil luua ühe paketi mis tahes distributsiooni jaoks. Juhul kui Flatpak rakenduse installimine ja käivitamine on võimalik ka administraatori teadmata.
Peamine probleem seisneb selles, et kõik rakendused ei saa liivakastis töötada. Mõned inimesed vajavad otsest juurdepääsu platvormile. Ma ei räägi isegi tuumamoodulitest, mis on rangelt tuumast sõltuvad ega sobi liivakasti kontseptsiooniga.
Teine probleem seisneb selles, et ettevõttekeskkonnas populaarsed Red Hati ja SUSE distributsioonid ei sisalda veel Snappy ja Flatpaki tuge.
Sellega seoses pole Veeam Agent Linuxile saadaval mitte sisse lülitatud .
Pakihaldurite küsimuse lõpetuseks tahaksin märkida, et on võimalus paketihalduritest üldse loobuda, kombineerides binaarfailid ja skripti nende installimiseks ühte paketti.
Selline pakett võimaldab luua ühe ühise paketi erinevate distributsioonide ja platvormide jaoks, läbi viia interaktiivse installiprotsessi, tehes vajalikud kohandamised. Selliseid Linuxi pakette olen kohanud ainult VMware'ilt.
Uuendamisprobleem
Isegi kui kõik sõltuvusprobleemid on lahendatud, võib programm samal distributsioonil erinevalt töötada. See on uuenduste küsimus.
Värskendusstrateegiaid on kolm:
- Lihtsaim on mitte kunagi värskendada. Seadsin serveri üles ja unustasin selle. Miks värskendada, kui kõik töötab? Probleemid algavad esmakordsel toega ühenduse võtmisel. Distributsiooni looja toetab ainult värskendatud versiooni.
- Saate turustajat usaldada ja seadistada automaatsed värskendused. Sel juhul helistatakse tugiteenusele tõenäoliselt kohe pärast ebaõnnestunud värskendust.
- Käsitsi värskendamise võimalus alles pärast selle testimisinfrastruktuuris käivitamist on kõige usaldusväärsem, kuid kulukas ja aeganõudev. Kõik ei saa seda endale lubada.
Kuna erinevad kasutajad kasutavad erinevaid uuendusstrateegiaid, on vaja toetada nii uusimat väljalaset kui ka kõiki varem välja antud. See raskendab nii arendus- kui testimisprotsessi ning lisab tugimeeskonnale peavalu.
Erinevad riistvaraplatvormid
Erinevad riistvaraplatvormid on probleem, mis on suuresti spetsiifiline algkoodile. Vähemalt peate iga toetatud platvormi jaoks koguma binaarfaile.
Veeam Agent for Linuxi projektis ei saa me ikka veel midagi sellist RISC-i toetada.
Ma ei hakka sellel teemal lähemalt peatuma. Toon välja vaid põhiprobleemid: platvormist sõltuvad tüübid, nt size_t, struktuuri joondamine ja baitide järjekord.
Staatiline ja/või dünaamiline linkimine
Kuid küsimus on "Kuidas siduda raamatukogudega - dünaamiliselt või staatiliselt?" arutlemist väärt.
Reeglina kasutavad Linuxi C/C++ rakendused dünaamilist linkimist. See toimib suurepäraselt, kui rakendus on loodud spetsiaalselt konkreetse distributsiooni jaoks.
Kui ülesandeks on katta ühe binaarfailiga erinevaid distributsioone, siis tuleb keskenduda vanimale toetatud distributsioonile. Meie jaoks on selleks Red Hat 6. See sisaldab gcc 4.4, mida isegi C++11 standard ei toeta .
Ehitame oma projekti gcc 6.3 abil, mis toetab täielikult C++14. Loomulikult peate sel juhul Red Hat 6-s kandma kaasas libstdc++ ja võimendusteeke. Lihtsaim viis on nendega staatiliselt linkida.
Kuid kahjuks ei saa kõiki teeke staatiliselt linkida.
Esiteks süsteemiteegid nagu libfuse, libblkid on vaja dünaamiliselt linkida, et tagada nende ühilduvus kerneli ja selle moodulitega.
Teiseks on litsentsidega peensus.
GPL-litsents võimaldab põhimõtteliselt siduda teeke ainult avatud lähtekoodiga. MIT ja BSD võimaldavad staatilist linkimist ja teekide kaasamist projekti. Kuid LGPL ei paista staatilise linkimisega vastuolus olevat, vaid nõuab linkimiseks vajalike failide jagamist.
Üldiselt väldib dünaamilise linkimise kasutamine seda, et teil pole vaja midagi esitada.
C/C++ rakenduste loomine
Erinevate platvormide ja distributsioonide jaoks C/C++ rakenduste ehitamiseks piisab gcc sobiva versiooni valimisest või ehitamisest ning konkreetsete arhitektuuride jaoks ristkompilaatorite kasutamisest ning kogu teekide komplekti kokkupanemisest. See töö on üsna teostatav, kuid üsna tülikas. Ja pole mingit garantiid, et valitud kompilaator ja teegid pakuvad toimiva versiooni.
Ilmne eelis: infrastruktuur on oluliselt lihtsustatud, kuna kogu ehitusprotsessi saab lõpule viia ühes masinas. Lisaks piisab ühe arhitektuuri jaoks ühe binaarfailide komplekti kogumisest ja saate need pakkida erinevate distributsioonide jaoks mõeldud pakettidesse. Nii luuakse Veeam Agent for Linuxi jaoks veeami paketid.
Erinevalt sellest võimalusest saate lihtsalt ette valmistada farmi, see tähendab mitu masinat kokkupanekuks. Iga selline masin pakub konkreetse distributsiooni ja konkreetse arhitektuuri jaoks rakenduste kompileerimist ja pakettide koostamist. Sel juhul tehakse koostamine turustaja koostatud vahenditega. See tähendab, et kompilaatori ettevalmistamise ja teekide valimise etapp on välistatud. Lisaks saab koostamisprotsessi hõlpsalt paralleelselt paralleelida.
Sellel lähenemisviisil on aga negatiivne külg: iga sama arhitektuuri distributsiooni jaoks peate koguma oma binaarfailide komplekti. Puuduseks on ka see, et nii palju masinaid tuleb hooldada ning eraldada palju kettaruumi ja RAM-i.
Nii kompileeritakse veeamsnapi kerneli mooduli KMOD paketid Red Hati distributsioonide jaoks.
Avage ehitusteenus
Kolleegid SUSE-st proovisid rakendada mõnda keskteed rakenduste koostamise ja pakettide koostamise eriteenuse näol - .
Sisuliselt on tegemist hüperviisoriga, mis loob virtuaalmasina, paigaldab sinna kõik vajalikud paketid, kompileerib rakenduse ja ehitab paketi selles isoleeritud keskkonnas, misjärel virtuaalmasin vabastatakse.
OpenBuildService'is juurutatud planeerija määrab, kui palju virtuaalmasinaid see optimaalse paketi koostamise kiiruse jaoks käivitada saab. Sisseehitatud allkirjastamismehhanism allkirjastab paketid ja laadib need üles sisseehitatud hoidlasse. Sisseehitatud versioonihaldussüsteem salvestab muudatuste ja järkude ajaloo. Jääb üle lihtsalt oma allikad sellesse süsteemi lisada. Te ei pea isegi serverit ise seadistama, võite kasutada avatud serverit.
Siiski on probleem: sellist harvesterit on raske olemasolevasse infrastruktuuri sobitada. Näiteks pole versioonikontrolli vaja, meil on lähtekoodide jaoks juba oma. Meie allkirjamehhanism on erinev: kasutame spetsiaalset serverit. Samuti pole hoidlat vaja.
Lisaks on muude distributsioonide - näiteks Red Hati - tugi üsna halvasti rakendatud, mis on arusaadav.
Sellise teenuse eeliseks on SUSE distributsiooni järgmise versiooni kiire tugi. Enne väljalaske ametlikku väljakuulutamist postitatakse komplekteerimiseks vajalikud pakendid avalikku hoidlasse. OpenBuildService'i saadaolevate distributsioonide loendisse ilmub uus. Märkame ruudu ja see lisatakse ehitusplaani. Seega toimub distributsiooni uue versiooni lisamine peaaegu ühe klõpsuga.
Meie infrastruktuuris on OpenBuildService'i abil kokku pandud kõik veeamsnapi kerneli mooduli KMP paketid SUSE distributsioonide jaoks.
Järgmisena tahaksin peatuda kerneli moodulitega seotud probleemidel.
kernel ABI
Linuxi kerneli mooduleid on ajalooliselt levitatud lähtekujul. Fakt on see, et kerneli loojad ei koorma end tuumamoodulite stabiilse API toetamise pärast ja eriti binaarsel tasemel, mida edaspidi nimetatakse kABI-ks.
Vaniljetuuma mooduli ehitamiseks vajate kindlasti selle konkreetse tuuma päiseid ja see töötab ainult sellel tuumal.
DKMS võimaldab kerneli värskendamisel automatiseerida moodulite loomise protsessi. Selle tulemusena kasutavad Debiani hoidla kasutajad (ja selle paljud sugulased) tuumamooduleid kas levitaja hoidlast või DKMS-i abil allikast kompileeritud.
Ettevõtlussektorile selline olukord aga eriti ei sobi. Patenditud koodide levitajad soovivad toodet levitada kompileeritud binaarfailidena.
Administraatorid ei soovi turvakaalutlustel arendustööriistu tootmisserverites hoida. Enterprise Linuxi turustajad, nagu Red Hat ja SUSE, otsustasid, et nad võivad toetada oma kasutajate jaoks stabiilset kABI-d. Tulemuseks olid KMOD paketid Red Hati jaoks ja KMP paketid SUSE jaoks.
Selle lahenduse olemus on üsna lihtne. Distributsiooni konkreetse versiooni puhul on kerneli API külmutatud. Levitaja teatab, et kasutab kernelit näiteks 3.10 ja teeb ainult parandusi ja täiustusi, mis ei mõjuta kerneli liideseid ning kõige esimese kerneli jaoks kogutud mooduleid saab ilma ümberkompileerimiseta kasutada kõigi järgnevate jaoks.
Red Hat väidab, et kABI ühilduvus levib kogu selle elutsükli jooksul. See tähendab, et kokkupandud moodul rhel 6.0 jaoks (väljalase november 2010) peaks töötama ka versiooniga 6.10 (väljalase juuni 2018). Ja see on peaaegu 8 aastat. Loomulikult on see ülesanne üsna raske.
Oleme registreerinud mitmeid juhtumeid, kus veeamsnapi moodul lakkas töötamast kABI ühilduvusprobleemide tõttu.
Pärast seda, kui RHEL 7.0 jaoks kompileeritud veeamsnap moodul osutus RHEL 7.5 tuumaga mitteühilduvaks, kuid see laaditi ja garanteeris, et server jooksis kokku, loobusime täielikult kABI ühilduvuse kasutamisest RHEL 7 jaoks.
Praegu sisaldab RHEL 7 KMOD pakett iga väljalaskeversiooni komplekti ja mooduli laadivat skripti.
SUSE lähenes kABI-ühilduvuse ülesandele hoolikamalt. Need pakuvad kABI-ühilduvust ainult ühes hoolduspaketis.
Näiteks SLES 12 ilmumine toimus septembris 2014. Ja SLES 12 SP1 oli juba detsembris 2015 ehk siis on möödas veidi rohkem kui aasta. Kuigi mõlemad versioonid kasutavad tuuma 3.12, ei ühildu need kABI-ga. Ilmselgelt on kABI-ühilduvuse säilitamine vaid aasta jooksul palju lihtsam. Iga-aastane kerneli mooduli värskendustsükkel ei tohiks mooduli loojatele probleeme tekitada.
Selle SUSE poliitika tulemusena ei ole me oma veeamsnapi moodulis registreerinud ühtegi probleemi kABI ühilduvusega. Tõsi, SUSE pakettide arv on peaaegu suurusjärgu võrra suurem.
Plaastrid ja tagaportid
Kuigi levitajad püüavad tagada kABI ühilduvuse ja tuuma stabiilsuse, püüavad nad ka selle stabiilse tuuma jõudlust parandada ja defekte kõrvaldada.
Samal ajal jälgivad ettevõtte Linuxi tuuma arendajad lisaks enda "vigade kallal töötamisele" ka vanilje tuumas toimuvaid muutusi ja kannavad need üle oma "stabiilsesse".
Mõnikord toob see kaasa uusi .
Red Hat 6 viimases versioonis tehti viga ühes väiksemas värskenduses. See tõi kaasa asjaolu, et veeamsnapi moodul jooksis hetktõmmise avaldamisel süsteemi kokku. Võrreldes kerneli allikaid enne ja pärast värskendust, saime teada, et süüdi oli backport. Sarnane parandus tehti ka vanilje tuuma versioonis 4.19. Lihtsalt see parandus töötas vanilje tuumas hästi, kuid selle ülekandmisel "stabiilsele" versioonile 2.6.32 tekkis probleem spinlockiga.
Muidugi on kõigil alati vigu, aga kas tasus stabiilsusega riskides koodi lohistada 4.19 pealt 2.6.32 peale?.. Ma pole kindel...
Kõige hullem on see, kui turundus sekkub "stabiilsuse" ja "moderniseerimise" vahelisesse tõmblusse. Turundusosakond vajab, et uuendatud distributsiooni tuum oleks ühelt poolt stabiilne ning samal ajal parema jõudluse ja uute funktsioonidega. See viib kummaliste kompromissideni.
Kui proovisin SLES 4.4 SP12-st kerneli 3-le moodulit ehitada, leidsin üllatuseks selles vanilla 4.8 funktsiooni. Minu arvates on SLES 4.4 SP12 tuuma 3 ploki sisend-/väljundrakendus sarnasem 4.8 tuumaga kui SLES4.4 SP12 stabiilse 2 kerneli eelmine väljalase. Ma ei saa hinnata, mitu protsenti koodi SP4.8 jaoks kernelist 4.4-st SLES 3-le üle kanti, kuid ma ei saa isegi kernelit sama stabiilseks 4.4-ks nimetada.
Kõige ebameeldivam selle juures on see, et kirjutades moodulit, mis töötaks võrdselt hästi erinevatel tuumadel, ei saa enam tugineda kerneli versioonile. Arvestada tuleb ka jaotusega. On hea, et mõnikord saate osaleda definitsioonis, mis ilmub koos uute funktsioonidega, kuid see võimalus ei ilmu alati.
Selle tulemusena kasvab kood veidrate tingimuslike kompileerimisdirektiividega.
Samuti on paigad, mis muudavad dokumenteeritud kerneli API-d.
Sattusin jaotusele 5.16 ja oli väga üllatunud, kui nägin, et lookup_bdev kutse selles kerneli versioonis muutis sisendparameetrite loendit.
Selle kokku saamiseks pidin makefile'i lisama skripti, mis kontrollib, kas funktsioonil lookup_bdev on maski parameeter.
Kerneli moodulite allkirjastamine
Aga tuleme tagasi pakettide levitamise teema juurde.
Stabiilse kABI üks eeliseid on see, et kerneli mooduleid saab allkirjastada binaarfailina. Sel juhul saab arendaja olla kindel, et moodulit pole kogemata kahjustatud ega tahtlikult muudetud. Seda saate kontrollida käsuga modinfo.
Red Hat ja SUSE distributsioonid võimaldavad kontrollida mooduli signatuuri ja laadida seda ainult siis, kui vastav sertifikaat on süsteemis registreeritud. Sertifikaat on avalik võti, millega moodul allkirjastatakse. Jagame seda eraldi pakendina.
Probleem on siin selles, et sertifikaadid saab kas kernelisse sisse ehitada (levitajad kasutavad neid) või need tuleb utiliidi abil kirjutada EFI püsimällu mokutil. Kasulikkus mokutil Sertifikaadi installimisel nõuab see süsteemi taaskäivitamist ja isegi enne operatsioonisüsteemi tuuma laadimist palub administraatoril lubada uue sertifikaadi laadimine.
Seega nõuab sertifikaadi lisamine füüsilist administraatori juurdepääsu süsteemile. Kui masin asub kuskil pilves või lihtsalt kaugserveriruumis ja ligipääs toimub ainult võrgu kaudu (näiteks ssh kaudu), siis on sertifikaati võimatu lisada.
EFI virtuaalmasinates
Vaatamata sellele, et EFI-d on juba pikka aega toetanud peaaegu kõik emaplaaditootjad, ei pruugi administraator süsteemi paigaldamisel mõelda EFI vajalikkusele ning see võidakse keelata.
Mitte kõik hüperviisorid ei toeta EFI-d. VMWare vSphere toetab EFI-d alates versioonist 5.
Microsoft Hyper-V sai ka EFI toe alates Hyper-V-st Windows Server 2012R2 jaoks.
Kuid vaikekonfiguratsioonis on see funktsioon Linuxi masinate jaoks keelatud, mis tähendab, et sertifikaati ei saa installida.
Seadistage suvand versioonis vSphere 6.5 Secure Boot võimalik ainult veebiliidese vanas versioonis, mis töötab Flashi kaudu. HTML-5 veebiliides on endiselt kaugel.
Eksperimentaalsed jaotused
Ja lõpuks, käsitleme eksperimentaalsete ja ilma ametliku toetuseta levitamist. Ühest küljest ei leidu selliseid distributsioone tõenäoliselt tõsiste organisatsioonide serverites. Sellistele distributsioonidele puudub ametlik tugi. Seetõttu esitage need. Toodet ei saa sellises distributsioonis toetada.
Sellised distributsioonid muutuvad aga mugavaks platvormiks uute eksperimentaalsete lahenduste proovimiseks. Näiteks Fedora, OpenSUSE Tumbleweed või Debiani ebastabiilsed versioonid. Need on üsna stabiilsed. Neil on alati uued programmide versioonid ja alati uus tuum. Aasta pärast võib see eksperimentaalne funktsioon jõuda värskendatud RHEL-i, SLES-i või Ubuntu juurde.
Nii et kui miski ei tööta eksperimentaalsel distributsioonil, on see põhjus probleemi väljaselgitamiseks ja selle lahendamiseks. Peate olema valmis selleks, et see funktsioon ilmub peagi kasutajate tootmisserveritesse.
Saate uurida versiooni 3.0 ametlikult toetatud distributsioonide praegust loendit . Kuid tegelik nimekiri distributsioonidest, millel meie toode võib töötada, on palju laiem.
Mind isiklikult huvitas eksperiment Elbruse OS-iga. Peale veeam paketi valmimist oli meie toode paigaldatud ja töökorras. Kirjutasin sellest katsest Habré kohta aastal .
Noh, uute distributsioonide toetamine jätkub. Ootame versiooni 4.0 avaldamist. Beeta on ilmumas, nii et hoidke silm peal !
Allikas: www.habr.com