DevOps ahal genuen moduan garatu dugu. 8 ginen, eta Vasya Windows-en politena zen. Bat-batean Vasya joan zen, eta Windows garapenak emandako proiektu berri bat abiarazteko zeregina izan nuen. Windows garapen pila osoa mahai gainean bota nuenean, egoera mina zela konturatu nintzen...
Horrela hasten da istorioa Alexandra Sinchinova on . Windows-eko espezialista nagusiak konpainia utzi zuenean, Alexanderk galdetu zuen zer egin orain. Aldatu Linuxera, noski! Alexanderk kontatuko dizu nola lortu zuen aurrekari bat sortzea eta Windows garapenaren zati bat Linuxera transferitzea, 100 azken erabiltzaileentzako amaitutako proiektu baten adibidea erabiliz.
Nola erraz eta esfortzurik gabe entregatu proiektu bat RPMra TFS, Puppet, Linux .NET core erabiliz? Nola lagundu proiektuaren datu-base baten bertsioak garatzeko taldeak Postgres eta Flyway hitzak lehen aldiz entzuten baditu eta epea biharamunean amaitzen bada? Nola integratu Docker-ekin? Nola motibatu .NET garatzaileak Windows eta irabiatuak alde batera uzteko Puppet eta Linuxen alde? Nola konpondu gatazka ideologikoak Windows ekoizpenean mantentzeko indarrik, ez gogorik, ez baliabiderik ez badago? Horri buruz, baita Web Deploy, testing, CI, lehendik dauden proiektuetan TFS erabiltzeko praktikei buruz eta, jakina, hautsitako makuluei eta laneko irtenbideei buruz, Alexanderren txostenaren transkripzioan.
Beraz, Vasyak utzi zuen, nire esku dago zeregina, garatzaileak pazientziarik gabe itxaroten ari dira sardeekin. Azkenean Vasya ezin zela itzuli konturatu nintzenean, negozioari ekin nion. Hasteko, Win VM-en ehunekoa baloratu nuen gure flotan. Puntuazioa ez zen Windowsen aldekoa izan.
DevOps aktiboki garatzen ari garenez, konturatu nintzen aplikazio berri bat emateko ikuspegian zerbait aldatu behar zela. Irtenbide bakarra zegoen: ahal izanez gero, transferitu dena Linuxera. Google-k lagundu zidan - garai hartan .Net jada Linuxera eraman zuten, eta konturatu nintzen hori zela irtenbidea!
Zergatik .NET core Linux-ekin batera?
Hainbat arrazoi zeuden horretarako. "Ordaindu dirua" eta "ez ordaindu" artean, gehiengoak bigarrena aukeratuko du - nik bezala. MSDBrako lizentziak 1 dolar inguru balio du; Windows makina birtualen flota mantentzeak ehunka dolar balio du. Enpresa handi batentzat hau gastu handia da. Horregatik aurrezki - lehen arrazoia. Ez garrantzitsuena, esanguratsuetako bat baizik.
Windows makina birtualek beren Linux anaiek baino baliabide gehiago hartzen dituzte - astunak dira. Enpresa handiaren tamaina ikusita, Linux aukeratu dugu.
Sistema lehendik dagoen CIn integratzen da. DevOps progresibotzat hartzen dugu gure burua, Bamboo, Jenkins eta GitLab CI erabiltzen ditugu, beraz, gure lan gehiena Linux-en exekutatzen da.
Azken arrazoia da akonpainamendu erosoa. "Eskortetarako" sartzeko langa jaitsi behar genuen: atal teknikoa ulertzen duten mutilak, etenik gabeko zerbitzua bermatzen dutenak eta bigarren lerrotik zerbitzuak mantentzen dituztenak. Dagoeneko ezagutzen zuten Linux pila, beraz, askoz errazagoa da produktu berri bat ulertzea, eustea eta mantentzea baliabide gehigarriak gastatzea Windows plataformarako softwarearen funtzionaltasun bera ulertzeko.
Baldintzak
Lehenik eta behin - Garatzaileentzako irtenbide berriaren erosotasuna. Guztiak ez zeuden aldaketarako prest, batez ere Linux hitza esan ondoren. Garatzaileek euren gogoko Visual Studio, TFS nahi dute muntaketa eta irabiatuetarako autotestekin. Produkzioaren entrega nola gertatzen den ez da garrantzitsua haientzat. Hori dela eta, ohiko prozesua ez aldatzea eta dena aldatu gabe uztea Windows garapenerako erabaki dugu.
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
Zertan ari zen lanean Windows taldea orduan?
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, hauek leiho sendoak ziren. TFS-k hainbat Build agente erabili zituen, proiektu asko muntatzeko erabiltzen zirenak. Agente bakoitzak 3-4 langile ditu zereginak paralelizatzeko eta prozesua optimizatzeko. Ondoren, kaleratze planen arabera, TFS-k labean berria entregatu zuen Build Windows aplikazioen zerbitzarira.
Zer lortu nahi genuen?
TFS erabiltzen dugu entrega eta garapenerako, eta aplikazioa Linux Aplikazio zerbitzari batean exekutatzen dugu, eta haien artean nolabaiteko magia dago. 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
Linux-en backend-a egiteko asmoa zuten. Backend-ak datu-basearekin elkarreraginean jarduten du, beharrezko pribilegioen zerrenda kargatzen du eta, ondoren, baimendutako erabiltzaileak zein pribilegioen arabera, finantza-dokumentuak sinatzeko eta exekutatzeko bidaltzeko sarbidea ematen du, edo nolabaiteko txostena sortzeko.
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 - Magic Box. Dagoeneko ulertzen dugu Linux aldera joatea bermatuta dugula. Formulatu ditzagun irtenbideak behar zituzten 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 Linuxen ezin dela hori gabe egin, baina proiektua bera, muntatu ondoren, DLL fitxategi exekutagarrien multzoa zen. 150 inguru ziren, proiektua nahiko zaila zen. Irtenbide harmoniatsu bakarra bitar hau RPM-n paketea eta aplikazioa bertatik zabaltzea da.
Bertsioa. Askotan askatu behar izan genuen, eta paketearen izena nola osatu erabaki behar genuen. Hau TFS-rekin integrazio-mailaren galdera da. Eraikitze-agente bat genuen Linux-en. TFS-k zeregin bat kudeatzaile bati -langileari- bidaltzen dionean Eraikitzeko agenteari, kudeatzaile-prozesuaren ingurunean amaitzen diren aldagai mordoa ere pasatzen dizkio. Inguruko aldagai hauek Eraikitze-izena, bertsio-izena eta beste aldagai batzuk dituzte. Irakurri honi buruz gehiago "RPM paketea eraikitzen" atalean.
TFS konfiguratzea Pipeline konfiguratzera iritsi zen. Aurretik, Windows-eko proiektu guztiak Windows-eko agenteetan bildu genituen, baina orain Linux-eko agente bat agertzen da - Eraikitze-agente bat, eraikitze-taldean sartu behar dena, artefaktu batzuekin aberastua eta Build-agente honetan zer proiektu mota eraikiko diren esan. , eta nolabait aldatu Pipeline.
Identitate Zerbitzaria. ADFS ez da gure bidea, Kode Irekiaren alde goaz.
Goazen osagaietatik.
Kaxa magikoa
Lau zatiz osatuta dago.
Linux Eraikitzeko agentea. Linux, horretarako eraikitzen dugulako - logikoa da. Zati hau hiru urratsetan egin zen.
- 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. Linux ostalari guztientzat eskuragarri dagoen RPM biltegi korporatibo bera erabiliko genuela suposatu zen. Horixe egin zuten. Biltegiko zerbitzaria konfiguratuta dago web kako beharrezko RPM paketea deskargatu zuena zehaztutako kokapenetik. Paketearen bertsioaren berri eman zion webhook-ari Build agenteak.
GitLab. Kontuz! GitLab hemen garatzaileek ez dute erabiltzen, operazio sailak baizik eta aplikazioen bertsioak, paketeen bertsioak kontrolatzeko, Linux makina guztien egoera kontrolatzeko 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.
Horren ostean, TFS-k konpromiso berri bat iritsi dela ikusten du. Zein aplikazio? TFS ezarpenetan Build agente jakin batek zer baliabide dituen adierazten duen etiketa bat dago. Kasu honetan, .NET Core proiektu bat eraikitzen ari garela ikusten du eta igerilekutik Linux Build agente bat hautatzen du.
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 pakete bidalketa eskema zehatz hau RPM biltegira? Zergatik ezin dut berehala bildutako paketea biltegira bidali? Kontua da segurtasuna bermatzeko baldintza bat dela. Eszenatoki honek baimenik gabeko pertsonek RPM paketeak kargatzeko aukera mugatzen du Linux makina guztientzat eskuragarri dagoen zerbitzari batera.
Datu-basearen bertsioa
Garapen taldearekin egindako kontsulta batean, mutilak MS SQL-tik gertuago zeudela, baina Windows ez ziren proiektu gehienetan jadanik PostgreSQL erabiltzen ari ginen indar guztiekin. Ordaindutako guztia bertan behera 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 desabantaila nabarmena da. Entity Framework Core-rekin konparatu dezakezu beste modu batzuetan, garatzaileen erosotasunari dagokionez. Gogoratzen duzue hori lehen postuan jartzen genuela, eta irizpide nagusia Windows garapenerako ezer ez aldatzea zela.
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", Windows Build agente guztien iturriak aztertzen dituena. Bigarrena - 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.
Windows-erako erabil genitzakeen makina guztiak zenbatzen baditugu, baina proiektu honetan Linuxera aldatuz gero, 10 dolar inguru aurreztuko ditugu.Eta hori lizentzietan baino ez da, eta gehiago edukia kontuan hartzen badugu.
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
Guztiak animatzen ditut Windows botatzera, baina ez da nola prestatu ez dakidalako. Arrazoia da Opensource irtenbide gehienak direla Linux pila. ondo zaude baliabideetan aurreztu. Nire ustez, etorkizuna komunitate indartsua duten Linux-en Open Source soluzioei dagokie.
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