Kita ngembangake DevOps kanthi paling apik. Ana 8 kita, lan Vasya minangka sing paling keren ing Windows. Dumadakan Vasya lunga, lan aku duwe tugas ngluncurake proyek anyar sing diwenehake dening pembangunan Windows. Nalika aku mbuwang kabeh tumpukan pangembangan Windows ing meja, aku ngerti yen kahanan kasebut lara ...
Mangkene critane diwiwiti Alexandra Sinchinova ing . Nalika spesialis Windows anjog metu saka perusahaan, Alexander kepingin weruh apa apa saiki. Ngalih menyang Linux, mesthi! Alexander bakal menehi pitutur marang kowe kepiye carane nggawe preseden lan nransfer bagean pangembangan Windows menyang Linux nggunakake conto proyek sing wis rampung kanggo 100 pangguna pungkasan.
Carane gampang lan effortlessly ngirim project kanggo RPM nggunakake TFS, Wayang, Linux .NET inti? Kepiye carane ndhukung versi database proyek yen tim pangembangan krungu tembung Postgres lan Flyway kanggo pisanan, lan tenggat wektu sesuk? Kepiye cara nggabungake karo Docker? Carane menehi motivasi .NET pangembang kanggo nglirwaaken Windows lan smoothies ing sih saka Wayang lan Linux? Kepiye cara ngatasi konflik ideologi yen ora ana kekuwatan, utawa kepinginan, utawa sumber daya kanggo njaga Windows ing produksi? Babagan iki, uga babagan Web Deploy, testing, CI, babagan praktik nggunakake TFS ing proyek sing wis ana, lan, mesthi, babagan crutches sing rusak lan solusi sing bisa digunakake, ing transkrip laporan Alexander.
Dadi, Vasya kiwa, tugas ana ing aku, para pangembang ngenteni kanthi ora sabar karo pitchforks. Nalika pungkasane aku ngerti yen Vasya ora bisa bali, aku banjur mudhun menyang bisnis. Kanggo miwiti, aku ngevaluasi persentase Win VM ing armada kita. Skor kasebut ora milih Windows.
Amarga kita aktif ngembangake DevOps, aku ngerti manawa ana sing kudu diganti ing pendekatan kanggo ngirim aplikasi anyar. Mung ana siji solusi - yen bisa, transfer kabeh menyang Linux. Google nulungi aku - ing wektu iku .Net wis ditransfer menyang Linux, lan aku ngerti yen iki solusi!
Apa .NET inti magepokan karo Linux?
Ana sawetara alasan kanggo iki. Antarane "mbayar dhuwit" lan "ora mbayar", mayoritas bakal milih sing nomer loro - kaya aku. Lisensi kanggo MSDB regane udakara $1; njaga armada mesin virtual Windows regane atusan dolar. Kanggo perusahaan gedhe iki biaya gedhe. Mulane nyimpen - alesan pisanan. Ora sing paling penting, nanging salah siji sing penting.
Mesin virtual Windows njupuk sumber daya luwih akeh tinimbang para sadulur Linux - padha abot. Amarga ukuran perusahaan gedhe, kita milih Linux.
Sistem kasebut mung digabungake menyang CI sing ana. Kita nganggep awake dhewe DevOps progresif, kita nggunakake Bamboo, Jenkins lan GitLab CI, saengga umume karya kita mlaku ing Linux.
Alasan pungkasan yaiku iringan sing trep. We needed kanggo murah alangi kanggo entri kanggo "iringan" - wong lanang sing ngerti bagean technical, njamin layanan uninterrupted, lan njaga layanan saka baris kapindho. Dheweke wis kenal karo tumpukan Linux, mula luwih gampang ngerti, ndhukung lan njaga produk anyar tinimbang nggunakake sumber daya tambahan kanggo ngerti fungsi piranti lunak sing padha kanggo platform Windows.
syarat
Kawitan lan utomo - penak saka solusi anyar kanggo pangembang. Ora kabeh padha siap kanggo owah-owahan, utamanΓ© sawise tembung Linux ngandika. Pangembang pengin Visual Studio favorit, TFS karo autotests kanggo rakitan lan smoothies. Cara pangiriman menyang produksi ora penting kanggo wong-wong mau. Mulane, kita mutusake ora ngganti proses biasa lan ninggalake kabeh sing ora diganti kanggo pangembangan Windows.
Proyek anyar dibutuhake nggabungake menyang CI sing ana. Ril wis ana lan kabeh pakaryan kudu ditindakake kanthi njupuk parameter sistem manajemen konfigurasi, standar pangiriman sing ditampa lan sistem pemantauan.
Gampang dhukungan lan operasi, minangka syarat kanggo ambang entri minimal kanggo kabeh peserta anyar saka macem-macem divisi lan departemen dhukungan.
Deadline - wingi.
Win Development Group
Apa tim Windows nggarap banjur?
Saiki aku bisa ngomong kanthi yakin IdentityServer4 punika kelangan free alternatif kanggo ADFS karo Kapabilitas padha, utawa apa Inti Kerangka Entitas - swarga kanggo pangembang, ngendi sampeyan ora kudu repot nulis skrip SQL, nanging njlèntrèhaké pitakonan ing database ing istilah OOP. Nanging banjur, sajrone diskusi babagan rencana aksi, aku ndeleng tumpukan iki kaya-kaya cuneiform Sumeria, mung ngerteni PostgreSQL lan Git.
Ing wektu iku kita aktif nggunakake Wayang minangka sistem manajemen konfigurasi. Ing umume proyek kita digunakake GitLab CI, lentur, layanan dhuwur-load imbang nggunakake HAProxy ngawasi kabeh karo Zabbix, ligamen Grafana ΠΈ Prometheus, Jaeger, lan kabeh iki muter ing potongan wesi HP c ESXi ing VMware. Saben uwong ngerti - klasik saka genre.
Ayo goleki lan coba ngerti apa sing kedadeyan sadurunge miwiti kabeh intervensi kasebut.
Ana apa
TFS minangka sistem sing cukup kuat sing ora mung ngirim kode saka pangembang menyang mesin produksi final, nanging uga duwe set kanggo integrasi sing fleksibel banget karo macem-macem layanan - kanggo nyedhiyakake CI ing tingkat salib-platform.
Sadurunge, iki minangka jendhela sing padhet. TFS nggunakake sawetara agen Mbangun, sing digunakake kanggo ngumpulake akeh proyek. Saben agen duwe 3-4 buruh kanggo parallelize tugas lan ngoptimalake proses. Banjur, miturut rencana rilis, TFS ngirim Build sing anyar dipanggang menyang server aplikasi Windows.
Apa sing arep digayuh?
Kita nggunakake TFS kanggo pangiriman lan pembangunan, lan mbukak aplikasi ing server Aplikasi Linux, lan ana sawetara jenis Piandel antarane wong-wong mau. Iki Kothak Piandel lan ana uyah saka karya ahead. Sadurunge pisah, aku bakal nyingkirake lan ujar sawetara tembung babagan aplikasi kasebut.
Proyek kasebut
Aplikasi kasebut nyedhiyakake fungsi kanggo nangani kertu prabayar.
Klien
Ana rong jinis pangguna. Pisanan entuk akses kanthi mlebu nggunakake sertifikat SSL SHA-2. U saka liya ana akses nggunakake login lan sandhi.
HAProxy
Banjur panjaluk klien menyang HAProxy, sing ngrampungake masalah ing ngisor iki:
- wewenang utama;
- mandhek SSL;
- nyetel panjalukan HTTP;
- panjalukan siaran.
Sertifikat klien diverifikasi ing sadawane rantai. kita- panguwasa lan kita bisa mbayar iki, amarga kita dhewe ngetokake sertifikat kanggo layanan klien.
Pay manungsa waΓ© menyang titik katelu, kita bakal bali menyang sethitik mengko.
Backend
Dheweke ngrancang nggawe backend ing Linux. Backend sesambungan karo basis data, mbukak dhaptar hak istimewa sing dibutuhake, banjur, gumantung saka hak istimewa pangguna sing sah, menehi akses kanggo mlebu dokumen finansial lan dikirim kanggo eksekusi, utawa ngasilake sawetara laporan.
Simpenan karo HAProxy
Saliyane rong konteks sing dilayari saben klien, ana uga konteks identitas. IdentityServer4 mung ngijini sampeyan kanggo mlebu, iki analog free lan kuat kanggo ADFS - Layanan Federasi Direktori Aktif.
Panjaluk identitas diproses ing sawetara langkah. Langkah pisanan - pelanggan mlebu ing mburi, sing komunikasi karo server iki lan mriksa ananΓ© token kanggo klien. Yen ora ditemokake, panyuwunan kasebut bali menyang konteks asale, nanging kanthi pangalihan, lan kanthi pangalihan kasebut menyang identitas.
Langkah kapindho - panjaluk kasebut ditampa menyang kaca wewenang ing IdentityServer, ing ngendi klien ndhaptar, lan token sing ditunggu-tunggu katon ing database IdentityServer.
Langkah katelu - klien iki redirected bali marang konteks asale.
IdentityServer4 nduweni fitur: iku ngasilake respon kanggo request bali liwat HTTP. Ora ketompo carane kita berjuang karo nyetel server, ora ketompo carane kita enlightened dhΓ©wΓ© karo dokumentasi, saben-saben kita nampa panjalukan klien awal karo URL sing teka liwat HTTPS, lan IdentityServer bali konteks padha, nanging karo HTTP. Kita padha cingak! Lan kita nransfer kabeh iki liwat konteks identitas menyang HAProxy, lan ing header kita kudu ngowahi protokol HTTP menyang HTTPS.
Apa dandan lan ing ngendi sampeyan nyimpen?
Kita ngirit dhuwit kanthi nggunakake solusi gratis kanggo menehi wewenang klompok pangguna, sumber daya, amarga kita ora nempatake IdentityServer4 minangka simpul sing kapisah ing bagean sing kapisah, nanging digunakake bebarengan karo backend ing server sing padha ing endi backend aplikasi mlaku. .
Carane kudu bisa
Dadi, kaya aku janji - Magic Box. Kita wis ngerti manawa kita dijamin pindhah menyang Linux. Ayo ngrumusake tugas tartamtu sing mbutuhake solusi.
Wayang wujud. Kanggo ngirim lan ngatur konfigurasi layanan lan aplikasi, resep-resep sing keren kudu ditulis. Gulungan potlot kanthi cetha nuduhake carane cepet lan efisien rampung.
Cara pangiriman. Standar kasebut yaiku RPM. Saben uwong ngerti yen ing Linux sampeyan ora bisa nindakake tanpa, nanging proyek kasebut, sawise perakitan, minangka set file DLL sing bisa dieksekusi. Ana udakara 150, proyek kasebut cukup angel. Siji-sijine solusi sing harmonis yaiku ngemas binar iki menyang RPM lan nyebarake aplikasi kasebut.
Versiing. Kita kudu ngeculake asring banget, lan kita kudu mutusake carane nggawe jeneng paket kasebut. Iki minangka pitakonan babagan tingkat integrasi karo TFS. Kita duwe agen mbangun ing Linux. Nalika TFS ngirim tugas kanggo handler - buruh - kanggo agen Mbangun, iku uga pass Bunch saka variabel sing mungkasi munggah ing lingkungan proses handler. Variabel lingkungan iki ngemot jeneng Build, jeneng versi, lan variabel liyane. Waca liyane babagan iki ing bagean "Mbangun paket RPM".
Nyetel TFS teka mudhun kanggo nyetel Pipeline. Sadurunge, kita ngumpulake kabeh proyek Windows ing agen Windows, nanging saiki agen Linux katon - agen Build, sing kudu dilebokake ing grup mbangun, ditambah karo sawetara artefak, lan ngandhani apa jinis proyek sing bakal dibangun ing agen Build iki. , lan piye wae ngowahi Pipeline.
IdentityServer. ADFS dudu cara kita, kita arep Open Source.
Ayo dadi liwat komponen.
Kothak Piandel
Dumadi saka patang bagean.
Agen Linux Mbangun. Linux, amarga kita mbangun - iku logis. Bagian iki ditindakake kanthi telung langkah.
- Konfigurasi buruh lan ora piyambak, wiwit karya mbagekke ing project iki samesthine.
- Instal .NET inti 1.x. Napa 1.x nalika 2.0 wis kasedhiya ing repositori standar? Amarga nalika kita miwiti pembangunan, versi stabil 1.09, lan diputusake kanggo nggawe proyek kasebut adhedhasar.
- Git 2.x.
RPM-gudang. Paket RPM kudu disimpen ing endi wae. Dianggep manawa kita bakal nggunakake gudang RPM perusahaan sing padha sing kasedhiya kanggo kabeh host Linux. Sing padha nindakake. Server repositori dikonfigurasi pancing web sing ndownload paket RPM sing dibutuhake saka lokasi sing ditemtokake. Versi paket kasebut dilaporake menyang webhook dening agen Build.
GitLab. manungsa waΓ©! GitLab ing kene ora digunakake dening pangembang, nanging dening departemen operasi kanggo ngontrol versi aplikasi, versi paket, ngawasi status kabeh mesin Linux, lan nyimpen resep - kabeh manifests Wayang.
Wayang - ngrampungake kabeh masalah kontroversial lan ngirim konfigurasi sing dikarepake saka Gitlab.
Kita miwiti nyilem. Kepiye cara pangiriman DLL menyang RPM?
Pangiriman DDL menyang RPM
Ayo dadi ngomong kita duwe .NET pangembangan rock star. Iku nggunakake Visual Studio lan nggawe cabang release. Sawise iku, diunggah menyang Git, lan Git ing kene minangka entitas TFS, yaiku, minangka gudang aplikasi sing dienggo pangembang.
Sawise TFS weruh yen komitmen anyar wis teka. app kang? Ing setelan TFS ana label nuduhake sumber apa agen Mbangun tartamtu wis. Ing kasus iki, dheweke weruh yen kita mbangun proyek .NET Core lan milih agen Linux Build saka blumbang.
Agen Mbangun nampa sumber lan ngundhuh sing perlu katergantungan saka repositori .NET, npm, lsp. lan sawise mbangun aplikasi kasebut dhewe lan kemasan sabanjure, ngirim paket RPM menyang gudang RPM.
Ing sisih liya, kedadeyan ing ngisor iki. Insinyur departemen operasi langsung melu peluncuran proyek kasebut: dheweke ngganti versi paket ing Hiera ing gudang ngendi resep aplikasi disimpen, sawise Wayang micu Yum, njupuk paket anyar saka gudang, lan versi anyar saka aplikasi siap digunakake.
Kabeh iku prasaja ing tembung, nanging apa sing kedadeyan ing agen Build dhewe?
Packing DLL RPM
Nampa sumber proyek lan mbangun tugas saka TFS. Agen mbangun wiwit mbangun proyek dhewe saka sumber. Proyek sing dirakit kasedhiya minangka set file DLL, sing dikemas ing arsip zip kanggo nyuda beban ing sistem file.
Arsip ZIP dibuwang menyang direktori mbangun paket RPM. Sabanjure, skrip Bash miwiti variabel lingkungan, nemokake versi Build, versi proyek, path menyang direktori mbangun, lan mbukak RPM-build. Sawise mbangun wis rampung, paket diterbitake kanggo panyimpenan lokal, sing dumunung ing agen Mbangun.
Sabanjure, saka agen Mbangun menyang server ing gudang RPM Panjaluk JSON dikirim nuduhake jeneng versi lan mbangun. Webhook, sing dakkandhakake sadurunge, ndownload paket iki saka gudang lokal ing agen Build lan nggawe perakitan anyar kasedhiya kanggo instalasi.
Napa skema pangiriman paket tartamtu iki menyang repositori RPM? Napa aku ora bisa langsung ngirim paket sing wis dirakit menyang gudang? Kasunyatane iki minangka syarat kanggo njamin keamanan. Skenario iki mbatesi kemungkinan wong sing ora sah ngunggah paket RPM menyang server sing bisa diakses kabeh mesin Linux.
Versi database
Ing konsultasi karo tim pangembangan, ternyata wong lanang luwih cedhak karo MS SQL, nanging ing umume proyek non-Windows, kita wis nggunakake PostgreSQL kanthi sekuat tenaga. Amarga kita wis mutusake kanggo ninggalake kabeh sing dibayar, kita uga wiwit nggunakake PostgreSQL ing kene.
Ing bagean iki aku arep kanggo pitutur marang kowe carane kita versi database lan carane kita milih antarane Flyway lan Entity Framework Core. Ayo katon ing pro lan cons sing.
ΠΠΈΠ½ΡΡΡ
Flyway mung dadi siji cara, kita kita ora bisa muter maneh - iki minangka kerugian sing signifikan. Sampeyan bisa mbandhingake karo Entity Framework Core kanthi cara liya - babagan kepenak pangembang. Sampeyan elinga yen kita sijine iki ing ngarep, lan kritΓ©ria utama ora ngganti apa-apa kanggo pembangunan Windows.
Kanggo Flyway kita sawetara jinis pambungkus dibutuhakesupaya wong lanang ora nulis pitakon SQL. Dheweke luwih cedhak karo operasi ing istilah OOP. Kita nulis instruksi kanggo nggarap obyek database, nggawe query SQL lan dieksekusi. Versi database anyar wis siyap, diuji - kabeh apik, kabeh bisa digunakake.
Entity Framework Core duwe minus - ing beban abot mbangun pitakon SQL suboptimal, lan drawdown ing database bisa dadi pinunjul. Nanging amarga kita ora duwe layanan beban dhuwur, kita ora ngetung beban ing atusan RPS, kita nampa risiko iki lan delegated masalah kanggo mangsa kita.
ΠΠ»ΡΡΡ
Inti Kerangka Entitas dianggo metu saka kothak lan gampang kanggo berkembang, lan Flyway Gampang nggabungake menyang CI sing ana. Nanging kita nggawe trep kanggo pangembang :)
Prosedur roll-up
Wayang ndeleng manawa ana owah-owahan ing versi paket, kalebu sing tanggung jawab kanggo migrasi. Kaping pisanan, nginstal paket sing ngemot skrip migrasi lan fungsionalitas sing gegandhengan karo database. Sawise iki, aplikasi sing bisa digunakake karo database diwiwiti maneh. Sabanjure, instalasi komponen sing isih ana. Urutan paket diinstal lan aplikasi diluncurake diterangake ing manifes Wayang.
Aplikasi nggunakake data sensitif, kayata token, sandhi database, kabeh iki ditarik menyang config saka master Wayang, ngendi padha disimpen ing wangun ndhelik.
masalah TFS
Sawise kita mutusake lan nyadari yen kabeh pancen bisa digunakake kanggo kita, aku mutusake kanggo ndeleng apa sing kedadeyan karo majelis ing TFS kanthi sakabehe kanggo departemen pangembangan Win ing proyek liyane - apa kita mbangun / ngeculake kanthi cepet utawa ora, lan nemokake masalah sing signifikan babagan kacepetan.
Salah sawijining proyek utama mbutuhake 12-15 menit kanggo ngumpul - suwene suwe, sampeyan ora bisa urip kaya ngono. A analisis cepet nuduhake drawdown elek ing I / O, lan iki ing susunan.
Sawise nganalisa komponen kanthi komponen, aku nemtokake telung fokus. pisanan- "Kaspersky antivirus", sing mindai sumber ing kabeh agen Windows Build. Kapindho - Windows Indexer. Iku ora dipatèni, lan kabeh wis diindeks ing wektu nyata ing agen Mbangun sak proses penyebaran prajurit.
Katelu - Npm nginstal. Ternyata ing umume Pipelines kita nggunakake skenario sing tepat iki. Napa dheweke ala? Prosedur instalasi Npm ditindakake nalika wit dependensi dibentuk ing package-lock.json, ing ngendi versi paket sing bakal digunakake kanggo mbangun proyek kasebut direkam. Kakurangan iku Npm nginstal narik munggah versi paling anyar saka paket saka Internet saben wektu, lan iki njupuk akèh wektu ing cilik saka project gedhe.
Pangembang kadhangkala nyobi ing mesin lokal kanggo nyoba carane bagean tartamtu utawa kabeh proyek bisa digunakake. Kadhangkala, kabeh iku kelangan lokal, nanging padha nglumpuk, mbalek metu, lan ora ana apa-apa. Kita wiwiti ngerti apa masalahe - ya, macem-macem versi paket kanthi dependensi.
kaputusan
- Sumber ing pangecualian AV.
- Pateni indeksasi.
- Menyang npm ci.
Keuntungan saka npm ci yaiku kita Kita ngumpulake wit dependensi sapisan, lan kita entuk kesempatan kanggo nyedhiyakake pangembang dhaftar paket saiki, karo kang bisa eksprimen lokal minangka akeh sing disenengi. Iki ngirit wektu pangembang sing nulis kode.
Konfigurasi
Saiki sethithik babagan konfigurasi repositori. Historis kita nggunakake Nexus kanggo ngatur repositori, kalebu REPO internal. Repositori internal iki ngemot kabeh komponen sing digunakake kanggo tujuan internal, contone, pemantauan sing ditulis dhewe.
Kita uga nggunakake NuGet, amarga nduweni cache sing luwih apik dibandhingake karo manajer paket liyane.
asil
Sawise kita ngoptimalake Agen Mbangun, wektu mbangun rata-rata suda saka 12 menit dadi 7.
Yen kita Count kabeh mesin sing bisa digunakake kanggo Windows, nanging ngalih menyang Linux ing project iki, kita disimpen bab $ 10. Lan iku mung ing lisensi, lan liyane yen kita njupuk menyang akun isi.
Rencana
Kanggo kuartal sabanjure, kita ngrancang ngupayakake ngoptimalake pangiriman kode.
Ngalih menyang gambar Docker prebuild. TFS punika bab kelangan karo akeh Plugins sing ngijini sampeyan kanggo nggabungake menyang Pipeline, kalebu rakitan basis pemicu saka, ngomong, gambar Docker. Kita pengin nggawe pemicu iki kanggo sing padha package-lock.json. Yen komposisi komponen sing digunakake kanggo mbangun proyek kasebut owah-owahan, kita mbangun gambar Docker anyar. Iku mengko digunakake kanggo masang wadhah karo aplikasi nglumpuk. Saiki ora kaya ngono, nanging kita arep ngalih menyang arsitektur layanan mikro ing Kubernetes, sing aktif berkembang ing perusahaan kita lan wis suwe ngladeni solusi produksi.
Ringkesan
Aku kasurung everyone kanggo uncalan adoh Windows, nanging ora amarga aku ora ngerti carane cook iku. Alesane yaiku paling akeh solusi Opensource tumpukan Linux. Opo sampean ora opo-opo ngirit sumber daya. Miturut pendapatku, masa depan dadi solusi Open Source ing Linux kanthi komunitas sing kuat.
Profil speaker Alexander Sinchinov .
punika konferensi integrasi pembangunan, testing lan operasi pangolahan kanggo profesional dening profesional. Mulane proyek sing diomongake Alexander? dileksanakake lan digunakake, lan ing dina kinerja ana loro rilis sukses. On Ing tanggal 27 lan 28 Mei bakal ana kasus liyane sing padha saka praktisi. Sampeyan isih bisa mlumpat menyang kreta pungkasan lan utawa njupuk wektu tiket. Ketemu kita ing Skolkovo!
Source: www.habr.com