Kehitimme DevOpsia parhaamme mukaan. Meitä oli 8, ja Vasya oli siistein Windowsissa. Yhtäkkiä Vasya lähti, ja minun tehtäväni oli käynnistää uusi projekti, jonka toimitti Windows-kehitys. Kun kaadin koko Windows-kehityspinon pöydälle, tajusin tilanteen olevan kipeä...
Näin tarina alkaa Alexandra Sinchinova päälle . Kun johtava Windows-asiantuntija lähti yrityksestä, Alexander pohti, mitä tehdä nyt. Vaihda tietysti Linuxiin! Alexander kertoo, kuinka hän onnistui luomaan ennakkotapauksen ja siirtämään osan Windows-kehityksestä Linuxiin käyttämällä esimerkkiä valmiista projektista 100 000 loppukäyttäjälle.
Kuinka toimittaa projekti helposti ja vaivattomasti RPM:lle TFS:n, Puppetin tai Linuxin .NET-ytimen avulla? Kuinka tukea projektitietokannan versiointia, jos kehitystiimi kuulee sanat Postgres ja Flyway ensimmäistä kertaa ja määräaika on ylihuomenna? Kuinka integroida Dockeriin? Kuinka motivoida .NET-kehittäjät luopumaan Windowsista ja smoothieista Puppetin ja Linuxin hyväksi? Miten ratkaista ideologiset ristiriidat, jos ei ole voimaa, halua tai resursseja ylläpitää Windowsia tuotannossa? Tästä, samoin kuin Web Deploysta, testauksesta, CI:stä, TFS:n käyttökäytännöistä olemassa olevissa projekteissa ja tietysti rikkinäisistä kainalosauvoista ja toimivista ratkaisuista Alexanderin raportin transkriptiossa.
Joten, Vasya lähti, tehtävä on minulla, kehittäjät odottavat kärsimättömästi pisteillä. Kun vihdoin tajusin, että Vasyaa ei voitu palauttaa, ryhdyin asioihin. Aluksi arvioin Win VM:ien prosenttiosuuden laivastomme. Pisteet eivät olleet Windowsin hyväksi.
Koska kehitämme aktiivisesti DevOpsia, ymmärsin, että uuden sovelluksen toimittamisessa on tehtävä jotain muutosta. Oli vain yksi ratkaisu - jos mahdollista, siirrä kaikki Linuxiin. Google auttoi minua - tuolloin .Net oli jo siirretty Linuxiin, ja tajusin, että tämä oli ratkaisu!
Miksi .NET-ydin Linuxin kanssa?
Tähän oli useita syitä. Väliltä "maksa rahaa" ja "ei maksa" enemmistö valitsee toisen - kuten minä. MSDB:n lisenssi maksaa noin 1 000 dollaria; Windows-virtuaalikoneiden ylläpitäminen maksaa satoja dollareita. Suurelle yritykselle tämä on suuri kulu. Siksi säästöt - ensimmäinen syy. Ei tärkein, mutta yksi merkittävimmistä.
Windows-virtuaalikoneet vievät enemmän resursseja kuin Linux-veljensä - ne ovat raskaita. Ottaen huomioon suuren yrityksen laajuuden, valitsimme Linuxin.
Järjestelmä on yksinkertaisesti integroitu olemassa olevaan CI:hen. Pidämme itseämme progressiivisina DevOpsina, käytämme Bamboota, Jenkinsiä ja GitLab CI:tä, joten suurin osa työstämme toimii Linuxilla.
Viimeinen syy on kätevä seura. Meidän piti alentaa "saattajien" pääsyn estettä – tyyppejä, jotka ymmärtävät teknisen osan, varmistavat keskeytymättömän palvelun ja ylläpitävät palveluita toiselta linjalta. He tunsivat Linux-pinon jo entuudestaan, joten heidän on paljon helpompi ymmärtää, tukea ja ylläpitää uutta tuotetta kuin käyttää lisäresursseja ymmärtääkseen saman Windows-alustan ohjelmiston toiminnallisuuden.
Vaatimukset
Ennen kaikkea - uuden ratkaisun mukavuus kehittäjille. Kaikki eivät olleet valmiita muutokseen, varsinkaan sen jälkeen, kun sana Linux oli puhuttu. Kehittäjät haluavat suosikkinsa Visual Studion, TFS:n automaattisilla testeillä kokoonpanoille ja smoothieille. Heille ei ole tärkeää, miten tuotanto tapahtuu. Siksi päätimme olla muuttamatta tavallista prosessia ja jättää kaiken ennalleen Windows-kehitystä varten.
Uusi projekti tarvitaan integroida olemassa olevaan CI:ään. Kiskot olivat jo valmiina ja kaikki työ piti tehdä ottaen huomioon konfiguraationhallintajärjestelmän parametrit, hyväksytyt toimitusstandardit ja valvontajärjestelmät.
Helppokäyttöinen tuki ja käyttö, edellytyksenä vähimmäispääsykynnykselle kaikille uusille osallistujille eri divisioonoista ja tukiosastosta.
Deadline - eilen.
Voita kehitysryhmä
Mitä Windows-tiimi työskenteli silloin?
Nyt voin vakuuttavasti sanoa sen IdentityServer4 on siisti ilmainen vaihtoehto ADFS:lle, jolla on vastaavat ominaisuudet, tai mitä Entity Framework Core - kehittäjän paratiisi, jossa ei tarvitse vaivautua SQL-skriptien kirjoittamiseen, vaan kuvailla tietokannan kyselyitä OOP-termein. Mutta sitten toimintasuunnitelman keskustelun aikana katsoin tätä pinoa ikään kuin se olisi sumerilaista nuolenpäätä, tunnistaen vain PostgreSQL:n ja Gitin.
Käytimme tuolloin aktiivisesti nukke kokoonpanonhallintajärjestelmänä. Useimmissa projekteissamme käytimme GitLab CI, Joustava, tasapainoisia korkean kuormituksen palveluita käyttämällä HAProxy seurannut kaikkea Zabbix, nivelsiteet grafana и Prometheus, Jääkäri, ja kaikki tämä pyöri raudanpaloilla HP c ESXi päälle VMware. Kaikki tietävät sen - genren klassikko.
Katsotaanpa ja yritetään ymmärtää mitä tapahtui ennen kuin aloitimme kaikki nämä toimet.
Mitä tapahtui
TFS on melko tehokas järjestelmä, joka ei vain toimita koodia kehittäjältä lopulliseen tuotantokoneeseen, vaan sisältää myös joukon erittäin joustavaa integrointia eri palveluihin - tarjotakseen CI:n monien alustojen tasolla.
Aiemmin nämä olivat kiinteät ikkunat. TFS käytti useita Build-agentteja, joita käytettiin monien projektien kokoamiseen. Jokaisella agentilla on 3-4 työntekijää rinnakkaisemaan tehtäviä ja optimoimaan prosessia. Sitten julkaisusuunnitelmien mukaan TFS toimitti juuri valmistetun Buildin Windows-sovelluspalvelimelle.
Mitä halusimme saavuttaa?
Käytämme TFS:ää toimitukseen ja kehittämiseen ja käytämme sovellusta Linux-sovelluspalvelimella, ja niiden välillä on jonkinlaista taikuutta. Tämä Magic Box ja edessä on työn suola. Ennen kuin puran sen osiin, otan askeleen sivuun ja sanon muutaman sanan sovelluksesta.
Hanke
Sovellus tarjoaa toimintoja prepaid-korttien käsittelyyn.
Asiakas
Käyttäjiä oli kahdenlaisia. Ensimmäinen sai pääsyn kirjautumalla sisään käyttämällä SSL SHA-2 -varmennetta. U toinen oli pääsy kirjautumistunnuksella ja salasanalla.
HAProxy
Sitten asiakaspyyntö meni HAProxylle, joka ratkaisi seuraavat ongelmat:
- ensisijainen lupa;
- SSL irtisanominen;
- HTTP-pyyntöjen viritys;
- lähetyspyyntöjä.
Asiakasvarmenne varmistettiin ketjun varrella. Me - viranomaisen ja meillä on siihen varaa, koska myönnämme itse palveluasiakkaille varmenteita.
Kiinnitä huomiota kolmanteen kohtaan, palaamme siihen hieman myöhemmin.
taustaosa
He suunnittelivat tekevänsä taustajärjestelmän Linuxille. Taustaohjelma on vuorovaikutuksessa tietokannan kanssa, lataa tarvittavan luettelon käyttöoikeuksista ja sen jälkeen, riippuen valtuutetun käyttäjän oikeuksista, tarjoaa pääsyn talousasiakirjojen allekirjoittamiseen ja lähettämiseen suoritettavaksi tai jonkinlaisen raportin luomiseen.
Säästöjä HAProxylla
Niiden kahden kontekstin lisäksi, joissa jokainen asiakas navigoi, oli myös identiteettikonteksti. IdentityServer4 antaa sinun vain kirjautua sisään, tämä on ilmainen ja tehokas analogi ADFS - Active Directoryn yhdistämispalvelut.
Henkilöllisyyspyyntö käsiteltiin useassa vaiheessa. Ensimmäinen askel - asiakas pääsi takapäähän, joka oli yhteydessä tämän palvelimen kanssa ja tarkisti asiakkaan tunnuksen olemassaolon. Jos sitä ei löytynyt, pyyntö palautettiin takaisin kontekstiin, josta se tuli, mutta uudelleenohjauksella, ja uudelleenohjauksella se meni identiteettiin.
Toinen vaihe - pyyntö vastaanotettiin IdentityServerin valtuutussivulle, johon asiakas rekisteröityi, ja kauan odotettu merkki ilmestyi IdentityServer-tietokantaan.
Kolmas vaihe - asiakas ohjattiin takaisin kontekstiin, josta se tuli.
IdentityServer4:ssä on ominaisuus: se palauttaa vastauksen palautuspyyntöön HTTP:n kautta. Huolimatta siitä, kuinka paljon kamppailimme palvelimen asettamisen kanssa, riippumatta siitä, kuinka paljon valisimme itseämme dokumentaatiolla, joka kerta kun saimme ensimmäisen asiakaspyynnön URL-osoitteella, joka tuli HTTPS:n kautta, ja IdentityServer palautti saman kontekstin, mutta HTTP:llä. Olimme järkyttyneitä! Ja kaikki tämä siirrettiin identiteettikontekstin kautta HAProxylle, ja otsikoissa piti muuttaa HTTP-protokolla HTTPS:ksi.
Mikä on parannus ja mistä olet säästänyt?
Säästimme rahaa käyttämällä ilmaista ratkaisua käyttäjäryhmän, resurssien valtuutukseen, koska emme sijoittaneet IdentityServer4:ää erilliseksi solmuksi erilliseen segmenttiin, vaan käytimme sitä yhdessä taustajärjestelmän kanssa samalla palvelimella, jossa sovelluksen taustaosa toimii. .
Miten sen pitäisi toimia
Joten kuten lupasin - Magic Box. Ymmärrämme jo, että siirrymme kohti Linuxia. Muotoillaan konkreettisia ratkaisuja vaativia tehtäviä.
Nukke ilmentyy. Palvelu- ja sovelluskokoonpanon toimittamiseksi ja hallitsemiseksi piti kirjoittaa hienoja reseptejä. Kynärulla osoittaa kaunopuheisesti, kuinka nopeasti ja tehokkaasti se tehtiin.
Toimitustapa. Vakio on RPM. Kaikki ymmärtävät, että Linuxissa et voi tehdä ilman sitä, mutta itse projekti kokoonpanon jälkeen oli joukko suoritettavia DLL-tiedostoja. Heitä oli noin 150, projekti oli melko vaikea. Ainoa harmoninen ratkaisu on pakata tämä binaari RPM:ään ja ottaa sovellus käyttöön siitä.
Versiointi. Meidän piti julkaista hyvin usein, ja meidän piti päättää, miten paketin nimi muodostetaan. Tämä on kysymys TFS:n integroinnin tasosta. Meillä oli rakennusagentti Linuxissa. Kun TFS lähettää tehtävän käsittelijälle - työntekijälle - Build-agentille, se välittää sille myös joukon muuttujia, jotka päätyvät käsittelijäprosessin ympäristöön. Nämä ympäristömuuttujat sisältävät koontiversion nimen, version nimen ja muita muuttujia. Lue lisää tästä "RPM-paketin rakentaminen" -osiosta.
TFS:n asetukset päätyi putkilinjan asettamiseen. Aiemmin keräsimme kaikki Windows-projektit Windows-agenteille, mutta nyt ilmestyy Linux-agentti - Build-agentti, joka on sisällytettävä koontiryhmään, rikastettava artefakteilla ja kerrottava, minkä tyyppisiä projekteja tälle Build-agentille rakennetaan. , ja muokata putkilinjaa jollakin tavalla.
IdentityServer. ADFS ei ole meidän tapamme, olemme menossa avoimeen lähdekoodiin.
Käydään komponentit läpi.
Magic Box
Koostuu neljästä osasta.
Linux Build agentti. Linux, koska rakennamme sitä varten – se on loogista. Tämä osa tehtiin kolmessa vaiheessa.
- Määritä työntekijät eikä yksin, koska projektin parissa odotettiin hajautettua työtä.
- Asenna .NET Core 1.x. Miksi 1.x, kun 2.0 on jo saatavilla vakiovarastossa? Koska kun aloitimme kehityksen, vakaa versio oli 1.09 ja sen pohjalta päätettiin tehdä projekti.
- Git 2.x.
RPM-arkisto. RPM-paketit piti varastoida jonnekin. Oletettiin, että käyttäisimme samaa yrityksen RPM-tietovarastoa, joka on kaikkien Linux-isäntien käytettävissä. Niin he tekivät. Arkistopalvelin on määritetty verkkokoukku joka latasi vaaditun RPM-paketin määritetystä sijainnista. Build-agentti ilmoitti paketin version webhookiin.
GitLab. Huomio! Täällä GitLabia eivät käytä kehittäjät, vaan käyttöosasto valvomaan sovellusversioita, pakettiversioita, seuraamaan kaikkien Linux-koneiden tilaa ja tallentaa reseptin - kaikki Puppet-luettelot.
nukke — ratkaisee kaikki kiistanalaiset ongelmat ja toimittaa Gitlabilta täsmälleen haluamamme kokoonpanon.
Alamme sukeltaa. Kuinka DLL-toimitus RPM:ään toimii?
Toimitus DDL RPM
Oletetaan, että meillä on .NET-kehityksen rocktähti. Se käyttää Visual Studiota ja luo julkaisuhaaran. Sen jälkeen se lataa sen Gitiin, ja Git tässä on TFS-yksikkö, eli se on sovellusvarasto, jonka kanssa kehittäjä työskentelee.
Tämän jälkeen TFS näkee, että uusi sitoumus on saapunut. Mikä sovellus? TFS-asetuksissa on otsikko, joka osoittaa, mitä resursseja tietyllä rakennusagentilla on. Tässä tapauksessa hän näkee, että olemme rakentamassa .NET Core -projektia ja valitsee Linux Build -agentin poolista.
Build-agentti vastaanottaa lähteet ja lataa tarvittavat riippuvuudet .NET-arkistosta, npm jne. ja sen jälkeen, kun se on rakentanut itse sovelluksen ja sen pakkaamisen, lähettää RPM-paketin RPM-tietovarastoon.
Toisaalta tapahtuu seuraavaa. Käyttöosaston insinööri on suoraan mukana projektin käyttöönotossa: hän muuttaa pakettien versioita Hiera arkistoon, johon sovellusresepti on tallennettu, minkä jälkeen Nukke laukeaa Yum, hakee uuden paketin arkistosta ja sovelluksen uusi versio on valmis käytettäväksi.
Kaikki on yksinkertaista sanoin, mutta mitä itse Build-agentissa tapahtuu?
Pakkaus DLL RPM
Vastaanotettu projektilähteet ja rakennustehtävä TFS:stä. Rakenna agentti alkaa rakentaa itse hanketta lähteistä. Koottu projekti on saatavana settinä DLL-tiedostoja, jotka on pakattu zip-arkistoon tiedostojärjestelmän kuormituksen vähentämiseksi.
ZIP-arkisto heitetään pois RPM-paketin rakennushakemistoon. Seuraavaksi Bash-komentosarja alustaa ympäristömuuttujat, etsii koontiversion, projektiversion, polun koontihakemistoon ja suorittaa RPM-koontiversion. Kun rakennus on valmis, paketti julkaistaan paikallinen arkisto, joka sijaitsee Build-agentissa.
Seuraavaksi Build-agentista RPM-tietovaraston palvelimelle JSON-pyyntö on lähetetty ilmaisee version ja koontiversion nimen. Webhook, josta puhuin aiemmin, lataa juuri tämän paketin Build-agentin paikallisesta arkistosta ja asettaa uuden kokoonpanon asennettavaksi.
Miksi tämä paketin toimitusjärjestelmä RPM-tietovarastoon? Miksi en voi lähettää koottu pakettia välittömästi arkistoon? Tosiasia on, että tämä on ehto turvallisuuden varmistamiselle. Tämä skenaario rajoittaa mahdollisuutta, että luvattomat ihmiset lataavat RPM-paketteja palvelimelle, joka on kaikkien Linux-laitteiden käytettävissä.
Tietokannan versiointi
Neuvottelussa kehitystiimin kanssa kävi ilmi, että kaverit olivat lähempänä MS SQL:ää, mutta useimmissa ei-Windows-projekteissa käytimme jo PostgreSQL:ää kaikin voimin. Koska olimme jo päättäneet luopua kaikesta maksetusta, aloimme käyttää PostgreSQL:ää myös täällä.
Tässä osassa haluan kertoa kuinka versiosimme tietokannan ja kuinka valitsimme Flywayn ja Entity Framework Coren välillä. Katsotaanpa niiden etuja ja haittoja.
Miinukset
Flyway kulkee vain yhteen suuntaan, me emme voi perääntyä - Tämä on merkittävä haitta. Voit verrata sitä Entity Framework Coreen muillakin tavoilla – kehittäjien mukavuuden kannalta. Muistathan, että asetimme tämän etusijalle, ja pääkriteerinä oli olla muuttamatta mitään Windows-kehityksen kannalta.
Flyway meille jonkinlainen kääre tarvittiinjotta pojat eivät kirjoita SQL-kyselyt. Ne ovat paljon lähempänä OOP-toimintaa. Kirjoitimme ohjeet tietokantaobjektien kanssa työskentelemiseen, loimme SQL-kyselyn ja suoritimme sen. Tietokannan uusi versio on valmis, testattu - kaikki on kunnossa, kaikki toimii.
Entity Framework Corella on miinus - raskaan kuormituksen alla se rakentaa alioptimaalisia SQL-kyselyitä, ja tietokannan lasku voi olla merkittävä. Mutta koska meillä ei ole korkean kuormituksen palvelua, emme laske kuormitusta satoissa RPS:issä, hyväksyimme nämä riskit ja delegoimme ongelman tulevaisuuden meille.
Pros
Entity Framework Core toimii suoraan pakkauksesta ja on helppo kehittääja Flyway Integroituu helposti olemassa olevaan CI:hen. Mutta teemme siitä kätevän kehittäjille :)
Roll-up-menettely
Puppet näkee, että muutos pakettiversioon on tulossa, mukaan lukien se, joka vastaa siirrosta. Ensin se asentaa paketin, joka sisältää siirtokomentosarjoja ja tietokantoihin liittyviä toimintoja. Tämän jälkeen tietokannan kanssa toimiva sovellus käynnistetään uudelleen. Seuraavaksi tulee muiden komponenttien asennus. Järjestys, jossa paketit asennetaan ja sovellukset käynnistetään, on kuvattu Puppet-luettelossa.
Sovellukset käyttävät arkaluontoisia tietoja, kuten tunnuksia, tietokannan salasanoja, kaikki tämä vedetään konfiguraatioon Puppet masterista, jossa ne tallennetaan salatussa muodossa.
TFS-ongelmia
Kun päätimme ja ymmärsimme, että kaikki todella toimii meillä, päätin tarkastella, mitä tapahtui TFS:n kokoonpanoille kokonaisuudessaan Win-kehitysosastolle muissa projekteissa - rakensimmeko/julkaisimmeko nopeasti vai emme, ja havaitsi merkittäviä ongelmia nopeuden suhteen.
Yhden pääprojektin kokoaminen vie 12-15 minuuttia - se on pitkä aika, et voi elää niin. Nopea analyysi osoitti kauhean häiriön I/O:ssa, ja tämä oli taulukoissa.
Analysoituani sen komponentti kerrallaan tunnistin kolme pesäkettä. Ensimmäinen - "Kaspersky antivirus", joka tarkistaa kaikkien Windows Build -agenttien lähteet. Toinen - Windows Indeksoija. Sitä ei poistettu käytöstä, ja kaikki indeksoitiin reaaliajassa Build-agenteissa käyttöönottoprosessin aikana.
Kolmas - Npm asennus. Kävi ilmi, että useimmissa Pipelinesissä käytimme juuri tätä skenaariota. Miksi hän on huono? Npm-asennus suoritetaan, kun riippuvuuspuu muodostetaan paketti-lukko.json, johon tallennetaan projektin rakentamiseen käytettävien pakettien versiot. Huonona puolena on, että Npm install hakee joka kerta Internetistä uusimmat versiot paketeista, mikä vie paljon aikaa suuren projektin tapauksessa.
Kehittäjät kokeilevat joskus paikallisella koneella testatakseen, miten tietty osa tai koko projekti toimii. Joskus kävi ilmi, että kaikki oli siistiä paikallisesti, mutta ne koottiin, rullattiin ulos, eikä mikään toiminut. Alamme selvittää, mikä ongelma on - kyllä, eri versiot paketeista, joissa on riippuvuuksia.
päätös
- Lähteet AV-poikkeuksissa.
- Poista indeksointi käytöstä.
- Siirtyminen npm ci.
npm ci:n edut ovat, että me Keräämme riippuvuuspuun kerran, ja saamme mahdollisuuden tarjota kehittäjälle nykyinen pakettiluettelo, jolla hän voi kokeilla paikallisesti niin paljon kuin haluaa. Tämä säästää aikaa kehittäjät, jotka kirjoittavat koodia.
kokoonpano
Nyt vähän arkiston kokoonpanosta. Käytämme historiallisesti yhteys arkistojen hallintaan, mukaan lukien Sisäinen REPO. Tämä sisäinen arkisto sisältää kaikki komponentit, joita käytämme sisäisiin tarkoituksiin, esimerkiksi itsekirjoitettuun valvontaan.
Käytämme myös nuget, koska sillä on parempi välimuisti verrattuna muihin paketinhallintaohjelmiin.
Tulos
Kun olemme optimoineet rakennusagentit, keskimääräinen rakennusaika lyheni 12 minuutista 7:ään.
Jos laskemme kaikki koneet, joita olisimme voineet käyttää Windowsille, mutta vaihdoimme Linuxiin tässä projektissa, säästimme noin $ 10 000. Ja se on vain lisensseissä ja enemmän, jos sisältö otetaan huomioon.
suunnitelmat
Suunnittelimme seuraavan vuosineljänneksen aikana optimoimaan koodin toimituksen.
Vaihdetaan esikoon Docker-kuvaan. TFS on hieno asia, jossa on monia laajennuksia, joiden avulla voit integroida Pipelineen, mukaan lukien esimerkiksi Docker-kuvan trigger-pohjainen kokoonpano. Haluamme käynnistää tämän saman paketti-lukko.json. Jos projektin rakentamiseen käytettyjen komponenttien koostumus jotenkin muuttuu, rakennamme uuden Docker-imagin. Sitä käytetään myöhemmin säiliön käyttöönottamiseksi kootun sovelluksen kanssa. Nyt näin ei ole, mutta suunnittelemme siirtymistä mikropalveluarkkitehtuuriin Kubernetesissa, joka kehittyy yhtiössämme aktiivisesti ja on palvellut tuotantoratkaisuja jo pitkään.
Yhteenveto
Kannustan kaikkia heittämään Windowsin pois, mutta se ei johdu siitä, ettenkö osaa valmistaa sitä. Syynä on, että useimmat avoimen lähdekoodin ratkaisut ovat Linux-pino. Oletko kunnossa säästää resursseja. Mielestäni tulevaisuus kuuluu avoimen lähdekoodin ratkaisuille Linuxissa, jossa on tehokas yhteisö.
Alexander Sinchinovin puhujaprofiili .
on ammattilaisille suunnattu konferenssi kehitys-, testaus- ja käyttöprosessien integroinnista ammattilaisille. Siksikö projekti, josta Alexander puhui? toteutettu ja toimiva, ja esityspäivänä oli kaksi onnistunutta julkaisua. Päällä Toukokuun 27. ja 28. päivänä tulee vielä enemmän vastaavia tapauksia ammatinharjoittajilta. Voit silti hypätä viimeiseen vaunuun ja tai ota aikaa lippu. Nähdään Skolkovossa!
Lähde: will.com