Arendasime DevOpsi nii hästi kui suutsime. Meid oli 8 ja Vasya oli Windowsi kõige lahedam. Järsku Vasya lahkus ja mul oli ülesanne käivitada uus projekt, mille pakkus Windowsi arendus. Kui ma kogu Windowsi arenduspaki lauale viskasin, mõistsin, et olukord oli piin...
Nii see lugu algab Aleksandra Sinchinova edasi . Kui juhtiv Windowsi spetsialist ettevõttest lahkus, mõtles Aleksander, mida nüüd teha. Loomulikult lülituge Linuxile! Aleksander räägib teile, kuidas tal õnnestus 100 000 lõppkasutaja jaoks valminud projekti näitel luua pretsedent ja osa Windowsi arendusest Linuxile üle kanda.
Kuidas lihtsalt ja vaevata projekti RPM-i edastada TFS-i, Puppeti või Linuxi .NET-tuuma abil? Kuidas toetada projekti andmebaasi versioonimist, kui arendusmeeskond kuuleb esimest korda sõnu Postgres ja Flyway ning tähtaeg on ülehomme? Kuidas Dockeriga integreerida? Kuidas motiveerida .NET-i arendajaid loobuma Windowsist ja smuutidest Puppeti ja Linuxi kasuks? Kuidas lahendada ideoloogilisi konflikte, kui Windowsi tootmises ülalpidamiseks pole jõudu, tahtmist ega ressursse? Selle kohta, samuti veebi juurutamise, testimise, CI kohta, TFS-i kasutamise tavade kohta olemasolevates projektides ning loomulikult katkiste karkude ja töölahenduste kohta Alexanderi aruande ärakirjas.
Niisiis, Vasya lahkus, ülesanne on minu kanda, arendajad ootavad kannatamatult kahvliga. Kui lõpuks mõistsin, et Vasjat ei saa tagasi saata, asusin asja kallale. Alustuseks hindasin Win VM-ide protsenti meie masinapargis. Skoor ei olnud Windowsi kasuks.
Kuna arendame aktiivselt DevOpsi, mõistsin, et uue rakenduse tarnimise lähenemisviisis tuleb midagi muuta. Lahendus oli vaid üks – võimalusel viia kõik üle Linuxi. Google aitas mind – sel ajal oli .Net juba Linuxi porditud ja ma mõistsin, et see on lahendus!
Miks .NET core koos Linuxiga?
Sellel oli mitu põhjust. "Maksa raha" ja "ei maksa" vahel valib enamus teise - nagu mina. MSDB litsents maksab umbes 1 dollarit; Windowsi virtuaalmasinate pargi ülalpidamine maksab sadu dollareid. Suurele ettevõttele on see suur kulu. Sellepärast kokkuhoid - esimene põhjus. Mitte kõige olulisem, kuid üks olulisemaid.
Windowsi virtuaalmasinad võtavad rohkem ressursse kui nende Linuxi vennad - nad on rasked. Arvestades suure ettevõtte ulatust, valisime Linuxi.
Süsteem on lihtsalt integreeritud olemasolevasse CI-sse. Peame end progressiivseks DevOpsiks, kasutame Bamboo, Jenkinsi ja GitLab CI-d, nii et suurem osa meie tööst töötab Linuxis.
Viimane põhjus on mugav kaaslane. Meil oli vaja langetada sisenemisbarjääri "eskortidel" - meestel, kes mõistavad tehnilist osa, tagavad katkematu teeninduse ja hooldavad teenuseid teisest liinist. Nad olid Linuxi pinuga juba tuttavad, seega on neil palju lihtsam uut toodet mõista, toetada ja hooldada, kui kulutada täiendavaid ressursse, et mõista sama Windowsi platvormi tarkvara funktsionaalsust.
Nõuded
Eelkõige - uue lahenduse mugavus arendajatele. Kõik neist ei olnud muutusteks valmis, eriti pärast sõna Linux väljaütlemist. Arendajad soovivad oma lemmikut Visual Studio, koosluste ja smuutide automaattestidega TFS-i. Nende jaoks pole oluline, kuidas tootmisse tarnitakse. Seetõttu otsustasime tavalist protsessi mitte muuta ja jätta kõik Windowsi arendamiseks muutmata.
Vaja uus projekt integreerida olemasolevasse CI-sse. Rööpad olid juba olemas ja kogu töö tuli teha konfiguratsioonihaldussüsteemi parameetreid, aktsepteeritud tarnestandardeid ja seiresüsteeme arvestades.
Toetamise ja kasutamise lihtsus, mis on kõikide uute osalejate eri osakondadest ja tugiosakonnast minimaalse sisseastumisläve tingimuseks.
Tähtaeg - eile.
Võida arendusgrupp
Millega Windowsi meeskond siis töötas?
Nüüd võin seda julgelt väita Identiteediserver4 on lahe tasuta alternatiiv sarnaste võimalustega ADFS-ile või mis Olemi raamistiku tuum - arendaja paradiis, kus ei pea vaeva nägema SQL skriptide kirjutamisega, vaid kirjeldama andmebaasis olevaid päringuid OOP terminites. Aga siis, tegevuskava arutamise ajal, vaatasin seda virna, nagu oleks see sumeri kiilkiri, tundes ära ainult PostgreSQL ja Git.
Sel ajal kasutasime aktiivselt Nukuteater konfiguratsioonihaldussüsteemina. Enamikus oma projektides kasutasime GitLab CI, Elastne, tasakaalustatud suure koormusega teenuseid kasutades HAProxy jälgis kõike Zabbix, sidemed grafana и Prometheus, Jaeger, ja see kõik keerles rauatükkide peal HP c ESXi edasi VMware. Kõik teavad seda – žanri klassika.
Vaatame ja proovime mõista, mis toimus enne kõigi nende sekkumiste alustamist.
Mis juhtus
TFS on üsna võimas süsteem, mis mitte ainult ei edasta koodi arendajalt lõplikule tootmismasinale, vaid omab ka komplekti väga paindlikuks integreerimiseks erinevate teenustega - CI pakkumiseks platvormidevahelisel tasemel.
Varem olid need täisaknad. TFS kasutas mitmeid Buildi agente, mida kasutati paljude projektide koostamiseks. Igal agendil on 3-4 töötajat ülesannete paralleelseerimiseks ja protsessi optimeerimiseks. Seejärel edastas TFS väljalaskeplaanide kohaselt värskelt küpsetatud Buildi Windowsi rakendusserverisse.
Mida me saavutada tahtsime?
Kasutame kohaletoimetamiseks ja arendamiseks TFS-i ning käivitame rakendust Linuxi rakenduste serveris ning nende vahel on mingi maagia. See Magic Box ja ees on töö sool. Enne lahti võtmist astun sammu kõrvale ja räägin mõne sõna rakenduse kohta.
Projekt
Rakendus pakub funktsioone ettemakstud kaartide käsitlemiseks.
klient
Kasutajaid oli kahte tüüpi. Esimene sai juurdepääsu SSL SHA-2 sertifikaadiga sisse logides. U teine oli juurdepääs sisselogimise ja parooliga.
HAProxy
Seejärel läks kliendi taotlus HAProxy-le, mis lahendas järgmised probleemid:
- esmane luba;
- SSL-i lõpetamine;
- HTTP päringute häälestamine;
- saatetaotlused.
Kliendi sertifikaati kontrolliti kogu ahela ulatuses. Meie - asutus ja me saame seda endale lubada, kuna me ise väljastame teenindusklientidele sertifikaate.
Pöörake tähelepanu kolmandale punktile, selle juurde naaseme veidi hiljem.
Taustaprogramm
Nad plaanisid teha taustaprogrammi Linuxile. Taustaprogramm suhtleb andmebaasiga, laadib vajalike õiguste loendi ja seejärel, olenevalt sellest, millised õigused volitatud kasutajal on, annab juurdepääsu finantsdokumentide allkirjastamiseks ja täitmiseks saatmiseks või mõne aruande genereerimiseks.
Säästud HAProxyga
Lisaks kahele kontekstile, milles iga klient navigeeris, oli olemas ka identiteedikontekst. Identiteediserver4 võimaldab lihtsalt sisse logida, see on tasuta ja võimas analoog ADFS - Active Directory föderatsiooni teenused.
Identiteeditaotlust töödeldi mitmes etapis. Esimene samm - klient sattus tagaprogrammi, mis suhtles selle serveriga ja kontrollis kliendi tokeni olemasolu. Kui seda ei leitud, tagastati päring tagasi konteksti, kust see pärines, kuid ümbersuunamisega ja koos ümbersuunamisega läks see identiteedile.
Teine samm – taotlus võeti vastu IdentityServeri autoriseerimislehele, kuhu klient registreerus, ja see kauaoodatud märk ilmus IdentityServeri andmebaasi.
Kolmas samm - klient suunati tagasi konteksti, kust see tuli.
IdentityServer4-l on funktsioon: see tagastab vastuse tagastamistaotlusele HTTP kaudu. Ükskõik kui palju me serveri seadistamisega vaeva nägime, kui palju me end dokumentatsiooniga valgustasime, saime iga kord esialgse kliendipäringu URL-iga, mis tuli HTTPS-i kaudu ja IdentityServer tagastas sama konteksti, kuid HTTP-ga. Olime šokeeritud! Ja me kandsime selle kõik läbi identiteedikonteksti HAProxy-sse ja päistes pidime muutma HTTP-protokolli HTTPS-iks.
Mis on paranemine ja kust säästsite?
Säästsime raha, kasutades tasuta lahendust kasutajate grupi, ressursside autoriseerimiseks, kuna me ei paigutanud IdentityServer4 eraldiseisvasse segmenti eraldi sõlmena, vaid kasutasime seda koos taustaprogrammiga samas serveris, kus rakenduse taustaprogramm töötab. .
Kuidas see peaks toimima
Niisiis, nagu ma lubasin - Magic Box. Oleme juba aru saanud, et liikumine Linuxi poole on garanteeritud. Sõnastame konkreetsed ülesanded, mis nõudsid lahendusi.
Nuku manifest. Teenuste ja rakenduste konfiguratsiooni tarnimiseks ja haldamiseks tuli kirjutada lahedaid retsepte. Pliiatsirull näitab kõnekalt, kui kiiresti ja tõhusalt see tehtud sai.
Kohaletoimetamise viis. Standard on RPM. Kõik saavad aru, et Linuxis ei saa te ilma selleta hakkama, kuid projekt ise oli pärast kokkupanekut käivitatavate DLL-failide komplekt. Neid oli umbes 150, projekt oli päris raske. Ainus harmooniline lahendus on pakendada see binaarfail RPM-i ja juurutada rakendus sellest.
Versioonide koostamine. Pidime väga sageli välja andma ja pidime otsustama, kuidas paketi nime moodustada. See on TFS-iga integreerituse taseme küsimus. Meil oli Linuxis ehitusagent. Kui TFS saadab ülesande töötlejale – töötajale – ehitusagendile, edastab see sellele ka hulga muutujaid, mis jõuavad töötleja protsessi keskkonda. Need keskkonnamuutujad sisaldavad järgu nime, versiooni nime ja muid muutujaid. Lisateavet selle kohta leiate jaotisest "RPM-paketi koostamine".
TFS-i seadistamine jõudis torujuhtme seadistamiseni. Varem kogusime kõik Windowsi projektid Windowsi agentide peal, kuid nüüd ilmub Linuxi agent - ehitusagent, mis tuleb lisada ehitusrühma, rikastada mõningate artefaktidega ja öelda, mis tüüpi projekte sellele ehitusagendile ehitatakse. ja muutke torujuhet kuidagi.
Identiteediserver. ADFS ei ole meie tee, me kasutame avatud lähtekoodi.
Vaatame komponente läbi.
Magic Box
Koosneb neljast osast.
Linuxi ehitusagent. Linux, sest me ehitame selle jaoks – see on loogiline. See osa tehti kolmes etapis.
- Konfigureerige töötajaid ja mitte üksi, sest projektiga loodeti jagada tööd.
- Installige .NET Core 1.x. Miks 1.x, kui 2.0 on standardhoidlas juba saadaval? Sest kui arendamisega alustasime, oli stabiilne versioon 1.09 ja selle põhjal otsustatigi projekt teha.
- Git 2.x.
RPM-hoidla. RPM-pakette oli vaja kuskil hoiustada. Eeldati, et kasutame sama ettevõtte RPM-i hoidlat, mis on saadaval kõigile Linuxi hostidele. Seda nad tegidki. Hoidlaserver on konfigureeritud veebikonks mis laadis määratud asukohast alla vajaliku RPM-paketi. Paketi versioonist teatas veebihaagile ehitusagent.
GitLab. Tähelepanu! Siin ei kasuta GitLabi mitte arendajad, vaid operatsioonide osakond, et juhtida rakenduste versioone, pakettide versioone, jälgida kõigi Linuxi masinate olekut ja see salvestab retsepti – kõik Puppeti manifestid.
Nukuteater — lahendab kõik vastuolulised probleemid ja pakub Gitlabilt täpselt sellise konfiguratsiooni, mida me tahame.
Hakkame sukelduma. Kuidas DLL-i edastamine RPM-ile töötab?
Tarne DDL kuni RPM
Oletame, et meil on .NET-i arenduse rokkstaar. See kasutab Visual Studio ja loob väljalaskeharu. Pärast seda laadib see selle Giti üles ja Git on siin TFS-üksus, st see on rakenduste hoidla, millega arendaja töötab.
Pärast seda näeb TFS, et saabunud on uus kohustus. Milline rakendus? TFS-i sätetes on silt, mis näitab, millised ressursid konkreetsel ehitusagendil on. Sel juhul näeb ta, et me ehitame .NET Core projekti ja valib basseinist Linux Buildi agendi.
Ehitusagent saab allikad ja laadib need alla sõltuvused .NET-i hoidlast, npm-st jne. ja pärast rakenduse enda koostamist ja sellele järgnevat pakkimist saadab RPM-i paketi RPM-i hoidlasse.
Teisest küljest juhtub järgmine. Operatsiooniosakonna insener on projekti juurutamisega otseselt seotud: ta muudab sisse pakettide versioone Hiera hoidlas, kus on salvestatud rakenduse retsept, mille järel vallandub Nukk Yum, toob hoidlast uue paketi ja rakenduse uus versioon on kasutamiseks valmis.
Sõnades on kõik lihtne, aga mis toimub Buildi agendi enda sees?
Pakkimine DLL RPM
Sai projekti allikad ja ehitusülesande TFS-ist. Ehitusagent hakkab projekti ise allikatest üles ehitama. Kokkupandud projekt on saadaval komplektina DLL-failid, mis on failisüsteemi koormuse vähendamiseks pakitud ZIP-arhiivi.
ZIP-arhiiv visatakse minema RPM-paketi ehituskataloogi. Järgmisena lähtestab Bashi skript keskkonnamuutujad, otsib ülesehituse versiooni, projekti versiooni, tee ehituskataloogi ja käivitab RPM-ehituse. Kui ehitamine on lõpetatud, avaldatakse pakett aadressil kohalik hoidla, mis asub ehitusagendil.
Järgmiseks ehitusagendilt serverisse RPM-i hoidlas JSON-i päring on saadetud märkides versiooni ja järgu nime. Webhook, millest ma varem rääkisin, laadib just selle paketi Build agendi kohalikust hoidlast alla ja teeb uue koostu installimiseks kättesaadavaks.
Miks see konkreetne paki edastamise skeem RPM-i hoidlasse? Miks ma ei saa kokkupandud pakki kohe hoidlasse saata? Fakt on see, et see on ohutuse tagamise tingimus. See stsenaarium piirab võimalust, et volitamata inimesed laadivad RPM-pakette üles serverisse, mis on juurdepääsetav kõigile Linuxi masinatele.
Andmebaasi versioonide loomine
Konsultatsioonil arendusmeeskonnaga selgus, et kutid olid MS SQL-ile lähemal, kuid enamikes mitte-Windowsi projektides kasutasime juba täie jõuga PostgreSQL-i. Kuna olime juba otsustanud kõigest tasulisest loobuda, hakkasime ka siin kasutama PostgreSQL-i.
Selles osas tahan teile rääkida, kuidas me andmebaasi versiooni tegime ja kuidas valisime Flyway ja Entity Framework Core'i vahel. Vaatame nende plusse ja miinuseid.
Miinused
Flyway läheb ainult ühte suunda, meie me ei saa tagasi pöörata - see on märkimisväärne puudus. Entity Framework Core'iga saab seda võrrelda ka muul viisil – arendaja mugavuse mõttes. Mäletate, et seadsime selle esiplaanile ja peamine kriteerium oli mitte midagi muuta Windowsi arendamiseks.
Meie jaoks Flyway mingit ümbrist oli vajaet poisid ei kirjutaks SQL päringud. Nad on OOP-i mõistes tegutsemisele palju lähemal. Kirjutasime juhised andmebaasiobjektidega töötamiseks, genereerisime SQL-päringu ja käivitasime selle. Andmebaasi uus versioon on valmis, testitud - kõik on korras, kõik töötab.
Entity Framework Core'il on miinus – suure koormuse korral see loob suboptimaalseid SQL päringuid, ja andmebaasi vähenemine võib olla märkimisväärne. Aga kuna meil pole suure koormusega teenust, siis me ei arvuta koormust sadades RPS-ides, võtsime need riskid vastu ja delegeerisime probleemi enda kanda.
Plusse
Olemi raamistiku tuum töötab karbist välja ja seda on lihtne arendadaja Flyway Lihtne integreerida olemasolevasse CI-sse. Aga teeme selle arendajatele mugavaks :)
Roll-up protseduur
Puppet näeb, et tulemas on muudatus paketi versioonis, sealhulgas selles, mis vastutab migratsiooni eest. Esiteks installib see paketi, mis sisaldab migratsiooniskripte ja andmebaasiga seotud funktsioone. Pärast seda taaskäivitatakse andmebaasiga töötav rakendus. Järgmine on ülejäänud komponentide paigaldamine. Pakettide installimise ja rakenduste käivitamise järjekorda kirjeldatakse Puppeti manifestis.
Rakendused kasutavad tundlikke andmeid, nagu märgid, andmebaasi paroolid, kõik see tõmmatakse Puppet masterist konfiguratsiooni, kus need salvestatakse krüpteeritud kujul.
TFS-i probleemid
Pärast seda, kui olime otsustanud ja mõistnud, et meie jaoks kõik tõesti töötab, otsustasin vaadata, mis toimub Win arendusosakonna TFS-i koostudega tervikuna teiste projektide puhul – kas ehitasime/väljastame kiiresti või mitte, ja avastas olulisi probleeme kiirusega.
Ühe põhiprojekti kokkupanekuks kulub 12-15 minutit – see on pikk aeg, nii ei saa elada. Kiire analüüs näitas sisend-väljundis kohutavat tõrget ja see oli massiividel.
Pärast selle komponentide kaupa analüüsimist tuvastasin kolm koldet. Esiteks - "Kaspersky viirusetõrje", mis skannib kõigi Windows Buildi agentide allikaid. Teine - Windows Indekseerija. Seda ei keelatud ja kõik indekseeriti juurutusprotsessi ajal ehitusagentides reaalajas.
Kolmas - Npm installimine. Selgus, et enamiku torujuhtmete puhul kasutasime täpselt seda stsenaariumi. Miks ta halb on? Npm installiprotseduur käivitatakse, kui sõltuvuspuu moodustatakse pakett-lukk.json, kus salvestatakse projekti koostamiseks kasutatavate pakettide versioonid. Negatiivne külg on see, et Npm install tõmbab iga kord Internetist uusimad pakettide versioonid ja see võtab suure projekti puhul palju aega.
Arendajad katsetavad mõnikord kohaliku masinaga, et testida, kuidas konkreetne osa või kogu projekt töötab. Mõnikord selgus, et kohapeal oli kõik lahe, aga panid kokku, rullisid lahti ja miski ei töötanud. Hakkame aru saama, milles probleem on – jah, erinevad sõltuvustega pakettide versioonid.
otsus
- Allikad AV erandites.
- Keela indekseerimine.
- Üleminek npm ci.
Npm ci eelised seisnevad selles, et meie Kogume sõltuvuspuu üks kordja saame võimaluse pakkuda arendajale praegune pakettide nimekiri, millega ta saab kohapeal katsetada nii palju kui tahab. See säästab aega arendajad, kes kirjutavad koodi.
Konfiguratsioon
Nüüd natuke hoidla konfiguratsioonist. Ajalooliselt kasutame Nexus hoidlate haldamiseks, sealhulgas Sisemine REPO. See sisemine repositoorium sisaldab kõiki komponente, mida kasutame sisemistel eesmärkidel, näiteks enda kirjutatud jälgimiseks.
Kasutame ka NuGet, kuna sellel on teiste paketihalduritega võrreldes parem vahemälu.
Tulemus
Pärast ehitusagentide optimeerimist vähenes keskmine ehitusaeg 12 minutilt 7-le.
Kui lugeda kokku kõik masinad, mida oleksime võinud Windowsi jaoks kasutada, kuid selles projektis Linuxile üle läinud, säästsime umbes $10 000. Ja seda ainult litsentside pealt ja rohkemgi, kui sisu arvesse võtta.
Plaanid
Järgmises kvartalis plaanisime töötada koodi edastamise optimeerimisega.
Lülitumine eelkoostatud Dockeri pildile. TFS on lahe asi paljude pistikprogrammidega, mis võimaldavad teil Pipeline'i integreerida, sealhulgas näiteks Dockeri kujutise päästikupõhine kokkupanek. Tahame selle käivitada samale pakett-lukk.json. Kui projekti koostamiseks kasutatud komponentide koostis kuidagi muutub, ehitame uue Dockeri pildi. Seda kasutatakse hiljem konteineri juurutamiseks koos kokkupandud rakendusega. Praegu see nii ei ole, kuid meie ettevõttes aktiivselt arenevas ja juba pikemat aega tootmislahendusi teenindavas Kubernetes plaanime üle minna mikroteenuste arhitektuurile.
Kokkuvõte
Julgustan kõiki Windowsi minema viskama, kuid see ei tulene sellest, et ma ei tea, kuidas seda süüa teha. Põhjus on selles, et enamik avatud lähtekoodiga lahendusi on Linuxi virn. kas sul on kõik korras säästa ressursse. Minu arvates kuulub tulevik avatud lähtekoodiga lahendustele Linuxis koos võimsa kogukonnaga.
Aleksandr Sintšinovi kõneleja profiil .
on konverents arendus-, testimis- ja tööprotsesside integreerimisest professionaalidele professionaalide poolt. Sellepärast see projekt, millest Aleksander rääkis? rakendatud ja töökorras ning esinemispäeval ilmus kaks edukat väljaannet. Peal 27. ja 28. mail on sarnaseid juhtumeid praktikutelt veelgi rohkem. Viimasesse vankrisse saab veel hüpata ja või võta aega pilet. Kohtume Skolkovos!
Allikas: www.habr.com