Kategórie
Novinky Technológie Zákulisie

Ako sme postavili nový WebSupport za 3 hodiny

Doba čítania: 5 min.

V piatok 20. septembra sme boli svedkami zaujímavej udalosti, kedy sme sa snažili o vygenerovanie celej novej infraštruktúry, pomocou nástrojov konfiguračného manažmentu na novom hárdveri.

Za normálnych okolnosti by sme čerstvo rozbalené servery osadili do racku v datacentre, prepojili a začali inštalovať ručne, jeden za druhým. To je tá jednoduchšia časť.

Potom by nasledovala konfigurácia Openstacku a na ňom vytvorenie virtuálnych serverov.

Virtuálne servery by boli nagenerované z templátov (vzorov), ktoré by sme naklonovali a nimi vygenerovali ďalšie virtuálne servery, (napr. web, db servery a pod). Servery by sa pridali do monitoringu a do skriptov na zálohovanie.

Táto časť by zabrala niekoľko týždňov, či mesiacov.

Pokiaľ by sme potrebovali nasadiť ďalší server, či už virtuálny alebo fyzický, museli by sme zopakovať viacero úkonov (pravdepodobne z veľkej časti ručne, pretože by sme nemali na to vytvorené mechanizmy).

Tento prístup má problém v tom, že všetky skúsenosti a znalosti, ktoré by sme počas tohto procesu nazbierali, by sme mali v hlavách, resp. maximálne v dokumentácií. Robiť to pomocou konfiguračného manažmentu, nám umožňuje efektívnejšie zaznamenať tieto nadobudnuté skúsenosti formou kódu, ktorý je zároveň aj dokumentáciou.

Čo obnáša vygenerovanie spomínanej infraštruktúry? Ide o:

1.

    • Automatizovanú inštaláciu serverov. Pre začiatok sme inštalovali 8. compute uzlov (servery, na ktorých bežia virtuálne servery) na blade serveroch a jeden manažment uzol. Neskôr postupne rozšírime počet compute uzlov na 24.

Inštalácia nového servera zbehla v priemere za 180 – 300 sekúnd. Do 15 minút sme mali preinštalovaných všetkých 9 serverov so základnou inštaláciou Ubuntu 12.04 pomocou projektu FAI (fai-project.org). Servery sa inštalovali cez sieť, takže stačilo ich len nastaviť tak, aby bootovali zo siete.

Inštalácia zo siete predstavuje samostatnú VLAN sieť, na ktorom bežia dhcpd, tftp, dns, ntp a nfs služby, ktorých konfigurácia je taktiež pod správou konfiguračného manažmentu. Stačí pridať tento nový server do konfigurácie a o chvíľu sú vygenerované všetky potrebné konfigurácie pre jednotlivé služby.

2.

    • Automatizovanú konfiguráciu Openstacku, čo znamená, že po štarte serveru sa spustil CFEngine3, ktorý si od policy serveru stiahol všetky zdrojové súbory, čím začal inštaláciu a konfiguráciu Openstacku. Konfigurácia Openstacku bola pri vývoji náročnejšia časť, pretože išlo o rozsiahly a komplikovaný projekt. Zapísanie týchto znalosti do CFEnegine už zabral len zlomok času a jeho vykonanie ešte menej.

Táto časť trvala približne hodinu, počas ktorej sa konfigurovala sieť, vytvorenie blokových zariadení pre virtuálne servery, importoval sa základný obraz Ubuntu 12.04, z ktorého sa inštalovali neskôr ďalšie virtuálne servery.

3.

    • Následuje jedna z najdôležitejších častí – vytváranie logickej infraštruktúry, čo sú vlastne zvirtualizované servery, zabezpečujúce službu zdieľaného hostingu. Jeho štruktúra vyzerá približne takto:

log infrastruktura

Po detekcii úspešnej inštalácie Openstacku – sa compute uzly začali zobrazovať na manažment uzle, čo znamenalo umožniť spúštať jednotlivé virtuálne servery.

V kóde nemáme definované zoznamy serverov ako napr. apache24-php53-1, apache24-php53-2, ale je definovaný typ a počet virtuálnych serverov. Zvýšenie počtu daného typu predstavuje inkrementovanie tejto hodnoty o potrebný počet, čo systém zdeteguje a vytvorí nové inštancie (virtuálne servery).

Virtuálny server sa po svojom štarte začal konfigurovať presne na rolu, na ktorú bol určený. Konfigurovali sa webservery, databázove servery, loadbalancery a pod., v závislosti od jeho mena (máme konzistentnú mennú schému pre servery).

Inštalácia prebiehala, inštalovaním formou balíčkov .deb z nášho repozitára ubuntu balíčkov. Príprava balíčkov so všetkými našimi úpravami (patchmi do rôznych projektov), trvala vyše mesiaca. To je výrazná zmena oproti minulosti, kedy sa nanovo kompilovali ako napr. Apache, pri každom deploymente webservera.

Build Apache Webservera

    Celkovo máme v súčasnosti pripravených 175. balíčkov, z veľkej časti tvorených rôznymi verziami Apache webservera, PHP a ich rozšíreniami.

4.

    Po naštartovaní všetkých potrebných aplikačných serverov, sme si nechali zobraziť stránku na testovacej doméne.

OpenStack2
Kedže sa o celú konfiguráciu stará CFEngine3 a FAI, má celý systém prirodzenú snahu konvergovať do predpísanej konfigurácie a tou je infraštruktúra pre zdieľaný hosting. Prázdne servery boli pre CFEngine3 iba jeden z mnohých stavov, ktorý sa snažil opraviť.

Ak by sa teda stalo náhodou to, že sa servery odchýlia od predpísanej konfigurácie, (napr. sa kompletne premažú) systém sa ich bude snažiť vrátiť do pôvodného stavu. V tomto prípade to znamená, že ich znova nainštaluje a nakonfiguruje úplne automaticky.

Táto konvergencia je aplikovaná naprieč celou infraštruktúrou, a týka sa aj vyšších vrstiev (virtuálne servery, aplikačné servery). Ak napríklad virtuálny server, ktorý má na starosti PHP 5.5 z nejakého dôvodu nebeží, systém sa postará o jeho spustenie a konfiguráciu. Ak na tomto serveri nebeží napríklad Apache webserver, systém ho naštartuje.

Taktiež to znamená, že sme schopní zobrať program, ktorí sme pre CFEngine3 vytvorili a zreprodukovať rovnakú infraštruktúru aj na inom hárdveri. Plánujeme takto napríklad využiť časť starej infraštruktúry na Openstack, určený na vývoj a testovanie.

Ďalším z dôsledkov je aj to, že pre administrátorov už nemá zmysel chodiť po serveroch a ručne vykonávať zmeny, pretože tie sa dostanú vždy do pôvodného stavu. Dokonca predpokladáme, že vôbec nebude nutné časom chodiť na produkčné servery. Čím výrazne eliminujeme ľudský faktor.

Kedže však zmeny robiť treba, museli sme sa zamerať na manažmenť zmien a ako zmeny nasadzovať do produkcie. Kedže celý kód je manažovaný cez GIT (systém na správu zdrojových kódov) je v ňom automaticky zahrnutá aj dokumentácia zmien. Na samotný change management a QA sa určite zameráme v niektorom budúcom článku.

Uzavreli sme teda jednu z ďalších dôležitých kapitol tohto projektu. Postavili sme pevné základy, na ktorých môžeme stavať ďalej, a preto sa pomaličky začíname pripravovať na migráciu všetkých naších služieb, o čom budete samozrejme vopred informovaní.

Zdroj fotografií: Twitter

16 odpovedí na “Ako sme postavili nový WebSupport za 3 hodiny”

velmi pekne!
z mojej skusenosti su dolezite robit vsetky zmeny len cez management engine, casom adminov vzdy napadne robit veci rychlo, a potom to ide mimo management a obycajne ked zbehne compliance check tak sa to dobabre:) a ozaj dobre je mat jenkins na testovanie modulov + ozaj dobre testovat deployment,removal a {move ; restore} ..to su vsetko veci kde cloveka ani nenapadne co sa vsetko moze podiat:)

este nie, ale urcite budeme pretoze mame mnozstvo moznosti na ladenie vykonu.

Pokial by sme vsak vzali do uvahy iba papierove parametre CPU, tak jeden core je 2x vykonejsi ako core ktory pouzivame bezne.

skor mi islo o porovanie Ubuntu vs Debian (pokial viem, ten ste pouzivali predtym) .. ci nebudete mat problem s vykonom samotneho OS ..

80% 3rd party enterprise-close sw je rh oel only (mozno este suse sem tam) ziadne debiany sa nehraju, o triedu lepsia dokumentacia k rh oel oproti *buntu to su dve co ma napadli v 3tej sekunde

Pri deploymente OpenStacku su prave nehra na RHEL a SUSE, kedze Ubuntu Server je distribucia, ktora ma uz dlhsiu dobu oficialne repositare pre OpenStack. Deploynut OpenStack v produkcnej kvalite znamena niekolko mesiacov testovania a prace, kedze je to stale velmi mlady, komplexny a s kazdou verziou meniaci sa sotware. Nasadit to na RHEL by znamenalo dalsie mesiace navyse badania a trhania si vlasov, kedze Red Hat zaciatkom roka o OpenStacku nechyroval a neexistovala skoro ziadna dokumentacia. Nehovoriac o tom je ze nasadzovat cloudove riesenie ktore je zadarmo, ktore si chlapci supportuju sami a potom tam dat RHEL, kde treba platit licencie nejde akosi dokopi. Dalsi argument pre Ubuntu je, ze WebSupport sa snazi ceny produktov drzat na co najprijatelnejsej urovni. RHEL je naozaj super pre enterprise, kde sa tam najimaju ludia, ktory nevedia pouzit ani grep a potrebuju velmi casto pomoc ich supportu. Ludia z Websupportu su ale ina liga a takyto Enterprise support by bolo platit zbytocne (viem o com hovorim, pracujem v taketo Enteprise spolocnosti a tieto supporty poznam).

ale prd … zas OpenStack nie je az taky dolezity software, aby sa kazdy z RedHatu koli tomu posral a ta sprisahanecka teoria, ze by to nefungovalo, ta je tiez na prd.
ale ja mam moju vlastnu sprisahanecku teoriu. ja totizto tod mam tiez kopec knih o debiane, de sa dozvies ako si robit custom deb baliky, ale nemam a ani nevim o nejakej dobrej dokumentacii toho isteho pre rpm bazirovane distribucie, mozno su, ale mna to nezaujima, v kazdom pripade vychadzam z teho, ze oni poznaju deb baliky a preto budu pouzivat bud debian alebo ubuntu a cele to teoretizovanie o tom, ci aj SuSE by islo je potom odveci, lebo to by sa moseli koli tomu ucit nove veci (pre custom baliky toho apaca co tam amateri kompilovali).

Mám rád Vašu firmu. Dakedy som bol u Vás na prijímacom pohovore, na ktorom som neuspel, ale poradili ste mi a to pre mňa zatiaľ žiadna firma nespravila. Nechcem, aby to vyzeralo tak, že sa Vám snažim robiť reklamu. Jednoducho som vďačný a nebojím sa to vyjadriť.

Pridaj komentár

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *