 Krásné dopoledne, pořád ještě. Vůvodně jsem myslel, že jsem to poslední co vás dělí o tobě, ale naštěstí nejsem, takže snad budeme mít ještě energií všichni. Já jsem Martin Čimeček a dneska vám ukážu, jak jsem nasazoval WordPress do cloudu, konkrétně do toho našego cloudu, protože jsem z Microsoftu, takže do Microsoft Azure, co jsem se přitom naučil a jaký typy a triky bych vám třeba chtěl předat, s tím, že jsem si zkusil i trošičku zabrou si do vývoje WordPressu, protože když jsem dostal možnost tohle, co tady ukázat, kluci říkali, hele ty děláš ty cloudy, tak nám podí ukázat, jak se nasazuje WordPress do toho vašeho cloudu. Super, 80 slavídová preská je kožděcky, rozjedeme PowerPoint a pak mě napadlo, vidím ty z 10 pohledy tady, pak mě napadlo a nebo ne, tak já se zeptám, jak to vlastně dělají, co to znamená a zkusím si to taky. Tak jsem si to zkusil a teď vám ukážu, na co jsem přišel. V Microsoft opraciu pět let, v březnu to bude pět let, nastoupil jsem jako konzultant, pak jsem se stal technickým evangelistou, nikdo nevěděl, co to znamená, takže teď už se to naš čestí menuje software engineer a spolu s tím je tam vidět i ten přechod mezi PowerPointem u technického evangelisty a skutečním kodem u softwareové engineera, takže moje práce teď spočívá v tom, že sedím s partnerami a s zákazníkami a programujeme společně na jejich projektech a dodáváme do nich naše pokročilejší technologie, primár několém cloudu, protože Azure je prostě to, co je dneska Microsoft. Potom to dávám na GitHub a tak dál. Kdybyste mě podnešku ještě neměli dost, tak u mě na webu najdete rozsesníček na všechny možné sociálí sítě, GitHuby a podcast a další věci. Inak na konci prezentaci bude odkaz, kde si tuhle celou prezentaci včetně dimíček můžete stáhnout, prohlídnout. No a co WordPress? Já jsem samozřejmě používal WordPress, používám ho do dnes. Samozřejmě asi jako spoustat z vás, tady jsem si napsal v PHP svůj vlastní framework, pak jsem zistil, že to není úplně dobrý, že to moje CMS komoc dobře neškáluje, tak jsem přišel na WordPress a když jsem se připravoval, tak jsem zistil, že můj blog na WordPressu běží od roku 2010, což jdeme na 8 let, což jsem ani nečekal. A pro zajímavou z první článek je o tom, jaké mám zkušenosti s Windows Mobile 6.5. Možná si zpomeňat, že existoval takovýhle operační systém na mobili, existovali mobili, kterého v sobě měli. Ani pro Microsoft není WordPress nic nového, naše technické blogy od roku 2015 běží taky na WordPressu. Takže když budete třeba na blogs, MSDN, Microsoftcom nebo technet Microsoftcom, tak už to běží na WordPressu, se vši všude s administrací, s pluginami a tak dál. Nebylo to úplně jednoduché, těch blogů tam jsou desítky až stovky tisíc a všechny zdílí nějakou jednu infrastrukturu, trval plů roku, nejse podařilo to všechno vzprovoznit a nakonfigurovat a otestovat, ale dneska už je to spolehlivé a fungujeme na tom. O tomhle mluvit nebudu. Kdy jsem se připravoval a díval jsem se na to, jaké jsou možnosti nasadit WordPress do Azure, tak mě napadlo, že ta přednáška by se spíš mohla měnovat, nasozujeme WordPress tisíc krát jinak. To mi takové neprošlo, takže se podíváme jenom na jednu jedinou možnost, ale chci vám zmínit i ty další. Úplně první a nejednušší věc, kterou můžete udělat, která je nezávislá na typu toho cloudu, v podstatě můžete udělat i u sebe na počítači, je rozděci virtuální mašinu, z Windows nebo z Linuxem, tam nahrát všechny soubory, rozděci tam Apache, rozděci tam PHPko, prostě ten typický vamp, nebo lampstek a provozovat to tam. Bude to fungovat? Není to dobrý, proč? Protože to špatně škáluje, špatně se to spravuje. Musíte si tam všechno nastavit, chci tez to udělat GitHub, musíte si o nastavit, chci tez tomu dát SSL certifikát, zase musíte to prostě nakonfigurovat růčně. Jsou služby, které tohle dokážou řešit, v rohem lépa i jednoduši, protože prostě na to byly připravené. A jednou z nich je trá web apps. Máme 3 varianty už dneska, pro Windows, nad Windows, nad Linuxem a nad Docker Containerem, což je v posledě taky nad Linuxem. A já budu mluvit o té Windowsí variantě, přestože vím, že nikou není ideální nasozovat PHPko a WordPress na Windows, tak vám ukážu, že to d, že se to dá používat, ale samozřejmě, kdybyste chtěli Linux, to není problém. A další možnost je vytvořit si Docker Container a ten nasadit a hostovat zase jako menečovanou službu, kdybyste si přijali k tomu i Kubernetes, aniž by se to museli installovat, taky to d. No a pak tam jsou k tomu databáze, taky jako služba, to znamená MySQL, Maria se připravuje na uželotelský datablop storage CD-nka, ale o tom budu ještě mluvit. Dneska bych to rozdělal na dvě části, je ta vývojová a pak ta provozní, to znamená, jak jsem si zkusil třeba dělat vývoj nad WordPressem a s Azurem a jak potom byste mohli optimalizovat provoz toho webu, aby je fungoval hezky v tom cloudu, protože přeci jdou je to trošku jiný, než na vašem servříku ve sklepě, nebo na běžným web hostingu. Takže vývoj, jsem se zeptal kluku, co to znamená vlastně vyvíjet pro WordPress a zjistili jsme, nebo došel jsem k tomu, že to znamená výciméně tvorbu Shablon, tvorbu pluginu, případně editaci toho core WordPressu a nebo nějaké další eksterní upravy nebo nadstavby. Takže jsem se zaměřil tady na to a zkusil jsem si upravit Shablonu. Uplně nejednuší způsob, jak můžete začít s WordPressem, nicméně aniž byste měli cokoliv u sebe na počítači, řekněme, že si chcete jenom prozkoušet nějaké pluginy, prozkoušet nějaké Shablony, je vytvořit si WordPress de Shablony. To znamená, že vytvoříme nový takzvaný resource, vyhledáme WordPress a je tady miliarda variant, všechno jsou to WordPressy v různých konfiguracích nebo v různým způsobu násazení. Já vyberu ten první, protože ten je, ten je na Windows, případně vyšlo i na Linuxu, s ním si zvolit názef, web1,2,3 a můžu si vybrat nejaké databázy, to bobě ježí. A tohle je velice důležité rozhodnutí, hlavně na začátku, protože vy můžete provozovat WordPress majský URL, který je součástí to webhostingu, a nebo jako externí službu databázy. Pro testování a vývoj klidně in-up, ale jak mnoje to běhete chtít nasadit kamkoliv, tak vždycky dedikovanou databázy. No a pak je tady další důležitý rozhodnutí a to je kam vlastně ten svůj servří, ten svůj web nasadim a můžu si vybrat, kdybych chtěl třeba do Australie, můžu, kdybych chtěl do Brazílie, taky tam datacentrum je k dispozici. Nám nejbližší je asi Norf, případně Vesturop, ty odezvy tam jsou srovnatelné a další velice důležité rozhodnutí, kolik výkonu vlastně dostanu a kolik mě to bude stát. Tady je na výběr spousta různých varianty, tady samozřejmě i frí, na to proklikávání plug-inu nebo na nějaký hraní z WordPressem idealní, protože nepotřebujete nic dalšího. Jak mnoje bude tě chtít třeba vlastní doménu nebo vlastně SSL certifikát, případně škálovat, tak už se bude tě muset poohlenout po něčem vyším, pak ten standard se tak jako hodí na běžný provoz. Ty ceny berty jako orientační, protože tohle je typ účtu, který má nějakým způsobem nastavený ceny, ale můžete vidět trošku jinak. A tady jsou vidět ty funkcionality, které k tomu dostáváte. Já klidně zvolim fríčko, OK, a poslední krok je nastavit parametri database, takže tady bysme vybrali user Password klasiku, verzi 5756, MySQL a název, takže tady by to bylo něco jako WordPress. Já to nebudu dokońčovat, protože tvorbatí na tabáze chvílku trvá, ten web jako takový hrychlé, ale ta na tabáze trvá. A už jsem si to vytvořil předem, takže tady mám rozjetý WordPressový web, má svoji jako adresu, proč to trvá tak dlouho? Typnete si někdo? Proč ten první request trval tak dlouho? Protože to běží na Windows, na IES, a IES-ko má s kylou vlastnost, že když tam nechodí dlouho nějak requesty, tak prostě uspí aplikační půl, to znamenáž den první request chvíli trvá. Dá se tomu předejít, ukážu vám jak. Takže tohle nějakej WordPress web, můžu si s ním dělat, co chci, instalovat tam plug-iny, aktualizovat ho, prostě klasika, nic úplně speciálního. Abyste viděli, že to není černá skřínka, že to někdo prostě dal do nějaké galéry, a teď mi to tam následila, já ti nemám kontrolu, tak vám ukážu repozitás, který ho to pochází. Na GitHubu je repo, já si zapnul lupu, kde jsou různí šablony pro Azure, takže tady je připraviná speciální instalace WordPressu, musí být speciální proto, že trošku mění vapconfig, aby si správně načítal parametry databáze. Z nějakého důvodu WordPress fungoje tak v tom základu, že musíte do vapconfigu natvrdo napsat ty údaje, takže tady to upravili, tak aby si je to načetl přímo z nastavení prostředí, což znamená, že já si se podívám tady do application settings, tak tady v sechci connection strings už mám automaticky connection string na mojí MySQL databázy, tady schovaný, je to MySQL. Tím pádem, se nemusel to install při tom první installat, si to nemusel nastavovat, takže to je nejednodušší způsob, jak si rozjít WordPress. Takže další krok, mám nějakou instalaci lokalně, na té si pracují, vytvořím si tam ty svoje shablony, ty plug-in a tak dál a pak jichci dostat do cloud, abychí třeba někomu ukázal, to je vlastně dva proky. No a protože já jsem opatrné na svůj počítač a nechce, aby tam byli věci, který třeba nepoůžívám, nebo tam jsou zbytečný, tak jsem si nechtěl instalovat takový ten klasický vampstek takový ten většině napadlo, co? Samozřejmě do cr, že jo, to dneska hrozně frčí, všechno je v kontaineru. Tak zadám do docru, do cr for windows existuje, no jo anči, to si budou muset nainstallovat do cr for windows, to taky nechci. Tak se budou zjel virtual fresheru, Windows Server 2016, který podporuje, tak zvonou nestit virtualizaci, což znamená, když jí mi tam do cr a začalo experimentování s různými imidžem. Co použít, když si vygooglíte, že chcete WordPress do cr for development, tak na vás vypadne spousta článku, spousta různých imidžů, já jsem ich pár vyzkoušel, nakonec mě přišel nejlepší, asi tenhle, ve spojitosti s klasickým MySQL, protože už je tam předinstallovaný xdebug, takže když si správně nakonfigurujete podstikrokovat ten svůj plug-in, ale on poběží v dokrů. Nakonec s vám ukážu, učel jsem skončil, tohle je dokr-compouse, pokud neznátej dokr, tohle je prostě předpis jaký součástí bude celá aplikace mít a v jakým pořadí se nasadí, zásadí. Takže mám tady databázy, která vychází s imidžem klasickým MySQL, a mám tady WordPress, který je na té databázy a je to WordPress Latest. Nakonec jsem se vykašel na xdebug, protože se mi nepodářil ho rozjet v toho vyžilostudiokout. Očvědně tam je nějakej konflikt, takže nakonec jsem zůstal u toho WordPress Latest. Případně je docela zajímavý i mič je tenhle, ačkoliv má v názvu napsáno vpcli, tak právě neobsahuje vpcli. Když ho z nějakého dovodu nebude chtít a je trošku menší, takže tady si stáhnu WordPress Image na portech port 80 pošlu na 8999 a mám tady svojí složku html navázanou na složku html v tom imidži. Když se podíváme na containery už běží oba a mám tady taky svojí vývojářskou stránku. A pak jsem všel a začel jsem editovat, takže tady je to složka html mám tady nějaké šablony tak řekněme, že bych si chtěl upravit převzít divinout svojí vlastní šablonu takže tady udělám nějakou super upravu typu čauky a hned tí vidím. Je tam takový den klasický jenom říkaj inr loup to znamená něco vyskouším, uložím, šub a vidím hned výsledek z tím x-debugem by to bylo ještě trochu lepší, protože bych si to mohli krokovat. Takže tady jsem pro vedsměnu projevila se mi v kontaineru řekněme, že vývoj pokračuje takže dělám vývojářské věci vývím, vývím, vývím je nás na tom třeba několik tak všichni vývíme, bly a teď nastává čas, kdych chceme to ukázat třeba klientovy pracovat jsme na tom 14. měsíc, 2 měsíce a teď si řekáme, tak teď jim to předvede my si se jim to bude líbit, případně ať nám dají připomínky. Oni se na můj localhost nepřípují na můj doker kontainer potřebuji ho dát někam ven První co se nabízí a co je z celé validní možnost je udělat z toho doker image ten publikovat do privátního repozitáře který je teda kif-eżru a z něj pak vyprovižnuva ten doker image šlo by to, je to zbytečně složitý a trvá to dlouho když tady udělám změnu tak než se mi zbylduje ten image a než si nasedí, tak to prostě trvá druhá varianta dá to do gitu protože ta websitea v eżru může složit jako gitrepo takže já můžu rovnou pušovat přes git znamená, že já už tady mám vytvořený gitrepozitář jenom jsem provety do změnu takže jí tam zase přidám čauky teď si budou museli vytvořit sejtu, do který nasadím v eżru takže použiju tento krát prázdnou nikoli ze šablony ten postup je úplně stejný takže VPDF ten názef, ten bude tvořit do ménu tady je důležitý, že to vkládám na stejný app service plan to, že jsem si tam předtím vytvořil server za nějakých 20 eur, 25 eur neznamená, že na ním smí běžet jenom jeden web no ich tam může být do konce nekonečno, ich tam může být takže tam, takže to dávám na stejný plan a bych už je tril tak create tohle bude rychlejší během pár vteřiny bysme měli mít nasazenou novou sajtu a co se fyzicky děje eżro vytváří JSON třetpis který následně nasazuje co můžete udělat vy, je vytvořit si ten třetpis taky, kdy bude všechno chci tuhle databázy, tuhle web app takové konfiguraci můžete mít nasazovat rovnou bez klikáň tak uděláme se, jestli už to tady je už to tady je, Vepudev před desetí lety před osmi lety když jsem nasazoval WordPress tak jsem použil ftpko, samozřejmě kdo ne, ješ jo dneska už jsme trošku dál takže sice tady to ftpko je já používám spíš na to, abych se podíval co vlastně na tom servru mám za soubory takže vlastně přes git takže nastavíme ještě ne, ještě nastavíme co jiného ještě si přidám takzvaný deployment slot můžete ke každé sejti přidat ještě pět slotů a ten slot je v posledě kopie té stránky, které není navázaná ale je nezávislát, to znamená může to být testovací prostředí beta prostředí alfa prostředí prostředí pro VIP a produkce, třeba takže já tam přidám slot, který se bude konec staging naklonuju si konfiguraci ok ono mi to zase vytvoří další sajtu a teprve na ten staging budu nasazovat z gitu za chyli uvidíte pro oč tak deployment options vybereme si zdroji strašně by mě zajímalo jestli někdo někdy nasazoval do gitu přes Dropbox třeba, asi díkdo z vás do před byste se určitě přiznali nebo přez OneDrive nevím, jestli to jako standardní postup že to tam taky dali tuhle možnost ale budiš názvojím loko git tím se mi tady vygeneruje repozitář kdybych to teď naklonoval, tak to bude prázdný protože tam nic není, můžeme se přisvičit že ta stránka je prázdná no, asi to repo, který mám na vývojářské mašně rozšířim takže git, remote ežer git, push set, upstream ežer, master tak, chce to povně hezlo, to obec nevadí já trošku machrujuju s nimi a příkazem ale protože jsem to dělal tisíc krát takže si pamatuju, že tady musí být ten upstream a tak, kdy to vám to samozřejmě řekne takže to nemusí ty věd z hlavy tak máme tam 16 souborů takže to bude chvíli trvat, než se než se nahrou, každopádně teď se děje to že se nahrávají ty soubory do repozitáře v té web appce ten repozitář se zdílí mezi různými instancemi aplikace, to znamená, že když si rozjedete když budeš kálova do šíchřky a rozjedete si 2, 3, 4, 5 instancí tak všechny si vezmout ten zdrojak z toho společného úložitě takže cokoliv tam změníte, kdykoliv uděláte push tak se to projeví na všechny instancích protože to prostě zdílí tak už mi běží deployment command takže se kopíruje 16 souborů, to běh par vteřin už na minutu napravává s mezi tím nějaký dotaz proti mne tak deployment successful takže teď kdybych byl najivní, tak bych si předstvoval, že to tady uvidím naštěstí nejsem najivní, jsem ošlihalý dývojář a tohle běh je překvapí proč to nefunguje tukášte si někdo typnout jo přesně tak i špatně nastavené prostředí te data báze teď je nastavená na doker na nějakou double, která tady neexistuje takže já musím jít do nastavení té stránky a přidat si tam ten connection string na data bázy ten první krok jo mimochodem tady si dá vybrat verze ph neskutejště dobrá funkce kterou což mě překvapilo někteří dnešní hosty, že ještě neumí musíte kulitnou přád na podporu a trvá to 3 dny tak tady prostě chci verzi 7.1 kliknou save počkám 3 vteřiny tak tady dáme w pdb a connection string jsem si uložil sem a je to mysql co teď samozřejmě to stále nejde proč tam nasozujeme defaultní wordpress konfigurák tak číslo 2 upravit konfiguraci a příledně příležitosti si upravíme i deployment script takže vypekontent už nepotřebuju mám tady upravený script pro Azure, kteří čté environment variable a pak mám vlastní deployment script protože vy můžete i tenhle ten proces co se tady děje, si můžete upravit podle to, jak chcete chcete chcete si tam používáte npm code když je to Node.js aplikace můžete si tam spustit co chcete v rámci toho deploymentu takže tady mám nějaký cmd script můžete to být zpavršel, můžete to být bash když je to na Linuxu a ten script jsem nepsal já, protože jsem nemusel že není úplně jednoduchý ale dá se stáhnout přesně pro tu vaší web-upku si ho můžete stáhnout vezmu webconfig přejménu jeho na local vezmu konfig azure a přejménu jeho na webconfig důvody je jednoduché lokalně chci pracovat na doku když to nasadím, tak si aby to automaticky běžel na tý SQL v databázy v azure takže když teď udělám zase puš tak už to samozřejmě bude rychlejší protože se změnilo jenom pár souborů 3 a už mi běží deployment command soubory se překopírovali teď už bych bych byl překopený kdyby to nešlo jej a je tady čauky potíle přípravě už je to jednoduché a celkem rychlejí protože mi stačí tady cokoliv změnit jej nepávatel jste jsi někdo ten git příkaz, jak to udělat na jednou git add a git commit tam na to je nějaký parametr et prosím jo takhle, že by to bylo asi ne tam to byl jeden takový příkaz to je jedno git push tak mi co se děje to je dobrý znamení teď znovu nabíhá ten aplikační půl tak to mi připomíná že tady je možno studiat always on což znamená, že ežero bude neustále udržovat ten aplikační půl nažhavený takže ho nikdy nevychladné a tím pádem to nebude trvat takhle dlouho a vlastně ten první rekvez vždycky proběhne takhle tohle je nějaký divý jo dobrý tak teď je to na tom stagingu a dostane se tam kdokoliv kdo znátu adresu, takže další krok může být, že třeba pro zákazníka udělám to že dám přístupěnom konkrétním lidem, aby se na to stránku mohli podívat aniž bych musel cokoliv upravovat v kodu tak tady stačí přepnout authentication vyberu Azure Active Directory že jakýkoliv Azure účet má pod sebou Active Directory do kterého můžete přidávat jakýkoliv účty takže vy byste třeba pro lidi od zákazníka vytvořili pár účtů tady byste to zaplina on a nikdo kdo se nepřihlásí účtem z vašeho adečka, tak se na to stránku nedostane teď to dělat nebudu tak řeklíme, že jsme to otestovali líbí se to super paráda takže další krok je, přepnout to na produkci protože v produkční stránce tedy nyní nic tam je taková tam modra už pivá, tady to je vidět takže uděláme swap ze stagingu na produkci tady už mi to říká varování i pozor, na produkci ještě ph copy 6 tak budící to změň a nebo to tam prostě zůstane fajně to nevadí a další věc bude tam navíc ještě connection string to je asi jinou databázy pro testování a jinou pro produkci tím pádem byste zaškrtli, že tohle je slot setting takže by se to neprzeneslo mě to nevadí v tohle chvíli takže to tam nechám ale ok teď se nic nekopíruje teď se prostě jenom mění ty DNS záznami a prohazujou se takže my budeme moc vyskoušet, že na produkci je to co jsme chtěli a na stagingu je produkce je to tady i ta kterou jsem chtěl tak, to byl svap tímhle můžeme tu vývojevou část asi ukončit je to jeden ze způsobu je to ten, kde jsem si vyskoušel a přijde mi celkem efektivní samozřejmě tam trošku ještě ten krok navíc v tom doku protože jsem si nechtěl nic instalovat na počítač ale taky to de teď pojď mi na pár typů na ten provoz always onu jsme komentovali nechcete, aby se vám uspal aplikační půl to se týká samozřejmě jen o Windows když to poběžíte na Linuxu tak to je jiná situace MySQL in app je to hrozně lákavý ušetřit z databázy, nemít tobokém dácí to rovno do tý web appky provozovat to tam není to dobrý pro produkci ze dvou důvodů minimálně za prvé výkon tam MySQL databázy zdílí ten server s webovou aplikací, to znamená prostor na disku, ramku, výkon procesoru a když se to vytíží jedno z toho tak to může tu databázy zabít nebo to může zabít tu web appku druhý důvod vůbec to neškáluje jakože vůbec když přidáte druhou instanci tý stejný aplikace webový tak bude mít svojí databázy což je nepoužitelní v praxi protože prostě loadbalancer to hodí na jedno instanci tam budou nějaké data pak to hodí na jinou instanci, tam budou jiné data že nikdy, nikdy, nikdy nikdy MySQL in app produkci existuje šikovný plug-in Microsoft Azure Forward Press kde můžete nastavit aby se všechny aploudy ukládaly do Azure Storage Azure Storage je místo na ukládání soubodů v Azure, je to na to připravený je to na to škálovaný propusnosti tam někde v desítkách tisíc requestu za sekundu takže se tak nepůdří to zabít a je velice jednoduchý to nakonfigurovat ale dalšiný druhá variantat je ukládat přímou na to instanci, tam je omezený místo omezený výkon, bla bla, znáte to je dobrý pochopit, jak funguje škálování že chvíli když se nám zvíší záťeš toho webu, tak máte dvě možnosti budučkálovat nahoru nebo do šířky Skill app zjednoho procesoru budete mít dvá tři, víc paměti nebo silnější nebo je to standard, nebo je to premium a tak dál že tohle až tolik nepoužívá, lepší scale out, to znamená, že mi to neběží na jedný instanci, na jednom serveru nejdou, na dvou, na třech, na čtyřech, na třech, na třech, na dvou a load balancer sám rozhoduje, kam ten požadevek přijde. Tohle můžete dělat ručně, nebo automaticky. Jak to vypadá? Scale out, znamená, že si všimnou, že je můj blog je strašně populální, co budu dělat, nestíhá to, háře to 5 stovky, tak prostě přidám další. Já dám radši 5. Save, do minuty to naběhne. Další možnost je na stavici automatické škálování a tady už můžete dělat relativně kompleksní pravidla. Můžete říct, že třeba když průměrné vytížení procesoru za posledních 10 minut bude větší než 70%, tak přijde i další instanci. To znamená, že se to bude dědit automaticky. Tady pozor, trošku past, je, že nejmější hodnota je 5, takže tam je plovoucí okno, kdy to sleduje průměr, tohoto cpučka a až po 5 minutách to naškáluje. Takže kdybyste si s tím hráli a říkali si, tak teď tam pošlu load test, to budím, co to udělá, tak se nedívte, že to neudělá nic. Prostě až po 5 minutách se přihodí ta instanci. V tom případě vym, kdy ta kampani se stane, tak bych to udělal ručně. Tohoto se je spíš používá na aplikace pod velkou zátyží, která postupně narůstá a pak je jednoduší to pořešit. Já jsem si zkusil tam postiť nějaký jednoduší load test, 600 uživatelů konkarentních. Tady je vidět, kdy to naškálovalo, příblíště po těch 5 minutách, po 5 a půl, mi tady klesla odezva a je vidět, že začala zase růst. Takže by to chtělo, samozřejmě, naškálovat ještě znovu. Jenom ten test byl 10 minutový, takže už to nestihl. Tak, škálování. S tím se pojí i supercash, protože spíš, než na to, že by to nestihl web server, narazíte na to, že nebude stěje data báze. Že to bude házet 5 slavky při spojení. Určitě znáte supercash, nejvygyneruje statické soubory, ale mělka s těch stráné, k tím pádem na data bázi toho nejde tolik. V ežilto funguje. Dobře. Trošku lákavý, taky může být zapnout si tak zvonou low-clash, což ten app service podporuje, ale je to triky. Protože low-clash znamená, že nestihl soubory nebudou pocházit s nějakého společního úložiště, ale že se opravdu nakopídou na ten web server a tam od seď se budou načítat. U PH-kolik aplikací a i třeba JavaScriptových je to super, protože oni většinou bývají hodně náročný na IOW operace a může je to zbrzdit. Takže když se zapnete low-clash, tak se budou načítat z lokálního filesystemu. Na druhou stranu, případně WordPressu, to může být triky, protože vyděláte třeba updated pluginů, děláte updated shablon, měníte tam různý věci a to se ukládá v tomhle případě na tu instanci. Takže jak mle přidáte další instanci, tak tam ty změny nejsou. To je nasadíte novou verzi, zase jsou ty změny pryč. Kde se to dá pa užít, je ve spojití se staging slotem. Ve smyslu, že na produkci nastavíte tu low-clash, ale na tom stagingu, na tom testování ne. Takže tam vidíte ty změny o kamžitě, všechno se zachová a jak mlejste s tím spokojení, tak uděláte swap, to jsem ukazoval a v tu chvíli produkce si načte do cache ty nový soubory a ty už se nemění, tam očekávám, že to zůstane, jak to je. Takže třeba update a další věci testujeme v tom stagingu. Kdybyste chceli cdnku, je tam. Nezkoušel jsem prakticky, ale je možné si vytvořit, je to akamaj, takže má docela dost endpointu po světě. Dobrý nápad je hromadit více aplikací na jeden upserviceplán, je to ekonomický. Na druhou stranu, pokud máte klienta, který, kde očekáváte, že si ve mě hodně toho výkonu bude mít velkou zátěž, tak mu prostě dedikujete jeho vlastní plán. A poslední věc, kterou vám chci ukázat, která mi přijde hodně super, jsou automatické backupy. Jednu z funkcí, vidíte, že je tady spoustat těch různých feature, ale jednou z nich je možnou z nastavici automatický backup, kdy já kliknu na konfig, řeknu do jakýho story, chci ty zálohy ukládat, takže už tady mám třeba vytvořené nějaký Dux Webpl, do konkrétního containeru backups, OK. A teď můžu říct, že třeba jednou za den, v 11.34 se mi udělá záloha. A udělá se záloha webu, to znamená všech souborů, udělá se záloha konfigurace toho webu, a udělá se záloha databáze, protože používám connection string v Azure, a tady ho nemám, protože jsem přepnout ty sloty. Kdybych tady děl ten connection string, tak ho zaškrtnu. Takže nakonec tam najdu na story, či každej den tuhle zálohu. Myslím si, že maximum je asi tři za den, nebo čtyři v tomhle automatickým. A nic mám nebrání si udělat ručně. A pak je tady i hezky restore. Poslední věc, SSL-ko. Azure vám dává z darma k dispozici HTTP na Azure Web site.net. Když jste to je vlastní certifikat, můžete si o tam napojit a případně použít let's encrypt jako extension. Tahle extension asi postará o to, že se automaticky každý jí asi 3 měsíce nebo jak rychl ten let's encrypt vyprší. Automaticky obnoví certifikal pro doménu. I Microsoft už se nejednou stalo, že se nám vypršeli certifikáty na velkých doménách. Kdybyste chtěli e-mail, počítejte s tím, to je trochu keč. Ten web hosting nemá v sobě možnost semetop. Takže použijete externí službu, třeba. Třeba sent grid. Závěrem, než se dostaneme k dotazu, myslí tam nějaký jsou. Jeden. Kdybyste si to chtěli zkusit, existuje způsob, jak se k ežero dostat za darmo, je to defesentials. Na jeden rok dostanete možnost vytvářet web-upky, jsou tam i nějaký virtuáli do určitých výkonů a pár dalších věcí. Co mi sklamalo a co tam není, je MySQL jako služba. Takže řešení tady proto je buď využít kredit, který tam na začátku dostanete a potom to nastaví do virtuálu a nebo prostě použít jinou MySQL database někde vedle. Doufám, že se tam dostanete taky někdy. A nebo si vytvářete triálku, dostanete 200 dolarů na měsíc a můžete zase s nímať dělat, co chcete. Kdyby vám zajímala tahle prezentace, chtěli jste se podívat na ty odkazy nebo si to znovu projít, případně postupy dema, který se mu kazoval, tak to najdete tady. A teď můžeme přijít na dotazy. Jsou nějaké přímo tady. Jak funguje load balancer automaticky? Load balancer je tam built in, takže to prostě ani nerozhoduješ, nebo ne. A on dělá round robin podle vytížení procesoru. Že on monitoruje celý ten cluster všechny instance a když tam, když jedné je vytíženější, tak to prostě hodí na jinou, s tím, že potom uživatel má v prohlížeči a fanity kuký, takže se dostane vždycky na stejnou instanci. Co všedáte, taky vypnout, ale není to úplně dobré. Co mě nejvíc potrátilo při rozcházení WordPressu, asi ten docker, ale zpíš, ta přehršel možnosti, jak to udělat. Mě jsem z tohle v hlavu, jak pátrací balon, protože je možný to udělat, takhle, takhle, takhle, a teď co je nejlepší. Takže na koniec, jsem nejvíc času strávil s tím, že jsem se snažil rozjet třeba ten debugging v doku, pak to tam nějak rozumě nasadit a tak. A potom jsou to ty výkonostní problémy, pokud je o soubory. Když je ta sajta hodně zatížená a nepoužívá tu super cache, tak tam jsem narážel na to, že to prostě nizvládalo z ty requesty. Takže jsem to vyřešel tou keši. CDN-ku jsem konfiguroval, ale pak jsem mi už nějak nepoužíval, tak neměl jsem mi k tomu moci vyrozumět vyskoušet. Ta konfigurace jako taková je jednoduchá, tam se prostě zaškrtné, že to má kešovat konkrétní sajtu nebo soubory na storagey a pomocí toho... ...toho plug-inu se řekne, že tohle je CDN-ka. Tak co píšou tedy? Jak probíhá aktualizace kodu, když běží více instancí na jednou? Jenutný downtime nebo snížení počtu instancí na jednu? Většinou se to vejde do toho TCP-tajimoutu, do jedný minuty, že prostě když uživatel pošle request, tak tu odpověj dostane, i když se nasazuje nová verze. Technické to funguje tak, že to repose nasadí do toho z dělního úložiště a zněj si to pak postupně bero jednotlivý instancet, tak prostě se votočí jedna, druhá, třetí, čtvrtá, takže tam by downtime neměl být skoro vůbec. Když má uživatel smůlu, že zrovna klikne na tu instancí, která se aktualizuje, tak se můhle bude chvíli točit kolečko. Když bude být jako hodně smůlu, tak mu to vytájimoutuje, ale to jsem snadžiště neviděl, že by to bylo takhle zlí. Já jsem ho měl ve svim Windows Serveru v Azure, a případně je možné udělat když ho stovala v sobě taky do CrContainer. Jo, protože to je lowclhou z toho serveru. Já jsem tady připojený někam, kam si do Azureu, a tam to všechno běží. Ještě jsem se k tomu nedostal, oni mi v práci nechtějí tento AVSko zaplatit. Tak... Takže nevím, ale určit, že rád si poslechnu zkušeností z jiných cloudů. To mě zajímá. No tak, ono pak záleží, jak se to počítá, co to znamená, že nejdraší, když si mají třeba stejnou funkcionalitu, si mají stejnou dostupnost, hodně často se to začná vypláce, když tam to sají tu nedávám jednu, ale dám jich tam třeba pět. Že mám pět malých klientů, tak je prostě hodím na jeden web hosting, a pak je to 30 eur děleno pěti, už není tak zlí na to, co za to dostává. V velkých hráčů jsou spoplatiná i data, přeno si data tak. To je to stejný všechno, počítá se přeno z datacentra ven. Trošku pastě je v tom, že přeno z datacentra ven je i mezi datacentry. Takže když si nedám pozor a dám si tu databázy do West Europe a web do North Europe, pak se to taky počítá. Ale tam je to i výkonosně špatný, takže na to je třeba si dát pozor vždycky. Že WordPress Latest Image nemá extension pro zip a rozzipování. Já jsem tam pluginy instaloval a neměl jsem s tím žádný problémy. Nenávazel jsem. Dvě minuty. Vtip nějaký nikdo. Tak dobře. Tak já vám děkuji, budu tady ještě chvíle, takže kdyby vás zajímalo oště něco offline, klidně se můžete zeptat nebo si můžeme pobavit o tom, jak to provozujete v jiném klaudu a na co narážíte. A to je ode mě všechno. Díky.