Ahal genuen moduan garatu genuen DevOps. Zortzi ginen, eta Vasya zen jatorrena. WindowsBat-batean Vasya joan zen, eta niri eman behar izan nion hornidura eskaintzen duen proiektu berri bat abiarazteko ardura. Windows-garapena. Mahai gainean pila osoa bota nuenean Windows-garapenak, orduan konturatu nintzen egoera mingarria dela...
Horrela hasten da istorioa Alexandra Sinchinova on Espezialista nagusiak enpresa utzi zuenean Windows, Alexanderrek orain zer egin behar zuen galdetu zion bere buruari. Joan honera LinuxNoski! Alexanderrek esango dizu nola lortu zuen aurrekari bat ezartzea eta zati bat itzultzea Windows garapenak Linux 100.000 azken erabiltzailerentzako proiektu amaitu baten adibidea erabiliz.
Nola erraz eta ahaleginik gabe entregatu proiektu bat RPMra TFS, Puppet erabiliz, Linux .NET Core? Nola mantentzen duzu proiektuaren datu-basearen bertsioen kontrola garatzaileak Postgres eta Flyway hitzak lehen aldiz entzuten baditu, eta epea biharko eguna bada? Nola integratzen zara Dockerrekin? Nola motibatzen dituzu .NET garatzaileak alde batera uzteko? Windows eta irabiakiak Txotxongiloarentzat eta LinuxNola konpondu gatazka ideologikoak zerbitzatzen ari bazara Windows Ez duzu energiarik, gogorik edo baliabiderik ekoizpenean hasteko? Alexanderren aurkezpenak hau jorratzen du, baita Web Hedapena, probak, CI, TFS praktikak proiektuetan eta, noski, konponbide akastunak eta funtzionatzen duten irtenbideak ere.
Beraz, Vasya joan egin zen, nirea zen zeregina, eta garatzaileak sardexkekin irrikaz itxaroten ari ziren. Azkenean Vasya ez zela itzuliko konturatu nintzenean, lanean hasi nintzen. Lehenik eta behin, gure flotaren Win VM ehunekoa ebaluatu nuen. Probabilitateak haren aurka zeuden. Windows.
DevOps garatzen ari garenez, konturatu nintzen aplikazio berriak zabaltzeko ikuspegian zerbait aldatu behar genuela. Irtenbide bakarra zegoen: dena jatorrizko bertsiora eramatea, ahal bazen. LinuxGooglek lagundu zidan - garai hartan .Net jadanik eramana zegoen Linux, eta konturatu nintzen hau zela konponbidea!
Zergatik .NET core-rekin batera Linux?
Hainbat arrazoi zeuden horretarako. Ordaindu eta ez ordaintzearen artean aukera izanda, jende gehienak azken aukera aukeratuko luke, nik bezala. MSDBrako lizentzia batek 1.000 dolar inguru balio du, eta makina birtual flota bat mantentzeak Windows ehunka dolarretakoa da. Enpresa handi batentzat, gastu handia da hau. Beraz, aurrezki - lehen arrazoia. Ez garrantzitsuena, esanguratsuetako bat baizik.
Makina birtualak Windows beren anaiek baino baliabide gehiago hartzen dituzte Linux - astunak diraEnpresa handiaren tamaina kontuan hartuta, aukeratu genuen Linux.
Sistema lehendik dagoen CIn integratzen daDevOps aurrerakoitzat hartzen dugu geure burua, Bamboo, Jenkins eta GitLab CI erabiltzen ditugu, beraz, gure lan gehiena hemen egiten dugu: Linux.
Azken arrazoia da akonpainamendu erosoa. "Mantentzaileentzako" sarrera-hesia jaitsi behar genuen, hau da, alde teknikoa ulertzen dutenak, funtzionamendu-denbora bermatzen dutenak eta zerbitzuak bigarren lerrotik mantentzen dituztenak. Pila ezagutzen zuten jada. Linux, beraz, askoz errazagoa da produktu berri bat ulertzea, laguntzea eta mantentzea softwarearen antzeko funtzionalitatea ulertzeko baliabide gehigarriak gastatzea baino Windows plataforma.
Baldintzak
Lehenik eta behin - Garatzaileentzako irtenbide berriaren erosotasunaEz zeuden guztiak aldaketarako prest, batez ere hitza esan ondoren LinuxGaratzaileek beren Visual Studio gogokoena nahi dute, TFS, eraikuntza-proba automatizatuekin eta smoothieekin. Nola entregatzen duten ekoizpenera ez da garrantzitsua haientzat. Horregatik erabaki dugu ohiko prozesua ez aldatzea eta uztea... Windows- garapenak aldatu gabe jarraitzen du.
Proiektu berria behar da lehendik dagoen CIn integratzea. Errailak hor zeuden jada eta lan guztiak konfigurazio kudeaketa sistemaren parametroak, onartutako entrega estandarrak eta monitorizazio sistemak kontuan hartuz egin behar ziren.
Laguntza eta funtzionamendu erraztasuna, dibisio ezberdinetako eta laguntza saileko parte-hartzaile berri guztien gutxieneko sarrera-atalasearen baldintza gisa.
Epea - atzo.
Irabazi Garapen Taldea
Zerekin ari zen lanean taldea orduan? Windows?
Orain ziur esan dezaket hori Identitate Zerbitzaria 4 ADFSrako doako alternatiba polita da antzeko gaitasunak dituena, edo zer Entitate-esparruaren muina - Garatzaileentzako paradisua, non ez duzun SQL script-ak idazten kezkatu behar, baina datu-baseko kontsultak OOP terminoetan deskribatzen dituzun. Baina gero, ekintza-planaren eztabaidan, pila hau sumeriar cuneiformea balitz bezala begiratu nuen, PostgreSQL eta Git bakarrik ezagutuz.
Garai hartan aktiboki erabiltzen genuen Txotxongilo konfigurazioa kudeatzeko sistema gisa. Gure proiektu gehienetan erabili dugu GitLab CI, Elastikoak, karga handiko zerbitzu orekatuak erabiliz HAProxy dena kontrolatu zuen Zabbix, lotailuak Grafana и Prometeo, Jaeger, eta hau guztia burdina pusketan biraka ari zen HP c ESXi on VMware. Denek dakite - generoaren klasiko bat.
Begiratu eta saia gaitezen ulertzen zer gertatu zen esku-hartze hauek guztiak hasi aurretik.
Zer gertatu zen
TFS sistema nahiko indartsua da, garatzailearengandik azken produkzio-makinara kodea helarazten ez ezik, hainbat zerbitzurekin oso malgua integratzeko multzo bat ere badu, CI plataforma anitzeko mailan eskaintzeko.
Aurretik, leiho guztiak ziren. TFS-k hainbat Build agente erabiltzen zituen, hainbat proiektu eraikitzen zituztenak. Agente bakoitzak 3-4 langile zituen zereginak paralelizatzeko eta prozesua optimizatzeko. Ondoren, argitalpen planen arabera, TFS-k Build berria entregatu zuen. Windows-aplikazio zerbitzaria.
Zer lortu nahi genuen?
TFS erabiltzen dugu entrega eta garapenerako, eta aplikazioa abiarazten dugu Linux Aplikazio zerbitzaria, eta magia pixka bat dago bien artean. Hau Kaxa magikoa eta hor dago lanaren gatza aurretik. Desmuntatu aurretik, urrats bat albo batera emango dut eta aplikazioari buruz hitz batzuk esango ditut.
Proiektu
Aplikazioak aurrez ordaindutako txartelak kudeatzeko funtzionaltasuna eskaintzen du.
Bezero
Bi erabiltzaile mota zeuden. Lehenengoa sarbidea lortu du SSL SHA-2 ziurtagiri bat erabiliz saioa hasita. U bigarrena saio-hasiera eta pasahitza erabiliz sarbidea zegoen.
HAProxy
Ondoren, bezeroaren eskaera HAProxy-ra joan zen, eta honek arazo hauek konpondu zituen:
- lehen mailako baimena;
- SSL amaiera;
- HTTP eskaerak sintonizatzea;
- difusio eskaerak.
Bezeroaren ziurtagiria kate osoan egiaztatu zen. Gu - Ficha eta hori ordaindu dezakegu, guk geuk igortzen baititugu zerbitzu-bezeroei ziurtagiriak.
Erreparatu hirugarren puntuari, beranduago itzuliko gara.
backend
Atzeko aldea egitea aurreikusita zegoen LinuxAtzeko planoak datu-basearekin elkarreragiten du, beharrezko pribilegioen zerrenda kargatzen du eta, ondoren, baimendutako erabiltzailearen pribilegioen arabera, finantza-dokumentuak sinatzeko eta exekutatzeko bidaltzeko edo txosten bat sortzeko sarbidea ematen du.
Aurreztea HAProxy-rekin
Bezero bakoitzak nabigatzen zituen bi testuinguruez gain, identitate-testuinguru bat ere bazegoen. Identitate Zerbitzaria 4 saioa hasteko aukera ematen dizu, hau analogo doakoa eta indartsua da ADFS - Active Directory federazio zerbitzuak.
Nortasun eskaera hainbat urratsetan prozesatu da. Lehen urratsa - bezeroa backend sartu zen, zerbitzari honekin komunikatu eta bezeroarentzako token baten presentzia egiaztatu zuen. Aurkitu ezean, eskaera sortu zen testuingurura itzultzen zen, baina birzuzenketa batekin, eta birbideraketarekin identitatera joan zen.
Bigarren urratsa - eskaera jaso zen IdentityServer-eko baimen-orrira, non erregistratu zen bezeroa, eta IdentityServer datu-basean itxaroten zen token hori agertu zen.
Hirugarren urratsa - bezeroa berriro bideratu zen sortu zen testuingurura.
IdentityServer4 ezaugarri bat du: HTTP bidez itzultzeko eskaeraren erantzuna itzultzen du. Zerbitzaria konfiguratzeko zenbat borroka egin genuen, dokumentazioarekin zenbat argitu ginen, HTTPS bidez zetorren URL batekin hasierako bezero eskaera jasotzen genuen bakoitzean, eta IdentityServer-ek testuinguru bera itzuli zuen, baina HTTPrekin. Harrituta geratu ginen! Eta hori guztia identitate-testuinguruaren bidez transferitu genuen HAProxyra, eta goiburuetan HTTP protokoloa HTTPSra aldatu behar izan genuen.
Zein da hobekuntza eta non gorde duzu?
Dirua aurreztu dugu erabiltzaile talde bat, baliabideak baimentzeko doako irtenbide bat erabiliz, ez baitugu IdentityServer4 nodo bereizi gisa jarri segmentu bereizi batean, baizik eta backendarekin batera erabili baitugu aplikazioaren backend-a exekutatzen den zerbitzari berean. .
Nola funtzionatu behar du
Beraz, agindu nuen bezala – Kutxa Magikoa. Badakigu dagoeneko norabide horretan goazela. LinuxFormulatu ditzagun konpondu beharreko zeregin zehatzak.
Txotxongiloen manifestuak. Zerbitzuaren eta aplikazioen konfigurazioa emateko eta kudeatzeko, errezeta politak idatzi behar izan ziren. Arkatza-erroilu batek elokuenteki erakusten du zein azkar eta eraginkortasunez egin zen.
Entregatzeko modua. Estandarra RPM da. Denek ulertzen dute hori Linux Ez zegoen beste modurik, baina proiektua bera, eraiki ondoren, DLL fitxategi exekutagarrien bilduma bat zen. 150 inguru ziren, eta horrek proiektua nahiko astuna bihurtzen zuen. Irtenbide iraunkor bakarra binario hauek RPM batean paketatzea eta aplikazioa handik zabaltzea zen.
Bertsioa. Oso maiz kaleratuko genituen, eta paketearen izena nola osatu erabaki behar genuen. Hau TFS-rekin integrazio mailaren kontua zen. Eraikuntza-agente bat genuen LinuxTFS-k Build agente bateko langile bati zeregin bat bidaltzen dionean, langilearen ingurunean gordeta dauden aldagai multzo bat ere pasatzen dio. Ingurune aldagai hauek Build izena, bertsio izena eta beste aldagai batzuk dituzte. Xehetasun gehiago "RPM pakete bat eraikitzea" atalean daude eskuragarri.
TFS konfiguratzea Dena Pipeline-a ezartzera mugatu zen. Lehen, gainean eraikitzen genuen Windows-eragile guztiak Windows-proiektuak, eta orain badirudi Linux-agent — eraikuntza-taldean sartu behar den eraikuntza-agente bat, zenbait artefakturekin aberastua, eraikuntza-agente honetan zer nolako proiektuak eraikiko diren zehaztua eta Hodia modu batean aldatua.
Identitate Zerbitzaria. ADFS ez da gure bidea, Kode Irekiaren alde goaz.
Goazen osagaietatik.
Kaxa magikoa
Lau zatiz osatuta dago.
Linux Eraikitzaile agentea. Linux, horretarako konpilatzen ari garelako —zentzua du. Zati hau hiru urratsetan osatu da.
- Langileak konfiguratu eta ez bakarrik, proiektuan banatutako lana espero baitzen.
- Instalatu .NET Core 1.x. Zergatik 1.x 2.0 biltegi estandarrean dagoeneko eskuragarri dagoenean? Garatzen hasi ginenean, bertsio egonkorra 1.09 zen, eta proiektua horretan oinarrituta egitea erabaki zen.
- Git 2.x.
RPM-biltegia. RPM paketeak nonbait gorde behar ziren. Denek eskura zezaketen korporazioko RPM biltegi bera erabili behar genuen. Linux ostalariak. Hori egin genuen. Biltegi zerbitzaria konfiguratuta dago web kako beharrezko RPM paketea deskargatu zuena zehaztutako kokapenetik. Paketearen bertsioaren berri eman zion webhook-ari Build agenteak.
GitLab. Kontuan izan: GitLab ez dute garatzaileek erabiltzen hemen, baizik eta eragiketa sailak aplikazioen bertsioak, paketeen bertsioak eta guztien egoera kontrolatzeko. Linux-makinak eta errezeta gordetzen du - Puppet manifestu guztiak.
Txotxongilo — Arazo eztabaidagarri guztiak konpontzen ditu eta Gitlabetik nahi dugun konfigurazioa ematen du.
Murgiltzen hasten gara. Nola funtzionatzen du DLL bidalketak RPMra?
Bidalketa DDL RPM-ra
Demagun .NET garapeneko rock izarra dugula. Visual Studio erabiltzen du eta kaleratzeko adar bat sortzen du. Horren ostean, Git-era kargatzen du, eta Git hemen TFS entitate bat da, hau da, garatzaileak lan egiten duen aplikazioen biltegia da.
Ondoren, TFS-k ikusten du konpromiso berri bat iritsi dela. Zein aplikazio? TFS ezarpenek eraikuntza-agente bakoitzak zein baliabide dituen adierazten dute. Kasu honetan, .NET Core proiektu bat eraikitzen ari garela ikusten du eta hautatzen du Linux Eraiki agentea multzotik.
Eraikitzeko agenteak iturriak jasotzen ditu eta beharrezkoak deskargatzen ditu mendekotasun .NET biltegitik, npm, etab. eta aplikazioa bera eta ondorengo paketea eraiki ondoren, RPM paketea bidaltzen du RPM biltegira.
Bestalde, honako hau gertatzen da. Eragiketa saileko ingeniariak zuzenean parte hartzen du proiektuaren hedapenean: paketeen bertsioak aldatzen ditu Hiera aplikazioaren errezeta gordetzen den biltegian, eta ondoren Puppet abiarazten da Yum, pakete berria biltegitik lortzen du eta aplikazioaren bertsio berria erabiltzeko prest dago.
Hitzez dena sinplea da, baina zer gertatzen da Build agentearen barruan?
DLL RPM paketea
TFS-tik proiektu-iturriak eta eraikitze-zereginak jaso ditu. Eraikitzeko agentea proiektua bera iturrietatik eraikitzen hasten da. Muntatutako proiektua multzo gisa eskuragarri dago DLL fitxategiak, fitxategi-sistemaren karga murrizteko zip artxibo batean biltzen direnak.
ZIP artxiboa bota egiten da RPM paketeen eraikitze direktoriora. Ondoren, Bash script-ak ingurune-aldagaiak hasieratzen ditu, Eraikitze bertsioa, proiektuaren bertsioa, eraikitze direktoriorako bidea aurkitzen ditu eta RPM-build exekutatzen du. Eraikuntza amaitutakoan, paketea hemen argitaratzen da tokiko biltegia, Eraiki agentean dagoena.
Ondoren, Eraiki agentetik RPM biltegiko zerbitzarira JSON eskaera bidali da bertsioaren eta eraikitzearen izena adieraziz. Webhook, lehenago hitz egin dudana, pakete hau bera deskargatzen du tokiko biltegitik Build agentean eta muntaia berria instalatzeko eskuragarri jartzen du.
Zergatik RPM biltegirako banaketa-eskema berezi hau? Zergatik ezin da eraikitako paketea berehala biltegira bidali? Segurtasun-baldintza bat da hau. Egoera honek baimenik gabeko pertsonek RPM paketeak publikoki eskuragarri dagoen zerbitzari batera igotzeko aukera mugatzen du. Linux-autoak.
Datu-basearen bertsioa
Garapen-kontsultan, mutilak MS SQL-ra hurbilago daudela ikusi zen, baina kasu gehienetan ez...Windows PostgreSQL asko erabiltzen ari ginen hainbat proiektutarako. Ordainpeko softwarea uztea erabaki genuenez, hemen ere PostgreSQL erabiltzen hasi ginen.
Zati honetan datu-basea nola bertsionatu genuen eta Flyway eta Entity Framework Core artean nola aukeratu genuen esan nahi dizuet. Ikus ditzagun haien alde onak eta txarrak.
Cons
Flyway bide bakarrean doa, gu ezin dugu atzera egin — hau eragozpen nabarmena da. Entity Framework Core-rekin beste modu batzuetan konpara daiteke — garatzaileen erosotasunaren ikuspegitik. Gogoratzen duzu hau lehentasun nagusitzat hartu genuela, eta irizpide nagusia ezer ez aldatzea izan zela Windows-garapenak.
Flyway guregatik bilgarri moduko bat behar zenmutilek idazten ez dezaten SQL kontsultak. OOP terminoetan jarduteko askoz gertuago daude. Datu-baseko objektuekin lan egiteko argibideak idatzi ditugu, SQL kontsulta bat sortu eta exekutatu dugu. Datu-basearen bertsio berria prest dago, probatua - dena ondo dago, dena funtzionatzen du.
Entity Framework Core-k ken bat du - karga astunetan SQL kontsulta ezin hobeak eraikitzen ditu, eta datu-basean behera egitea esanguratsua izan daiteke. Baina karga handiko zerbitzurik ez dugunez, ez dugu karga ehunka RPStan kalkulatzen, arrisku horiek onartu eta arazoa etorkizunean eskuordetu genuen.
Pros
Entitate-esparruaren muina kaxatik kanpo funtzionatzen du eta garatzeko erraza da, eta Flyway Erraz integratzen da lehendik dagoen CI-n. Baina garatzaileentzat erosoa egiten dugu :)
Biltzeko prozedura
Puppet-ek paketeen bertsioan aldaketa bat datorrela ikusten du, migrazioaz arduratzen dena barne. Lehenik eta behin, migrazio-scriptak eta datu-baseari lotutako funtzionalitateak dituen pakete bat instalatzen du. Horren ostean, datu-basearekin lan egiten duen aplikazioa berrabiaraziko da. Ondoren, gainerako osagaien instalazioa dator. Paketeak instalatzeko eta aplikazioak abiarazteko ordena Puppet manifestuan deskribatzen da.
Aplikazioek datu sentikorrak erabiltzen dituzte, hala nola, tokenak, datu-baseen pasahitzak, hau guztia Puppet master-etik konfiguraziora sartzen da, non forma enkriptatuan gordetzen dira.
TFS arazoak
Guztiak benetan funtzionatzen zuela guretzat erabaki eta konturatu ondoren, TFS-ko muntaketekin osotasunean zer gertatzen ari zen aztertzea erabaki nuen Win garapen-sailerako beste proiektu batzuetan - azkar eraikitzen/argitzen ari ginen ala ez, eta abiadurarekin arazo handiak aurkitu zituen.
Proiektu nagusietako batek 12-15 minutu behar ditu muntatzeko; hori denbora luzea da, ezin zara horrela bizi. Azterketa azkar batek I/O-n beherakada izugarria erakutsi zuen, eta hau arrayetan zegoen.
Osagaiz osagai aztertu ondoren, hiru foku identifikatu nituen. Lehenengoa - "Kaspersky antibirusa", guztion esku dagoena Windows Eraikuntza-agenteek iturburu-kodea eskaneatzen dute. Bigarrena da Windows Indizea. Ez zen desgaitu, eta dena denbora errealean indexatu zen Build agenteetan inplementazio prozesuan.
Hirugarrena - Npm instalatzea. Pipeline gehienetan agertoki zehatz hau erabiltzen genuela. Zergatik da txarra? Npm instalazio-prozedura exekutatzen da mendekotasun-zuhaitza osatzen denean package-lock.json, non proiektua eraikitzeko erabiliko diren paketeen bertsioak erregistratzen diren. Alde txarra da Npm install-ek Internetetik paketeen azken bertsioak ateratzen dituela aldi bakoitzean, eta honek denbora asko behar du proiektu handi baten kasuan.
Garatzaileek batzuetan tokiko makina batean esperimentatzen dute zati jakin batek edo proiektu osoak nola funtzionatzen duen probatzeko. Batzuetan, lokalean dena polita zegoela ikusten zen, baina muntatu, zabaldu eta ezer ez zuen funtzionatu. Arazoa zein den asmatzen hasten gara - bai, mendekotasunak dituzten paketeen bertsio desberdinak.
Erabaki
- AV salbuespenetako iturriak.
- Desgaitu indexazioa.
- Joan npm ci.
npm ci-ren abantailak guk ditugu Mendekotasun zuhaitza behin biltzen dugu, eta garatzaileari emateko aukera dugu egungo paketeen zerrenda, eta horrekin lokalean nahi adina esperimentatu dezake. Hau denbora aurrezten du kodea idazten duten garatzaileak.
konfigurazioa
Orain biltegiaren konfigurazioari buruz apur bat. Historikoki erabiltzen dugu Nexus biltegiak kudeatzeko, besteak beste Barneko REPO. Barne biltegi honek barne helburuetarako erabiltzen ditugun osagai guztiak ditu, adibidez, norberak idatzitako monitorizazioa.
Guk ere erabiltzen dugu NuGet, beste pakete-kudeatzaile batzuekin alderatuta, cachea hobea baitu.
Emaitza
Eraikitzeko agenteak optimizatu ondoren, batez besteko eraikuntza-denbora 12 minututik 7ra murriztu zen.
erabil ditzakegun makina guztiak zenbatzen baditugu Windows, baina itzulita Linux Proiektu honetan, 10.000 dolar inguru aurreztu ditugu. Eta hori lizentzietan bakarrik da; edukia kontuan hartzen badugu, are gehiago da.
Planak
Hurrengo hiruhilekoan, kodearen entrega optimizatzeko lan egiteko asmoa genuen.
Aurrez eraikitako Docker irudi batera aldatzen. TFS gauza polita da Pipeline-n integratzeko aukera ematen duten plugin askorekin, abiarazleetan oinarritutako muntaketa barne, esate baterako, Docker-en irudia. Aktibatzaile hau berarentzat egin nahi dugu package-lock.json. Proiektua eraikitzeko erabilitako osagaien konposizioa nolabait aldatzen bada, Docker irudi berria eraikiko dugu. Geroago, muntatutako aplikazioarekin edukiontzia zabaltzeko erabiltzen da. Orain ez da horrela, baina Kubernetesen mikrozerbitzuen arkitektura batera aldatzeko asmoa dugu, gure enpresan aktiboki garatzen ari dena eta denbora luzez produkzio irtenbideak zerbitzatzen ari dena.
Laburpena
botatzera animatzen ditut guztiak Windows, baina ez da nola prestatu ez dakidalako. Arrazoia da kode irekiko irtenbide gehienak direla Linux-pila. ondo zaude baliabideetan aurreztuNire ustez, etorkizuna kode irekiko irtenbideetan dago. Linux komunitate indartsu batekin.
Alexander Sinchinoven hizlariaren profila .
profesionalen garapen, proba eta funtzionamendu prozesuen integrazioari buruzko jardunaldia da. Horregatik Alexanderk hitz egin zuen proiektua? ezarri eta lanean, eta emanaldiaren egunean bi kaleratze arrakastatsu izan ziren. On Maiatzaren 27an eta 28an praktikatzaileen antzeko kasu gehiago izango dira. Oraindik azken bagoira salto egin dezakezu eta edo hartu zure denbora txartela. Ezagutu gaitzazu Skolkovon!
Iturria: www.habr.com
