Univerzita Hradec Králové Fakulta informatiky a managementu

Transkript

1 Univerzita Hradec Králové Fakulta informatiky a managementu katedra informačních technologií Automatizace vývoje softwaru pomocí samoobslužného portálu a volitelného schvalovacího procesu pomocí cloudového řešení Diplomová práce Autor: Bc. Tomáš Hradecký Studijní obor: Aplikovaná informatika Vedoucí práce: Ing. Aleš Komárek Hradec Králové duben 2017

2 Prohlášení Prohlašuji, že jsem diplomovou práci vypracoval samostatně a uvedl jsem všechny použité prameny a literaturu. V Hradci Králové dne 27. dubna 2017 Bc. Tomáš Hradecký

3 Poděkování Rád bych zde poděkoval Ing. Aleši Komárkovi za odborné vedení práce, podnětné rady a čas, který mi věnoval.

4 Anotace Tato diplomová práce je zaměřena na zhodnocení postupu přípravy prostředí pro testování softwarových aplikací a možností využití cloudových technologií pro automatizaci tohoto procesu. V této práci je vysvětlen pojem cloud společně s klíčovými pojmy spojenými s cloudovými technologiemi a nástroji pro tvorbu aplikačního katalogu a workflow. Práce obsahuje též analýzu pracovního postupu přípravy testovacího prostředí a návrh postupu s cloudovým řešením. Bylo provedeno prozkoumání a srovnání cloudových řešení společně s nástroji pro aplikační katalog a workflow za účelem výběru vhodného řešení. V praktické části je popsán vybraný nástroj pro aplikační katalog a použit pro vytvoření testovacího prostředí. Annotation Title: Automation of software development using self-service portal and optional approval process using cloud solution This master thesis is focused on evaluation of testing environment preparation process and possibility to use cloud technology for automatization of this process. This thesis explains cloud technology with key concept related to cloud technology and tools for create application catalog and workflow. It also describes analyze of testing environment preparation process and design of process with cloud technology. Multiple cloud technology, tools for workflow and application catalog were described and compared. In practical part,there is described chosen tool for application catalog and is used for prepare testing environment.

5 Obsah 1 Úvod 1 2 Technologie Virtualizace Hardwarová virtualizace Softwarová virtualizace Síťová virtualizace Desktopová virtualizace Aplikační virtualizace Cloud Privátní cloud Veřejný cloud Hybridní cloud Infrastructure as a Service (IaaS) Software as a Service (SaaS) Data as a Service (DaaS) Platform as a Service (PaaS) Containers (Kontejnery) Docker Orchestrace Konfigurační management Infrastructure as a Code (IaaC) Puppet SaltStack Nástroje OpenStack Architektura

6 Obsah Moduly VMware vcloud Suite Architektura VMware vcloud Director VMware vcloud Connector vcloud Network Verze Licencování Aplikační katalog Účel aplikačního katalogu VMware vapp VMware Horizon Apps OpenStack HEAT OpenStack Murano Cloud Service Broaker (CSB) Schvalovací workflow Účel schvalovacího workflow vcenter Orchestrator Mistral Congress Analýza Prostředí pro nasazení Analýza aktuálního procesu Návrh nového procesu Hlediska pro srovnání Srovnání Srovnání cloudových platforem Hlediska pro srovnání Srovnání Srovnání nástrojů aplikačního katalogu Hlediska pro srovnání Srovnání Srovnání nástrojů pro workflow Hlediska pro srovnání

7 Obsah Srovnání Realizace Vybrané nástroje Architektura Proces objednání prostředí Implementace Průběh Testování Testovací Aplikace Shrnutí výsledků 77 7 Závěry a doporučení 79 Literatura 81

8 Seznam obrázků 2.1 Architektura bare-metal virtualizační technologie, převzato a upraveno dle: [1] Architektura hosted virtualizační technologie, převzato a upraveno dle: [1] Znázornění cloudové technologie, převzato z: [6] Porovnání správy cloudových služeb, převzato a upraveno dle: [13] Srovnání architektury kontejnerizace s virtualizační technologií, převzato a upraveno dle: [18] Architektura platformy OpenStack, převzaton a upraveno z: [15] Architektura platformy VMware vcloud Suite, převzato a upraveno z: [31] Licence VMware vrealize Suite, převzato a upraveno z: [35] Edice VMware vcloud Suite, převzato a upraveno z: [35] Architektura VMware Horizon, převzato a upraveno z: [42] Architektura modulu Murano OpenStack platformy, převzato a upraveno z: [46] Logická architektura CSB Workflow vcenter Orchestrator, převzato z: [38] Architektura modulu Mistral, převzato a upraveno z: [40] Aktuální proces přípravy testovacího prostředí Návrh procesu přípravy testovacího prostředí Logická architektura navrženého prostředí Proces objednání prostředí

9 Seznam tabulek 2.1 Porovnání veřejného a privátního cloudu, převzato a upraveno dle [9] Nástroje konfiguračního managementu a jejich přístupy k definici konfigurací Tabulka srovnání procesů přípravy testovacího prostředí Tabulka srovnání cloudových platforem Tabulka srovnání nástrojů pro aplikační katalog Tabulka srovnání nástrojů pro aplikační katalog Tabulka srovnání nástrojů pro workflow

10 1 Úvod Proces testování softwarových aplikací vyžaduje vhodné prostředí a způsob jak je připravovat, aby testování mohlo probíhat efektivně. Bez vhodného automatizovaného přístupu se jedná o manuální proces plný komunikace mezi odděleními a čekáním na provedení příslušného kroku jiným oddělením. Cloudové technologie v dnešní době nabízejí velice široké možnosti využití a díky funkcionalitám jako je aplikační katalog je možné je s úspěchem využít i pro řešení následující problematiky. Tato práce se zaměřuje na prozkoumání problematiky cloudových technologií a nástrojů pro tvorbu aplikačního katalogu pro účely přípravy testovacích prostředí, kam by přinesli značnou automatizaci. Obsah diplomové práce je kromě úvodu členěn do 6 kapitol. V následující kapitole 2 jsou popsány teoretické principy cloudových i dalších technologií spjatých s tématem. Obsahem kapitoly 3 je popis dvou vybraných cloudových platforem, stejně tak jako nástrojů pro řešení aplikačního katalogu a workflow. V kapitole 4 je provedena podrobná analýza procesu přípravy prostředí pro testování softwarových aplikací a srovnání s nově navrženým procesem s využitím cloudových platforem a aplikačního katalogu. Součástí je i srovnání nástrojů aplikačního katalogu a workflow. Realizace popisující navržené řešení pro automatizaci přípravy testovacích prostředí a způsob implementace je popsána v kapitole 5. V kapitole 6 jsou zhodnoceny výsledky dosažené při zhotovování práce. V závěrečné kapitole 7 jsou poté uvedeny závěry a doporučení získané v průběhu práce. V obsahu diplomové práce jsou používány některé názvy v původním anglickém znění. K tomuto rozhodnutí mě vedla především skutečnost, že v technické literatuře i praxi jsou tyto pojmy běžně zmiňovány v původním znění, což zvyšuje jednoznačnost. 1

11 2 Technologie V následující kapitole jsou popsány jednotlivé technologie vztahující se k řešené problematice, které je nutné znát a chápat pro správné porozumění dané oblasti. Budou zde vymezeny pojmy používané ve zbylé části této práce. 2.1 Virtualizace Technologie virtualizace není ve světě informatiky nijak nová. Počátky virtualizace se objevovaly již v 60. letech 20. století. Hlavní myšlenka spočívá, jak samotný název napovídá, ve vytváření a spravování virtuálních počítačů, v praxi označovaných zkratkou VM z anglického Virtual Machines. Jedním z hlavních problémů v oblasti informačních technologií před příchodem virtualizace bylo nevhodné využívání výpočetních zdrojů. Jednotlivé služby měly často vyhrazené servery, například kvůli bezpečnosti a nebyla výjimkou skutečnost, kdy bylo efektivně využíváno přibližně 10% výpočetních zdrojů. Taková situace byla velice nevhodná a virtualizace slibovala díky své technologii až 80% využití výpočetních zdrojů serverů. Při virtualizaci jsou vytvářeny VM v rámci fyzického serveru a ty se dělí o reálné výpočetní zdroje fyzického serveru, na kterém jsou spuštěny. Díky této technologii je možné mnohem efektivněji využívat dostupné výpočetní zdroje, jelikož jednotlivé služby mají stále dedikované servery, ale ty už jsou pouze virtuální. Je tak zachována bezpečnost vyplývající právě z oddělení jednotlivých služeb. V dnešní době se již kromě virtualizace serverů využívá i virtualizace v oblasti síťových prvků, a to jak routerů a switchů tak i například firewallů. Technologii virtualizace lze rozdělit na dva typy, kterými jsou hardwarová a softwarová virtualizace. Oba typy jsou popsány dále a jsou uvedeny dostupné aplikace jako 2

12 Virtualizace příklady. Jelikož u obou typů je hlavní vrstvou tzv. hypervisor je virtualizace nazývaná jako hypervisor based, přeloženo do češtiny založena na hypervisoru. Toto označení se využívá především pro odlišení tzv kontejnerové virtualizace, container based virtualization, která bude popsána dále. [1] [30] Hardwarová virtualizace Prvním popsaným typem virtualizace je hardwarová, známá také jako bare-metal, což označuje její nasazení přímo na samotný serverový hardware. U hardwarové virtualizace se na dotyčný server neinstaluje žádný operační systém. Právě z důvodu absence operačního systému je zde minimální softwarová vrstva mezi hardwarem serverů a vytvářenými VM, proto je tento druh virtualizace stabilnější než dále zmíněná softwarová virtualizace. Vyšší stability je dosaženo tím, že vše je umístěno tak blízko k hardwaru serveru jak jen to jde. Další výhodou jsou nižší ztráty výpočetního výkonu pro funkci virtualizace, jelikož hardwarová virtualizace nevyžaduje takové zdroje jako operační systém potřebný pro softwarovou virtualizaci. Výpočetní zdroje jsou zde delegovány samotnou virtualizační technologií bez omezení systémem. Na obrázku 2.1 jsou znázorněny jednotlivé vrstvy virtualizační architektury a jak na sebe navazují. První vrstva je server hardware. Tato vrstva označuje veškeré fyzické stroje, jejichž zdroje budou k dispozici pro virtualizaci. Je vhodné zmínit, že zdroje nemusí pocházet pouze z jednoho fyzického server. Je možno pomocí softwarových řešení vytvořit pro virtualizaci prostředí, které disponuje zdroji mnoha fyzických serverů. Tato technologie je dnes běžně využívána a může být implementována jako součást následující vrstvy Hypervisor, samotná virtualizace by bez této funkcionality nebyla zdaleka tak silným nástrojem. Vrstva hypervisor označuje software spravující samotný serverový hardware, někdy je tato vrstva označována také jako Virtual Machines Monitor, zkráceně VMM. Fyzická vrstva je tak překryta abstraktní vrstvou, která umožňuje hypervisoru delegovat fyzický hardware pocházející z jednoho nebo více fyzických serverů mezi několik jednotlivých virtuálních strojů, jejichž počet je omezen pouze dostupnými výpočetními zdroji. Pro každý virtuální stroj je vytvořen virtuální hardware zastupující celý server včetně všech potřebných komponent, který disponuje nakonfigurovanými zdroji. [1][30] 3

13 Virtualizace Hardware (bare-metal) virtualization Virtual Machine #1 Virtual Machine #2 Virtual Machine #3 Virtual hardware Virtual hardware Virtual hardware Hypervisor (VMM) Server Hardware Obrázek 2.1: Architektura bare-metal virtualizační technologie, převzato a upraveno dle: [1] Příkladem hardwarové virtualizace je například aplikace VM Ware ESXi. Po instalování na server je ovládání dostupné prostřednictvím webové konzole, která poskytuje všechny funkce zmíněné aplikace. Následující výčet některých funkcí slouží především pro upřesnění čeho všeho se technologie virtualizace dotýká. správa VM zálohování kontrola stavu hardwaru (teploty, vytížení...) síťování zabezpečení alokace zdrojů Softwarová virtualizace Druhým typem je virtualizace softwarová. Tento typ vyžaduje operační systém plnící roli hostitele, do kterého je technologie nasazena a vytváří tak VM až nad samotným operačním systémem. Rozdělování veškerých výpočetních zdrojů je zde 4

14 Virtualizace spravováno hostitelským operačním systémem, a je proto velmi důležité, aby daný operační systém splňoval tuto úlohu co nejlépe a s co nejnižšími nároky na svou funkci, kterými by upíral výpočetní zdroje dostupné pro virtualizaci. Architektura softwarové virtualizace je znázorněna na následujícím obrázku 2.2. Od virtualizace hardwarové se liší pouze přítomností vrstvy operačního systému mezi vrstvami server hardware a hypervisor. Funkce jednotlivých vrstev jsou shodné s funkcemi v hardwarové virtualizace. Veškeré podstatné rozdíly byly již zmíněny v části ohledně hardwarové virtualizace. [1][30] Software (hosted) virtualization Virtual Machine #1 Virtual Machine #2 Virtual Machine #3 Virtual hardware Virtual hardware Virtual hardware Hypervisor (VMM) Host Operating System Server Hardware Obrázek 2.2: Architektura hosted virtualizační technologie, převzato a upraveno dle: [1] Pro softwarovou virtualizaci jsou dostupné například produkty Oracle Virtual Box nebo VM Ware Workstation. Tyto produkty se však liší funkcionalitou. Oba produkty nabízejí virtualizaci, která nabízí alternativu k dual-boot funkci pro výběr požadovaného operačního systému. Produkty jsou vhodné pro zkoušení nových verzí operačních systémů a jejich funkcí před skutečným nasazením. Při používání těchto aplikací se spouští VM jako aplikace v rámci běžícího operačního systému. Poněkud odlišným typem softwarové virtualizace je produkt od společnosti Microsoft s názvem Hyper-V pracující jako modul v rámci serverového operačního systému Microsoft Windows Server. Tento produkt nabízí virtualizaci použitelnou v serverovém prostředí, která nicméně trpí nevýhodami zmíněnými v části o hard- 5

15 Virtualizace warové virtualizaci. [1][30] Síťová virtualizace Síťová virtualizace umožňuje spravovat dostupnou šířku pásma rozdělením do nezávislých komunikačních kanálů, které jsou přiřazeny jednotlivým cílům. Nejznámější a běžně používanou síťovou virtualizační technikou je VLAN (Virtual Local Area Network), která vytváří oddělení logické a fyzické síťové topologie. [1][30] Momentálně je častým tématem síťová virtualizace v podobě SDN (Software Defined Netwrok), neboli softwarové definované sítě. V tomto přístupu se virtualizují i jednotlivé síťové prvky s cílem vytvořit co nejvhodnější síťovou topologii, která bude výkonná, odolná, snadno spravovatelná, programovatelná a automatizovaná.[2] Desktopová virtualizace Desktopová virtualizace je známá v češtině jako virtualizace pracovní plochy. Použití desktopové virtualizace umožňuje vzdálené připojení k desktopu, který je spuštěn na VM. Desktopová virtualizace má několik výhod, mezi které patří například schopnost centralizace desktopového nasazení a tím snížení nákladů na distribuovanou správu, protože uživatelé přistupují na své centralizované desktopy z mnoha nespravovaných zařízení prostřednictvím klientské aplikace.[1][30] Aplikační virtualizace Aplikační virtualizace využívá stejného principu jako desktopová virtualizace, ale místo poskytování prostředí k funkci celého operačního systému, odděluje aplikační virtualizace funkci aplikace od operačního systému. Virtualizací je přetvářen distribuovaný model aplikace tak, že je spustitelný na všech stanicích se shodným typem operačního systému (Windows/Linux/MacOS). Takto virtualizované aplikace si navíc jsou schopné k sobě přibalit další potřebné balíčky. Aplikace je tak všude, kde je spuštěna naprosto shodná.[1][30] 6

16 Cloud 2.2 Cloud Cloud jakožto technologie bývá často zaměňována s virtualizací. Tato kapitola tedy bude zaměřena převážně na vysvětlení důvodů proč k tomu dochází a vysvětlení rozdílů mezi těmito technologiemi. V překladu toto slovo znamená mrak. Tento pojem je až překvapivě výstižný, jelikož cloudové technologie pojímají mnoho různých funkcí a není tak nijak snadné vytvořit vhodnou definici. Nicméně je nutné si tento pojem definovat, proto budou uvedeny dvě definice, souhrn mnoha definic cloudu lze nalézt v článku. [3][30] "A Cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resources based on service-level agreements established through negotiation between the service provider and consumers" [4] První definice říká, že cloud je typ distribuovaného a paralelního systému skládajícího se z propojených virtualizovaných počítačů. Tyto počítače jsou prezentovány jako jednotný výpočetní zdroj dle dohod uzavřených mezi poskytovatelem a zákazníkem. "...the key thing we want to virtualize or hide from the user is complexity...all that software will be virtualized or hidden from us and taken care of by systems and/or professionals that are somewhere else - out there in The Cloud" [5] Druhá definice zmiňuje, že klíčové je co nejvíce skrýt komplexitu, o kterou se starají odborníci na straně poskytovatele služeb. Každá definice popisuje část cloudu jakožto celku, je proto vhodné spojit obsah obou do jedné, která by více informovala o celé problematice. Taková definice by mohla znít například takto. Cloud je způsob nabídky informačních služeb zákazníkovi založených na virtualizaci v podobě cílového produktu skrývající komplexitu technologie, která tyto služby poskytuje. Pro znázornění následuje obrázek

17 Cloud Obrázek 2.3: Znázornění cloudové technologie, převzato z: [6] Nyní je již možné říci hlavní rozdíly cloudu a virtualizace, které by měli zamezit jejich záměně. Na prvním místě se jedná o fakt, že ačkoli virtualizace figuruje v obou technologiích, tak v případě cloudu se nejedná o konečnou podobu, zatímco u virtualizace ano. U cloudových technologií je virtualizace spojena právě se skrýváním komplexity a nabídkou služeb, které nejsou tvořeny pouze samostatnými VM, ale i něčím navíc. Souhrnně lze tedy konstatovat, že cloud je technologie využívající technologii virtualizace a zároveň ji obohacuje o své funkcionality. Jak tedy bylo zmíněno, cloud je především o nabídce výpočetních technologií v podobě služby cílovému zákazníkovi. Takových služeb je několik a ty nejběžnější budou dále popsány a vysvětleny Privátní cloud Privátní cloud je typ, který je vyvinut dle daných požadavků společnosti a to převážně pro její interní použití. Takový cloud, však nemusí nutně být nasazen v rámi společnosti, pro kterou je vyvíjen. Implementaci může společně s hostováním platformy poskytovat společnost zabývající se cloudovými technologiemi. Tato možnost je vhodná v případě, kdy se společnost rozhodne získat cloudové řešení jako hotový produkt místo toho, aby se o nasazení pokusili silami vlastních techniků. Motivací pro privátní cloud mají společnosti hned několik. Předně je to maxi- 8

18 Cloud malizace a optimalizace využívání stávajících zdrojů. Dále pak z důvodu zabezpečení zahrnující ochranu osobních údajů, a také, jelikož přenos dat mezi veřejným cloudem a interní informační infrastrukturou je stále znatelný. Opomíjena by neměla být ani skutečnost, kdy společnosti vyžadují plnou kontrolu nad kritickými aktivitami. Závěrem je vhodné zmínit, že často se privátní cloud využívá i pro výzkumné a výukové účely v akademických kruzích.[8][10][30] Veřejný cloud Veřejný cloud není na rozdíl od privátního řešen na míru zákazníka. V oblasti veřejného cloudu jsou služby nabízené širokému spektru zákazníků prostřednictvím internetu. Veškerá hardwarová infrastruktura je u samotného poskytovatele, který má plnou kontrolu nad jeho provozem, cenami, politikou atd. Mezi klasické a nejznámější příklady poskytovatelů veřejných cloudů patří Microsoft Azure, Amazon WS, Google Apps.[8][10][30] Porovnání veřejného a privátního cloudu je shrnuto v následující tabulce 2.1 Tabulka 2.1: Porovnání veřejného a privátního cloudu, převzato a upraveno dle [9] Veřejný Cloud hostovaný poskytovatelem služeb určen pro více zákazníků využívá společnou infrastrukturu vhodné pro data která nejsou citlivá přístup přes internet Privátní cloud hostovaný poskytovatelem nebo zákazníkem určen pro jediného zákazníka (společnost) nevyužívá společnou infrastrukturu vhodné i pro citlivá data přístup přes internet nebo privátní síť Hybridní cloud Hybridní cloud je kombinace výše zmíněných typů, tedy veřejného a privátního cloudu. Hybridní cloudy jsou využívány k optimalizaci zdrojů a zlepšení hlavních procesů s podporou periferních funkcí cloudu. [8][10][30] 9

19 Cloud Infrastructure as a Service (IaaS) Dříve označováno jako HaaS, což je zkratka anglického Hardware as a Service. Jedná se o cloudovou službu, která vznikla jako výsledek rapidního nástupu hardwarové virtualizace a IT automatizace umožňující zákazníkovi zakoupení hardwaru či celého virtuálního data centra. Nabízená služba nepostrádá ani potřebnou flexibilitu či škálovatelnost. Vše je pak zákazníkovi účtováno metodou známou jako pay-as-you-go, kde zákazník zaplatí jen to, co opravdu spotřeboval. Společnosti si tak mohou pronajmout požadované zdroje místo jejích zakoupení. Při využívání IaaS mají zákazníci možnost horizontální škálovatelnosti, kdy jedna aplikace je zpracovávána na více VM a zátěž je mezi ně rozkládána. Díky tomu je možné dynamicky měnit požadovaný výkon například pro společnosti s vysokým vytížením webových serverů v určitou denní dobu. Jedná se tedy o vhodné řešení pro vlastníky licencí k softwaru, kteří se nechtějí starat o hardware. Příkladem těchto služeb jsou pak například Amazon WS nebo Microsoft Azure. [11][12][30] Software as a Service (SaaS) Jedná se o model cloudové služby, kde jsou nabízené softwarové aplikace, jako služba dostupná přes síť internet místo lokálně instalovaných aplikací. Nabízené aplikace jsou spouštěné na hardwaru poskytovatele. Nejznámějšími poskytovateli jsou například salesforce.com s nabízeným CRM systémem a Google Apps. U placených služeb se běžně platí licence za měsíc používání. U této služby nemá zákazník žádnou kontrolu nad infrastrukturou zpracovávající dané služby. Tato služba je tedy vhodná pro zákazníky vyžadující přístup k aplikačnímu softwaru bez omezení lokality odkud přistupují. [11][12][30] Data as a Service (DaaS) Jedná se o službu nabízející datové úložiště v prostředí cloudu. Je možné ukládat data různých typů a operovat s nimi, jako by byly uloženy lokálně. Mezi nabízené patří i specializované databázové servery, které ale mohou mít omezené funkcionality, například absenci spojovacích join operací. 10

20 Containers (Kontejnery) Příkladem jsou Amazon SimpleDB, Google BigTabble, Apache HBase. [11][12] Platform as a Service (PaaS) Jedná se o službu složenou z kombinace výše zmíněných služeb, kdy se nabízí řešení v podobě komplexní platformy. Nabízené řešení je většinou individuální pro každého poskytovatele. Cílem je poskytnout službu poskytující komplexní prostředky pro celý životní cyklus vývoje aplikací zákazníka dostupnou prostřednictvím sítě internet. Může se jednat o řešení nabízející aplikaci včetně podpory škálování hardwaru, na kterém je spuštěna s přístupem k datům uloženém v cloudovém prostředí díky DaaS. [11][12][30] Na závěr je uveden obrázek 2.4, na kterém je zobrazeno rozdělení správy u hlavních cloudových služeb. Cloud Service management Private cloud IaaS PaaS SaaS Application Application Application Application Data Data Data Data Runtime Runtime Runtime Runtime Middleware Middleware Middleware Middleware OS OS OS OS Virtualization Virtualization Virtualization Virtualization Servers Servers Servers Servers Storage Storage Storage Storage Networking Networking Networking Networking by user by provider Obrázek 2.4: Porovnání správy cloudových služeb, převzato a upraveno dle: [13] 2.3 Containers (Kontejnery) Kontejnerizace je nový přístup využívaný v informatice. Pří běžné virtualizaci je virtualizován kompletní hardware, na kterém je spuštěn samostatný operační systém, 11

21 Containers (Kontejnery) a až v něm je nasazena požadovaná aplikace. U kontejnerizace je to jiné. Vytvářejí se oddělené kontejnery, což je operace o kterou se stará vrstva zvaná container engine. Kontejnery jsou spouštěné v operačním systému jako oddělené entity, které pak jsou v systému viditelné jako běžící procesy. Koncept je založen na implementaci linuxové funkce zvané kernel namespaces, jmenný prostor, původně vytvořené kvůli obtížnému vypořádání s vysoko výkonnými počítačovými clustery. [17] Tato funkce přistupuje k jádru systému Linux a pomocí systémového volání si vytváří separátní instanci předchozího namespace. V systému Linux jsou namespace implementovány pro síť, uživatele, systémový soubor, PID (proces ID) atd. Namespace lze využít mnoha různými způsoby, ale tím hlavním je vytvoření izolovaného kontejneru, který nemá žádný přehled nebo přístup k objektům mimo kontejner. Proces běžící uvnitř kontejneru vystupuje, jako by byl spuštěný na klasickém systému Linux. [17] Na rozdíl od virtualizace může být kontejner tak malý, jako samotný proces v něm spuštěný. Jelikož není virtualizovaný celý operační systém, jsou kontejnery výrazně úspornější k operační paměti i ostatním zdrojům. [17] Ačkoli hlavním specifikem je oddělení kontejnerů, tak stejně tak potřebné je i jejich schopnost komunikovat s okolím. Použitím volání linuxového jádra je možné připojit například složku umístěnou na serveru, která tak může být připojena k více kontejnerům naráz. [17] Nevýhodou kontejnerů je jejich povědomí o zdrojích na kterých jsou spuštěny, konkrétně o procesoru a operační paměti. Proces spuštěný uvnitř kontejneru neví o limitech zdrojů. Pro proces jsou viditelná všechna vlákna procesoru a také veškerá operační paměť, a to i přesto, že má proces povoleno být spuštěn jen na jednom vláknu nebo s omezenou pamětí. [17] Porovnání architektur běžné virtualizace a kontejnerizace je zobrazen na následujícím obrázku

22 Containers (Kontejnery) App 1 App 2 App 3 Bins/Libs Bins/Libs Bins/Libs Guest OS Guest OS Guest OS App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Hypervisor Host Operating System Infrastructure Hypervisor-based Virtualization Container engine Operating System Infrastructure Container-based Virtualization Obrázek 2.5: Srovnání architektury kontejnerizace s virtualizační technologií, převzato a upraveno dle: [18] Nejznámějším zástupcem kontejnerové technologie je container engine Docker, který bude přiblížen v následující kapitole. [17] Docker Docker je nejrozšířenější open-source softwarová platforma pro virtualizaci založenou na kontejnerech. Jedním z důvodů, proč je Docker využíván, je eliminace práce na lokálním zařízení. Díky kontejneru je možné testovat cokoli velice rychle a bez rizika poškození vlastního systému. Pokud chceme v Dockeru vytvořit nový kontejner, jsou potřeba pouze dvě komponenty. První komponentou je nainstalovaný Docker engine pro vytváření kontejnerů. Druhou nutnou komponentou je obraz operačního sytému, na kterém má kontejner být spuštěn. Mimo nutné komponenty je možné využít i volitelné, jako například připojit ke kontejneru lokální složku tak, aby byla dostupná z kontejneru. Vytvořené kontejnery také disponují přístupem k internetu přes stanici, na které jsou spuštěny. Kontejnery je také možné zálohovat vytvářením snapshotů. Lze tedy připravit kontejner s veškerou nutnou konfigurací pouze jednou a si vytvořit snapshot. Kdykoli je poté nutné použít kontejner v původním stavu, pouze spustíme nový kontejner, který 13

23 Orchestrace bude jako image používat vytvořený snapshot. [20][19] 2.4 Orchestrace Orchestrace je v daném odvětví velice důležitou technologií. Bez vhodné orchestrace by správa současných komplexních technologií byla výrazně komplikovanější. Orchestrace přináší do řízení určitou inteligenci a autonomii. U informačních technologií je orchestrace založena na jednotlivých hardwarových prvcích, softwarových službách a jimi nabízenými funkcemi. Pro orchestraci jsou vytvářeny šablony, pomocí kterých může prostředí automaticky řídit prvky pro zajištění cílové služby zákazníkovi. Orchestrace se také někdy nesprávně zaměňuje s automatizací. Ačkoli význam pojmů je obdobný není shodný a existují rozdíly, kvůli kterým se jedná o odlišné termíny. Automatizace je samostatná úloha jako například spuštění webového serveru, nakonfigurování serveru, zastavení služby. Na rozdíl od toho, orchestrace je založena na automatizaci celého procesního postupu (workflow). Orchestrací je tedy myšleno, že je zajišťován proces skládající se z celé posloupnosti automatizovaných úloh, které vedou například ke spuštění aplikace včetně přípravy infrastruktury. Souhrnně lze tedy říci, že automatizace se stará o úlohy a orchestrace o procesy.[21][22] 2.5 Konfigurační management Konfigurační management je velice užitečnou a v současné době často využívanou technologií pro správu konfigurace infrastruktury. Funkcionalita konfiguračního managementu je zaměřena na jednoduché konfigurování výpočetních stanic s rozmanitými operačními systémy. V konfiguračním managementu se využívá přístup IaaC, který je popsán dále.[24] Infrastructure as a Code (IaaC) Jedná se o princip založený na možnosti přistupovat k výpočetní infrastruktuře, jako ke kódu a nezáleží na tom, zda se jedná o stroje fyzické nebo virtuální. Při definici kódu pro vynucování konfigurace na cílové výpočetní stanici se využívají dva různé přístupy dle možností jazyka používaného nástroje. Deklarativní přístup 14

24 Konfigurační management je založen na definici podmínek, které musí být splněné, aby bylo možné považovat operaci za zdárně dokončenou. Příklad takové definice je následující. Je nutné aby bylo nainstalována databáze, webový server a nastavená síťová rozhraní. Druhým typem přístupu je imperativní přístup. Imperativní přístup je založen na definici přesného postupu jak docílit výsledné konfigurace. Příkladem je pak definice v následujícím tvaru. Nainstaluj databázi, poté nainstaluj webový server a nakonfiguruj síťová rozhraní. Dále je pro IaaC přístup nutné představit způsoby, jak jsou definice vynucovány na cílové stanici. Tyto metody existují dvě a to push a pull. Hlavním rozdílem mezi zmíněnými metodami je, že zatímco pull přístup si získává svou konfiguraci z řídícího serveru, tak u push přístupu je tato konfiguraci protlačena na stanici právě zmíněným řídícím serverem. Tabulka 2.2 zobrazuje některé z nástrojů konfiguračního managementu a možnosti definičních přístupů jimi používaných jazyků společně s metodou jak jsou tyto definice vynucovány. Tabulka 2.2: Nástroje konfiguračního managementu a jejich přístupy k definici konfigurací Nástroj Přístup Metoda CFEngine Deklarativní Pull Chef Imperativní Pull Puppet Declarativní Pull SaltStack Declarativní & Imperativní Push & Pull Puppet Prvním příkladem konfiguračního managementu je Puppet. Jedná se open-source nástroj napsaný v programovacím jazyce Ruby, využívaný jak na systémech Unixového typu tak i na systémech Windows, jehož první verze byla vydána v roce Pro popis systémových konfigurací byl pro Puppet vytvořen vlastní deklarativní jazyk. Puppet je navržen pro deklarativní správu konfigurací operačních systémů jak Unixového typu, tak systémů Windows. Uživatel popisuje zdroje a jejich hodnoty použitím deklarativního jazyka vytvořeného pro Puppet. Vytvořené soubory s hodnotami do konfigurace se nazývají manifesty. Puppet zjišťuje systémové informace a kompiluje 15

25 Konfigurační management manifest do katalogů specifických pro daný systém, které obsahují zdroje a jejich závislosti. Tyto katalogy jsou poté aplikovány na cílovém systému. Puppet je založen na klient-server architektuře, kde server je znám jako master a klient jako agent. V roli mastera je server, který obsahuje manifesty pro konfiguraci a je kontaktován agentem na němž se konfigurace vynucuje. Vynucení konfigurace může být spouštěno jako plánovaná úloha, nebo manuálně když je to potřeba.[25] [24] SaltStack SaltStack je open-source platforma pro konfigurační management založená na programovacím jazyku Python. SaltStack je stejně jako Puppet založen na architektuře klient-server. Server je označován jako master a klient jako minion. Na master serveru jsou uloženy soubory definující konfigurace pro minion servery. Salt se však liší možností funkce v módu označovaném jako master-less. V tomto módu není využívaný server v roli master, nicméně tato varianta se používá jen zřídka. Salt-master je centrálním bodem infrastruktury, po které komunikuje s miniony přes knihovnu ZeroMQ. Veškerá data jsou pro přenos serializovaná. Tato komunikace je velice rychlá, což je velkým plusem. Dalším z rozdílů mezi Puppet a SaltStack je využívaný jazyk. Zatímco jazyk v Puppetu je pouze deklarativní, tak jazyk použitý v Salt umožňuje i imperativní přístup při definování výsledné konfigurace. [26] 16

26 3 Nástroje V této kapitole jsou za účelem pozdějšího srovnání popsány jednotlivé nástroje pro cloudové řešení, aplikační katalog a workflow. 3.1 OpenStack OpenStack je hned po linuxovém jádře největší open-source projekt na světě. Jedná se o cloudovou platformu založenou na službách, které je možné doinstalovat na operačního systému s jádrem Linux v mnoha distribucích. Mezi nejrozšířenější distribuce pro OpenStack patří CentOS a Ubuntu. V následující kapitole bude popsána architektura nástroje OpenStack společně s jeho funkcemi. OpenStack je jakožto open-source projekt volně dostupný a existuje hned několik společností, které se zabývají zlepšováním standardních funkcí a implementování nových za účelem vytvoření vlastní cloudové platformy. Takové cloudové platformy jsou poté nabízeny zákazníkům pro implementaci v rámci datového centra zákaznické společnosti. Mezi zmíněné implementace jednotlivých funkcionalit patří například Juniper Contrail, OpenDaylight, PlumGrid. Zástupci z řad společností zabývající se tvorbou kompletní cloudové platformy založené na OpenStack pak jsou například Mirantis, RedHat nebo HP Architektura Architektura platformy OpenStack je založena na jednotlivých službách poskytující funkcionality pro cloudové řešení. Tyto služby jsou nazvány jako moduly a jejich jednotliví zástupci budou popsání v následující části. Aby platforma byla funkční musí spolu moduly komunikovat, k tomu dochází přes API jednotlivých služeb. Tato 17

27 OpenStack rozhraní je jediný způsob jak s modulem komunikovat a jak přistupovat k jeho funkcionalitám. Obrázek 3.1 zobrazuje architekturu platformy OpenStack. Heat Horizon Orchestrates cloud Provides UI Neutron Provide network conectivity for Cinder Provides columes for Nova VM Provisions Provide images Glance Stores images in Swift Monitors Provides authorization for Ceilometer Backup volumes in Keystone Obrázek 3.1: Architektura platformy OpenStack, převzaton a upraveno z: [15] Moduly Keystone je hlavním modulem celé platformy. Jedná se o službu pro ověřování identity uživatelských přístupů k funkcím jednotlivých modulů. Uživatelem může být jak osoba zadávající požadavek, tak jiný modul platformy. Dále poskytuje správu samotných uživatelských účtů. Keystone je kritická služba a jelikož veškeré moduly komunikují skrze ní, tak musí být nainstalována první. Jakožto služba pro identitu ověřuje uživatele a tenanty odesíláním validovaných autorizačních tokenů mezi všemi službami OpenStack prostředí. Pomocí tokenu je prováděna autentizace a autorizace pro požadované operace. V modulu Keystone je koncept tenantů, rolí a uživatelů. Tenant je určitá skupina uživatelů s definovanými právy a zdroji jako jsou, uživatelé, instance, sítě, image pro boot instancí. Uživatel může být členem více, než jednoho tenantu a má možnost mezi nimi přepínat pro přístup ke zdrojům daného tenantu. Role jsou v OpenStacku admin a member. V roli admin má uživatel přístup k operacím ovlivňujícím celý tenant, což může být například modifikace externí sítě. V roli member 18

28 OpenStack lze naproti tomu provádět pouze operace spjaté s konkrétním uživatelem, jako například správa instancí a sítí uvnitř tenantu.[14][16] Glance plní v OpenStack prostředí funkci umožňující uživatelům kompletní správu image (obrazů) virtuálních instancí. Tyto image jsou poté dostupné jako bootovací disky instancí vytvářených v prostředí OpenStack. Samotné image mohou být uloženy v různých lokacích a to od lokálního souborového systému, přes distribuovaný souborový systém až po možnosti objektového úložiště OpenStack modulu Cinder.[14] Základním síťovým modulem platformy je modul Neutron. Neutron je SDN (Software Defined Networking) modul a stará se o vytváření virtuálních sítí, routing, nebo i firewall, či rozklad zátěže (load-balance). S možnostmi SDN lze popsat komplexní OpenStack prostředí s mnoha tenanty. V prostředí OpenStack je SDN jako pluggable architektura, což znamená, že je možné připojit a spravovat rozlišné switche, firewally, load balancery a tím dosáhnout funkcí jako může být například Load Ballance as a Service (LBaaS) nebo Firewall-as-a-Service (FWaaS). Běžně jsou pak nejvyužívanější funkce pro správu externí a interní sítě a floating IP. Externí síť slouží k propojení tenantu s datovým centrem a tak zajistit přístup k internetu. Sítě interní jsou plně v režii zákazníka a slouží pro uspořádání vnitřní topologie instancí. Floating IP jsou IP adresy, které jsou prostřednictvím statického překladu adres SNAT přidělovány instancím v OpenStack prostředí. Jedná se o adresy z veřejného rozsahu a po jejich přidělení je příslušná instance dostupná přes síť internet. Neutron je v praxi často nahrazovaným modulem platformy. K nahrazení dochází způsobem, že je nasazen jiný balíček určený pro řešení síťové vrstvy, který nahrazuje a rozšiřuje funkcionalitu původního modulu. Neutron je poté používán pouze jako API ke zbylým modulům platformy.[16] Modul Nova je určený k poskytování výpočetních služeb. Hlavním účelem je vytváření instancí, které jsou již dále využívány dle přání a potřeb zákazníka. Díky funkcím modulu Nova je možné vytvořit vysoce škálovatelné a redundantní prostředí. Lze například spravovat klíče pro přístup k instancím, nebo migrovat instance. Migrace je funkce, při které je instance přesunuta z výpočetního compute serveru, na kterém je spuštěna, na jiný compute node. Tato funkce je využívána například, když je nutné přesunout instanci z přetíženého compute serveru. Speciálním případem migrace je pak live migrace. Při využívání live migrace je daná instance přesouvána za 19

29 OpenStack běhu a uživatel tak nemusí vůbec poznat, že k migraci došlo.[14][16] Swift je OpenStack modul pro správu objektového úložiště. Díky funkcím modulu Swift je možné vytvořit široce škálovatelné a vysoce redundantní úložiště. Poskytované služby jsou obdobné jako S3 storage od Amazon. S objektovým úložištěm modulu Swift je možné ukládat velké množství objektů na virtuální úložiště, které vystupuje jako kapacitně neomezené. Omezení je dáno pouze dostupným hardwarem, který je možné přidávat, či měnit tak, aby bylo dosaženo dostatečné kapacity. Při ukládání se často využívá replikace, to znamená, že data jsou uložena na více místech zároveň a tím jsou zálohována.[16] Pro správu blokového úložiště je k dispozici modul Cinder. Data zapsaná na disky aktuálně spuštěných instancí nejsou perzistentní. Po ukončení instancí jsou data ztracena. V modulu Cinder se definují tzv. volume, což jsou perzistentní úložiště, která mohou být přiřazena ke spuštěné instanci. Takový volume lze přiřadit pouze k jediné instanci. Služby dostupné díky funkcím modulu Cinder jsou velice podobné blokovému úložišti Amazon EC3 Elastic Storage. [14][16] Celou OpenStack platformu lze ovládat skrze příkazy zadávané do konzole. Existuje zde však modul Horizon, který slouží pro ovládání dostupných funkcí celé platformy OpenStack, a to prostřednictvím grafického uživatelského rozhraní dostupného přes webový prohlížeč. Horizon je služba nasazená na webový server Apache a používá Python WSGI (Web Service Gateway Interface) a framework pro rychlý vývoj webu Django. Ačkoli je ovládání skrze Horizon jednodušší především pro méně technické uživatele platformy OpenStack, například cílové zákazníky, nejsou v něm dostupné veškeré implementované funkcionality, a proto správci platformy stále musí využívat ovládání skrze příkazy v konzoli.[14][16] Orchestrační služby jsou v OpenStack prostředí zastoupeny modulem Heat. Heat poskytuje možnosti k definování prostředí a zdrojů přes šablony. Vytvářením prostředí za pomocí šablon vznikají stacky. Obsahem stacku jsou nejen instance, ale také sítě, nebo přiřazené IP adresy. Stacky je možné snadno spravovat, a to prostřednictvím modulu Horizon, nebo přes příkazy zadávané do konzole.[14][16] 20

30 VMware vcloud Suite 3.2 VMware vcloud Suite Společnost VMware je tvůrcem produktu vcloud. Jedná se o nástroj pro použití v prostředí privátního cloudu skládající se z několika produktů společnosti VMware poskládaných dohromady tak, aby nabízely komplexní služby jako cloudová platforma Architektura V této části práce bude popsána architektura VMware vcloud Suite. Následující obrázek 3.2 znázorňuje architekturu (vlevo) a nástroje (vpravo), ze kterých se skládá vcloud Suite. VMware vcloud Suite Cloud management Bussiness Management Operations Management Service Provisioning Software-Defined Networking and Security Cloud Infrastructure Virtual Datacenter Virtual Infrastructure Functions Software-Defined Storage and Availability Cloud management VMware vcenter Chargeback Manager VMware vcenter Operations Manager Suite VMware vcloud Automation Center VMware vfabric Application Director VMware vcloud Networking and Security Cloud Infrastructure VMware vcloud Director VMware vcloud Connector VMware vcenter Site Recovery Manager VMware vsphere Tools Obrázek 3.2: Architektura platformy VMware vcloud Suite, převzato a upraveno z: [31] Virtual Infrastructure - vsphere Předně se vcloud skládá z produktu vsphere. Produkt vsphere je používán jako hypervisor. Při použití vspehere je možné ve VMware vcloud spravovat velké oblasti výpočetních zdrojů (resource pools) virtualizované výpočetní infrastruktury. Na spravovaných VM jsou pak provozovány aplikace s požadovanou funkcionalitou. [31][29][32] Software-Defined Networking and Security - vcloud Networking and Security Produkt vcloud Networking and Security zahrnuje firewall, VPN, DHCP, NAT a ostatní síťové funkce pro virtualizaci počítačového prostředí. Jedná se o SDN (Software Defined Netoworking) nástroj pro snadnou správu síťové infrastruk- 21

31 VMware vcloud Suite tury v cloudovém prostředí. Veškeré aplikace, které simulují síťové prvky svými funkcemi jsou napojeny přímo na výpočetní zdroje, na kterých jsou prováděny. [30][29][32] Software-Defined Storage and Availability - vcenter Site Recovery Manager Pro správu úložiště je k dispozici funkce nástroje vcenter. Veškerá kapacita je agregována do různých oblastí dle jejich výkonu. Do těchto oblastí jsou pak přiřazovány aplikace tak, aby měli přístup k úložišti o odpovídajícím výkonu. Dostupné jsou také funkce pro zálohu uložených dat. [31][30][29] Virtual Datacenter - vcloud Director, vcloud Connecter Spojením nižších vrstev dohromady vzniká virtuální datové centrum. Je možné vytvářet i více takovýchto virtuálních datových center, kde každé disponuje kompletní sadou funkcí nižších vrstev a je plně izolované od ostatních. VMware vcloud Director spravuje IaaS architekturu prostřednictvím monitorování, a ovládání cloudových komponent. VMware vcloud Connector slouží pro zjednodušení migrace VM, ISO image a šablon do a z prostředí veřejného cloudu jak pro zákazníka, tak pro poskytovatele. [31][29] Service Provisioning - vcloud Automation Center, vfabric Application Director Názvem vcloud Automation Center je označován nástroj, který ulehčuje zřizování cloudových služeb. Lze tak připravovat aplikace, které jsou nabízeny v podobě služeb. Pro vytváření těchto služeb jsou připraveny standardizované komponenty pro různé typy aplikací. Příprava těchto služeb je pro zjednodušení a urychlení automatizována. Veškeré nabízené služby jsou poté dostupné skrze samoobslužný aplikační katalog.[30][29][32] Operations Management - vcenter Operations Manager Suite Operační management je uzpůsoben pro snadnou a efektivní správu cloudových prostředků a jejich optimalizaci. Mezi dostupné funkce patří například vizuální reprezentace zdraví, bezpečnostních rizik a efektivity infrastruktury zdrojů. Samozřejmou funkcí je možnost nastavení varování při dosažení limitů na jednotlivých zdrojích datového centra. Je tak mnohem snadnější vhodně a včas zareago- 22

32 VMware vcloud Suite vat na aktuální situaci.[31][30][29][32] Bussiness Management - vcenter Chargeback Manager Chargeback nástroj umožňuje sledování prostředků podobně jako operační management, avšak s jiným cílem. Hlavním cílem bussiness managementu je poskytnout přehled nad využívanými zdroji datového centra a náklady s nimi spojenými. [30][29][32] VMware vcloud Director V této části bude blíže popsán klíčový nástroj z produktu VMware vcloud, a to vcloud Director. Nástroj je předně určen pro správu privátních a hybridních cloudových architektur. Správa architektury je realizována přístupem IaaS (Infrastructure-as-a-Service) prostřednictvím kontroly a monitorování rozlišných komponent cloudového prostředí, jako je například správa VM, billing atd.[30][32] Primárně je nástroj zaměřen na použití v prostředí privátních a hybridních cloudových infrastruktur. Nástroj je realizován soustavou buněk, což jsou servery s operačním systémem Linux, konkrétně pak Red Hat, nebo CentOS obsahující součásti vcloud Director nástroje. Každá buňka obsahuje sadu služeb jako je přenos služeb, proxy konzole, vcenter listener a další. Buňky vyžadují, aby měli přiřazeny alespoň 2 IP adresy, jednu primárně pro uživatelské rozhraní, označované jako API vcloud Director a druhou pro proxy konzoli pro vzdálený přístup. Dvě adresy jsou potřeba z důvodu, že obě služby poslouchají síťový provoz na portu 443 protokolu TCP. Komunikace mezi jednotlivými buňkami probíhá přes ActiveMQ zprávy zasílané po primárním rozhraní. Pro buňky je i společná databáze, kde jsou uložené stavová data a konfigurace. Databázi je doporučené realizovat prostřednictvím Oracle RAC,Microsot SQL Failover, KairosDB nebo Cassandra Cluster Přenosové služby vyžadují, aby všechny buňky měli přístup ke společné sdílené složce, obvykle mapovánu přes NFS(Network File System). 23

33 VMware vcloud Suite VMware vcloud Connector VMware vcloud Connector je další z klíčových komponent VMware vcloud produktu. Nástroj je volně dostupný a primárně je určený pro snadnou migraci. Díky vcloud Connector lze přesouvat zátěž mezi oblastmi, které jsou spravovány přes VMware vsphere a vcloud prostředí. VMware vcloud Connector je založen na architektuře klient-server. Pro správnou funkci je nutné mít alespoň jeden vcloud Connector Server a počet vcloud Connector Node, což je označení pro klienta, záleží na počtu cloudů, které mají být propojeny. VMware vcloud Node je zodpovědný za přenos dat z jednoho cloudu (vsphere/v- Cloud Director) na jiný. VMware vcloud Server je používán ke správě všech připojených vcloud Connector Node. [33] vcloud Network VMware vcloud Network je nástroj sloužící ke správě sítových služeb. Pro správu prostředí jsou dostupné následující typy sítí. Pro zajištění externí konektivity se sítí internet je k dispozici externí síť (external network). Každá externí síť je na pozadí zapouzdřována buď do VXLAN, nebo do VLAN, které však pro svůj omezený rozsah ztrácí využití pro větší zákazníky. Síť může být využívána i pro poskytnutí přístupu k fyzickému prvku, VM instanci ve vcloud prostředí. Organizační sítě virtuálního datového centra (Organization VDC Networks) poskytují organizaci vnitřních sítí, kde mohou být propojovány vapp aplikace, aby spolu mohli komunikovat. Tyto sítě jsou vytvářeny přes vcloud Director v síťových rozsazích, které definují jejich vytvoření na vrstvě vsphere. Organizační sítě mohou být připojené do externí sítě pro umožnění interakce s okolním světem. Posledním typem sítí jsou vapp Networks, které jsou kompletně konfigurovány zákazníkem za účelem zpřístupnění vapp aplikací. Jedná se o shodné sítě, jako jsou privátní vnitřní sítě. Několik vapp aplikací může komunikovat navzájem připojením do organizační sítě. Obecně existují dva způsoby, pro vytváření vapp sítě. Prní typ je direct, který je přímo připojen do externí organizační sítě. Druhý typ nazývaný routed je privátní síť, která je pomocí NAT překládána a může být privátně nebo přímo 24

34 VMware vcloud Suite routována. [30] Verze VMware vcloud Suite je nabízen ve třech různých edicích lišících se dle zahrnutých funkcí. Jednotlivé edice jsou složeny z edice vrealize Suite a vsphere Enterprise Plus. Edice vrealize Suite zobrazuje obrázek 3.3. vrealize Suite Editions vrealize Suite Enterprise DevOps-ready IT vrealize Suite Standard Intelligent operations vrealize Bussiness for Cloud Standard: Cloud Compare, Costing Log Insight: Log Analysis vrealize Operations Advanced: SDDC Monitoring for Hybrid Clouds vrealize Suite Advanced Automated IT to IaaS vrealize Automation Advanced Infrastructure Automation vrealize Bussiness for Cloud Advanced:Cloud Planning, Compare, Costing Log Insight: Log Analysis vrealize Operations Advanced: SDDC Monitoring for Hybrid Clouds vrealize Operations: Aplication Monitoring vrealize Automation Enterprise: Application Automation vrealize Automation Advanced Infrastructure Automation vrealize Bussiness for Cloud Advanced:Cloud Planning, Compare, Costing Log Insight: Log Analysis vrealize Operations Advanced: SDDC Monitoring for Hybrid Clouds Obrázek 3.3: Licence VMware vrealize Suite, převzato a upraveno z: [35] Verze standard zahrnuje nástroje pro monitorování prostředí, analýzu logů a také billing. Verze advanced zahrnuje funkcionality verze standard a přidává automatizaci infrastruktury a funkce pro podnikové plánování. Nejvyšší verze Enterprise zahrnuje funkce edice advanced a přidány jsou nástroje pro monitorování a automatizaci aplikací.[35] 25

35 Aplikační katalog vrealize Suite Standard vcloud Suite Editions vrealize Suite Advanced vrealize Suite Enterprise vrealize Suite Standard vrealize Suite Advanced vrealize Suite Enterprise vsphere Enterprise Plus for vcloud vsphere Enterprise Plus for vcloud vsphere Enterprise Plus for vcloud Obrázek 3.4: Edice VMware vcloud Suite, převzato a upraveno z: [35] Licencování Od verze 7 je licencování založeno na novém modelu Portable Licensing Unit (PLU). Nový model slibuje flexibilitu ve využití vcloud Suite. S novým licenčním modelem je možné použít vcloud Suite k budování a správě privátních cloudů založených na vsphere, stejně tak jako cloudů založených na jiných hypervisorech. PLU licence umožňuje ke správě obou zmíněných variant využít jednu licenci. Konkrétně pak jedna PLU umožňuje spravovat neomezený počet nasazených VM nad jedním procesorem ve vsphere nebo až nad 15 instancemi operačního systému (Operating System Instance - OSI) nasazených v rámci jiného prostředí, než VMware vsphere. Zároveň však nelze využít obě možnosti současně. [34][35] 3.3 Aplikační katalog Následující kapitola popisuje službu aplikačního katalogu a shrnuje nabízené funkce. V kapitole jsou také popsány možnosti, jakými lze získat funkce aplikačního katalogu a k čemu je využít Účel aplikačního katalogu Aplikační katalog je aktuálně velmi populární funkcí především pro koncové uživatele cloudových služeb. Pod pojmem aplikační katalog rozumíme funkcionalitu nabízející aplikace jako službu. Nabízená služba je složena z cílové aplikace spuštěné na VM jako součásti, která je vytvořena právě pro účely vybrané aplikace. Katalog by měl 26

36 Aplikační katalog být přehledný, jednoduchý pro použití a mělo by být snadné přidávat další aplikace do nabídky pro zákazníky. Přístup ke katalogu by měl být co nejsnadnější a ideálně také nezávislí na poloze, odkud je k němu přistupováno. Vhodné řešení je tak přístup přes webový prohlížeč a přihlášení ke katalogu přes uživatelské přístupové údaje VMware vapp VMware vapp je nástroj sloužící k poskytování aplikací nabízených zákazníkům v podobě služby přes samoobslužný portál. Jedná se o řešení, které je standardní jednotkou nasazenou v vcloud Director. Skládá se z jedné, nebo více VM a detailů k přiřazeným síťovým konfiguracím. VMware vcloud vapp se od standardních šablon nabízených nástrojem VMware vsphere liší tím, že obsahují předkonfigurovaný virtuální firewall, a detaily o počtu interních a externích sítí do něj napojených. Na takto specifikované instanci je pak spouštěna vybraná aplikace. Samotné vapp aplikace je možné importovat nebo exportovat v podobě OVF balíčku. Aplikace jsou do katalogu nástroje vapp nahrávány skrze API nebo vcloud rozhraní. Standardizované vapp šablony pro běžné operační systémy jsou obvykle poskytovány poskytovatelem cloudových služeb v globálním katalogu. Zákazníci mají možnost vytvořit si vlastní vapps, nebo je importovat skrze vcloud Connector nebo OVF balíček. [30][32] V následujícím seznamu jsou shrnuty kritéria pro nasazení vapp Při vytváření VM uvnitř vapp, by měl být zvolen odpovídající operační systém v nastavení vlastností VM Na VM by měli být nainstalovány VMware Tools pro správnou funkci a získání výhod ukončování operačního systému a upravování skriptů (přiřazení IP adresy atd.). Nakonfigurované limity jednotlivých VM mohou být po jejich vytvoření vynucovány prostřednictvím blocking task. Lze vytvářet stavové snapshoty (snímky) aplikací, které lze migrovat mezi jednotlivými virtuálními datovými centry. Při migraci není garantována kompat- 27

37 Aplikační katalog ibilita při přechodu mezi různými platformami procesorů (Intel a AMD) v datových centrech. Ne všechny OVF balíčky konfigurací jsou podporovány nástrojem vcloud Director. [30][32] Tvorba nové vapp se provádí přes nástroj dostupný ve webovém klientu. Aplikace jsou vytvářené z jedné nebo více instancí a sítí, které je spojují. Pro vytvoření vapp aplikace je možné použít již existující instanci, a nebo vytvořit novou. Vytvořenou aplikaci je poté samozřejmě možné různě konfigurovat. Největší výhodou je přenositelnost vytvořených aplikací. Aplikaci je totiž po jejím vytvoření možné exportovat jako OVF balíček a opět ho importovat i v jiném vcenter prostředí. [30] [32] VMware Horizon Apps VMware Horizon Apps je nástroj pro virtualizaci aplikací nabízených jako SaaS. Aplikace jsou nabízeny v katalogu a dostupné odkudkoli skrze rozhraní klientské aplikace VMware Horizon View nebo webového prohlížeče. Aplikace jsou spouštěny v cloudovém prostředí, které je na pozadí svázáno s nástrojem. Nástroj je založen na Microsoft Remote Desktop Session Host (RDSH), který slouží pro připojení k aplikaci. Po připojení k aplikaci je možné ji využívat jako by byla lokálně nainstalována, a je tedy možné ukládat i nahrávat soubory a používat zdroje serveru, ke kterému je aplikace připojena. Jelikož je nástroj založen na RDHS je funkcionalita omezena pouze na aplikace pro operační systém Microsoft Windows a je tedy i hlavním cílem nástroje doručit Windows aplikaci na jiné operační systémy. Výhodou využití RDHS je možnost vytvoření jediné instance s aplikací, která bude k dispozice více uživatelům. [42] [43] [44] Aplikace pro Horizon jsou získávány z RDHS serveru, který musí obsahovat dané aplikace. Skrze grafické rozhraní klientské aplikace je poté požadovaná aplikace vybrána a přidána do aplikačního katalogu přístupného uživatelům. [42] [43] [44] Další funkcionalitou VMware Horizon je vytváření virtuálních pracovních ploch, které mohou využívat PCoIP, nebo Blast Extreme protokol. Při využívání Blast Extreme protokolu je možné využívat grafickou akceleraci a za pomoci h.264 kodeku využívat až 4K rozlišení. [42] [43][44] 28

38 Aplikační katalog Obrázek 3.5 zobrazuje logickou architekturu VMware Horizon. Obrázek 3.5: Architektura VMware Horizon, převzato a upraveno z: [42] OpenStack HEAT Heat je modul stručně popsaný již v kapitole o cloudové platformě OpenStack. Jelikož jeho funkce umožňují i úvahy pro použití jako aplikační katalog, bude nyní popsán blíže. Heat není modul určený přímo pro účely aplikačního katalogu, nicméně v určité míře by bylo možné ho pro tento účel využít. Pro Heat jsou vytvářeny šablony cloudových aplikací skládající se z různých cloudových zdrojů. V šablonách jsou specifikovány vazby mezi jednotlivými zdroji, ke kterým Heat přistupuje přes API ostatních služeb. Obvykle je Heat využíván ke správě infrastruktury, nicméně při začlenění nástrojů konfiguračního managementu, jako je SaltStack či Puppet, které již byly zmíněny dříve, jej lze úspěšně použít i pro účely aplikačního katalogu. [45] Heat využívá šablon ve formátu HOT. Příklad jednoduché šablony je uveden níže. [45] heat_template_version: description: Simple template to deploy a single compute instance 29

39 Aplikační katalog parameters: key_name: type: string label: Key Name description: Name of key-pair to be used for compute instance image_id: type: string label: Image ID description: Image to be used for compute instance instance_type: type: string label: Instance Type description: Type of instance (flavor) to be used resources: my_instance: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: { get_param: image_id } flavor: { get_param: instance_type } outputs: instance_ip: description: The IP address of the deployed instance value: { get_attr: [my_instance, first_address] } V uvedené ukázce šablony je vidět definovaný seznam parametrů, které jsou poté využívány v dalších částech šablony. Další částí jsou zdroje, kde je vytvořena instance o dané velikosti (flavor). V závěru ukázky jsou pak definovány výstupy z provedené šablony. 30

40 Aplikační katalog OpenStack Murano Murano je další z rozšiřujících modulů platformy OpenStack. Jeho primární funkcí je nabídnout uživateli aplikační katalog. [46] Murano modul poskytuje katalog aplikací dostupný přes webový prohlížeč, kam lze umístit jednotlivé aplikační balíčky. Pro správu a vytváření aplikací je připraveno uživatelské rozhraní a API. Použití není omezené cílovým operačním systémem, a proto lze vytvářet balíčky jak pro Windows tak pro Linux. [46] Následující obrázek 3.6 zobrazuje architekturu modulu Murano. Veškeré vzdálené operace jako je instalace softwaru a konfigurace jsou přenášeny přes AMQP frontu do murano-agent bloku. Komunikace může být nakonfigurována na oddělenou instanci AMQP pro zajištění izolace serverů a infrastruktury. Pro komunikaci s ostatními moduly OpenStack platformy je využíván přístup k REST API přes python klienty. Modul Keysone zajišťuje, že Murano může komunikovat s moduly v OpenStack prostředí. Pro orchestraci infrastruktury dle aplikačních definic je využíván modul Heat. [46] Murano Architecture murano-client CLI Keystone Heat VM Horizon muranodashboard murano-api murano-engine murano-agent Database RabbitMQ RabbitMQ Environments Packages REST API optional REST API mandatory AMQP optional AMQP mandatory Obrázek 3.6: Architektura modulu Murano OpenStack platformy, převzato a upraveno z: [46] Tvorba aplikačních modulů je prováděna přes deklarační jazyk do šablonového souborů, který je shodný s šablonou modulu Heat. Dále je součástí manifest obsahu- 31

41 Aplikační katalog jící obecná metadata o aplikaci, dynamická definice formuláře uživatelského rozhraní, spustitelné scripty instalující danou službu a definice potřebných tříd. K balíčku je možné přibalit i logo, které bude v katalogu prezentovat danou aplikaci jako ikona. [46] Cloud Service Broaker (CSB) CSB je platforma určena pro rozšíření služeb přes několik cloudových technologii, ideálně by měla být schopna poskytovat služby aplikačního katalogu nezávisle na tom, jaká cloudová technologie je k tomu využívána. Definice z Gartner říká: "Cloud services brokerage (CSB) is an IT role and business model in which a company or other entity adds value to one or more (public or private) cloud services on behalf of one or more consumers of that service via three primary roles including aggregation, integration and customization brokerage. A CSB enabler provides technology to implement CSB, and a CSB provider offers combined technology, people and methodologies to implement and manage CSB-related projects." [39] Vývojem CSB platformy se zabývá několik společností, jako například IBM, nebo Mirantis, kterému bude věnována tato část práce. CSB je platforma pro správu služeb v cloudu. Všechny služby jsou na bázi XaaS (Anything as a Service) a společně sdílí rozhraní pro jejich správu. Rozsah jeho využití je široký, od správy celé infrastruktury až po spravování široké škály cloudových služeb a virtualizačních platforem. To vše je možné pomocí pokročilých nástrojů pro správu konfigurace spolu s využitím různých služeb pro klienty. Logická architektura CSB platformy je znázorněna obrázkem

42 Aplikační katalog CSB Logical Architecture SaaS Services Orchestrate Cloud resources Orchestrate IaaS resources Manage Microsoft cloud Manage SaaS subscirptions Config. Management (CSB Engine Plugin) Cloud Orchestration (CSB Engine Plugin) Office365 API Client (CSB Engine Plugin) SaaS Clients (CSB Engine Plugin) CSB Frontend Cache CSB API CSB Engine Backend Web UI (part of CSB API) CSB Frontend ecommerce Database CSB Database Obrázek 3.7: Logická architektura CSB Jak znázorňuje obrázek 3.7, CSB je rozděleno na dvě hlavní části, a to frontend a backend. Pro přístup zákazníka k nabízeným službám slouží frontend, který využívá grafické uživatelské rozhraní dostupné přes webový prohlížeč. Na druhé straně je backend ovládaný administrátory, také přes grafické uživatelské rozhraní dostupné webovým prohlížečem. CSB funguje tak, že zákazník si vybere požadovanou službu a tím jeho starost končí. Příprava proběhne automaticky skrze CSB, kde se použije příslušná funkcionalita pro ovládání infrastruktury (backend), na kterém bude služba provozována. CSB umožňuje využívat široké množství backend prostředí pro provoz služeb. Frontend je zpracován v Oscar ecommerce Framework, FeinCMS a LeonardoCMS. Cílový uživatel tak využívá samoobslužný portál ve vzhledu nákupního portálu. Pro tvorbu služeb byl použit Django framework. Součásti backendu je CSB databáze, která je realizována Galera clustrem. Tato databáze slouží k ukládání všech dat z API. Po každém provedeném příkazu nebo zavolaném procesu se API doptá databáze na vrácení příslušných dat. Pro zjednodušení nasazení a správy serverů, na kterých je CSB nasazeno je využíván nástroj konfiguračního managementu SaltStack. Místo manuální správy infrastruktury, tak lze využívat funkce nástroje SaltStack. Pro ujištění, že vše 33

43 Schvalovací workflow funguje tak jak má, jsou zahrnuty monitorovací nástroje jako Sensu, Graphite a Heka. Sledována je celá CSB platforma, aby byly administrátorům poskytnuty informace k minimalizaci problémů. Platforma umožňuje zakládat profily pro společnosti v roli zákazníka, s několika interními uživateli. Tito uživatelé pak prostřednictvím samoobslužného frontend portálu objednávají požadované služby, kterými jsou jak VM instance s vybranými operačními systémy, tak třeba licence pro softwarové aplikace typu Microsoft Office. Díky rozhraní, které je situováno do stylu nákupního portálu, jsou přehledně dostupné informace o měsíčních platbách za poskytované služby. Možné je připravovat i nové aplikace dostupné skrze portál a nejen jediným způsobem. První postup využívá Microsoft Azure backend AzurePack, kdy jsou vytvářeny VM instance do cloudového prostředí Microsoft Azure. Aplikace je vytvářena skrze novou VM instanci, která je uvedena do požadovaného stavu a následně je z této instance vytvořen image. Výsledný image je pak zapsaný jako nový produkt do samoobslužného portálu. Další způsob je použít OpenStack Heat backend. Zde je využíváno cloudové prostředí OpenStack a možnosti modulu Heat. Pro vytvoření VM instance je připravena Heat šablona po jejímž proběhnutí je spuštěn bash script, který se postará o doinstalování příslušných aplikací. Heat šablona spolu s bash scriptem je poté přidána jako nový produkt portálu. 3.4 Schvalovací workflow V této kapitole je popsán účel schvalovacího workflow a jím nabízených funkcí. Součástí kapitoly je i představení možných řešení pro schvalovací workflow Účel schvalovacího workflow Využití schvalovacích procesů se může pro cloudová prostředí na první pohled zdát jako bezpředmětná, nicméně při hlubší analýze lze nalézt jejich užitek, a to především pro větší společnosti. Účelem schvalovacího workflow je poskytnou funkcionality pro přesné řízení procesů a začlenění do jejich průběhu schvalování. Procesy jsou převážně složeny z mnoha propojených kroků, jež je nutné provádět v určitém pořadí. Schvalovací work- 34

44 Schvalovací workflow flow umožňuje ke každému klíčovému kroku přidat schvalovací podmínku. Takováto podmínka je delegována na zodpovědnou osobu, která dle momentálních preferencí a vlastního vědomí rozhodně, zda lze pokračovat. Rozhodování může být prováděno i automaticky za pomocí různých dotazů, například na výpočetní zdroje vcenter Orchestrator VMware vcenter Orchestrator je nástroj pro orchestraci VMware cloudového prostředí vcloud Suite. Nabízené funkce umožňují vytvářet automatizovaná workflow (pracovní postupy) včetně schvalovacích funkcionalit, kam je však zahrnuto pouze schvalování na základe informací zjištěných přes dotazy na jednotlivé nástroje vcloud. Nástroj je založen na množství plug-inů, které svým použitím přidávají podporu různých řešení. Po dlouhou dobu se jednalo o dosti nákladné řešení, nicméně v posledních letech je nabízené zdarma v rámci nástroje VMware vcenter. VMware vcenter Orchestrator se nasazuje na VM přes přiřazení OVF balíčku k instanci vytvořené v rámci vcenter. VMware vcenter Orchestrator je ovládán skrze klientskou aplikaci instalovanou na lokální stanici. Skrze aplikaci lze jednotlivá workflow nejen spouštět, ale také editovat a vytvářet. Proces tvorby workflow je prováděn skrze grafické rozhraní klientské aplikace, která nabízí rozhraní fungující stylem drag-and-drop. [36][37] Obrázek 3.8: Workflow vcenter Orchestrator, převzato z: [38] 35

45 Schvalovací workflow Mistral Mistral je modul cloudové platformy OpenStack, který je stejně jako ostatní také volně dostupný a lze ho tak nasadit v podobě služby. Mistral poskytuje funkcionality k definování schvalovacích workflow pro procesy prováděné v prostředí OpenStack platformy bez psaní kódu. Stejně jako v případě vcenter Orchestrator je schvalování omezeno na vyhodnocení získaných dat z OpenStack prostředí. Dostupné jsou i funkcionality pro odesílání výstupů a vyhodnocování vstupních dat, avšak bez bližší implementace. [41] V kontextu modulu Mistral je workflow popisováno jako bussines proces skládající se z více rozlišných, navzájem propojených kroků, které je nutné provést v určitém pořadí na distribuovaném prostředí. [41] Uživatel může proces popsat jako soustavu úloh a jejích průběhů. Takto upravený popis procesu lze nahrát do Mistral modulu, který se postará o správu stavů, správné pořadí provádění úloh, paralelní zpracování, synchronizaci a řešení vysoké dostupnosti. Mistral také poskytuje funkcionality pro flexibilní plánování úloh. Lze tak přesně specifikovat v jakých časových intervalech má být úloha spouštěna. Spojením více úloh dohromady vzniká workflow. [41] Jedním z využití možností modulu Mistral je plánování úloh prováděných v cloudovém prostředí. Takové úlohy mohou být velice rozmanité, a to od provádění lokálních procesů na specifických VM instancích, až po volání REST API přístupných v cloudovém prostředí za účelem rozmanitých nabízených funkcionalit. Lze provádět i úlohy správy cloudového prostředí jako vytváření nebo ukončování VM instancí. Důležitou vlastností je zmíněné skládání do workflow spuštěných v plánovaném čase s případnou periodou. Mistral se sám postará o paralelní provedení a poskytne monitorování a správu prováděných úloh. Uživatel může specifikovat workflow skládající se z úloh spojených s několika instancemi, sítěmi a aplikacemi na nich spouštěných. [41] Architekturu modulu Mistral zobrazuje obrázek

46 Schvalovací workflow Workflow queue Mistral Architecture Engine Scheduler API Server Task Queue workflows executions tasks actions triggers Task Executor Task Executor Obrázek 3.9: Architektura modulu Mistral, převzato a upraveno z: [40] API server z obrázku 3.9 vystavuje dostupné REST API pro monitorování a spouštění workflow. Vyzvedávání příslušného workflow z fronty zařizuje Engine. Též je zde obsluhován postup spouštění workflow a výpočet, které úlohy jsou připraveny pro uložení do Task queue (fronty úloh). [41] Provádění jednotlivých úloh je účelem Task executor bloků. Jsou zde vybírány úlohy z fronty a spouštěny. Po dokončení úlohy je zaslán výsledek zpět na Engine blok. Pro ukládání a spouštění zpožděných volání je připraven blok Scheduler. Scheduler obsluhuje periodické vykonávání úloh a komunikuje s bloky Engine a Executor. v posledním bloku jsou persistentně uložené definice jednotlivých workflow, aktuálně spuštěné stavy a jejich výsledky. [41] Pro specifikaci workflow jsou používány šablonové soubory typu yaml. Mistral podporuje dva typy definovaných workflow a to direct (přímý), a reverse (zpětný). Direct workflow se skládá z úloh kombinovaných do grafu, kde každá úloha může být spuštěna až po dokončení předchozí, na jejíž výsledků závisí. Direct workflow jsou považovány za dokončené pokud již nezbývá žádná úloha které by měla být vykonána. Nyní následuje příklad jednoduché direct šablony, ve které dochází k vytvoření instance. [41]

47 Schvalovací workflow version: 2.0 create_vm: description: Simple workflow sample type: direct input: # Input parameter declarations - vm_name - image_ref - flavor_ref output: # Output definition vm_id: <% $.vm_id %> tasks: create_server: action: nova.servers_create name=<% $.vm_name %> image=<% $.image_ref %> flavor=<% $.flavor_ref %> publish: vm_id: <% $.id %> on-success: - wait_for_instance wait_for_instance: action: nova.servers_find id=<% $.vm_id %> status= ACTIVE retry: delay: 5 count: 15 Reverse workflow jsou taková, kde všechny vazby grafu jsou závislosti. U tohoto typu workflow je nutné specifikovat které úlohy musí být dokončené.pokud je takové workflow spuštěno, Mistral sám identifikuje potřebné závislosti k úspěšnému provedení. Níže následuje příklad reverse workflow. [41] --- version: 2.0 create_vm_and_send_ type: reverse input: 38

48 Schvalovací workflow - vm_name - image_id - flavor_id output: result: <% $.vm_id %> tasks: create_vm: action: nova.servers_create name=<% $.vm_name %> image=<% $.image_id %> flavor=<% $.flavor_id %> publish: vm_id: <% $.id %> search_for_ip: action: nova.floating_ips_findall instance_id=null publish: vm_ip: <% $[0].ip %> associate_ip: action: nova.servers_add_floating_ip server=<% $.vm_id %> address=<% $.vm_ip %> requires: [search_for_ip] send_ action: send_ to= admin@mysite.org body= Vm is created and id <% $.vm_id %> and ip address <% $.vm_ip %> requires: [create_vm, associate_ip] Jak je v ukázce vidět, kromě tvorby instance následuje i přiřazení IP adresy jejíž požadavkem je dokončené hledání IP adresy (search_for_ip). V závěru ukázky je blok, který informuje o vytvoření instance mailovou zprávou a to za předpokladu, že je vytvořena instance a má přiřazenou IP adresu. [41] Congress Dalším modulem dostupným do cloudové platformy OpenStack je Congress. Hlavním účelem proč Congress vznikl, je poskytnout Policy-as-a-Service (politika jako služba) přes libovolné cloudové služby a dodržování politik v dynamickém prostředí. 39

49 Schvalovací workflow [47] Služby poskytované IT oddělením jsou vždy řízeny a uváděny do souladu s obchodní politikou společnosti. Jedním ze způsobů jak vynutit tyto politiky je ručně. V takovém případě jsou manuálně zasílány informační maily ohledně dané situace atd. V současné situaci, kdy světem hýbou cloudové technologie, jsou však služby očekávány co nejrychleji, proto je potřeba využívat flexibilnější přístup. [47] Congress je zaměřen na poskytnutí rozšiřitelného open-source frameworku pro vedení a regulaci napříč poskytovanými službami dynamické infrastruktury cloudového prostředí. Congress umožňuje použití deklarativního jazyka pro popis obchodní logiky. Příkladem takové logiky je například, že VM instance nesmí být nikdy vytvořena v jiné geografické oblasti než úložiště, kde bude disk zmíněné VM instance. Je tedy možné monitorovat, vynucovat, definovat, a kontrolovat politiky v heterogenním cloudovém prostředí. Congress sbírá informace z jednotlivých modulů OpenStack platformy jako Nova, Neutron atd. a ověřuje zda aktuální stav odpovídá definované politice. [47] Vytvářené politiky se skládají z definice chyb, které mohou nastat a jak na ně má být reagováno pokud nastanou. Níže následuje ukázka definice. error(vm, network) :- nova:virtual_machine(vm) nova:network(vm, network) nova:owner(vm, vm_owner) neutron:owner(network, network_owner) not neutron:public_network(network) not same_group(vm_owner, network_owner) same_group(user1, user2) :- ad:group(user1, group) ad:group(user2, group) execute[neutron:disconnectnetwork(vm, network)] :- error(vm, network) Ukázka definice říká, že každá síť připojená do VM instance musí být veřejná nebo vlastněna někým, kdo je ve stejné skupině, jako vlastník VM instance. V případě 40

50 Schvalovací workflow že bude tato podmínka porušena, vyvolá se chyba a bude následovat odpojení dané sítě. [47] Congress spolupracuje s libovolnou cloudovou službou a to za předpokladu, že lze reprezentovat stav služby v tabulkovém formátu. Tabulka je definovaná jako kolekce řádků se sloupci, kde každá buňka tabulky obsahuje záznam ve tvaru čísla, nebo řetězce, ke komunikaci s jednotlivými službami využívá Congress ovladače, které je nutné napsat a poté nakonfigurovat pro danou službu. [47] 41

51 4 Analýza V následující kapitole je provedena analýza postupu přípravy prostředí pro testování softwarových aplikací a zpracován návrh nového postupu. Zmíněné postupy jsou následně srovnány dle popsaných hledisek. Srovnání je provedeno také pro cloudové platformy, aplikační katalogy a nástroje pro workflow. Při srovnávání bylo využíváno nejen obecně dostupných informací, ale také znalostí a zkušeností mých, a kolegů v české pobočce společnosti Mirantis a.s. v jejíž spolupráci byla tato práce vytvořena. 4.1 Prostředí pro nasazení Tato kapitola se bude zabývat představením a analýzou prostředí pro nasazení komplexního řešení zaměřeného na zefektivnění testovacího procesu při vývoji softwarových aplikací. Analýze bylo podrobeno prostředí společnosti zabývající se vývojem softwarových aplikací. Účelem samotné analýzy bylo nejen zmapovat dosavadní průběh, ale také zvážit a navrhnout možná zlepšení, či automatizaci za využití aktuálně velmi populárních cloudových řešení. Jak vlastně probíhá proces vývoje softwaru? Softwarové aplikace jsou vždy vyvíjeny v několika fázích a samotný vývoj je pouze jedna jeho část. Vše samozřejmě začíná u návrhu aplikace, a to jak ze strany uživatelského rozhraní, tak ze strany vnitřního návrhu struktury pro zaručení všech požadovaných funkcionalit a přehledného členění aplikace. Po dokončení návrhové části vývoje aplikace se přechází k programování a tedy samotnému vývoji aplikace, což je často označováno jako nejdůležitější část. Nejdůležitější části, je však kvalitní návrh aplikace, samotné technické provedení aplikace je samozřejmě také důležité, avšak bez kvalitního návrhu začne vývoj velice brzy narážet na komplikace způsobené právě absencí kvalitního návrhu. Poslední 42

52 Prostředí pro nasazení a často opomíjenou, avšak neméně důležitou, části je testování funkčnosti aplikace. Vývoj nikdy neprobíhá v jediném sledu. Jak jsou postupně zhotovovány jednotlivé implementace funkcionalit, probíhá také jejich testování společně s ověřováním, zda jejich implementace nijak neovlivnila již implementované části aplikace. Předmětem analýzy a návrhu je předně způsob, jak zautomatizovat právě testovací proces. Automatizací testovacího procesu však nejsou myšleny automatické testy aplikace, ale automatizovaná příprava prostředí pro testování aktuálního stavu aplikace. Jedná se tedy o přípravu výpočetních stanic v určitém výchozím stavu, které je očekávané pro správné fungování aplikace Analýza aktuálního procesu Aktuální proces přípravy testovacího prostředí nevyužívá žádnou cloudovou technologii. Testovací prostředí jsou připravována jako VM instance na serverovém nástroji pro virtualizaci VMware ESXi. Servery s testovacími instancemi nejsou nijak odděleny od zbytku infrastruktury a ani se nejedná o servery, které by byly určené pouze pro testovací prostředí. Tvorba prostředí je prováděna ručně bez jakýchkoli automatizačních nástrojů. Běžný způsob jakým jsou aktuální verze aplikace testovány je založen na manuálním vytvoření VM instance administrátorem v prostředí virtualizačního nástroje na serverovém vybavení společnosti. Jelikož se VM instance pro testování nachází ve stejných lokacích, kde jsou provozovány i produkční aplikace, jedná se o vysoce rizikový postup. Celý proces je prováděn samotnými pracovníky administrátorského oddělené, konkrétně poté co je připravena nová verze aplikace pro testování, musí pracovníci testovacího oddělení kontaktovat administrátory pro zřízení VM instance za účelem testování nové verze. Manuální provedení je samozřejmě způsob jak mohou být do procesu zanášeny chyby a navíc je tak konzumován čas pracovníků, který by mohl být využit produktivněji. Celý proces přípravy VM instance pro testování zobrazuje následující diagram

53 Prostředí pro nasazení Obrázek 4.1: Aktuální proces přípravy testovacího prostředí Již na první pohled je zřejmé, že se jedná o dosti komplikovaný postup plný manuálních úkonů a hlavně komunikace při předání řízení probíhajícího procesu. Pokud by se v tomto, již tak značně komplikovaném procesu, mělo navíc začlenit například schvalování vytvoření nové testovací instance managementem, nebo jakékoli jiné úkony, znamenalo by to nejenom obtížné začlenění samotného úkonu, ale také další nárůst složitosti celého procesu. Největší negativa analyzovaného postupu jsou shrnuty v následujícím seznamu: časté předávání řízení procesu 44

54 Prostředí pro nasazení V diagramu je celkem 6 případů kdy probíhá komunikace mezi jednotlivými odděleními. Z praxe je dobře známo, že aby taková komunikace byla efektivní, stejně jako vyřizování požadavků, je vyžadována neustálá kontrola komunikačního kanálu. Vznikají tak prodlevy nejenom mezi jednotlivými reakcemi komunikace, ale také při vyčkávání než je provedena požadovaná akce. Dalším důvodem, proč je komunikace při předávání řízení nevhodná, je u důvodu, že tím vzniká prostor pro chyby lidského faktoru, například neuvedení nutných informací, nebo prosté zmýlení. V optimálním procesu by mělo být vyžadováno co nejméně komunikace mezi jednotlivými odděleními, aby byl proces jednodušší, rychlejší a také odolnější k chybám. velké množství manuálních úkonů Jak z diagramu vyplývá, veškeré úkony jsou prováděny manuálně, což znamená, že proces nevyužívá žádnou automatizaci. Procesy založené čistě na manuálních úkonech jsou velice náchylné na chyby lidského faktoru. Mohou tak vznikat chyby vlivem překlepů, špatné konfigurace atd. Manuální úkony také vyžadují účast pracovníka, který je tak zaměstnán rutinními úkony pro přípravu testovacích prostředí a nemůže svůj čas využít produktivněji, což pro společnost znamená další náklady. Vhodnější by tedy bylo připravení šablon pro zautomatizování co největší části procesu a tím odlehčení pracovníkům administrátorského oddělení. náročné monitorování prostředí Z hlediska monitorování se také nejedná o vhodné řešení. Jelikož k prostředí, kde jsou vytvářeny testovací prostředí mají přístup pouze pracovníci z administrátorského oddělení, nemají pracovníci testovacího oddělení žádnou možnost přímé kontroly vlastních prostředí. Může tak velice snadno nastat situace, kdy pracovník testovacího oddělení zapomene na své staré prostředí a to bude zbytečně zabírat výpočetní zdroje, kapacitu úložiště a třeba i veřejnou IP adresu. Samozřejmě by bylo možné zadat pracovníkům oddělení administrátorů za úkol monitorovat a vyhledávat stará a nepoužívaná prostředí na smazání, avšak opět by tak vznikla rutinní manuální činnost, která by zbytečně zaměstnávala pracovníky na 45

55 Prostředí pro nasazení neproduktivních činnostech. Navíc by se také opět jednalo o proces plný komunikace, s majiteli daného testovacího prostředí, aby bylo možné zjistit, zda se jedná o nepotřebné prostředí a může tedy být odstraněno. Z hlediska monitorování by bylo vhodné, aby pracovníci testovacího oddělení měli přístup k monitoringu vlastních testovacích prostředí a mohli je sami snadno spravovat a využívat asistence pracovníků administrátorského oddělení až v případě, kdy to bude opravdu nutné. Vzhledem ke skutečnosti, že testovací prostředí jsou připravována v prostředí, kde se nachází i produkční aplikace, je pochopitelné, že přístup musí zůstat pouze povolaným pracovníkům. V případě využití cloudové technologie, by jednotliví pracovníci testovacího oddělení měli vlastní tenant, který by poskytoval požadované možnosti monitorování, a zároveň by nebyl dán přístup do nesprávných míst. bezpečnost Bezpečnost také není zrovna silnou stránkou aktuálního procesu přípravy testovacích prostředí. Testovací prostředí jsou sice vytvářeny v nástroji pro virtualizaci, avšak na fyzickém serveru, ve stejném prostředí, kde se nachází i instance s produkčními aplikacemi, jejich výpadek by měl kritické následky pro chod společnosti. Dalším rizikem je případ, kdy by se testovací prostředí dostalo do nepovolaných rukou například nějakého kybernetického útočníka. Díky neexistujícímu oddělení jednotlivých testovacích prostředí mezi sebou, ale také mezi testovacími a produkčními prostředími, by případný útočník měl značně usnadněnou práci a mohl by napáchat velké škody na podnikových výpočetních systémech. Bezpečnost by tedy také měla být posílena. V případě využití serverové virtualizace by byl ideální přístup takový, kdy by pro přípravu testovacích prostředí byly vyčleněny samostatné servery, které by byly odděleny od produkčních aplikací a měli by přístup pouze k nezbytným komponentám informační sítě společnosti. V případě cloudových technologií se nabízí vytvoření tenatů pro jednotlivé pracovníky testovacího oddělení, kteří jsou tak navzájem odděleni samotnou cloudovou platformou. časová náročnost 46

56 Prostředí pro nasazení Čas je také velice důležitým problémem daného procesu. V aktuálním procesu není nijak stanoveno, jak dlouho bude proces přípravy a tedy i samotného testování trvat. Časové kvantum potřebné k dokončení testování je závislé na rychlosti vytvoření testovacího prostředí a to je závislé na rychlosti reakce administrátorského pracovníka na žádost a také na nutných úkonech, které je třeba provést při vytváření prostředí. Nejhorším případem je situace, kdy dojde k zamítnutí přípravy testovacího prostředí. V takové situaci je dle firemní politiky předepsáno vyčkat do dalšího dne, než bude znovu kontaktováno oddělení administrátorů s novým požadavkem na testovací prostředí. Není tak zpomalován postup jen testovacího oddělení, ale také oddělení vývoje. Nelze totiž pokračovat ve vývoji navazujících funkcionalit bez otestovaní poslední verze. Měla by tedy existovat možnost vytvořit časový plán se standardizovanou dobou nutnou pro vytvoření testovacího prostředí, aby bylo možné efektivně plánovat celý proces vývoje softwarové aplikace. Zároveň je vhodné v procesu minimalizovat nebo úplně eliminovat čekání pro maximální efektivitu. náklady Náklady na proces jsou spojeny s jednotlivými, výše zmíněnými, negativy aktuálního procesu. Náklady narůstají při časových prodlevách, nejvíce pak v momentu, kdy jsou pracovníci nuceni čekat a nemohou tak pokračovat v práci. Dalším faktorem ovlivňujícím náklady je množství testovacích prostředí a tím vzniklé náklady za výpočetní zdroje. Bez vhodného řešení monitoringu, které bude přístupné i testovacímu oddělení, bude docházet k zapomenutým prostředím, která tak budou nejen blokovat výpočetní zdroje, ale také zvyšovat náklady. Manuální úkony mají také velký vliv na náklady jelikož pracovníci, kteří je vykonávají nemohou svůj čas věnovat produktivnějším činnostem. Snížení nákladů je tak jedním z cílů, které by měl nový proces zlepšit. Dosáhnou požadovaného snížení nákladů je možné vhodným řešení výše zmíněných negativ. nízká modularita Modularita procesu by sama o sobě až takovým negativem nebyla, avšak pouze do okamžiku, kdy by do procesu měly být přidány nové úkony. V takovém pří- 47

57 Prostředí pro nasazení padě dojde ke komplikaci již tak dosti komplikovaného procesu, což bude mít mnohé negativní následky, jako například prodloužení nutné doby pro provedení procesu. Proces by tedy bylo vhodné co nejvíce zjednodušit, aby bylo možné v případě potřeby snadno přidávat nové úkony, avšak zjednodušení procesu by nijak nemělo ubrat na pokrytých oblastech Návrh nového procesu Vlastní návrh průběhu přípravy testovacího prostředí se snaží o eliminaci negativ aktuálního průběh, které byly zmíněny v předchozí části. Při návrhu bylo vycházeno z následujících předpokladů: automatizované úkony V navrženém postupu je počítáno, s připravením a využíváním automatizačních nástrojů. Hlavní důraz je kladen na možnost automatizovaného vytváření prostředí například využitím šablon. Pro snadné uvedení prostředí do výchozího stavu, v případě, že tak nebylo vytvořeno, je využíváno nástrojů konfiguračního managementu. Oba tyto předpoklady značně zjednodušují proveditelnost procesu a také šetří čas pracovníků. využití cloudové platformy Díky používání cloudové platformy je možné vytvářet oddělená prostředí (tenanty) pro jednotlivé členy testovacího oddělení, zároveň jsou tato oddělení díky cloudové platformě odděleny od zbylé infrastruktury. Jednotlivé tenanty mají alokované vlastní zdroje pro užívání, které spravují samotní pracovníci testovacího oddělení. Není tak nutné předávat řízení předávat řízení administrátorským pracovníkům při správě testovacích prostředí. Hlavní důraz byl při návrhu kladen na zjednodušení procesu při zachování všech nutných úkonů. Minimalizace komunikace a předávání řízení procesu. Jednoznačnější definování odpovědnosti za úkony. Návrh nového procesu přípravy testovacího prostředí je znázorněn následujícím diagramem

58 Prostředí pro nasazení Obrázek 4.2: Návrh procesu přípravy testovacího prostředí Hlediska pro srovnání Pro srovnání původního a nového procesu bylo stanoveno několik hledisek, dle kterých bude provedeno srovnání. Hlediska byla sestavena tak, aby bylo co nejpodrobněji prozkoumáno, které řešení je vhodnější pro proces přípravy testovacích prostředí. automatizace procesu Automatizací procesu je rozuměna minimalizace manuálních úkonů, které musí vykonávat samotní pracovníci. Je tak využíváno různých šablon a nástrojů pro automatickou přípravu prostředí, jako je například konfigurační management. Hlavním přínosem je zefektivnění celého procesu a odlehčení pracovníkům od rutinní práce. 49

59 Prostředí pro nasazení časová náročnost procesu Proces by měl proběhnout v co nejkratší možné době,pokud možno bez jakýchkoli prodlev vzniklých při čekání. technická náročnost procesu Technická náročnost by měla být pouze v nutných mezích, aby byly vhodně pokryty požadavky a řešeny negativa stávajícího procesu. homogenita připraveného prostředí Od procesu je vyžadováno, aby byla vytvářená prostředí homogenní a testování tak probíhalo vždy za shodných podmínek. Není však míněno testováno pouze na jediné platformě, avšak testování za přítomnosti všech vyžadovaných komponent. přehlednost procesu Přehlednosti procesu může být dosaženo především díky monitoringu. Monitoringem je možné odhalovat existujících testovacích prostředí pracovníkům testovacího oddělení a tím minimalizaci nežádoucích výdajů za zapomenutá prostředí. Další možností je zjednodušení procesu pro jasný průběh. náklady na proces Vítaným přínosem nového procesu je snížení nákladů na celý proces a také jejich snadnější vyčíslení, hlavně díky časovému odhadu. Zároveň by nový proces neměl dosahovat přílišné technické náročnosti, která by vyžadovala nákladná školení pro pracovníky, kteří je budou vykonávat. nutná komunikace v procesu Komunikace by v procesu měla být v co nejmenší míře a to především z důvodu, aby nedocházelo k nežádoucímu předávání řízení procesu. Zároveň tak bude pracovníkům odlehčeno od množství mailů, nebo jiných využívaných komunikačních prostředků, na které musí denně reagovat. Samozřejmě není žádoucí eliminovat komunikaci vedoucí za efektivním a kvalitním prováděním procesu. modularita procesu 50

60 Prostředí pro nasazení Proces je navržen tak, aby bylo snadné ho v případě potřeby modulovat pro začlenění nových úkonů. Zároveň však modularita neubírá na komplexnosti celého procesu, který musí pokrývat všechny potřebné oblasti Srovnání V této části je provedeno srovnání aktuálního a navrženého postupu, které byly popsány v předchozích částech, dle specifik uvedených v předchozí části. Nejdříve je popsáno srovnání dle jednotlivých hledisek a v závěru je uvedena shrnující tabulka. Prvním hlediskem pro srovnání obou procesů byla automatizace procesu. Automatizace je v procesu využívána při vytváření testovacích prostředí prostřednictvím šablon a konfiguračního managementu. Pochopitelně by bylo možné připravit i automatizaci pro pravidelné vytváření testovacích prostředí, je však otázka, zda je vydávání nových verzí softwaru dostatečně pravidelné, aby bylo vhodné tuto funkcionalitu využít. V prvním hledisku je tedy vhodnější nové řešení. Druhým srovnávacím hlediskem byla časová náročnost. Z hlediska časové náročnosti je klíčové, aby v procesu bylo co nejméně možností ke vzniku prostojů. Prostoje vznikají, jak již bylo výše popsáno, hlavně při komunikaci a předávání řízení procesu. Jak je z digramů vidět, nově navržený proces značně snížil počet situací, kdy dochází k předávání řízení. Jedinou situací kdy může docházet k čekání testovacího oddělení je situace, kdy nastane v cloudovém prostředí chyba. Zároveň také byla eliminována situace, kdy je čekáno a periodicky dotazováno na prostředky pro testovací prostředí. Vzhledem k rychlostem cloudových řešení, s jejichž nasazením se počítá, v úkonech,které by byly využívány v tomto procesu, se odhadovaná doba potřebná pro přípravu testovacího prostředí může pohybovat v řádech jednotek minut pro jednodušší prostředí. Technická náročnost byla třetím hlediskem pro srovnání obou procesů. Srovnání dle technické náročnosti může být v případě znalosti pouze jednoho řešení silně subjektivní. Samozřejmé je, že pracovníci zvyklí na svůj postup jej budou považovat za jednodušší. Při dostatečné analýze je však tato subjektivnost odstraněna. Technická náročnost spojena se správou cloudového prostředí je snadnější, než přístup původní, jelikož cloudová prostředí využívají webová rozhraní, ve kterých je správa obdobná jako v oblasti služeb veřejných cloudů. Rozdílem je však skutečnost, že správu testo- 51

61 Prostředí pro nasazení vacích prostředí provádějí samotní pracovníci testovacího oddělení. Bude tedy nutné, aby testovací oddělení bylo zaškolené na nové prostředí. Zde by se dalo konstatovat, že nové řešení bude pro pracovníky testovacího oddělení mírně technicky náročnější než předchozí řešení. Čtvrtým hlediskem byla homogenita připravovaných prostředí. Homogenita prostředí je pro testování důležitá, aby nevznikaly potíže s testováním a falešně nahlášené chyby z důvodu nekonzistentního prostředí. S využitím konfiguračního managementu a šablon pro testovací prostředí je dosažení homogenity snadnější a rychlejší. Pátým hlediskem byla přehlednost procesu. Již při pohledu na oba digramy je zřetelné, že v druhém případě došlo ke značnému zjednodušení a také ucelení odpovědností. Přehlednosti je také dosaženo díky snadnějšímu monitoringu testovacích prostředí, které je zajištěno cloudovou platformou. Je tak možné říci, že navržený proces přinesl lepší přehlednost. Náklady na proces byly dalším hlediskem srovnání. Vstupní náklady na zavedení nového řešení budou pochopitelně vyšší, než náklady na aktuální provoz. V delším časovém horizontu má však nové řešení díky optimalizaci procesu a nabízeným možnostem, vyplývajících z cloudového řešení, silný potenciál mít nižší náklady. Předposledním hlediskem byla nutnost komunikace při procesu. Eliminace nežádoucí komunikace byla jedním z hlavních hledisek, se kterými bylo nové řešení navrženo. V diagramu je patrné, že komunikace byla značně omezena, což má přínos i pro další hlediska. Na závěr je srovnávána modularita procesu. Z hlediska modularity je na tom lépe navržené řešení, a to především z důvodu zjednodušení, čímž je snadnější i začlenění nových úkonů. Nyní následuje shrnující tabulka

62 Srovnání cloudových platforem Tabulka 4.1: Tabulka srovnání procesů přípravy testovacího prostředí Hlediska Aktuální proces Navržený proces automatizace časová náročnost technická náročnost homogenita prostředí přehlednost náklady nutnost komunikace modularita žádné automatizované prvky závislá na rychlosti komunikace, čekací cyklus až v řádu dnů známé prostředí, jednodušší pro testovací oddělení, náročnější pro administrátory manuální zaručení homogenity proces není přehledný, těžko se určují zodpovědnosti známé udržovací náklady nutná častá komunikace obtížná modularita kvůli komplikovanosti automatizace přípravy prostředí v řádu minut nutné zaškolení, mírný nárůst pro testovací oddělení homogenní prostředí díky automatizaci přehlednější řešení, snadnější určení odpovědností vyšší vstupní náklady, návratnost v čase komunikace nutná pouze při chybě vyšší modularita díky přehlednosti 4.2 Srovnání cloudových platforem V této části práce bude provedeno srovnání cloudových platforem, která byla popsána již dříve, konkrétně tedy OpenStack a VMware vcloud. Nejdříve je popsáno srovnání dle jednotlivých hledisek a v závěru je uvedena shrnující tabulka Hlediska pro srovnání Pro srovnání výše představených cloudových platforem byla stanovena následující hlediska. Hlediska byla zvolena tak, aby byly shrnuty výhody a nevýhody jed- 53

63 Srovnání cloudových platforem notlivých platforem. komplexnost platformy Komplexností platformy je rozuměno množství dostupných funkcí, provázanost jednotlivých částí platformy i celková soudržnost produktu. Zahrnuta je i možnost rozšiřování platformy. otevřenost platformy Doby kdy open-source nástroje nebyli ve společnostech příliš akceptovány jsou již pryč a open-source projekty jsou na vzestupu. Výhodou je například fakt, že open-source nepřestane kvůli obchodní politice podporovat určité funkcionality a také nepřináší nákladné licencování. Další výhodou open-source je skutečnost, že technologie je dostupná všem a může tedy snadněji vznikat velké množství doplňků, které rozšiřují jejich funkcionalitu. Má však i své nedostatky a to třeba obtížnější dostupností dokumentace či podpory. dostupnost dokumentace Dostupná a kvalitní dokumentace je velmi důležitá pro správně využívání nástroje. Využívání nezdokumentovaného nástroje může být velmi rizikové a málokterá společnost se pro takový nástroj v praxi rozhodne. dostupnost podpory Kvalitní a dostupná podpora je stejně důležitá jako samotná dokumentace. Ačkoli mají společnosti vlastní týmy techniků informačních technologií, běžně jsou zakupovány podpory od společností specializující se právě na dané nástroje Srovnání Popis obou platforem byl proveden v předchozí kapitole, avšak vzhledem k rozsahu byly vybrány pouze některé oblasti. Množství služeb dostupných ve zmíněných cloudových platformách je velice široký a není předmětem této práce jejich podrobný popis. Jak OpenStack tak vcloud Suite jsou velice komplexní platformy s množstvím funkcí, avšak OpenStack je poněkud náročnější na správu. Důležitou součástí je i podpora hypervisor nástrojů. OpenStack podporuje všechny myslitelné jako jsou XEN, 54

64 Srovnání cloudových platforem KVM, Hyper-V ESXi. VMware vcloud Suite až do verze 7 podporoval pouze své nástroje, ačkoli nyní s příchodem licenční politiky PLU slibuje podporu libovolných hypervisor nástrojů, není tato skutečnost dosud potvrzena a dostatečně otestována v praxi, navíc stále existuje možnost, že v příští verzi podpora opět zmizí. Přístup k OpenStack platformě je realizován skrze webové rozhraní, které lze různě upravovat zatímco k připojení k vcloud nástrojům je někdy skrze klientskou aplikaci a někdy skrze webové rozhraní. Podpora uložených formátů image je u OpenStack neomezená, zatímco vcloud podporuje pouze OVF. Platforma OpenStack nabízí na rozdíl od vcloud i volně dostupná API, což má značný vliv na rozšiřitelnost celé platformy. U obou platforem je samozřejmostí i live migrace nebo HA (High Availability - vysoká dostupnost). Z hlediska komplexnosti je tedy zřejmé, že ani jedna z platforem výrazně nezaostává v nabízených funkcích, avšak existují rozdíly v podporovaných nástrojích. Srovnání z hlediska otevřenosti je jednoznačně v neprospěch vcloud platformy jakožto proprietárního řešení. Veškeré funkce i podpora jsou plánovány společností VMware bez zásahu komunity. Přístupná nejsou většinou ani API jednotlivých nástrojů, na které by bylo možné vytvořit rozšíření. Nevýhodou open-source řešení můžou být komplikace vznikající z důvodů přílišné univerzálnosti. Obě platformy disponují velice rozsáhlou a kvalitní dokumentací, která je navíc doplněna odbornou literaturou, a také množstvím zkušeností uživatelů dostupných na internetových diskuzních fórech. Zde tedy není v nevýhodě ani jedna platforma. Při hledání podpory vcloud platformy je samozřejmě v nabídce samotný VMware. Pro OpenStack platformu je výběr mnohem širší. V případě, kdy je zakoupeno nasazení platformy se většinou jedná o platformu s různými funkcemi přidanými dodavatelskou společností. poté je vhodné využít podporu právě této společnosti. V případě, kdy se jedná o standardní OpenStack platformu je výběr širší. Nevýhodou je, že není dostupná podpora ke všem existujícím modulům platformy. 55

65 Srovnání nástrojů aplikačního katalogu Tabulka 4.2: Tabulka srovnání cloudových platforem Hlediska OpenStack vcloud Suite komplexnost platformy otevřenost platformy dostupnost dokumentace dostupnost podpory velice univerzální platforma, množství funkcí z modulů, obtížnější na správu, široká podpora hypevisor nástrojů, podpora image formátů, jednotný přístup skrze GUI open-source, dostupné API kvalitní dokumentace, odborná literatura, spousta informací na diskuzních fórech dostatek společností nabízejících podporu, nejsou podporovány všechny moduly množství funkcí VMware nástrojů, snadná správa, neověřená podpora hypervisor nástrojů, omezená podpora image formátů proprietární platforma kvalitní oficiální VMware dokumentace, odborná literatura VMware podpora 4.3 Srovnání nástrojů aplikačního katalogu V této části práce bude provedeno srovnání produktů nabízející funkcionalitu aplikačního katalogu. Jednotlivé nástroje již byly popsány dříve. Nejdříve je popsáno srovnání dle jednotlivých hledisek a v závěru je uvedena shrnující tabulka Hlediska pro srovnání Nástroje nabízející funkce aplikačního katalogu byly srovnávány dle následujících hledisek. nabízené funkce 56

66 Srovnání nástrojů aplikačního katalogu Nástroj by měl poskytovat dostatečné funkce pro pokrytí širokého spektra podnikových požadavků. Aplikace je vhodné i správně nakonfigurovat. otevřenost nástroje Důvody pro zařazení hlediska otevřenosti jsou shodná se srovnáváním cloudových platforem. dostupnost dokumentace Důvody pro zařazení hlediska dostupnosti dokumentace jsou shodná se srovnáváním cloudových platforem. dostupnost podpory Důvody pro zařazení hlediska dostupnosti podpory jsou shodná se srovnáváním cloudových platforem. spojitost s ostatními nástroji Možnost spolupráce nástrojů s ostatními, které vytváří cloudové prostředí je klíčová a jejich nasazení by bez ní nemělo smysl. vývoj nových aplikací Způsob jakým jsou připravovány nové aplikace, je velmi důležitý a měl by být jednoduchý na používání. podpora platforem Velkou výhodou je, jestliže nástroj umožňuje používat rozlišná cloudová prostředí, lze tak snadněji propojovat již implementovaná datová centra Srovnání Při popisu nástrojů pro aplikační katalog bylo možné si všimnout, že pojem není zcela jednoznačný. Především nástroj vapp, který je součástí VMware vcloud Suite uvádí, že je určen pro tvorbu aplikačního katalogu, avšak aplikace jím vytvářené jsou ve smyslu souboru VM instancí společně s úložištěm a síťovou infrastrukturou podobně, jako je tomu u modulu Heat platformy OpenStack, který je však primárně určen pro orchestraci infrastruktury. 57

67 Srovnání nástrojů aplikačního katalogu Při srovnávání z hlediska funkcionality nástroje se patrně nejvíce projeví rozlišnost pojetí aplikačního katalogu. VMware vapp jakožto součást vcloud Suite je zaměřen na vytváření komplexních balíčků cloudových zdrojů. Balíček se skládá z VM instance, síťové infrastruktury, úložiště a dodatečné konfigurace. Pro přímé srovnání je nejvhodnější modul Heat. Oba nástroje vytváří balíčky zdrojů, Heat skrze šablonu vytvořenou v deklarativním jazyce a vapp skrze grafické rozhraní klientské aplikace. V případě modulu Heat je velice snadné použít bash script, který se postará o následné nakonfigurování a případné nasazení aplikací. V případě vapp je nutné vše udělat ručně a až následně vyexportovat OVF balíček, který je možné různě přenášet. Naproti tomu Horizon Apps je nástroj přímo určený pro poskytování virtualizovaných aplikací. Jsou zde vytvářeny aplikace, které jsou vybírány z prostředí serveru a následně přidány do katalogu pro uživatele. Nevýhodou je omezení pouze na aplikace operačního systému Windows. Veškerá manipulace s katalogem je prováděna skrze grafické rozhraní klientské aplikace a v případě koncového uživatele i skrze webový prohlížeč. Další funkcionalitou jsou například virtualizované desktopy. OpenStack modul Murano je určen primárně pro vytváření aplikačního katalogu. V jádru se příliš neliší od modulu Heat. Hlavním rozdílem je skrze webový prohlížeč dostupné uživatelské rozhraní, určené k výběru aplikace. Jednotlivé aplikace jsou však tvořeny obdobně jako v modulu Heat šablonou a následně spouštěným scriptem, který uvede prostředí do požadovaného stavu. Funkcionalita posledního zástupce, a to CSB, je určena pro poskytnutí aplikačního katalogu, přičemž jeho součástí mají být balíčky zdrojů i softwarové aplikace. CSB navíc zahrnuje ve svém rozhraní přehledně zobrazené informace o ceně jednotlivých aplikací, což je funkcionalita, která u ostatních nástrojů není nativně zahrnuta a je tedy nutné ji případně zahrnout jinými nástroji. Otevřenost nástroje je shodná s tím, jak tomu bylo u cloudových platforem. Nástroje společnosti VMware jsou proprietární a často nenabízí otevřená API pro tvorbu vlastních nástrojů. Moduly OpenStack jsou naopak open-source a vše je tedy volně dostupné. Poslední nástroj CSB je komerční řešení vyvinuté společností Mirantis. Důležitost dokumentace byla již zmíněna při porovnávání cloudových platforem, zde je to s dokumentací shodné. OpenStack moduly disponují kvalitní, komunitou vytvořenou dokumentací a také množstvím zkušeností na diskuzních fórech. VMware nástroje disponují oficiální dokumentací, odbornou literaturou a také informacemi na 58

68 Srovnání nástrojů aplikačního katalogu diskuzních fórech. Nástroj CSB je stále částečně ve fázi vývoje a kompletní dokumentace ještě není zhotovena, při této práci bylo čerpáno z její aktuální verze, která bude dokončena společně s aplikací a bude dostupná se samotným nástrojem. Stejně jako dokumentace i podpora již byla zmíněna při srovnávání cloudových platforem. Opět je zde oficiální podpora pro nástroje VMware. Podpora pro moduly OpenStack je shodně nabízena většinou ze strany dodavatele cloudového řešení, případně jinou společností, kde je podpora modulů Murano a Heat běžně dostupná. Podpora nástroje CSB je závislá na jejím dodavateli jakožto tvůrci. Jelikož vapp je součástí vcloud není zde žádný problém s návazností na ostatní nástroje vcloud Suite platformy. V případě Horizon Apps se jedná o funkcionalitu nástroje Horizon, který je taktéž součástí vcloud platformy. Souhrnně lze tedy říci, že spojitost s VMware nástroji je velice dobrá, jelikož jsou všechny od stejného společnosti a jsou určeny pro spolupráci. V případě OpenStack modulů je jejich spolupráce na vysoké úrovni, především díky otevřeným API, na které jsou navázány další moduly OpenStack platformy. Oba moduly přímo využívají základní moduly platformy, které je možné snadno monitorovat, například pro účely billingu. Nástroj CSB není přímo určen jako součást cloudové platformy, proto má v sobě již zabudované například prvky pro billing, s ostatními nástroji komunikuje skrze jejich API. K procesu vývoje nových aplikací je u nástrojů VMware přistupováno skrze grafické rozhraní klientské aplikace a v případě vapp je dále nutné dovést prostředí do požadovaného stavu manuálně a až následně vytvořit OVF balíček. Tento postup tedy nevyužívá téměř žádnou automatizaci. V nástroji Horizon Apps je také vývoj aplikací prováděn skrze grafické rozhraní, zde se vybírá z aplikací na serveru, omezení je pouze na aplikace operačního systému Windows kvůli protokolu RDHS. Moduly platformy Open- Stack využívají k tvorbě nových aplikací deklarativní jazyk ve spojení s bash scripty. Tento přístup nabízí značně vyšší znovupoužitelnost než prostředí grafické aplikace u VMware nástrojů. V případě CSB nástroje je několik přístupů, jak již bylo popsáno v předchozí kapitole, například využití existujících zdrojů a konfiguračního scriptu nebo vytvoření image z nakonfigurovaného prostředí. Nástroje VMware jsou určené výhradně pro VMware prostředí, a není zde podpora pro jiné platformy. OpenStack modul Murano umožňuje použití nejenom pro OpenStack, ale také pro VMWare a Amazon. V případě modulu Heat jsou podporovány 59

69 Srovnání nástrojů aplikačního katalogu šablony pro prostředí Amazon AWS. Nástroj CSB je přímo vyvíjen s cílem zastřešit cloudové platformy a poskytnout řešení nezávisle na platformě. Lze využít OpenStack, stejně tak jako VMware, Microsoft Azure, či Amazon AWS jak je znázorněno v obrázku 3.7 v předchozí kapitole. Nyní následují shrnující tabulky srovnání Tabulka 4.3: Tabulka srovnání nástrojů pro aplikační katalog 1 Hlediska VMware vapp VMware Horizon Apps funkce nástroje otevřenost nástroje dostupnost dokumentace dostupnost podpory spojitost s ostatními nástroji vývoj nových aplikací podpora platforem balíček zdrojů a konfigurace proprietární nástroj, často nepřístupná API oficiální dokumentace VMware, odborná literatura, diskuzní fóra oficiální podpora VMware spojitost v rámci VMware nástrojů grafické rozhraní klientské apliakce, manuální uvedení do požadovaného stavu, import OVF balíčku pouze VMware prostředí virtualizované desktopy, katalog softwarových aplikací proprietární nástroj, často nepřístupná API oficiální dokumentace VMware, odborná literatura, diskuzní fóra oficiální podpora VMware spojitost v rámci VMware nástrojů grafické rozhraní klientské apliakce, výběr z aplikací serveru pouze VMware prostředí 60

70 Srovnání nástrojů aplikačního katalogu Tabulka 4.4: Tabulka srovnání nástrojů pro aplikační katalog 2 Hlediska Murano Heat CSB Funkce nástroje otevřenost nástroje dostupnost dokumentace dostupnost podpory spojitost s ostatními nástroji vývoj nových aplikací podpora platforem softwarové aplikace, primárně určen k aplikačnímu katalogu zdroje s konfigurací a bash scriptem, primárně určen pro orchestraci aplikace jakožto zdroje i software, implementovaný billing open-source open-source proprietární nástroj komunitní komunitní dokumentace dokumentace dokumentace od OpenStack, diskuzní OpenStack, diskuzní dodavatele fóra, odborná fóra, odborná literatura literatura běžně podporovaný běžně podporovaný modul v rámci modul v rámci ze strany dodavatele OpenStack OpenStack ostatní moduly ostatní moduly OpenStack, otevřená OpenStack, otevřená zastřešuje nižší API, spolupráce s API, spolupráce s nástroje VMware a Amazon VMware a Amazon uvedení do stavu a deklarativní jazyk a deklarativní jazyk a vytvoření image, bash script bash script šablona zdrojů a konfigurační script VMware, Amazon OpenStack, Amazon, OpenStack, Amazon AWS, Microsoft VMware AWS Azure, OpenStack, Rackspace... 61

71 Srovnání nástrojů pro workflow 4.4 Srovnání nástrojů pro workflow V této části práce bude provedeno srovnání nástrojů určených ke správě workflow. Jednotlivé nástroje byly popsány v kapitole 3. Srovnání bude provedeno mezi VMware vcenter Orchestrator a moduly Mistral a Congress platfromy Openstack Hlediska pro srovnání Pro srovnání nástrojů s funkcionalitou pro workflow byla stanovena následující hlediska nabízené funkce Nástroj by měl poskytovat dostatečné funkce pro pokrytí širokého spektra podnikových požadavků. Důležitá jsou například upozornění prostřednictvím mailové zprávy. otevřenost nástroje Důvody pro zařazení hlediska otevřenosti jsou shodná se srovnáváním cloudových platforem. dostupnost dokumentace Důvody pro zařazení hlediska dostupnosti dokumentace jsou shodná se srovnáváním cloudových platforem. dostupnost podpory Důvody pro zařazení hlediska dostupnosti podpory jsou shodná se srovnáváním cloudových platforem. spojitost s ostatními nástroji Možnost spolupráce nástrojů s ostatními, které vytváří cloudové prostředí je klíčová a jejich nasazení by bez ní nemělo smysl. vývoj nových workflow Způsob jakým jsou připravována nová workflow, je velmi důležitý a měl by být jednoduchý na používání. 62

72 Srovnání nástrojů pro workflow Srovnání Již při popisu jednotlivých nástrojů pro tvorbu workflow bylo patrné, že možnosti schvalovacího workflow jako takového nenabízí plně ani jeden nástroj. Zatímco VMware vcenter Orchestrator a OpenStack modul Mistral byly zaměřeny na workflow jakožto posloupnost úloh, které mají být provedeny v rámci průběhu komplexního procesu, OpenStack modul Congress se zabývá implementací podnikových pravidel do cloudového prostředí. Díky otevřenosti OpenStack modulů však existuje možnost vlastní implementace potřebných funkcionalit. VMware pro své řešení vcloud Suite jiný nástroj nenabízí a moduly Mistral a Congress jsou na vrženy pro vzájemnou spolupráci, proto bude srovnání provedeno jako spojení Congress a Mistral proti VMware vcenter Orcehstrator. Nabízené funkce jsou u obou porovnávaných nástrojů obdobné, ani u jednoho nechybí klasické funkce spolupracující s ostatními nástroji své platformy pro tvorbu workflow a možnosti jako zasílání mailových zpráv nebo plánované spuštění. Pro začlenění podnikových pravidel je vhodnější spojení OpenStack nástrojů, jelikož je to primární účel modulu Congress. OpenStack modul Mistral na rozdíl od vcenter Orchestrator umožňuje používat kromě datových výstupů také vstupy. Díky tomu existuje možný potenciál k vytvoření skutečného schvalovacího workflow. Při srovnávání otevřenosti je celkem jasné, že o něm nelze mluvit v případě nástroje VMware vcenter Orcehstrator. VMware je velká společnost, avšak je řízena v určitém směru svým vedením. Ačkoli je cílem tohoto vedení uspokojit poptávku zákazníka, přístup k němu je takový, že je nabízen ucelený produkt. Naproti tomu open-source řešení je řízeno komunitou a nedochází zde k rozhodnutí, která mohou znamenat například ukončení podpory určitého nástroje. Z tohoto hlediska je tedy spojení OpenStack modulů jednoznačně ve výhodě. Dostupnost dokumentace je, jak již bylo řečeno, velice důležitým hlediskem při výběru vhodného nástroje. Bez znalostí jak nástroj využívat a možností je získat zbývá pouze možnost využívání zakoupené podpory, jejíž využívání ve všech případech může znamenat nemalé náklady. Dokumentace obou produktů je na velice vysoké úrovni, obě obsahují popis nástroje, návod jak jej využívat i praktické příklady. To vše dostupné přes webové stránky VMware potažmo příslušného OpenStack modulu. Oba zmíněné moduly OpenStack platformy již disponují kvalitně zpracovanou dokumen- 63

73 Srovnání nástrojů pro workflow tací, nicméně u některých mladších modulů tomu tak být nemusí. V neposlední řadě by neměla být zapomenuta síla všemožných diskuzních portálů, která často obsahují ověřené postupy jak vyřešit danou situaci. Z pohledu dokumentace jsou tedy oba nástroje rovnocenné. Dostupnost podpory byla druhým hlediskem odvozený od open-source nástroje. Kvalitní podpora pro používané nástroje je velice důležitá hlavně v případě, kdy je funkce nástroje pro společnost kritická. Včasný a správný zásah podpory může společnosti ušetřit spoustu problémů a nákladů. V případě nástroje vcenter Orchestrator je v nabídce placená podpora přímo od společnosti VMware, navíc je také zdarma dostupný nástroj vcenter Server Support Assistant, který má mimo jiné poskytovat varovná hlášení ukazující na možný problém dříve než nastane. S moduly OpenStack platformy je to poněkud jiné, obvykle je podpora k OpenStack platformě dodáván společností, která jej pro svého zákazníka nasadila. Zároveň je však vhodné zmínit, že ne každá společnost nasazující OpenStack poskytuje podporu pro všechny moduly, které jsou k OpenStack platformě dostupné. Například společnost RedHat nenabízí podporu ani pro jeden ze dvou modulů. Z pohledu podpory je vhodnější nástroj vcenter Orchestrator. Spojitost s ostatními nástroji je pro vytvoření kvalitně fungujícího celku velice důležitá. Nástroje VMware jsou vytvářeny jedinou společností s cílem vytvořit cloudovou platformu, spolupráce s ostatními nástroji je zde tedy pochopitelná. Již z popisu VMware vcloud Suite platformy je možné si všimnout skutečnosti, že se nejedná o jediný komplexní nástroj, ale o spojení několika nástrojů, které dohromady vytváří konečnou platformu. U open-source platformy je tomu jinak, nový modul může vytvářet jiná komunita, pokud však chce, aby byl modul vhodně použitelný, musí správně spolupracovat s již existujícími a využívanými moduly OpenStack platformy. Příkladem je právě spojení modulů Mistral a Congress. V oblasti spojitosti s jinými nástroji jsou si tedy nástroje rovnocenné Vývoj nových workflow je v nástroji vcenter Orchestrator řešen přes grafické rozhraní. Vývoj v prostředí grafického rozhraní má samozřejmé své výhody, mezi které patří například jeho jednoduché používání. Jednoduché používání však může být zmařeno, pokud je nástroj příliš komplexní a grafické rozhraní zatěžuje uživatele velkým množstvím nastavení, ve kterých je nutné hledat. Vytváření workflow pro moduly Mistral a Congress je založeno na deklarativním jazyku, jehož příklad byl uveden 64

74 Srovnání nástrojů pro workflow při popisu modulů v předchozí kapitole. Grafické rozhraní je určitě vhodnější pro méně technické uživatele nástroje, naopak prostředí deklarativního jazyka uvítají techničtí pracovníci zvyklí pracovat s nástroji přes příkazy, což nabízí možnost znovupoužitelnosti již využitých částí workflow. Shrnutí provedeného srovnání je v následující tabulce 4.5. Tabulka 4.5: Tabulka srovnání nástrojů pro workflow Hlediska vcenter Orchestrator Mistral & Murano funkce nástroje otevřenost nástroje dostupnost dokumentace dostupnost podpory spojitost s ostatními nástroji vývoj nových workflow workflow, zprávy uzavřené dokumentace od VMware podpora od VMware spolupráce s nástroji vcloud Suite balíčku skrze GUI workflow, zprávy, podniková pravidla, vstupní a výstupní data open-source kvalitní dokumentace vývojářů modulu nenalezena společnost nabízející podporu spolupráce se všemi klíčovými moduly OpenStack skrze deklarativní jazyk 65

75 5 Realizace V následující kapitole bude popsána realizace, jejímž předmětem je navrhnout řešení samoobslužného portálu obsahující aplikační katalog. Při návrhu jsou vybrány nástroje popsané a porovnané výše. Za účelem konečného výběru byla provedena diskuze s pracovníky české pobočky společnosti Mirantis a.s. 5.1 Vybrané nástroje Nástroje byly vybírány tak, aby mohli nabídnout řešení nově navrženého procesu přípravy testovacích prostředí, které bylo uvedeno v předchozí kapitole. Vzhledem k výsledkům srovnání v minulé kapitole a obsahu diskuze s pracovníky společnosti Mirantis, byly pro konečný návrh řešení portálu vybrány následující nástroje. Pro roli cloudového prostředí byla zvolena open-source platforma OpenStack. Bylo tomu tak především díky její kvalitní dokumentaci, dostupnosti v podobě opensource a množství dostupných funkcionalit. Při analýze produktů společnosti VMware bylo nemalou komplikací obrovské množství nástrojů, přičemž každý měl svůj speciální název. Často má jeden produkt několik názvů kvůli rozdílným licencím a zahrnutým funkcionalitám. V konečném souhrnu tak společnost VMware sice nabízí sofistikované nástroje, avšak způsob orientace ve velkém množství pojmenování je velmi obtížný a často vyžaduje pracovníky zaměřeného výhradně na nástroje společnosti VMware. Cloudová platforma OpenStack bude spolupracovat s hypervisorem KVM, který je s ní nejčastěji používán. Pro automatizované nasazení bude použit nástroj konfiguračního managementu SaltStack, který je běžně využíván i ve společnosti Mirantis. Výběrem cloudové platformy OpenStack je tedy jasné, že ani další nástroje nebudou od společnosti VMware, nicméně tomu tak není pouze z důvodu samotné cloudové platformy. Funkce nabízené nástroji společnosti VMware nejsou k danému účelu příliš 66

76 Architektura vhodné. Velká část správy VMware nástrojů je prováděna skrze klientské aplikace, kam je směřováno i využívání aplikačního katalogu, tím je potlačena možnost univerzálního využití a dostupnosti odkudkoli. Dalším negativem vedoucím k zavrhnutí VMware nástrojů jej jejich uzavřenost, která vede k nutnosti využívání pouze nástrojů společnosti VMware. Operačním systémem, na kterém bude OpenStack platforma postavena byla zvolena linuxová distribuce Ubuntu. Ohledně nástrojů pro schvalovací workflow se dospělo k závěru, že vzhledem k neexistujícímu řešení, které by nabízelo možnosti schvalování postupů skrze odpovídající datový vstup a výstup, bude od jeho zahrnutí do konečného řešení upuštěno. K tomuto rozhodnutí přispěla i skutečnost, že s jednalo o volitelný požadavek. Aplikační katalog bude pro řešení implementován za pomocí nástroje CSB. 5.2 Architektura Pro účely konečného řešení byla navržena architektura zobrazující návaznost a využití jednotlivých vybraných nástrojů. Logical Architecture Frontend CSB Backend OpenStack (SaltMinion) Salt SaltMaster Git Horizon Nova Glance User Heat Neutron Git Keystone Cinder Salt Admin Instances VM #1 VM #2 VM #3 Obrázek 5.1: Logická architektura navrženého prostředí Obrázek 5.1 zobrazuje komunikaci jednotlivých části navržené architektury. Při pohledu ze strany uživatele je vše inicializováno skrze vyžádání prostředí ve frontend rozhraní CSB nástroje. Požadavek je předán na backend, který převede žádost do takového 67

77 Proces objednání prostředí tvaru, aby jej bylo možné zpracovat na cílové platformě, zde OpenStack. Prostředí jsou v platformě OpenStack připravována z modulu pro orchestraci Heat, ten přistoupí k modulu Keystone, aby byla ověřena identita v rámci OpenStack platformy. Následně jsou skrze jednotlivé moduly připraveny části pro instance jako bootovací image z modulu Glance, který je předán modulu Nova při vytváření instance samotné. Po dokončení přípravy prostředí je přístupné uživateli, který si jej vyžádal skrze přiřazenou IP adresu. Přístup admin uživatele spočívá v plném přístup ke všem třem logickým částem architektury. Mimo možnosti standardního uživatele tedy muže přímo přistupovat za účelem správy k backend části CSB, i k SaltMaster komponentě, skrze kterou může využívat možnosti SaltStack nástroje ke správě OpenStack částí, které jsou v roli minion, což znázorňuje i šipka vedoucí od Salt k OpenStack komponentě. SaltMaster komponenta uchovává formule a metadata potřebná pro konfigurací prostředí do požadovaného stavu. 5.3 Proces objednání prostředí V následující části je popsán postup procesu při zakládání žádosti o prostředí skrze CSB frontend. Proces je zachycen obrázkem 5.2. Obrázek 5.2: Proces objednání prostředí Proces začíná tím, že uživatel založí objednávku a následně je předáno řízení CSB. Po nastavení parametrů objednávky následuje její odeslání, kde je posouzeno, zda se jedná o velkou objednávku, při tomto posouzení se zahrnuje počet instancí v objed- 68