Nggawe aplikasi serep sing bisa digunakake ing distribusi apa wae ora gampang. Kanggo mesthekake Veeam Agent kanggo Linux bisa digunakake ing distribusi saka Red Hat 6 lan Debian 6, menyang OpenSUSE 15.1 lan Ubuntu 19.04, sampeyan kudu ngrampungake sawetara masalah, utamane yen produk piranti lunak kalebu modul kernel.
Artikel kasebut digawe adhedhasar bahan saka pidato ing konferensi kasebut .
Linux ora mung salah sawijining sistem operasi sing paling populer. Ateges, iki minangka platform kanthi basis sampeyan bisa nggawe sing unik, sing sampeyan dhewe. Thanks kanggo iki, Linux duwe akeh distribusi sing beda-beda ing set komponen piranti lunak. Lan ing kene ana masalah: supaya produk piranti lunak bisa digunakake ing distribusi apa wae, sampeyan kudu nganggep fitur saben.
Manajer paket. .deb vs .rpm
Ayo diwiwiti kanthi masalah sing jelas babagan nyebarake produk ing macem-macem distribusi.
Cara sing paling umum kanggo nyebarake produk piranti lunak yaiku nyelehake paket kasebut ing repositori supaya manajer paket sing dibangun ing sistem bisa nginstal saka kono.
Nanging, kita duwe rong format paket sing populer: Rpm и deb. Iki tegese kabeh wong kudu ndhukung.
Ing donya paket deb, tingkat kompatibilitas apik tenan. Paket sing padha diinstal lan bisa digunakake kanthi apik ing Debian 6 lan Ubuntu 19.04. Standar kanggo proses mbangun paket lan nggarap, sing dilebokake ing distribusi Debian lawas, tetep relevan ing Linux Mint lan OS SD sing anyar. Mulane, ing kasus Veeam Agent kanggo Linux, siji paket deb kanggo saben platform hardware cukup.
Nanging ing donya paket rpm, beda banget. Kaping pisanan, amarga ana rong distributor sing mandiri, Red Hat lan SUSE, sing kompatibilitas pancen ora perlu. Kapindho, distributor iki duwe kit distribusi saka sing. dhukungan lan eksperimen. Ana uga ora perlu kanggo kompatibilitas antarane wong-wong mau. Ternyata el6, el7 lan el8 duwe paket dhewe. Paket kapisah kanggo Fedora. Paket kanggo SLES11 lan 12 lan sing kapisah kanggo openSUSE. Masalah utama yaiku dependensi lan jeneng paket.
Masalah ketergantungan
Sayange, paket sing padha asring ana ing jeneng sing beda ing distribusi sing beda. Ing ngisor iki minangka dhaptar parsial saka dependensi paket veeam.
Kanggo EL7:
Kanggo SLES 12:
- libblkid
- libgcc
- libstdc++
- ncurses-libs
- sekring-libs
- file-libs
- veeamsnap=3.0.2.1185
- libblkid1
- libgcc_s1
- libstdc++6
- libmagic1
- libfuse2
- veeamsnap-kmp=3.0.2.1185
Akibaté, dhaptar dependensi unik kanggo distribusi.
Sing luwih elek yaiku nalika versi sing dianyari wiwit ndhelikake ing jeneng paket lawas.
Conto:
Paket wis dianyari ing Fedora 24 ncurses saka versi 5 kanggo versi 6. Produk kita dibangun karo versi 5 kanggo njamin kompatibilitas karo distribusi lawas. Kanggo nggunakake versi perpustakaan 5th lawas ing Fedora 24, aku kudu nggunakake paket kasebut ncurses-compat-libs.
Akibaté, ana rong paket kanggo Fedora, kanthi dependensi sing beda.
Luwih menarik. Sawise nganyari distribusi sabanjure, paket kasebut ncurses-compat-libs karo versi 5 saka perpustakaan iku dadi ora kasedhiya. Iku larang kanggo distributor kanggo nyeret perpustakaan lawas menyang versi anyar saka distribusi. Sawise sawetara wektu, masalah kasebut bola-bali ing distribusi SUSE.
Akibaté, sawetara distribusi kudu ngeculake ketergantungan sing jelas ncurses-libs, lan ndandani produk supaya bisa digunakake karo versi perpustakaan apa wae.
Miturut cara, ing versi 8 saka Red Hat ora ana paket meta maneh python, kang diarani lawas apik python-2.7. Ana python2 и python3.
Alternatif kanggo manajer paket
Masalah karo dependensi wis lawas lan wis suwe jelas. Mung elinga Dependency neraka.
Kanggo gabungke macem-macem perpustakaan lan aplikasi supaya kabeh bisa stabil lan ora konflik - nyatane, iki tugas sing distributor Linux nyoba kanggo ngatasi.
Manajer paket nyoba ngatasi masalah iki kanthi cara sing beda. Snappy saka Canonical. Gagasan utama: aplikasi kasebut mlaku ing kothak wedhi sing diisolasi lan dilindhungi saka sistem utama. Yen aplikasi mbutuhake perpustakaan, aplikasi kasebut diwenehake karo aplikasi kasebut dhewe.
Flatpak uga ngijini sampeyan kanggo mbukak aplikasi ing kothak wedhi nggunakake Linux Containers. Ide kothak wedhi uga digunakake AppImage.
Solusi kasebut ngidini sampeyan nggawe siji paket kanggo distribusi apa wae. Ing kasus saka Flatpak instalasi lan Bukak saka aplikasi bisa malah tanpa kawruh administrator.
Masalah utama yaiku ora kabeh aplikasi bisa mlaku ing kothak wedhi. Sawetara wong butuh akses langsung menyang platform kasebut. Aku ora malah ngomong bab modul kernel, kang strictly gumantung ing kernel lan ora pas karo konsep kothak wedhi.
Masalah kapindho yaiku distribusi sing populer ing lingkungan perusahaan saka Red Hat lan SUSE durung ngemot dhukungan kanggo Snappy lan Flatpak.
Ing babagan iki, Veeam Agent kanggo Linux ora kasedhiya ora on .
Kanggo ngrampungake pitakonan babagan manajer paket, aku pengin dicathet yen ana pilihan kanggo ninggalake manajer paket kanthi nggabungake file binar lan skrip kanggo nginstal dadi siji paket.
Bundel kasebut ngidini sampeyan nggawe siji paket umum kanggo macem-macem distribusi lan platform, nindakake proses instalasi interaktif, nindakake kustomisasi sing dibutuhake. Aku mung nemoni paket kasebut kanggo Linux saka VMware.
Nganyari masalah
Sanajan kabeh masalah ketergantungan wis dirampungake, program kasebut bisa mlaku kanthi beda ing distribusi sing padha. Iku bab nganyari.
Ana 3 strategi nganyari:
- Sing paling gampang yaiku ora tau nganyari. Aku nyiyapake server lan kelalen babagan. Apa nganyari yen kabeh bisa digunakake? Masalah wiwit sepisanan sampeyan hubungi dhukungan. Sing nggawe distribusi mung ndhukung rilis sing dianyari.
- Sampeyan bisa dipercaya distributor lan nyetel nganyari otomatis. Ing kasus iki, telpon kanggo ndhukung kamungkinan sanalika sawise nganyari gagal.
- Opsi nganyari manual mung sawise mlaku ing infrastruktur tes yaiku sing paling dipercaya, nanging larang lan akeh wektu. Ora saben wong bisa mbayar.
Amarga pangguna sing beda nggunakake strategi nganyari sing beda, mula kudu ndhukung rilis paling anyar lan kabeh sing dirilis sadurunge. Iki nggawe rumit proses pangembangan lan tes lan nambah ngelu menyang tim dhukungan.
Macem-macem platform hardware
Platform hardware sing beda-beda minangka masalah sing umume khusus kanggo kode asli. Paling ora, sampeyan kudu ngumpulake binari kanggo saben platform sing didhukung.
Ing proyek Veeam Agent for Linux, kita isih ora bisa ndhukung apa-apa kaya RISC iki.
Aku ora bakal ngomong babagan masalah iki kanthi rinci. Aku mung bakal njelaske nganggo bentuk garis masalah utama: jinis gumantung platform, kayata size_t, alignment struktur lan urutan byte.
Link statis lan / utawa dinamis
Nanging pitakonane yaiku "Kepiye nyambungake karo perpustakaan - kanthi dinamis utawa statis?" worth rembugan.
Minangka aturan, aplikasi C/C++ ing Linux nggunakake link dinamis. Iki dianggo apik yen aplikasi dibangun khusus kanggo distribusi tartamtu.
Yen tugase kanggo nutupi macem-macem distribusi kanthi siji file binar, mula sampeyan kudu fokus ing distribusi sing paling tuwa sing didhukung. Kanggo kita, iki Red Hat 6. Isine gcc 4.4, sing malah standar C ++ 11 ora ndhukung. .
Kita mbangun proyek nggunakake gcc 6.3, sing ndhukung C++ 14 kanthi lengkap. Mesthi, ing kasus iki, ing Red Hat 6 sampeyan kudu nggawa libstdc ++ lan nambah perpustakaan karo sampeyan. Cara paling gampang yaiku ngubungake kanthi statis.
Nanging sayangé, ora kabeh perpustakaan bisa disambungake kanthi statis.
Kaping pisanan, perpustakaan sistem kayata libfuse, libblkid kudu disambungake kanthi dinamis kanggo mesthekake kompatibilitas karo kernel lan module.
Kapindho, ana subtlety karo lisensi.
Lisensi GPL ing dasare ngidini sampeyan ngubungake perpustakaan mung karo kode opensource. MIT lan BSD ngidini ngubungake statis lan ngidini perpustakaan kalebu ing proyek. Nanging LGPL ora koyone mbantah link statis, nanging mbutuhake file sing perlu kanggo nyambungake bareng.
Umumé, nggunakake panyambungan dinamis bakal nyegah sampeyan kudu nyedhiyani apa wae.
Membangun aplikasi C/C++
Kanggo mbangun aplikasi C / C ++ kanggo platform lan distribusi sing beda, cukup kanggo milih utawa mbangun versi gcc sing cocog lan nggunakake kompiler silang kanggo arsitektur tartamtu lan ngumpulake kabeh perpustakaan. Karya iki cukup layak, nanging cukup nyusahake. Lan ora ana jaminan manawa kompiler lan perpustakaan sing dipilih bakal nyedhiyakake versi sing bisa digunakake.
Kauntungan sing jelas: infrastruktur disederhanakake, amarga kabeh proses mbangun bisa rampung ing siji mesin. Kajaba iku, cukup kanggo ngumpulake siji set binari kanggo siji arsitektur lan sampeyan bisa ngemas menyang paket kanggo distribusi sing beda. Iki carane paket veeam dibangun kanggo Veeam Agent kanggo Linux.
Beda karo pilihan iki, sampeyan mung bisa nyiyapake farm mbangun, yaiku, sawetara mesin kanggo perakitan. Saben mesin kasebut bakal nyedhiyakake kompilasi aplikasi lan perakitan paket kanggo distribusi tartamtu lan arsitektur tartamtu. Ing kasus iki, kompilasi ditindakake kanthi nggunakake sarana sing disiapake dening distributor. Yaiku, tahap nyiapake kompiler lan milih perpustakaan diilangi. Kajaba iku, proses mbangun bisa gampang paralel.
Nanging, ana kekurangan kanggo pendekatan iki: kanggo saben distribusi ing arsitektur sing padha, sampeyan kudu ngumpulake file binar dhewe. Kerugian liyane yaiku akeh mesin sing kudu dijaga lan akeh ruang disk lan RAM kudu dialokasikan.
Mangkene carane paket KMOD saka modul kernel veeamsnap dikompilasi kanggo distribusi Red Hat.
Bukak Layanan Mbangun
Kolega saka SUSE nyoba ngleksanakake sawetara titik tengah ing wangun layanan khusus kanggo ngumpulake aplikasi lan paket assembling - .
Ateges, iku hypervisor sing nggawe mesin virtual, nginstal kabeh paket sing dibutuhake, ngumpulake aplikasi lan mbangun paket ing lingkungan sing terisolasi iki, sawise mesin virtual kasebut dirilis.
Penjadwal sing dileksanakake ing OpenBuildService bakal nemtokake jumlah mesin virtual sing bisa diluncurake kanggo kacepetan bangunan paket sing optimal. Mekanisme tandha sing dibangun bakal mlebu paket kasebut lan diunggah menyang repositori sing dibangun. Sistem kontrol versi sing dibangun bakal nyimpen riwayat owah-owahan lan mbangun. Sing isih ana mung nambahake sumber sampeyan menyang sistem iki. Sampeyan malah ora kudu nyiyapake server dhewe; sampeyan bisa nggunakake sing mbukak.
Nanging, ana masalah: pemanen kuwi angel pas karo infrastruktur sing ana. Contone, kontrol versi ora dibutuhake; kita wis duwe dhewe kanggo kode sumber. Mekanisme tandha kita beda: kita nggunakake server khusus. Repositori uga ora dibutuhake.
Kajaba iku, dhukungan kanggo distribusi liyane - contone, Red Hat - dileksanakake rada kurang, sing bisa dingerteni.
Kauntungan saka layanan kasebut yaiku dhukungan cepet kanggo versi distribusi SUSE sabanjure. Sadurunge pengumuman resmi rilis, paket sing dibutuhake kanggo perakitan dipasang ing gudang umum. Sing anyar katon ing dhaptar distribusi sing kasedhiya ing OpenBuildService. Kita mriksa kothak lan ditambahake menyang rencana mbangun. Mangkono, nambah versi anyar saka distribusi wis rampung ing meh siji klik.
Ing infrastruktur kita, nggunakake OpenBuildService, kabeh macem-macem paket KMP saka modul kernel veeamsnap kanggo distribusi SUSE dirakit.
Sabanjure, aku pengin mikir babagan masalah khusus kanggo modul kernel.
kernel ABI
Modul kernel Linux wis historis disebarake ing wangun sumber. Kasunyatane manawa para pangripta kernel ora ngebotake awake dhewe kanthi prihatin ndhukung API sing stabil kanggo modul kernel, lan utamane ing tingkat binar, luwih diarani kABI.
Kanggo mbangun modul kanggo kernel vanilla, temtunipun kudu header saka kernel tartamtu iki, lan iku mung bisa digunakake ing kernel iki.
DKMS ngidini sampeyan ngotomatisasi proses mbangun modul nalika nganyari kernel. Akibaté, pangguna gudang Debian (lan akeh sedulure) nggunakake modul kernel saka gudang distributor utawa dikompilasi saka sumber nggunakake DKMS.
Nanging, kahanan iki ora cocog karo segmen Enterprise. Distributor kode kepemilikan pengin nyebarake produk kasebut minangka binari kompilasi.
Administrator ora pengin nyimpen alat pangembangan ing server produksi amarga alasan keamanan. Distributor Enterprise Linux kayata Red Hat lan SUSE mutusake manawa bisa ndhukung kABI sing stabil kanggo pangguna. Asil kasebut yaiku paket KMOD kanggo Red Hat lan paket KMP kanggo SUSE.
Inti saka solusi iki cukup prasaja. Kanggo versi distribusi tartamtu, API kernel beku. Distributor nyatakake yen dheweke nggunakake kernel, contone, 3.10, lan mung nggawe koreksi lan dandan sing ora mengaruhi antarmuka kernel, lan modul sing diklumpukake kanggo kernel pisanan bisa digunakake kanggo kabeh sing sabanjure tanpa recompilation.
Red Hat ngaku kompatibilitas kABI kanggo distribusi ing kabeh siklus urip. Sing, modul nglumpuk kanggo rhel 6.0 (rilis November 2010) uga kudu bisa ing versi 6.10 (rilis Juni 2018). Lan iki meh 8 taun. Alamiah, tugas iki cukup angel.
Kita wis nyathet sawetara kasus nalika modul veeamsnap mandheg kerja amarga masalah kompatibilitas kABI.
Sawise modul veeamsnap, disusun kanggo RHEL 7.0, ternyata ora kompatibel karo kernel saka RHEL 7.5, nanging dimuat lan dijamin bakal nabrak server, kita nglirwakake panggunaan kompatibilitas kABI kanggo RHEL 7 kabeh.
Saiki, paket KMOD kanggo RHEL 7 ngemot perakitan kanggo saben versi rilis lan skrip sing ngemot modul kasebut.
SUSE nyedhaki tugas kompatibilitas kABI kanthi luwih teliti. Padha nyedhiyakake kompatibilitas kABI mung ing siji paket layanan.
Contone, rilis SLES 12 ditindakake ing September 2014. Lan SLES 12 SP1 wis ana ing Desember 2015, yaiku, luwih saka setahun kepungkur. Sanajan loro rilis nggunakake kernel 3.12, kABI ora kompatibel. Temenan, njaga kompatibilitas kABI mung setaun luwih gampang. Siklus nganyari modul kernel taunan ngirim ora nyebabake masalah kanggo panyipta modul.
Minangka asil saka kabijakan SUSE iki, kita durung nyathet masalah siji karo kompatibilitas kABI ing modul veeamsnap. Bener, jumlah paket kanggo SUSE meh urutan gedhene luwih gedhe.
Patches lan backports
Senajan distributor nyoba kanggo mesthekake kompatibilitas kABI lan stabilitas kernel, padha uga nyoba kanggo nambah kinerja lan ngilangi cacat kernel stabil iki.
Ing wektu sing padha, saliyane "nggawe kesalahan" dhewe, pangembang perusahaan Linux kernel monitor ngganti kernel vanilla lan nransfer menyang "stabil".
Kadhangkala iki ndadékaké kanggo anyar .
Ing rilis paling anyar saka Red Hat 6, kesalahan digawe ing salah sawijining nganyari cilik. Iku mimpin kanggo kasunyatan sing modul veeamsnap dijamin kanggo nabrak sistem nalika gambar asli seko dirilis. Sawise mbandhingake sumber kernel sadurunge lan sawise nganyari, kita nemokake manawa backport sing disalahake. Perbaikan sing padha digawe ing versi kernel vanilla 4.19. Iku mung fix iki makarya nggoleki ing kernel vanilla, nanging nalika nransfer menyang "stabil" 2.6.32, ana masalah karo spinlock.
Mesthi, saben wong tansah duwe kasalahan, nanging iku worth nyeret kode saka 4.19 kanggo 2.6.32, risking stabilitas? .. Aku ora yakin ...
Sing paling awon yaiku nalika marketing melu perang antarane "stabilitas" lan "modernisasi." Departemen marketing mbutuhake inti saka distribusi sing dianyari dadi stabil, ing tangan siji, lan ing wektu sing padha luwih apik ing kinerja lan duwe fitur anyar. Iki ndadékaké kanggo kompromi aneh.
Nalika aku nyoba kanggo mbangun modul ing kernel 4.4 saka SLES 12 SP3, Aku kaget nemokake fungsi saka vanilla 4.8 ing. Ing mratelakake panemume, pemblokiran I / O implementasine saka 4.4 kernel saka SLES 12 SP3 luwih padha karo 4.8 kernel saka release sadurungé saka stabil 4.4 kernel saka SLES12 SP2. Aku ora bisa ngadili apa persentasi kode ditransfer saka kernel 4.8 kanggo SLES 4.4 kanggo SP3, nanging aku ora bisa malah nelpon kernel padha stabil 4.4.
Sing paling ora nyenengake yaiku nalika nulis modul sing bisa digunakake kanthi apik ing kernel sing beda, sampeyan ora bisa ngandelake versi kernel maneh. Sampeyan uga kudu njupuk menyang akun distribusi. Iku apik sing kadhangkala sampeyan bisa melu ing definisi sing katon bebarengan karo fungsi anyar, nanging kesempatan iki ora tansah katon.
Akibaté, kode dadi overgrown karo arahan kompilasi kondisional aneh.
Ana uga patch sing ngganti API kernel sing didokumentasikan.
Aku teka tengen distribusi 5.16 lan kaget banget weruh yen lookup_bdev telpon ing versi kernel iki ngganti dhaptar parameter input.
Kanggo nggabungake, aku kudu nambah skrip menyang makefile sing mriksa apa fungsi lookup_bdev duwe parameter topeng.
Modul kernel mlebu
Nanging ayo bali menyang masalah distribusi paket.
Salah sawijining kaluwihan kABI sing stabil yaiku modul kernel bisa ditandatangani minangka file binar. Ing kasus iki, pangembang bisa yakin manawa modul kasebut ora sengaja rusak utawa diowahi kanthi sengaja. Sampeyan bisa mriksa iki nganggo printah modinfo.
Distribusi Red Hat lan SUSE ngidini sampeyan mriksa teken modul lan mbukak mung yen sertifikat sing cocog didaftar ing sistem kasebut. Sertifikat minangka kunci umum kanggo mlebu modul kasebut. We disebaraké minangka paket kapisah.
Masalah ing kene yaiku sertifikat bisa dibangun ing kernel (distributor digunakake) utawa kudu ditulis ing memori non-volatile EFI nggunakake sarana. mokutil. Utilitas mokutil Nalika nginstal sertifikat, sampeyan kudu miwiti maneh sistem lan, sanajan sadurunge mbukak kernel sistem operasi, njaluk administrator ngidini ngemot sertifikat anyar.
Mangkono, nambah sertifikat mbutuhake akses administrator fisik menyang sistem. Yen mesin dumunung nang endi wae ing méga utawa mung ing kamar server remot lan akses mung liwat jaringan (contone, liwat ssh), iku bakal ora bisa kanggo nambah sertifikat.
EFI ing mesin virtual
Senadyan kasunyatan manawa EFI wis suwe didhukung dening meh kabeh manufaktur motherboard, nalika nginstal sistem, administrator bisa uga ora mikir babagan kabutuhan EFI, lan bisa uga dipateni.
Ora kabeh hypervisor ndhukung EFI. VMWare vSphere ndhukung EFI wiwit saka versi 5.
Microsoft Hyper-V uga entuk dhukungan EFI sing diwiwiti karo Hyper-V kanggo Windows Server 2012R2.
Nanging, ing konfigurasi gawan fungsi iki dipatèni kanggo mesin Linux, kang tegese certificate ora bisa diinstal.
Ing vSphere 6.5, atur pilihan Boot Aman mung bisa ing versi lawas saka antarmuka web, kang lumaku liwat Flash. UI Web ing HTML-5 isih adoh.
Distribusi eksperimental
Lan pungkasane, ayo nimbang masalah distribusi lan distribusi eksperimen tanpa dhukungan resmi. Ing tangan siji, distribusi kasebut ora bisa ditemokake ing server organisasi serius. Ora ana dhukungan resmi kanggo distribusi kasebut. Mulane, nyedhiyani sing. Produk ora bisa didhukung ing distribusi kasebut.
Nanging, distribusi kasebut dadi platform sing trep kanggo nyoba solusi eksperimen anyar. Contone, Fedora, OpenSUSE Tumbleweed utawa versi Debian sing ora stabil. Padha cukup stabil. Padha tansah duwe versi anyar saka program lan tansah kernel anyar. Ing setaun, fungsi eksperimen iki bisa uga ana ing RHEL, SLES utawa Ubuntu sing dianyari.
Dadi yen ana sing ora bisa digunakake ing distribusi eksperimen, iki minangka alasan kanggo nemtokake masalah lan ngrampungake. Sampeyan kudu siyap kanggo kasunyatan manawa fungsi iki bakal katon ing server produksi pangguna.
Sampeyan bisa nyinaoni dhaptar distribusi sing didhukung resmi saiki kanggo versi 3.0 . Nanging dhaptar distribusi nyata sing bisa digunakake produk kita luwih akeh.
Secara pribadi, aku kasengsem ing eksperimen karo Elbrus OS. Sawise ngrampungake paket veeam, produk kita wis diinstal lan bisa digunakake. Aku nulis babagan eksperimen iki ing Habré ing .
Ya, dhukungan kanggo distribusi anyar terus. Kita ngenteni versi 4.0 bakal dirilis. Beta bakal katon, mula kudu waspada !
Source: www.habr.com