DevOps je v dnešní době skloňován vedle vývoje takřka na každém kroku. Jen málokdo ale tuší, co vše se za tímto termínem ukrývá – včetně lidí, kteří se obdobným oborem zabývají desítky let. Vojtěch Kijenský z české technologické společnosti Cleverlance se tak rozhodl celé toto odvětví přiblížit a popsat, jaký může mít DevOps pro větší i menší firmy přínos.

Vojtěch Kijenský aktuálně v rámci Cleverlance, jejíž většinový podíl vlastní tuzemská skupina KKCG, pracuje pro Škodu Auto, konkrétně na pozicích lead DevOps vývojáře a také architekta pro cloudové servery od Amazonu. Na následujících řádcích popisuje DevOps od jednoduchého nastavení přes možnosti a automatizaci až k vyhodnocení.

***

V počátcích technologického vývoje se projektový tým, který vytvářel aplikace, skládal z vývojářů, analytiků, testerů, systémových administrátorů, síťařů a hardware specialistů. Pokud byli všichni sehraní, fungovalo to. Zjednodušeně: lidé zodpovědní za vývoj vytvořili aplikaci (vývojáři) a předali ji systémovým administrátorům, kteří ji nasazovali (jakkoliv automatizovaně) na hardware v serverovně.

Ne tak dávno přišel ke slovu tzv. agilní přístup k vývoji. Ten se tím rapidně zrychlil a komunikace mezi vývojáři a operations byla čím dál složitější. V podstatě pak stačilo málo aby produkt (nebo jeho verze), na který klient netrpělivě čeká, nebyl vůbec doručen, případně byl doručen se značnou chybovostí. Na vině byla, a většinou stále je, komunikace mezi různými částmi týmu.

Existují tedy vývojáři a operations. Tyto dva tábory se spolu sice možná snaží komunikovat a domlouvat, ale v praxi je to složitější. Každý mluví takříkajíc vlastním jazykem, případně jiným nářečím. To, co je jednoduché z pohledu vývoje, nemusí být implementovatelné na serverech z pohledu infrastruktury. A to, co je snadno řešitelné v infrastruktuře bude zase velký oříšek pro vývojáře.

Co by se stalo, kdybychom měli vývojáře a poslali ho na studia k operations? Nebo z druhé strany, měli někoho z operations a poslali ho na výzvědy k vývojářům? Tímto krokem nakonec vznikne někdo, kdo si může říkat DevOps specialista. Aby si tento titul ale opravdu „zasloužil“, musí pochopit více, než z čeho projekt je a kam se implementuje. Musí změnit zejména způsob myšlení.

Mluvíme o celé sadě postupů, které automatizují a standardizují procesy mezi vývojem softwaru a operations, tak aby bylo možné software tvořit, testovat a vydávat rychleji a spolehlivěji. Základní myšlenkou přitom je, že DevOps není jen technologie, ale celé paradigma vývoje.

Aby to ve firmě fungovalo, je třeba změnit nejen používané aplikace, ale celý přístup k vývoji, testování i nasazování do produkce a vůbec celé uvažování nad tímto procesem.

You build it, you run it!

Dříve by to byla utopie, ale dnes už je možné pronajmout a nechat si spravovat celé clustery s propojením na nejrůznější služby od databází (např. Postgres, MySQL nebo CockroachDB), přes fronty (jako Kaftka či RabbitMQ), analytické systémy (Hadoop), logovací a monitorovací infrastrukturu (Elasticsearch, kibana, grafana) až po nejrůznější IoT služby a REST API. A jak jinak urychlit celý proces od vytvoření až po nasazení aplikace, než tím, že si budete umět tyto aplikace spouštět sami.

Jiný mindset, nové nástroje i nové schopnosti = DevOps

Pokud firma provozuje nějakou aplikaci, je dnes trendem místo vlastní infrastruktury na místě používat vzdálený cloud. Cloudová infrastruktura dnes už může být optimalizovaná pro vysokou dostupnost, pro nízkou latenci, dokonce lze nastavit, že například zákazníci z Čech budou využívat datový cloud v Německu a zákazníci z Francie ve Francii. Moderní cloudy splňují vysoké standardy zabezpečení a další výhodou je možnost používat řadu technologií spojených s jejich provozem jako službu.

V reálu to znamená, že si firmy nemusí držet specialisty, kteří se budou starat o infrastrukturu, její údržbu a instalaci, protože to vše dostanou jako službu, ve které formou tzv. microservices provozují své aplikace. Šetří se tedy (dnes tak nedostatkové) lidské síly i peníze. Důležité je vyvíjet nové aplikace jako cloud native. Nejčastější cloudy, se kterými se setkáte, jsou Azure, AWS a Google Cloud.

Dříve se většina aplikací vyvíjela jako monolitická. Dnes se dělají aplikace z menších částí, které spolu přes jedno rozhraní vzájemně komunikují. Výhoda? Ty monolitické startují třeba čtvrt hodiny, menší aplikace v řádu desítek vteřin. U microservice architektury se vždy snažíme, aby byla nasazovaná jako Platform as a Service (PaaS) nebo Software as a Service (SaaS).

Oblíbenou metodologií je v této oblasti „The Twelve-Factor App“, která je vlastně souhrnem pravidel, která zásadně zpřehlední vývoj, pokud je dodržuje celý tým. Popisuje, jak zacházet s kódem, kde ukládat konfigurace, co se zálohami, buildy, jak na škálování, logy či administraci.

Architektura bez serveru (Serverless) i automatizace

Další velice zajímavý stavební kámen architektury moderních aplikací je „serverless“. Z výše zmíněných malých aplikací se zkrátka vezme část kódu, která může být výpočetně náročná, nebo naopak není potřeba její neustálý běh, použije se k tomu rozhraní, které vystavuje jak AWS (AWS Lambda), tak Azure (Azure Functions), ten si nastartuje malé subprocesy, spočítá výsledky a vrátí je zpět do servisy. Dokáže se škálovat i na úrovni funkcí, které mohou běžet paralelně a nezávisle.

Nezmínili jsme ještě jednu vhodnou vlastnost pro DevOps, a tou je lenost. DevOps si snaží maximálně ulehčit život automatizací – ta je alfou a omegou dnešního DevOps vývoje. Automatizujeme nasazování, pracovní procesy, testování, infrastrukturu, i správu a revizi uživatelských práv a přístupů, prostě všechno.

Kdy s automatizací začít? Pokud je potřeba jakoukoliv činnost opakovat víckrát než jednou.

Abychom mohli vyvíjet rychle a měli jistotu, že jsme nikde nic nerozbili, musíme mít vše pokryté testy, které si píší sami vývojáři. Tato myšlenka dotažena ad absurdum znamená, že by se měl naprogramovat nejdřív test a pak až funkce. Test Driven Development ostatně není v oblasti vývoje softwaru žádná novinka. Nečekat na testery a psát si testy samostatně patří to k tomu výše zmiňovanému DevOps přemýšlení.

Pro automatizaci pracovních postupů používáme nástroje jako Jenkins (CI/CD), Gitlab, Container registry nebo Jira. V praxi to vypadá tak, že vývojář umístí svůj kód do GitLabu, automatická pipeline nad ním spustí unit testy, zkompiluje program a nasadí ho do prostředí na server, kde pak bude kontinuálně monitorovaný. V ideálním případě opravdu vše běží samo.

Automatizace infrastruktury: Infrastruktura jako kód!

Ideální konečný stav je, aby na všech prostředích vše běželo vždy stejně a aby se tato prostředí vytvořila na pouhé kliknutí. Nikdo tedy neinstaluje operační systém, všechno by mělo být naskriptované pomocí různých šablon. Abychom mohli vytvořit infrastrukturu jako kód, musíme nejdříve odstínit aplikaci od hardware. O to se stará například virtualizační nástroj Docker.

Vytvořenou aplikaci vezmeme a nasadíme do nějakého ekosystému – dnes nejčastěji buď Kubernetes nebo OpenShift. Všechno může běžet i on-premise, ale to není tak zásadní, oč v DevOps běží. Jak Kubernetes, tak OpenShift lze provozovat po několika kliknutích. Kubernetes běží hostovaně u všech velkých poskytovatelů.

U infrastruktury máme několik možností. Můžeme „naklikat“ infrastrukturu z pohodlí webového prohlížeče, nebo, a to je více preferované, vytvořit šablonu, podle které bude poskytovatel vytvářet infrastrukturu přímo přes API vrstvu. Nejrozšířenější univerzální šablonový software je Terraform. Obsahuje napojení na všechny velké poskytovatele, nebo je možné použít on-premise servery.

Snazší a mnohdy lepší, je psát tyto šablony v nativních scriptech (u AWS například Cloudformation v YAML a JSON, nebo nově AWS CDK, kde je možné popsat infrastrukturu JavaScriptem, v Javě nebo Pythonu). Tím se možnosti poskytovatele využijí na maximum. Tuto šablonu pak stačí pustit a lze s ní vytvořit identické prostředí i několikrát za sebou (vhodné pro různé prostředí dev/test).

Samotné aplikace lze do prostředí dodávat pomocí všech známých nástrojů od Jenkins, Gitlab, Bitbucket. Aplikaci máme v produkci, ale tím to nekončí. Je potřeba ji začít vyhodnocovat, analyzovat a opravovat chyby, potřebujeme tedy kontinuální metriky a nástroje pro analýzu. Ke sběru logů a jejich vizualizaci lze využít ELK Stack, což je celý balík nástrojů pro tyto účely.

Kibana je nástroj, který umožňuje procházení logů ve vizualizované formě na jednom místě, což perfektně umožňuje zjistit výkon aplikace i případně odhalit, kde je přesně problém, vedle filtrování chyb lze zobrazit i metriky z CPU atd.

Metodika

Dříve tak oblíbený a často používaný vodopádový přístup sice umožňuje pečlivý, ale v žádném případě ne rychlý vývoj. Proto se dnes používají tak často skloňované agilní metodiky, které umožní rozdělit vývoj na malé části a provádět ho po kouscích. Když se nad tím zamyslíte, je to v zásadě podstata celé DevOps filozofie – od infrastruktury až po metodiku a naopak.

Praktikujeme tedy denní standupy a vývoj běží v krátkých sprintech. Důležitá je standardizace celého vývojového procesu, počínaje analýzou, přes vývoj, testování, nasazování až po monitorování výkonu hotové aplikace.

Pro úspěch DevOps projektu je potřeba kombinace odborných znalostí, kvalitní technologie, řemeslné zkušenosti, ale hlavně změna nastavení fungování týmu a uvažování vývojářů. Ale pak to stojí za to. Dobře nastavený projekt pak umožňuje rychlejší inovace, je schopen obratem reagovat na požadavky byznysu, spolupráce týmu je efektivnější, stoupá celková kvalita kódu a výsledkem jsou častější releasy.