Vyvíjeli jsme DevOps, jak jsme mohli. Bylo nás 8 lidí a Vaša byl nejlepším specialistou na Windows. Najednou Vaša odešel a já dostal úkol spustit nový projekt, který poskytuje vývoj pro Windows. Když jsem na stůl vyjmenoval celý stack Windows vývoje, uvědomil jsem si, že situace je bolestivá...
Tak začíná příběh Alexandr Sinčinov na . Když z firmy odešel vedoucí specialista na Windows, Alexandr si položil otázku, co teď dělat. Přecházet na Linux, samozřejmě! Alexandr poví, jak se mu podařilo vytvořit precedens a převést část vývoje Windows na Linux na příkladu realizovaného projektu pro 100 000 koncových uživatelů.
Jak snadno a neformálně dodávat projekt v RPM pomocí TFS, Puppet, Linux .NET core? Jak udržovat verzování databáze projektu, když vývojáři poprvé slyší slova Postgres a Flyway, a termín je pozítří? Jak integrovat s Dockerem? Jak motivovat .NET vývojáře, aby se vzdali Windows a smoothií ve prospěch Puppetu a Linuxu? Jak řešit ideologické konflikty, když obsluhovat Windows v produkci není sil, přání ani zdrojů? O tom, a také o Web Deploy, testování, CI, o praktikách používání TFS v existujících projektech, a samozřejmě o zlomených berličkách a funkčních řešeních, v přepisu přednášky Alexandra.
Takže Vaša odešel, úkol je na mně, vývojáři čekají s vidlemi nedočkavě. Když jsem si konečně uvědomil, že Vašu nelze vrátit — pustil jsem se do práce. Nejprve jsem odhadl procento Win VM v našem parku. Počty nebyly v prospěch Windows.
Protože aktivně rozvíjíme DevOps, uvědomil jsem si, že je třeba něco změnit v přístupu k zavedení nové aplikace. Řešení bylo jedno — pokud možno převést vše na Linux. Google mi pomohl — v té době už byl .Net portován na Linux, a já jsem pochopil, že to je řešení!
Proč .NET core ve spojení s Linuxem?
Na to bylo několik důvodů. Mezi „platit peníze“ a „neplatit“ většina vybere druhé — jako já. Licence na MSDB stojí kolem 1 000 $, údržba parku virtuálních strojů Windows se počítá na stovky dolarů. Pro velkou firmu to jsou velké náklady. Proto úspora — je první důvod. Nejsou to nejdůležitější důvody, ale jeden z vážných.
Virtuální stroje Windows zabírají více zdrojů než jejich linuxoví bratři — jsou těžké. Vzhledem k velikosti velké společnosti jsme zvolili Linux.
Systém se jednoduše integruje do stávajícího CI. Považujeme se za progresivní DevOpsáky, používáme Bamboo, Jenkins a GitLab CI, a proto většina našich operací běží na Linuxu.
Poslední důvod je pohodlná údržba. Potřebovali jsme snížit překážky pro "údržbáře" – lidi, kteří chápou technickou část, zajišťují bezproblémovost a obsluhují služby ze druhé linie. Ti už byli obeznámeni se stackem Linux, takže pro ně je mnohem snazší pochopit nový produkt, podporovat ho a udržovat, než vynakládat další prostředky na zvládnutí obdobné funkčnosti softwaru pro Windows.
Požadavky
První a hlavní je pohodlí nového řešení pro vývojáře. Ne všichni byli připraveni na změny, zvlášť po vyslovení slova Linux. Vývojáři chtějí svou oblíbenou Visual Studio, TFS s automatizovanými testy pro sestavení a smoothie. Jak probíhá dodání do produkce – to jim není důležité. Proto jsme se rozhodli neměnit obvyklý proces a ponechat pro Windows vývoj vše beze změn.
Nový projekt je třeba integrovat do stávajícího CI. Rámy už byly a veškerou práci bylo nutné provést s ohledem na parametry systému pro správu konfigurace, přijaté standardy dodání a monitorovací systémy.
Jednoduchost v údržbě a provozu, jako podmínka pro minimální překážky pro všechny nové účastníky z různých oddělení a údržby.
Deadlinem byl včera.
Skupina Win developmentu
Na čem tedy pracoval tým Windows?
Teď mohu s jistotou říci, že IdentityServer4 je skvělá bezplatná alternativa ADFS se srovnatelnými možnostmi, nebo co Entity Framework Core je rájem pro vývojáře, kde se nemusíte trápit psaním SQL skriptů, ale popisujete dotazy do DB v termínech OOP. Ale tehdy, na diskuzi o plánu akce, jsem se na tento stack díval jako na sumerskou klínové písmo, poznával pouze PostgreSQL a Git.
V tu dobu jsme aktivně používali Puppet jako systém správy konfigurace. V většině našich projektů jsme aplikovali GitLab CI, Elastic, vyvažovali vysoce zatížené služby s pomocí HAProxy, sledovali vše s pomocí Zabbix, propojení Grafana a Prometheus, Jaeger, a to všechno běželo na strojích HP s ESXi na VMware. Všichni to známe – klasika žánru.
Podíváme se a pokusíme se pochopit, co se dělo předtím, než jsme se pustili do všech těchto zásahů.
Co bylo
TFS je poměrně mocný systém, který nejen dodává kód od vývojáře k finálnímu produkčnímu stroji, ale také má sadu pro velmi flexibilní integraci s různými službami – pro zajištění CI na multiplatformní úrovni.
Dříve to byly samé okna. TFS používal několik Build-agentů, na kterých se shromažďovalo množství projektů. V každém agentu bylo 3-4 pracovníků, aby se úkoly paralelizovaly a optimalizoval proces. Dále, podle vydávacích plánů, TFS dodával čerstvě upečený Build na Windows-server aplikací.
K čemu jsme chtěli přijít
Pro dodání a vývoj používáme TFS, a spouštíme aplikaci na Linux Application server, a mezi nimi je nějaká magie. Tento Magic Box je sůl nadcházející práce. Než ho rozebere na části, udělám krok stranou a řeknu dvě slova o aplikaci.
Projekt
Aplikace poskytuje funkcionalitu pro operace s předplacenými kartami.
Client
Existovaly dva typy uživatelů. První měl přístup, autorizující se pomocí SSL certifikátu SHA-2. Druhý měl přístup pomocí uživatelského jména a hesla. HAProxy
Dále klientský dotaz vcházel do HAProxy, které řešilo následující úkoly:
primární autorizace;
- terminace SSL;
- ladění HTTP dotazů;
- přesměrování dotazů.
- Ověření certifikátu klienta probíhalo přes řetězec. My jsme –
authority a můžeme si to dovolit, protože sami vydáváme certifikáty klientům služby. Všimněte si třetího bodu, k tomu se vrátíme později.
Backend
Backend plánovali udělat na Linuxu. Backend interaguje s DB, načítá potřebný seznam privilegií a poté, v závislosti na tom, jaká privilegium má autorizovaný uživatel, poskytuje přístup k podepisování finančních dokumentů a jejich zasílání k realizaci, nebo generaci nějaké zprávy.
Úspora s HAProxy
Kromě dvou kontextů, ve kterých každý z klientů pobíhal, existoval ještě kontext identity.
ten umožňuje autorizaci, je to bezplatná a mocná alternativa pro IdentityServer4 ADFS Active Directory Federation Services — Dotaz v identity byl zpracováván v několika krocích. První krok –.
klient se dostal do backendu. dostal se do backendu, který vyměňoval data s tímto serverem a kontroloval existenci tokenu pro klienta. Pokud nebyl nalezen – požadavek se vrátil zpět do kontextu, ze kterého přišel, ale již s přesměrováním, a s přesměrováním šel na identity.
Druhý krok – požadavek se dostal na stránku autorizace v IdentityServer, kde se klient registroval a v databázi IdentityServer se objevil ten vytoužený token.
Třetí krok – klient byl přesměrován zpět do kontextu, ze kterého přišel.
IdentityServer4 má určitou zvláštnost: odpověď na zpětný požadavek vrací po HTTP. Jak jsme se s nastavením serveru snažili, jak jsme studovali dokumentaci, ale pokaždé jsme dostávali původní požadavek klienta s URL, které přišlo po HTTPS, a IdentityServer vracel tentýž kontext, ale s HTTP. Byli jsme v šoku! A celý to jsme převedli přes kontext identity na HAProxy, a v hlavičkách bylo nutné modifikovat protokol HTTP na HTTPS.
V čem je zlepšení a kde jsme ušetřili?
Ušetřili jsme peníze použitím bezplatného řešení pro autorizaci skupiny uživatelů, zdroje, neboť jsme neodčlenili IdentityServer4 jako samostatný uzel do samostatného segmentu, ale použili jsme ho společně se backendem na tom samém serveru, kde běží backend aplikace.
Jak to má fungovat
Takže, jak jsem slíbil – Magic Box. Již rozumíme, že se jistě ubíráme směrem k Linuxu. Pojďme formulovat konkrétní úkoly, které vyžadovaly řešení.
Manifesty Puppet. Abychom dodávali a spravovali konfiguraci služby a aplikace, bylo nutné napsat skvělé recepty. Rolnička s tužkou náležitě ukazuje, jak rychle a kvalitně to bylo provedeno.
Způsob dodání. Standard je RPM. Všichni chápou, že v Linuxu bez něj to nejde, ale samotný projekt po sestavení představoval sadu spustitelných DLL-souborů. Bylo jich asi 150, projekt je dost těžký. Jediným harmonickým řešením je zabalit tuto binární záležitost do RPM a poté z ní rozbalovat aplikaci.
Verzování. Museli jsme často vycházet, a proto bylo nutné rozhodnout, jak pojmenovávat balíčky. To je otázka úrovně integrace s TFS. Build agent byl na Linuxu. Když TFS odešle úkol zpracovateli - worker - na Build agent, předává mu také sadu proměnných, které se dostanou do prostředí procesu zpracovatele. V těchto proměnných prostředí se předává název Build, název verze a další proměnné. Více o tom v části „sestavení RPM balíčku“.
Nastavení TFS se soustředilo na nastavení Pipeline. Dříve jsme na Windows agentech sestavovali všechny projekty pro Windows, a nyní se objevuje Linux agent - Build agent, který je třeba zařadit do skupiny sestavení, obohatit o nějaké artefakty, říci, jaké konkrétní typy projektů budou na tomto Build agentovi sestavovány, a nějakým způsobem modifikovat Pipeline.
IdentityServer. ADFS není naše cesta, podporujeme Open Source.
Podívejme se na komponenty.
Magic Box
Skládá se ze čtyř částí.
Linux Build agent. Linux, protože pro něj sestavujeme - logické. Tato část probíhala ve třech krocích.
- Nastavit worker-y a nikoli jednoho, protože se předpokládala distribuovaná práce na projektu.
- Nainstalovat .NET Core 1.x. Proč zrovna 1.x, když už je k dispozici 2.0 ve standardním repozitáři? Protože, když jsme začali vyvíjet, stabilní verzí byla 1.09, a projekt se rozhodlo udělat pod ní.
- Git 2.x.
RPM-repozitář. RPM balíčky bylo třeba někde uložit. Předpokládalo se, že budeme používat ten samý firemní RPM repozitář, který je dostupný všem Linux hostům. Tak jsme také učinili. Na serveru repozitáře je nastaven webhook , který stahoval požadovaný RPM balíček z určeného místa. Verzi balíčku hlásil Build agent webhooku.
GitLab. Pozor! GitLab se zde nepoužívá vývojáři, ale provozním oddělením pro kontrolu verzí aplikace, verzí balíčků, kontrolu stavu všech Linux strojů a uchovává v něm recepturu - všechny manifesty Puppet.
Puppet — řeší všechny sporné momenty a dodává přesně tu konfiguraci, kterou chceme, z GitLab.
Začínáme se nořit. Jak probíhá dodávka DLL do RPM?
Dodávka DLL do RPM
Představme si, že máme rockovou hvězdu vývoje na .NET. Používá Visual Studio a vytváří vydanou větev. Poté ji nahrává do Gitu, a Git zde - TFS entita, tedy to je repozitář aplikace, se kterým vývojář pracuje.
Poté TFS vidí, že došel nový commit. Jaká aplikace? V nastavení TFS je značka, jaké zdroje má každý Build agent. V tomto případě vidí, že sestavujeme projekt .NET Core a vybírá Linux Build agent z poolu.
Build agent získává zdroje, stahuje potřebné závislosti z repozitáře .NET, npm atd. a po sestavení samotné aplikace a následném balení odešle RPM balíček do RPM repozitáře.
Na druhé straně probíhá následující. Inženýr oddělení údržby se přímo zabývá nasazením projektu: mění verze balíčků v Hiera v repozitáři, kde se uchovává recept na aplikaci, po čemž Puppet spouští Yum, stáhne nový balíček z repozitáře a nová verze aplikace je připravena k použití.
Na slovech je to jednoduché, ale co se děje uvnitř na samotném Build agentu?
Balení DLL RPM
Byly získány zdroje projektu a úkol na sestavení od TFS. Build agent spouští sestavení samotného projektu ze zdrojů.Sestavený projekt je dostupný v podobě mnoha DLL souborů, které jsou zabaleny do zip archivu pro snížení zátěže na souborový systém.
ZIP archiv je umístěn do adresáře sestavení balíčku RPM. Dále Bash skript inicializuje proměnné prostředí, najde verzi Build, verzi projektu, cestu do adresáře sestavení a spouští RPM-build. Po dokončení sestavení je balíček publikován v lokálním repozitáři, který se nachází na Build agentu.
Dále, z Build agenta na server v RPM repozitáři je odeslán JSON požadavek s uvedením názvu verze a buildu. Webhook, o kterém jsem mluvil dříve, stahuje tento balíček z lokálního repozitáře na Build agentu a zpřístupňuje novou verzi k instalaci.
Proč právě takový způsob dodání balíčku do repozitáře RPM? Proč není možné okamžitě odeslat sestavený balíček do repozitáře? Jde o podmínku pro zajištění bezpečnosti. Takový scénář omezuje možnost neoprávněného načítání RPM balíčků cizími osobami na server, který je dostupný všem Linuxovým strojům.
Verzování DB
Na konsilu s vývojem bylo zjištěno, že klukům je bližší MS SQL, ale ve většině non-Windows projektů jsme již plně používali PostgreSQL. Jak jsme se již rozhodli vzdát všeho placeného, začali jsme používat PostgreSQL i zde.
V této části chci popsat, jak jsme prováděli verzování databázového systému a jak jsme vybírali mezi Flyway a Entity Framework Core. Podíváme se na jejich výhody a nevýhody.
Nevýhody
Flyway funguje pouze jedním směrem, my nemůžeme se vrátit zpět — to je významná nevýhoda. Srovnávat s Entity Framework Core lze z hlediska jiných parametrů — z pohledu pohodlí vývojáře. Jistě si pamatujete, že jsme to postavili na první místo a hlavním kritériem bylo nezměnit nic pro Windows vývoj.
Pro Flyway jsme potřebovali nějaký obal, aby kluci nemuseli psát SQL dotazy. Je pro ně mnohem přirozenější pracovat s objekty OOP. Napsali jsme návody na práci s objekty databáze, SQL dotaz se vytvořil a vykonal. Nová verze databáze je hotová, prošla testem — vše funguje.
Entity Framework Core má nevýhodu — při vysokém zatížení generuje neoptimální SQL dotazy, a pokles výkonu databáze může být značný. Ale protože nemáme vysoce zatížený servis, nezapočítáváme zatížení v řádu stovek RPS, přijali jsme tato rizika a delegovali problém budoucím nám.
Výhody
Entity Framework Core funguje z krabice a je pohodlný pro vývoj, zatímco Flyway se snadno integruje do stávajícího CI. Ale my děláme věci pohodlně pro vývojáře :)
Procedura nasazení
Puppet vidí, že došlo ke změně verze balíčků, mezi nimiž je ten, který odpovídá za migraci. Nejprve instaluje balíček, který obsahuje migrační skripty a funkce spojené s databází. Poté se restartuje aplikace, která pracuje s databází. Následuje instalace zbývajících komponent. Pořadí instalace balíčků a spuštění aplikací je popsáno v manifestu Puppet.
Aplikace používají citlivé údaje, jako jsou tokeny, hesla k databázi; to vše se získává v konfiguraci z Puppet master, kde jsou uchovávány v zašifrované podobě.
Problémy TFS
Poté, co jsme se ujistili, že nám všechno skutečně funguje, rozhodl jsem se podívat, co se děje se sestavami v TFS obecně pro oddělení Win vývoje u dalších projektů — jak rychle se sestavujeme / uvolňujeme, a odhalil jsem zásadní problémy se rychlostí.
Jeden z hlavních projektů se sestavuje 12-15 minut — to je dlouho, takto nežijeme. Rychlá analýza ukázala hrozné poklesy I/O, a to na polích.
Analyzoval jsem komponenty a identifikoval tři ohniska. První je „Kaspersky antivirus“, který na všech Windows Build-agentech skenuje zdrojové kódy. Druhý – Windows Indexer. Nebyl vypnutý a na Build-agentech se v reálném čase indexovalo všechno v procesu nasazení.
Třetí – Npm install. Ukázalo se, že ve většině Pipelines jsme používali právě tento scénář. Čím je špatný? Procedura Npm install se spouští při vytváření stromu závislostí v package-lock.json, kde jsou zaznamenány verze balíčků, které budou použity pro sestavení projektu. Nevýhoda spočívá v tom, že Npm install pokaždé stahuje aktuální verze balíčků z internetu, a to zabere značný čas v případě velkého projektu.
Vývojáři někdy experimentují na místním stroji, aby otestovali fungování jednotlivé části nebo celého projektu. Někdy se stalo, že lokálně vše fungovalo skvěle, ale při sestavení, nasazení – nic nefungovalo. Začínáme zjišťovat, kde je problém – aha, různé verze balíčků se závislostmi.
Řešení
- Zdrojové kódy do výjimek AV.
- Vypnutí indexace.
- Přechod na npm ci.
Výhody npm ci spočívají v tom, že vytváříme strom závislostí jednou, a získáme možnost poskytnout vývojáři aktuální seznam balíčků, se kterým může libovolně experimentovat lokálně. To šetří čas vývojářům, kteří píší kód.
Konfigurace
Nyní něco o konfiguraci repozitáře. Historicky používáme Nexus pro správu repozitářů, včetně Interní REPO. Do tohoto interního repozitáře se dodávají všechny komponenty, které používáme pro interní účely, například vlastní monitorovací systémy.
Dále také používáme NuGet, protože lépe kešuje ve srovnání s jinými správci balíčků.
Výsledek
Po optimalizaci Build-agentů se průměrná doba sestavení zkrátila z 12 minut na 7.
Pokud sečteme všechny stroje, které bychom mohli použít pro Windows, ale převedli jsme je na Linux v tomto projektu, ušetřili jsme přibližně $10 000. A to jsou jen náklady na licence, a pokud vezmeme v úvahu údržbu – víc.
Plány
Na následující čtvrtletí jsme naplánovali práci na optimalizaci dodávky kódu.
Přechod na prebuild Docker-obraz. TFS je skvělá věc se spoustou pluginů, které umožňují integraci do Pipeline, včetně sestavení na základě spouštěče, řekněme, Docker-obrazů. Tento spouštěč chceme vytvořit na ten správný package-lock.json. Pokud dojde k jakékoli změně v složení komponentů, které se používají pro sestavení projektu, vytvoříme nový Docker obrázek. Ten je následně použit pro nasazení kontejneru se sestavenou aplikací. V současnosti to není realizováno, ale plánujeme přejít na mikroslužbovou architekturu v Kubernetes, která se aktivně rozvíjí v naší společnosti a již dlouho obsluhuje produkční řešení.
Shrnutí
Vyzývám všechny, aby zahodili Windows, ale není to proto, že bych ji neuměl připravit. Důvodem je, že většina řešení v Opensource je Linuxový stack. Ušetříte tím spoustu zdrojů. Podle mého názoru je budoucnost v řešeních Open Source na Linuxu s silným komunitním zázemím.
Profil mluvčího Alexandra Sinčanova .
— je konference o integraci procesů vývoje, testování a provozu pro profesionály od profesionálů. Právě proto je projekt, o kterém mluvil Alexandr, realizován a funguje, a během dne prezentace proběhly dva úspěšné releasy. Na 27. a 28. května bude ještě více takových případů od praktiků. Ještě se můžete dostat do posledního vlaku a nebo v klidu vstupenku. Setkáme se ve Skolkovo!
Zdroj: habr.com
