Deployment pipeline: jdeme na to v cloudu!

Mohl bych začít ohranou písničkou na téma, že neustálé změny tlačí byznys na překotný rozvoj, což nás nutí k neustálému vydávání release software. To nepopírám. Ale automatizovat celý proces od uložení kódu k vydání do produkce chceme i ze dvou jiných důvodů, kde košile je bližší než kabát. Jednak deployovat opakovaně ručně je úmorná práce se spoustou lidských chyb. A potom, množství software roste exponenciálně s digitalizací a dělením na microservices. Proto nemáme jinou možnost než automatizovat všechny nekreativní činnosti vývoje. Jak nám může ve stavbě deployment pipeline pomoci veřejný cloud?

V prostředí vývoje software nazýváme deployment pipeline systém automatického procesování nového verzovaného kódu z repozitáře do neprodukčních a produkčního prostředí.

Základní kroky od napsání nového kódu po jeho spuštění obvykle označujeme širokým termínem build (ale v některých oblastech tento význam výrazně zužujeme třeba jen na sestavení image). Tyto kroky jsou v zásadě tři:

Pro jistotu, pokud není vývoj software vaším denním chlebem, si řekněme, co který krok představuje.

Kompilace

Vývojář připraví programový kód ve vývojovém nástroji (jako je Eclipse nebo Visual Studio), který mu pomáhá rychle a bezchybně vytvářet logiku kódu. Kód uloží do repositáře (např. GitHub, Bitbucket), kde je kód opatřen verzí, kombinován s prací ostatních vývojářů, uložen do příslušné větve vývoje, spojen s požadovanou změnou apod.

Samotný kód sice hezky ve zvoleném jazyce popisuje, co má software dělat, ale je třeba jej přeložit do instrukcí, které je schopen přebírat a vykonávat procesor. Proto je třeba kód zkompilovat. Toto je již desítky let automatizovaný postup, kdy modul vývojového nástroje zvaný compiler kód překládá a vytvoří balíček spustitelných souborů, knihoven, datových struktur apod. Balíček je uložen v repositáři jako další artefakt.

Do této oblasti patří i vytvoření kontejnerové image, která kompilovaný balíček složí dohromady s potřebnou strukturou software a komponent operačního systému, pro který je image určen. Image je uložen do repositáře (Docker Hub, jFrog Artifactory, AWS ECR, Azure Container Repository atd.).

Testování

Nad software lze v různých fázích vývoje provádět velké množství testů – některé automatizovaně, některé poloautomatizovaně a některé ručně. Čím častější release požaduji, tím více automatických testů, které musí někdo velmi pracně připravit, potřebuji. Mezi známými nástroji pro automatické testování jmenujme například Selenium.

Ještě před kompilováním může být kód testován na kvalitu a bezpečnost nástroji jako je SonarQube, provádí se tzv. continuous code inspection. Naopak po vytvoření balíčku nebo containeru může proběhnout komplexní scan zranitelností balíčku, jako např. Qualys scannerem integrovaným do Azure Security centra nad kontejnery umístěnými v Azure Container registru.

Pomocí unit testů automaticky kontroluji jednotlivé moduly programu, integračními testykontroluji, že je program schopný přenášet data mezi komponentami, funkčními testyověřuji, že software pracuje podle zadání.

Dále, až po deploymentu do daného prostředí/stage, mluvíme o end-to-end testováníz pohledu uživatele a celého prostředí, o akceptačních testech formalizujících možnost posunu do produkce, výkonových testech ověřujících rychlost aplikace v daném prostředí a o penetračních testech zjišťujících, zda prostředí aplikace není napadnutelné.

Deployment

Prostředí aplikace se skládá z více komponent, virtuálních serverů, kontejnerů, frameworků, databází a síťových prvků. Obvykle existuje více prostředí, minimálně testovací a produkční, ale robustní aplikace mívají například prostředí vývojové, dvě testovací, školící, preprodukční a produkční.

Deploymentem se rozumí umístění kompilovaného balíčku software do cílového místa ve filesystému, provedení potřebných konfigurací na prostředí, a pokud je to nutné, rovněž integraci na okolní systémy. Toto je možné provést ručně na jednotlivých strojích pomocí připravených skriptů, které ručně spouštíme, anebo pomocí automatizace, která umožňuje kontrolovaně provést celý deployment z centrálního ovládacího prvku. Jmenujme nejznámější nástroje Jenkins nebo Teamcity.

Automatická deployment pipeline

Pokud se bavíme o automatické deployment pipeline, máme na mysli automatické provedení všech tří výše uvedených kroků (a obvykle mnohem více). Jak bylo zmíněno, potřebujeme k tomu nástroje, které nám umožní automaticky provádět:

• Řízení zdrojových kódů
• Kompilaci kódu a přípravu images
• Testování releasu
• Konfiguraci prostředí
• Monitorování celého procesu

Cílem jsou:

• continuous integration – schopnost integrovat do společného balíku změny kódu od více vývojářů; nezaměňovat s tím, že je při continuous deploymentu potřeba zachovat schopnost neustálé integrace s dalšími aplikacemi;
• continuous delivery – po provedení změny v kódu a po ručním schválení jsem schopen různé verze kódu automaticky nasadit do různých prostředí včetně produkce; deployment je startován ručně ve vhodný moment v rámci release management procesů;
• případně continuous deployment – zahrnuje kompletní automatické nasazení od testů kódu, unit testů až po samotný deployment a případné další funkční i nefunkční testy na nasazeném software v daném prostředí („na jedno kliknutí“).

Možná jste už na podobné „continuous“ termíny alergičtí a nedivím se. Rovněž slovo agileu někoho vzbuzuje pocit, jakoby mu někdo stále opakoval: „…krev, krev, krev..“. V tomto textu bude ale použito pouze jednou. Na trendech a hypech se živí spousta společností, které vymýšlejí a reutilizují moderní pojmy. To ale nic nemění na faktu, že se správnými nástroji a postupy je týmová práce na software efektivnější.

Situace A: Pipeline už máme

Ve velkém množství firem již existuje pro nové projekty alespoň částečně vystavená pipeline, která typicky může vypadat takto:

Nejvíce podceňované nebo obcházené jsou zde obvykle části testování a bezpečnosti, často z prostého důvodu nákladů a časových omezení při vývoji.

Nasazení i takovéto jednoduché pipeline znamená spolupráci vývojových i provozních týmů se zapojením bezpečnosti a samozřejmě byznysu. Vyžaduje odbornost, zkušenost a často týdny práce. Ve velkých prostředích je na provoz a rozvoj deployment pipelines dedikován celý tým specialistů.

Jak to bude vypadat ve veřejném cloudu?

Pokud máme již ve firmě zkušenosti s automatizací, přechod ke cloudovým službám (tak, jak podporujeme zákazníky v ORBITu) probíhá obvykle dvěma cestami:

Cesta nejmenšího odporu

Pokud firma začíná využívat cloudové zdroje, má již vystavenou funkční pipeline a vnímá cloud jako další flexibilní datacentrum, kde čerpá IaaS, PaaS a kontejnerové zdroje, může se velmi dobře používat stávající setup. Běžné nástroje, jako je zmíněný Jenkins, obsahují plug-iny pro Azure i AWS zdroje. Je tedy možné používat veřejný cloud jako další platformu pro další stages.

Cesta nativních nástrojů

Pokud bude pro firmu veřejný cloud majoritní nebo výhradní platformou (odehrává se většinová migrace z on-premisu), je výhodné naopak používat nástroje poskytovatelů cloudu. Microsoft a Amazon zde mají odlišný přístup.

Microsoft dlouhodobě staví své nástroje pro vývoj a CI/CD, které z Team Foundation Server dokonvergovaly k nástroji Azure DevOps, který je možné nasadit i používat jak v cloudu, tak i on-premise.

AWS DevOps nástroje jsou (narozdíl od Azure DevOps) oddělené a je možné využít jen některé z nich.

Pojďme si nabídku obou poskytovatelů krátce představit. Nebudeme srovnávat, ale připomínáme, že obě cloudové platformy poskytují nástroje, kterými lze ovládat cloudové zdroje všech velkých veřejných poskytovatelů, a nabízí tedy možnost deploymentu do multi-cloudového prostředí. (O tématu DevOps si podrobněji přečtěte v tomto článku.)

Microsoft Azure DevOps

Azure DevOps existuje jako verze Server (k instalaci na on-premise) a jako Services (jako služba v prostředí Microsoft Azure, ovšem s možností „self-hosted“ mimo SaaS). Původně vychází z produktů Team Foundation Server a Visual Studio Team Systemspojených s IDE (vývojového nástroje) MS Visual Studio. Aktuální cloudový produkt je přizpůsobený k práci s MS Visual Studiem i s Eclipse, jako hlavní repozitář používá Git a obsahuje nástroje pro celý DevOps cyklus.

Skládá se z pěti modulů:

Azure Boards

• pro plánování práce na vývoji v Kanban stylu

Azure Pipelines

• pro buildování, testování a deployment ve spojení s GitHubem
• podporuje Node.js, Python, Java, PHP, Ruby, C/C++ a samozřejmě .NET
• pracuje s Docker Hubem a Azure Container Registry a umí deployment do K8S prostředí

Azure Repos

• hostovaná Git repository

Azure Test Plans

• podpora testování ve spojení se Stories z Azure Boards

Azure Artifacts

• nástroj pro sdílení artefaktů a balíčků v týmech

Nástroje Azure DevOps jsou navzájem propojeny do jednoho ekosystému a je možné začít používat kterýkoliv modul.

Výsledkem může být třeba tato jednoduchá architektura pro hybridní nasazení webové aplikace s použitím Terraformu:

Při limitech na počet uživatelů a při paralelních pipeline je v omezené míře možné nástroje používat zdarma (do pěti uživatelů, do 2 GB v Artifacts), dále v plánech Basic (bez Test Plans) po pěti dolarech za měsíc za uživatele a spolu s Test Plans (téměř desetinásobně nákladnější plán, ale testování je testování).

Nedávno mě zaujala přednáška na téma využití Azure DevOps nejen pro vývoj software interním a externím zákazníkům, ale jeho použití i pro IT lid, který skriptuje a potřebuje tedy své skripty udržovat, verzovat, synchronně spouštět apod. Každý IT admin je tedy vývojář, který může dobře využít Azure DevOps. Dobrá myšlenka.

AWS continous deployment tools

Amazon poskytuje množství vlastních nástrojů i integrovaných nástrojů třetích stran, ze kterých lze snadno sestavit kompletní automatickou deployment pipeline.

AWS CodeArtifact

• bezpečné úložiště artefaktů
• platby za objem uložených dat

AWS CodeBuild

• služba kompilující zdrojové kódy, provádějící testy a buildující softwarové balíčky
• platby za čas sestavení buildu

Amazon CodeGuru

• machine learning systém vyhledávající chyby a zranitelnosti přímo v kódu (podporuje Java a Python)
• platby podle počtu řádků kódu

AWS CodeCommit

• prostor pro sdílení zdrojových kódů na bázi Gitu
• do pěti uživatelů zdarma

AWS CodeDeploy

• automatizace deployment do služeb EC2, Fargate (serverless kontejnery) i Lambdy, a navíc řízení on-prem serverů
• bez poplatků s výjimkou změn na on-prem serverech a platby za použité zdroje

AWS CodePipeline

• vizualizace a automatizace různých stages v sw release procesu
• platba cca dolar za každou aktivní pipeline

K vykonávání deploymentu včetně infrastructure as a code se přidává použití AWS Cloudformation. Jednotlivé kroky lze trigrovat k provedení s pomocí AWS Lambda. Do ekosystému kontejnerizace je integrován register Amazon ECR a samotný Kubernetessystém Amazon EKS. Další užitečnou službou je např. Amazon ECR image scanningk identifikaci zranitelností v kontejnerových images.

Výsledek může u Amazonu vypadat například takto pro DevSecOps deployment pipeline:

 

Situace B: A co když začínám na zelené louce?

Začít s automatizací bez předchozích zkušeností znamená nutnost zorientovat se v aktuální nabídce nástrojů a vybrat si ten správný mix pro vlastní potřebu. Bez zkušeností ovšem těžko můžete stanovit, co budete v celé pipeline potřebovat, a obvykle dochází ke dvěma extrémům:

• sázka na jistotu a výběr uceleného komerčního řešení v plné výbavě za plnou cenu,
• postupná a úmorná stavba po jednotlivých komponentách s nestabilním výsledkem.

Ani jeden přístup není optimální z hlediska finanční a časové investice.

Začněme v cloudu

Cloudové nástroje zde nabízejí lepší variantu. Obsahují obvyklou cenovou a funkční flexibilitu s možností snadno si nástroje vyzkoušet včetně plné integrace. Jsou sestaveny k okamžitému použití, nevyžadují investice a dají se lehce škálovat. Proto se jedná o rozumný kompromis mezi výše zmíněnými dvěma extrémy. Lze začít v malém a postupně vybudovat velké řešení odpovídající skutečným potřebám vývojových a provozních týmů.

Pokud tedy začínáte v cloudu nebo on-premise od nuly, doporučuji stavět deployment pipeline na SaaS službách poskytovaných v cloudu. Dostanete aktualizované, otestované, navzájem integrované a zabezpečené nástroje za predikovatelné náklady.

A je toto ten DevOps?

V článku jsem se pokusil popsat potřeby a nástroje pro sestavení pipeline z technického pohledu. Samotný Dev/Sec/Ops přístup a náš pohled na to, jak má být implementován, rozebíráme v tomto článku naší série Encyklopedie cloudu: stručný průvodce cloudovým prostředím.

Budu rád, když mi napíšete, jak vypadá vaše pipeline. Dejte vědět, jaká je vaše preference v cloudu – zůstanete u nástrojů, na které jste zvyklí? Preferujete set nástrojů od AWS? Anebo máte dobrou zkušenost s Azure DevOps?