🥇Příběh vzniku cloudové služby, okořeněný kyberpunkem

S rostoucím pracovním stážem v IT začínáte vnímat, že systémy mají svůj charakter. Mohou být laskavé, tiché, nervózní, přísné. Mohou přitahovat nebo odrazovat. Tak či onak, musíte se s nimi "dohadovat", manévrovat mezi "úskalími" a vytvářet řetězce jejich interakce.

A tak jsme měli čest vybudovat cloudovou platformu, což si vyžádalo "přesvědčit" pár subsystémů, aby s námi pracovaly. Naštěstí máme "jazyk API", šikovné ruce a spoustu nadšení.

V tomto článku nebude technický hardcore, ale popsání problémů, se kterými jsme se setkali při vytváření cloudu. Rozhodl jsem se popsat naši cestu jako lehkou technickou fantazii o tom, jak jsme hledali společný jazyk se systémy a co z toho vzešlo.

Vítejte pod článkem.

Začátek cesty

Nedávno byla před naším týmem stanovena úloha – spustit cloudovou platformu pro naše klienty. Měli jsme podporu vedení, zdroje, hardwarovou infrastrukturu a svobodu vybrat technologie pro realizaci softwarové části služby.

Bylo rovněž několik požadavků:

služba potřebuje pohodlný osobní účet;
platforma musí být integrována do stávajícího fakturačního systému;
softwarová a hardwarová část: OpenStack + Tungsten Fabric (Open Contrail), které naši inženýři dokázali dostatečně dobře "připravit".

O tom, jak byla shromážděna tým, vyvíjel se rozhraní osobního účtu a přijímaly se designové rozhodnutí, povíme někdy jindy, pokud bude mít komunita Habr zájem.
Nástroje, které jsme se rozhodli použít:

Python + Flask + Swagger + SQLAlchemy – zcela standardní Python balíček;
Vue.js pro frontend;
interakci mezi komponentami a službami jsme se rozhodli realizovat pomocí Celery nad AMQP.

Abych předešel otázkám o volbě Pythonu, vysvětlím. Jazyk zaujal své místo v naší společnosti a kolem něj se vytvořila malá, ale přesto kultura. Proto bylo rozhodnuto začít budovat službu právě na něm. O to více, že rychlost vývoje v takových úlohách často rozhoduje.

Tak začněme naše seznámení.

Tichý Bill – fakturace

S tímto klukem jsme se znali dlouho. Vždy seděl vedle a něco tiše počítal. Někdy nám předával žádosti uživatelů, vystavoval klientské faktury a spravoval služby. Obyčejný pracovitý kluk. Pravda, byly i komplikace. Byl mlčenlivý, někdy zamyšlený a často — svým vlastním myšlenkám.

Billing je první systém, se kterým jsme se pokusili spřátelit. A první obtíž, na kterou jsme narazili, byla při zpracování služeb.

Například při vytváření nebo odstraňování, úkol se dostane do interní fronty billingového systému. Tímto způsobem je realizován systém asynchronní práce se službami. Pro zpracování našich typů služeb jsme museli "skládat" naše úkoly do této fronty. A zde jsme se setkali s problémem: nedostatek dokumentace.

Podle popisu programového API se tento úkol přece jen vyřešit dá, ale neměli jsme čas na reverzní inženýrství, a proto jsme logiku vytáhli ven a zorganizovali frontu úkolů nad RabbitMQ. Operace se službou je iniciována klientem z uživatelského rozhraní, obalena do "úkolu" Celery na backendu a prováděna na straně billingového systému a OpenStacku. Celery umožňuje poměrně snadno spravovat úkoly, organizovat opakování a sledovat stav. O "celerysticku" se můžete dočíst například, zde.

Také billing nezastavil projekt, na kterém došly peníze. Při komunikaci s vývojáři jsme zjistili, že při výpočtu podle statistik (a my potřebujeme implementovat právě takovou logiku) existuje složitá vzájemná závislost pravidel zastavení. Ale tyto modely se špatně přizpůsobují našim realitám. Také jsme realizovali přes úkoly na Celery, přičemž logiku správy služeb jsme vzali na backend.

Obě výše uvedené problémy vedly k tomu, že se kód trochu nafoukl a v budoucnu se budeme muset zabývat refaktoringem, abychom oddělili logiku práce s úkoly do samostatné služby. Také potřebujeme uchovávat část informací o uživatelích a jejich službách ve svých tabulkách, abychom tuto logiku podporovali.

Další problém — mlčenlivost.

Na část žádostí k API Billy mlčky odpovídá "Ok". Například to tak bylo, když jsme uplatňovali přislíbené platby během testování (o tom později). Žádosti byly správně provedeny a my jsme neviděli chyby.

Musel jsem zkoumat logy, když jsem pracoval se systémem přes UI. Ukázalo se, že samotný billing provádí podobné dotazy, měnící scope na konkrétního uživatele, například admin, předávajícího ho v parametru su.

Celkově, i přes mezery v dokumentaci a drobné chyby API, to proběhlo docela dobře. Logy se dají číst i při vysokém zatížení, pokud víte, jak jsou uspořádány a co hledat. Struktura databáze je spletitá, ale docela logická a v něčem dokonce atraktivní.

Takže, shrneme-li to, hlavní problémy, které jsme měli během interakce, souvisejí se specifiky implementace konkrétního systému:

nedokumentované „funkce“, které nás nějakým způsobem ovlivnily;
uzavřené zdrojové kódy (billing je napsán v C++), což znamená, že není možné problém číslo 1 vyřešit jinak než metodou pokusů a omylů.

Naštěstí má produkt dostatečně robustní API a integrovali jsme do svého uživatelského rozhraní následující podsystémy:

modul technické podpory — požadavky z uživatelského rozhraní jsou „prolity“ do billingu transparentně pro klienty služby;
finanční modul — umožňuje vystavovat faktury aktuálním klientům, provádět odpisy a vytvářet platební dokumenty;
modul pro správu služeb — pro tento modul jsme museli implementovat svůj zpracovatel. Rozšiřitelnost systému nám hrála do karet, a tak jsme „naučili“ Billu nový typ služeb.
Bylo to náročné, ale myslím, že se s Billou nakonec samozřejmě domluvíme.

Procházky po wolframových polích — Tungsten Fabric

Wolframová pole, posetá stovkami drátů, které skrze sebe prohání tisíce bitů informací. Informace se shromažďují do „balíčků“, analyzují se a vytvářejí složité trasy, jako kouzlem.

Toto je doména druhého systému, se kterým jsme se museli spřátelit — Tungsten Fabric (TF), bývalý OpenContrail. Jejím úkolem je spravovat síťové zařízení, poskytující programovou abstrakci nám, uživatelům. TF — SDN, encapsole složitou logiku práce se síťovým zařízením. O samotné technologii existuje slušný článek, například, tady.

Systém je integrován s OpenStackem (o něm se zmíním níže) prostřednictvím pluginu Neutron.

Interakce služeb OpenStack.

S touto systémou nás seznámili kluci z provozního oddělení. Používáme API systému pro správu síťové vrstvy našich služeb. Zatím nám nepřináší vážné problémy ani obtíže (o klucích z OÉ se neodvážím hovořit), nicméně došlo i k některým kuriózním interakcím.

První vypadal takto: příkazy, které vyžadovaly výstup velkého množství dat na konzoli instance při připojení přes SSH, jednoduše „visely“ na připojení, zatímco přes VNC všechno fungovalo správně.

Pro ty, kteří problém neznají, to vypadá docela legračně: ls /root funguje správně, zatímco například top „zamrzá“ naprosto. Naštěstí jsme se již s podobnými problémy setkali. Vyřešilo se to laděním MTU na trase od compute uzlů k routerům. Mimochodem, to není problém TF.

Další problém čekal za rohem. V jeden „krásný“ okamžik zmizela kouzla směrování, prostě tak. TF přestal řídit směrování na zařízení.

Pracovali jsme s OpenStack z úrovně admina a poté jsme přecházeli na úroveň potřebného uživatele. SDN se zdá být „převzato“ s využitím uživatelského rozsahu, ve kterém se akce provádějí. Faktem je, že tento stejný adminský účet se používá pro spojení TF a OpenStack. Při přepínání pod uživatele „kouzlo“ zmizelo. Rozhodli jsme se vytvořit samostatný účet pro práci se systémem. To umožnilo pracovat, aniž bychom narušovali funkčnost integrace.

Krycí formy života — OpenStack

Krycí bytost podivného tvaru obývá blízko wolframových polí. Nejvíce připomíná dítě obr a jedním mávnutím může zničit nás, ale žádné jasné agresivity od něj nevychází. Nevyvolává strach, ale jeho rozměry vzbuzují obavy. Stejně jako složitost toho, co se kolem děje.

OpenStack je jádrem naší platformy.

OpenStack má několik subsystémů, z nichž v současnosti nejvíce používáme Nova, Glance a Cinder. Každý z nich má své API. Nova se stará o výpočetní zdroje a vytváření instancí, Cinder — o správu objemů a jejich snímků, Glance — image služba, která spravuje šablony OS a jejich metainformace.

Každá služba se spouští v kontejneru a zprostředkovatelem zpráv je „bílý králík“ — RabbitMQ.

Tento systém nám způsobil nejvíce nečekaných potíží.

A první problém na sebe nenechal dlouho čekat, když jsme se pokusili připojit další svazek k serveru. Cinder API kategoricky odmítlo tuto úlohu splnit. Přesněji, pokud věříme samotnému OpenStacku, spojení je navázáno, ale uvnitř virtuálního serveru diskové zařízení chybí.

Rozhodli jsme se "obejít" a požádali o stejnou akci Nova API. Výsledek — zařízení se správně připojuje a je dostupné uvnitř serveru. Zdá se, že problém nastává, když block-storage neodpovídá Cinderu.

Další obtíž nás čekala při práci s disky. Systémový svazek se nedařilo odpojit od serveru.

Opět, samotný OpenStack "přísahá", že spojení zrušil a nyní je možné správně pracovat se svazkem samostatně. Ale API kategorie nechtělo provádět operace s diskem.

Zde jsme se rozhodli nezapojovat se příliš do konfliktu, ale změnit pohled na logiku fungování služby. Když už existuje instance, musí existovat i systémový svazek. Proto uživatel zatím nemůže odstranit nebo odpojit systémový "disk", aniž by odstranil "server".

OpenStack je dost složitý komplex systémů s vlastní logikou interakce a složitým API. Naší oporou je dost podrobná dokumentace a samozřejmě metoda pokusů a omylů (kam bychom bez ní došli).

Testovací spuštění

Testovací spuštění jsme prováděli v prosinci loňského roku. Hlavním úkolem bylo ověřit v reálném režimu náš projekt z technického hlediska a z pohledu UX. Publikum jsme vybírali selektivně a testování bylo uzavřené. Nicméně jsme také ponechali možnost požádat o přístup k testování na našem webu.

Samotný test se samozřejmě neobešel bez kuriózních momentů, neboť na tomto naše dobrodružství teprve začíná.

Za prvé, jsme poněkud nepřiměřeně posoudili zájem o projekt a museli jsme operativně přidávat compute-nody přímo během testu. Běžný případ pro klastr, ale i zde byly nuance. V dokumentaci pro konkrétní verzi TF je uvedena konkrétní verze jádra, na kterém byla testována práce s vRouter. Rozhodli jsme se spouštět nody s novějšími jádry. Výsledkem bylo, že TF nedostal trasy z nod. Museli jsme naléhavě vrátit jádra zpět.

Další kuriozita je spojená s funkcionalitou tlačítka "změnit heslo" v osobním účtu.

Rozhodli jsme se použít JWT pro organizaci přístupu do uživatelské sekce, abychom nemuseli pracovat se sezeními. Vzhledem k tomu, že systémy jsou různorodé a široce rozptýlené, spravujeme svůj token, do kterého "zabalujeme" sezení z billingového systému a token z OpenStacku. Při změně hesla token samozřejmě "expiruje", protože údaje o uživateli již nejsou platné a je třeba je znovu vydat.

Utekla nám tato chvíle, a zdrojů, abychom rychle doplnili tento kousek, jednoduše nebylo dost. Museli jsme před samotným spuštěním oříznout funkce.
V současné době provádíme odhlášení uživatele, pokud bylo heslo změněno.

I přes tyto nuance proběhlo testování dobře. Během několika týdnů nás navštívilo přibližně 300 lidí. Měli jsme možnost podívat se na produkt očima uživatelů, otestovat ho v akci a shromáždit kvalitní zpětnou vazbu.

Pokračování příště

Pro mnohé z nás je to první projekt takového rozsahu. Získali jsme řadu cenných lekcí o tom, jak pracovat v týmu, přijímat architektonická a designová rozhodnutí. Jak s omezenými zdroji integrovat složité systémy a uvádět je do produkce.

Samozřejmě, že je na čem pracovat, jak v oblasti kódu, tak na rozhraních integrace systémů. Projekt je poměrně mladý, ale jsme plní ambicí vybudovat z něj spolehlivou a uživatelsky přívětivou službu.

Systémy jsme už dokázali přesvědčit. Bill poslušně počítá, vystavuje faktury a vyřizuje uživatelské dotazy u sebe v kůlně. "Kouzlo" wolframových polí nám zajišťuje stabilní spojení. A jen OpenStack občas dělá vrtochy, křičí něco jako "'WSREP has not yet prepared node for application use". Ale to je úplně jiný příběh...

Před nedávnem jsme spustili službu.
Všechny podrobnosti se můžete dozvědět na našich webu.

Tým vývoje CLO