Mēs izstrādājām DevOps, cik vien labi varējām. Mēs bijām astoņi, un Vasja bija stilīgākā sistēmā Windows. Pēkšņi Vasja aizgāja, un man bija uzdevums uzsākt jaunu projektu, ko nodrošināja Windows izstrāde. Kad es nometu visu Windows izstrādes steku uz galda, es sapratu, ka situācija ir sāpīga...
Tā sākas stāsts Aleksandra Sinčinova par . Kad vadošais Windows speciālists pameta uzņēmumu, Aleksandrs domāja, ko tagad darīt. Protams, pārslēdzieties uz Linux! Aleksandrs pastāstīs, kā viņam izdevās izveidot precedentu un daļu Windows izstrādes pārcelt uz Linux, izmantojot pabeigta projekta piemēru 100 000 gala lietotājiem.
Kā viegli un bez piepūles piegādāt projektu RPM, izmantojot TFS, Puppet, Linux .NET kodolu? Kā atbalstīt projektu datu bāzes versiju veidošanu, ja izstrādes komanda pirmo reizi dzird vārdus Postgres un Flyway, un termiņš ir parīt? Kā integrēties ar Docker? Kā motivēt .NET izstrādātājus atteikties no Windows un smūtijiem par labu Puppet un Linux? Kā atrisināt ideoloģiskos konfliktus, ja nav ne spēka, ne vēlēšanās, ne resursu Windows uzturēšanai ražošanā? Par to, kā arī par Web Deploy, testēšanu, CI, par TFS izmantošanas praksi esošajos projektos un, protams, par salūzušiem kruķiem un darba risinājumiem Aleksandra ziņojuma atšifrējumā.
Tātad, Vasja aizgāja, uzdevums ir manā ziņā, izstrādātāji nepacietīgi gaida ar dakšām. Kad beidzot sapratu, ka Vasju nevar atgriezt, ķēros pie lietas. Sākumā es novērtēju Win VM procentuālo daļu mūsu flotē. Rezultāts nebija par labu Windows.
Tā kā mēs aktīvi izstrādājam DevOps, es sapratu, ka kaut kas ir jāmaina pieejā jaunas lietojumprogrammas piegādei. Bija tikai viens risinājums - ja iespējams, visu pārcelt uz Linux. Google man palīdzēja - tajā laikā .Net jau bija portēts uz Linux, un es sapratu, ka tas ir risinājums!
Kāpēc .NET kodols kopā ar Linux?
Tam bija vairāki iemesli. Starp “maksāt naudu” un “nemaksāt” lielākā daļa izvēlēsies otro - tāpat kā es. MSDB licence maksā aptuveni 1 USD; Windows virtuālo mašīnu parka uzturēšana maksā simtiem dolāru. Lielam uzņēmumam tie ir lieli izdevumi. Tāpēc ietaupījums Sākot no pirmais iemesls. Nevis svarīgākais, bet viens no nozīmīgākajiem.
Windows virtuālās mašīnas aizņem vairāk resursu nekā viņu Linux brāļi - tie ir smagi. Ņemot vērā lielā uzņēmuma mērogu, mēs izvēlējāmies Linux.
Sistēma ir vienkārši integrēta esošajā CI. Mēs sevi uzskatām par progresīviem DevOps, mēs izmantojam Bamboo, Jenkins un GitLab CI, tāpēc lielākā daļa mūsu darbu darbojas operētājsistēmā Linux.
Pēdējais iemesls ir ērts pavadījums. Vajadzēja pazemināt iebraukšanas barjeru “eskortam” – puišiem, kuri saprot tehnisko daļu, nodrošina nepārtrauktu apkalpošanu un apkalpo pakalpojumus no otrās līnijas. Viņi jau bija pazīstami ar Linux steku, tāpēc viņiem ir daudz vieglāk saprast, atbalstīt un uzturēt jaunu produktu, nekā tērēt papildu resursus, lai izprastu to pašu programmatūras funkcionalitāti Windows platformai.
Prasības
Pirmkārt un galvenokārt - jaunā risinājuma ērtības izstrādātājiem. Ne visi no viņiem bija gatavi pārmaiņām, it īpaši pēc vārda Linux izrunāšanas. Izstrādātāji vēlas savu iecienītāko Visual Studio, TFS ar automātiskajiem testiem komplektiem un kokteiļiem. Viņiem nav svarīgi, kā notiek piegāde uz ražošanu. Tāpēc mēs nolēmām nemainīt ierasto procesu un atstāt visu nemainīgu Windows izstrādei.
Nepieciešams jauns projekts integrēt esošajā KI. Sliedes jau bija un viss darbs bija jāveic, ņemot vērā konfigurācijas vadības sistēmas parametrus, pieņemtos piegādes standartus un uzraudzības sistēmas.
Atbalsta un darbības vienkāršība, kā nosacījums minimālajam iestāšanās slieksnim visiem jaunajiem dalībniekiem no dažādām divīzijām un atbalsta nodaļas.
Termiņš - vakar.
Win attīstības grupa
Ar ko tad strādāja Windows komanda?
Tagad to varu droši apgalvot Identitātes serveris4 ir forša bezmaksas alternatīva ADFS ar līdzīgām iespējām, vai kas Entītijas struktūras kodols - izstrādātāju paradīze, kur nav jāraizējas ar SQL skriptu rakstīšanu, bet gan jāapraksta vaicājumi datubāzē OOP terminos. Bet tad, apspriežot rīcības plānu, es paskatījos uz šo kaudzi tā, it kā tas būtu šumeru ķīļraksts, atpazīstot tikai PostgreSQL un Git.
Toreiz mēs aktīvi izmantojām marionete kā konfigurācijas pārvaldības sistēma. Lielākajā daļā mūsu projektu mēs izmantojām GitLab CI, Elastīgs, sabalansētus augstas slodzes pakalpojumus, izmantojot HAProxy uzraudzīja visu ar Zabbix, saites grafana и Prometejs, Vilnas triko, un tas viss griezās uz dzelzs gabaliem HP c ESXi par VMware. Visi to zina – žanra klasika.
Apskatīsim un mēģināsim saprast, kas notika, pirms mēs sākām visas šīs iejaukšanās.
Kas notika
TFS ir diezgan jaudīga sistēma, kas ne tikai piegādā kodu no izstrādātāja līdz galīgajai ražošanas iekārtai, bet tai ir arī komplekts ļoti elastīgai integrācijai ar dažādiem pakalpojumiem - lai nodrošinātu CI starpplatformu līmenī.
Iepriekš tie bija cietie logi. TFS izmantoja vairākus Build aģentus, kas tika izmantoti daudzu projektu apkopošanai. Katram aģentam ir 3–4 darbinieki, lai paralēli veiktu uzdevumus un optimizētu procesu. Pēc tam saskaņā ar izlaišanas plāniem TFS piegādāja tikko izcepto Build Windows lietojumprogrammu serverim.
Ko mēs gribējām sasniegt?
Mēs izmantojam TFS piegādei un izstrādei un palaižam lietojumprogrammu Linux lietojumprogrammu serverī, un starp tām ir sava veida maģija. Šis Burvju kastīte un priekšā ir darba sāls. Pirms to izjaukšu, paspēšu soli malā un teikšu dažus vārdus par aplikāciju.
Projekts
Lietojumprogramma nodrošina funkcionalitāti priekšapmaksas karšu apstrādei.
Klients
Bija divu veidu lietotāji. Pirmais ieguva piekļuvi, piesakoties, izmantojot SSL SHA-2 sertifikātu. U otrais bija piekļuve, izmantojot pieteikumvārdu un paroli.
HAProxy
Pēc tam klienta pieprasījums nonāca HAProxy, kas atrisināja šādas problēmas:
- primārā atļauja;
- SSL pārtraukšana;
- HTTP pieprasījumu regulēšana;
- apraides pieprasījumi.
Klienta sertifikāts tika pārbaudīts visā ķēdē. Mēs - iestāde un mēs to varam atļauties, jo mēs paši izsniedzam pakalpojumu klientiem sertifikātus.
Pievērsiet uzmanību trešajam punktam, pie tā atgriezīsimies nedaudz vēlāk.
aizmugure
Viņi plānoja izveidot aizmuguri operētājsistēmā Linux. Aizmugursistēma mijiedarbojas ar datu bāzi, ielādē nepieciešamo privilēģiju sarakstu un pēc tam atkarībā no autorizētā lietotāja privilēģijām nodrošina piekļuvi finanšu dokumentu parakstīšanai un nosūtīšanai izpildei vai kāda veida atskaites ģenerēšanai.
Ietaupījumi ar HAProxy
Papildus diviem kontekstiem, kuros navigēja katrs klients, bija arī identitātes konteksts. Identitātes serveris4 tikai ļauj jums pieteikties, tas ir bezmaksas un spēcīgs analogs ADF Sākot no Active Directory federācijas pakalpojumi.
Identitātes pieprasījums tika apstrādāts vairākos posmos. Pirmais solis - klients iekļuva backend, kas sazinājās ar šo serveri un pārbaudīja klienta pilnvaras esamību. Ja tas netika atrasts, pieprasījums tika atgriezts atpakaļ kontekstā, no kura tas tika saņemts, taču ar novirzīšanu, un ar novirzīšanu tas tika novirzīts uz identitāti.
Otrais solis – pieprasījums saņemts uz autorizācijas lapu IdentityServer, kur klients reģistrējās, un šis ilgi gaidītais marķieris parādījās IdentityServer datu bāzē.
Trešais solis - klients tika novirzīts atpakaļ kontekstam, no kura tas nāca.
IdentityServer4 ir funkcija: tas atgriež atbildi uz atgriešanas pieprasījumu, izmantojot HTTP. Neatkarīgi no tā, cik daudz mēs cīnījāmies ar servera iestatīšanu, neatkarīgi no tā, cik daudz mēs sevi apgaismojām ar dokumentāciju, katru reizi, kad mēs saņēmām sākotnējo klienta pieprasījumu ar URL, kas nāca caur HTTPS, un IdentityServer atgrieza to pašu kontekstu, bet ar HTTP. Mēs bijām šokēti! Un mēs to visu pārsūtījām caur identitātes kontekstu uz HAProxy, un galvenēs mums bija jāmaina HTTP protokols uz HTTPS.
Kāds ir uzlabojums un kur jūs ietaupāt?
Ietaupījām naudu, izmantojot bezmaksas risinājumu lietotāju grupas, resursu autorizācijai, jo IdentityServer4 nenovietojām kā atsevišķu mezglu atsevišķā segmentā, bet izmantojām kopā ar aizmugursistēmu tajā pašā serverī, kur darbojas aplikācijas aizmugure. .
Kā tam vajadzētu darboties
Tātad, kā jau solīju - Magic Box. Mēs jau saprotam, ka mums ir garantēta virzība uz Linux. Formulēsim konkrētus uzdevumus, kuriem bija nepieciešami risinājumi.
Leļļu manifesti. Lai nodrošinātu un pārvaldītu pakalpojumu un lietojumprogrammu konfigurāciju, bija jāraksta foršas receptes. Zīmuļa rullis daiļrunīgi parāda, cik ātri un efektīvi tas tika paveikts.
Piegāde metode. Standarts ir RPM. Ikviens saprot, ka Linux bez tā nevar iztikt, taču pats projekts pēc montāžas bija izpildāmu DLL failu kopums. Viņu bija ap 150, projekts bija diezgan grūts. Vienīgais harmoniskais risinājums ir iesaiņot šo bināro failu RPM un izvietot no tā lietojumprogrammu.
Versionēšana. Mums bija jāizlaiž ļoti bieži, un mums bija jāizlemj, kā izveidot pakotnes nosaukumu. Tas ir jautājums par integrācijas līmeni ar TFS. Mums bija izveides aģents operētājsistēmā Linux. Kad TFS nosūta uzdevumu apdarinātājam — darbiniekam — Build aģentam, tas arī nodod tam virkni mainīgo, kas nonāk apdarinātāja procesa vidē. Šie vides mainīgie satur Build nosaukumu, versijas nosaukumu un citus mainīgos. Vairāk par to lasiet sadaļā “RPM pakotnes veidošana”.
TFS iestatīšana nonāca pie cauruļvada iestatīšanas. Iepriekš mēs apkopojām visus Windows projektus uz Windows aģentiem, bet tagad parādās Linux aģents - Build aģents, kas jāiekļauj būvēšanas grupā, jāpapildina ar dažiem artefaktiem un jāpasaka, kāda veida projekti tiks veidoti uz šī Build aģenta. , un kaut kā modificēt cauruļvadu.
IdentityServer. ADFS nav mūsu ceļš, mēs ejam uz atvērtā pirmkoda izmantošanu.
Iesim cauri komponentiem.
Burvju kastīte
Sastāv no četrām daļām.
Linux Build aģents. Linux, jo mēs tai būvējam — tas ir loģiski. Šī daļa tika veikta trīs posmos.
- Konfigurējiet darbiniekus un ne viens pats, jo bija paredzēts sadalīts darbs pie projekta.
- Instalējiet .NET Core 1.x. Kāpēc 1.x, ja standarta repozitorijā jau ir pieejams 2.0? Jo, kad sākām izstrādi, stabilā versija bija 1.09, uz kuras pamata tika nolemts taisīt projektu.
- Git 2.x.
RPM-repozitorijs. RPM pakotnes bija kaut kur jāglabā. Tika pieņemts, ka mēs izmantosim to pašu korporatīvo RPM repozitoriju, kas ir pieejams visiem Linux saimniekiem. To viņi darīja. Repozitorija serveris ir konfigurēts tīmekļa āķis kas lejupielādēja nepieciešamo RPM pakotni no norādītās vietas. Par pakotnes versiju tīmekļa aizķerim ziņoja Build aģents.
GitLab. Uzmanību! GitLab šeit izmanto nevis izstrādātāji, bet gan operāciju nodaļa, lai kontrolētu lietojumprogrammu versijas, pakotņu versijas, uzraudzītu visu Linux mašīnu statusu, un tas saglabā recepti - visus Puppet manifestus.
marionete — atrisina visas strīdīgās problēmas un nodrošina tieši tādu konfigurāciju, kādu mēs vēlamies no Gitlab.
Mēs sākam nirt. Kā darbojas DLL piegāde uz RPM?
Piegāde DDL līdz RPM
Pieņemsim, ka mums ir .NET izstrādes rokzvaigzne. Tas izmanto Visual Studio un izveido laidiena filiāli. Pēc tam tas augšupielādē to pakalpojumā Git, un Git šeit ir TFS entītija, tas ir, tā ir lietojumprogrammu repozitorijs, ar kuru strādā izstrādātājs.
Pēc tam TFS redz, ka ir pienākusi jauna apņemšanās. Kura lietotne? TFS iestatījumos ir etiķete, kas norāda, kādi resursi ir konkrētajam Build aģentam. Šajā gadījumā viņš redz, ka mēs veidojam .NET Core projektu, un no kopas izvēlas Linux Build aģentu.
Build aģents saņem avotus un lejupielādē nepieciešamo atkarību no .NET repozitorija, npm utt. un pēc pašas lietojumprogrammas izveidošanas un turpmākās iesaiņošanas nosūta RPM pakotni uz RPM repozitoriju.
No otras puses, notiek sekojošais. Operāciju nodaļas inženieris ir tieši iesaistīts projekta izvēršanā: viņš maina pakotņu versijas Hiera repozitorijā, kurā tiek glabāta lietojumprogrammas recepte, pēc kuras tiek aktivizēta Lelle Yum, ienes jauno pakotni no krātuves, un jaunā lietojumprogrammas versija ir gatava lietošanai.
Vārdos viss ir vienkārši, bet kas notiek paša Build aģenta iekšienē?
Iepakojums DLL RPM
Saņemti projekta avoti un izveides uzdevums no TFS. Veidot aģents sāk būvēt pašu projektu no avotiem. Samontētais projekts pieejams komplektā DLL faili, kas ir iesaiņoti zip arhīvā, lai samazinātu failu sistēmas slodzi.
ZIP arhīvs tiek izmests uz RPM pakotnes veidošanas direktoriju. Pēc tam Bash skripts inicializē vides mainīgos, atrod Build versiju, projekta versiju, ceļu uz būvēšanas direktoriju un palaiž RPM-build. Kad būvēšana ir pabeigta, pakotne tiek publicēta vietējā repozitorija, kas atrodas Build aģentā.
Pēc tam no Build aģenta uz serveri RPM repozitorijā JSON pieprasījums ir nosūtīts norādot versijas un būvējuma nosaukumu. Webhook, par kuru es runāju iepriekš, lejupielādē tieši šo pakotni no Build aģenta vietējās krātuves un padara jauno komplektu pieejamu instalēšanai.
Kāpēc šī konkrētā paku piegādes shēma RPM repozitorijā? Kāpēc es nevaru uzreiz nosūtīt salikto pakotni uz repozitoriju? Fakts ir tāds, ka tas ir drošības nodrošināšanas nosacījums. Šis scenārijs ierobežo iespēju, ka nesankcionēti cilvēki augšupielādēs RPM pakotnes serverī, kas ir pieejams visām Linux iekārtām.
Datu bāzes versiju noteikšana
Konsultācijā ar izstrādātāju komandu izrādījās, ka puiši ir tuvāki MS SQL, bet lielākajā daļā ne-Windows projektu mēs jau ar visu spēku izmantojām PostgreSQL. Tā kā mēs jau bijām nolēmuši atteikties no visa apmaksātā, mēs sākām izmantot PostgreSQL arī šeit.
Šajā daļā es vēlos jums pastāstīt, kā mēs izveidojām datubāzes versijas un kā mēs izvēlējāmies starp Flyway un Entity Framework Core. Apskatīsim to plusus un mīnusus.
Mīnusi
Flyway iet tikai vienā virzienā, mēs mēs nevaram atgriezties - tas ir būtisks trūkums. Varat to salīdzināt ar Entity Framework Core citos veidos — izstrādātāja ērtību ziņā. Jūs atceraties, ka mēs to izvirzījām priekšplānā, un galvenais kritērijs bija neko nemainīt Windows izstrādei.
Flyway mums vajadzēja kaut kādu iesaiņojumulai puiši neraksta SQL vaicājumi. Tie ir daudz tuvāk darbībai OOP izteiksmē. Mēs uzrakstījām instrukcijas darbam ar datu bāzes objektiem, ģenerējām SQL vaicājumu un izpildījām to. Jaunā datu bāzes versija ir gatava, pārbaudīta - viss kārtībā, viss darbojas.
Entity Framework Core ir mīnuss — zem lielas slodzes tas veido neoptimālus SQL vaicājumus, un izņemšana datubāzē var būt ievērojama. Bet, tā kā mums nav augstas slodzes servisa, mēs nerēķinām slodzi simtos RPS, mēs pieņēmām šos riskus un deleģējām problēmu sev.
Plusi
Entītijas struktūras kodols darbojas ārpus kastes un ir viegli attīstāmsun Flyway Viegli integrējas esošajā CI. Bet mēs to darām ērti izstrādātājiem :)
Roll-up procedūra
Puppet redz, ka gaidāmas izmaiņas pakotnes versijā, tostarp tajā, kas ir atbildīga par migrāciju. Pirmkārt, tā instalē pakotni, kurā ir migrācijas skripti un ar datu bāzi saistītas funkcionalitātes. Pēc tam programma, kas darbojas ar datu bāzi, tiek restartēta. Tālāk seko atlikušo komponentu uzstādīšana. Pakešu instalēšanas un lietojumprogrammu palaišanas secība ir aprakstīta leļļu manifestā.
Lietojumprogrammas izmanto sensitīvus datus, piemēram, žetonus, datu bāzes paroles, tas viss tiek ievilkts konfigurācijā no Puppet master, kur tie tiek glabāti šifrētā veidā.
TFS problēmas
Kad mēs nolēmām un sapratām, ka mums viss patiešām darbojas, es nolēmu paskatīties uz to, kas notiek ar komplektiem TFS kopumā Win izstrādes nodaļai citos projektos - neatkarīgi no tā, vai mēs būvējam/izlaidām ātri vai nē, un atklāja būtiskas problēmas ar ātrumu.
Viena no galvenajiem projektiem montāža aizņem 12-15 minūtes - tas ir ilgs laiks, jūs nevarat tā dzīvot. Ātra analīze parādīja briesmīgu I/O samazināšanos, un tas notika masīvos.
Analizējot to pa komponentiem, es identificēju trīs perēkļus. Pirmkārt - "Kaspersky antivīruss", kas skenē avotus visos Windows Build aģentos. Otrais - Windows Indeksētājs. Tas netika atspējots, un viss tika indeksēts reāllaikā Build aģentos izvietošanas procesa laikā.
Trešais - Npm instalēšana. Izrādījās, ka lielākajā daļā cauruļvadu mēs izmantojām tieši šo scenāriju. Kāpēc viņš ir slikts? Npm instalēšanas procedūra tiek palaista, kad tiek izveidots atkarības koks pack-lock.json, kur tiek ierakstītas pakotņu versijas, kas tiks izmantotas projekta izveidei. Negatīvā puse ir tāda, ka Npm install katru reizi izvelk jaunākās pakotņu versijas no interneta, un tas aizņem daudz laika liela projekta gadījumā.
Izstrādātāji dažreiz eksperimentē ar vietējo mašīnu, lai pārbaudītu, kā darbojas konkrēta daļa vai viss projekts. Reizēm izrādījās, ka uz vietas viss ir forši, bet samontēja, izrullēja un nekas neizdevās. Mēs sākam saprast, kas ir problēma - jā, dažādas pakotņu versijas ar atkarībām.
Šķīdums
- Avoti AV izņēmumos.
- Atspējot indeksēšanu.
- Iet uz npm ci.
npm ci priekšrocības ir tādas, ka mēs Mēs vienu reizi apkopojam atkarības koku, un mēs iegūstam iespēju nodrošināt izstrādātāju pašreizējo paku sarakstu, ar kuru viņš var eksperimentēt uz vietas, cik vien viņam patīk. Šis ietaupa laiku izstrādātāji, kas raksta kodu.
Konfigurācija
Tagad nedaudz par repozitorija konfigurāciju. Vēsturiski mēs izmantojam sakars repozitoriju pārvaldīšanai, tostarp Iekšējais REPO. Šajā iekšējā repozitorijā ir visas sastāvdaļas, kuras mēs izmantojam iekšējiem mērķiem, piemēram, pašrakstītai uzraudzībai.
Mēs arī lietojam NuGet, jo tai ir labāka kešatmiņa salīdzinājumā ar citiem pakotņu pārvaldniekiem.
Piedzīvojiet efektīvu rezultātu spēku
Pēc Build Agents optimizēšanas vidējais izveides laiks tika samazināts no 12 minūtēm līdz 7.
Ja saskaitām visas mašīnas, kuras varējām izmantot operētājsistēmai Windows, bet šajā projektā pārgājām uz Linux, mēs ietaupījām apmēram $ 10 000. Un tas attiecas tikai uz licencēm un vairāk, ja ņemam vērā saturu.
Plāni
Nākamajā ceturksnī mēs plānojām strādāt pie koda piegādes optimizēšanas.
Pārslēgšanās uz iepriekš izveidotu Docker attēlu. TFS ir lieliska lieta ar daudziem spraudņiem, kas ļauj integrēties Pipeline, tostarp, piemēram, Docker attēla montēšanu, pamatojoties uz trigeriem. Mēs vēlamies aktivizēt šo vienu un to pašu pack-lock.json. Ja projekta izveidei izmantoto komponentu sastāvs kaut kā mainās, mēs veidojam jaunu Docker attēlu. Vēlāk to izmanto, lai izvietotu konteineru ar salikto lietojumprogrammu. Šobrīd tā nav, taču Kubernetes plānojam pāriet uz mikropakalpojumu arhitektūru, kas mūsu uzņēmumā aktīvi attīstās un jau ilgāku laiku apkalpo ražošanas risinājumus.
Kopsavilkums
Es aicinu visus izmest Windows, bet tas nav tāpēc, ka es nemāku to pagatavot. Iemesls ir tāds, ka lielākā daļa atvērtā pirmkoda risinājumu ir Linux kaudze. vai tev viss ir kārtībā ietaupīt uz resursiem. Manuprāt, nākotne pieder atvērtā pirmkoda risinājumiem operētājsistēmā Linux ar spēcīgu kopienu.
Aleksandra Sinčinova runātāja profils .
ir konference par izstrādes, testēšanas un darbības procesu integrāciju profesionāļiem, ko veic profesionāļi. Tāpēc projekts, par kuru runāja Aleksandrs? ieviesta un darbojas, un uzstāšanās dienā bija divi veiksmīgi izlaidumi. Ieslēgts 27. un 28. maijā būs vēl vairāk līdzīgu gadījumu no praktiķiem. Vēl var ielekt pēdējā vagonā un vai velti laiku biļete. Tiekamies Skolkovā!
Avots: www.habr.com