Virtualizační platformy, kontejnerové technologie a Cloud služby Virtualization Platform, Container Technology and Cloud Services

Transcription

1 VŠB Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky Virtualizační platformy, kontejnerové technologie a Cloud služby Virtualization Platform, Container Technology and Cloud Services 2018 Jakub Kačík

2

3

4

5

6 Rád by som predovšetkým poďakoval vedúcemu bakalárskej práce Ing. Radoslavovi Fasugovi, Ph.D. za príkladné vedenie, cenné rady a všetok venovaný čas. Ďakujem taktiež pánovi Ing. Jiřímu Rydelovi za ochotu a pomoc pri riešení technických problémov s virtuálnymi servermi. V neposlednom rade ďakujem svojej rodine a priateľom za podporu počas celého štúdia.

7 Abstrakt Táto bakalárska práca sa zaoberá analýzou virtualizačných platforiem, kontajnerových technológií a cloud služieb pre potreby prevádzkovania rozsiahlych informačných systémov. Cieľom práce je prevedenie ukážkového informačného systému do prostredia Docker kontajnerov. Teoretická časť popisuje problematiku vývoja rozsiahlych informačných systémov a porovnáva virtualizačné platformy od spoločností VMware, Citrix, Red Hat a Microsoft a taktiež obsahuje porovnanie cloud službieb od poskytovateľov Amazon, Microsoft a Google. Ďalej má za úlohu zoznámiť čitateľa s kontajnerovými technológiami so zameraním na platformu Docker. Súčasťou práce je veľké množstvo praktických ukážok popisujúcich vytváranie a spúšťanie kontajnerov. Praktická časť zahŕňa návrh rozdelenia projektu do kontajnerov, vytvorenie Dockerfile súborov, prípravu prostredia pre nasadenie a samotné nasadenie kontajnerov. Kľúčové slová: Informačný systém, virtualizácia, vsphere, Hyper-V, Xen, KVM, cloud, Google Cloud Platform, AWS, Azure, Docker, kontajner Abstract This bachelor thesis deals with the analysis of virtualization platforms, container technologies and cloud services for the operation of large-scale information systems. The aim of this thesis is to bring sample information system into the Docker container environment. The theoretical part describes problems related to development of large-scale information systems and compares virtualization platforms from companies VMware, Citrix, Red Hat and Microsoft and also includes comparision of cloud services from providers Amazon, Microsoft and Google. Further, it informs readers about container technologies focusing on the Docker platform. Next part of thesis contains a large number of practical examples describing the creation and launching of containers. The practical part includes design of division a project into containers, Dockerfiles creation, preparation of an environment for deployment and deployment of containers. Key Words: Information system, virtualization, vsphere, Hyper-V, Xen, KVM, cloud, Google Cloud Platform, AWS, Azure, Docker, container

8 Obsah Zoznam použitých skratiek a symbolov 10 Zoznam obrázkov 12 Zoznam tabuliek 13 Zoznam výpisov zdrojového kódu 14 Úvod 15 1 Vývoj a nasadenie rozsiahlych informačných systémov Životný cyklus vývoja softvéru Modely Problematika vývoja rozsiahlych informačných systémov Virtualizačné platformy Hypervisor Virtualizácia serverov VMware Microsoft Hyper-V Citrix Xen KVM Kontajnerové technológie Kontajnerizácia Docker Docker Swarm Kubernetes Cloud služby Cloud computing Amazon Web Services Google Cloud Platform Microsoft Azure Práca s Dockerom Docker Images Docker Containers Docker Volumes

9 5.4 Docker Swarm Docker Compose Docker Stack Vytváranie vlastných obrazov Portál ponuky a dopytu Gloffer Infraštruktúra portálu Gloffer Porovnanie virtualizačných platforiem Porovnanie cloudu oproti vlastnej virtualizácií Kontajnerizácia portálu Gloffer Návrh Vytvorenie obrazov Príprava prostredia pre nasadenie Nasadenie kontajnerov Záver 87 Literatúra 89 Prílohy 92 A Výukové videá 93 B Obsah CD 94 9

10 Zoznam použitých skratiek a symbolov SDLC Software Development Life Cycle EP Extreme Programming RAID Redundant Array of Independent Disks API Application Programming Interface JSON JavaScript Object Notation XML extensible Markup Language OS Operation System CPU Central Processing Unit RAM Random Access Memory CLI Command Line Interface IT Information Technology VM Virtual Machine DCUI Direct Console User Interface CIM Common Information Model VMM Virtual Machine Monitor VMX Virtual Machine extensions IC Integration Component VID Virtualization Infrastructure Driver VMMS Virtual Machine Management Service VMWP Virtual Machine Worker Process VSC Virtualization Service Client VSP Virtualization Service Provider WMI Windows Management Instrumentation REST Representational State Transfer PaaS Platform as a Service IaaS Infrastructure as a Service SaaS Software as a Service VPN Virtual Private Network IP Internet Protocol DNS Domain Name Server EC2 Elastic Compute Cloud AMI Amazon Machine Image AWS Amazon Web Services SDK Software Development Kit EBS Elastic Block Storage EFS Elastic File Storage 10

11 S3 Simple Storage Service GCE Google Cloud Engine KVM Kernel-based Virtual Machine QEMU Quick EMUlator vcpu virtual Central Processing Unit SQL Structured Query Language IOPS Input/Output Operations Per Second HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure URL Uniform Resource Locator BLOB Binary Large Object SMB Server Message Block OData Open Data Protocol SSD Solid State Drive HDD Hard Disk Drive iscsi internet Small Computer Systems Interface IMAP Internet Message Access Protocol POP3 Post Office Protocol PHP Hypertext Preprocessor BSON Binary JavaScript Object Notation VLAN Virtual Local Area Network 11

12 Zoznam obrázkov 1 Životný cyklus vývoja softvéru Vodopádový model Špirálový model Extrémne programovanie Škálovateľnosť Dostupnosť Clustering Integrácia Porovnanie typov hypervisorov Porovnanie tradičnej a virtualizovanej architektúry Porovnanie typov virtualizácií VMware ESXi architektúra Microsoft Hyper-V architektúra Xen Project Hypervisor architektúra KVM architektúra Docker architektúra Docker vs VM Docker + VM Porovnanie typov cloud služieb Ukážka príkazu docker search Ukážka príkazu docker run Ukážka príkazu docker ps Ukážka príkazu docker swam join-token Ukážka príkazu docker node ls Ukážka príkazu docker stack ls Ukážka príkazu docker stack services Ukážka príkazu docker service ps Ukážka nahratia obrazu do repozitára Docker Hub Diagram komponentov zobrazujúci prepojenie kontajnerov Štruktúra priečinku WebApp Nastavenie automatického vytvárania obrazu pre webovú aplikáciu Štruktúra priečinku Elasticsearch Zloženie Swarmu pre kontajnerizáciu projektu Prehľad spustených služieb Úvodná stránka portálu Gloffer bežiaceho v kontajneroch

13 Zoznam tabuliek 1 Technické parametre serveru Asus Technické parametre serveru Supermicro Porovnanie technických parametrov virtualizačných platforiem Porovnanie technologických parametrov virtualizačných platforiem Kalkulácia ceny pre produkt Red Hat Virtualization Kalkulácia ceny pre produkt XenServer 7.3 Standard Kalkulácia ceny pre produkt VMware vsphere 6.5 Standard Parametre VM pre výpočet nákladov na prevádzku v cloude Kalkulácia ceny pre Microsoft Azure Kalkulácia ceny pre Amazon Web Services Kalkulácia ceny pre Google Cloud Platform Kalkulácia ceny pre vlastnú virtualizáciu

14 Zoznam výpisov zdrojového kódu 1 Ukážka Docker Mount Volume Ukážka Docker Data Volume Docker Compose - najpoužívanejšie parametre Docke Compose - praktická ukážka Docker Stack - sekcia deploy Docke Stack - praktická ukážka Ukážka Dockerfile súboru pre vytvorenie webového serveru Nginx Dockerfile pre Nginx + PHP7.1 + Composer + Redis Dockerfile pre Elasticsearch Vytvorenie a upload Elasticsearch obrazu Inštalácia Docker Community Edition Nastavenie Swarm módu Vygenerovanie tokenu pre pripojenie manažérskych uzlov Nastavenie štítkov pre prvý a druhú uzol Nastavenie štítkov pre tretí uzol Nastavenie minimálneho limitu pre ukladanie Elasticsearch indexov Nastavenia pre optimalizáciu výkonu nástroja Redis Spustenie riadiaceho nástroja Swarmpit Štruktúra súboru gloffer.yml Nasadenie kontajnerov pre portál Gloffer

15 Úvod V dnešnej dobe je už takmer všetko online. Jednotlivci, malé spoločnosti ale aj veľké organizácie prichádzajú do kontaktu s informačnými systémami na dennom poriadku a častokrát bez toho aby si to priamo uvedomovali. Tieto systémy sa stali neoddeliteľnou súčasťou každého z nás a našli si uplatnenie vo všetkých odvetviach priemyslu. Práve tento fakt spôsobuje, že je stále dôležitejšie klásť vysoký dôraz na spoľahlivosť, dostupnosť a zabezpečenie týchto systémov, pretože každý výpadok služby, nezávisle na tom či sa jedná o malý e-shop alebo obrovskú sociálnu sieť, môže viesť k nemalým finančným stratám. Tieto požiadavky je nutné realizovať ako na softvérovej tak aj hardvérovej úrovni. Výber vhodného riešenia pre nasadanie systému predstavuje dôležitý krok, ktorý môže firmám dopomôcť k vytúženému cieľu. V súčastnosti existuje viacero možností, ako a kde môže byť systém nasadený. V tejto práci popisujem rôzne možnosti prevádzkovania informačných systémov, medzi ktoré patrí virtualizácia, cloud služby a v neposlednom rade relatívne nový ale zato stále obľúbenejší pojem s názvom kontajnerizácia. Práca je zameraná na analýzu spomenutých technológií a taktiež na praktickú realizáciu kontajnerizácie na ukážkovom informačnom systéme. Prvá kapitola sa zaoberá problematikou vývoja a nasadenia rozsiahlych informačných systémov. V tejto časti je popísaný životný cyklus vývoja softvéru, od špecifikácie požiadaviek cez implementáciu až po samotné nasadenie a údržbu. Ďalšia časť kapitoly sa venujem najznámejším modelom využívaných pri vývoji týchto systémov. Nasleduje posledná časť, ktorá je zameraná na problematiku vývoja rozsiahlych informačných systémov, ako je škálovateľnosť, vysoká dostupnosť alebo bezpečnosť. Ďalšia kapitola rozoberá základné pojmy spojené so serverovou virtualizáciou. Popisuje akými spôsobmi je možné hosťovať virtuálne stroje a taktiež rozdielne prístupy prerozdeľovania hardvérových prostriedkov týmto strojom. Kapitola ďalej obsahuje porovnanie virtulizačných platforiem od spoločností VMware, Citrix, Microsoft a Red Hat z pohľadu architektúry, ponúkaných produktov a riadiacich nástrojov. Nasledujúca kapitola zoznamuje čitateľa s pojmom kontajnerizácia. Postupne preberá princíp fungovania kontajnerov, ich porovnanie s virtuálnymi strojmi a možnosti nasadenia. Kapitola sa taktiež venuje najznámejšiemu zástupcovi z tejto oblasti, spoločnosti Docker, jeho architektúre, produktovej rade a riadiacim nástrojom. V kapitole s názvom Cloud služby je najskôr definovaný pojem cloud computing a následne sú tieto služby opísané z pohľadu ich základného rozdelenia a spôsobu nasadenia. Súčasťou kapitoly je porovnanie cloud služieb od poskytovateľov Amazon, Microsoft a Google, zamerané na výpočtové prostriedky a úložiská dát. V ďalšej časti prakticky popisujem vytváranie kontajnerov na základe obrazov, princípy vývoja viac-kontajnerových aplikácií, možnosti nasadenia, škálovania a podobne. V tejto časti je taktiež zahrnutý postup vytvárania vlastných obrazov a ich následné uloženie. Jedná sa o 15

16 príručku, ktorá zoznámi čitateľa s technológiu Docker a pomôže mu rýchlo sa zorientovať v danej problematike. Ďalšia časť je zameraná na popis infraštruktúry portálu Gloffer z pohľadu technických parametrov a použitých technológií. Na základe týchto parametrov je vykonané porovnanie virtualizačných produktov od spoločností Citrix, Vmware, Microsoft a Red Hat so zameraním na pomer cena/výkon. Kapitola sa ďalej venuje porovnaniu cloudu oproti vlastnej virtualizácií, v ktorom sú zahrnuté náklady spojené s nákupom hardvéru, virtualizačného softvéru a energií. Záverečná kapitola je venovaná samotnej kontajnerizácií portálu Gloffer. V tejto časti je najskôr vykonaný návrh rozdelenia projektu do jednotlivých kontajnerov. Po tomto kroku nasleduje vytvorenie vlastných obrazov, príprava a optimalizácia prostredia pre nasadenie a samotné nasadenie kontajnerov. 16

17 1 Vývoj a nasadenie rozsiahlych informačných systémov V tejto kapitole najskôr popisujem životný cyklus vývoja softvéru a následne sa venujem modelom využívaných v softvérovom inžinierstve. [1] Vývoj informačných systémov, ako aj ich veľkosť a s tým spojené požiadavky sa neustále menia a museli sa tomu prispôsobiť aj jednotlivé modely. Nemalý podiel má na tom aj virtualizácia a cloud, pretože s týmito technológiami prišli nielen nové možnosti nasadenia ale aj škálovateľnosť, vysoká dostupnosť a iné vlastnosti, ktoré sú charakteristické pre dnešné systémy. Je napríklad veľmi dôležité už pri samotnom návrhu systému rozhodnúť, kde bude nasadený, pretože migrácia do cloudu v neskorších fázach projektu môže predstavovať veľkú výzvu a to hlavne pre rozsiahle systémy, ktoré sa častokrát skladajú z veľkého množstva spolupracujúcich častí. Záver kapitoly obsahuje najčastejšie problémy, s ktorými sa potýkame práve pri vývoji rozsiahlych informačných systémov. 1.1 Životný cyklus vývoja softvéru Životný cyklus vývoja softvéru(sdlc) je postupnosť činností, ktoré vedú k vytvoreniu softvérového produktu. Tieto činnosti môžu zahŕňať vývoj softvéru od nuly alebo v súčasnosti sa často vyvíja softvér rozšírením a úpravami už existujúceho produktu. Existuje veľké množstvo softvérových procesov, ale všetky zahŕňajú v určitej podobe aktivity, ktoré sú zobrazené na Obrázku 1. Obr. 1: Životný cyklus vývoja softvéru Definícia požiadaviek Prvá a zároveň najdôležitejšia fáza vo vývoji softvéru, ktorej úlohou je zistiť rozsah problému a navrhnúť vhodné riešenia. Počas tejto fázy dochádza k zdokumentovaniu všetkých požiadaviek 17

18 koncového zákazníka na produkt, ktorý sa má navrhnúť a vyvíjať počas SDLC. Definuje, či je potrebný nový systém alebo stačí vylepšiť existujúci systém pre dosiahnutie strategických cieľov podniku. Neoddeliteľnou súčasťou tejto fázy sú stretnutia s klientmi, konzultantmi, zamestnancami a všetkými zainteresovanými stranami. Počas definície požiadaviek taktiež dochádza k zváženiu zdrojov, ako sú personál, náklady a čas Návrh Návrh softvéru podrobne opisuje potrebné špecifikácie, funkcie a operácie, ktoré spĺňajú požiadavky navrhnuté počas predchádzajúcej fázy. Na základe týchto špecifikácií a ďalších parametrov ako je hodnotenie rizík, robustnosť produktu, modularita, rozpočet a podobne, sa pre daný výrobok vyberá najlepší dizajnový prístup Implementácia Táto fáza zahŕňa implementáciu návrhu do kódu spustiteľného programovacieho jazyka. Ide o najdlhšiu fázu SDLC, počas ktorej musia byť dodržané špecifické požiadavky na kódovanie. Výstupom implementácie je spustiteľný kód, ktorý je pripravený na testovanie Testovanie Vytvorený kód sa testuje, aby sa zabezpečilo, že výrobok skutočne rieši potreby, ktoré boli zhromaždené počas definovania požiadaviek. V tejto fáze opravujeme všetky nedostatky, až kým produkt nespĺňa pôvodné špecifikácie. Počas tejto fázy sa vykonávajú nielen všetky typy funkčných testov, ako unit testovanie, integračné testy, akceptačné testy, ale prebieha aj mimofunkčné testovanie Nasadenie Po úspešnom testovaní a akceptovaní výrobku je produkt dodaný zákazníkovi na použitie. Cieľom tejto fázy je úspešné dodanie softvéru koncovým užívateľom Údržba Záverečná fáza, ktorá zahŕňa údržbu a pravidelné aktualizácie produktu. Tento krok je potrebný pokiaľ koncoví zákazníci potrebujú jemne doladiť systém, opraviť chyby, zvýšiť výkonnosť, pridať nové možnosti alebo splniť ďalšie požiadavky používateľov. 1.2 Modely Existuje veľa modelov popisujúcich SDLC. Tieto modely popisujú rôzne procesy alebo metodiky, ktoré sa vyberajú pre vývoj projektu v závislosti od účelu a cieľov. Modely boli vyvinuté s cieľom zabezpečiť úspech v procese vývoja softvéru. Medzi najznámejšie modely patria: 18

19 1.2.1 Vodopádový model Jeden z prvých modelov využívaných v softvérovom inžinierstve. Jedná sa o prediktívny 1 model. Stal sa základom pre väčšinu dnes využívaných prístupov vývoja softvéru. Princíp vodopádu spočíva v tom, že množina činností spojená s danou fázou nemôže začať skôr ako skončí predchádzajúca. To znamená, že výstup fázy slúži ako vstup pre nasledujúcu fázu, viď Obrázok 2. Obr. 2: Vodopádový model Využitie Vývoj každého softvéru je v niečom odlišný a preto vyžaduje vhodný prístup na základe jeho požiadaviek. Situácie kedy je najvhodnejšie použiť vodopádový model sú: Projekt je krátky Požiadavky neobsahujú rizikové časti Požiadavky sú dopredu známe Požiadavky sa v priebehu vývoja nebudú zásadne meniť Výhody Vodopádový model je ľahko pochopiteľný a použiteľný. Fázy sú spracovávané a dokončené jedna po druhej. Každá fáza vývoja prebieha v striktnom poradí bez akýchkoľvek prekrývajúcich sa alebo iteračných krokov. Model má jasne definované etapy a míľniky. Jednotlivé procesy a výsledky sú veľmi dobre zdokumentované. 1 Model vývoja, ktorý predpovedá čo je potrebné urobiť a následne sa tieto činnosti vykonajú. 19

20 Nevýhody Oneskorenie medzi zadaním projektu a vytvorením spustiteľného systému je príliš dlhé. Výsledok závisí na úplnom a korektnom zadaní požiadaviek kladených na systém. Nie je možné odhaliť výslednú kvalitu projektu danou splnením všetkých požiadaviek, pokiaľ nie je výsledný softvér dokončený Špirálový model Model je založený na iteratívnom 2 vývoji a hodnotení rizík. Každá slučka špirály predstavuje jednu fázu softvérového procesu. Špirálový model kombinuje toleranciu a prevenciu zmien. Predpokladá sa, že zmeny sú výsledkom rizík projektu a zahŕňa explicitné aktivity na ich riešenie. Špirálový model taktiež zahŕňa vytváranie a hodnotenie prototypov 3. Každá slučka špirály sa delí na štyri sektory. Obrázok 3 zobrazuje princíp špirálového modelu. Obr. 3: Špirálový model[2] 2 Model vývoja, v ktorom sa opakujú jednotlivé fázy SDLC. Na začiatku sa zameriava na základnú implementáciu, ktorá postupne získava širší súbor funkcií. 3 Ranná verzia softvéru, umožňujúca demonštrovať princípy, vyskúšať možnosti návrhu a zistiť prípadné problémy. 20

21 1. Nastavenie cieľov Sú definované konkrétne ciele pre danú fázu projektu. Identifikujú sa jednotlivé obmedzenia a vytvára sa podrobný plán riadenia. Sú určené riziká projektu a prípadné alternatívne stratégie. 2. Hodnotenie a obmedzenie rizík Pre každé z identifikovaných rizík projektu sa vykonáva podrobná analýza a prijímajú sa potrebné kroky na ich obmedzenie. Dochádza taktiež k vytvoreniu prototypu na dosiahnutie potrebných cieľov. 3. Vývoj a testovanie Po vyhodnotení rizík nastáva na základe vytvoreného prototypu voľba vhodného modelu pre vývoj. 4. Plánovanie nasledujúcej iterácie V tejto časti dochádza revízií a rozhodnutiu, či sa bude pokračovať v ďalšej slučke špirály alebo vyvinutý produkt odpovedá požiadavkám koncového zákazníka. Využitie Špirálový model je považovaný za jeden z najužitočnejších a najflexibilnejších prístupov vývoja. Minimalizuje riziko ako pre zákazníkov tak aj pre vývojárske tými. Model sa využíva hlavne v týchto situáciách: Počas vývoja produktu sa očakávajú výrazné zmeny Rozpočet produktu je obmedzený a hodnotenie rizík je dôležité Zákazník nemá jasnú predstavu o výslednom produktu Produkt má byť uvoľňovaný vo fázach, aby bolo možné získať spätnú väzbu od zákazníkov Výhody Hlavnou výhodou modelu je možnosť pridať prvky produktu keď sú k dispozícií. To zaručuje, že neexistuje žiadny rozpor s predchádzajúcimi požiadavkami a dizajnom. Model taktiež umožňuje rozsiahle využívanie prototypov, rozdelenie vývoja softvéru do menších častí a presnejšie zachytenie požiadaviek. Nevýhody Riadenie modelu je zložitejšie. Nie je vhodný pre malé a nízkorizikové projekty. Obsahuje veľký počet fáz, čo vyžaduje nadmernú dokumentáciu. Trvanie špirály ako aj celého projektu nemusí byť známe. 21

22 1.2.3 Extrémne programovanie Jedná sa o vývoj softvéru agilným 4 prístupom. Cieľom extrémneho programovania(ep) je zlepšiť kvalitu softvéru a rýchlo reagovať na požiadavky zákazníka. Takisto aj spolupráca so zákazníkmi a ich interakcia do vývoja projektu je väčšia ako pri iných modeloch, pretože zákazník plní úlohu člena tímu. Dodávanie softvéru prebieha priebežne v malých časových intervaloch a jeho funkcie sú dôsledne testované. Na Obrázku 4 môžete vidieť jednotlivé fázy EP. Obr. 4: Extrémne programovanie Využitie Vývoj pomocou EP sa používa hlavne pre dynamicky sa meniace projekty s nejasnými požiadavkami a vysokými rizikami. Výhody Veľmi realistický prístup vývoja softvéru. Funkčnosť softvéru môže byť rýchlo rozvíjaná a preukázaná. Požiadavky na zdroje sú minimálne. Model poskytuje vývojárom flexibilitu. EP zahŕňa minimálne plánovanie, dokumentáciu a pravidlá. 4 Model vývoja, ktorý sa zameriava na samoorganizáciu tímov, vysokú interakciu so zákazníkom a rýchle reakcie na zmeny. 22

23 Nevýhody Väčšie riziko udržateľnosti. Vývoj je vysoko závislý na interakcií so zákazníkom, pokiaľ si zákazník nie je istý tým čo chce, projekt môže byť vedený nesprávnym smerom. Existuje veľmi vysoká individuálna závislosť, pretože existuje minimálna dokumentácia. 1.3 Problematika vývoja rozsiahlych informačných systémov Rozsiahle informačné systémy sú charakteristické svojou obrovskou veľkosťou v akejkoľvek predstaviteľnej rovine. Obsahujú veľký počet riadkov kódu, uložených dát, prístupov, vzájomných závislostí medzi softvérovými súčasťami a v neposlednom rade majú obrovské hardvérové požiadavky. Rozsiahle systémy môže taktiež charakterizovať počet ľudí podieľajúcich sa na jeho vývoji alebo čas strávený týmto vývojom. Tieto systémy podliehajú vysokým nárokom na používanie. Medzi charakteristické vlastnosti patria: Decentralizácia a geografická dostupnosť Nepretržitý vývoj a nasadenie Heterogénne, nekonzistentné a meniace sa požiadavky Ľudia nie sú len používateľmi ale stávajú sa súčasťou systému Zlyhanie ako norma, nie ako výnimka Všetky tieto charakteristiky spôsobujú problémy pri vývoji a prevádzke. Aplikácie ktoré bežia na distribuovaných systémoch sú omnoho komplikovanejšie na vývoj a prevádzku ako centralizované systémy. Rozsiahle systémy musia tolerovať zlyhanie jedného alebo viacerých uzlov bez narušenia bežiaceho systému. Konštrukcie, algoritmy, programovacie techniky a celkový pohľad na vývoj rozsiahlych systémov sú oveľa zložitejšie ako tie, ktoré sa používajú pre bežné systémy. [3] [4] Výkonnosť Výkonnosť predstavuje jednu z hlavných kvalitatívnych parametrov informačných systémov, pretože udáva množstvo práce, ktorú musí aplikácia vykonať v danom čase alebo do určitého časového limitu. Tieto systémy musia byť navrhnuté tak, aby zvládali maximálnu záťaž, nie priemer. Výkonnosť sa zvyčajne udáva pomocou nasledujúcich parametrov: Priepustnosť Doba odozvy 23

24 1.3.2 Škálovateľnosť Systém je považovaný za škálovateľný pokiaľ zvládne zvýšenú záťaž bez zmeny dizajnu. Tieto systémy sa vyrovnávajú so zvyšujúcou sa záťažou pridaním hardvéru. Pri návrhu musí byť taktiež zohľadnené vyvažovanie zaťaženia - záťaž je rozdelená medzi niekoľko strojov, takže každý v danom momente obsluhuje len určité percento zaťaženia. Tento princíp je popísaný na Obrázku 5. Obr. 5: Škálovateľnosť Dostupnosť Informačné systémy, musia byť vysoko dostupné. Je to schopnosť systému pracovať veľké percento času. Medzi najväčších nepriateľov dostupnosti patrí nestabilita alebo úplná nedostupnosť systému spôsobená hardvérovým alebo softvérovým zlyhaním. V súčasnosti existuje veľké množstvo prostriedkov pre podporu dostupnosti, ako sú napríklad RAID diskové polia, redundantné napájacie zdroje a podobne. Avšak aj pri takomto hardvéri môžu systémy zlyhať a preto sa dnes využíva rozdelenie záťaže do viacerých uzlov a pri poruche konkrétneho uzla nastane okamžité presmerovanie na funkčný uzol. Na Obrázku 6 je ukážka presmerovania požiadaviek pri výpadku uzla. Ďalšou technológiou využívanou v rozsiahlych informačných systémoch pre podporu dostupnosti je clustering. Táto technológia využíva viac ako jeden stroj pre prístup k rovnakým dátovým zdrojom. To znamená že dva stroje sú pripojené k tomu istému dátovému zdroju, pričom jeden z nich pracuje v pohotovostnom režime. V prípade poruchy dôjde k presmerovaniu na záložný zdroj. Princíp clusteru je zobrazený na Obrázku 7. 24

25 Obr. 6: Dostupnosť Obr. 7: Clustering Bezpečnosť Bezpečnosť je jednou z najdôležitejších aspektov dizajnu a tým skôr pre rozsiahle systémy, pretože sú často otvorené útokom agentov na ľubovoľných miliónoch celosvetových lokalít. Návrhári systému preto musia dôkladne zvážiť, aké mechanizmy použijú pre ochránenie svojho systému. Medzi najčastejšie požiadavky týkajúce sa bezpečnosti patria: Autentifikácia Autorizácia Šifrovanie Integrita Nepopierateľnosť 25

26 1.3.5 Monitorovanie Je to schopnosť systému odhaliť chyby a automaticky reagovať na. Táto schopnosť pochádza z prístrojového a podnikového monitorovania. Prístrojové monitorovanie slúži na určenie zdravia jednotlivých komponentov systému v danom okamihu. Podnikové monitorovanie sleduje zdravie systému a jeho odolnosť voči chybám. Na hlásenie týchto chýb sa najčastejšie využíva logovanie. Samozrejmosťou je oznamovanie vzniknutých udalosti správcom systému Integrácia Integrácia popisuje spôsob ako môže aplikácia čo najjednoduchšie rozšíriť svoj kontext. Táto funkcionalita býva zabezpečená pomocou API rozhrania, ktoré poskytuje kontrolovaný externý prístup k dátam vo vnútri systému. V prípade klienta, využívajúceho API, nie je rozhodujúca použitá technológia, pretože dáta s ktorými pracuje sú poskytované v univerzálnom formáte(json, XML,...). API je najčastejšie využívané mobilnými aplikáciami. Princíp aplikácie poskytujúcej API rozhranie je na Obrázku 8. Obr. 8: Integrácia 26

27 2 Virtualizačné platformy stack 0 Kernel da?e Kapitola sa zaoberá konceptom serverovej virtualizácie a rozoberá jej jednotlivé typy. [5] Ďalej obsahuje porovnanie existujúcich virtualizačných platforiem z pohľadu architektúry, produktovej rady a riadiacich nástrojov. Virtuálny HW Virtuálny HW 2.1 Hypervisor Hypervisor Hypervisor(Virtual Machine Monitor) predstavuje tenkú softvérovú vrstvu, ktorá sa nachádza Aplikácie Aplikácie medzi fyzickým hardvérom a virtuálnymi počítačmi. Jeho úlohou je prerozdeľovanie zdrojov medzi Opera?ný jednotlivé systém virtuálne stroje. Opera?ný Existujú systém dve triedy hypervisorov, Typ 1 a Typ Hardvér 2. Na Obrázku 9 je zobrazené porovnanie týchto hypervisorov Typ 1 Hypervisor Libvirt QEMU Aplikácie Tento typ predstavuje inštaláciu virtualizačnej vrstvy priamo na fyzickom hardvéri počítača, bez nutnosti behu hostiteľského operačného systému pod ním. Vďaka tejto vlastnosti je toto Hypervisor Virtualizovaný hardvér riešenie oveľa efektívnejšie a bezpečnejšie ako Typ 2. OS OS Hardvérová virtualizácia OS Virtuálny HW Opera?ný systém Hardvér Typ 2 Hypervisor Hypervisor Typu 2 reprezentuje aplikáciu, ktorá beží nad operačným systémom Hypervisor a vytvára softvérové rozhranie, ktoré emuluje fyzické prostriedky pre beh jednotlivých virtuálnych strojov. Linux Kernel Táto dodatočná vrstva spôsobuje, že toto riešenie je menej efektívne ako Typ 1. Typ 2 je taktiež menej spoľahlivý, pretože všetko čo ovplyvňuje dostupnosť základného Hardvér operačného systému(aktualizácie, chyby,...), môže ovplyvniť hypervisor a jeho hostí. OS OS OS OS OS OS Hypervisor Hypervisor Hostite?ský OS Hardvér Hardvér Typ 1 Hypervisor Typ 2 Hypervisor Obr. 9: Porovnanie typov hypervisorov 27

28 2.2 Virtualizácia serverov Princíp serverovej virtualizácie spočíva v rozdelení jedného fyzického servera na niekoľko izolovaných virtuálnych prostredí. Týmto spôsobom server maskuje pred hosťom svoje skutočné zdroje a taktiež predstavuje spôsob ako znížiť výdavky a zvýšiť výkonnosť. Tento princíp spolu s porovnaním voči tradičnej architektúre je zobrazený na Obrázku 10. Výkon virtuálneho serveru sa nezhoduje s výkonnosťou serveru bežiaceho priamo na skutočnom hardvéri, avšak koncept virtualizácie funguje, pretože väčšina hosťovaných operačných systémov a aplikácií nepotrebuje pre svoju činnosť plný hardvérový výkon. Medzi najpopulárnejšie princípy serverovej virtualizácie patria: Virtu Toolstack Softvérová virtualizácia Hardvérová Domain virtualizácia 0 Kernel Aplikácie Opera?ný systém Aplikácie Opera?ný systém Paravirtulizácia Ovláda?e Porovnanie jednotlivých je zobrazené na Obrázku 11. Spoločnou charakteristikou všetkých prístupov je beh každého hosťa vo vlastnom virtuálnom prostredí. To umožňuje použitie rozdielnych operačných systémov nezávisle na operačnom systéme hostiteľského serveru. Hosť taktiež nemá Hypervisor Virtualizovaný hardvér znalosť o tom, že beží v hostiteľskom operačnom systéme a nie priamo na hardvéri. O prideľovanie hardvérových zdrojov jednotlivým serverom sa stará hypervisor. Medzi najhlavnejšie výhody serverovej virtualizácie patria: Hardvér Libvirt Úspora nákladov znížením počtu fyzických strojov Prenositeľnosť systému bez nutnosti zmeny konfigurácie Vysoká dostupnosť a rozloženie záťaže Automatizácia a zjednotená správa Aplikácie Aplikácie Aplikácie Aplikácie OS OS OS Opera?ný systém Hypervisor Hardvér Hardvér Obr. 10: Porovnanie tradičnej a virtualizovanej architektúry 28

29 2.2.1 Softvérová virtualizácia Softvérová virtualizácia spúšťa virtualizovaný operačný systém nad virtualizačnou platformou existujúceho operačného systému. Jedná sa o emuláciu hardvérových zdrojov na úrovni operačného systému. Tento typ virtualizácie poskytuje menší výkon pretože operačný systém, ktorý Toolstack Aplikácie Aplikácie poskytuje virtualizačnú platformu taktiež potrebuje určité zdroje a to ovplyvňuje virtuálne systémy bežiace nad ním. Domain 0 Kernel Hardvérová virtualizácia Ovláda?e Opera?ný systém Opera?ný systém Umožňuje spúšťanie jednotlivých virtualizovaných operačných systémovlibvirt priamo QEMU nad jedným hardvérom bez nutnosti existujúceho operačného systému. O sprístupňovanie a prerozdeľovanie hardvérových zdrojov sa stará Hypervisor Virtualizovaný hardvér hypervisor. Jedná sa o najefektívnejší spôsob serverovej virtualizácie. Hardvér Paravirtualizácia Hypervisor Linux Kernel Paravirtualizácia sa nesnaží o napodobnenie hardvérového prostredia pre jednotlivých hostí ako v prípade hardvérovej virtualizácie, ale princíp spočíva v umožneniu komunikácie hosťa priamo Hardvér s hypervisorom. Aby bolo toto možné, je potrebný operačný systém s upraveným jadrom. Aplikácie Opera?ný systém OS OS OS OS OS OS Upravený OS Upravený OS Upravený OS Virtuálny HW Virtuálny HW Virtuálny HW Hypervisor Hypervisor Hypervisor Hostite?ský OS Hardvér Hardvér Hardvér Paravirtualizácia Hardvérová virtualizácia Softvérová virtualizácia Obr. 11: Porovnanie typov virtualizácií 2.3 VMware VMware je celosvetový líder v oblasti virtualizácie. Jedná sa o jednu z najstarších spoločností v tomto odvetví. Bola založená v roku 1998 a v súčasnosti ponúka obrovské portfólio produktov zo všetkých oblastí virtualizácie. Vlajkovú platformu spoločnosti predstavuje serverová virtualizácia s názvom vsphere, ktorá je aktuálne dostupná vo verzií 6.5. Stavebnými základmi vsphere je hypervisor ESXi a riadiaci nástroj vcenter Server. VMware vo svojej produktovej rade vsphere ponúka viacero platených a jednu neplatenú verziu. Neplatená verzia nesie označenie vsphere Hypervisor a ako už z názvu vyplýva, jedná 29

30 sa iba o samostatný hypervisor ESXi, ktorý síce umožňuje vytvárať neobmedzený počet virtuálnych stojov, ale správcovia nemajú k dispozícií riadiaci nástroj vcenter Server, ktorý slúži na Client nastavenie pokročilých funkcií. Docker Hypervisor Host obsahuje jediné obmedzenie, ktoré Registry dovoľuje prideliť maximálne 8 vcpu na jeden virtuálny stroj. Platené verzie nesú označenie vsphere Standard, vsphere dockeer Enterprise build Plus a vsphere withdocker Operations daemon Management Enterprise Plus. Tieto verzie sa od seba odlišujú dostupnou funkcionalitou a ponúkajú možnosť 60 dennej skúšobnej doby. Jednotlivé docker pull licencie neobsahujú nástroj vcenter Server a je potrebné ho dokúpiť ako samostatný produkt. Nákup licencií sa vzťahuje na počet fyzických procesorov, takže v prípade viacprocesorového servera je potrebné zakúpiť niekoľko licencií, akoby sa jednalo o samostatné fyzické Containers Images docker run stroje. Spoločnosť taktiež ponúka Kontajner produkt s názvom vsphere Essentials Kits vo viacerých verziách, ktorý obsahuje licencie pre viacero procesorov spolu s licenciou pre vcenter Server Essentials. Posledným z rady vsphere je produkt s názvom vsphere Remote Office Branch Office, ktorý je navrhnutý špeciálne pre IT infraštruktúru umiestnenú vo vzdialených distribuovaných lokalitách. [6] Architektúra Hypervisor ESXi je definovaný ako hypervisor Typu 1. Tento hypervisor je nainštalovaný priamo na fyzickom hardvéri a stará sa o prideľovanie zdrojov jednotlivým virtuálnym strojom. ESXi sa skladá z komponentov zobrazených na Obrázku 12. [7] VM Linux VM Windows CIM VMX DCUI syslog hostd vpxa VMM VMM User Worlds Ovláda?e VMkernel Obr. 12: VMware ESXi architektúra VMkernel Jedná sa o základný operačný systém, vytvorený špeciálne pre hypervisor ESXi. Tento systém poskytuje prostriedky pre spúšťanie procesov jednotlivých virtuálnych počítačov a taktiež zabezpečuje plnú kontrolu nad fyzickým hardvérovom serveru. 30

31 User Worlds User Worlds predstavuje proces bežiaci v operačnom systéme VMkernel. Jedná sa o mechanizmus, ktorý slúži na pridelenie nevyhnutných prostriedkov pre beh procesov v prostredí hypervisora. Direct Console User Interface(DCUI) Lokálne používateľské rozhranie, ktoré je prístupné iba pomocou konzoly serveru a je primárne určené na počiatočnú konfiguráciu a riešenie problémov. Other User World Processes Táto komponenta reprezentuje procesy, ktoré sú spúšťané VMkernelom a radíme sem: Hostd: Autentifikácia používateľov, ich správa a riadenie prístupu. Vpxa: Agent používaný na pripojenie k aplikácii VirtualCenter. Syslog: Lokálne zaznamenávanie log informácií s možnosťou odosielania na vzdialený cieľ. Common Information Model(CIM) CIM poskytuje rozhranie, ktoré umožňuje vzdialenú správu hardvérových prostriedkov prostredníctvom API. Virtual Machine Monitor(VMM) Proces poskytujúci prostredie pre jednotlivé virtuálne stroje. Každý virtuálny stroj ďalej obsahuje proces s názvom VMX, ktorý je zodpovedný za komunikáciu s I/O zariadeniami, užívateľskými rozhraniami a konzolou Riadiace nástroje vcenter Server predstavuje centralizovanú platformu pre jednoduchú a efektívnu správu produktov vsphere. Poskytuje správcom výkonné nástroje pre správu všetkých hostiteľov spolu s monitorovaním výkonu jednotlivých virtuálnych strojov. Rýchlo analyzuje a odstraňuje problémy vďaka silnej integrácií s virtuálnou infraštruktúrou. Poskytuje veľké množstvo štandardizovaných šablón pre nasadzovanie produktov. Samozrejmosťou je podpora logovania. Vďaka open-plugin architektúre umožňuje pridanie veľkého množstva rozširujúcich funkcií od VMware a jeho partnerov. Dostupný je v dvoch verziách. VMware vcenter Server Standard, ktorý poskytuje kompletnú sadu nástrojov a umožňuje správu neobmedzeného množstva hostiteľov a VMware vcenter Server Foundation, ktorý má obmedzený súbor funkcií a je vhodný pre malé podniky(max. 4 hostitelia). [8] 31

32 vsphere Command-Line Interface Rozhranie príkazového riadku pre konfiguráciu hostiteľa ESXi. vsphere Web Client Nástroj VMware vsphere Web Client, umožňuje správu viacerých hostiteľov ESXi pripojených k vcenter Server z prostredia webového prehliadača. VMware Host Client VMware Client predstavuje webovú aplikáciu, ktorá slúži na správu jednotlivých hostiteľov ESXi, ktorí nie sú pripojení k vcenter Server. Tento klient sa taktiež využíva na vykonávanie núdzovej správy, pokiaľ je vcenter Server nedostupný a na prvotnú konfiguráciu hypervisora. 2.4 Microsoft Hyper-V Hyper-V je produkt virtualizácie od spoločnosti Microsoft. Jedná sa o hypervisor, ktorý využíva hardvérovú emuláciu na vytváranie virtuálnych strojov. Prvýkrát sa táto technológia objavila vo Windows Server 2008 a stala sa súčasťou aj desktopových operačných systémov od verzie Windows 8. Hyper-V umožňuje beh oddelených inštancií systémov rôznych platforiem a architektúr. Microsoft podobne ako VMware ponúka jednu neplatenú a viacero platených verzií serverovej virtualizácie. Neplatená verzia nesie označenie Microsoft Hyper-V Server 2016 a jedná sa iba o samostatný hypervisor. Je možné ho spravovať prostredníctvom konzoly a neobsahuje rozšírené funkcie pre podporu virtualizácie. Na druhú stranu neexistuje žiadne hardvérové obmedzenie v porovnaní s platenými verziami. Medzi platené produkty sa radia Microsoft Server 2016 vo verzií Standard, Datacenter a Essentials. Tieto verzie sa od seba odlišujú ponúkanou funkcionalitou a počtom licencií na prevádzku virtuálnych serverov. V prípade verzií Standart a Datacenter sa jednotlivé licencie vzťahujú na počet fyzických jadier procesora. Na fyzický server existuje požiadavka minimálneho nákupu. Musia sa licencovať najmenej 2 procesory s 8 jadrami na server, to je celkovo 16 jadier, ktoré musia byť licencované a to aj vtedy, ak je použitý napríklad iba jeden štvorjadrový procesor. V prípade verzie Essentials sa jedná o licenciu speciality server, ktorá môže byť použitá iba na jednom serveri s maximálne dvoma fyzickými procesormi. [9] [10] Architektúra Základným prvkom architektúry je hypervisor, konkrétne sa jedná o Typ 1. Hyper-V podporuje izoláciu z hľadiska oddielu(partition). Hypervisor musí obsahovať aspoň jeden root oddiel so systémom Windows. Tento oddiel má priamy prístup k hardvérovým zdrojom a zabezpečuje celú logiku virtualizácie. Umožňuje taktiež vytváranie tzv. child partitions, ktoré následne hosťujú operačné systémy spolu s aplikáciami. Komunikácia medzi oddielmi a hypervisorom je 32

33 zabezpečená pomocou API rozhrania(hypercalls). Princíp fungovania Hyper-V môžete vidieť na Obrázku 13. [11] Root Partition VMWP Child Partition Windows Child Partition Linux VMMS VMI Aplikácie Aplikácie VCP VID VSC/IC Linux VSC/IC Ovláda?e WinHV Ovláda?e WinHV Ovláda?e LinuxHV VMBus VMBus VMBus Hypercalls Hypervisor Obr. 13: Microsoft Hyper-V architektúra Root Partition Jedná sa o prvý oddiel, ktorý je vytvorený ihneď po spustení hypervisora. Tento oddiel má prístup k fyzickým zdrojom servera a slúži na vytváranie a správu detských oddielov. Child Partition Child Partition reprezentuje každý oddiel, ktorý bol vytvorený root oddielom. Všetok prístup k fyzickým zdrojom je zabezpečený prostredníctvom zbernice(vmbus). Tieto oddiely môžu hosťovať operačné systémy Windows alebo Linux. Hypercall Rozhranie pre komunikáciu s hypervisorom. Integration Component(IC) Komponenta, ktorá umožňuje detským oddielom komunikovať s ostatnými oddielmi a hypervisorom. 33

34 Virtualization Infrastructure Driver(VID) Poskytuje služby pre správu diskových oddielov, virtuálnych procesorov a pamäte. VMBus Jedná sa o zbernicu, ktorá poskytuje mechanizmus pre komunikáciu medzi jednotlivými virtuálnymi oddielmi. Virtual Machine Management Service(VMMS) Zodpovedá za riadenie stavu všetkých virtuálnych strojov v detských oddieloch. Virtual Machine Worker Process(VMWP) Táto komponenta poskytuje služby správy virtuálnych počítačov z root inštancie systému Windows pre hostiteľské operačné systémy v detských oddieloch. Služba taktiež vytvára samostatný pracovný proces pre každý spustený virtuálny počítač. Virtualization Service Client(VSC) VSC využíva hardvérové zdroje, ktoré sú poskytované rodičovským oddielom, aby uspokojilo I/O požiadavky svojich zariadení. Virtualization Service Provider(VSP) Jedná sa o službu, ktorá poskytuje zdroje pre detské oddiely cez VMBus. WinHv/LinixHv Jedná sa o akýsi most medzi ovládačmi operačného systému a hypervisorom, ktorý umožňuje ovládačom zavolať hypervisor pomocou štandardných konvencií systému. Windows Management Instrumentation(WMI) API pre správu a riadenie virtuálnych strojov Riadiace nástroje Správu Hyper-V je možné vykonávať pomocou viacerých nástrojov. Primárny spôsob predstavuje Hyper-V Manager, [9] ktorý je súčasťou ľubovoľného operačného systému Windows podporujúceho technológiu Hyper-V alebo ako doplnok v nástroji Remote Server Administration Tools pre systémy Windows neobsahujúce túto technológiu. Ďalšiu možnosť reprezentuje platený nástoj Microsoft System Center, [12] ktorý je určený prevažne pre veľké dátové centrá. Jednotlivé virtuálne stoje je taktiež možné spravovať pomocou príkazového riadku. 34

35 Hyper-V Manager Jedná sa o najbežnejší spôsob pre správu Hyper-V. Umožňuje spravovať malé množstvo lokálnych alebo vzdialených hostiteľov. Medzi charakteristické znaky patria: Vytváranie, ničenie a konfigurácia virtuálnych strojov Konfigurácia a riadenie replikácie Monitorovanie Zálohovanie Sieťové nastavenia Microsoft System Center Riadiaci nástroj Microsoft System Center obsahuje bohatú škálu nástrojov pre správu Windows Serverov. Jedná sa o centralizovaný riadiaci nástroj, ktorý je vhodný ako pre malé prostredia tak aj pre veľké dátové centrá. Je dostupný v dvoch verziách, Standard a Datacenter. Primárny rozdiel medzi týmito verziami je v počte spravovaných virtuálnych inštancií serverového softvéru. Pre System Center platí rovnaká licenčná filozofia ako v prípade Windows Server System Center sa skladá z nasledujúcich komponentov: Configuration Manager: Nasadenie, distribúcia a správa infraštruktúry. Data Protection Manager: Zabezpečenie a obnova údajov. Endpoint Protection: Zabezpečenie klientov vrátane detekcie škodlivého softvéru. Operations Manager: Monitorovanie zdravia celej dátovej infraštruktúry. Orchestrator: Automatizácia tvorby, monitorovania a nasadzovania IT zdrojov. Service Manager: Riešenie incidentov a problémov, kontrola zmien a správu životného cyklu aktív. Virtual Machine Manager: Správa virtuálnych stojov a informácie o ich stave v reálnom čase. 2.5 Citrix Xen Ďalším veľkým hráčom v oblasti virtualizácie je spoločnosť Citrix Systems ponúkajúca širokú škálu produktov. Produkt serverovej virtualizácie nesie názov XenServer a je dostupný vo viacerých verziách. Najnovšia verzia má označenie XenServer 7.2 a umožňuje organizáciám akejkoľvek veľkosti alebo typu vytvárať rozsiahle virtualizačné riešenia. Základným prvkom je Xen Project Hypervisor. Jedná sa o hypervisor Typu 1 rovnako ako v prípade VMware Hypervisor ESXi a Microsoft Hyper-V. 35

36 XenServer je dostupný vo svojej základnej verzií ako open-source virtualizačná platforma. Táto verzia je obmedzená v ponúkanej funkcionalite a taktiež neobsahuje žiadnu možnosť technickej podpory. Na druhú stranu, existuje obrovská komunita vývojárov, ktorá z časti nahrádza tento nedostatok. Pre užívateľov, ktorí požadujú rozšírené funkcie a pre ktorých je produktová podpora kľúčová ponúka spoločnosť Citrix riešenie v podobe Standard a Enterprise edície. Obe verzie sú zdarma po dobu 90 dní. V prípade platených verzií sa licencia vzťahuje na počet fyzických procesorov. XenServer je možné spravovať pomocou konzoly alebo grafického riadiaceho nástroja XenCenter. [13] Architektúra Xen Project Hypervisor [14] predstavuje open-source hypervisor Typu 1. Umožňuje spúšťanie mnohých inštancií operačných systémov a je zodpovedný za prideľovanie prostriedkov týmto inštanciám. Bežiaca inštancia virtuálneho stroja sa nazýva doména. Súčasťou architektúry je aj špeciálna doména - doména 0, ktorá obsahuje ovládače pre všetky zariadenia v systéme. Architektúra Xen Projet Hypervisora je zobrazená na Obrázku 14. Domain 0 Linux Domain U Linux Domain U Windows Toolstack Aplikácie Aplikácie Domain 0 Kernel Opera?ný systém Opera?ný systém Ovláda?e Libvirt Q Hypervisor Virtualizovaný hardvér Hardvér Obr. 14: Xen Project Hypervisor architektúra The Control Domain(Domain 0) Kontrolná doména(domain 0) je špecializovaný virtuálny stoj, ktorý dokáže priamo pristupovať k fyzickému hardvéru servera a taktiež zabezpečuje integráciu s inými virtuálnymi počítačmi. Tento virtuálny stoj neobsahuje žiadne grafické rozhranie pre správu ale vystavuje ovládacie OS rozhranie(toolstack) vonkajšiemu svetu, prostredníctvom ktorého je systém riadený. Xen Project Hypervisor nie je možné použiť bez tejto domény. Upravený OS Upravený OS Upravený OS Virtuálny HW Virtuálny HW Virtuálny HW OS OS OS OS Hyperv Hypervisor 36 Hypervisor Hostite?sk Hardvér Hardvér Hardv

37 Guest Domains/Virtual Machines(Domain U) Jedná sa o štandardné virtuálne prostredia obsahujúce operačný systém a aplikácie. Xen Project Hypervisor podporuje nielen hardvérovú virtualizáciu ale aj paravirtualizáciu. Oba tieto typy môžu byť použité súčasne. Hostiteľské virtuálne počítače sú úplne izolované od fyzického hardvéru a komunikácia prebieha len prostredníctvom Domény Riadiace nástroje Hypervisor je možné spravovať pomocou príkazového riadku alebo grafického nástroja XenCenter. [15] Tento nástroj slúži na komplexnú správu XenServerov z prostredia Microsoft Windows. Umožňuje správcom jednoduché monitorovanie hostiteľov, prideľovanie fyzických zdrojov, nasadzovanie, migráciu a mnoho ďalších funkcií. Podobne ako v prípade XenServeru sa jedná o open-source platformu, ktorá dovoľuje inštaláciu mnohých užitočných nástrojov. XenCenter charakterizujú nasledujúce vlastnosti: Kompletná inštalácia virtuálneho stroja, konfigurácia a riadenie životného cyklu Správa hostiteľských sietí Dynamická správa pamäte Konfigurácia vysokej dostupnosti Riadenie prístupu na základe rolí 2.6 KVM KVM predstavuje open-source virtualizačné riešenie založené na Linuxovom jadre. Je jeho neoddeliteľnou súčasťou od verzie KVM sa stalo jednou z najpoužívanejších virtualizačných technológií súčasnosti a nadobudlo viaceré podoby vďaka úpravám kódu rôznych firiem a organizácií. [16] Medzi najznámejšie patrí Red Hat a jeho virtualizačné riešenie Red Hat Virtualization. Aktuálna verzia nesie označenie Red Hat Virtualization 4.1 a ponúka možnosť 60 dennej skúšobnej doby. Tento produkt v sebe zahŕňa Red Hat Enterprise Virtualization Hypervisor a nástoj pre správu Red Hat Enterprise Virtualization Manager. Licencia sa vzťahuje na soketový pár, pričom existuje iba jedna verzia produktu, ktorá obsahuje úplný súbor funkcií. Cena predplatného závisí od úrovne podpory, ktorú zákazník vyžaduje. [17] Architektúra Jedná sa o plnú hardvérovú virtualizáciu pre architektúru x86. KVM vyžaduje pre svoj beh CPU s podporou virtualizácie. V prípade Intelu sa jedná o technológiu VT-X. Technológia od spoločnosti AMD nesie označenie AMD-V. Nevyhnutnou súčasťou KVM je hosťovaný hypervisor 37

38 a emulátor QEMU. Jedná sa o hypervisor typu 2 a spoločne s hypervisorom KVM umožňuje Domain U Windows beh viacerých virtuálnych strojov založených na operačnom systéme Windows alebo Linux. Aplikácie Architektúra KVM hosťuje obrazy virtuálneho stroja ako bežné linuxové procesy, takže každý obraz môže využívať všetky funkcie linuxového jadra ako je zabezpečenie, úložisko, pamäť a Opera?ný systém podobne. Súčasťou architektúry je aj API rozhranie s názvom libvirt, ktoré umožňuje spravovať hypervisor pomocou najrôznejších nástrojov. Architektúru je zobrazená na Obrázku 15. [16] Libvirt QEMU Aplikácie Virtualizovaný hardvér Opera?ný systém Hypervisor Linux Kernel Hardvér OS Obr. 15: KVM architektúra OS OS OS álny HW OS OS Virtuálny HW Riadiace nástroje Virtuálny HW Hypervisor KVM je možné spravovať pomocou širokej škály open-source nástrojov. Tieto nástroje ponúkajú Hypervisor širokú variabilitu použitia. Hostite?ský Medzi najznámejšie OS patria ovirt, KimChi a mnoho ďalších. [16] Red Hat Enterprise Virtualization Manager Hardvér Hardvér Jedná sa o centralizovaný riadiaci nástoj pre správu všetkých aspektov virtualizačnej infraštruktúry od spoločnosti Red Hat. [17] Ponúka bohaté používateľské rozhranie, ktoré umožňuje úplnú konfiguráciu virtuálnych strojov z prostredia webového prehliadača. Medzi charakteristické vlastnosti patria: Migrácia virtuálnych počítačov medzi hostiteľmi bez prerušenia Vyvažovanie zaťaženia na základe dostupných zdrojov Monitorovanie virtuálnych strojov, hostiteľských systémov a úložiska v reálnom čase Vytváranie virtuálnych strojov na základe šablón Automatizácia 38

39 3 Kontajnerové technológie 3.1 Kontajnerizácia Táto technológia využíva virtualizáciu na úrovni OS pre vývoj a prevádzku distribuovaných aplikácií bez nutnosti spustenia samostatného virtuálneho stroja pre každú aplikáciu. Namiesto toho tieto aplikácie bežia v izolovaných prostrediach(kontajneroch) na jedinom hostiteľovi a zdieľajú prístup k jadru operačného systému. Keďže kontajnery zdieľajú rovnaké jadro OS ako hostiteľ, je ich prevádzka efektívnejšia ako beh samostatných virtuálnych strojov. Hostiteľský systém má za úlohu prerozdeľovať fyzické zdroje, ako je CPU a pamäť RAM jednotlivým kontajnerom. Kontajner je samostatne spustiteľný balík softvéru, ktorý obsahuje všetko potrebné na jeho prevádzku: kód, systémové nástroje, systémové knižnice, súbory a podobne. Kontajnery izolujú softvér od svojho okolia a umožňujú tak beh aplikácií založených na systéme Linux alebo Windows bez ohľadu na prostredie. [18] Výhody Prenos kontajnerov medzi systémami bez nutnosti zmeny kódu Vysoká efektivita využívania fyzických zdrojov Vysoká výkonnosť Nevýhody Nedostatočná izolácia od hostiteľského OS 3.2 Docker Docker predstavuje najrozšírenejší produkt softvérovej kontajnerizácie. Jeho architektúra je zobrazená na Obrázku 16. Je dostupný v platenej ako aj neplatenej edícií. Súčasná verzia nesie označenie Docker v Táto technológia je napísaná v jazyku GO a využíva mnoho funkcionalít Linuxového jadra. Jedná sa o open-source platformu, ktorá umožňuje vytváranie štandardizovaných prostredí - kontajnerov. Tieto kontajnery je možné spustiť kdekoľvek, kde sa nadchádza klient-server aplikácia s názvom Docker Engine. Stavebnými prvkami Docker Engine sú nasledujúce komponenty: [19] Server REST API Klient 39

40 3.2.1 Architektúra Client Docker Host Registry dockeer build Docker daemon docker pull docker run Containers Kontajner Images Obr. 16: Docker architektúra Ko Docker daemon Docker daemon prijíma požiadavky od Docker API a spravuje jednotlivé Docker objekty. Viacero daemonov môže spolu komunikovať a spravovať tieto objekty. Docker client CIM VMX DCUI syslog hostd vpxa Jedná sa o primárny spôsob, ako mnoho Docker užívateľov komunikuje VMMs Docker VMMdaemonom. Klient odosiela príkazy do daemona User Worlds prostredníctvom Docker API a ten ich následne vykoná. Klient môže komunikovať s viacerými daemonmi. VMkernel Ovláda?e Docker registries VM Linux VM Windows Slúžia na ukladanie jednotlivých Docker obrazov. Obsahujú dva základné verejné registre s názvom Docker Hub 5 a Docker Cloud 6. Docker je nakonfigurovaný tak, že predvolene vyhľadáva obrazy v registri Docker Hub. Je taktiež možné vytvárať vlastné súkromné registre. Dôležitou súčasnou je Docker Store 7, ktorý umožňuje zakúpiť a predávať Docker obrazy alebo ich bezplatne distribuovať. Docker objects Medzi základný objekt patrí obraz - jedná sa o read-only šablónu s pokynmi na vytvorenie Docker kontajnera. Obrazy sú často založené na inom obraze s dodatočnými prispôsobeniami. 5 Webová stránka Docker Hub: zo dňa Webová stránka Docker Cloud: zo dňa Webová stránka Docker Store: zo dňa

41 Môžeme vytvárať vlastné obrazy alebo použiť niektorý z už publikovaných obrazov. Pri vytváraní vlastného obrazu, je nevyhnutné vytvoriť Dockerfile s jednoduchou syntaxou pre jeho spustenie. Každá inštrukcia v Dockerfile vytvára vrstvu v obraze. Pri zmene Dockerfile a obnovení obrazu sa zmenia iba vrstvy, ktoré boli zasiahnuté touto zmenou - dôvod prečo je obraz taký malý a rýchly. Ďalším objektom je kontajner, ktorý predstavuje spustiteľnú inštanciu obrazu. Tieto inštancie je možné spravovať pomocou rozhrania Docker API. Môžeme taktiež pripojiť kontajner do jednej alebo viacerých sietí, pridať k nemu ukladací priestor alebo vytvoriť nový kontajner na základe jeho aktuálneho stavu. Štandardne je kontajner relatívne dobre izolovaný od iných kontajnerov a hostiteľského stroja. Môžete určiť, ako budú izolované jednotlivé komponenty ako je sieť, úložný priestor alebo iné podkladové subsystémy z iných kontajnerov alebo z hostiteľského počítača. Pri odstránení kontajnera dochádza k strate všetkých údajov, ktoré nie sú uložené v permanentnej pamäti. Posledný objekt tvoria Služby, ktoré umožňujú rozširovať kontajnery cez viacero Docker daemonov a zabezpečujú ich vzájomnú spoluprácu. Komunikácia prebieha pomocou Docker API. Umožňujú nám definovať počet replík, pričom užívateľovi sa táto služba stále javí ako jedna aplikácia. Tento režim je dostupný od verzie Verzie Docker Community Edition Jedná sa o neplatenú verziu, ktorá je ideálnou voľbou pre vývojárov a malé firmy začínajúce s Dockerom a pre experimentovanie s kontajnermi. Je k dispozícií pre mnoho platforiem ako desktop, cloud, open-source operačné systémy a iné. Predstavuje kompletnú sadu nástrojov pre vytváranie, testovanie a spúšťanie kontajnerových aplikácií. Súčasťou je aj automatické vytváranie, overovanie a kontrola zraniteľnosti obrazov. Disponuje jedným súkromným repozitárom. Uvoľňovanie verzií prebieha v mesačných Edge a štvrťročných Stable vydaniach. Technická podpora nie je k dispozícií, avšak existuje široká podpora komunity a taktiež pravidelné opravy chýb pre aktuálnu verziu. [20] Docker Enterprise Edition Táto verzia predstavuje predplatné softvéru, podpory a certifikácie pre podnikové IT tímy, ktoré vytvárajú a spravujú kritické aplikácie. Jedná sa o modernú a dôveryhodnú platformu s integrovaným riadením a zabezpečením pre všetky druhy aplikácií. Je dostupná vo verzií Basic, Standard a Advanced. Jednotlivé verzie sa od seba odlišujú ponúkanou funkcionalitou a je možné ich vyskúšať na mesiac zadarmo. Riadenie prebieha pomocou Docker Datacentra, ktoré umožňuje jednoduché vytváranie, správu, zabezpečenie, podpisovanie a orchestráciu Docker kontajnerov. Uvoľňovanie verzií prebieha v mesačných Edge a štvrťročných Stable vydaniach. Na rozdiel od Docker Community Edition je k dispozícií spätná oprava chýb pre všetky dostupné verzie. Samozrejmosťou je aj technická podpora vo viacerých verziách. [21] 41

42 3.2.3 Docker vs VM Kontajnery a virtuálne stroje majú veľa spoločného čo sa týka izolácie a prideľovania zdrojov. Ich funkčnosť sa ale odlišuje v spôsobe virtualizácie. Kontajnery virtualizujú operačný systém, zatiaľ čo VM virtualizujú hardvér. Táto dôležitá vlastnosť spôsobuje, že kontajnery sú prenosnejšie ako virtuálne stroje. Rozdiel je zobrazený na Obrázku 17. Kontajner Kontajner Kontajner OS OS OS Hypervisor Registry Hostite?ský OS Hardvér Hostite?ský OS Hardvér ges Obr. 17: Docker vs VM Docker + VM V súčasnosti predstavuje toto riešenie jedno z najefektívnejších spôsobov virtualizácie, viď Obrá- CIM VMX DCUI syslog hostd vpxa zok 18. Použitie kontajnerov spoločne s VM poskytuje vysokú flexibilitu VMM nielen VMMpri nasadzovaní User Worlds a správe aplikácií ale aj pri využívaní dostupných fyzických zdrojov. VM Linux VM Windows Ovláda?e Kontajner VMkernel Kontajner OS OS VM Linux VM Windows Hypervisor pxa VMM VMM Hardvér Obr. 18: Docker + VM Kompatibilita a možnosti nasadenia Docker predstavuje technológiu, ktorú je možné spustiť takmer na každom zariadení. Je podporovaný operačnými systémami Windows, Mac OS a Linux. Práve operačný systém Linux 42

43 predstavuje riešenie, ktoré je najviac využívané pri nasadzovaní aplikácií a vzniklo veľké množstvo distribúcií optimalizovaných pre beh kontajnerov. Medzi najznámejšie patria CoreOS alebo RancherOS. [22] Taktiež spoločnosti zaoberajúce sa serverovou virtualizáciou integrovali podporu kontajnerov do svojich produktov a riadiacich nástrojov. Aj tento fakt svedčí o stále rastúcej popularite tejto technológie. VMware ponúka vlastný produkt s názvom vsphere Integrated Containers a pre porovnanie, spoločnosť Citrix má svoje riešenie založené na integrácií so systémom CoreOS. Ďalšiu možnosť pre nasadenie kontajnerov predstavuje cloud. Microsoft, Google a Amazon poskytujú služby umožňujúce beh kontajnerov bez potreby prenájmu samostatného virtuálneho stroja. Tieto produktu obsahujú súkromné registre pre ukladanie obrazov, nástroje pre monitorovanie a nasadzovanie kontajnerov a mnoho ďalších doplnkových služieb. Samozrejmosťou je možnosť inštalácie Dockeru priamo na prenajaté VM. 3.3 Docker Swarm Docker Swarm predstavuje natívny nástroj pre správu a orchestráciu clusterov. [23] Od verzie 1.12 sa stal neoddeliteľnou súčasťou Docker Enginu. Princíp spočíva vo vytváraní Docker hostí, ktorí bežia v Swarm móde. Hostia môžu vystupovať v roli manažéra alebo pracovníka. Manažér ma za úlohu spravovať jednotlivých pracovníkov a tí zas poskytovať požadované služby. Jednotlivé uzly a služby je možné spravovať pomocou Swarm API alebo Docker CLI. Docker Swarm charakterizujú nasledovné vlastnosti: Správa clusterov integrovaná v Docker Engine Decentralizovaný dizajn Škálovanie Vyrovnávanie záťaže Vysoká bezpečnosť Kontrola a monitorovanie stavu aplikácií Komponenty Nodes Uzol predstavuje inštanciu Docker Engine, ktorý je súčasťou Swarmu. Môžeme spustiť jeden alebo viacero uzlov na jednom fyzickom stroji ale zvyčajne sa tieto uzly rozprestierajú cez viacero virtuálnych serverov. Swarm definuje dva typy uzlov: Manager: Riadi pracovné uzly, vykonáva požiadavky, prerozdeľuje úlohy a udržiava požadovaný stav clustera. 43

44 Worker: Prijíma požiadavky od manažéra a vykonáva požadované úlohy, informuje manažéra o aktuálnom stave. Services Služba je definovaná ako množina úloh, ktoré sa majú vykonať v manažérskych alebo pracovných uzloch. Predstavuje centrálnu štruktúru Swarm systému a spôsob interakcie s užívateľom. Vytvorením služby sa definuje, ktorý obraz kontajnera bude použitý a ktoré príkazy sa vykonajú. Existujú dva druhy služieb: Replikované: Spustenie úloh na dopredu špecifikovanom množstve uzlov. Globálne: Spustenie úlohy na všetkých dostupných uzloch v clusteri. Tasks Úloha špecifikuje kontajner a množinu inštrukcií, ktoré sa majú spustiť. Predstavuje základnú jednotku práce s kontajnerom. Manažérske uzly priradzujú úlohy jednotlivým pracovníkom na základe počtu replík nastavených v službe. Load balancing Každá úloha bežiaca v Swarm móde má pridelený vlastný DNS záznam. Tieto záznamy sú využívané manažérskymi uzlami na prerozdeľovanie požiadaviek medzi služby bežiace v rámci clustera. 3.4 Kubernetes Kubernetes je open-source nástroj pre automatizáciu, správu, nasadenie a škálovanie kontajnerových aplikácií. [24] [25] Tento nástroj bol pôvodne vytvorený spoločnosťou Google. Jedná sa o alternatívu k nástroju Docker Swarm. Základným prvkom je spoločné API rozhranie, ktoré komunikuje s ostatnými komponentami a zabezpečuje celú funkcionalitu. Medzi základné vlastnosti patria: Orchestrácia kontajnerov Automatizácia nasadzovania a aktualizovania aplikácií Škálovanie aplikácií podľa potreby Kontrola zdravia aplikácií a automatické zastavenie, spustenie a nahradenie Možnosť pridania ďalších open-source projektov pre rozšírenie Kubernetes nástroja 44

45 3.4.1 Komponenty Master Node Stroj, ktorý sa stará o riadenie jednotlivých uzlov a rozdeľovanie úloh. Worker Node Tieto stroje vykonávajú úlohy prichádzajúce z Mater Node. Pods Jedná sa o prepojenú skupinu kontajnerov, ktoré pristupujú k spoločným zdrojom a navonok sa tvária ako jedna aplikácia. Replication Controller Táto komponenta slúži na zabezpečenie behu špecifického počtu Pods v clusteri. Labels Labels sa používajú na organizovanie skupín objektov, ako sú napríklad Pods. Services Služby poskytujú koncové body, ktoré môžu byť prepojené do Pods pomocou Labels. Jedná sa o akúsi vonkajšiu tvár kontajnera. API Server Umožňuje správu Master Node a sprostredkováva komunikáciu medzi viacerými komponentami pre udržanie zdravia clusteru. API Server taktiež poskytuje webové grafické rozhranie pre správu jednotlivých služieb a uzlov. Scheduler Scheduler slúži na prerozdeľovanie záťaží na konkrétny uzol. Tento komponent taktiež sleduje požiadavky a na základe nich plánuje umiestňovanie nezaradených Pods. Controller Manager Jedná sa o jeden z najdôležitejších komponentov, ktorý ma za úlohu zaistiť požadovaný stav clustera a zabezpečuje aby sa spustil požadovaný počet Pods. Kubelet Táto komponenta sa nachádza v každom uzli a je zodpovedná za správu jednotlivých Pods. Kubelet taktiež sleduje API Server, aby vedel na základe Scheduleru kedy vytvoriť alebo naopak odstrániť Pods. 45

46 4 Cloud služby V prvej časti kapitoly popisujem pojem cloud computing spolu s jeho základným rozdelením. Zvyšok sa venuje porovnaniu jednotlivých poskytovateľov cloud služieb z pohľadu prenájmu infraštruktúry a úložiska. Konkrétne sa je jedná o Amazon Web Services, Google Cloud Platform a Microsoft Azure. 4.1 Cloud computing Cloud computing predstavuje model, v ktorom sú servery, úložisko, služby, aplikácie a podobne všadeprítomné prostredníctvom siete a umožňuje rýchlo poskytnúť tieto prostriedky s minimálnym úsilím a maximálnou účinnosťou. Cloud computing abstrahuje detaily implementácie systému od používateľov a vývojárov. Aplikácie bežia na fyzických systémoch, ktoré nie sú špecifikované, údaje sa ukladajú na miestach, ktoré sú neznáme, správa systémov je prenesená na iné osoby a prístup používateľov je všadeprítomný. Neoddeliteľnou súčasťou je virtualizácia a zdieľanie zdrojov. Cloud služby sú charakteristické tým, že dokážu podľa potreby dodať výpočtové prostriedky založené na najnovšej generácií hardvéru z vhodnej geografickej polohy. [26] Typy cloud služieb Toto rozdelenie predstavuje špecifickú, vopred zabalenú kombináciu zdrojov ponúkanú poskytovateľmi cloudu. Obrázok 19 zobrazuje toto rozdelenie. Cloud služby sa členia do nasledujúcich kategórií: Platforma ako služba(paas) Táto služba predstavuje ideálne riešenie pre vývojárov a prevádzkovateľov softvéru, pretože poskytuje platformy, ktoré umožňujú vývoj, nasadenie a testovanie aplikácii bez nutnosti starania sa o samotnú infraštruktúru. Tieto platformy sú založené na špecifických typoch programovacích jazykov a aplikačných frameworkoch. Poskytovateľ služby je zodpovedný za správu cloud infraštruktúry, operačných systémov, podporných nástrojov a ďalších prostriedkov. Infraštruktúra ako služba(iaas) IaaS predstavuje model, v ktorom poskytovateľ ponúka IT infraštruktúru pre akúkoľvek výpočtovú aktivitu. Predstavuje ideálne riešenie pre zákazníkov, ktorí vyžadujú vysokú úroveň kontroly, pretože poskytuje prístup k samotným virtualizovaným serverom a umožňuje ich úplnú konfiguráciu. 46

47 Softvér ako služba(saas) Toto riešenie predstavuje najkompletnejší typ cloud služieb, v ktorom je hardvér, softvér, ako aj samotné riešenie poskytované ako kompletný produkt. Užívateľ má k dispozícií veľmi obmedzenú administratívnu kontrolu a všetka správa je v rukách poskytovateľa. Obr. 19: Porovnanie typov cloud služieb[27] Nasadenie cloud služieb Model nasadenia definuje špecifický typ prostredia cloudu a spôsob jeho umiestnenia. Vyznačuje sa predovšetkým vlastníctvom, veľkosťou a spôsobom prístupu. Cloud podľa typu nasadenia delíme do nasledujúcich kategórií: Verejný cloud Pri tomto type cloudu je hardvér, softvér a ďalšia podporná infraštruktúra výhradne vo vlastníctve a správe poskytovateľa cloudu. Privátny cloud Infraštruktúra súkromného cloudu je vlastnená a využívaná jedinou organizáciou. Cloud môže byť spravovaný samotnou organizáciou alebo spoločnosťou tretej strany. Hybridný cloud Hybridný cloud predstavuje kombináciu verejného a súkromného cloudu, ktorá sa tvári ako spoločná jednotka, pričom je zachovaná ich jedinečná identita. 47

48 Komunitný cloud Tento typ je podobný verejnému cloudu s výnimkou toho, že jeho prístup je obmedzený na konkrétnu oblasť užívateľov so spoločnými vlastnosťami. Komunitný cloud môže byť vlastnený členmi komunity alebo poskytovateľom tretej strany. 4.2 Amazon Web Services Táto služba bola spustená v roku 2006 a v súčasnosti je Amazon najväčším poskytovateľom cloudových služieb, pričom sa jeho servery nachádzajú v rôznych geografických oblastiach. Užívateľ má k dispozícií viac ako 90 rôznych služieb a taktiež Marketplace, v ktorom si môže zakúpiť už hotové riešenia. Pre užívateľov, ktorí nemajú skúsenosti s cloudovými službami, Amazon poskytuje účet zdarma na 12 mesiacov avšak s určitými obmedzeniami. Obrovskou výhodou Amazonu oproti konkurencií je veľké množstvo dokumentácie, kvalitná technická podpora, fóra a podpora veľkého množstva programovacích jazykov. O výpočtový výkon sa stará jednotka s označením Elastic Compute Cloud. Amazon taktiež ponúka rozsiahlu analýzu údajov, strojové učenie, rozsiahly úložný priestor založený na rôznych typoch diskov a rôzne sieťové technológie, ako VPN, verejná IP adresa, DNS a podobne. [28] [29] Elastic Compute Cloud(EC2) Amazon Elastic Compute Cloud reprezentuje kategóriu IaaS a umožňuje používateľom vytváranie a prevádzku virtuálnych strojov na serverovej farme Amazonu s rôznymi profilmi výkonu. Základná spustiteľná jednotka nesie označenie Amazon Machine Image(AMI) a predstavuje inštanciu servera spolu s operačným systémov Linux alebo Windows. AWS ponúka veľké množstvo platených ako aj bezplatných AMI šablón. Užívateľ môže vytvárať vlastné AMI a zverejňovať ich pre ďalšie použitie. Medzi charakteristické vlastnosti EC2 patrí replikácia a vyvažovanie záťaže, založené na vyhľadávaní serverov v rôznych geografických oblastiach pre dosiahnutie vysokej tolerancie voči chybám. EC2 je možné spravovať pomocou webového rozhrania Amazon Management Console, príkazového riadku AWS CLI a rozhrania AWS SDK, ktoré poskytuje API pre programátorov rôznych jazykov a platforiem. Amazone Elastic Compute Cloud delíme na základe spôsobu využitia do nasledujúcich kategórií: General Purpose Compute Optimized Memory Optimized Accelerated Computing Storage Optimized 48

49 Tieto inštancie sa ďalej delia na: On-Demand: Možnosť zvýšiť alebo znížiť výpočtové kapacity na základe aktuálnych požiadaviek aplikácií. Spot Instances: Nevyužité výpočtové prostriedky EC2 za výhodné ceny, inštancie môžu byť kedykoľvek prerušené pokiaľ EC2 potrebuje výpočtové kapacity späť. Reserved Instances: Rezervácia inštancií s cenovým zvýhodnením, priradenie k určitej zóne Amazon Storage Systems Ukladanie dát predstavuje kritickú komponentu každého softvéru a preto je nevyhnutné zvoliť najvhodnejší spôsob ich uchovania. Pri vytvorení AMI dochádza k rezervácií určitého množstva ukladacieho priestoru, ktorý ale neposkytuje trvalé uloženie dát a jeho životnosť je obmedzená na dobu behu tejto inštancie. Pre trvalé uloženie dát Amazon poskytuje nasledujúce typy služieb: Elastic Block Storage(EBS) Táto služba poskytuje blokový úložný priestor pre inštancie EC2. Jednotlivé bloky sa replikujú pre dosiahnutie vysokej úrovne dostupnosti a trvácnosti. EBS poskytuje konzistentnú úroveň výkonu s nízkou latenciou a možnosťou škálovania úložného priestoru podľa potreby. Najčastejšie sa využíva pre relačné a NoSQL databázy. Elastic File System(EFS) EFS poskytuje úložný priestor, ktorý predstavuje štandardné rozhranie súborového systému, pre aplikácie bežiace v AWS. Táto služba umožňuje jednoduché vytváranie a konfiguráciu súborových systémov s automatickou správou kapacity pamäte. Simple Storage Service(S3) Jedná sa o objektový typ úložiska, ktorý poskytuje rozsiahle a bezpečné úložné kapacity pre uchovávanie všetkých typov dát. Využíva sa hlavne pre zálohovanie. Glacier Amazon Glacier predstavuje rovnakú typ úložného priestoru ako Amazon S3. Jediný rozdiel je v dobe prístupu k dátam. S3 umožňuje real-time prístup, zatiaľ čo užívatelia Amazon Glacier si musia vystačiť s prístupom v rozmedzí minút až niekoľko hodín. 49

50 4.3 Google Cloud Platform Druhým veľkým poskytovateľom cloud služieb je spoločnosť Google. Táto služba bola spustená v roku 2011 a podobne ako Amazon ponúka veľké množstvo produktov dostupných z rôznych kútov sveta, avšak s tým rozdielom, že jednotlivé služby sú účtované po minútach. Google poskytuje účet zdarma s 300$ kreditom po dobu 12 mesiacov. O výpočet sa stará jednotka s názvom Google Compute Engine. Google poskytuje najvyspelejšiu analýzu údajov, strojové učenie a umelú inteligenciu. Samozrejmosťou je aj široká ponuka uloženia dát a podpora VPN, DNS a podobne. Nevýhodou tohto poskytovateľa je obmedzený výber programovacích jazykov. [30] Google Compute Engine(GCE) Google Compute Engine zastupuje kategóriu IaaS. Ponúka škálovateľné virtuálne stroje s vlastným spravovaním, ktoré sú hosťované na infraštruktúre spoločnosti Google a dostupné po celom svete. GCE ponúka veľké množstvo konfigurácií, ktoré sú založené na systémoch Linux a Windows. Jednotlivé inštancie je možné spravovať pomocou webového rozhrania Google Developers Console, príkazového riadku a RESTful API nesúceho názov Compute Engine API. [31] [32] Predefined machine types Jedná sa o preddefinované typy strojov, ktoré obsahujú pevný počet vcpu a pamäte. Delia sa do nasledujúcich kategórií:. Standard machine types Shared-core machine types High-memory machine types High-CPU machine types Mega-memory machine types Custom machine types Táto možnosť je využívaná pokiaľ preddefinované typy inštancií nespĺňajú potreby zákazníka a je nutné vytvoriť inštancie s vlastným počtom vcpu a pamäte. Podobne ako v prípade Amazonu, predstavujú obrazy základnú spustiteľnú jednotku, ktorá obsahuje operačný systém a všetok súvisiaci systémový a aplikačný softvér. Spoločnosť Google poskytuje niekoľko štandardných verzií obrazov a takisto možnosť vytvorenia vlastných obrazov. 50

51 4.3.2 Google Storage Options Google ponúka širokú škálu permanentných úložísk pre dáta aplikácií a virtuálnych strojov, ktoré sa delia do nasledujúcich kategórií: [33] Google Cloud Storage Poskytuje objektový typ úložiska, ktoré slúži na ukladanie všetkých druhov dát. Využíva sa hlavne na zálohovanie. Cloud SQL Táto služba predstavuje úložný priestor pre relačné databázy. Konkrétne sa jedná o systémy typu PostgreSQL BETA a MySQL. Cloud BigTable Služba zastupujúca NoSQL databázy, vhodná pre pracovné záťaže s nízkou latenciou a vysokou priepustnosťou. Predstavuje ideálne riešenie pre Big Data nástroje a analytické služby. Cloud Spanner Cloud Spanner predstavuje databázové riešenie postavené na štruktúre relačných databáz v kombinácií s horizontálnym škálovaním NoSQL databáz. Cloud Datastore Jedná sa o dokumentovo orientovanú NoSQL databázu. Obsahuje výkonný vyhľadávací nástoj a je vhodná prevažne pre mobilné a webové aplikácie. Persistent Disk Blokové dátové úložisko vhodné pre virtuálne stoje a kontajnery. Umožňuje inštanciám pristupovať k dátam akoby sa jednalo o fyzické disky v počítači alebo na serveri. Neobsahuje poplatky za IOPS. 4.4 Microsoft Azure Posledným z veľkých poskytovateľov je Microsoft. Služba bola spustená v roku 2008 a ponúka produkty založené na systémoch Windows alebo Linux, pričom tieto služby sú dostupné z viacerých geografických oblastí. Podobne ako v prípade Google sú služby účtované po minútach. Súčasťou Microsoft Azure je Marketplace, ktorý poskytuje širokú ponuku už hotových riešení. Pre testovanie jednotlivých služieb je pre každého užívateľa k dispozícií účet zdarma s 200$ kreditom. Azure podporuje väčšinu dnes známych programovacích jazykov. Samozrejmosťou je široká ponuka uloženia dát, analýza údajov a rôzne sieťové nastavenia. [34] 51

52 4.4.1 Azure Virtual Machines Virtuálne stroje spoločnosti Microsoft reprezentujú typ služby IaaS. Poskytujú flexibilitu virtualizácie bez toho aby zákazník musel udržiavať fyzický hardvér avšak neodpadá nutnosť konfigurácie softvéru bežiaceho na jednotlivých inštanciách. Tieto inštancie sa delia na základe parametrov, ako je počet vcpu a veľkosť pamäte RAM do nasledujúcich kategórií: General purpose Compute optimized Memory optimized Storage optimized GPU optimized High performance compute Správa je zabezpečená pomocou Azure CLI, Azure PowerShell alebo webového portálu. Azure poskytuje veľké množstvo obrazov, ktoré sú dostupné cez Marketplace a sú založené na systémoch Linux alebo Windows v kombinácií s rôznymi doplňujúcimi aplikáciami a taktiež existuje možnosť vytvorenia a spustenia vlastného obrazu Microsoft Azure Storage Microsoft vo svojom portfóliu ponúka niekoľko typov permanentných úložných priestorov, ktoré sa vyznačujú vysokou škálovateľnosťou, bezpečnosťou, rýchlosťou a delia sa do nasledujúcich kategórií: Blob storage Táto služba umožňuje ukladanie veľkého množstva neštruktúrovaných dátových objektov, ako sú obrázky, zálohy a podobne vo forme BLOBu. Dáta je možné získavať odkiaľkoľvek prostredníctvom protokolov HTTP a HTTPS. Azure Files Tento typ úložiska predstavuje vysoko dostupné zdieľané sieťové súbory, ku ktorým je možné pristupovať z ľubovoľného miesta na svete pomocou URL adresy, využívajúce prenosový protokol SMB. 52

53 Queue storage Služba poskytujúca ukladanie a prístup k správam uložených vo fronte, ktoré sa majú spracovávať asynchrónne. Veľkosť správy je obmedzená na 64KB a počet front je limitovaný veľkosťou úložiska. Prístup k jednotlivým správam je zabezpečený pomocou protokolu HTTP alebo HTTPS. Table storage Table storage slúži na ukladanie veľkého množstva štruktúrovaných dát vo formáte kľuč-hodnota s využitím NoSQL databázy. Využíva sa hlavne pre webové aplikácie a prístup k dátam zabezpečuje protokol OData. Disk storage Posledným typom je Disk storage, ktorý využívajú VM pre ukladanie operačných systémov, aplikácií a dát. Existujú dve výkonnostné úrovne: Premium storage: SSD Standard storage: HDD 53

54 5 Práca s Dockerom V tejto kapitole popisujem prácu s Dockerom, od spustenia prvého kontajnera cez vytváranie vlastných obrazov až po nasadzovanie viac-kontajnerových aplikácií. Pre fungovanie všetkých príkazov je nevyhnutné najskôr nainštalovať samotný Docker 8 a vytvoriť si Docker ID Docker Images Obrazy predstavujú základnú spustiteľnú jednotku, ktorú využívajú kontajnery pre svoj beh. V tejto sekcií je opísaná manipulácia s obrazmi a taktiež ich vyhľadávanie v repozitári Docker Hub. Vyhľadávanie obrazov Prvý príkaz predstavuje docker search <názov>, ktorý slúži na vyhľadávanie obrazov v repozitári Ducker Hub. Obr. 20: Ukážka príkazu docker search Na Obrázku 20 je zobrazený vzorový výpis výsledkov, ktoré sa zhodujú s vyhľadávaným výrazom hello-world. Alternatívne a efektívnejšie riešenie predstavuje vyhľadávanie obrazov priamo na stránke pretože každý obraz disponuje množstvom dodatočných informácií o jeho konfigurácií. Sťahovanie obrazov Ak nájdeme obraz, ktorý chceme použiť, môžeme ho jednoducho stiahnuť pomocou príkazu docker pull <názov>:<tag>. Tag predstavuje parameter, ktorý je možné vynechať a v takom prípade dôjde k stiahnutiu najnovšej verzie obrazu. Zoznam obrazov Pre zobrazenie všetkých lokálne dostupných obrazov spolu so základnými informáciami sa používa príkaz docker images. 8 Postup inštalácie: zo dňa Stránka pre registráciu: zo dňa

55 Vymazávanie obrazov Posledným príkazom v tejto časti je docker rmi <názov/id>:<tag>, pomocou ktorého je možné odstrániť nežiadúce obrazy z nášho zariadenia. Pre úspešné odstránenie obrazu je nutné aby všetky kontajnery, ktoré obraz využívajú, boli zastavené. 5.2 Docker Containers V tejto časti je vysvetlené, ako na základe obrazu vytvoriť kontajner a taktiež sú predstavené základné úkony, ktoré je možné vykonávať s týmito kontajnermi. Vytvorenie kontajnera Kontajnery je možné vytvárať pomocou príkazu docker run <názov obrazu>:<tag>. Tento príkaz taktiež vykoná automatické spustenie kontajnera. Pokiaľ obraz, z ktorého chceme vytvoriť kontajner nie je dostupný lokálne, dôjde k jeho vyhľadaniu a stiahnutiu akoby sme použili príkaz docker pull <názov>:<tag>. Obr. 21: Ukážka príkazu docker run Obrázok 21 zobrazuje výstup vygenerovaný po spustení kontajnera. Pridaním parametra -d do príkazu docker run spôsobíme, že kontajner bude bežať na pozadí a do konzoly nebude propagovať žiadny výstup. Zoznam kontajnerov Pre zobrazenie aktuálne bežiacich kontajnerov slúži príkaz docker ps. Výstup tohoto príkazu môžete vidieť na Obrázku 22. Obr. 22: Ukážka príkazu docker ps K dispozícii je taktiež príkaz docker ps -a, ktorý vypíše zoznam všetkých kontajnerov, vrátane tých, ktoré nie sú spustené. Nastavenie portov Ďalší dôležitý parameter predstavuje -p, ktorý slúži na nastavenie portov hosťa a kontajnera. Príkaz má nasledujúcu podobu: docker run -p <port hosťa>:<port kontajnera> <názov obrazu>:<tag>. 55

56 Zastavenie a odstránenie kontajnerov Posledné dva príkazy v tejto časti sú: docker stop <názov/id>, ktorý ako už názov napovedá, slúži na zastavenie kontajnera a docker rm <názov/id>, ktorý ho odstráni. Pre úspešné odstránenie je nevyhnutné aby kontajner nebol spustený. 5.3 Docker Volumes Docker Volumes predstavujú spôsob ako trvalo uchovať dáta aj mimo prevádzky kontajnera. Tieto zväzky sa využívajú hlavne pre uloženie obsahu databáz, informácií o logovaní a taktiež pre zdieľanie informácií medzi hostiteľom a kontajnermi. Rozlišujeme dva typy zväzkov: Mount Volumes Data Volumes Mount Volumes Pri Mount Volume je súbor alebo adresár z hostiteľského počítača namapovaný do kontajnera. Tento typ sa využíva hlavne pri vývoji webových stánok, pretože každá zmena je ihneď viditeľná bez nutnosti reštartovania webového serveru bežiaceho v kontajneri. Príkaz pre Mount Volumes vyzerá nasledovne: docker run -v <cesta k súboru hostiteľa>:<cesta k súboru kontajnera>. jakubkacik$ docker run -p 80:80 -v /data/web/:/usr/local/apache2/htdocs/ httpd Výpis 1: Ukážka Docker Mount Volume Vo Výpise. 1 sa nachádza ukážka príkazu, ktorý spustí webový server Apache 10 a namapuje adresár s názvom web z hostiteľského počítača do adresára htdocs nachádzajúceho sa v kontajneri. Data Volumes Tento typ predstavuje úložisko, ktoré je vytvorené v súborovom systéme hostiteľa a plne v réžii Dockeru. Zväzok môžeme vytvoriť explicitne pomocou príkazu docker volume create <názov> alebo podobne ako v prípade Mount Volumes pomocou príkazu docker run -v <názov úložiska>:<cesta k súboru kontajnera>. Druhý spomenutý prístup je zobrazený vo Výpise 2. jakubkacik$ docker run -p 3306:3306 -v mysql-data:/var/lib/mysql mysql Výpis 2: Ukážka Docker Data Volume Pre zobrazenie dostupných zväzkov slúži príkaz: docker volume ls. Odstránenie je možné pomocou docker volume rm <názov>. 10 Informácie o obraze: zo dňa

57 5.4 Docker Swarm Docker Swam umožňuje vytvárať a spravovať kontajnerové aplikácie rozprestierajúce sa cez viacero hostiteľov. Swarm režim je predvolene vypnutý a na zapnutie slúži príkaz docker swarm init --advertise-addr <ip adresa uzlu>. Tento príkaz spôsobí, že uzol nadobudne úlohu manažéra celého clusteru. Pre rozšírenie clusteru o ďalšie uzly je potrebné vygenerovať autorizačný token. Uzly je možné pripojiť v roli manažéra alebo pracovníka. Pre tento účel slúži príkaz docker swarm join-token <manager/worker>. Obr. 23: Ukážka príkazu docker swam join-token Po vygenerovaní tokenu(obrázok 23) stačí skopírovať celý príkaz a spustiť na požadovanom uzle. Je nevyhnutné aby uzly, ktoré chceme prepojiť boli vzájomne viditeľné. Pre zobrazenie informácií o jednotlivých uzloch v clusteri slúži príkaz docker node ls, viď Obrázok 24. Tento príkaz je možné spustiť iba na manažérskych uzloch. Obr. 24: Ukážka príkazu docker node ls Ďalší užitočný príkaz predstavuje docker node update <názov uzla> --role <manager/worker>, pomocou ktorého môžeme zmeniť rolu v ktorej vystupuje uzol v rámci clusteru. Pre riadenie nasadzovania jednotlivých kontajnerov sa používajú štítky. Príkaz pre pridanie štítku ma nasledujúcu podobu: docker node update <názov uzla> --label-add <kľúč>=<hodnota>. Odstránime ho príkazom docker node update <názov uzla> --label-rm <kľúč>. Posledný príkaz z tejto sekcie reprezentuje docker swarm leave, ktorým odoberieme uzol z clustera. 5.5 Docker Compose Docker Compose reprezentuje nástroj, pomocou ktorého je možné vytvoriť viacero kontajnerov jediným príkazom. Pre tento účel sa využíva súbor s názvom docker-compose.yml, ktorý obsahuje konfiguráciu všetkých kontajnerov. Jedná sa o nástroj pre lokálny vývoj a testovanie viac-kontajnerových aplikácií. Výpis 3 zobrazuje ukážka súboru docker-compose.yml s najčastejšie používanými parametrami. 57

58 version: # Verzia docker-compose services: # Definovanie kontajnerov servicename: # Názov kontajnera image: # Obraz ports: # Nastavenie portov volumes: # Pripojenie k úložisku environment: # Nastavenie premenných prostredia kontajnera networks: # Pripojenie k sieti depends_on: # Vyjadrenie závislosti na iných kontajneroch volumes: # Definovanie úložísk networks: # Definovanie sietí Výpis 3: Docker Compose - najpoužívanejšie parametre Pre spustenie viac-kontajnerových aplikácií slúži príkaz docker-compose up. Tento príkaz je nutné spúšťať z priečinku, v ktorom sa nachádza súbor docker-compose.yml. Na zastavenie všetkých služieb sa používa príkaz docker-compose down. Vo Výpise 4 môžete vidieť praktickú ukážku docker-compose.yml. Súbor definuje Wordpress 11 kontajner dostupný na porte 8080 a databázu MariaDB 12. Tieto kontajnery spolu komunikujú prostredníctvom siete s názvom net. Wordpress využíva Mount Volume pre namapovanie webového obsahu a šablón. Databáza pre uchovanie permanentného obsahu definuje Data Volume s názvom mariadb-data. Oba kontajnery taktiež obsahujú nastavenie premenných prostredia špecifických pre danú službu. Posledné nastavenie predstavuje závislosť wordpress kontajnera na databáze, t.j. pokiaľ nedôjde k úspešnému spusteniu db, nespustí sa ani wordpress. version: 2 services: wordpress: image: wordpress ports: :80 volumes: -./wordpress-data:/var/www/html environment: 11 Informácie o obraze: zo dňa Informácie o obraze: zo dňa

59 - WORDPRESS_DB_HOST: db - WORDPRESS_DB_NAME: wordpress - WORDPRESS_DB_USER: user - WORDPRESS_DB_PASSWORD: password networks: - net depends_on: - db db: image: mariadb volumes: - mariadb-data:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD: password - MYSQL_DATABASE: wordpress - MYSQL_USER: user - MYSQL_PASSWORD: password networks: - net volumes: mariadb-data: networks: net: Výpis 4: Docke Compose - praktická ukážka 5.6 Docker Stack Docker Stack predstavuje skupinu vzájomne prepojených služieb. Podobne ako Docker Compose využíva súbor s príponou.yml pre definovanie všetkých kontajnerov. Narozdiel od Docker Compose je tento nástroj využívaný pre produkčné prostredia s viacerými uzlami. Hlavný rozdiel predstavuje podpora škálovania kontajnerov. Docker Stack umožňuje nastaviť limity pre zdroje využívané kontejnermi, pridáva možnosť nasadiť kontajner na konkrétny uzol a taktiež definuje správanie pri zlyhaní kontajnera. Všetky tieto parametre je možné nastaviť v sekcií deploy. Výpis 5 zobrazuje najvýznamnejšie parametre z tejto sekcie. deploy: mode: # Mód nasadenia - replicated, global replicas: # Počet replík kontajnera restart_policy: # Podmienka reštartovania 59

60 condition: # no, on-failture, always resources: # Nastavenie limitov pre využívanie zdrojov limits: cpu_count: cpu_percent: memory: placement: # Definovanie podmienok pre nasadenie constraints: Výpis 5: Docker Stack - sekcia deploy Po vytvorení.yml súbora, stačí spustiť príkaz docker deploy -c <.yml súbor> <názov stacku>, ktorý vykoná nasadenie všetkých kontajnerov. Pokiaľ už existuje stack s rovnakým názvom, dôjde k jeho aktualizácií. Vo Výpise 6 sa nachádza ukážka konfiguračného súboru z predchádzajúcej sekcie, ktorý som upravil pre beh v produkčnom prostredí. Služba wordpress obsahuje nastavenia pre spustenie troch replík kontajnera na manažérskych uzloch. Mód nasadenia je definovaný ako replicated - Docker sám rozhodne, na ktorých uzloch budú bežať kontajnery a taktiež dovoľuje spustenie väčšieho množstva rovnakých kontajnerov na jednom uzle. Pre db je definovaný druhý typ nasadenia - global, ktorý umožňuje spustiť maximálne jeden kontajner rovnakého typu na uzol. Databázu som nastavil tak, aby sa kontajner nasadil iba na uzloch, ktoré majú definovaný typ mariadb a obmedzil som veľkosť pamäte RAM na 8GB. version: 3.4 services: wordpress: image: wordpress ports: :80 volumes: -./wordpress-data:/var/www/html environment: - WORDPRESS_DB_HOST: db - WORDPRESS_DB_NAME: wordpress - WORDPRESS_DB_USER: user - WORDPRESS_DB_PASSWORD: password networks: - net depends_on: - db deploy: 60

61 mode: replicated replicas: 3 placement: constraints: - node.role == manager db: image: mariadb volumes: - mariadb-data:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD: password - MYSQL_DATABASE: wordpress - MYSQL_USER: user - MYSQL_PASSWORD: password networks: - net deploy: mode: global placement: constraints: - node.label.type == mariadb resources: limits: memory: 8G volumes: mariadb-data: networks: net: Výpis 6: Docke Stack - praktická ukážka Pre zobrazenie aktuálne bežiacich stackov slúži príkaz docker stack ls. Obr. 25: Ukážka príkazu docker stack ls Z Obrázku 25 možno vyčítať, že beží stack s názvom mystack, ktorý reprezentujú dve služby. Pre detailnejší náhľad na tieto služby sa používa príkaz docker stack services <názov stacku>. 61

62 Tento príkaz zobrazuje názov, id služby, mód nasadenia, porty, počet bežiacich kontajnerov a obraz z ktorého vznikli, viď Obrázok 26. Obr. 26: Ukážka príkazu docker stack services Služby definované ako replicated je možné jednoducho škálovať pomocou príkazu docker service scale <názov/id>=<počet>. Ďalší užitočný príkaz predstavuje docker service ps <názov služby>, ktorý poskytuje informácie o stavoch jednotlivých kontajnerov, vzniknutých chybách a v neposlednom rade zobrazuje, na ktorom uzle beží konkrétny kontajner. Na Obrázku 27 môžete vidieť ukážku tohoto príkazu. Obr. 27: Ukážka príkazu docker service ps Posledným príkazom v tejto časti je docker stack rm <názov stacku>, ktorý slúži na odstránenie bežiacich stackov. 5.7 Vytváranie vlastných obrazov Táto časť popisuje vytvorenie vlastného obrazu a jeho následné nahratie do repozitára Docker Hub. Dockerfile Dockerfile predstavuje súbor, ktorý obsahuje inštrukcie pre vytvorenie vlastného obrazu. Tieto inštrukcie sú vykonávané jedna po druhej a postupne vytvárajú vrstvy obrazu. Vlastné obrazy sú najčastejšie založené na linuxových distribúciach ako Alpine 13, Ubuntu 14 a podobne. Dockerfile charakterizujú nasledujúce parametre: FROM: Základ pre tvorbu vlastného obrazu. LABEL: Pridanie metadát do obrazu. RUN: Vykonávanie príkazov nad aktuálnym obrazom. ENTRYPOINT: Príkaz, ktorý sa vykoná pri spustení kontajnera. 13 Informácie o obraze: zo dňa Informácia o obraze: zo dňa

63 EXPOSE: Definovanie portu kontajnera. ENV: Nastavenie premenných prostredia. COPY: Kopírovanie nových súborov a adresárov do súborového systému kontajnera. ADD: Rovnaké ako COPY, možnosť kopírovať vzdialené súbory pomocou URL a podpora tar súborov. CMD: Príkaz, ktorý sa vykoná pri spustení kontajnera alebo argument pre ENTRYPO- INT. VOLUME: Nastavenie úložiska. USER: Nastavenie užívateľa pre spúšťanie príkazov RUN, CMD a ENTRYPOINT. WORKDIR: Nastavenie pracovného adresára pre príkazy RUN, CMD, ENTRYPOINT, COPY a ADD. ONBUILD: Inštrukcia, ktorá sa vykoná po vytvorení obrazu. Výpis 7 reprezentuje Dockerfile súbor definujúci vlastný webový server Nginx 15. Ako základ som použil linuxovú distribúciu Alpine(veľkosť 5MB), aby bol obraz čo najmenší. Inštalácia serveru a vytvorenie potrebných priečinkov prebehlo pomocou štandardných linuxových príkazov. FROM Alpine LABEL Maintener="Jakub Kačík" Version="1.0" # Inštalácia Nginx serveru a vytvorenie potrebných adresárov RUN apk add nginx && \ mkdir /run/nginx && \ mkdir /var/www/html # Nakopírovanie konfiguračného súboru COPY config/nginx.conf /etc/nginx/nginx.conf # Overenie správnosti konfiguračného súboru RUN ["nginx" "-t"] # Nakopírovanie webového obsahu COPY public/ /var/www/html/ 15 Informácia o obraze: zo dňa

64 EXPOSE 80 # Príkaz pre spustenie Nginx serveru CMD ["nginx", "-g", "daemon off;"] Výpis 7: Ukážka Dockerfile súboru pre vytvorenie webového serveru Nginx Vytvorenie obrazu Ďalší dôležitý krok predstavuje príkaz docker build -t <názov>., ktorý z inštrukcií definovaných v Dockerfile vytvorí obraz. Tento príkaz je nutné spúšťať z priečinku, v ktorom sa nachádza Dockerfile súbor. Nahratie obrazu do Docker Hubu Posledný krok reprezentuje nahratie obrazu do repozitára Docker Hub. Ako prvé je nutné vykonať prihlásenie pomocou Docker ID. Pre tento účel slúži príkaz docker login. Po úspešnom zadaní prihlasovacích údajov môžeme použiť príkaz docker tag <názov obrazu> <názov repozitára>:<verzia>, ktorým priradíme obraz do nášho repozitára. Následne je ešte potrebný príkaz docker push <názov repozitára>:<verzia>, ktorý vykoná nahratie do Docker Hubu. Pokiaľ repozitár uvedený v tom to príkaze neexistuje, dôjde k jeho automatickému vytvoreniu. Postup nahratia je zobrazený na Obrázku 28. Obr. 28: Ukážka nahratia obrazu do repozitára Docker Hub Ďalšiu možnosť predstavuje automatické vytvorenie a nahratie obrazu. Táto funkcionalita je zabezpečená prostredníctvom služby, ktorú poskytuje Docker Cloud spolu s prepojením na GitHub 16 alebo Bitbucket 17. Na základe nastavení dôjde k vytvoreniu obrazu s každou novou verziou zdrojového kódu. Jedná sa o veľmi užitočnú funkcionalitu, hlavne pri vývoji webových aplikácií. Súčasťou tohoto procesu je aj kontrola správnosti obrazu a notifikácia prostredníctvom u. Ukážka tohoto nastavenia je zobrazená na Obrázku 31 v kapitole Webová stránka GutHubu: zo dňa Webová stránka Bitbucketu: zo dňa

65 6 Portál ponuky a dopytu Gloffer 6.1 Infraštruktúra portálu Gloffer Portál Gloffer 18 predstavuje projekt spoločnosti Serious Investment s.r.o. Jedná sa o online systém pre ponuku a dopyt produktov a služieb. Systém taktiež umožňuje zrovnávanie produktov, komunikáciu zákazníkov priamo s firmami a hodnotenie týchto firiem. Infraštruktúra portálu Gloffer je tvorená 6 fyzickými servermi, ktoré zabezpečujú potrebné výpočtové prostriedky. Štyri servery sú od spoločnosti Asus a disponujú rovnakými technickými parametrami, viď Tabuľka 1. Asus Počet soketov 2 CPU Intel Xeon E Počet jadier 8 Počet vlákien 16 Frekvencia CPU Kapacita RAM Typ RAM 2.60Ghz Ghz 64GB DDR3 Tabuľka 1: Technické parametre serveru Asus Zvyšné dva servery sú značky Supermicro a podobne ako v prípade serverov Asus majú totožné technické parametre. Tieto parametre sú zobrazené v Tabuľke 2. Supermicro Počet soketov 1 CPU Intel Xeon E v3 Počet jadier 12 Počet vlákien 24 Frekvencia CPU 2.40Ghz Ghz Kapacita RAM 64GB Typ RAM DDR4 Tabuľka 2: Technické parametre serveru Supermicro Prístup k dátam je riešený pomocou zdieľaného úložiska s využitím prenosového protokolu iscsi. Všetky servery disponujú virtualizačným riešením od spoločnsoti Xen, konkrétne sa jedná o Xen- 18 Webová stránka portálu Gloffer: zo dňa

66 Server 7.2. Správa celej virtualizovanej infraštruktúry je zabezpečené pomocou nástroja Xen- Center. Pre efektívne využitie dostupných výpočtových prostriedkov, beží na každom serveri niekoľko virtuálnych strojov. Tieto stroje hosťujú operačný systém Ubuntu Server spolu so všetkými použitými technológiami, medzi ktoré patria: Nginx Jedná sa o open-source webový server, ktorý poskytuje vysoký výkon, jednoduchú konfigurovateľnosť a má nízke hardvérové nároky. Nginx je taktiež možné použiť ako reverzný proxy server alebo IMAP/POP3 proxy server. Disponuje veľkým množstvom modulov, pomocou ktorých môžeme rozšíriť jeho funkcie. Medzi spoločnosti využívajúce Nginx patrí napríklad streamovancia služba Netflix alebo repozitár pre ukladanie zdrojových kódov GitHub. [35] Elasticsearch Elasticsearch predstavuje distribuovaný RESTful nástroj pre vyhľadávanie a analýzu dát. Táto technológia je napísaná v jazyku Java a predstavuje ideálne riešenie pre webové portály vďaka full-text vyhľadávaniu v reálnom čase. Práca s ním je zabezpečená pomocou protokolu HTTP a dáta sú prenášané vo formáte JSON. Elasticsearch podporuje zoskupovanie do clusteru. [36] PHP Jedná sa o skriptovací programovací jazyk, využívaný hlavne pre tvorbu webových aplikácií. Preklad kódu prebieha na strane serveru a výsledok je odosielaný späť k užívateľovi. Jazyk je dynamicky typovaný, t.j. nepoužíva sa špecifikácia dátového typu u premenných. PHP disponuje veľkým množstvom frameworkov, ktoré uľahčujú a urýchľujú vývoj aplikácií. [37] Composer Composer predstavuje nástroj pre jednoduchú správu PHP závislostí. Umožňuje deklarovať knižnice pre náš projekt a ich následnú inštaláciu alebo aktualizáciu. Inštalačný súbor je vo formáte JSON MySQL MySQL reprezentuje relačnú open-source databázu od spoločnosti Oracle, založenú na jazyku SQL. Jedná sa o jednu z najpoužívanejších databáz pre webové aplikácie. Najčastejšie sa používa v kombinácií s webovým serverom Apache alebo Nginx a skriptovacími jazykmi ako PHP, Perl alebo Python. Obsahuje širokú škálu funkcií pre zabezpečenie vysokej výkonnosti a dostupnosti. Správu je možné vykonávať pomocou veľkého množstva nástrojov. [38] 66

67 6.1.6 MongoDB Jedná sa o open-source databázu využívajúcu dokumentovo orientovaný model. MongoDB uchováva dáta vo formáte BSON(binárna reprezentácia JSON) a podporuje natívne ukladanie dát do vyrovnávajúcej pamäte a pamäte RAM pre zabezpečenie vysokého výkonu pri zápise a čítaní. Veľkou výhodou je podpora veľkého množstva programovacích jazykov. MongoDB v sebe zahŕňa funkcie pre replikáciu, automatocké škálovanie a podporu indexov. [39] Redis Redis predstavuje open-source NoSQL databázu, ktorá sa najčastejšie používa ako cachovací nástroj pre urýchlenie webových aplikácií. Redis podporuje širokú škálu formátov(string, list, hash,...), ktoré môžu byť použité ako kľúče pre databázu. Dáta sú udržiavané primárne v pamäti, čo spôsobuje že je veľmi rýchly. Podporuje taktiež pravidelné ukladanie pamäte na disk, vďaka čomu predchádza strate údajov v prípade zlyhania. Ďalšie užitočné vlastnosti predstavujú replikácia, vstavané vyvažovanie záťaže a možnosť vytvorenia clusteru. [40] 6.2 Porovnanie virtualizačných platforiem Výber vhodnej virtualizačnej platformy predstavuje dôležitý krok, ktorý môže firmám ušetriť nemalé finančné náklady. Porovnanie platforiem som vykonal z pohľadu najnižších licenčných programov vzhľadom k faktu, že infraštruktúra portálu Gloffer je tvorená malým počtom serverov a pomer cena/výkon hrá veľmi dôležitú úlohu. [41] Porovnanie technických parametrov Tabuľka 3 zobrazuje limitujúce technické parametre jednotlivých virtualizačných produktov. Tieto parametre sú viac ako dostačujúce nielen pre potreby portálu Gloffer ale vystačili by si s nimi aj oveľa väčšie datacentrá. Jednotliví výrobcovia neustále posúvajú tieto limity, aby obstáli v tvrdej konkurencii a taktiež kvôli stále výkonnejšiemu a dostupnejšiemu hardvéru. Red Hat Virtualization 4.1 Citrix XenServer 7.3 Standard VMware vsphere 6.5 Standard Windows Server 2016 Standard CPU Hypervisor VM neobmedzene RAM 12TB 5TB 12TB 24TB vcpu VM RAM 4TB 1.5TB 6TB 12TB Úložisko 8TB 2TB 64TB 2TB Cluster Hostiteľ Tabuľka 3: Porovnanie technických parametrov virtualizačných platforiem 67

68 6.2.2 Porovnanie technologických parametrov Údaje uvedené v Tabuľke 3 ukazujú, že technické parametre nepredstavujú problém pri výbere virtualizačnej platformy. Skutočné obmedzenie nastáva až pri výbere vhodných technológií. Toto je oblasť, za ktorú si výrobcovia nechávajú zaplatiť, pretože verzie produktov sa od seba častokrát odlišujú iba v množstve použitých technológií. Tabuľka 4 porovnáva najdôležitejšie technológie jednotlivých virtualizačných produktov. Z porovnania vyplýva, že spoločnosti Red Hat, Citrix a VMware dosahujú v danej produktovej rade technologickej roviny. Z porovnania vyčnieva Microsoft, ktorý ponúka najširší súbor funkcií. Red Hat Virtualization 4.1 Citrix XenServer 7.3 Standard VMware vsphere 6.5 Standard Live Migration Maintenance Mode Automated Live Migration Power Manager Storage Migration Integrated High Availibility Automatic VM Reset Replication Hypervisor Upgrades VM Patching Live VM Snapshot Integrated Backup Automated Host Deployments VM Tamplates Orchestration Security Shared File System SW Storage Replication Caching VLAN Graphic Acceleration Container Support Windows Server 2016 Standard Tabuľka 4: Porovnanie technologických parametrov virtualizačných platforiem 68

69 6.2.3 Cenové porovnanie produktov Do výslednej sumy som zohľadnil cenu za riadiaci nástoj, pretože bez neho by nebolo možné využiť plný virtualizačný potenciál jednotlivých produktov. Pre výpočet som vychádzal z informácií obsiahnutých v Tabuľke 1, Tabuľke 2 a počtu fyzických serverov. Ceny sú vyrátané na obdobie jedného roka. Microsoft Produkt Microsoft Server 2016 Standard nebol z môjho pohľadu zaujímavý, pretože obsahoval licencie operačného systému Windows Server 2016 a infraštruktúra portálu Gloffer je založená na systémoch Linux. Alternatívne riešenie predstavuje použitie samotného hypervisora Hyper-V pre hosťovanie linuxových virtuálnych strojov ale bez možnosti akejkoľvek technickej podpory, obmedzeným súborom virtualizačných funkcií a obmedzenou správou. Red Hat Licencia produktu Red Hat Virtualization sa vzťahuje na soketový pár. V tejto licencií je ďalej zahrnutý riadiaci nástroj Red Hat Virtulization Manager a technická podpora. V Tabuľke 5 sú uvedené ceny pri 12 hodinovej podpore počas bežných pracovných dní. Pre podporu 24/7 sa cena vyšplhá na 1499$ za licenciu. Veľmi dôležitý fakt zohráva to, že technická podpora sa vzťahuje iba na certifikované OS 20. Tieto systémy sú viazané dodatočnými licenciami, čo navýši celkovú cenu virtualizácie. Existuje aj licencia, ktorá obsahuje certifikovaný systém Red Hat Enterprise Linux pre neobmedzený počet VM. Cena tejto licencie pri základnej podpore vychádza na 2,699$ a s podporou 24/7 na 3,499$. Počet Cena Spolu Red Hat Virtualization $ 4995$ Red Hat Virtualization Manager 1 v cene 0$ Technická podpora 1 v cene 0$ Výsledná suma 4995$ Tabuľka 5: Kalkulácia ceny pre produkt Red Hat Virtualization 4.1 Citrix Spoločnosť Citrix 21 má najjednoduchšiu cenovú politiku. Licencie sa vzťahujú na počet fyzických procesorov a v cene je zahrnutá technická podpora 24/7. Riadiaci nástoj XenCenter je zdarma pre všetky produkty. Tabuľka 6 obsahuje výslednú sumu produktu XenServer 7.3 Standard ceny ku dňu Zoznam certifikovaných OS: zo dňa ceny ku dňu

70 Počet Cena Spolu XenServer 7.3 Standard $ 7630$ XenCenter 1 zdarma 0$ Technická podpora 1 v cene 0$ Výsledná suma 7630$ Tabuľka 6: Kalkulácia ceny pre produkt XenServer 7.3 Standard VMware VMware 22 podobne ako Citrix licencuje počet fyzických procesorov. Tabuľka 7 obsahuje ceny pre produkty vsphere 6.5 Standard a vcenter Server Standard pri základnej technickej podpore(12 hodín počas bežných pracovných dní). Pre podporu 24/7 sa cena pre vsphere navýši na $ a v prípade vcenter Server na $. Počet Cena Spolu VMware vsphere 6.5 Standard $ 18247,80$ VMware vcenter Server Standard $ Technická podpora 1 v cene 0$ Výsledná suma $ Tabuľka 7: Kalkulácia ceny pre produkt VMware vsphere 6.5 Standard Odporučenie Na základe porovnaní z predchádzajich častí odporúčam produkt Citrix XenServer 7.3 Standard. Tento produkt disponuje porovnateľnými technologickými parametrami vzhľadom ku konkurenčným riešeniam. Technické parametre sú taktiež viac ako postačujúce pre aktuálny stav infraštruktúry portálu Gloffer. Dôležitú úlohu pri rozhodovaní zohral veľký počet podporovaných operačných systémov 23, technická podpora a v neposlednom rade cena. 6.3 Porovnanie cloudu oproti vlastnej virtualizácií Cloud v dnešenej dobe predstavuje veľmi obľúbený typ hostingu. Poskytuje zákazníkom výkon na mieru, rôzne možnosti úložiska, vyvažovanie záťaže a mnoho ďalších služieb. To všetko založené na najnovších hardvérových komponentoch a kompletne zálohované. Všetky tieto faktory robia z cloudu ideálneho adepta pre nasadenie informačných systémov. Na druhú stranu, ceny za tieto 22 ceny ku dňu Zoznam podporovaných OS: /downloads/xenserver-7-0-vm-users-guide.pdf, zo dňa

71 produkty sa môžu vyšplhať do takej úrovne, že sú neakceptovateľné pre firmy a tie si radšej vystačia s vlastnou virtualizáciou alebo presunú do cloudu len určitú časť svojich služieb. V tejto časti som nadviazal na výber virtualizačnej platformy pre portál Gloffer. Vykonal som porovnanie cenových nákladov na vlastnú virtualizáciu voči cloudovým riešeniam poskytovaných spoločnosťami Microsoft, Google a Amazon. Vzhľadom k rozmanitosti ponúkaných služieb som do porovnania zahrnul iba produkty prenájmu virtuálnych stojov(iaas). Ceny 24 sú vypočítané na obdobie jedného roka a parametre jednotlivých VM môžete vidieť v Tabuľke 8. vcpu RAM Počet VM 1. VM 8 16GB VM 4 16GB 4 3. VM 4 8GB 14 Tabuľka 8: Parametre VM pre výpočet nákladov na prevádzku v cloude Do výslednej sumy som ďalej započítal cenu za prenájom zdieľaného SSD úložiska o celkovej kapacite 4TB Cenové náklady cloudu V tejto časti som vykonal výpočet nákladov spojených s prevádzkou virtuálnych serverov v prostredí cloudu. Vo výslednej sume nie je započítaná technická podpora, vyvažovanie záťaže alebo počet vstupno-výstupných operácií za sekundu. Microsoft Azure 25 V Tabuľke 9 sú zobrazené ceny za virtuálne stoje dostupné z regiónu Západnej Európy. Pre produkt D4s bola využitá zľava za prenájom na obdobie jedného roka. Označenie produktu Cena za rok CZK 1. VM A8v VM A VM D3s Úložisko P Celková suma Tabuľka 9: Kalkulácia ceny pre Microsoft Azure 24 Ceny prepočítané z USD do CZK pomocou: zo dňa ceny ku dňu

72 Amazon Web Services 26 Amazon narozdiel od Microsoft Azure poskytoval zľavy na všetky produkty, ktoré som použil pri výpočte. Výslednú sumu môžete vidieť v Tabuľke 10. Označenie produktu Cena za rok CZK 1. VM c4.xlarge VM c4.2xlarge VM m5.xlarge Úložisko gp Celková suma Tabuľka 10: Kalkulácia ceny pre Amazon Web Services Google Cloud Platform 27 Zadaným parametrom z Tabuľky 8 vyhovoval iba produkt n1-standard-4 a pre zvyšné virtuálne stroje som musel využiť možnosť vlastnej konfigurácie. Všetky produkty ponúkali zľavu za ročný prenájom a výsledná cena je zobrazená v Tabuľke 11. Označenie produktu Cena za rok CZK 1. VM custom VM custom VM n1-standard Úložisko Celková suma Tabuľka 11: Kalkulácia ceny pre Google Cloud Platform Cenové náklady na vlastnú virtualizáciu V Tabuľke 12 môžete vidieť náklady spojené s nákupom a prevádzkou vlastného virtualizačného riešenia. Nejedná sa však o konečnú sumu, pretože netreba zabúdať ani na náklady spojené s fyzickým umiestnením serverov a taktiež je potrebné zaplatiť zamestnancov, ktorí sa starajú o prevádzku daných zariadení ceny ku dňu ceny ku dňu

73 Počet Cena CZK Spolu CZK Server Asus 4 ks Server Supermicro 2 ks XenServer 7.3 Standard 10 ks SSD 2TB 2 ks Energie kwh Celková suma Tabuľka 12: Kalkulácia ceny pre vlastnú virtualizáciu Zhodnotenie Z cien vypočítaných v Tabuľkách 12, 9, 10 a 11 vyplýva, že prevádzka vlastného virtualizačného riešenia vychádza oveľa lacnejšie ako prenájom virtuálnych serverov v prostredí cloudu. Tento rozdiel sa môže výrazne prehĺbiť pri predpoklade, že nedôjde k nákupu nových serverov v ďalších rokoch. Na druhú stranu, vlastné riešenie môže trpieť výpadkami služieb spôsobenými hardvérovým zlyhaním a taktiež pri potrebe dodatočného výkonu je nutné nakúpiť nové servery spolu s virtualizačným softvérom. Cloud v porovnaní s vlastnou virtualizáciou vyžaduje väčšie finančné náklady ale zato disponuje vysokou spoľahlivosťou, dostupnosťou a umožňuje pridať alebo odobrať výpočtové prostriedky podľa potreby vo veľmi krátkom časovom úseku. Užívateľ je taktiež oslobodený od starostí o samotný hardvér a stým spojenými technickými problémami. 73

74 7 Kontajnerizácia portálu Gloffer Posledná kapitola sa zaoberá samotným prevedením portálu Gloffer do prostredia Docker kontajnerov. Ako vývojové prostredie som použil Visual Studio Code 28 spolu s rozšírením Docker. 7.1 Návrh Projekt bude rozdelený do štyroch kontajnerov. Obrázok 29 graficky zobrazuje rozdelenie jednotlivých technológií v rámci kontajnerov a taktiež ich vzájomnú komunikáciu. Obr. 29: Diagram komponentov zobrazujúci prepojenie kontajnerov Centrálny prvok portálu Gloffer tvorí webový server Nginx spolu so skriptovacím jazykom PHP 7.1. Tento kontajner bude ďalej obsahovať Composer pomocou ktorého budú doinštalované moduly nevyhnutné pre beh webovej aplikácie. Do kontajnera bude na základe požiadaviek taktiež zaradený cachovací nástroj Redis, aby bola zabezpečená čo najrýchlejšia výmena údajov s webovou aplikáciou. Ďalší kontajner bude tvoriť NoSQL databáza MongoDB, ktorá bude slúžiť na ukladanie neštruktúrovaných dát webovej aplikácie. Veľmi dôležitý prvok bude predstavovať kontajner obsahujúci nástoj Elasticsearch. Tento kontajner bude zabezpečovať vyhľadávanie a poskytovanie výsledkov pre webovú aplikáciu v reálnom čase. Posledný kontajner bude reprezentovať relačná databáza MySQL, ktorej hlavnou funkciou bude ukladanie všetkých objektov aplikácie. 28 Webová stránka Visual Studio Code: zo dňa

75 7.2 Vytvorenie obrazov Kontajnerizácia projektu si vyžiadala nielen oficiálne obrazy dostupné v repozitári Docker Hub ale musel som taktiež vytvoriť vlastné pomocou Dockerfile súborov, vzhľadom k zložitosti niektorých kontajnerov a samotným špecifikám projektu. Nginx + PHP7.1 + Composer + Redis Tento kontajner je založený na vlastnom obraze kvôli jeho komplexnosti. Obraz som vytvoril s dôrazom na čo najmenšiu veľkosť a jednoduchú konfigurovateľnosť všetkých použitých technológií. Prvotné vytvorenie obrazu trvalo približne 5 minút a 30 sekúnd. Tento čas sa môže líšiť v závislosti od rýchlosti internetového pripojenia a výkonu samotného hardvéru. Dôležitejšiu informáciu predstavuje veľkosť samotného obrazu, ktorá po skomprimovaní činila 426MB. Tento výsledok je veľmi dobrý vzhľadom k množstvu použitých technológií. Výpis 8 zobrazuje výsledný Dockerfile súbor. FROM php:7.1-fpm-alpine LABEL Maintainer="Jakub Kacik" Version="1.0" RUN apk update && apk add --no-cache bash supervisor curl \ libcurl git autoconf imap-dev g++ libtool make gcc \ gnu-libiconv --repository \ musl-dev linux-headers libmcrypt-dev libpng-dev icu-dev \ libpq libxslt-dev libffi-dev freetype-dev \ libjpeg-turbo-dev && docker-php-ext-configure gd \ --with-gd \ --with-freetype-dir=/usr/include/ \ --with-png-dir=/usr/include/ \ --with-jpeg-dir=/usr/include/ && \ docker-php-ext-install mysqli gd intl json zip imap bcmath && \ pecl install redis && docker-php-ext-enable redis && \ pecl install mongodb && docker-php-ext-enable mongodb && \ docker-php-source delete ENV LD_PRELOAD /usr/lib/preloadable_libiconv.so RUN addgroup -S nginx && adduser -S -G nginx nginx && apk add --no-cache nginx RUN addgroup -S redis && adduser -S -G redis redis && apk add --no-cache redis RUN curl -ss php -- \ --install-dir=/usr/bin --filename=composer 75

76 RUN mkdir -p /etc/nginx/sites-available/ && \ mkdir -p /etc/nginx/sites-enabled/ && \ mkdir /redis-data && chown redis:redis /redis-data && \ mkdir /run/nginx/ && \ mkdir -p /var/www/html && chown -R nginx:nginx /var/www/html COPY config/nginx/nginx.conf /etc/nginx/nginx.conf COPY config/nginx/nginx-site.conf /etc/nginx/sites-available/default.conf COPY config/php/php.conf /usr/local/etc/php-fpm.d/ COPY config/supervisord/supervisord.conf /etc/supervisor/conf.d/supervisord.conf COPY config/redis/redis.conf /usr/local/etc/redis/redis.conf COPY --chown=nginx:nginx html/ /var/www/html/ COPY script/start.sh /start.sh USER nginx RUN composer global require hirak/prestissimo \ && composer install --no-dev --working-dir=/var/www/html USER root RUN chmod 755 /start.sh && ln -s /etc/nginx/sites-available/default.conf \ /etc/nginx/sites-enabled/default.conf EXPOSE WORKDIR /redis-data VOLUME /redis-data CMD ["/start.sh"] Výpis 8: Dockerfile pre Nginx + PHP7.1 + Composer + Redis Základ tvorí oficiálny obraz PHP7.1-fpm-alpine 29. Tento obraz som vybral kvôli jednoduchej inštalácií PHP rozšírení, pretože projekt sa rýchlo vyvíja a často dochádza k pridaniu nových doplnkov. Následovne som v sekcii RUN doinštaloval všetky potrebné rozšírenia, bez ktorých by nebola možná inštalácia ďalších technológií. Táto sekcia obsahuje príkaz docker-php-ext-install, ktorý umožňuje rýchle pridanie veľkého množstva oficiálnych rozšírení pre PHP. Medzi kľúčové rozšírenia využívané webovou aplikáciou patria: mysqli, imap, redis a mongodb. 29 Informácie o obraze: zo dňa

77 Príkaz ENV definuje cestu k doplnku libiconv. Jedná sa o opravu chyby, pri ktorej nedochádzalo k nájdeniu spomínaného rozšírenia. Nasledujú tri príkazy RUN, ktoré postupne nainštalovali Nginx, Redis a Composer. Jednotlivé technológie som rozdelil do samostatných vrstiev, aby v prípade rozšírenia niektorej z nich(inštalácia doplnkov a podobne) došlo iba k aktualizácií konkrétnej vrstvy. Toto riešenie zabezpečí, že opätovné vytvorenie obrazu po zmene v niektorej zo spomínaných vrstiev bude oveľa rýchlejšie. Ďalší príkaz RUN zabezpečil vytvorenie všetkých potrebných adresárov pre uloženie konfiguračných súborov. Tento príkaz taktiež vytvoril adresár pre zdrojové kódy aplikácie spoločne s adresárom pre ukladanie dát nástoja Redis. Nasleduje niekoľko príkazov COPY, ktoré postupne nakopírovali konfiguračné súbory, zdrojový kód aplikácie a skript pre spustenie kontajnera. Po nakopírovaní zdrojových kódov som doinštaloval závislosti pomocou Composeru. Pred týmto krokom som ešte zmenil užívateľa na nginx, pretože priečinok do ktorého sa dané závislosti inštalujú je vo vlastníctve tohoto užívateľa a taktiež samotný Composer neodporúča vykonávať inštaláciu ako root užívateľ z bezpečnostných dôvodov. Ako ďalší krok som vrátil užívateľa späť na root a pridelil potrebné práva pre spúšťací skript. Súčasťou tohoto kroku bolo aj prepojenie konfiguračných súborov serveru Nginx. Príkazom EXPOSE som definoval porty pre webový server Nginx(80, 443) a cachovací nástoj Redis(6379). Jednalo sa o štandardné porty pre dané služby. Následovne som nastavil pracovný adresár pre kontajner pomocou príkazu WORKDIR a spoločne s príkazom VOLUME som zabezpečil aby nedošlo s strate Redis údajov počas prípadného zlyhania alebo aktualizácie kontajnera. Posledný krok predstavovalo definovanie príkazu, ktorý sa spustí po vytvorení kontajnera. V tomto prípade sa jedná o skript s názvom start.sh, ktorý obsahuje pokyny pre spustenie všetkých služieb. Obrázok 30 zobrazuje štruktúru priečinku obsahujúceho všetky súbory pre vytvorenie obrazu. Obr. 30: Štruktúra priečinku WebApp 77

78 Po definovaní Dockerfilu som vytvoril repozitár v Docker Cloud a nastavil automatické vytváranie obrazu pomocou GitHubu. Jednalo sa o dôležitý krok, ktorý umožňuje prístup k aktuálnej verzií obrazu odkiaľkoľvek na svete. Obrázok 31 zobrazuje nastavenie tohoto repozitára spolu s konfiguráciou pre automatické vytvorenie obrazu. Táto konfigurácia spustí vytvorenie obrazu na základe Dockefilu uloženého v koreňovom adresári pre každú release verziou webovej aplikácie. Obr. 31: Nastavenie automatického vytvárania obrazu pre webovú aplikáciu Elasticsearch Ďalší kontajner reprezentuje vyhľadávací nástroj Elasticsearch. Pre tento kontajner som taktiež vytvoril vlastný obraz ale tentokrát sa jednalo len o minimálne úpravy. Skutočnú výzvu 78

79 pri tvorbe tohoto obrazu predstavovala samotná konfigurácia nástoja Elasticsearch, ktorá v prípade potreby zabezpečí, že sa kontajnery vedia automaticky detekovať a vytvoriť cluster pre dosiahnutie čo najvyššieho výkonu. Dockerfile pre Elasticsearch je zobrazený vo Výpise 9. FROM docker.elastic.co/elasticsearch/elasticsearch-oss:6.2.0 LABEL Maintener="Jakub Kačík" Version="1.0" Description="Elasticsearch" COPY --chown=elasticsearch:elasticsearch config/elasticsearch.yml /usr/share/ elasticsearch/config/elasticsearch.yml EXPOSE Výpis 9: Dockerfile pre Elasticsearch Ako základ obrazu som použil oficiálnu distribúciu z produkcie Elasticsearch 30. Konkrétne sa jednalo o open-source verziu 6.2. Ďalší dôležitý krok predstavovalo nakopírovanie samotnej konfigurácie s potrebnými právami, aby Elasticsearch dokázal pracovať v režime clusteru. Posledným príkazom som definoval porty na ktorých bude daná služba dostupná. Tento obraz som narozdiel od webového serveru vytvoril a nahral do repozitára pomocou štandardných Docker príkazov, pretože sa nepredpokladajú jeho časté zmeny. Postup je zobrazený vo Výpise 10. jakubkacik$ docker build -t kac0051/elastic. jakubkacik$ docker tag kac0051/elastic kac0051/elasticsearch:1.0 jakubkacik$ docker push kac0051/elasticsearch:1.0 Výpis 10: Vytvorenie a upload Elasticsearch obrazu Štruktúra priečinku pre vytvorenie obrazu s názvom kac0051/elasticsearch je zobrazená na Obrázku 32. Elasticsearch config elasticsearch.yml Dockerfile Obr. 32: Štruktúra priečinku Elasticsearch 30 Informácie o obraze: zo dňa

80 MongoDB Pre kontajner obsahujúci NoSQL databázu MongoDB 31 som použil oficiálny obraz z repozitára Docker Hub. Tento kontajner nevyžadoval žiadne špeciálne nastavenia, ktoré by nebolo možné vykonať priamo nad daným obrazom. MySQL Posledný kontajner reprezentuje relačná databáza MySQL 32. Podobne ako v predchádzajúcom prípade som použil oficiálny obraz z repozitára Docker Hub. 7.3 Príprava prostredia pre nasadenie Pre nasadenie a otestovanie kontajnerov som mal k dispozícií tri virtuálne stroje, ktoré disponovali operačným systémom Ubuntu Server Všetky virtuálne stroje boli pripojené do rovnakej podsiete. Inštalácia Dockeru Prvý krok predstavovala inštalácia samotného Dockeru na jednotlivé VM. Pre inštaláciu som vybral Stable vydanie Docker Community Edition vo verzii Jednalo sa o najnovšiu aktuálne dostupnú verziu. Postup inštalácie popisuje Výpis 11. jakubkacik$ apt-get update jakubkacik$ apt-get install docker-ce= ~ce-0~ubuntu Výpis 11: Inštalácia Docker Community Edition Vytvorenie Swarmu Ďalší krok reprezentovalo vytvorenie clusteru. Všetky uzly som nastavil do role manažéra, aby v prípade výpadku niektorého z nich dokázal cluster ďalej pracovať a prerozdeľovať úlohy. Pri tomto nastavení sa toleruje výpadok jedného uzla. Odporúča sa vždy nepárny počet manažérov. Najskôr som na jednom z uzlov povolil swarm mód, viď Výpis 12. jakubkacik$ docker swarm init --advertise-addr Výpis 12: Nastavenie Swarm módu Následne som na tomto uzle vygeneroval token pre pripojenie zvyšných virtuálnych strojov v roli manažéra(výpis 13). jakubkacik$ docker swarm join-token manager docker swarm join --token SWMTKN-1-1wx9voeq71ixjyg9gzlx05zw2zmrneoyhbirv120ts0b3vahef -afux17yggo550dy6hyevvzwus :2377 Výpis 13: Vygenerovanie tokenu pre pripojenie manažérskych uzlov 31 Informácie o obraze: zo dňa Informácie o obraze: zo dňa

81 Vygenerovaný príkaz obsahujúci token som spustil na zvyšných dvoch uzloch. Požadované zloženie clusteru som overil pomocou príkazu docker node ls a tento výsledok je možné vidieť na Obrázku 33. Obr. 33: Zloženie Swarmu pre kontajnerizáciu projektu Dodatočné nastavenia Pre riadenie nasadzovania kontajnerov som pridelil jednotlivým uzlom štítky. Prvý a druhý uzol hosťuje kontajnery MySQL a MongoDB. Výpis 14 zobrazuje príkazy, ktorými som vykonal tieto nastavenia. jakubkacik$ docker node update zvwqi0761m9iopph6er0ch8yh --label-add sql=mysql jakubkacik$ docker node update tiaoo0oirv45d9igdr1bqftd1 --label-add nosql=mongo Výpis 14: Nastavenie štítkov pre prvý a druhú uzol Na poslednom uzle som nastavil štítok pre nasadenie kontajneru obsahujúceho nástroj Elasticsearch. Toto nastavenie je zobrazené vo Výpise 15. jakubkacik$ docker node update o0qw7ssvx47rsmg1cn5cra4qv --label-add search=elastic Výpis 15: Nastavenie štítkov pre tretí uzol Všetky vyššie spomenuté služby som nasadil v móde global narozdiel od webového serveru, pri ktorom som definoval počet replík kontajnera nezávisle od toho kde sa mal nasadiť. Ako ďalší krok som vykonal nastavenie limitu pre ukladanie indexov služby Elasticsearch. Toto nastavenie je nutné vykonať na všetkých uzloch, ktoré hosťujú danú službu, inak dôjde k zlyhaniu. Minimálna hodnota predstavuje číslo Výpis 16 obsahuje postup pre toto nastavenie. jakubkacik$ grep vm.max_map_count /etc/sysctl.conf jakubkacik$ sysctl -w vm.max_map_count= Výpis 16: Nastavenie minimálneho limitu pre ukladanie Elasticsearch indexov Ďalšie nastavenia, ktoré som vykonal na hostiteľoch slúžili na zabezpečenie maximálneho výkonu cachovacieho nástroja Redis. Jednalo sa o opravu varovných hlášok, ktoré sa vyskytovali pri spúšťaní tohoto nástoja a informovali o tom, že Redis nemusí pracovať na plný výkon. Postup tohoto nastavenia je zobrazený vo Výpise 17. jakubkacik$ sysctl -w net.core.somaxconn=65535 jakubkacik$ echo never > /sys/kernel/mm/transparent_hugepage/enabled jakubkacik$ echo vm.overcommit_memory = 1 >> /etc/sysctl.conf Výpis 17: Nastavenia pre optimalizáciu výkonu nástroja Redis. 81

82 Pre zachovanie nastavení počas reštartovania systému som prvé dva príkazy z Výpisu 17 pridal do existujúceho súboru s cestou /etc/rc.local. Ako posledný krok som spustil kontajner obsahujúci riadiaci nástroj Swarmpit 33. Pomocou tohoto nástoja je možné vykonávať správu celého clusteru z prostredia webového prehliadača. Výpis 18 popisuje postup stiahnutia s spustenia Swarmpitu. jakubkacik$ git clone jakubkacik$ docker stack deploy -c swarmpit/docker-compose.yml swarmpit Výpis 18: Spustenie riadiaceho nástroja Swarmpit 7.4 Nasadenie kontajnerov Po inštalácií Dockeru a príprave samotného prostredia pre nasadenie som vytvoril súbor s názvom gloffer.yml, v ktorom som definoval všetky služby spolu s nastaveniami jednotlivých kontajnerov. Vo Výpise 19 je zobrazená výsledná podoba súboru gloffer.yml. version: "3.4" services: webapp: image: kac0051/webapp ports: - 80: :6379 deploy: replicas: 2 restart_policy: condition: on-failure update_config: parallelism: 1 delay: 20s resources: limits: memory: 6G networks: - mongo-net - mysql-net - elastic-net depends_on: 33 Webová stránka riadiaceho nástoja Swarmpit: zo dňa

83 - elasticsearch - mongodb - mysql elasticsearch: image: kac0051/elasticsearch:1.0 ports: : :9300 environment: - "ES_JAVA_OPTS=-Xms4096m -Xmx4096m" deploy: mode: global restart_policy: condition: on-failure placement: constraints: - node.labels.search == elastic resources: limits: memory: 8G networks: - elastic-net volumes: - elastic-data:/usr/share/elasticsearch/data mongodb: image: mongo ports: :27017 volumes: - mongo-data:/data/db deploy: mode: global restart_policy: condition: on-failure placement: constraints: - node.labels.nosql == mongo 83

84 resources: limits: memory: 8G networks: - mongo-net mysql: image: mysql ports: :3306 volumes: - mysql-data:/var/lib/mysql environment: - "MYSQL_ROOT_PASSWORD=pAs_Sw0rd" networks: - mysql-net deploy: mode: global restart_policy: condition: on-failure placement: constraints: - node.labels.sql == mysql resources: limits: memory: 8G volumes: mongo-data: mysql-data: elastic-data: networks: mongo-net: mysql-net: elastic-net: Výpis 19: Štruktúra súboru gloffer.yml 84

85 Ako ďalší krok som vykonal samotné nasadenie kontajnerov pomocou príkazu, ktorý je zobrazený vo Výpise 20. jakubkacik$ docker stack deploy -c gloffer.yml elastic_web_mysql_mongo --withregistry-auth Výpis 20: Nasadenie kontajnerov pre portál Gloffer V tomto príkaze som musel použiť parameter with-registry-auth, pretože súbor gloffer.yml definuje služby založené na obrazoch zo súkromného repozitára. Následne som overil beh jednotlivých služieb pomocou nástroja Swarmpit, viď Obrázok 34. Na obrázku možno vidieť, že došlo k úspešnému spusteniu všetkých kontajnerov v požadovanom množstve a taktiež k vytvoreniu sietí pomocou ktorých tieto kontajnery komunikujú. Obr. 34: Prehľad spustených služieb Po overení behu všetkých potrebných služieb som pristúpil k webovému portálu prostredníctvom IP adresy jedného z uzlov. Vďaka vstavanému Load Balanceru je možné zobraziť webový portál aj na uzle, na ktorom nie je fyzicky spustený. Kontajner obsahujúci nástoj Elasticsearch je možné v prípade potreby rozšíriť pridaním nového uzla so štítkom search=elastic. Elasticsearch automaticky rozpozná nový kontajner a vytvorí cluster pre navýšenie vyhľadávacieho výkonu. Webový server umožňuje jednoduché škálovanie prostredníctvom nástroja Swarmpit. Pri navýšení počtu replík dôjde k spusteniu nového kontajnera v priebehu niekoľkých desiatok sekúnd. Taktiež nasadzovanie novej verzie prebieha veľmi rýchlo a bez toho aby došlo k výpadku ce- 85

86 lej služby, pretože kontajnery sú aktualizované postupne. Týmto spôsobom je zaručená vysoká dostupnosť, čo v dnešnej dobe predstavuje veľmi podstatnú vlastnosť. Výsledok kontajnerizácie je zobrazený na Obrázku 35. Obr. 35: Úvodná stránka portálu Gloffer bežiaceho v kontajneroch 86