Við þróuðum DevOps eins og við gátum. Við vorum 8 og Vasya var flottust í Windows. Skyndilega fór Vasya og ég fékk það verkefni að setja af stað nýtt verkefni sem var útvegað af Windows þróun. Þegar ég henti öllum Windows þróunarbunkanum á borðið, áttaði ég mig á því að ástandið var sársaukafullt...
Svona byrjar sagan Alexandra Sinchinova á . Þegar leiðandi Windows sérfræðingur hætti hjá fyrirtækinu, velti Alexander fyrir sér hvað ætti að gera núna. Skiptu yfir í Linux, auðvitað! Alexander mun segja þér hvernig honum tókst að skapa fordæmi og flytja hluta af Windows þróun yfir á Linux með því að nota dæmi um lokið verkefni fyrir 100 notendur.
Hvernig á að skila verkefni auðveldlega og áreynslulaust í RPM með TFS, Puppet, Linux .NET kjarna? Hvernig á að styðja útgáfu á verkefnagagnagrunni ef þróunarteymið heyrir orðin Postgres og Flyway í fyrsta skipti og frestur er fram eftir degi? Hvernig á að samþætta við Docker? Hvernig á að hvetja .NET forritara til að yfirgefa Windows og smoothies í þágu Puppet og Linux? Hvernig á að leysa hugmyndafræðileg átök ef það er hvorki styrkur, vilji né fjármagn til að viðhalda Windows í framleiðslu? Um þetta, sem og um Web Deploy, prófun, CI, um vinnubrögð við að nota TFS í núverandi verkefnum, og, auðvitað, um brotnar hækjur og vinnulausnir, í afriti af skýrslu Alexanders.
Svo, Vasya fór, verkefnið er á mér, verktaki bíða óþolinmóðir með pitchforks. Þegar ég loksins áttaði mig á því að ekki væri hægt að skila Vasya, fór ég að vinna. Til að byrja með mat ég hlutfall Win VMs í flota okkar. Staðan var Windows ekki í hag.
Þar sem við erum virkir að þróa DevOps, áttaði ég mig á því að eitthvað þarf að breyta í nálguninni við afhendingu nýs forrits. Það var aðeins ein lausn - ef mögulegt er, flyttu allt yfir á Linux. Google hjálpaði mér - á þeim tíma hafði .Net þegar verið flutt yfir á Linux og ég áttaði mig á því að þetta var lausnin!
Hvers vegna .NET kjarna í tengslum við Linux?
Fyrir því voru nokkrar ástæður. Milli „borga peninga“ og „ekki borga“ mun meirihlutinn velja annað - eins og ég. Leyfi fyrir MSDB kostar um $1; viðhald á flota Windows sýndarvéla kostar hundruð dollara. Fyrir stórt fyrirtæki er þetta mikill kostnaður. Þess vegna sparnað - fyrsta ástæðan. Ekki það mikilvægasta, en eitt af þeim mikilvægu.
Windows sýndarvélar taka meira fjármagn en Linux bræður þeirra - þeir eru þungir. Í ljósi umfangs stórfyrirtækisins völdum við Linux.
Kerfið er einfaldlega samþætt við núverandi CI. Við lítum á okkur sem framsækið DevOps, við notum Bamboo, Jenkins og GitLab CI, þannig að mest af vinnu okkar keyrir á Linux.
Síðasta ástæðan er þægilegur undirleikur. Við þurftum að lækka aðgangshindrun fyrir „fylgdarmenn“ – strákarnir sem skilja tæknilega hlutann, tryggja óslitna þjónustu og viðhalda þjónustu frá annarri línu. Þeir voru þegar kunnugir Linux staflanum, þannig að það er miklu auðveldara fyrir þá að skilja, styðja og viðhalda nýrri vöru en að eyða auknu fjármagni til að skilja sömu virkni hugbúnaðar fyrir Windows pallinn.
Kröfur
Fyrst og fremst - þægindi nýju lausnarinnar fyrir þróunaraðila. Þeir voru ekki allir tilbúnir til breytinga, sérstaklega eftir að orðið Linux var talað. Hönnuðir vilja uppáhalds Visual Studio þeirra, TFS með sjálfvirkum prófum fyrir samsetningar og smoothies. Hvernig afhending til framleiðslu á sér stað skiptir þá ekki máli. Þess vegna ákváðum við að breyta ekki venjulegu ferli og láta allt vera óbreytt fyrir þróun Windows.
Vantar nýtt verkefni aðlagast núverandi CI. Teinarnir voru þegar til staðar og öll vinna þurfti að vinna með hliðsjón af breytum stillingastjórnunarkerfisins, viðurkenndra afhendingarstaðla og eftirlitskerfa.
Auðveldur stuðningur og rekstur, sem skilyrði fyrir lágmarksþátttöku fyrir alla nýja þátttakendur úr mismunandi deildum og stuðningsdeild.
Skilafrestur - í gær.
Win Development Group
Hvað var Windows teymið að vinna með þá?
Nú get ég sagt það með öryggi IdentityServer4 er flottur ókeypis valkostur við ADFS með svipaða möguleika, eða hvað Entity Framework Core - paradís fyrir þróunaraðila, þar sem þú þarft ekki að nenna að skrifa SQL forskriftir, heldur lýsa fyrirspurnum í gagnagrunninum í OOP skilmálum. En svo, meðan á umræðunni um aðgerðaáætlunina stóð, horfði ég á þennan stafla eins og hann væri súmerska fleygboga, og þekkti aðeins PostgreSQL og Git.
Á þeim tíma vorum við virkir að nota puppet sem stillingarstjórnunarkerfi. Í flestum verkefnum okkar notuðum við GitLab CI, Elastic, jafnvægi hár-álag þjónustu með HAProxy fylgdist með öllu með Zabbix, liðbönd grafana и Prometheus, Jaeger, og allt þetta var að snúast á járnbitum HP c ESXi á VMware. Það vita það allir - klassík í tegundinni.
Við skulum skoða og reyna að skilja hvað gerðist áður en við byrjuðum á öllum þessum inngripum.
Hvað gerðist
TFS er nokkuð öflugt kerfi sem skilar ekki aðeins kóða frá þróunaraðilanum til lokaframleiðsluvélarinnar, heldur hefur einnig sett fyrir mjög sveigjanlegan samþættingu við ýmsa þjónustu - til að veita CI á vettvangsstigi.
Áður fyrr voru þetta traustir gluggar. TFS notaði nokkra Build umboðsmenn, sem voru notaðir til að setja saman mörg verkefni. Hver umboðsmaður hefur 3-4 starfsmenn til að samhliða verkefnum og hámarka ferlið. Síðan, samkvæmt útgáfuáætlunum, afhenti TFS nýbökuðu Buildið á Windows forritaþjóninn.
Hverju vildum við ná?
Við notum TFS fyrir afhendingu og þróun og keyrum forritið á Linux forritaþjóni og það er einhvers konar galdur á milli þeirra. Þetta Magic Box og þar er salt verksins framundan. Áður en ég tek hana í sundur mun ég stíga skref til hliðar og segja nokkur orð um umsóknina.
Project
Forritið býður upp á virkni til að meðhöndla fyrirframgreidd kort.
viðskiptavinur
Það voru tvær tegundir af notendum. First fékk aðgang með því að skrá þig inn með SSL SHA-2 vottorði. U seinni það var aðgangur með innskráningu og lykilorði.
HAProxy
Síðan fór beiðni viðskiptavinarins til HAProxy, sem leysti eftirfarandi vandamál:
- frumheimild;
- SSL uppsögn;
- stilla HTTP beiðnir;
- útsendingarbeiðnir.
Viðskiptavinavottorðið var staðfest meðfram keðjunni. Við - yfirvald og við höfum efni á því þar sem við sjálf gefum út skírteini til þjónustuviðskipta.
Gefðu gaum að þriðja atriðinu, við munum koma aftur að því aðeins síðar.
Bakendi
Þeir ætluðu að búa til bakendann á Linux. Bakendinn hefur samskipti við gagnagrunninn, hleður nauðsynlegum lista yfir réttindi og veitir síðan, eftir því hvaða réttindi viðurkenndur notandi hefur, aðgang til að undirrita fjárhagsskjöl og senda þau til framkvæmdar, eða búa til einhvers konar skýrslu.
Sparnaður með HAProxy
Til viðbótar við þau tvö samhengi sem hver viðskiptavinur fór í, var einnig auðkennissamhengi. IdentityServer4 leyfir þér bara að skrá þig inn, þetta er ókeypis og öflug hliðstæða fyrir ADFS - Active Directory Federation þjónusta.
Beiðnin um auðkenni var afgreidd í nokkrum skrefum. Fyrsta skref - viðskiptavinur lenti í bakendanum, sem hafði samskipti við þennan netþjón og athugaði tilvist tákns fyrir biðlarann. Ef hún fannst ekki var beiðninni skilað aftur í samhengið sem hún kom frá, en með tilvísun og með tilvísuninni fór hún í auðkenni.
Annað skref - beiðnin barst á heimildarsíðuna í IdentityServer, þar sem viðskiptavinurinn skráði sig og þessi langþráða tákn birtist í IdentityServer gagnagrunninum.
Þriðja skref - viðskiptavinurinn var vísað til baka í samhenginu sem það kom úr.
IdentityServer4 hefur eiginleika: það skilar svarinu við skilabeiðninni í gegnum HTTP. Sama hversu mikið við áttum í erfiðleikum með að setja upp þjóninn, sama hversu mikið við upplýstum okkur með skjölunum, í hvert skipti sem við fengum fyrstu beiðni viðskiptavinar með slóð sem kom í gegnum HTTPS, og IdentityServer skilaði sama samhengi, en með HTTP. Okkur brá! Og við fluttum allt þetta í gegnum auðkennissamhengið til HAProxy og í hausunum þurftum við að breyta HTTP samskiptareglunum í HTTPS.
Hver er framförin og hvar sparaðir þú?
Við spöruðum pening með því að nota ókeypis lausn til að heimila hóp notenda, auðlindir, þar sem við settum IdentityServer4 ekki sem sérstakan hnút í aðskildum hluta, heldur notuðum hann ásamt bakendanum á sama netþjóni þar sem bakendi forritsins keyrir .
Hvernig það ætti að virka
Svo, eins og ég lofaði - Magic Box. Við skiljum nú þegar að við erum tryggð að fara í átt að Linux. Við skulum móta ákveðin verkefni sem kröfðust lausna.
Brúða birtist. Til að afhenda og stjórna þjónustu- og forritastillingum þurfti að skrifa flottar uppskriftir. Blýantsrúlla sýnir vel hversu fljótt og vel það var gert.
Sendingaraðferð. Staðallinn er RPM. Allir skilja að í Linux geturðu ekki verið án þess, en verkefnið sjálft, eftir samsetningu, var sett af keyranlegum DLL skrám. Þeir voru um 150 talsins, verkefnið var frekar erfitt. Eina samræmda lausnin er að pakka þessu tvöfalda inn í RPM og dreifa forritinu frá því.
Útgáfa. Við þurftum að gefa út mjög oft og við þurftum að ákveða hvernig við myndum pakkanafnið. Þetta er spurning um stig samþættingar við TFS. Við vorum með byggingarfulltrúa á Linux. Þegar TFS sendir verkefni til meðhöndlunar - starfsmanns - til Build umboðsmannsins, sendir það líka fullt af breytum sem enda í umhverfi meðhöndlunarferlisins. Þessar umhverfisbreytur innihalda smíðaheitið, útgáfuheitið og aðrar breytur. Lestu meira um þetta í hlutanum „Búa til RPM pakka“.
Uppsetning TFS kom að því að setja upp Pipeline. Áður söfnuðum við öllum Windows verkefnum á Windows umboðsmönnum, en nú birtist Linux umboðsmaður - Build umboðsmaður, sem þarf að vera með í byggingarhópnum, auðgað með nokkrum gripum og sagt hvaða tegund af verkefnum verður byggð á þessum Build umboðsmanni , og einhvern veginn breyta leiðslunni.
IdentityServer. ADFS er ekki okkar leið, við erum að fara í Open Source.
Við skulum fara í gegnum þættina.
Magic Box
Samanstendur af fjórum hlutum.
Linux Build umboðsmaður. Linux, vegna þess að við byggjum fyrir það - það er rökrétt. Þessi hluti var gerður í þremur skrefum.
- Stilla starfsmenn og ekki einn, þar sem gert var ráð fyrir dreifðri vinnu við verkefnið.
- Settu upp .NET Core 1.x. Hvers vegna 1.x þegar 2.0 er nú þegar fáanlegt í venjulegu geymslunni? Vegna þess að þegar við byrjuðum á þróun var stöðuga útgáfan 1.09 og ákveðið var að gera verkefnið út frá því.
- Git 2.x.
RPM-geymsla. RPM pakka þurfti að geyma einhvers staðar. Gert var ráð fyrir að við myndum nota sömu RPM geymslu fyrirtækisins og er í boði fyrir alla Linux gestgjafa. Það gerðu þeir. Geymsluþjónninn er stilltur vefkrókur sem sótti nauðsynlegan RPM pakka frá tilgreindum stað. Pakkaútgáfan var tilkynnt til webhook af Build umboðsmanni.
GitLab. Athugið! GitLab hér er ekki notað af forriturum, heldur af rekstrardeild til að stjórna forritaútgáfum, pakkaútgáfum, fylgjast með stöðu allra Linux véla og það geymir uppskriftina - allar Puppet manifests.
puppet — leysir öll umdeild mál og skilar nákvæmlega þeirri uppsetningu sem við viljum frá Gitlab.
Við byrjum að kafa. Hvernig virkar DLL sending til RPM?
Afhending DDL til RPM
Segjum að við séum með .NET þróunarrockstar. Það notar Visual Studio og býr til útgáfugrein. Eftir það hleður það því upp á Git og Git hér er TFS eining, það er að segja að það er forritageymslan sem verktaki vinnur með.
Eftir það sér TFS að ný skuldbinding er komin. Hvaða app? Í TFS stillingunum er merkimiði sem gefur til kynna hvaða úrræði tiltekinn Build umboðsmaður hefur. Í þessu tilfelli sér hann að við erum að byggja upp .NET Core verkefni og velur Linux Build umboðsmann úr lauginni.
Byggingaraðili tekur við heimildum og halar niður nauðsynlegum ósjálfstæði úr .NET geymslunni, npm o.s.frv. og eftir að hafa smíðað forritið sjálft og síðari umbúðir, sendir RPM pakkann til RPM geymslunnar.
Aftur á móti gerist eftirfarandi. Verkfræðingur rekstrardeildar tekur beinan þátt í útsetningu verkefnisins: hann breytir útgáfum pakka í Hiera í geymslunni þar sem forritauppskriftin er geymd, eftir það kviknar Puppet Yum, sækir nýja pakkann úr geymslunni og nýja útgáfan af forritinu er tilbúin til notkunar.
Allt er einfalt í orðum, en hvað gerist inni í Build umboðsmanninum sjálfum?
Pökkun DLL RPM
Fékk verkefnisheimildir og smíðaverkefni frá TFS. Byggingarfulltrúi byrjar að byggja verkefnið sjálft upp úr heimildum. Samsett verkefni er fáanlegt sem sett DLL skrár, sem eru pakkaðar í zip skjalasafn til að draga úr álagi á skráarkerfið.
ZIP skjalasafninu er hent í RPM pakkann byggja skrána. Næst frumstillir Bash handritið umhverfisbreyturnar, finnur Build útgáfuna, verkefnisútgáfuna, slóðina að byggingaskránni og keyrir RPM-build. Þegar smíði er lokið er pakkinn birtur til staðbundinni geymslu, sem er staðsett á Build agent.
Næst, frá Build umboðsmanninum til netþjónsins í RPM geymslunni JSON beiðni er send sem gefur til kynna nafn útgáfunnar og smíðinnar. Webhook, sem ég talaði um áðan, hleður niður þessum pakka úr staðbundnu geymslunni á Build umboðsmanninum og gerir nýja samsetninguna tiltæka til uppsetningar.
Hvers vegna þetta tiltekna pakkaafhendingarkerfi til RPM geymslunnar? Af hverju get ég ekki sent samsetta pakkann strax í geymsluna? Staðreyndin er sú að þetta er skilyrði til að tryggja öryggi. Þessi atburðarás takmarkar möguleika óviðkomandi fólks að hlaða upp RPM pakka á netþjón sem er aðgengilegur öllum Linux vélum.
Útgáfa gagnagrunns
Í samráði við þróunarteymið kom í ljós að strákarnir voru nær MS SQL en í flestum verkefnum sem ekki voru Windows notuðum við PostgreSQL af fullum krafti. Þar sem við höfðum þegar ákveðið að yfirgefa allt sem greitt var, fórum við að nota PostgreSQL hér líka.
Í þessum hluta vil ég segja þér hvernig við útgefnum gagnagrunninn og hvernig við völdum á milli Flyway og Entity Framework Core. Við skulum skoða kosti þeirra og galla.
Gallar
Flugbraut fer bara eina leið, við við getum ekki snúið okkur til baka - þetta er verulegur ókostur. Þú getur borið það saman við Entity Framework Core á annan hátt - hvað varðar þægindi þróunaraðila. Þú manst að við settum þetta á oddinn og aðalviðmiðið var að breyta engu fyrir þróun Windows.
Fyrir Flyway okkur þurfti einhvers konar umbúðirsvo að strákarnir skrifi ekki SQL fyrirspurnir. Þeir eru miklu nær að starfa í OOP skilmálum. Við skrifuðum leiðbeiningar um að vinna með gagnagrunnshluti, bjuggum til SQL fyrirspurn og framkvæmdum hana. Nýja útgáfan af gagnagrunninum er tilbúin, prófuð - allt er í lagi, allt virkar.
Entity Framework Core hefur mínus - undir miklu álagi byggir óákjósanlegar SQL fyrirspurnir, og niðurdráttur í gagnagrunninum getur verið verulegur. En þar sem við erum ekki með mikla þjónustu, reiknum við ekki álagið í hundruðum RPS, við samþykktum þessa áhættu og framseldum vandamálið til framtíðar okkar.
Kostir
Entity Framework Core virkar úr kassanum og er auðvelt að þróa, og Flyway Aðlagast auðveldlega núverandi CI. En við gerum það þægilegt fyrir forritara :)
Upprifjunaraðferð
Puppet sér að breyting á pakkaútgáfu er að koma, þar á meðal sú sem ber ábyrgð á flutningi. Í fyrsta lagi setur það upp pakka sem inniheldur flutningsforskriftir og gagnagrunnstengda virkni. Eftir þetta er forritið sem vinnur með gagnagrunninum endurræst. Næst kemur uppsetning á íhlutunum sem eftir eru. Röð þar sem pakkar eru settir upp og forrit eru ræst er lýst í Puppet upplýsingaskránni.
Forrit nota viðkvæm gögn, svo sem tákn, lykilorð gagnagrunns, allt þetta er dregið inn í stillingar frá Puppet master, þar sem þau eru geymd á dulkóðuðu formi.
TFS vandamál
Eftir að við ákváðum og áttuðum okkur á því að allt væri í raun að virka fyrir okkur ákvað ég að skoða hvað væri að gerast með samsetningarnar í TFS í heild fyrir Win þróunardeildina á öðrum verkefnum - hvort sem við værum að byggja/losa hratt eða ekki, og uppgötvaði veruleg vandamál með hraða.
Eitt helsta verkefnið tekur 12-15 mínútur að setja saman - það er langur tími, þú getur ekki lifað svona. Fljótleg greining sýndi hræðilega samdrátt í I/O og þetta var á fylkjum.
Eftir að hafa greint það efni fyrir þátt, greindi ég þrjá brennipunkta. Fyrst - "Kaspersky vírusvörn", sem skannar heimildir á öllum Windows Build umboðsmönnum. Annað - Windows Flokkari. Það var ekki óvirkt og allt var verðtryggt í rauntíma á Build umboðsmönnum meðan á dreifingarferlinu stóð.
Í þriðja lagi - Npm uppsetning. Það kom í ljós að í flestum leiðslum notuðum við nákvæmlega þessa atburðarás. Af hverju er hann vondur? Npm uppsetningarferlið er keyrt þegar ósjálfstæðistréð er myndað í pakkalás.json, þar sem útgáfur af pakka sem verða notaðar til að byggja upp verkefnið eru skráðar. Gallinn er sá að Npm install dregur upp nýjustu útgáfur af pakka af netinu í hvert skipti og það tekur mikinn tíma ef um stórt verkefni er að ræða.
Hönnuðir gera stundum tilraunir á staðbundinni vél til að prófa hvernig tiltekinn hluti eða allt verkefni virkar. Stundum kom í ljós að allt var flott á staðnum en þeir settu það saman, rúlluðu því út og ekkert gekk. Við byrjum að finna út hvað vandamálið er - já, mismunandi útgáfur af pakka með ósjálfstæði.
ákvörðun
- Heimildir í AV undantekningum.
- Slökktu á verðtryggingu.
- Fara til npm ci.
Kostir npm ci eru þeir að við Við söfnum ávanatrénu einu sinni, og við fáum tækifæri til að veita verktaki núverandi lista yfir pakka, sem hann getur gert tilraunir með á staðnum eins mikið og hann vill. Þetta sparar tíma forritara sem skrifa kóða.
Stillingar
Nú aðeins um uppsetningu geymslunnar. Sögulega notum við Nexus til umsjón með geymslum, þ.m.t Innri REPO. Þessi innri geymsla inniheldur alla hluti sem við notum í innri tilgangi, til dæmis, sjálfskrifað eftirlit.
Við notum líka NuGet, þar sem það hefur betri skyndiminni samanborið við aðra pakkastjóra.
Niðurstaðan
Eftir að við fínstilltum byggingarmiðlana var meðalbyggingartíminn styttur úr 12 mínútum í 7.
Ef við teljum allar vélarnar sem við hefðum getað notað fyrir Windows, en skipt yfir í Linux í þessu verkefni, þá söfnuðum við um $10. Og það er bara á leyfum og fleira ef tekið er tillit til innihaldsins.
Áætlun
Á næsta ársfjórðungi ætluðum við að vinna að hagræðingu kóðaafhendingar.
Skipt yfir í forsmíðaða Docker mynd. TFS er flottur hlutur með mörgum viðbótum sem gera þér kleift að samþætta í Pipeline, þar á meðal kveikja byggða samsetningu, til dæmis, Docker mynd. Við viljum koma þessu af stað fyrir þann sama pakkalás.json. Ef samsetning íhlutanna sem notaðir voru til að byggja verkefnið breytist einhvern veginn, byggjum við nýja Docker mynd. Það er síðar notað til að dreifa ílátinu með samsettu forritinu. Þetta er ekki raunin núna, en við ætlum að skipta yfir í örþjónustuarkitektúr í Kubernetes, sem er í virkri þróun í fyrirtækinu okkar og hefur þjónað framleiðslulausnum í langan tíma.
Yfirlit
Ég hvet alla til að henda Windows, en það er ekki vegna þess að ég kann ekki að elda það. Ástæðan er sú að flestar Opensource lausnir eru það Linux stafla. er í lagi með þig spara á fjármagni. Að mínu mati tilheyrir framtíðin Open Source lausnum á Linux með öflugu samfélagi.
Ræðumaður Alexander Sinchinov .
er ráðstefna um samþættingu þróunar-, prófunar- og rekstrarferla fyrir fagfólk af fagfólki. Þess vegna verkefnið sem Alexander talaði um? útfært og unnið, og á flutningsdegi voru tvær vel heppnaðar útgáfur. Á Dagana 27. og 28. maí verða enn fleiri sambærileg mál frá iðkendum. Þú getur samt hoppað í síðasta vagninn og eða gefðu þér tíma miða. Hittu okkur í Skolkovo!
Heimild: www.habr.com