DevOps sme vyvinuli najlepšie, ako sme mohli. Bolo nás 8 a Vasya bol najlepší v systéme Windows. Zrazu Vasya odišiel a ja som mal za úlohu spustiť nový projekt, ktorý dodal vývoj pre Windows. Keď som vysypal na stôl celý balík vývoja systému Windows, uvedomil som si, že situácia je nepríjemná...
Takto sa začína príbeh Alexandra Sinchinová na . Keď popredný špecialista na Windows opustil spoločnosť, Alexander premýšľal, čo robiť teraz. Prejdite na Linux, samozrejme! Alexander vám na príklade dokončeného projektu pre 100 000 koncových používateľov povie, ako sa mu podarilo vytvoriť precedens a preniesť časť vývoja Windows do Linuxu.
Ako jednoducho a bez námahy dodať projekt do RPM pomocou TFS, Puppet, Linux .NET core? Ako podporiť vytváranie verzií projektovej databázy, ak vývojový tím počuje slová Postgres a Flyway prvýkrát a konečný termín je pozajtra? Ako sa integrovať s Dockerom? Ako motivovať vývojárov .NET, aby opustili Windows a smoothies v prospech Puppet a Linuxu? Ako vyriešiť ideologické konflikty, ak nie je ani sila, ani túžba, ani zdroje na udržanie Windowsu vo výrobe? O tomto, ako aj o Web Deploy, testovaní, CI, o praktikách používania TFS v existujúcich projektoch a, samozrejme, o zlomených barličkách a pracovných riešeniach, v prepise Alexandrovej správy.
Takže Vasya odišiel, úloha je na mne, vývojári netrpezlivo čakajú s vidlami. Keď som si konečne uvedomil, že Vasju nemožno vrátiť, pustil som sa do práce. Na začiatok som zhodnotil percento Win VM v našej flotile. Skóre nebolo v prospech systému Windows.
Keďže DevOps aktívne vyvíjame, uvedomil som si, že treba niečo zmeniť v prístupe k dodávaniu novej aplikácie. Bolo len jedno riešenie – ak je to možné, preniesť všetko na Linux. Pomohol mi Google – v tom čase už bol .Net portovaný na Linux a uvedomil som si, že toto je riešenie!
Prečo jadro .NET v spojení s Linuxom?
Bolo na to viacero dôvodov. Medzi „zaplatiť peniaze“ a „nezaplatiť“ si väčšina vyberie to druhé – ako ja. Licencia pre MSDB stojí asi 1 000 dolárov, údržba flotily virtuálnych strojov Windows stojí stovky dolárov. Pre veľkú spoločnosť sú to veľké náklady. Preto úspory - prvý dôvod. Nie najdôležitejší, ale jeden z najvýznamnejších.
Virtuálne stroje Windows zaberajú viac zdrojov ako ich bratia Linux - sú ťažké. Vzhľadom na rozsah veľkej spoločnosti sme si vybrali Linux.
Systém je jednoducho integrovaný do existujúceho CI. Považujeme sa za progresívnych DevOps, používame Bamboo, Jenkins a GitLab CI, takže väčšina našej práce beží na Linuxe.
Posledným dôvodom je pohodlný sprievod. Potrebovali sme znížiť bariéru vstupu pre „eskorty“ – ľudí, ktorí rozumejú technickej časti, zabezpečujú nepretržitú službu a udržiavajú služby z druhej línie. Už boli oboznámení so zásobníkom Linuxu, takže je pre nich oveľa jednoduchšie pochopiť, podporovať a udržiavať nový produkt, než míňať ďalšie zdroje na pochopenie rovnakej funkcie softvéru pre platformu Windows.
Požiadavky
V prvom rade - pohodlie nového riešenia pre vývojárov. Nie všetci boli pripravení na zmenu, najmä po vyslovení slova Linux. Vývojári chcú svoje obľúbené Visual Studio, TFS s automatickými testami pre zostavy a smoothies. Ako prebieha dodávka do výroby, nie je pre nich dôležité. Preto sme sa rozhodli nemeniť zaužívaný proces a nechať všetko nezmenené pre vývoj Windows.
Je potrebný nový projekt integrovať do existujúcej KI. Koľajnice tam už boli a všetka práca sa musela vykonať s prihliadnutím na parametre systému riadenia konfigurácie, prijaté štandardy dodávok a monitorovacie systémy.
Jednoduchosť podpory a prevádzky, ako podmienku pre minimálny vstupný prah pre všetkých nových účastníkov z rôznych divízií a oddelenia podpory.
Termín - včera.
Win Development Group
S čím tím Windows vtedy pracoval?
Teraz to môžem s istotou povedať IdentityServer4 je skvelá bezplatná alternatíva k ADFS s podobnými schopnosťami alebo čo Entity Framework Core - raj pre vývojárov, kde sa nemusíte obťažovať písaním SQL skriptov, ale popisovať dotazy v databáze v OOP termínoch. Ale potom, počas diskusie o akčnom pláne, som sa na tento zásobník pozeral, akoby to bolo sumerské klinové písmo, pričom som rozoznával iba PostgreSQL a Git.
V tom čase sme aktívne využívali bábka ako systém riadenia konfigurácie. Vo väčšine našich projektov sme použili GitLab CI, Elastický, vyvážené služby s vysokou záťažou pomocou HAProxy všetko monitoroval Zabbix, väzy grafana и Prometheus, Morský vták, a to všetko sa točilo na kusoch železa HP c ESXi na VMware. Každý to pozná – klasika žánru.
Pozrime sa a pokúsme sa pochopiť, čo sa dialo predtým, ako sme začali so všetkými týmito zásahmi.
Čo sa stalo
TFS je pomerne výkonný systém, ktorý nielen dodáva kód od vývojára do finálneho produkčného stroja, ale má aj sadu pre veľmi flexibilnú integráciu s rôznymi službami – na poskytovanie CI na multiplatformovej úrovni.
Predtým to boli pevné okná. TFS používalo niekoľko Build agentov, ktoré boli použité na zostavenie mnohých projektov. Každý agent má 3-4 pracovníkov na paralelizáciu úloh a optimalizáciu procesu. Potom, podľa plánov vydania, TFS doručil čerstvo upečený Build na aplikačný server Windows.
Čo sme chceli dosiahnuť?
Na doručovanie a vývoj používame TFS a spúšťame aplikáciu na serveri Linux Application Server a medzi nimi existuje určitá mágia. Toto Magic Box a pred nami je soľ práce. Skôr ako to rozoberiem, urobím krok vedľa a poviem pár slov o aplikácii.
Projekt
Aplikácia poskytuje funkcionalitu pre manipuláciu s predplatenými kartami.
Zákazník
Boli dva typy používateľov. Prvé získal prístup prihlásením pomocou certifikátu SSL SHA-2. U druhý bol prístup pomocou prihlasovacieho mena a hesla.
HAProxy
Potom žiadosť klienta smerovala do HAProxy, ktorá vyriešila nasledujúce problémy:
- primárna autorizácia;
- ukončenie SSL;
- ladenie požiadaviek HTTP;
- žiadosti o vysielanie.
Klientsky certifikát bol overený v reťazci. my - autorita a môžeme si to dovoliť, keďže sami vydávame certifikáty klientom služieb.
Venujte pozornosť tretiemu bodu; vrátime sa k nemu o niečo neskôr.
backend
Plánovali vytvoriť backend na Linuxe. Backend interaguje s databázou, načíta potrebný zoznam privilégií a potom, v závislosti od toho, aké privilégiá má oprávnený používateľ, poskytuje prístup na podpisovanie finančných dokumentov a ich odoslanie na vykonanie, alebo vygeneruje nejaký druh správy.
Úspory s HAProxy
Okrem dvoch kontextov, ktorými sa každý klient pohyboval, existoval aj kontext identity. IdentityServer4 len vám umožňuje prihlásiť sa, toto je bezplatný a výkonný analóg pre ADFS - Služby federácie služby Active Directory.
Žiadosť o identitu bola spracovaná v niekoľkých krokoch. Prvý krok - zákazníka sa dostal do backendu, ktorý komunikoval s týmto serverom a kontroloval prítomnosť tokenu pre klienta. Ak sa nenašla, požiadavka sa vrátila späť do kontextu, z ktorého prišla, ale s presmerovaním a s presmerovaním prešla na identitu.
Druhý krok - žiadosť bola prijatá na autorizačnú stránku na IdentityServer, kde sa klient zaregistroval a tento dlho očakávaný token sa objavil v databáze IdentityServer.
Tretí krok - klient bol presmerovaný späť do kontextu, z ktorého pochádza.
IdentityServer4 má funkciu: vráti odpoveď na žiadosť o vrátenie cez HTTP. Bez ohľadu na to, ako veľmi sme zápasili s nastavením servera, bez ohľadu na to, ako veľmi sme sa poučili s dokumentáciou, zakaždým, keď sme dostali počiatočnú požiadavku klienta s adresou URL, ktorá prišla cez HTTPS, a IdentityServer vrátil rovnaký kontext, ale s HTTP. Boli sme šokovaní! A to všetko sme preniesli cez kontext identity do HAProxy a v hlavičkách sme museli upraviť HTTP protokol na HTTPS.
Aké je zlepšenie a kde ste ušetrili?
Ušetrili sme peniaze použitím bezplatného riešenia na autorizáciu skupiny používateľov, zdrojov, keďže sme IdentityServer4 neumiestnili ako samostatný uzol do samostatného segmentu, ale použili sme ho spolu s backendom na rovnakom serveri, kde beží backend aplikácie .
Ako by to malo fungovať
Takže, ako som sľúbil - Magic Box. Už chápeme, že sa zaručene posunieme k Linuxu. Formulujme konkrétne úlohy, ktoré si vyžadovali riešenia.
Bábkové sa prejavuje. Na poskytovanie a správu konfigurácie služieb a aplikácií bolo potrebné napísať skvelé recepty. Zvitok ceruzky výrečne ukazuje, ako rýchlo a efektívne to bolo urobené.
Spôsob doručenia. Štandardom sú otáčky za minútu. Každý chápe, že v Linuxe sa bez neho nezaobídete, ale samotný projekt bol po zostavení súborom spustiteľných súborov DLL. Bolo ich asi 150, projekt bol dosť náročný. Jediným harmonickým riešením je zabaliť tento binárny súbor do RPM a nasadiť aplikáciu z neho.
Verziovanie. Museli sme vydávať veľmi často a museli sme sa rozhodnúť, ako vytvoríme názov balíka. Toto je otázka úrovne integrácie s TFS. Mali sme build agenta na Linuxe. Keď TFS pošle úlohu na handler – worker – Build agentovi, odovzdá mu aj kopu premenných, ktoré skončia v prostredí procesu handlera. Tieto premenné prostredia obsahujú názov zostavy, názov verzie a ďalšie premenné. Prečítajte si o tom viac v časti „Vytvorenie balíka RPM“.
Nastavenie TFS pristúpil k nastaveniu Pipeline. Predtým sme zhromaždili všetky projekty Windows na agentoch Windows, ale teraz sa objaví agent Linux - agent zostavenia, ktorý musí byť zahrnutý do skupiny zostavovania, obohatený o niektoré artefakty a povedať, aké typy projektov budú postavené na tomto agentovi zostavenia. a nejako upraviť potrubie.
IdentityServer. ADFS nie je naša cesta, ideme pre Open Source.
Poďme si prejsť komponenty.
Magic Box
Pozostáva zo štyroch častí.
Linux Build agent. Linux, pretože preňho staviame – je to logické. Táto časť bola vykonaná v troch krokoch.
- Konfigurovať pracovníkov a nie sám, keďže sa očakávala distribuovaná práca na projekte.
- Nainštalujte si .NET Core 1.x. Prečo 1.x, keď 2.0 je už k dispozícii v štandardnom úložisku? Pretože keď sme začali s vývojom, stabilná verzia bola 1.09 a bolo rozhodnuté vytvoriť projekt na jej základe.
- Git 2.x.
RPM-úložisko. RPM balíky bolo potrebné niekde uložiť. Predpokladalo sa, že budeme používať rovnaké firemné úložisko RPM, ktoré je dostupné pre všetkých hostiteľov Linuxu. To je to, čo urobili. Server úložiska je nakonfigurovaný webový háčik ktorý stiahol požadovaný balík RPM zo zadaného miesta. Verzia balíka bola webhooku nahlásená agentom Build.
GitLab. Pozor! GitLab tu nepoužívajú vývojári, ale prevádzkové oddelenie na kontrolu verzií aplikácií, verzií balíkov, sledovanie stavu všetkých linuxových strojov a uchováva recept - všetky manifesty bábok.
bábka — rieši všetky kontroverzné problémy a poskytuje presne takú konfiguráciu, akú od Gitlabu požadujeme.
Začíname sa potápať. Ako funguje doručovanie DLL do RPM?
Doručenie DDL do RPM
Povedzme, že máme vývojovú rockovú hviezdu .NET. Používa Visual Studio a vytvára vetvu vydania. Potom to nahrá do Gitu a Git je tu entita TFS, to znamená, že je to úložisko aplikácií, s ktorým vývojár pracuje.
Potom TFS vidí, že prišlo nové odovzdanie. Ktorá aplikácia? V nastaveniach TFS je štítok označujúci, aké zdroje má konkrétny Build agent. V tomto prípade vidí, že budujeme projekt .NET Core a vyberie z fondu agenta Linux Build.
Agent zostavenia dostane zdroje a stiahne potrebné závislostí z úložiska .NET, npm atď. a po zostavení samotnej aplikácie a následnom zabalení odošle RPM balíček do RPM úložiska.
Na druhej strane sa stane nasledovné. Inžinier prevádzkového oddelenia je priamo zapojený do zavádzania projektu: mení verzie balíkov Hiera v úložisku, kde je uložený recept aplikácie, po ktorom sa spustí Puppet yum, načíta nový balík z úložiska a nová verzia aplikácie je pripravená na použitie.
Všetko je jednoduché slovami, ale čo sa deje vo vnútri samotného agenta Build?
Balenie DLL RPM
Prijaté zdroje projektu a úloha zostavenia z TFS. Stavať agenta začína budovať samotný projekt zo zdrojov. Zostavený projekt je k dispozícii ako sada DLL súbory, ktoré sú zabalené v archíve zip, aby sa znížilo zaťaženie súborového systému.
ZIP archív sa vyhodí do adresára zostavenia balíka RPM. Ďalej skript Bash inicializuje premenné prostredia, nájde verziu zostavy, verziu projektu, cestu k adresáru zostavy a spustí zostavenie RPM. Po dokončení zostavenia je balík zverejnený miestne úložisko, ktorý sa nachádza na agentovi zostavenia.
Ďalej z agenta zostavenia na server v úložisku RPM Požiadavka JSON je odoslaná s uvedením názvu verzie a zostavy. Webhook, o ktorom som hovoril už skôr, stiahne práve tento balík z lokálneho úložiska v agentovi Build a sprístupní nové zostavy na inštaláciu.
Prečo práve táto schéma doručovania balíkov do úložiska RPM? Prečo nemôžem okamžite poslať zostavený balík do úložiska? Faktom je, že je to podmienka zaistenia bezpečnosti. Tento scenár obmedzuje možnosť neoprávnených osôb odovzdávať balíky RPM na server, ktorý je dostupný pre všetky počítače so systémom Linux.
Verzia databázy
Na konzultácii s vývojovým tímom sa ukázalo, že chalani majú bližšie k MS SQL, no vo väčšine projektov, ktoré nie sú pod Windows, sme už s vypätím všetkých síl používali PostgreSQL. Keďže sme sa už rozhodli opustiť všetko platené, začali sme používať PostgreSQL aj tu.
V tejto časti vám chcem povedať, ako sme spravovali verziu databázy a ako sme sa rozhodovali medzi Flyway a Entity Framework Core. Pozrime sa na ich klady a zápory.
Zápory
Flyway ide len jedným smerom, my nemôžeme sa vrátiť späť - to je značná nevýhoda. S Entity Framework Core ho môžete porovnať aj inak – z hľadiska pohodlia pre vývojárov. Pamätáte si, že sme to postavili do popredia a hlavným kritériom bolo nemeniť nič pre vývoj Windows.
Pre nás Flyway bol potrebný nejaký obalaby chalani nepísali SQL dotazy. Sú oveľa bližšie k fungovaniu v podmienkach OOP. Napísali sme návod na prácu s databázovými objektmi, vygenerovali SQL dotaz a spustili ho. Nová verzia databázy je pripravená, otestovaná - všetko je v poriadku, všetko funguje.
Entity Framework Core má mínus - pri veľkom zaťažení vytvára suboptimálne SQL dotazya čerpanie v databáze môže byť značné. Ale keďže nemáme službu s vysokou záťažou, nepočítame záťaž v stovkách RPS, tieto riziká sme akceptovali a delegovali problém na nás budúcich.
Pros
Entity Framework Core funguje po vybalení z krabice a ľahko sa vyvíjaa Flyway Ľahko sa integruje do existujúceho CI. Ale robíme to pohodlné pre vývojárov :)
Postup zrolovania
Puppet vidí, že prichádza zmena verzie balíka, vrátane verzie, ktorá je zodpovedná za migráciu. Najprv nainštaluje balík, ktorý obsahuje migračné skripty a funkcie súvisiace s databázou. Potom sa aplikácia, ktorá pracuje s databázou, reštartuje. Nasleduje inštalácia zostávajúcich komponentov. Poradie, v ktorom sa inštalujú balíčky a spúšťajú aplikácie, je popísané v manifeste Bábky.
Aplikácie používajú citlivé dáta, ako sú tokeny, heslá k databáze, to všetko sa sťahuje do konfigurácie z Puppet master, kde sú uložené v zašifrovanej podobe.
Problémy s TFS
Keď sme sa rozhodli a uvedomili sme si, že nám všetko naozaj funguje, rozhodol som sa pozrieť na to, čo sa deje so zostavami v TFS ako celku pre vývojové oddelenie Win na iných projektoch – či sme stavali/uvoľňovali rýchlo alebo nie, a objavil značné problémy s rýchlosťou .
Zloženie jedného z hlavných projektov trvá 12-15 minút – to je dlhá doba, takto sa žiť nedá. Rýchla analýza ukázala strašný pokles I/O, a to na poliach.
Po analýze komponent po komponente som identifikoval tri ohniská. Najprv - "Kaspersky antivírus", ktorý kontroluje zdroje na všetkých agentoch Windows Build. druhá - Windows Indexer. Nebolo to zakázané a všetko sa indexovalo v reálnom čase na agentoch zostavenia počas procesu nasadenia.
Po tretie - Inštalácia Npm. Ukázalo sa, že vo väčšine potrubí sme použili presne tento scenár. Prečo je zlý? Inštalačná procedúra Npm sa spustí, keď sa vytvorí strom závislostí package-lock.json, kde sú zaznamenané verzie balíkov, ktoré budú použité na zostavenie projektu. Nevýhodou je, že inštalácia Npm zakaždým stiahne najnovšie verzie balíkov z internetu, čo v prípade veľkého projektu zaberie veľa času.
Vývojári niekedy experimentujú na lokálnom počítači, aby otestovali, ako konkrétna časť alebo celý projekt funguje. Niekedy sa ukázalo, že lokálne je všetko v pohode, ale zmontovali to, vyrolovali a nič nefungovalo. Začíname zisťovať, v čom je problém - áno, rôzne verzie balíkov so závislosťami.
rozhodnutie
- Zdroje vo výnimkách AV.
- Zakázať indexovanie.
- Ísť do npm ci.
Výhody npm ci sú v tom, že my Strom závislostí zhromažďujeme raz, a dostaneme možnosť poskytnúť developerovi aktuálny zoznam balíkov, s ktorým môže lokálne experimentovať, koľko len chce. Toto šetrí čas vývojárov, ktorí píšu kód.
konfigurácia
Teraz trochu o konfigurácii úložiska. Historicky používame Nexus pre správu úložísk, vrátane Interné REPO. Toto interné úložisko obsahuje všetky komponenty, ktoré používame na interné účely, napríklad na vlastné monitorovanie.
Používame tiež NuGet, pretože má lepšie ukladanie do vyrovnávacej pamäte v porovnaní s inými správcami balíkov.
Výsledok
Po optimalizácii Build Agents sa priemerný čas zostavenia skrátil z 12 minút na 7.
Ak spočítame všetky stroje, ktoré sme mohli použiť pre Windows, ale v tomto projekte sme prešli na Linux, ušetrili sme okolo 10 000. A to len na licenciách a ak vezmeme do úvahy obsah, aj viac.
Plány
Na ďalší štvrťrok sme plánovali pracovať na optimalizácii doručovania kódu.
Prepnutie na vopred zostavený obraz Docker. TFS je skvelá vec s mnohými zásuvnými modulmi, ktoré vám umožňujú integrovať sa do Pipeline, vrátane zostavovania na základe spúšťača, povedzme, obrazu Docker. Chceme urobiť tento spúšťač pre ten istý package-lock.json. Ak sa zloženie komponentov použitých na zostavenie projektu nejako zmení, vytvoríme nový obrázok Docker. Neskôr sa používa na nasadenie kontajnera so zostavenou aplikáciou. Teraz to tak nie je, ale plánujeme prejsť na mikroservisnú architektúru v Kubernetes, ktorá sa v našej spoločnosti aktívne rozvíja a dlhodobo slúži produkčným riešeniam.
Zhrnutie
Odporúčam každému, aby zahodil Windows, ale nie je to preto, že by som ho nevedel variť. Dôvodom je väčšina Opensource riešení Zásobník Linuxu. si v poriadku ušetriť na zdrojoch. Podľa môjho názoru budúcnosť patrí Open Source riešeniam na Linuxe so silnou komunitou.
Profil rečníka Alexandra Sinčinova .
je konferencia o integrácii procesov vývoja, testovania a prevádzky pre profesionálov profesionálmi. Preto ten projekt, o ktorom Alexander hovoril? implementované a funkčné a v deň predstavenia boli dve úspešné vydania. Zapnuté 27. a 28. mája bude podobných prípadov od praktizujúcich ešte viac. Ešte môžete naskočiť do posledného vozňa a alebo si daj načas lístok. Stretneme sa v Skolkove!
Zdroj: hab.com