DevOps sme vyvíjali, ako najlepšie sme mohli. Boli sme štyria a Václav bol najlepší v oblasti Windows. Náhle Václav odišiel a ja som dostal úlohu spustiť nový projekt, ktorý dodáva Windows vývoj. Keď som na stôl vysypal celý stack Windows vývoja, uvedomil som si, že situácia je ťažká...
Takto sa začína príbeh Alexandra Sinčinova na . Keď z firmy odišiel vedúci špecialista na Windows, Alexander sa začal zamýšľať, čo teraz robiť. Prejsť na Linux, samozrejme! Alexander rozpráva, ako sa mu podarilo vytvoriť precedens a preložiť časť Windows vývoja na Linux na príklade realizovaného projektu pre 100 000 koncových používateľov.
Ako jednoducho a bez námahy doručiť projekt v RPM, využívajúc TFS, Puppet a Linux .NET core? Ako uchovávať verzionovanie databázy projektu, ak vývojári prvýkrát počuli slová Postgres a Flyway, a termín je už o dva dni? Ako integrovať s Dockerom? Ako motivovať .NET vývojárov vzdať sa Windows a smoothie v prospech Puppet a Linux? Ako riešiť ideologické konflikty, ak niet síl, ani túžby, ani prostriedkov na podporu Windows v produkcii? O tom, ako aj o Web Deploy, testovaní, CI, praktikách využívania TFS v existujúcich projektoch, a samozrejme, o zlomených podperách a fungujúcich riešeniach, hovorí Alexander vo svojej prezentácii.
Takže, Václav odišiel, úloha je na mne, vývojári čakajú s vidlami nedočkavo. Keď som si konečne uvedomil, že Václava nevrátim — pustil som sa do práce. Na začiatok som odhadol percento Win VM v našom parku. Počty nehrali v prospech Windows.
Keďže aktívne rozvíjame DevOps, uvedomil som si, že je potrebné zmeniť prístup k zavádzaniu novej aplikácie. Riešením bolo jedno — pokiaľ je to možné, všetko preniesť na Linux. Google mi pomohol — vtedy už bol .Net portovaný na Linux a uvedomil som si, že je to riešenie!
Prečo .NET core v kombinácii s Linuxom?
Na to bolo niekoľko dôvodov. Medzi „platiť peniaze“ a „neplatiť“ väčšina zvolí druhé — ako aj ja. Licencia na MSDB stojí okolo 1 000 $, údržba parku virtuálnych strojov Windows sa počíta v stovkách dolárov. Pre veľké spoločnosti sú to veľké náklady. Preto úspora — je prvý dôvod. Nie najdôležitejší, ale jeden z podstatných.
Virtuálne stroje Windows si vyžadujú viac zdrojov ako ich linuxoví kolegovia — sú ťažké. Vzhľadom na rozsah veľkej spoločnosti sme zvolili Linux.
Systém sa jednoducho integruje do existujúceho CI. Považujeme sa za pokrokových DevOps, používame Bamboo, Jenkins a GitLab CI, takže väčšina našich operácií prebieha na Linuxe.
Posledný dôvod je pohodlná podpora. Museli sme znížiť prah vstupu pre „podporovateľov“ – ľudí, ktorí rozumejú technickej stránke, zabezpečujú nepretržitosť a obsluhujú služby druhej línie. Už boli oboznámení so stackom Linux, preto pre nich bolo oveľa jednoduchšie pochopiť nový produkt, podporovať a spravovať ho, než míňať ďalšie zdroje na porozumenie podobnému funkčnému softvéru pre platformu Windows.
Požiadavky
Prvé a najdôležitejšie je pohodlie nového riešenia pre vývojárov. Nie všetci z nich boli pripravení na zmeny, najmä po vyslovení slova Linux. Vývojári chcú svoju obľúbenú Visual Studio, TFS s automatickými testami pre zostavy a smoothies. Ako prebieha dodávka do produkcie – to pre nich nie je dôležité. Preto sme sa rozhodli nemeniť osvedčený proces a nechať pre Windows vývoj všetko bez zmien.
Nový projekt treba integrovať do existujúceho CI. Koľajnice už boli a celú prácu bolo potrebné vykonať so zohľadnením parametrov systému riadenia konfigurácie, prijatých štandardov dodávok a systémov monitorovania.
Jednoduchosť v podpore a prevádzke, ako podmienka pre minimálny prah vstupu pre všetkých nových účastníkov z rôznych oddelení a podpory.
Deadline – včera.
Skupina Win vývoja
Na čom teda pracoval tím Windows?
Teraz môžem s určitosťou povedať, že IdentityServer4 je skvelá bezplatná alternatíva ADFS s podobnými možnosťami, alebo že Entity Framework Core je raj pre vývojára, kde sa nemusí zaoberať písaním SQL skriptov, ale môže opisovať dopyty do DB v rámci OOP. Ale vtedy, na diskusii o pláne akcií, som na tento stack pozeral ako na šumerčinu, pričom som poznal iba PostgreSQL a Git.
V tom čase sme aktívne používali Puppet ako systém riadenia konfigurácie. Vo väčšine našich projektov sme používali GitLab CI, Elastic, vyvažovali sme vysoko zaťažené služby pomocou HAProxy, sledovali sme všetko pomocou Zabbix, kombinácie Grafana a Prometheus, Jaeger, a to všetko bežalo na HP c ESXi na VMware. Všetkým známe – klasika žánru.
Pozrime sa a pokúsme sa pochopiť, čo sa dialo predtým, ako sme začali s týmito zásahmi.
Čo sa stalo
TFS je dosť výkonný systém, ktorý nielenže doručuje kód od vývojára k finálnej produkčnej mašine, ale tiež má sadu na veľmi flexibilnú integráciu s rôznymi službami, aby zabezpečil CI na multiplatformovej úrovni.
Predtým to boli iba nepriehladné okná. TFS používal niekoľko Build agentov, na ktorých sa zhromažďovalo množstvo projektov. V každom agente bolo 3-4 workery na paralelizáciu úloh a optimalizáciu procesu. Potom, podľa plánov vydania, TFS dodával čerstvo upečený Build na Windows server aplikácií.
K čomu sme chceli dospieť
Na dodávanie a vývoj používame TFS, a aplikáciu spúšťame na Linux Application serveri, a medzi nimi je akási mágia. Tento Magic Box je soľou nadchádzajúcej práce. Predtým, ako ho rozložím na časti, urobím krok nabok a poviem dve slová o aplikácii.
Projekt
Aplikácia poskytuje funkčnosť na manipuláciu s predplatenými kartami.
Client
Existovali dva typy používateľov. Prvý mal prístup, autorizujúc sa prostredníctvom certifikátu SSL SHA-2. Druhý mal prístup pomocou prihlasovacích údajov a hesla. Potom klientsky požiadavok prešiel do HAProxy, ktorý riešil nasledujúce úlohy:
HAProxy
primárna autorizácia;
- ukončovanie SSL;
- ladění HTTP požiadaviek;
- prekládanie požiadaviek.
- Overovanie certifikátu klienta prebiehalo cez reťazec. Sme
authority a môžeme si to dovoliť, pretože sami vydávame certifikáty klientom služby. Všimnite si tretí bod, neskôr sa k nemu vrátime.
Backend
Backend plánovali na Linuxe. Backend interaguje s DB, načítava potrebný zoznam privilegií a potom, v závislosti od toho, aké privilegované má autorizovaný používateľ, poskytuje prístup na podpisovanie finančných dokumentov a ich odosielanie na vykonanie, alebo generovanie nejakého reportu.
Úspora s HAProxy
Okrem dvoch kontextov, ktorými prechádzal každý z klientov, existoval ešte kontext identity.
ktorý presne umožňuje autorizáciu, je to bezplatný a výkonný ekvivalent pre IdentityServer4 ADFS Active Directory Federation Services — Žiadosť o identity sa spracovávala v niekoľkých krokoch. Prvý krok -.
klient sa dostal do backendu. dostal sa do backendu, ktorý vymieňal údaje s týmto serverom a kontroloval prítomnosť tokenu pre klienta. Ak ho nenašiel, požiadavka sa vrátila späť do kontextu, z ktorého prišla, ale už s presmerovaním, a s presmerovaním išla na identity.
Druhý krok – požiadavka sa dostala na stránku autorizácie v IdentityServer, kde sa klient registroval, a v databáze IdentityServer sa objavil ten vytúžený token.
Tretí krok – klient bol presmerovaný späť do kontextu, z ktorého prišiel.
IdentityServer4 má špecifickosť: odpoveď na spätnú požiadavku vracia cez HTTP. Akoby sme sa s nastavovaním servera akokoľvek snažili, akoby sme si prečítali dokumentáciu, ale zakaždým sme dostali iniciačnú požiadavku klienta s URL, ktorá prišla cez HTTPS, a IdentityServer vrátil ten istý kontext, ale s HTTP. Chceli sme sa šokovať! A preložili sme to cez kontext identity na HAProxy, a v hlavičkách sme museli upraviť protokol HTTP na HTTPS.
Aké je teda zlepšenie a kde sme ušetrili?
Ušetrili sme peniaze použitím bezplatného riešenia pre autorizáciu skupiny používateľov, využili sme prostriedky, pretože sme nevyčlenili IdentityServer4 ako samostatnú uzol do samostatného segmentu, ale použili sme ho spoločne s backendom na tom istom serveri, na ktorom beží backend aplikácie.
Ako by to malo fungovať
Takže, ako som sľúbil – Magic Box. Už rozumieme, že sa zaručene posúvame k Linuxu. Poďme formulovať konkrétne úlohy, ktoré potrebovali riešenie.
Manifesty Puppet. Aby sme doručovali a spravovali konfiguráciu služby a aplikácie, bolo potrebné napísať skvelé recepty. Rolka s ceruzou výstižne ukazuje, ako rýchlo a kvalitne to bolo urobené.
Spôsob doručovania. Štandard je RPM. Všetci chápu, že v Linuxe bez neho to nejde, ale samotný projekt po zostavení predstavoval súbor vykonávacích DLL súborov. Tých bolo okolo 150, projekt bol dosť náročný. Jediné harmonické riešenie je zabaliť túto binárnu hmotu do RPM a z nej už rozbehnúť aplikáciu.
Verziovanie. Museli sme sa často releasovať a bolo potrebné rozhodnúť, ako formovať názov balíka. To je otázka úrovne integrácie s TFS. Build agent sme mali na Linuxe. Keď TFS posiela úlohu spracovateľovi - worker - na Build agenta, odovzdáva mu aj skupinu premenných, ktoré sa dostanú do prostredia procesu spracovateľa. V týchto premenných prostredia sa prenáša názov Build, verzia a ďalšie premenné. Podrobnosti nájdete v časti „súbor RPM balíka“.
Nastavenie TFS spočívalo v nastavení Pipeline. Predtým sme zhromažďovali všetky Windows projekty na Windows agentoch, ale teraz sa objavuje Linux agent - Build agent, ktorý treba pridať do skupiny zostavovania, obohatiť o nejaké artefakty, povedať, akého typu projekty sa budú zostavovať na tomto Build agentovi, a nejako modifikovať Pipeline.
IdentityServer. ADFS nie je naša cesta, podporujeme Open Source.
Prejdeme si komponenty.
Magic Box
Skladá sa zo štyroch častí.
Linux Build agent. Linux, pretože ho na to potrebujeme - logicky. Táto časť sa vykonávala v troch krokoch.
- Nastaviť workery a nie len jedného, pretože sa predpokladala distribuovaná práca na projekte.
- Nainštalovať .NET Core 1.x. Prečo práve 1.x, keď je už dostupné 2.0 v štandardnom repozitári? Pretože, keď sme začali vyvíjať, stabilná verzia bola 1.09 a projekt sa rozhodlo urobiť pod ňu.
- Git 2.x.
RPM-repozitár. RPM balíky bolo potrebné niekde uchovávať. Predpokladalo sa, že budeme používať ten istý podnikový RPM repozitár, ktorý je dostupný všetkým Linux hostiteľom. Tak sme na serveri repozitára nastavili webhook ktorý sťahoval požadovaný RPM balík z uvedeného miesta. Verziu balíka webhook-u oznamoval Build agent.
GitLab. Pozor! GitLab sa tu používa nie vývojármi, ale oddelením prevádzky na kontrolu verzií aplikácie, verzií balíkov, kontrolu stavu všetkých Linux strojov a uchováva tam receptúru - všetky manifesty Puppet.
Puppet — rieši všetky sporné otázky a doručuje presne tú konfiguráciu, ktorú chceme, z Gitlabu.
Začneme sa ponárať. Ako prebieha dodanie DLL do RPM?
Dodanie DDL do RPM
Povedzme, že máme rockovú hviezdu vývoja na .NET. Používa Visual Studio a vytvára release vetvu. Potom ju načíta do Gitu, a Git tu - TFS entita, to znamená, že je to repozitár aplikácie, s ktorým pracuje vývojár.
Po čom TFS vidí, že prišla nová commit. Aká aplikácia? V nastaveniach TFS je označenie, akými prostriedkami disponuje daný Build-agent. V tomto prípade vidí, že zbierame .NET Core projekt a vyberá Linux Build-agent z poolu.
Build-agent získa zdrojové kódy, stiahne potrebné závislosti z repozitára .NET, npm atď. a po zostavení aplikácie a následnom zabalení odosiela RPM-balík do RPM-repozitára.
Na druhej strane prebieha toto. Inžinier oddelenia prevádzky sa priamo zaoberá nasadením projektu: mení verzie balíkov v Hiera v repozitári, kde je uložený recept aplikácie, po čom Puppet spustí Yum, vezme nový balík z repozitára a nová verzia aplikácie je pripravená na použitie.
Na papieri je všetko jednoduché, ale čo sa deje vo vnútri samotného Build-agenta?
Balenie DLL RPM
Získané zdrojové kódy projektu a úloha na zostavenie od TFS. Build-agent spúšťa zostavenie samotného projektu zo zdrojov. Zostavený projekt je dostupný vo forme množstva DLL súborov, ktoré sú zabalené do zip-archívu na zníženie záťaže na súborový systém.
ZIP-archív je umiestnený do adresára zostavenia balíka RPM. Ďalej Bash-skript inicializuje premenné prostredia, nájde verziu Build, verziu projektu, cestu do adresára zostavenia a spúšťa RPM-build. Po skončení zostavenia je balík publikovaný do místneho repozitára, ktorý sa nachádza na Build-agente.
Ďalej, z Build-agenta na server v RPM-repozitári odchádza JSON-dopyt s uvedením mena verzie a buildu. Webhook, o ktorom som už hovoril, stiahne tento balík z miestneho repozitára na Build-agente a sprístupní novú zostavu na inštaláciu.
Prečo práve takýto schéma dodania balíka do repozitára RPM? Prečo nemožno okamžite odoslať zostavený balík do repozitára? Ide o to, že toto je podmienka pre zabezpečenie. Takýto scenár obmedzuje možnosť neoprávnenej zloženia RPM-balíkov cudzími osobami na server, ktorý je prístupný všetkým Linuxovým strojom.
Verzionovanie DB
Na konzíliu s vývojom sa zistilo, že chlapcom je bližšie MS SQL, ale vo väčšine non-Windows projektov sme už naplno používali PostgreSQL. Pretože sme sa už rozhodli vzdať všetkého plateného, začali sme používať PostgreSQL aj tu.
V tejto časti chcem hovoriť o tom, ako sme realizovali verzionovanie DB a ako sme si vyberali medzi Flyway a Entity Framework Core. Pozrime sa na ich výhody a nevýhody.
Nevýhody
Flyway ide len jedným smerom, my nemôžeme sa vrátiť späť — to je zásadný mínus. Porovnávať s Entity Framework Core je možné z iných parametrov — z hľadiska pohodlia vývojára. Veď si pamätáte, že sme to postavili do centra pozornosti, a hlavným kritériom bolo nezmeniť nič pre Windows vývoj.
Pre Flyway sme potrebovali akýsi wrapper, aby chlapi nepísali SQL dopyty. Pre nich je oveľa prirodzenejšie pracovať v termínoch OOP. Napísali sme pokyny na prácu s objektmi DB, SQL dopyt bol vygenerovaný a vykonaný. Nová verzia DB je pripravená, vyskúšali sme ju — všetko je v poriadku, všetko funguje.
Entity Framework Core má nevýhodu — pri vysokých zaťaženiach generuje neoptimálne SQL dopyty, a pokles výkonu DB môže byť značný. Ale pretože naši služby nie sú veľmi zaťažené, nezaznamenávame zaťaženie v stovkách RPS, prijali sme tieto riziká a delegovali problém budúcim nám.
Výhody
Entity Framework Core funguje z krabice a je pohodlný pre vývoj, zatiaľ čo Flyway sa ľahko integruje do existujúceho CI. Ale robíme to pre pohodlie vývojárov :)
Procedúra nasadenia
Puppet vidí, že prichádza zmena verzie balíkov, medzi ktorými je aj ten, ktorý zodpovedá za migráciu. Najprv nainštaluje balík, ktorý obsahuje migračné skripty a funkčnosť viazanú na DB. Po tom sa reštartuje aplikácia, ktorá pracuje s DB. Potom nasleduje inštalácia zostávajúcich komponentov. Poradie inštalácie balíkov a spustenia aplikácií je popísané v manifeste Puppet.
Aplikácie používajú citlivé údaje, ako sú tokeny, heslá k DB, všetko to sa sťahuje do konfigurácie z Puppet mastera, kde sú uložené v zašifrovanej forme.
Problémy TFS
Potom, čo sme sa rozhodli a zistili, že nám naozaj všetko funguje, rozhodol som sa pozrieť, čo sa deje so zostavami v TFS celkovo pre oddelenie Win vývoja v iných projektoch — či rýchlo zostavujeme/release-ujeme, a objavil som zásadné problémy s rýchlosťou.
Jeden z hlavných projektov sa zostavuje 12-15 minút — to je dlhé, takto sa žiť nedá. Rýchla analýza ukázala hrozné poklesy výkonu pri I/O, a to na masívoch.
Po analýze po komponentoch som vyčlenil tri ohniská. Prvé — „Kaspersky antivirus“, ktorý skenuje zdrojové kódy na všetkých Windows Build agentoch. Druhý — Windows Indexér. Nebolo to vypnuté a šlo to v reálnom čase, indexovalo sa všetko počas procesu nasadenia.
Tretí — Npm install. Ukázalo sa, že v väčšine Pipeline sme používali práve tento scenár. Čím je zlý? Procedúra Npm install sa spúšťa pri vytváraní stromu závislostí v package-lock.json, kde sú zaznamenané verzie balíkov, ktoré sa budú používať na súborný projekt. Nevýhoda je v tom, že Npm install každý raz ťahá aktuálne verzie balíkov z internetu, a to je nemalý čas v prípade veľkého projektu.
Vývojári niekedy experimentujú na lokálnom stroji, aby otestovali fungovanie jednotlivých častí alebo projektu ako celku. Niekedy to dopadlo tak, že lokálne to všetko fungovalo skvele, ale pri zostavovaní, nasadzovaní — nič nefungovalo. Začneme zisťovať, v čom je problém — aha, rôzne verzie balíkov so závislosťami.
Riešenie
- Zdroje v výnimkách AV.
- Vypnutie indexácie.
- Prechod na npm ci.
Plusy npm ci sú v tom, že zostavujeme strom závislostí jednorazovo, a dostávame možnosť poskytnúť vývojárovi aktuálny zoznam balíkov, s ktorými môže neraz experimentovať lokálne. To šetří čas vývojárov, ktorí píšu kód.
Konfigurácia
Teraz trochu o konfigurácii repozitára. Historicky používame Nexus na správu repozitárov, vrátane Interného REPO. Do tohto interného repozitára sa dodávajú všetky komponenty, ktoré používame na interné účely, napríklad vlastné monitorovanie.
Tiež používame NuGet, pretože lepšie cache-uje v porovnaní s inými správami balíkov.
Výsledok
Po optimalizácii Build agentov sa priemerný čas zostavenia skrátil z 12 minút na 7.
Ak spočítame všetky stroje, ktoré by sme mohli použiť pre Windows, ale prešli na Linux v tomto projekte, ušetrili sme približne 10 000 dolárov. A to sú len licencie, a ak zohľadníme náklady na údržbu — ešte viac.
Plány
Na budúci kvartál sme naplánovali prácu na optimalizácii dodávania kódu.
Prechod na prebuild Docker obraz. TFS je skvelý nástroj s množstvom pluginov, ktoré umožňujú integráciu do pipeline, vrátane zostavovania na spúšťač, napríklad Docker obraz. Tento spúšťač chceme nastaviť na ten istý package-lock.json. Ak sa nejako mení zloženie komponentov, ktoré sa používajú na zostavenie projektu — vytvorí sa nový Docker obraz. V budúcnosti sa použije na nasadenie kontajnera so zostavenou aplikáciou. Momentálne to nie je, ale plánujeme prechod na mikroslužbovú architektúru v Kubernetes, ktorá sa aktívne vyvíja v našej spoločnosti a dlhodobo zabezpečuje produkčné riešenia.
Zhrnutie
Vyjadrujem výzvu všetkým, aby sa zbavili Windows, ale nie preto, že by som ju nevedel pripraviť. Dôvodom je, že väčšina Opensource riešení — to je Linux stack. Ušetríte na zdrojoch. Podľa môjho názoru, budúcnosť patrí riešeniam Open Source na Linuxe s silným komunitným zázemím.Profil rečníka Alexandra Sinčinova
na GitHub .
DevOps Conf na RIT++ predložiť príspevok rezervovať My sme rozvíjali DevOps, ako sme mohli. Bolo nás 8 a Vaša bol najlepší v Windows. Neočakávane Vaša odišiel a ja som dostal úlohu vyviesť nový projekt, ktorý dodáva Windows vývoj.
Zdroj: habr.com
