UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE. Katedra informačních technologií. Vývoj ASP.NET Core MVC aplikace s využitím služeb Microsoft Azure

UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Vývoj ASP.NET Core MVC aplikace s využitím služeb Microsoft Azure Autor BP: Martin Kočí Vedoucí BP: Ing. Pavel Bory 2018 Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Vývoj ASP.NET Core MVC aplikace s využitím služeb Microsoft Azure vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 SB. V Praze dne 26.7.2018.. (Martin Kočí)

Poděkování Děkuji vedoucímu bakalářské práce Ing. Pavlu Borymu za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Vývoj ASP.NET Core MVC aplikace s využitím služeb Microsoft Azure Development of ASP.NET Core MVC application with use of Microsoft Azure services 6

Abstrakt Tato práce se zabývá návrhem a implementací prototypu webové aplikace a integrací této aplikace s vybranými službami cloudové platformy Microsoft Azure. Vybrané cloudové služby, které tato webová aplikace zejména využívá, jsou: Azure App Service, Azure Storage, (Tables, Queues a Blobs) a Azure Document DB. Webová aplikace je naprogramována v programovacím jazyce C# a je postavena na moderním frameworku ASP.NET Core MVC. V práci je poskytnut návod, jak vybrané cloudové služby integrovat do webových aplikací implementovaných v ASP.NET Core MVC. Zároveň se práce bude zabývat popisem obecných trendů použití výše uvedených cloudových služeb. Klíčová slova: Microsoft Azure, Cloud, ASP.NET Core MVC, C#, webová aplikace Abstract The bachelor's thesis describes design and implementation of prototype of web application and integration of this application with selected services of cloud platform Microsoft Azure. The selected cloud services, which are especially used in this web application, are: Azure App Service, Azure Storage, (Tables, Queues and Blobs) and Azure Document DB. Web application is programmed with programming language C# and based on ASP.NET Core MVC framework. This bachelor's thesis provides instructions, how to integrate selected cloud services into web applications implemented in ASP.NET Core MVC. Alongside, the thesis will deal with the description of the general trends of the above mentioned cloud services. Keywords: Microsoft Azure, Cloud, ASP.NET Core MVC, C#, web application 7

Obsah Úvod... 10 1. Úvod do ASP. NET Core... 11 1.1 MVC... 12 1.2 Dependency Injection... 12 1.3 Entity Framework Core... 13 2. Cloud computing... 14 2.1 On-premises... 14 2.2 Co je to cloud... 14 2.3 Výhody a nevýhody cloudu... 15 2.4 Kategorie služeb cloud computingu... 17 2.5 Typy nasazení cloudových služeb... 18 3. Platforma Microsoft Azure... 20 3.1 Úvod do Microsoft Azure... 20 3.2 Představení služeb Microsoft Azure... 20 3.3 Azure App Services... 20 3.3.1 WebJobs... 22 3.4 Azure Storage... 22 3.4.1 Blob Storage... 23 3.4.2 File Storage... 24 3.4.3 Queue Storage... 25 3.4.4 Table Storage... 25 3.5 Azure Databases... 27 3.6 Azure Cosmos DB... 28 3.6.1 DocumentDB... 28 4. Vývoj webové aplikace... 31 4.1 Popis webové aplikace... 31 4.2 Návrh aplikace... 32 4.2.1 Použité technologie... 32 4.2.2 Architektura aplikace... 33 4.3 Příprava prostředí pro vývoj... 35 4.3.1 Visual Studio... 35 8

4.3.2 Portál Azure a předplatné.... 36 4.3.3 Hostování aplikace... 37 4.3.4 Nasazení aplikace... 41 4.4 Implementace aplikace... 42 4.4.1 Integrace s Azure DocumentDB... 42 4.4.2 Integrace s Azure Table Storage... 49 4.4.3 Integrace s Azure Blob Storage... 55 4.4.4 Integrace s Azure Queue Storage... 59 4.4.5 Integrace s WebJobs... 61 5. Obecné trendy použití vybraných služeb Microsoft Azure... 64 5.1 Obecné trendy použití Azure DocumentDB... 64 5.2 Obecné trendy použití Azure App Services... 65 5.3 Obecné trendy použití Azure Blob Storage... 66 5.4 Obecné trendy použití Azure Table Storage... 67 5.5 Obecné trendy použití Azure Queue Storage... 68 Závěr... 70 Conclusion... 72 Seznam použitých zkratek... 74 Seznam použitých zdrojů... 77 Seznam obrázků... 80 Seznam tabulek... 82 Seznam příloh... 83 Příloha A DVD-ROM... 83 9

Úvod V posledních letech došlo v oblasti informačních technologií k rychlému vývoji mnoha různých technologií a služeb. Stále snadnější dostupnost internetového připojení vede k posílení významu a popularity cloudu a to především cloudem poskytovaných cloudových služeb. Tyto služby se stávají dosažitelnějšími jak pro firmy, tak i pro běžné uživatele. Vypadá to, že obliba cloudových řešení na trhu informačních technologií stále roste, což má za důsledek, že tato řešení velmi často dostávají přednost před ostatními variantami. Zdá se tedy, že cloud a s ním související cloudové služby, jsou velkým příslibem do budoucna. Na trhu existuje nemalé množství variant, z nichž lze zvolit vhodného poskytovatele cloudových služeb. Mezi globální poskytovatele cloudových služeb patří společnost Microsoft, poskytující prostřednictvím své platformy Microsoft Azure všechny základní distribuční modely cloudových služeb IaaS, PaaS a SaaS. Tato práce si v praktické části klade za cíl vyvinout prototyp moderní webové aplikace, která bude integrována s vybranými službami již zmíněné platformy Microsoft Azure. Webová aplikace bude naprogramována pomocí programovacího jazyka C# a postavena na moderním frameworku ASP.NET Core MVC. Také by v práci mělo dojít k využití technologie Entity Framework Core. Z cloudových služeb platformy Microsoft Azure bude webová aplikace využívat zejména služby Azure App Service, Azure Storage, (Blobs, Tables, Queues) a službu Azure DocumentDB. V teoretické části bude nejprve představen moderní framework ASP.NET Core, na kterém je výše zmíněná webová aplikace postavena. Dále bude představen koncept cloud computingu, na který bude navazovat představení platformy Microsoft Azure společně s vybranými službami této platformy. V následující části bude poskytnut návod, ve kterém bude na vhodných příkladech již vyvinuté aplikace z praktické části ukázáno, jak tyto služby integrovat do webových aplikací implementovaných v ASP.NET Core MVC. Přičemž bude kladen důraz na analýzu vhodnosti použití těchto vybraných služeb. Zároveň se práce bude zabývat popisem obecných trendů použití výše uvedených cloudových služeb. 10

1. Úvod do ASP. NET Core ASP.NET Core je multiplatformní vysoko výkonný open-source framework pro tvorbu moderních v cloudu provozovaných a k internetu připojených aplikací. [5] Pomocí tohoto frameworku tedy lze vyvíjet moderní aplikace. Vývoj v ASP.NET Core se ovšem neomezuje jenom na vývoj moderních webových aplikací a služeb, ale lze také vyvíjet aplikace pro Internet of Things nebo backendové části mobilních aplikací. V případě vývoje aplikací také nejsme závislí na specifickém operačním systému. Při vývoji můžeme využít open-source vlastnosti tohoto frameworku a danou aplikaci vyvíjet jak na Windows, tak také na Linuxu či MacOS. Bezesporu velkou výhodou tohoto frameworku je možnost spuštění naší aplikace jak na.net Core, tak i na plnohodnotném.net Frameworku. Naší aplikaci potom můžeme nasadit buďto on-premises nebo do cloudu. ASP.NET Core není oproti klasickému ASP.NET postaven na knihovně Systém.Web.dll, nýbrž na sadě takzvaných NuGet balíčků. Tyto balíčky s sebou nesou výhodu v podobě možnosti optimalizace naší aplikace tak, aby obsahovala jen ty NuGet balíčky, které jsou v naší aplikaci nezbytné. Použití těchto balíčků nám přináší řadu výhod v podobě snadnějšího zabezpečení či lepšího výkonu naší aplikace. Dalším benefitem tohoto frameworku je snadná integrace s v dnešní době velmi populárními a v mnoha případech pro vývoj moderní aplikace nezbytnými client-side technologiemi. Mezi tyto technologie patří například Angular, Bootstrap, Bower, Grunt, Gulp, Knockout či React. ASP.NET Core Framework je vytvořen společností Microsoft a je zaměřen na provoz moderních aplikací v cloudu. Díky této skutečnosti tak ASP.NET Core nabízí snadnější nasazení a propojení s platformou Microsoft Azure, které se podrobně věnuji v dalších kapitolách této práce. 11

1.1 MVC ASP.NET Core MVC je postaven na architektonickém vzoru MVC, což je jeho důležitým rysem. Výhodou je, že víceméně nezáleží na tom, jestli je tento framework použit pro tvorbu webových aplikací nebo Web API, jelikož v případě obojího dochází k využití HTTP protokolu a komunikaci ve formě request-response. Myšlenkou architektury MVC je oddělení logiky od výstupu. Jedná se o architektonický vzor skládající se ze tří komponent (MVC). Model - V modelu se typicky řeší business logika a přístup k datům. View - Stará se o zobrazení obsahu uživateli skrze uživatelské rozhraní. Controller - Reaguje na požadavky od uživatele. Zajistí přístup k datům příslušného Modelu, vykonání business logiky a předání dat z Modelu do příslušného View, které se postará o zobrazení dat uživateli. Controller je tedy prostředníkem mezi Modelem a View. 1.2 Dependency Injection Důležitou vlastností ASP.NET Core Frameworku je vestavěný mechanismus Dependency Injection, jehož správné pochopení je nezbytné pro tvorbu aplikací v ASP.NET Core. Návrhový vzor Dependency Injection (DI) slouží pro snížení závislostí mezi jednotlivými částmi systému. Jeho provedení vychází z obecnějšího návrhového vzoru Inversion of Control (IoC). Tyto dva pojmy jsou často zaměňovány IoC je obecný princip, který upřednostňuje kontrolu zvenku objektů nad situací, kdy si objekt sám říká o věci v rámci svého kódu. Výsledkem je větší kontrola nad objekty a tento návrh zároveň umožňuje lepší znovu použitelnost. [27] Dependency Injection zajistí vhodné předání závislosti danému objektu. Pomocí Dependency Injection je dosaženo malé provázanosti mezi objekty. V případě ASP.NET Core dochází k využití jednoho ze specifických typů Dependency Injection, a to konkrétně Constructor Injection. Díky Constructor Injection dochází k předání instance implementující dané rozhraní do parametrů veřejného konstruktoru, kde parametry konstruktoru jsou typem daného rozhraní. 12

Aby mohla být instance, která implementuje dané rozhraní danému objektu dodána, je třeba ji zaregistrovat v již zmíněném Inversion of Control (IoC), často označovaným také jako Dependency Injection Container, který je zodpovědný za poskytnutí instance implementující dané rozhraní. Při vyžádání implementace daného rozhraní IoC tedy zajistí vytvoření instance typu třídy, která implementuje dané rozhraní a ta je poté díky Dependency Injection poskytnuta objektu, který si ji vyžádal. Jak již bylo zmíněno, tak velká výhoda Dependency Injection spočívá v možnosti znovu použitelnosti kódu, jelikož dochází k snížení závislostí mezi jednotlivými komponentami, které je poté možno snadněji použít v jiných částech aplikace. Daný kód se také stává čitelnějším, snáze rozšiřitelnějším, lépe udržitelnějším a jasné vztahy mezi komponentami napomáhají k snadnějšímu testování aplikace. 1.3 Entity Framework Core Entity Framework Core (EF Core) je poslední verzí Microsoftem doporučované technologie pro přístup k datům pro aplikace postavené na.net Core Frameworku. Entity Framework Core je navržen tak, aby byl odlehčený, rozšiřitelný a aby podporoval multiplatformní vývoj. [3] Entity Framework Core do dané aplikace získáme nainstalováním příslušného NuGet balíčku pro databázového poskytovatele, který je v aplikaci používán. Pomocí Entity Framework Core pak typicky přistupujeme k datům skrze modely dané aplikace. Důležitým pojmem, který souvisí s Entity Framework Core a umožňuje nám s ním pracovat, je takzvané Objektově-relační mapování. Entity Framework Core je objektově-relační mapper (ORM). Objektově-relační mapování je technika, která umožňuje vývojářům pracovat s daty za pomocí objektově-orentovaného přístupu skrze provádění práce potřebné k mapování mezi definovaným objektem v aplikačním programovacím jazyce a daty uloženými v relačním datovém zdroji. [3] 13

2. Cloud computing Při vývoji a hostování aplikací se zpravidla naskýtají dvě nejčastější řešení. První z nich je on-premises řešení, druhým řešením je cloud. 2.1 On-premises On-premises řešení fakticky znamená, že fyzické servery, které používáme pro svou aplikaci, jsou námi placené a také hostované. V tomto případě nejsme tedy jenom zodpovědní za vyvinutí naší aplikace, ale i za pořízení, nainstalovaní, konfiguraci a správu operačního systému a fyzického hardwaru, na kterém běží naše aplikace. Výhodou tohoto řešení je, že nad svou aplikací i infrastrukturou máme plnou kontrolu a přehled. Toto řešení s sebou ovšem nese i nemalé množství nevýhod. Značným omezením on-premises řešení je zodpovědnost nad jeho škálovatelností, tedy schopností být rozšířen. V případě škálovatelnosti bychom se mohli setkat s nutností škálovat vertikálně nebo horizontálně. Vertikální škálovatelnost označuje přidání nebo odebrání prostředků, typicky operační paměti nebo CPU. Naopak horizontální škálovatelnost znamená přidání nebo odebrání uzlů, typicky instancí serverů. V případě nesprávně provedeného škálování může docházet ke zbytečné redundanci, tedy k naddimenzování nebo poddimenzování daného řešení. Využívání on-premises řešení tak může vést až ke zbytečnému využívání prostředků během běžného provozu v době, kdy nejsou třeba. Nebo naopak může vést k limitnímu využití prostředků v době provozních špiček. Pro provozovatele on-premises řešení pak tyto situace znamenají nadbytečné náklady. Další nevýhodou on-premises řešení je zodpovědnost za zabezpečení a zálohování dat, jelikož jako poskytovatel plně odpovídáme za data, která na naší infrastruktuře skladujeme. 2.2 Co je to cloud Druhým hojně využívaným řešením při vývoji a hostování aplikací je pojem cloud, známý též jako cloud computing. Definice cloudu nemusí být úplně jasná, ale v zásadě je to termín, který se používá pro popis globální sítě serverů, z nichž každý má svoji funkci. Cloud není fyzický objekt, ale rozsáhlá síť vzájemně propojených vzdálených serverů po celém světě, které fungují jako jeden ekosystém. Tyto servery jsou navržené buď k ukládání 14

a správě dat, spouštění aplikací, nebo doručování obsahu a služeb, jako je streamování videí, webová pošta, kancelářský software nebo sociální média. Místo přistupování k souborům a aplikacím z místního nebo osobního počítače k nim přistupujete online z jakéhokoli zařízení s podporou internetu informace tak budou dostupné kdekoli a kdykoli je budete potřebovat. [6] 2.3 Výhody a nevýhody cloudu Jako každé řešení, tak i cloud s sebou přináší určité výhody a nevýhody, které by bylo vhodné při výběru konečného řešení uvážit. Cloud symbolizuje značný posun od tradičního pojetí informačních prostředků typu on-premises, který vede k jeho vysoké oblíbenosti. K výhodám cloudu bezesporu patří: Náklady - Cloud computing eliminuje náklady na pořízení, instalaci, konfiguraci a správu hardwaru a softwaru a na provoz místních datových center. Nemusíme tedy investovat jak do datového centra, tak ani do pracovníků, kteří by datové centrum spravovali. V případě zvolení tohoto řešení nemusíme řešit jednak opakované výdaje na renovaci infrastruktury, tak i skryté náklady, které se velmi často vyskytují v případě on-premises řešení. Flexibilita - Rozsah poskytovaných služeb lze v případě cloud computing měnit na vyžádání. K zajištění prostředků můžeme tedy dojít velmi rychle s minimálními časovými náklady, což umožňuje značnou flexibilitu. Elastická škálovatelnost - Umožňuje na vyžádání dodat vhodné množství informačních prostředků tak, aby infrastruktura odpovídala úrovni pracovní zátěže. Prostředky jsou nám typicky dodány z pro nás nejvýhodnější geografické polohy. Produktivita Pokud zvolíme cloudové řešení, tak za pořízení, instalaci a správu infrastruktury, na které běží naše aplikace, je zodpovědný poskytovatel. Fakt, že se o danou infrastrukturu nemusíme sami starat, typicky vede ke zvýšení produktivity a úsporám času. Práce s daty - V případě cloud computingu je odpovědnost za zabezpečení a zálohování dat na straně poskytovatele cloudových služeb. Jestliže dojde k havárii, tak bychom o svá data neměli přijít, protože jsou typicky zálohována na více redundantních uzlech poskytovatele. 15

Modernizace - Poskytovatelé cloudového řešení obvykle disponují nejmodernějším vybavením datových center. Toto vybavení zpravidla prochází častou revizí a je pravidelně aktualizováno. V případě nové verze softwaru se o jeho zavedení postará poskytovatel a nám jsou poté k dispozici nejnovější funkce. Jak je vidět, cloudová řešení s sebou nesou celou řadu výhod. S cloud computingem ovšem také souvisí i určité nevýhody, které je v případě zvolení tohoto řešení vhodné uvážit. Mezi tyto nevýhody patří: Náklady - U cloud computingu mohou být v určitých situacích náklady vyšší než u on-premises řešení. Toto se týká zejména malých projektů, kde při nevhodně zvolených možnostech dynamického škálování může docházet k nadbytečným nákladům. Toto se děje zejména krátkodobě do doby, než uživatel zjistí, jaké nastavení je pro něj nejvíce vhodné. Závislost na poskytovateli V případě zvolení cloudového řešení se v podstatě stáváme závislými na platformě daného poskytovatele. Velké rozdíly mezi poskytovateli se v mnoha případech stávají překážkou a znesnadňují migraci na jiná cloudová řešení. Omezená kontrola - Zvolení cloudového řešení má za následek, že naše data jsou uchována na cizí infrastruktuře. V praxi to znamená, že fyzicky nad svými daty nemáme prakticky žádnou kontrolu a jsme závislí na podpoře třetí strany. Nelze také vyloučit cílené či neúmyslné zneužití našich dat. Data jsou na internetu - V případě zvolení cloudového řešení cestují naše data po internetu. Poskytovatelé cloudu se samozřejmě přirozeně snaží o co nejlepší zabezpečení a šifrování dat, ovšem nelze vyloučit, že při sofistikovanějším útoku může dojít k odcizení našich dat. Odstávky - Při využívání cloudových služeb jsme plně závislí na internetu. Jakmile se z jakéhokoliv důvodu ocitneme bez internetového připojení, nebudeme moci cloudové služby využívat. Další nepříjemností, se kterou se v oblasti cloud computingu můžeme setkat, jsou plánované či neplánované odstávky, jelikož žádný systém není plně odolný vůči výpadkům. V případě plánovaných odstávek se poskytovatel řídí takzvaným SLA, neboli service level agreement, kde by měla být garantována dostupnost dané služby. 16

Latence - Jelikož jsou v případě cloud computingu datová centra rozmístěna v různých geografických lokacích, může tak v případě přenosu docházet k nežádoucím prodlevám spojení. Poté, co posoudíme výhody a nevýhody cloud computingu a rozhodneme se zvolit cloudové řešení, přichází na řadu výběr jedné z kategorií služeb, které cloud computing poskytuje. 2.4 Kategorie služeb cloud computingu Většina služeb cloud computingu spadá do tří hlavních kategorií: infrastruktura jako služba (IaaS), platforma jako služba (PaaS) a software jako služba (SaaS). Někdy se jim říká zásobník cloud computingu, protože jsou postaveny jedna na druhé. [7] Znalost vlastností a vzájemných rozdílů těchto kategorií, známých též pod pojmy servisní a distribuční modely, nám ulehčí zvolení vhodné varianty, která nejvíce odpovídá našim potřebám. Infrastruktura jako služba (IaaS) - Jedná se o nejzákladnější kategorii služeb cloud computingu. Pomocí IaaS si pronajímáte IT infrastrukturu, jako jsou servery a virtuální počítače (VM), úložiště, sítě a operační systémy, od poskytovatele cloudu na bázi průběžných plateb. [7] Platforma jako služba (PaaS) - Platforma jako služba (PaaS) odkazuje na služby cloud computingu, které dodávají na vyžádání prostředí pro vývoj, testování, dodávání a správu softwarových aplikací. Model PaaS je navržený tak, aby usnadňoval vývojářům rychlé vytváření webových nebo mobilních aplikací bez starostí o nastavování a správu podkladové infrastruktury serverů, úložiště, sítě a databází potřebných pro vývoj. [7] Software jako služba (SaaS) - Software jako služba (SaaS) je metoda dodávání softwarových aplikací přes Internet, na vyžádání a obvykle na základě předplatného. Pomocí SaaS poskytovatelé cloudu hostují a spravují softwarovou aplikaci a její podkladovou infrastrukturu a obsluhují veškerou údržbu, jako jsou softwarové upgrady a opravy zabezpečení. Uživatelé se k aplikaci připojují přes internet, obvykle pomocí webového prohlížeče v telefonu, tabletu nebo počítači. [7] 17

Obrázek 1: Distribuční modely Zdroj: http://cloudlighthouse.be/cloud/service-models/ 2.5 Typy nasazení cloudových služeb V případě cloudových služeb neřešíme pouze distribuční modely, ale je třeba také vzít v potaz, že ne všechny cloudy jsou totožné. Cloud lze rozlišovat podle majitele infrastruktury. Zpravidla existují čtyři základní kategorie pro nasazení cloudových služeb, a to veřejný cloud, privátní cloud, hybridní cloud a komunitní cloud. Veřejný cloud - Veřejné cloudy jsou vlastněné a provozované jinými poskytovateli cloudové služby, kteří dodávají své výpočetní prostředky, jako jsou servery a úložiště, přes internet. Microsoft Azure je příkladem veřejného cloudu. U veřejného cloudu veškerý hardware, software a další podpůrnou infrastrukturu vlastní a spravuje poskytovatel cloudu. [7] Privátní cloud - Privátní cloud odkazuje na prostředky cloud computingu, které používá jediná společnost nebo organizace. Privátní cloud může být fyzicky umístěný v místním datovém centru společnosti. Některé společnosti také platí jiným 18

poskytovatelům služeb za hostování jejich privátního cloudu. Privátní cloud je takový, kde se služby a infrastruktura spravuje v privátní síti. [7] Hybridní cloud - Hybridní cloudy kombinují veřejný a privátní cloud, které jsou technologicky propojené, aby mezi nimi šlo sdílet data a aplikace. Možnost hybridního cloudu přesouvat data a aplikace mezi privátním a veřejným cloudem dává společnostem větší flexibilitu a další možnosti nasazení. [7] Komunitní cloud Cloudová infrastruktura je provozována pro výhradní použití specifickou komunitou spotřebitelů, které mají sdílené zájmy (například cíl, bezpečnostní požadavky, politiku a dodržování předpisů). Může být vlastněna, spravována a provozována jednou nebo více organizacemi v komunitě, třetí stranou nebo kombinací obojího a může existovat on nebo off premises. [4] 19

3. Platforma Microsoft Azure Azure je kompletní cloudová platforma, která může hostovat naší existující aplikační infrastrukturu, nabízet výpočetní služby ušité na míru potřebám vývoje naší aplikace, nebo dokonce rozšířit naše on-premises aplikace. Azure integruje cloudové služby, které jsou potřeba k vývoji, testování, nasazení a správě našich aplikací - zatímco využíváme výhod efektivnosti cloud computingu. [1] 3.1 Úvod do Microsoft Azure Velkou výhodou Microsoft Azure je, že se jedná o velmi otevřenou a flexibilní platformu. V praxi to znamená, že si můžeme vybrat z více různých druhů operačních systémů, databází, programovacích jazyků, nástrojů a frameworků, pomocí kterých můžeme vytvořit služby hostované v Microsoft Azure. Navíc díky integrovaným nástrojům DevOps a Marketplace, lze získat efektivní podporu pro vývoj různých moderních aplikací. [1][2] Fyzicky je možné si Microsoft Azure představit jako rozšiřující se síť data center po celém světě. Tato data centra jsou zformována do takzvaných regionů. V době psaní této práce disponuje Microsoft Azure 50 regiony, přičemž se brzy chystá zprovoznění nemalého množství dalších regionů různě po světě. Tento fakt bezesporu staví Microsoft do role jednoho z globálních leaderů v poskytování cloudových služeb. Vysoký počet regionů je v kontextu cloudu velmi důležitý, jelikož na něm závisí dosažení vyšších výkonů, snadnější splnění požadavků uživatelů a variabilnější preference pro umístění dat. 3.2 Představení služeb Microsoft Azure Pokud se chystáme vyvíjet aplikace v Microsoft Azure, tak budeme s jistotou využívat některé z velkého množství nabízených služeb této platformy. V následujících kapitolách dojde k představení vybraných služeb, které budou v praktické části této práce integrovány s webovou aplikací vyvinutou v ASP.NET Core. Jedná se především o služby Azure App Services, Azure Storage a Azure Document DB, která je nyní součástí služby Azure Cosmos DB. 20

3.3 Azure App Services Azure App Services umožňuje rychlé vytváření a hostování cloudových aplikací. Azure App Services je nejlepší volbou pro většinu webových aplikací. Nasazování a správa jsou integrovány přímo do platformy, webové aplikace se mohou rychle škálovat tak, aby zvládli provoz při vysoké zátěži, a vestavěný load balancing a traffic manager zajišťují vysokou dostupnost aplikace. [8] Při vytváření App Service si lze vybrat některou z dostupných typů aplikací, které jsou v rámci Azure App Services nabízeny. Web Apps Umožňuje vytvářet a hostovat webové aplikace v programovacím jazyce podle vašeho výběru, aniž by bylo potřeba zabývat se správou infrastruktury. Nabízí automatické škálování a vysokou dostupnost, podporuje systémy Windows a Linux a umožňuje automatizované nasazení z Githubu, Visual studio Team Services nebo libovolného úložiště Git. [9] Mobile Apps Umožňuje vytvářet zajímavé multiplatformní a nativní aplikace pro ios, Andriod, Windows nebo Mac, ukládat data aplikací do cloudu nebo místně, ověřovat zákazníky, posílat nabízená oznámení nebo přidávat svoji vlastní back-endovou logiku. [10] API Apps Usnadňuje sestavení, hostování a využití rozhraní API napsaných v různých jazycích. [11] Logic Apps Služba Azure Logic Apps zjednodušuje vytváření automatizovaných škálovatelných pracovních postupů, které integrují aplikace a data napříč cloudovými službami a místními systémy. [12] Function Apps Azure Functions je výpočetní služba bez serveru umožňující spouštění kódu na vyžádání bez nutnosti explicitně zřizovat nebo spravovat infrastrukturu. Azure Functions můžete použít ke spuštění skriptu nebo kusu kódu jako reakci na různé události. [13] Web App for Containers Umožňuje vývojářům vzít vlastní kontejnerové image ve formátu Dockeru a snadno je nasadit a spouštět ve velkém s využitím Azure. [11] 21

3.3.1 WebJobs WebJob je funkce Azure App Services, která umožňuje spouštět programy nebo skripty jako úlohy na pozadí v rámci stejné webové aplikace. [14] WebJobs sdílí stejný prostor s Azure Web App a lze je konfigurovat třemi způsoby: Spouštět nepřetržitě WebJob se spustí při svém vytvoření, reaguje na události a běží nepřetržitě. Spouštět podle plánu WebJob se spustí podle předem vytvořeného plánu. Spouštět na vyžádání - WebJob se spustí na vyžádání. Typickým využitím WebJobs v aplikacích je spouštění úloh, které nevyžadují interakci s uživatelem, což typicky vede k zlepšení dostupnosti a responzivity aplikace. 3.4 Azure Storage Microsoft Azure Storage je cloudová služba spravovaná Microsoftem, která poskytuje vysoce dostupné, zabezpečené, odolné, škálovatelné a redundantní úložiště. Azure Storage se skládá ze služeb Blob Storage, File Storage, Queue Storage, a Table Storage.[15] V případě, že se chystáme využít některou ze služeb poskytovaných Azure Storage, tak je potřeba disponovat účtem úložiště. V zásadě existují dva typy účtů úložiště pro obecné účely, a to úroveň Standard a úroveň Premium. [1] Nejvíce rozšířeným druhem účtů úložiště jsou úložiště úrovně Standard, které mohou být použity pro všechny čtyři typy dat Blobs, Files, Tables a Queues. Účty úložiště úrovně Standard používají magnetická média pro ukládání dat. [1] Úložiště úrovně Premium poskytuje vysoce výkonné úložiště pro objekty Page blob a konkrétně pro virtual hard disks (VHDs). Účty úložiště úrovně Premium používají SSD k ukládání dat. Microsoft doporučuje používat úložiště úrovně Premium pro všechny naše virtuální stroje (VMs). [1] 22

Za předpokladu, že se chystáme využít Blob Storage, naskýtá se nám další možnost výběru typu účtu, a to účet služby Blob Storage. Účet služby Blob Storage je specializovaný účet úložiště používaný k ukládání objektů Block blobs a Append blobs. V tomto typu účtu úložiště nelze uchovávat Page blobs, tudíž zde nelze uchovávat VHD soubory. Tyto účty úložiště poskytují možnost zvolit vrstvu přístupu na Hot a Cool. Tato vrstva může být kdykoliv změněna. Vrstva přístupu Hot se používá pro soubory, ke kterým se přistupuje často. V případě blobů uložených ve vrstvě Hot platíte vyšší náklady za uchovávání blobů, ale náklady na přístup k blobům jsou mnohem nižší. Vrstva přístupu Cool se používá pro soubory, ke kterým se přistupuje méně často. V případě blobů uložených ve vrstvě Cool platíte vyšší náklady za přístup k blobům, ale náklady na uchovávání blobů jsou mnohem nižší [1] Tabulka 1: Typy účtů úložiště Azure Storage Typ účtu úložiště Standard Premium Blob Storage Podporované Blob, File, Queue, Blob Blob služby Table Typy podporovaných objektů blob Append blob, Block blob, Page blob Page blob Append blob, Block blob Zdroj: Vlastní zpracování 3.4.1 Blob Storage Azure Blob Storage je řešení cloudového úložiště Microsoftu pro datové objekty. Blob Storage dokáže ukládat velké objemy nestrukturovaných dat objektů, jako jsou textová nebo binární data. Přístup k datům ve službě Blob Storage je možný odkudkoli na světě přes protokol HTTP nebo HTTPS. [16] V případě této služby se typicky jedná o uchovávání archivních a záložních souborů, logů, obrázků, videa, hudby nebo dokumentů. Soubor libovolné velikosti a typu je určitým blob objektem a ty jsou organizovány do kontejnerů v rámci daného účtu. 23

Obrázek 2: Koncept služby Blob Storage Zdroj: https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobsintroduction Jak již bylo zmíněno, Azure Blob Storage podporuje tři druhy objektů blob. Block blobs Block blobs jsou tvořeny bloky dat a primárně se používají pro uchovávání souborů, které jsou čteny od začátku do konce, jako jsou mediální soubory nebo obrázky pro webové stránky. [1] Append blobs Jsou tvořeny z bloků jako block bloby, ale jsou optimalizovány pro doplňující operace. Jsou často používány pro logování informací z jednoho nebo více zdrojů do stejného blobu. [1] Page blobs Se používají pro uchování souborů s náhodným přístupem. Page blobs se primárně používají jako záložní úložiště pro VHD, který poskytuje odolné disky pro Azure virtuální stroje (Azure VMs), IaaS službu v Azure Compute. [1] 3.4.2 File Storage Azure File Storage umožňuje nastavit vysoce dostupné sdílené složky souborů sítě, ke kterým je možný přístup pomocí standardního protokolu SMB (Server Message Block). To znamená, že více virtuálních počítačů může sdílet stejné soubory s oprávněním ke čtení i zápisu. Soubory lze číst také pomocí rozhraní REST nebo klientských knihoven pro úložiště. [1] Zmíněná služba přináší značnou výhodu oproti klasickým on-premises sdíleným složkám, a to, že je možné ke sdíleným složkám přistupovat odkudkoliv skrze internet pomocí URL. Dále nám toto služba ulehčuje migraci aplikací i verzování nástrojů a služeb a odpadá starost o dostupnost a správu infrastruktury. 24

3.4.3 Queue Storage Azure Queue Storage je služba pro ukládání velkého počtu zpráv, ke kterým lze získat přístup z jakéhokoli místa na světě prostřednictvím ověřených volání s využitím protokolu HTTP nebo HTTPS. Jedna zpráva fronty může mít velikost až 64 kb a jedna fronta můžete obsahovat miliony zpráv, až do dosažení celkové kapacity účtu úložiště. V Queue Storage jsou zprávy organizovány do front v rámci daného účtu a zpráva může setrvat ve frontě maximálně sedm dní. [17] Toto úložiště podporuje takzvané First in First out fronty. Tato metoda zpracování dat je též známá pod pojmem FIFO, což je datová struktura, pro uchování dat, kde data vystupují ze struktury ve stejném pořadí, jako do ní vstupují. V případě fronty zpravidla dochází k asynchronnímu zpracování zpráv. Obrázek 3: Koncept služby Queue Storage Zdroj: https://docs.microsoft.com/en-us/azure/storage/queues/storagequeues-introduction 3.4.4 Table Storage Azure Table Storage je služba, která ukládá semi-strukturovaná data NoSQL do cloudu a poskytuje úložiště klíč-hodnota s návrhem bez použití schématu. Vzhledem k tomu, že je Table Storage bez schématu, je snadné data přizpůsobovat měnícím se potřebám aplikace. Přístup k datům Table Storage je pro mnoho typů aplikací rychlý a nákladově efektivní a pro podobné objemy dat obvykle znamená nižší náklady než tradiční SQL. [18] 25

V tabulce lze uložit libovolný počet entit a účet úložiště může obsahovat libovolný počet tabulek, až do limitu kapacity účtu úložiště. [18] Tabulka Je kolekcí entit. Tabulky nevynucují u entit schéma, což znamená, že jedna tabulka může obsahovat entity s různými sadami vlastností. [18] Entita Je sada vlastností, která se podobá řádku databáze. Entita ve službě Azure Storage může mít velikost až 1MB. [18] Vlastnost Podobá se sloupečku databáze. Vlastnost je pár názevhodnota. Každá entita může obsahovat až 252 vlastností pro ukládání dat. Každá entita má také tři systémové vlastnosti, které určují klíč oddílu (PartitionKey), klíč řádku (RowKey) a časové razítko (Timestamp). Entity se stejným klíčem oddílu můžete dotazovat rychleji a můžete je vkládat nebo aktualizovat v atomických operacích. Klíč řádku entity je jedinečným identifikátorem v rámci oddílu. [18] Klíč řádku a klíč oddílu spolu dohromady tvoří primární klíč entity. Obrázek 4: Koncept služby Table Storage Zdroj: https://docs.microsoft.com/en-us/azure/cosmos-db/table-storageoverview 26

3.5 Azure Databases Pokud se rozhodneme migrovat již existující aplikace do Microsoft Azure nebo vytvářet nové aplikace, tak bude v naší aplikaci jistě zapotřebí interakce s databází. V případě Microsoft Azure, lze využít některou z velkého množství služeb, které tato platforma poskytuje. Microsoft Azure nabízí portfolio zabezpečených, plně spravovatelných databázových služeb na podnikové úrovni, které podporují open source databázové stroje a umožňují rychlý vývoj. [19] Azure platforma nabízí několik možností, ze kterých si lze vybrat. V případě nabídky relačních databází lze využít Azure SQL Database, SQL Server běžící v Azure Virtual Machines nebo nemicrosoftí databázi jako Oracle nebo MySQL. [1] Z novějších relačních databázových služeb můžeme využít Azure Database pro PostgreSQL nebo Azure Database pro MariaDB. [19] Za předpokladu, že pro potřeby naší aplikace je více vyhovující nerelační databáze (NoSQL), pak pro tyto případy nabízí Azure Databases služby Azure Cosmos DB nebo Azure Table Storage. [19] Azure Databases poskytují i jiné služby než klasické relační a nerelační databáze. Mezi takové služby patří: Azure Database Migration Service Je plně spravovatelná služba navržená k bezproblémové migraci z více databázových zdrojů do platformy Azure Database s minimálními odstávkami. [20] Azure Redis Cache Zabezpečený zprostředkovatel zasílání zpráv a paměťové úložiště, která poskytuje vysokou propustnost a nízkou latenci pro přístup k datům aplikací. [21] Azure Data Factory Služba pro integraci hybridních dat (ETL) umožňuje vytvářet, plánovat a spravovat datovou integraci ve velkém měřítku. [22] SQL Data Warehouse Plně spravovatelný elastický datový sklad se zabezpečením na všech úrovních škálování. [19] 27

3.6 Azure Cosmos DB V průběhu tvorby této práce byla provedena reorganizace určitých služeb Microsoft Azure. Mezi službami, kterých se tato změna dotkla, byla i Azure DocumentDB. Služba Azure DocumentDB byla v podstatě první generací služby Azure Cosmos DB, které je nyní sama součástí. Oproti původní verzi byla do Cosmos DB přidána celá řada funkčností i významných vlastností a došlo k jejímu výraznému rozšíření. V důsledku této přeměny se automaticky jakýkoliv uživatel Azure Document DB stal uživatelem Azure Cosmos DB a získal tak přístup ke všem vlastnostem této služby. Azure Cosmos DB je globálně distribuovaná databáze pro vysoce škálovatelné aplikace s nízkou latencí a s nativní podporou NoSQL. Nabízí globální distribuci na klíč a automaticky replikuje data do libovolného počtu Azure regionů, tak aby data byla co nejblíže uživatelům, a tím zajišťuje přístup s rychlou odezvou. Lze elasticky škálovat a platit jen za propustnost a úložiště, které potřebujeme. Dále nabízí různé jasně definované modely konzistence a garantuje latenci při čtení nižší než 10 milisekund a při zápisu nižší než 15 milisekund na úrovni 99. percentilu v rámci jednoho regionu. To vše je zajištěné špičkovými komplexními smlouvami o úrovni služeb (SLA) zajišťující 99,999% vysokou dostupnost, latenci na úrovni 99. percentilu, garantovanou propustnost a konzistenci. [23] Důležitou vlastností Cosmos DB je, že se jedná o službu podporující více datových modelů. Pouze Azure Cosmos DB umožňuje používat data typu klíčhodnota, graf, sloupec a dokument v jediné službě. Azure Cosmos DB automaticky indexuje všechna data a pro přístup k datům umožňuje použití oblíbených rozhraní API, včetně SQL, JavaScript, Gremlin, MongoDB, Apache Cassandra a Table. [23] 3.6.1 DocumentDB Po již zmíněné reorganizaci služeb Microsoft Azure, se služba Azure DocumentDB stala součástí služby Azure Cosmos DB. DocumentDB je nyní jedním z dostupných rozhraní API pro Azure Cosmos DB. Konkrétně se jedná o rozhraní SQL API. Místo typů účtu DocumentDB máme nyní k dispozici typy účtů SQL API. 28

Pokud se chystáme pracovat se službou Azure Cosmos DB: SQL API, tak musíme disponovat účtem Azure Cosmos DB, jehož typem je SQL API. Databázový účet se skládá ze sady databází, kde každá obsahuje několik kolekcí, z nichž každá pak může obsahovat uložené procedury, triggery, funkce UDF, dokumenty a související přílohy. K databázi jsou také přiřazeni uživatelé. Každý má sadu oprávnění pro přístup k různým kolekcím, uloženým procedurám, triggerům, funkcím UDF, dokumentům a přílohám. [24] Databáze, uživatelé, oprávnění a kolekce jsou systémem definované prostředky s dobře známými schématy dokumenty, uložené procedury, triggery, funkce UDF a přílohy obsahují libovolný, uživatelem definovaný obsah JSON. [24] Kolekce je tedy jakýmsi kontejnerem pro dokumenty a může obsahovat libovolné množství dokumentů, které mohou mít různou strukturu. Obrázek 5: Koncept služby Azure Cosmos DB: SQL API Zdroj: https://docs.microsoft.com/en-us/azure/cosmos-db/sql-api-introduction 29

Díky rozhraní SQL API lze provádět dotazy pomocí dobře známých příkazů jazyka SQL nad daty formátu JSON bez schématu s konsistentní nízkou latencí. [24] Jazyk SQL ovšem není jediným možným způsobem, jak dotazovat dokumenty JSON ve službě Azure Cosmos DB: SQL API. Pro.NET vývojáře nabízí rozhraní SQL API vývojářskou sadu.net SDK, které nabízí poskytovatele dotazů jazyka LINQ. [24] Důležitou vlastností této služby je, že Azure Cosmos DB automaticky indexuje všechny dokumenty v databázi a neočekává ani nevyžaduje žádné schéma nebo vytváření sekundárních indexů. [24] Toto má za důsledek zrychlení dotazování a vyhledávání v databázi a také umožňuje dokumentům mít libovolnou strukturu. Rozhraní SQL API také umožňuje psát logiku aplikace jako programy vytvořené zcela v JavaScriptu. Tyto programy se registrují do kolekcí a mohou provádět databázové operace nad dokumenty dané kolekce. JavaScript je možné zaregistrovat ke spouštění jako trigger, uloženou proceduru nebo uživatelem definovanou funkci (UDF). Všechna JavaScriptová logika se spouští jako transakce. Pokud dojde k vyvolání výjimky během spouštění JavaScriptu, je celá transakce zrušena. [24] 30

4. Vývoj webové aplikace Tato kapitola se zabývá představením webové aplikace vyvinuté v ASP.NET Core MVC a následnou integrací vybraných služeb cloudové platformy Microsoft Azure s touto aplikací. V následujících částech této kapitoly dojde nejprve k popsání již zmíněné webové aplikace. Na popis aplikace navazuje pasáž, která je věnována použitým technologiím a návrhu architektury webové aplikace. Dále bude popsána příprava prostředí pro vývoj, jenž se bude zabývat vývojářskými nástroji, uživatelskými účty Microsoft a druhy předplatného, kterými je nezbytné disponovat, abychom mohli při vývoji využívat platformu Microsoft Azure a její nabízené služby. Následně se tato kapitola věnuje hostování a nasazení webové aplikace do prostředí Microsoft Azure. Závěrečná část této kapitoly je věnována implementaci webové aplikace vytvořené v praktické části této práce a poskytne návod, jak nastavit a integrovat vybrané služby Microsoft Azure s touto aplikací. 4.1 Popis webové aplikace Pro účely této práce byla vytvořena webová aplikace administračního systému fiktivní společnosti. Společnost vlastní několik budov označovaných jako Meeting Centres, ve kterých se nachází zasedací místnosti známé jako Meeting Rooms. Tyto Meeting Rooms jsou využívány zaměstnanci společnosti. V administračním systému se nachází databáze zaměstnanců, ve které lze prohlížet a filtrovat celkový seznam zaměstnanců společnosti. Dále je umožněno vytváření nových zaměstnanců či zobrazení detailu, aktualizace nebo smazání stávajících zaměstnanců. Každý zaměstnanec v aplikaci také disponuje určitým uživatelským nastavením. Jedná se jednak o kategorii profilového nastavení uživatele a také o kategorii nastavení aplikace. Uživatelské nastavení daného zaměstnance je přímo závislé na daném zaměstnanci. Pokud bude v aplikaci vytvořen nový zaměstnanec, tak automaticky dochází k vytvoření jeho uživatelských nastavení. Toto nastavení je pak možné zobrazit a aktualizovat v sekci nastavení zaměstnanců. Pokud dojde v aplikaci ke smazání daného zaměstnance, dochází tak i ke smazání jeho uživatelského nastavení. Poslední částí aplikace je úložiště pro média. V této části se nachází seznam obrázků zaměstnanců a seznam nahraných videí. V případě obrázků je možno zobrazit jejich 31

detail nebo jednotlivé obrázky stahovat či smazat. Je také umožněno do aplikace nahrávat obrázky daných zaměstnanců v libovolném rozlišení. Po nahrání obrázku do aplikace dochází k jeho asynchronnímu zpracování do požadovaného rozlišení. V případě videí je umožněno jednotlivá videa do aplikace nahrávat nebo z aplikace stahovat či smazat. 4.2 Návrh aplikace Obrázek 6: Úvodní strana aplikace Zdroj: Vlastní zpracování Než dojde k přípravě prostředí pro vývoj a následné samotné implementaci webové aplikace, je nejprve zapotřebí představit použité technologie a architekturu aplikace. 4.2.1 Použité technologie Webová aplikace je vyvinutá za použití již zmíněného moderního frameworku ASP.NET Core MVC. Backendová část aplikace je implementována v programovacím jazyce C#, který běží na straně serveru. Ve frontendové části aplikace jsou především využity populární technologie jako: HTML, CSS, javascriptová knihovna jquery a framework Bootstrap, který zajišťuje responsivní web design. Dochází zde ale také k 32

použití jazyka C# pro zpracování dat ze serveru, a to díky šablonovému systému Razor, který umožňuje ve Views kombinovat C# s HTML. Všechny části webové aplikace jsou provozovány v cloudové platformě Microsoft Azure. V případě této práce spadají veškeré použité služby do kategorie služeb PaaS. Tento distribuční model umožňuje rychlé vytváření aplikací, aniž bychom se museli starat o použitou infrastrukturu. Tato povinnost potom připadá na poskytovatele cloudu, tedy v našem případě na společnost Microsoft, což nám dává možnost plně se soustředit na samotný vývoj aplikace. 4.2.2 Architektura aplikace Celkovou architekturu vytvořené aplikace, tedy použité služby a jejich vzájemnou komunikaci zachycuje níže přiložený diagram. Obrázek 7: Diagram architektury aplikace Zdroj: Vlastní zpracování 33

Veškeré služby cloudové platformy Microsoft Azure, které jsou použity v aplikaci, jsou součástí jednoho logického kontejneru, tedy jedné Resource Group. Webová aplikace je hostována a spravována v jednom App Service plánu. Součástí App Service plánu je jedna App Service. S App Service souvisí Web App a WebJobs. Web App je typem App Service a slouží jako prostor pro běh vytvořené webové aplikace. WebJobs je funkce Web App a umožňuje spouštět úlohy, které probíhají na pozadí. V případě této aplikace souvisí využití WebJobs především se službami Azure Blob Storage a Azure Queue Storage. Azure Blob Storage se primárně využívá jako úložiště pro velké množství nestrukturovaných dat. V aplikaci je tato služba využita jednak jako úložiště pro obrázky, které je možno vložit do aplikace při vytváření fotografií zaměstnanců nebo jako úložiště pro videa. Azure Queue Storage je ideálním místem pro asynchronní zpracování zpráv. Pokud v aplikaci dojde k uložení obrázku do Blob Storage, tak je v aplikaci vytvořena zpráva obsahující příslušné informace o obrázku, a ta je zařazena do fronty. Z fronty si tuto zprávu vyzvedne WebJob a na jejím základě daný obrázek na pozadí zpracuje, takže nedojde k prodlevě při používání aplikace. Po dokončení zpracování je nová verze obrázku uložena do Blob Storage a daná zpráva je z fronty smazána. Asynchronní zpracování obrázků má za cíl každý vložený obrázek zkomprimovat a vytvořit z něj miniaturu odpovídající příslušnému rozlišení. Azure Table Storage je vhodná k ukládání velkého množství dat, ke kterým je potřeba často a rychle přistupovat, ale která není potřeba dotazovat. V aplikaci je toto úložiště použito pro různá uživatelská nastavení, kterými disponuje každý uživatel aplikace. Jedná se o kategorii profilového nastavení uživatele a o kategorii nastavení aplikace. Azure DocumentDB neboli Azure CosmosDB: SQL API jakožto NoSQL databáze, je vhodná pro ukládání velkého množství dat, která jsou potom uchována v dokumentech formátu JSON. Její výhoda je, že poskytuje rychlý přístup k datům a 34

možnost dotazování nad těmito daty. V aplikaci byla tato služba zvolena jako vhodné úložiště pro vytvořené zaměstnance, Meeting Centra a Meeting Roomy. 4.3 Příprava prostředí pro vývoj Abychom mohli začít vyvíjet aplikace za pomocí vývojářského nástroje Visual Studio a cloudové platformy Microsoft Azure, je nejprve zapotřebí disponovat uživatelským účtem Microsoft. Tento účet lze vytvořit na oficiálních webových stránkách Microsoftu. Existují dva druhy uživatelských účtů. Prvním z nich je osobní uživatelský účet Microsoft. Druhým je Microsoft účet organizace, který lze získat v případě příslušnosti k pracovní nebo školní organizaci spolupracující s Microsoftem. 4.3.1 Visual Studio V případě vývoje.net aplikací, je nejlepší volbou využít nástroj Visual Studio, který je spravován přímo Microsoftem. Visual Studio je interaktivní vývojové prostředí (IDE) a tvůrčí odrazový můstek, který lze použít pro zobrazení a úpravu zdrojového kódu, ale také k ladění, sestavování a publikaci různých druhů aplikací. Visual studio je dostupné pro operační systémy Windows a Mac a lze s jeho pomocí vyvíjet aplikace s použitím rozdílných programovacích jazyků. [25] Velkou výhodou Visual Studia je integrovaná podpora vývoje pro Microsoft Azure pomocí Azure.NET SDK, která velmi ulehčuje proces vývoje aplikací pro Azure. Sestavení, správa, testování a nasazení aplikací je tak s použitím tohoto nástroje velmi usnadněno. Tento vývojářský nástroj je dostupný v několika edicích a verzích. V době tvorby této práce je nejnovější verzí Visual Studio 2017. Microsoft se oproti předchozím verzím snaží vždy pravidelně poskytovat zlepšené funkčnosti a přidávat podporu nových verzí.net Frameworku pro snadnější a bezproblémový vývoj aplikací. Visual studio také nabízí různé edice. První z nich je Community, která je poskytována zdarma a je podmíněna vytvořením účtu Microsoft. Tato edice je primárně určena pro studenty a samostatné vývojáře. Další verzí je Professional, která je určena hlavně pro produkční a profesionální vývoj a malé vývojářské teamy. Třetí verzí je Enterprise, jenž slouží především vývojovým týmům, které vyvíjí komplexní řešení s velkými nároky a zabývají se všemi fázemi vývoje software. 35

Všechny výše uvedené edice se samozřejmě liší jak úrovní poskytovaných služeb, tak i svou cenou. Aktuální ceník všech edic předplatného je dostupný na oficiálních webových stránkách Visual Studia. Při tvorbě této práce bylo použito Visual Studio s edicí Community, která byla pro potřeby aplikace naprosto dostačující. 4.3.2 Portál Azure a předplatné. Vytvářet, spravovat a monitorovat všechny služby Microsoft Azure lze jednak programově pomocí příkazové řádky nebo pohodlněji skrze portál Azure. Při tvorbě této práce byla využita forma přístupu přes portál Azure. Tento portál je dostupný na webové stránce https://portal.azure.com a pro přístup k tomuto portálu je nezbytné vlastnit některý z již zmíněných Microsoft účtů. Abychom mohli využívat služby Microsoft Azure, a tedy i portál Azure, tak je nezbytné disponovat předplatným. Zde existuje několik druhů předplatného. Pokud začínáme s vývojem pro Microsoft Azure, tak Microsoft nabízí používání Azure na 30 dní s kreditem 200$ a s ročním či nelimitovaným bezplatným přístupem k vybraným službám. Často využívaným typem předplatného je také takzvané Pay-As-You-Go, neboli průběžné předplatné, kde platíme jen za prostředky, které použijeme. Pro studenty nabízí Microsoft předplatné Azure for Students s dostupným kreditem 100$. Pro začínající podnikatele pak stojí za zmínku program Microsoft BizSpark, který nabízí měsíční kredit v hodnotě 130$. Velmi zajímavým druhem předplatného je také takzvaný Azure Pass, který poskytuje kredit 100$ na měsíc po dobu 3 měsíců. Tento druh předplatného lze získat při osobní účasti na některé z akcí organizovaných Microsoftem. Při tvorbě této práce byl použit typ předplatného Azure Pass. 36

4.3.3 Hostování aplikace Poté, co je k dispozici portál Azure, přichází na řadu hostování aplikace. Microsoft Azure nabízí mnoho možností jak hostovat aplikace v rámci této platformy. V případě kategorie služeb PaaS, která bude využita při tvorbě této práce, je pro hostování webových aplikací vhodnou volbou použít již zmíněnou službu Azure Web Apps. Abychom ovšem mohli s Web Apps pracovat, je nutné mít nastaveno prostředí pro práci s touto službou. Při vývoji aplikace dochází zpravidla k využití více prostředků, proto je dobré pohlížet na všechny tyto prostředky jako na jednu skupinu a nikoliv jako na samostatné entity. Při práci se službami v Microsoft Azure je nezbytné, aby každý prostředek dané služby spadal do nějaké skupiny prostředků neboli Resource Group. Ta nám poté umožňuje snadnou správu všech využitých prostředků v aplikaci. Resource Group je logický kontejner, ve kterém se nasazují a spravují prostředky Azure, jako například webové aplikace, databáze a účty úložiště. [26] Z důvodu nižší latence je vhodné, aby všechny prostředky, se kterými pracujeme v rámci jedné aplikace, byly součástí stejné Resource Group. Obrázek 8: Vytváření Resource Group Zdroj: https://portal.azure.com (Vlastní zpracování) 37

Při vytváření nové Resource Group je nutné specifikovat údaje jako název Resource Group, druh předplatného a lokaci Resource Group. Název je vhodný vybrat tak, aby symbolizoval daný projekt. V případě této práce byl zvolen název BPResourceGroup (BakalářskáPráceResourceGroup). Jako předplatné byl zvolen již zmíněný Azure Pass. Lokaci je potřeba vybrat, jelikož je nutné specifikovat, kde se budou ukládat metadata o prostředcích. Jako lokace byla vybrána West Europe, tedy nejblíže dostupné data centrum. Po vytvoření lze danou Resource Group spravovat za pomoci portálu Azure. Poté, co disponujeme existující Resource Group, přichází na řadu vytvoření plánu služby, tedy App Service planu. App Service plan určuje umístění, velikost a funkce farmy webových serverů, která hostuje naše aplikace. [26] V rámci App Service planu tedy dochází k hostování App Services, které spolu sdílejí výpočetní prostředky daného App Service planu. Obrázek 9: Vytváření App Service planu Zdroj: https://portal.azure.com (Vlastní zpracování) 38

Při vytváření nového App Service planu je potřeba specifikovat určité údaje. Je nutné vyplnit vhodný název App Service planu, v případě této práce tedy BPAppServicePlan (BakalářskáPráceAppServicePlan). Následně zvolit dostupné předplatné, vytvořit novou či vybrat již existující Resource Group, dále zvolit operační systém a lokaci. Pro co nejlepší latenci je vždy vhodné zvolit stejnou lokaci jak pro Resource Group, tak pro všechny prostředky, které do dané Resource Group spadají, tedy i App Service plan. Posledním důležitým krokem je zvolení cenové úrovně App Service planu, která se primárně odvíjí od účelu a nároků dané aplikace. Microsoft nabízí velmi mnoho kategorií těchto cenových úrovní. Jednotlivé cenové úrovně se liší především svou cenou a také úrovní poskytovaných služeb. Patří sem možnost škálování výpočetních prostředků, využití určitého počtu instancí virtuálních strojů nebo možný počet hostovaných aplikací, kde je výsledná cena účtována za App Service plan nikoliv za jednotlivé App Services. Po vytvoření lze dle potřeb daný App Service plan spravovat pomocí portálu Azure. Pro účely této aplikace byla zvolena cenová úroveň B1 Basic, která je poskytována za poplatek 0,064$ za den. V rámci této úrovně lze využít až tří instancí virtuálního stroje, lepších než základních výpočetních prostředků a v App Service planu je umožněno hostovat libovolné množství App Services. Tato cenová úroveň je primárně určena pro vývoj a testování aplikací. Pokud bychom vyvíjeli aplikaci pro produkční účely, tak by bylo vhodné zvolit některou z vyšších cenových úrovní App Service planu, která poskytuje mnohonásobně bohatší služby. Nyní, když máme k dispozici Resource Group a v ní umístěný App Service plan, můžeme přistoupit k tvorbě samotné App Service, která bude umístěna v daném App Service plánu. V tomto případě půjde o vytvoření jednoho z již zmíněných typů služby Azure App Services, a to Azure Web App. 39

Obrázek 10: Vytváření Web App Zdroj: https://portal.azure.com (Vlastní zpracování) Při vytváření Web App je opět nutné zadat požadované údaje. Nejprve je potřeba zvolit vhodný název hostované aplikace, která bude poté dostupná na doméně <názevaplikace>.azurewebsites.net. V tomto případě bude tedy URL této aplikace https://bpadministrationsystem.azurewebsites.net.pokud bychom měli zájem o vlastní doménu, tak je možné její nastavení ve správě Web App, a to za předpokladu, že disponujeme placenou cenovou úrovní App Service planu. Dále je nutné zvolit dostupné předplatné, vytvořit novou nebo vybrat již existující Resource Group, zvolit jeden z dostupných operačních systémů a specifikovat App Service plan. Velmi zajímavou službou, která úzce souvisí s App Services je Azure Application Insights, díky které lze analyzovat a monitorovat danou aplikaci v reálném čase. Opět zde platí, že pro co nejlepší latenci je vždy vhodné zvolit stejnou lokaci jak pro Resource Group, tak pro všechny prostředky, které jsou součástí dané Resource Group. Vytvořenou Web App je poté možné spravovat za pomoci portálu Azure. 40

V případě, že naše aplikace využívá WebJoby, které jsou nakonfigurovány, aby byly spuštěny nepřetržitě, tak je doporučeno, abychom ve správě Web App zvolili možnost stálého připojení. Toto nastavení zajistí, že daná Web App bude dostupná nepřetržitě, což umožňuje spolehlivé spuštění tohoto typu WebJobů. Nastavení stálého připojení je možné jen v případě cenových úrovní B1 Basic a vyšších. 4.3.4 Nasazení aplikace Poté, co disponujeme prostorem pro hostování aplikace, přichází na řadu nasazení webové aplikace. Existuje více způsobů jak do Microsoft Azure nasazovat aplikace. Sofistikovaným a velmi populárním způsobem je nasazení s využitím verzování, známého též jako Source Control. V případě dané Web App lze pro potřeby nasazení zvolit některý z nabízených zdrojů. Obrázek 11: Možnosti nasazení aplikace Zdroj: https://portal.azure.com (Vlastní zpracování) 41

První možností je využití cloudové služby Visual Studio Team Services (VSTS), která umožňuje snadnou průběžnou integraci (CI) a průběžné doručení (CD). VSTS je velmi vhodné v případě týmového produkčního vývoje, jelikož značně usnadňuje sestavení, testovaní a nasazení aplikací do cloudu. Dalšími možnostmi pro verzování, které využívají distribuovaný systém správy verzí Git, a které také mimo jiné umožňují průběžné doručení (CD), jsou webové služby GitHub nebo Bitbucket. V případě verzování je také možné využití způsobu, kde jsou zdrojové kódy webové aplikace uloženy v lokálním repozitáři Git a k nasazení do Azure dochází skrze pushování do vzdáleného repozitáře. Naskýtá se i možnost použití cloudových úložišť Dropbox a One Drive, u kterých je ovšem verzování zdrojových kódů vcelku problematické. Eventuální možnou volbou je i využití externího repozitáře. Při tvorbě této práce byl jako možnost pro verzování zvolen Bitbucket. V případě, že při vývoji dochází k využití již zmíněného vývojářského nástroje Visual Studio, tak s jeho pomocí lze značně usnadnit publikaci aplikací do Azure App Services. Za pomoci integrovaného nástroje Team Explorer je možné snadno verzovat a publikovat vyvíjené aplikace přímo z Visual Studia do cloudu. 4.4 Implementace aplikace Nyní, když je připraveno prostředí pro vývoj, tak se již můžeme věnovat samotné implementaci aplikace. Následující kapitoly se budou zabývat nastavením vybraných služeb Microsoft Azure a následnou integrací těchto služeb s webovou aplikací. 4.4.1 Integrace s Azure DocumentDB Pro práci s Azure DocumentDB je nejprve potřeba disponovat účtem Azure Cosmos DB. Při vytváření účtu je nezbytné zadat potřebné údaje. Nejprve je nutné zvolit ID, tedy unikátní jméno, které identifikuje daný účet. Dále je potřeba vybrat jedno z nabízených API, a to buďto SQL, MongoDB, Cassandra, Azure Table nebo Gremlin. V případě DocumentDB se jedná o již zmíněné SQL API. Následně je nutné zvolit dostupné předplatné, vytvořit novou nebo vybrat již existující Resource Group a zvolit lokaci, která, by měla být stejná jako lokace příslušné Resource Group. Dále se nabízí možnost povolení geografické redundance, která má za cíl vytvoření replikované verze databáze v jiné spárované lokaci nebo využití vlastnosti multimaster, díky které lze využít lepších vlastností pro přístup k databázi odkudkoliv na 42

světě. Poslední volbou je využití Virtual network, která nabízí exkluzivní přístup k účtu Azure Cosmos DB ze speciálních virtuálních sítí a podsítí v rámci zvoleného předplatného. Daný vytvořený Azure Cosmos DB účet je poté možné spravovat za pomoci portálu Azure. Obrázek 12: Vytváření Azure Cosmos DB účtu Zdroj: https://portal.azure.com (Vlastní zpracování) 43

Po vytvoření účtu Azure Cosmos DB přichází na řadu vytvoření nové databáze a do ní spadající kolekce. Toto je možné učinit rovnou z kódu nebo v portále Azure s využitím nástroje průzkumník dat, s jehož pomocí lze spravovat data v rámci Azure CosmosDB. Je zde potřeba zadat unikátní ID databáze a nastavit zajištění databázové propustnosti. To umožňuje nastavit množství takzvaných RU/s, neboli počtu žádostí za vteřinu, kde platí, že čím větší propustnost, tím větší náklady a tím menší latence. Dále je potřeba zvolit unikátní název kolekce, kapacitu úložiště a propustnost, kde minimální hodnotu propustnosti lze nastavit na 400 RU/s. Poslední volbou je nastavení jedinečného klíče, který umožňuje přidat vrstvu integrity dat do databáze. V případě Azure Cosmos DB jsou náklady účtovány na základě zvolené propustnosti a kapacity úložiště. Při nejnižším možném nastavení, tedy fixní kapacitě úložiště 10 GB a propustnosti 400 RU/s, se měsíční náklady pohybují okolo 24$. Obrázek 13: Přidání kolekce v Azure Cosmos DB Zdroj: https://portal.azure.com (Vlastní zpracování) 44

Při vývoji aplikací, které využívají službu Azure Cosmos DB, nabízí Microsoft možnost použití Azure Cosmos DB emulátoru. Tento emulátor slouží především k účelům lokálního vývoje a testování aplikací a lze s jeho pomocí vyvíjet bez jakýchkoliv nákladů. Po dokončení vývoje v emulátoru, lze danou aplikaci snadno nasadit do Microsoft Azure, kde už ovšem dochází k účtování poplatků za využívané služby. Při implementaci webové aplikace, která využívá službu DocumentDB, je nejprve potřeba do daného projektu nainstalovat NuGet balíček Microsoft.Azure.DocumentDB.Core. Aby webová aplikace věděla, ke které databázi se má připojit, a aby bylo zajištěno důvěrné spojení mezi webovou aplikací a službou Azure Cosmos DB, tak je potřeba disponovat hodnotami identifikátoru URI a primárního klíče. Tyto hodnoty jsou dostupné na portále Azure v daném účtu Azure Cosmos DB pod záložkou Klíče. Je vhodné uvést, že při práci s DocumentDB dochází k serializaci a deserializaci entit, které jsou podle potřeby serializovány do podoby JSON dokumentů či posléze deserializovány do podoby C# objektů. Jak již bylo zmíněno, tak služba Azure DocumentDB byla zvolena jako úložiště pro vytvořené zaměstnance, Meeting Centra a Meeting Roomy, kde jednotlivé entity odpovídají jednotlivým dokumentům. Vytvořené rozhraní IDocumentDbRepository definuje základní metody pro práci s dokumenty dané kolekce. Obrázek 14: DocumentDB - Rozhraní pro práci s dokumenty kolekcí Zdroj: Zdrojový kód aplikace IDocumentDbRepository.cs (vlastní zpracování) 45

Rozhraní IDocumentDbRepository dále implementují jednotlivé repozitářové třídy, ve kterých dochází k práci s dokumenty již specifikované modelové třídy. Pro následující popis implementace platí, že je obdobný pro všechny repozitářové třídy v rámci dané služby. V případě zaměstnanců je repozitářovou třídou implementující rozhraní IDocumentDbRepository třída EmployeeRepository. Tato třída nejprve inicializuje důležité proměnné, které jsou nezbytné pro práci s dokumenty a které jsou definované v konfiguračním souboru appsettings.json. Obrázek 15: DocumentDB - Nezbytné proměnné pro práci se službou v aplikaci Zdroj: Zdrojový kód aplikace EmployeeRepository.cs (vlastní zpracování) Je tedy nutné disponovat jednak již zmíněnými hodnotami identifikátoru URI a primárního klíče (AuthKey), ale také názvem databáze a kolekce, která obsahuje dané dokumenty. Pomocí instance třídy DocumentClient dochází v aplikaci k přístupu ke službě DocumentDB, k vytvoření databáze, kolekce a dokumentu a také k manipulaci s kolekcemi a dokumenty. Abychom mohli v aplikaci manipulovat s dokumenty, tak je nejprve nezbytné vytvořit danou databázi a kolekci. Můžeme tak učinit již zmíněným způsobem skrze portál Azure, nebo rovnou ze zdrojového kódu aplikace při inicializaci aplikace. V tomto případě dochází nejprve k ověření, jestli daná databáze či kolekce existují a pokud neexistují, tak dochází k jejich vytvoření a příslušnému nastavení. 46

Obrázek 16: DocumentDB - Vytvoření databáze a kolekce v aplikaci Zdroj: Zdrojový kód aplikace DocumentDbInitializer.cs (vlastní zpracování) Poté, co disponujeme vytvořenou databází a v ní umístěnou kolekcí, a také máme k dispozici proměnné pro práci s DocumentDB, tak je možné implementovat jednotlivé metody dané repozitářové třídy. V metodě GetItemsAsync dochází k získání všech dokumentů dané kolekce. Pokud by kolekce obsahovala dokumenty rozdílného typu, tak je vhodné v modelové třídě nastavit příznak (DocType), díky kterému je následně možné získat pouze dokumenty odpovídající požadovanému typu. Jak již bylo uvedeno, tak JSON dokumenty je možné dotazovat jak pomocí jazyka SQL, tak v případě.net za pomoci LINQ. Dále v metodě GetItemAsync dochází k získání konkrétního dokumentu dané kolekce, který odpovídá požadovanému identifikátoru. 47

Obrázek 17: DocumentDB - Metody pro získání dokumentů Zdroj: Zdrojový kód aplikace EmployeeRepository.cs (vlastní zpracování) Dále následují metody pro vytvoření, aktualizování a smazání požadovaného dokumentu dané kolekce. Metoda AddDocumentAsync umožňuje vytvoření nového dokumentu. V případě metody UpdateDocumentAsync dochází k nahrazení stávajícího dokumentu, který odpovídá danému identifikátoru, dokumentem novým a metoda DeleteDocumentAsync slouží ke smazání daného dokumentu na základě poskytnutého identifikátoru. K využití výše popsaných metod dochází v controlleru aplikace, který reaguje na jednotlivé HTTP požadavky. Abychom tyto metody mohli v controlleru používat, je nejprve nezbytné daný repozitář (EmployeeRepository) zaregistrovat v Dependency Injection Containeru. Poté nám budou dané metody k dispozici skrze parametr konstruktoru, který je typu daného rozhraní (IDocumentDbRepository). 48

Obrázek 18: DocumentDB - Metody pro vytvoření, aktualizování a smazání dokumentů Zdroj: Zdrojový kód aplikace EmployeeRepository.cs (vlastní zpracování) 4.4.2 Integrace s Azure Table Storage Za předpokladu, že se chystáme využívat některou ze služeb Azure Storage, tak je nejprve nutné disponovat účtem úložiště Azure Storage. Při vytváření účtu je nezbytné zadat potřebné údaje. Nejdříve je nutné zvolit unikátní název účtu, který daný účet identifikuje. Dále je potřeba zvolit model nasazení, kde Microsoft pro nové účty doporučuje možnost ResourceManager. Následuje volba jednoho, z již zmíněných typů účtů, kde bylo pro potřeby této práce zvoleno úložiště úrovně Standard. Dále je nutné zvolit dostupné předplatné, vytvořit novou nebo vybrat již existující Resource Group a zvolit lokaci, u které opět platí že, by měla být stejná, jako lokace příslušné Resource Group. Poté je potřeba vybrat jednu z dostupných možností replikace dat, která poskytuje vysokou dostupnost a odolnost pro naše data. Následně je možné zvolit, zdali vyžadujeme výhradně zabezpečený přenos dat. Poslední volbou je využití Virtual network, která nabízí exkluzivní přístup k účtu Azure Storage ze speciálních virtuálních sítí a podsítí v rámci zvoleného předplatného. Daný vytvořený účet Azure Storage je vzápětí možné spravovat za pomoci portálu Azure. 49

Obrázek 19: Vytváření Azure Storage účtu Zdroj: https://portal.azure.com (Vlastní zpracování) 50

Při práci se službou Azure Storage ve Visual Studiu je vhodné využít možnosti Služby k připojení (Connected Services), která do projektu dané aplikace automaticky přidá závislosti, které jsou nutné pro připojení a využívání účtu úložiště Azure Storage. Dochází tedy jednak k přidání NuGet balíčku WindowsAzure.Storage a jednak k přidání připojovacího řetězce (Connection stringu), který obsahuje informace nutné pro připojení k úložišti. Připojovací řetězec je poté umístěn v konfiguračním souboru appsettings.json. Dobrou volbou je využití nástroje CloudExplorer, který slouží pro správu prostředků v rámci daného účtu Azure. V případě Azure Storage umožňuje jednak zobrazit vytvořené Bloby, Queues a Tables v rámci daného účtu, ale i následnou manipulaci s jejich daty. Veškerá data uložená v Azure Storage jsou součástí specifických oddílů, které náleží danému serveru. Jeden server tedy obsahuje jeden nebo více oddílů. V případě velkého zatížení daného serveru, může v rámci vyvažování zátěže docházet k přesunutí oddílu na jiný méně zatížený server. Na rozdíl od Blob Storage a Queue Storage jsme v případě Table Storage sami odpovědni za to, jak budou příslušné oddíly sdružovat naše data. Z tohoto důvodu je velmi důležité vhodně zvolit již zmíněné hodnoty vlastností klíče oddílu (PartitionKey) a klíče řádku (RowKey) dané entity. Výběr hodnot klíčů zásadním způsobem ovlivňuje výkon dané aplikace a není proto doporučeno volit tyto hodnoty jako náhodné. Vhodné nastavení obou hodnot klíčů má za důsledek zrychlení dotazování, jelikož podle hodnoty klíče oddílu bude Table Storage okamžitě vědět jaký oddíl má dotazovat a pomocí hodnoty klíče řádku bude moci jednoznačně identifikovat danou entitu v rámci daného oddílu. V případě této práce obsahuje Table Storage jednu tabulku pro všechna uživatelská nastavení zaměstnanců. Tato tabulka obsahuje entity, které odpovídají jednak nastavení profilu daného zaměstnance a také nastavení aplikace daného zaměstnance. Pro entity nastavení profilu (ProfileSettings) byl jako hodnota PartitionKey zvolen identifikátor zaměstnance, tedy jeho příjmení a jako hodnota RowKey byla vybrána statická hodnota identifikátoru nastavení profilu. V případě entit nastavení aplikace (ApplicationSettings) byl jako hodnota PartitionKey opět zvolen identifikátor zaměstnance, tedy jeho příjmení a jako hodnota vlastnosti RowKey byla zvolena statická hodnota identifikátoru nastavení aplikace. Tato volba tedy sdružuje jednotlivé kategorie nastavení náležící daným zaměstnanců do stejných oddílů. 51

Při implementaci aplikace dochází k vytvoření rozhraní ITableStorageRepository, které definuje základní metody pro práci s entitami. Obrázek 20: Table Storage - Rozhraní pro práci s entitami Zdroj: Zdrojový kód aplikace ITableStorageRepository.cs (vlastní zpracování) Rozhraní ITableStorageRepository dále implementují jednotlivé repozitářové třídy, ve kterých dochází k práci s entitami již specifikované modelové třídy. Pro následující popis implementace platí, že je obdobný pro všechny repozitářové třídy v rámci dané služby. V případě nastavení profilu zaměstnance je repozitářovou třídou, která implementuje rozhraní ITableStorageRepository třída ProfileSettingsRepository. V této třídě dochází nejprve k inicializaci důležitých proměnných, jenž jsou nezbytné pro práci se službou Azure Table Storage v aplikaci. Je tedy nutné disponovat již zmíněnou hodnotou připojovacího řetězce, díky které lze přistoupit k příslušnému účtu Azure Storage. Poté, co disponujeme přístupem k danému účtu, lze skrze objekt CloudTableClient přistupovat k úložišti Table Storage, které je součástí daného účtu Azure Storage. Dále dochází k získání reference na specifickou tabulku, nad kterou je poté možné provádět potřebné operace. Obrázek 21: Table Storage Nezbytné proměnné pro práci se službou v aplikaci Zdroj: Zdrojový kód aplikace ProfileSettingsRepository.cs (vlastní zpracování) 52

Abychom mohli v aplikaci manipulovat s entitami, tak je nejprve nezbytné vytvořit tabulku, která bude poté dané entity obsahovat. Lze tak učinit skrze portál Azure, nebo rovnou ze zdrojového kódu aplikace při inicializaci aplikace. V tomto případě dochází k ověření, jestli daná tabulka již v rámci daného účtu existuje a pokud neexistuje, tak dochází k jejímu vytvoření. Obrázek 22: Table Storage - Vytvoření tabulky Zdroj: Zdrojový kód aplikace TableStorageInitializer.cs (vlastní zpracování) Poté, co disponujeme vytvořenou tabulkou a máme k dispozici proměnné pro práci s Table Storage, tak je možné implementovat jednotlivé metody dané repozitářové třídy. V metodě GetEntitiesAsync dochází k získání všech entit odpovídajících danému RowKey, tedy v tomto případě všech profilových nastavení všech uživatelů. Takto se sice uskuteční prohledání všech oddílů, ovšem také následná jednoznačná identifikace požadovaného nastavení v rámci oddílu. Pokud bychom chtěli získat všechny kategorie nastavení daného uživatele, tak bychom byli schopni velmi rychle vyhledat požadované entity podle PartitionKey, jelikož všechna nastavení odpovídající danému uživateli náleží do stejného oddílu. Dále v metodě GetEntityAsync dochází k získání konkrétní entity, která odpovídá požadovanému PartitionKey a RowKey. Vzhledem ke specifikaci hodnot obou klíčů je identifikace požadované entity velmi rychlá. 53

Obrázek 23: Table Storage Metody pro získání entit Zdroj: Zdrojový kód aplikace ProfileSettingsRepository.cs (vlastní zpracování) Dále následují metody pro vytvoření, aktualizování a smazání entity. Metoda InsertEntityAsync umožňuje vytvoření nové entity se základními hodnotami jejích vlastností. Při vytváření je nutné specifikovat hodnoty obou klíčů. PartitionKey specifikuje, jakému oddílu entita náleží a RowKey identifikuje entitu v rámci oddílu. Dochází tedy k vytvoření specifické kategorie nastavení daného uživatele, kde je uživatel definován hodnotou PartitionKey a druh nastavení hodnotou RowKey, která v tomto případě odpovídá profilovému nastavení. V případě metody UpdateEntityAsync dochází k nahrazení stávající entity, entitou novou a metoda DeleteEntityAsync nejprve získá požadovanou entitu na základě hodnot PartitionKey a RowKey a poté dochází k jejímu smazání. 54

K využití výše popsaných metod poté opět dochází v controlleru aplikace, který reaguje na jednotlivé HTTP požadavky. Abychom tyto metody mohli v controlleru používat, je nejprve nezbytné daný repozitář (ProfileSettingsRepository) zaregistrovat v Dependency Injection Containeru. Poté nám budou dané metody k dispozici skrze parametr konstruktoru, který je typu daného rozhraní (ITableStorageRepository). Obrázek 24 Table Storage Metody pro vytvoření, aktualizování a smazání entit Zdroj: Zdrojový kód aplikace ProfileSettingsRepository.cs (vlastní zpracování) 4.4.3 Integrace s Azure Blob Storage Služba Azure Blob Storage byla zvolena jako úložiště pro vytvořené obrázky zaměstnanců a videa. Daný obrázek a dané video odpovídají jednomu objektu Blob. Tyto objekty Blob jsou organizovány do dvou Containerů, kde jeden sdružuje veškeré fotografie zaměstnanců a druhý veškerá videa. V aplikaci dochází k využití určitého typu objektů Blob, a to Block blobs. Jak již bylo uvedeno, tak Block blobs jsou vhodné pro uchovávání mediálních souborů nebo obrázků a k jejich uložení lze využít účet úložiště Azure Storage, které je typu Standard. 55

Jelikož již máme vytvořen a nastaven účet úložiště Azure Storage, tak se lze rovnou pustit do integrace služby Azure Blob Storage s aplikací. V případě práce s obrázky dochází v aplikaci k vytvoření rozhraní IBlobStorageRepository, které definuje základní metody pro práci s bloby. V případě práce s videi v aplikaci, je následně popsaný postup obdobný. Obrázek 25: Blob Storage Rozhraní pro práci s bloby Zdroj: Zdrojový kód aplikace IBlobStorageRepository.cs (vlastní zpracování) Uvedené rozhraní IBlobStorageRepository implementuje repozitářová třída PhotoStorageRepository. V této třídě dochází nejprve k inicializaci důležitých proměnných, které jsou nezbytné pro práci se službou Azure Blob Storage v aplikaci. Je tedy nutné disponovat hodnotou připojovacího řetězce, díky které lze přistoupit k příslušnému účtu Azure Storage. Poté, co disponujeme přístupem k danému účtu, tak lze skrze objekt CloudBlobClient přistupovat k úložišti Blob Storage, které je součástí daného účtu Azure Storage. Dále dochází k získání reference na specifický Container, nad kterým je poté možné provádět potřebné operace. Obrázek 26: Blob Storage Nezbytné proměnné pro práci se službou v aplikaci Zdroj: Zdrojový kód aplikace PhotoStorageRepository.cs (vlastní zpracování) 56

Abychom mohli v aplikaci manipulovat s bloby, tak je nejprve nezbytné vytvořit Containery, které v sobě dané bloby sdružují. Lze tak učinit jednak skrze portál Azure, nebo rovnou ze zdrojového kódu aplikace při inicializaci aplikace. Abychom mohli veřejně přistupovat k blobům, jenž náleží danému Containeru, tak je nutné nastavit přístup ke Containeru jako veřejný. Dále dochází k ověření, jestli daný Container již v rámci daného účtu existuje a pokud neexistuje, tak dochází k jeho vytvoření. Obrázek 27: Blob Storage Vytvoření Containeru Zdroj: Zdrojový kód aplikace BlobStorageInitializer.cs (vlastní zpracování) Poté, co disponujeme vytvořeným Containerem a máme k dispozici proměnné pro práci s Blob Storage, tak je možné implementovat jednotlivé metody repozitářové třídy PhotoStorageRepository. V metodě GetAllBlobsAsync dochází k získání všech blobů, jenž náleží do specifického Containeru. Dále v metodě GetBlob dochází k získání konkrétního blobu, který odpovídá požadovanému názvu. Následují metody pro nahrání a stažení blobu, ve kterých dochází k práci se soubory a streamy. Metoda UploadBlobAsync slouží pro nahrání specifického souboru na základě výběru uživatele, a ten je následně uložen do Blob Storage. V tomto případě by daným souborem měl být obrázek zaměstnance. V metodě DownloadBlobAsync dochází ke stažení konkrétního blobu, který odpovídá požadovanému názvu. Poslední metodou je metoda DeleteBlobAsync, která získá specifický blob na základě jeho názvu, a ten poté smaže. 57

Obrázek 28: Blob Storage Metody pro získání blobů Zdroj: Zdrojový kód aplikace PhotoStorageRepository.cs (vlastní zpracování) Obrázek 29: Blob Storage Metody pro nahrání, stažení a smazání blobu Zdroj: Zdrojový kód aplikace PhotoStorageRepository.cs (vlastní zpracování) 58

Stejně jako v předchozích případech, tak i nyní dochází k využití výše popsaných metod v controlleru aplikace, který reaguje na jednotlivé HTTP požadavky. Abychom tyto metody mohli v controlleru používat, je nejprve nezbytné daný repozitář (PhotoStorageRepository) zaregistrovat v Dependency Injection Containeru. Poté nám budou dané metody k dispozici skrze parametr konstruktoru, který je typu daného rozhraní (IBlobStorageRepository). 4.4.4 Integrace s Azure Queue Storage Služba Azure Queue Storage je v aplikaci použita pro asynchronní zpracování zpráv. Zprávy jsou organizovány do fronty v rámci daného účtu. Pokud v aplikaci dojde k uložení obrázku do Blob Storage, tak je vytvořena zpráva obsahující příslušné informace o obrázku, a ta je zařazena do fronty. Jelikož již disponujeme vytvořeným a nastaveným účtem úložiště Azure Storage, tak se lze rovnou pustit do integrace služby Azure Queue Storage s aplikací. Nejprve dochází k vytvoření rozhraní IQueueStorageRepository, které definuje základní metody pro práci s frontami v aplikaci. Obrázek 30: Queue Storage Rozhraní pro práci s frontami Zdroj: Zdrojový kód aplikace IQueueStorageRepository.cs (vlastní zpracování) Uvedené rozhraní IQueueStorageRepository dále implementuje repozitářová třída QueueStorageRepository. V této třídě nejprve dochází k inicializaci důležitých proměnných, které jsou nezbytné pro práci se službou Azure Queue Storage v aplikaci. Pro přístup k příslušnému účtu Azure Storage, je opět nutné disponovat hodnotou připojovacího řetězce, a poté lze skrze objekt CloudQueueClient přistupovat k úložišti Queue Storage, které je součástí daného účtu Azure Storage. Dále dochází k získání reference na specifickou frontu, nad kterou je poté možné provádět potřebné operace. 59

Obrázek 31:Queue Storage - Nezbytné proměnné pro práci se službou v aplikaci Zdroj: Zdrojový kód aplikace QueueStorageRepository.cs (vlastní zpracování) Abychom mohli v aplikaci manipulovat se zprávami, tak je nejprve nezbytné vytvořit frontu, která bude dané zprávy obsahovat. Lze tak učinit jednak skrze portál Azure, nebo rovnou ze zdrojového kódu aplikace při inicializaci aplikace. Dochází tedy k ověření, jestli daná fronta již v rámci daného účtu existuje a pokud neexistuje, tak dochází k jejímu vytvoření. Obrázek 32: Queue Storage - Vytvoření fronty Zdroj: Zdrojový kód aplikace QueueStorageInitializer.cs (vlastní zpracování) Poté, co disponujeme vytvořenou frontou a máme k dispozici proměnné pro práci s Queue Storage, tak je možné implementovat metodu repozitářové třídy QueueStorageRepository. V metodě AddMessageAsync dochází k přidání nové specifické zprávy do dané fronty. 60

Obrázek 33: Queue Storage Metoda pro přidání zprávy do fronty Zdroj: Zdrojový kód aplikace QueueStorageRepository.cs (vlastní zpracování) K využití výše uvedené metody dochází v controlleru aplikace, který reaguje na jednotlivé HTTP požadavky. Abychom tuto metodu mohli v controlleru používat, je nejprve nezbytné daný repozitář (QueueStorageRepository) zaregistrovat v Dependency Injection Containeru. Poté nám bude dané metoda k dispozici skrze parametr konstruktoru, který je typu daného rozhraní (IQueueStorageRepository). 4.4.5 Integrace s WebJobs WebJoby jsou funkcemi Azure App Service a jedná se o konzolové aplikace, které běží v kontextu dané webové aplikace. WebJob je možné vytvořit jednak za pomocí portálu Azure nebo rovnou z Visual Studia. Ve Visual Studiu je nejprve nutné vytvořit projekt typu Azure WebJobs, který bude součástí solution dané webové aplikace. Pokud v aplikaci dochází k asynchronnímu zpracování úloh na pozadí, které přistupují k datům náležícím službám Azure, tak je pro tento případ vhodné využít framework WebJobs SDK. Tento framework značným způsobem zjednodušuje práci s Azure WebJobs v aplikaci. V této aplikaci souvisí WebJoby s asynchronním zpracováním zpráv z fronty. Fronta je v aplikaci sledována WebJoby. Pokud se ve frontě objeví nová zpráva, která obsahuje příslušné informace o vytvořeném obrázku, tak dochází k jejímu zpracování WebJobem. Po úspěšném dokončení zpracování je nová verze obrázku uložena do Blob Storage a daná zpráva je z fronty automaticky smazána. Zpracování obrázků má za cíl každý obrázek, který je vložený do Blob Storage zkomprimovat do příslušného rozlišení. K tomuto zpracování obrázků dochází v aplikaci asynchronně, což má za důsledek, že nedochází k prodlevám při používaní aplikace. 61

Obrázek 34: WebJobs Asynchronní zpracování zprávy z fronty Zdroj: Zdrojový kód aplikace Function.cs (vlastní zpracování) Obrázek 35: Proces zpracování obrázku Zdroj: Vlastní zpracování Ještě předtím, než dojde k nasazení WebJobu do Azure, tak je pro připojení ke službě Azure Storage potřeba specifikovat hodnoty připojovacích řetězců, které obsahují informace nutné pro připojení k úložišti Azure Storage. Ke specifikaci těchto hodnot dochází v souboru App.config. 62

WebJob lze nasadit do Azure přímo z Visual Studia. Stačí v rámci daného projektu vybrat možnost publikovat jako Azure WebJob. Následně je nutné zvolit název WebJobu a druh konfigurace. V případě této aplikace je WebJob nakonfigurován aby běžel nepřetržitě. Obrázek 36: WebJobs Vytváření WebJobu Zdroj: Microsoft Visual Studio (vlastní zpracování) Dále je potřeba zvolit cíl pro publikaci, tedy již existující Web App, které bude následně daný WebJob součástí. Nyní zbývá publikovat aplikaci do Azure. Všechny vytvořené WebJoby je možné spravovat a monitorovat za pomoci portálu Azure. Obrázek 37: WebJobs Publikace WebJobu Zdroj: Microsoft Visual Studio (vlastní zpracování) 63