Windows Azure WebSites – nejjednodušší přechod do cloudu

2. díl - Windows Azure WebSites – nejjednodušší přechod do cloudu

Tomáš Herceg       25.08.2013       ASP.NET WebForms, ASP.NET MVC, Azure, ASP.NET/IIS, .NET       17854 zobrazení

V tomto díle si představíme technologii Windows Azure WebSites, která umožňuje snadno hostovat webové aplikace napsané v ASP.NET v cloudu.

Windows Azure WebSites je v zásadě klasický webhosting, na němž můžete provozovat aplikace napsané v ASP.NET, PHP, Node.js nebo Pythonu. Jsou velmi snadné na použití a jejich výhodou je podpora deploymentu aplikace pomocí technologie WebDeploy (kromě klasického FTP přístupu).

Pokud používáte některou ze služeb poskytujících správu verzí (např. GitHub, CodePlex, TFS v cloudu a další), WebSites podporují i automatický deployment přímo ze source control (tzv. continuous delivery). Například pokud použijete Team Foundation Service, přidá se vám do projektu Build Definition, kterou můžete spouštět buď automaticky, nebo ručně, a která umí stáhnout poslední verzi zdrojových kódů, zkompilovat je, spustit na nich testy (jsou-li jaké) a nakonec tuto verzi nasadit přímo na Azure WebSites.

 

Zakládáme účet na Azure

Stačí navštívit stránku www.windowsazure.com a proklikat průvodce. Pro registraci je vyžadováno zadat údaje k platební kartě, ale standardně je nastaven tzv. spending limit, to znamená, že pokud vyčerpáte kredit $150, který máte v rámci Trial verze přidělen, Microsoft pozastaví hned všechny služby, takže nebudete platit nic. V případě, že tedy na trial verzi zapomenete nějaké služby běžet, nestrhnou vám z karty nic, ale služby budou pozastaveny.

Jakmile vám kredit vyprší, zobrazí se vám na detailu předplatného hláška, že máte nastaven spending limit, a budete jej moci vypnout.

krok 1  krok 2   detail předplatného

Kliknutím na tlačítko Portal na obrazovce detailu předplatného se dostanete do hlavního portálu Azure, kde vidíte všechny svoje služby.

Azure portál

Na boku v menu vidíme všechny služby, které je možné vytvořit. K ostatním funkcím přistupujeme přes menu v pravém horním rohu.

 

Vytváříme novou WebSite

Otevřeme sekci Web Sites a klikneme na Create a new website. Máme 3 možnosti – buď vytvoříme novou website s výchozími nastaveními, v takovém případě zvolíme Quick create. Nebo můžeme chtít nastavit všechny možné parametry, v tom případě zvolíme Custom create. Případně můžeme vytvořit website z galerie předpřipravených, to bychom použili v případě, že potřebujeme narychlo zprovoznit nějaké hotové CMS nebo e-shop, např. DotNetNuke, BlogEngine.NET, Joomla, MediaWiki apod.

My vytvoříme website včetně všech nastavení, zvolíme tedy možnost Custom create.

vytvoření website   krok 1   krok 2

Zadáme nějaký unikátní název website, vybereme datacentrum, v němž má být aplikace umístěna, dále zvolíme databázi a název connection stringu (pokud používáme ASP.NET). Jako databázi můžeme použít MS SQL Server (buď klasickou placenou databázi, nebo free databázi s max. velikostí 20 MB) nebo MySQL, což se hodí především pro PHP aplikace.

Na následující obrazovce zvolíme název databáze a vybereme server, na němž má být umístěna. Vzhledem k tomu, že žádný server ještě nemáme, založíme si nový (v budoucnu pak na tomto serveru můžete mít třeba 5 databází – z hlediska ceny to žádný význam nemá, databáze na jednom serveru mají společný přihlašovací účet, takže se nedoporučuje sdílet jeden server pro více aplikací, které spolu nesouvisí).

Na další obrazovce můžeme ještě určit některé parametry databáze, jako např. výchozí collation. Poté se již začne vytvářet website, což chvíli trvá. Jakmile je vytvořena, kliknutím na název otevřeme její detail.

Detail WebSite

image

Na záložce Dashboard vidíme základní informace o website, graf, na němž se časem zobrazí informace o vytíženosti aplikace. V sekci Web Endpoint Status můžeme nastavit monitoring funkčnosti a následně sledovat dostupnost aplikace. V sekci Autoscale Status je možné nastavit automatické škálování, které při větší zátěži aplikaci rozběhne na více serverech, a jakmile zátěž pomine, vrátí se na jeden server.

V pravé části si můžeme zobrazit connection string k databázi (View connection strings), stáhnout publish profil do Visual Studia pro nasazení aplikace (Download the publish profile), dále nastavit jméno a heslo pro FTP přístup (Set up deployment credentials), restartovat heslo v případě zcizení publish profilu (Reset your publish profile credentials) a nakonec nastavit automatické nasazení ze systému pro správu verzí.

V panelu dole jsou potom tlačítka pro zastavení, restart, smazání website a asi nejdůležitější je Manage domains, pomocí kterého je možné nastavit, aby webová aplikace běžela např. na doméně 2. řádu. Toto tlačítko je nyní zakázané, jelikož website běží ve Free módu, kde tato funkce není dostupná.

monitoring   configure   configure

Na záložce Monitor můžeme podrobněji sledovat zatížení a chování aplikace, na záložce Configure je možné měnit nastavení aplikace, např. verzi .NET Frameworku a PHP, SSL certifikáty, úroveň logování a monitoringu aplikace, connection stringy a názvy souborů, které se použijí jako výchozí (např. index.html). Některá z těchto nastavení je možné specifikovat i pomocí souboru web.config.

image

WebSites mají aktuálně 3 režimy, ve kterých mohou fungovat.

  • Free. Nelze provozovat na vlastní doméně, pouze na doméně něco.azurewebsites.net. Tento režim má mnoho omezení, a pokud se jedná o navštěvovanější aplikaci, pak brzy narazíte na limit přenášených dat – je omezen na 165MB denně. Nepodporuje škálování. Zdarma je jen 20MB SQL databáze, větší už se platí.
  • Shared. Podobný model jako free, ale podporuje vlastní domény (bez HTTPS) a škálování. Datové přenosy jsou již placené a tudíž neomezené.
  • Standard. Plnohodnotný režim, aplikace má vyčleněnou jednu nebo více Small, Medium nebo Large instancí. Vhodné pro větší a často navštěvované aplikace, lepší než 1 Medium instance budou 2 Small instance, pokud je aplikace napsána dobře a podporuje škálování.

Dále je zde možné nastavit i variantu použité databáze, kromě 20MB free databáze existují Web a Business edice, které se liší především maximálními možnými velikostmi databáze. Web má max. velikost 5GB, Business až 150GB. Každá databáze je k dispozici ve 3 replikách - v případě, že jedna selže, okamžitě přijde na řadu druhá.

Nedávno byla spuštěna ještě edice Premium (aktuálně v betaverzi), která nabízí vyšší výkon.

Na poslední obrazovce Linked Resources je možné přidat další databáze a zdroje, které aplikace používá. Jedná se čistě o logické propojení zdrojů, které spolu souvisí – např. kdybyste chtěli smazat databázi, která je přilinkovaná k website, tak vás portál upozorní, že databáze je zřejmě používána. Každopádně webová aplikace se může připojit i k databázi, která nalinkovaná není.

 

Nasazujeme aplikaci

Jakmile máme webovou aplikaci hotovou, zbývá ji nasadit. Máme v zásadě dvě možnosti – na stránce Dashboard si vytvoříme heslo pro FTP a připojíme se pomocí standardního FTP klienta, nahrajeme soubory, upravíme web.config atd. Druhou a praktičtější možností je stáhnout si publish profil, nahrát ho do Visual Studia a provést nasazení pomocí kliknutí na tlačítko Publish v kontextovém menu projektu v okně Solution Explorer.

stažení publish profilu  image

Prohlížeč nám vrátí soubor s příponou .publishsettings, který uložíme na disk. Ve Visual Studiu klikneme pravým tlačítkem na naši ASP.NET aplikaci a vybereme možnost Publish. Objeví se průvodce pro nasazení aplikací.

krok 1   krok 2

Na první obrazovce klikneme na tlačítko Import a v dialogovém okně vybereme cestu k souboru .publishsettings. Na další obrazovce vidíme údaje, které Visual Studio použije pro nasazení. Používáme protokol WebDeploy.

krok 3    publish

Na třetí obrazovce můžeme vybrat build konfiguraci (Debug nebo Release), která se má nasadit (podle toho se provedou Web Config transformace, takže uvedeme-li např. v souboru Web.Release.config následující kód, upraví se connection string na výše uvedený). Více informací o Web Config transformacích najdete na MSDN.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  
  <connectionStrings>
    <add name="DefaultDatabase"
      connectionString="Data Source=tcp:kcd7i7xcqm.database.windows.net,1433;Initial Catalog=dnp_demo;User Id=dnp_demo@kcd7i7xcqm;Password=#####;"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
  </connectionStrings>
  
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
  </system.web>
  
</configuration>

Správný connection string pro použití v cloudu najdete na záložce Dashboard po kliknutí na View connection strings.

Po dokončení procesu je webová aplikace nasazena a běží na výchozí adrese website.

Kromě protokolu WebDeploy bývá občas praktické nastavit i FTP přístup, občas se hodí mít možnost urgentně opravit nějakou drobnou chybičku v jednom souboru aniž byste museli pracně a zdlouhavě spouštět Visual Studio, otevírat projekt a nasazovat celou aplikaci. Nehledě na to, že aplikace může ukládat nějaké soubory třeba do složky App_Data, k níž se jinak nedostanete.

 

Škálovatelnost a omezení

V případě, že hodláte provozovat aplikaci pouze na 1 instanci, není potřeba prakticky nic řešit a aplikaci lze nasadit prakticky beze změny (pokud tedy neděláte nějaké šílenosti typu používání COM objektů, přístup na disk mimo adresář webové aplikace atd.). U Azure WebSites ale nevadí, když si aplikace zapisuje do vlastního adresáře, data se ani nikam neztratí.

V případě, že chcete aplikaci škálovat, je nutné si uvědomit, že aplikace běží na dvou různých serverech a load balancing probíhá na úrovni HTTP požadavků, i včetně situace, že první požadavek je nasměrován na první instanci, ale postback na tu samou stránku je odeslán na jinou instanci. Aplikace by si tedy neměla držet žádná důležitá data v paměti (cacheování nevadí, pokud jsou data při změnách vždy propsána ihned do databáze). Neměla by ani zapisovat na disk nic kromě dočasných souborů. Také použití session je problematické, jelikož ve standardním nastavení se session uchovává v paměti – doporučuji session nepoužívat vůbec, protože mimo tohoto problému přináší 100 problémů dalších i bez škálování, a pokud už ji použít musíte, pak ji ukládejte do databáze, aby na ni viděly všechny instance.

V případě, že potřebujete ukládat nějaké soubory, není možné je ukládat do filesystému, protože není kontrola nad tím, na jakou instanci se uloží (nevíte, která instance ten požadavek zrovna zpracovávala). Zde je vhodné použít prostředky Windows Azure, například Blob Storage, o němž si budeme povídat v některém z dalších dílů.

Pokud škálujete, je třeba si uvědomit, že nikdy nevíte, na jakém konkrétním serveru se požadavek provede. Proto je nutné tomu celou aplikaci přizpůsobit a vyhnout se praktikám, které by mohly dělat problémy, jako například již zmíněná session, ukládání souborů s daty na disk nebo držení dat v paměti.

 

Nastavení DNS

Pokud se jedná o reálnou aplikaci, asi málokdo ji chce provozovat na adrese něco.azurewebsites.net. Proto je vhodné na záložce Dashboard dole kliknout na tlačítko Manage Domains. Předtím je nutné website přepnout alespoň do režimu Shared, ve Free módu vlastní domény podporovány nejsou.

Dejme tomu, že jste vlastníky domény www.contoso.com a chcete tuto doménu nasměrovat na vytvořenou WebSite. Musíte nejprve správně nastavit DNS záznamy, aby tuto doménu směrovaly na Azure. Konfigurace DNS se provádí u každé domény jinak, záleží, kde jste doménu registrovali a hlavně kdo spravuje vaše DNS záznamy (často to bývá přímo registrátor, ale není tomu tak vždy).

nastavení domén 

Typicky je potřeba nastavit jak A záznam pro samotnou doménu contoso.com (na IP adresu, která je uvedena v dialogovém okně), tak i CNAME záznam pro subdoménu www.contoso.com – ten by měl vést na něco.azurewebsites.com.

Po nastavení DNS je třeba počkat, než se změna zpropaguje (typicky to trvá pár desítek minut, ale může to trvat i několik hodin, v určitých případech i několik dní), ale jakmile se změna zpropaguje, pak lze přidat doménu v dialogovém okně na obrázku. Po potvrzení začne aplikace fungovat i na zadané doméně.

 

 

No a to je pro tento díl vše. Příště si budeme povídat o SQL Azure, ukážeme si, jak dostat databázi do cloudu a zpět, jak se připojit k databázi přímo ze svého SQL Management Studia atd.

 

hodnocení článku

0       Hodnotit mohou jen registrované uživatelé.

 

Všechny díly tohoto seriálu

6. Migrace ASP.NET aplikace do Azure WebSite 18.05.2014
5. Affinity Groups 12.11.2013
4. SQL Database – Nasazení databáze, dostupnost a škálovatelnost 11.09.2013
3. SQL Database – relační databáze hostovaná v cloudu 02.09.2013
2. Windows Azure WebSites – nejjednodušší přechod do cloudu 25.08.2013
1. Seznámení s Windows Azure 20.08.2013

 

 

 

Nový příspěvek

 

Prechod do azure s místního serverhostingu/cloudhostingu

Ahoj,

Mel bych dotaz:

Provozuji jeden obchod, který jsem si i napsal. Aplikace je napsána v mvc5,Ninject, code first přistup atd. Muzeš mi, prosím, napsat co vše potřebuju koupit abych mel jistotu ze nebude výpadek a já nepřijdu o data? Četl jsem něco o tom ze potřebuju dvě instance.

Mam ještě dotaz na škálovatelnost - v aplikaci používám ASP.NET IDENTITY jak přihlasovaní tedy řešit?

Co v případě, že mám obrázky uložené na disku a ne v db, ukládám také objednávky v pdf na disk - košíky, ale mám v db....

Moje db bude mit cca 30gb kdyz dam obrazky do db.... Stejně jak pak budu muset ukládat na disk - rychlost

Jsou někde ty praktické věci popsány?

Děkuji moc za odpověď.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

1) Bude potřeba Azure SQL databáze, stačí jedna, o data nepřijdete, je to klasický SQL Server, akorát hostovaný v cloudu.

2) Pak potřebujete WebSite, také stačí jedna (mají občas krátkodobé výpadky, stejně jako libovolný hosting, dříve je měli častěji (když se jednalo ještě o beta provoz), ale poslední dobou se na ně nenarážím), leda že byste potřeboval vysokou dostupnost, pak stačí také jedna, ale na záložce Scale řeknete, že chcete 2 instance.

3) Je dobré upgradovat na nejnovější Entity Framework a zapnout connection resiliency pro Azure SQL.

4) Obrázky a jiné soubory, které jste ukládal do filesystému, bude potřeba nyní ukládat do Azure Blob Storage, o kterém tady bude některý z dalších dílů seriálu.

5) ASP.NET Identity by měla fungovat normálně, jediné, s čím by mohl být problém, je, pokud v aplikaci používáte session - ta by při škálování přestala fungovat a musel byste nastavit, aby se ukládala do databáze.

A určitě aplikaci na záložce Scale přidělte rezervovanou instanci, na té shared a free jsou omezené datové přenosy a využití CPU, takže by se mohlo stát, že ji Azure samovolně zablokuje.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Tím scale myslíte jak se voli s - m - l - tak ten pocet - tedy 2vm?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Hlavně počet. Na většinu jednoduchých webů stačí 1 nebo 2 small instance, větší dávají smysl jen u výpočetně či paměťově náročných aplikací, což typické weby nebývají.

Můžete zkusit i 2 extra small instance, ty jsou velmi levné, a pro méně navštěvované aplikace by to mohlo být řešení, tohle bych ale podložil výkonnostními testy. Tam bych viděl jako hlavní omezení, že ty extra small instance jsou připojeny jen 5MBit/s linkou, takže pokud máte na webu hodně grafiky, bylo by v tom případě vhodné dát ji do CDN.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

já mám cca 500 tis stažených stránek.... takže stačí na to dvě small?

Jak se tedy prakticky řeší session?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

500 tisíc pageviews, ale za jakou dobu? Za den nebo za měsíc?

Tohle bych podložil nějakým zátěžovým testem, možností, jak to udělat je několik, dneska existuje spousta online služeb, které tohle řeší (Google mi vyplivnul loadimpact.com, blitz.io), případně si můžete napsat vlastní testovátko, nebo jestli máte Ultimate verzi Visual Studia, tak můžete použít jejich load testy.

Případně to můžete udělat tak, že to na 1 den dáte na 2 large instance, což už je hodně silná konfigurace, a podíváte se, jak moc jsou vytěžovány, a pak to downgradujete na 2 medium nebo na 2 small. Pokud to tam bude jen 1 den, nebude to stát moc, viz kalkulačka na webu www.azure.com, mělo by to být v pohodě možno odzkoušet i v trial módu, kde dostanete nějaké kredity zdarma. Můžete do aplikace zkusit zaintegrovat i NewRelic (free verze by měla stačit), který vám tam udělá kompletní performance analýzu, je to zároveň i profiler, takže hned uvidíte, co zoptimalizovat a jak na tom ta aplikace je.

Co se týče session, já bych to prakticky řešil tak, že bych ji vůbec nepoužíval. Pokud ji již v aplikaci máte a není ekonomické to předělávat na jinou metodu, pak bych použil tohle: http://msdn.microsoft.com/en-us/library/....

Anebo si můžete napsat vlastního session state providera, který to bude ukládat do databáze nebo do blob storage.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

ahoj, me by zajimalo pokud tedy budu delat aplikaci, která pouziva asp.net identity je potreba nejak resit - pokud budu pouzivat na vice instancich - skalovatelnost?

Jak se pak resi cacheovani?

Já mám třeba applikaci, která nastavuje pouziany jazyk a) dle prohlízece b) u prihlášeného uživatele co si zvolí - kam to mam ukladat? Podle jazyku se pak tahaji zaznamy v danem jazyku atd...

Je mozne v azure platit jen skutecny spotrebovany cas? napr. jsou hodiny kdy se na serveru nic nedeje - neni zadny pristup...

Ivona

nahlásit spamnahlásit spam 0 odpovědětodpovědět

ASP.NET identity by také autentizační token měla uchovávat v cookies, informace o vybraném jazyce bych uložil do cookies, anebo pokud je již uživatel přihlášen, tak do databáze.

Cacheování - buď můžete použít standardní ASP.NET cache, ale ta není distribuovaná (což často nevadí (je to zdarma, protože funguje inmemory, ale každá instance má pochopitelně svou cache, není to sdílené), potíž je akorát pokud potřebujete v určitých situacích nějakou tu položku z cache vyhodit na všech instancích, ale není ale tak složité napsat si to vlastními silami např. přes ServiceBus). Anebo Azure nabízí vlastní Windows Azure Cache, která tohle řeší, ale ta je placená - je potřeba zvážit, kolik dat budete cacheovat a jestli vůbec distribuovanou cache potřebujete, nebo stačí vlastné malá lokální cache na každé instanci.

Platíte vždy za to, že instance běží a je rezervována pro vaše potřeby. Jestli obsluhuje requesty nebo nakolik je vytěžované CPU, na tom nezáleží, aplikaci tam máte nasazenou, tak platíte za každou hodinu. Maximálně můžete udělat to, že v nočních hodinách aplikaci pustíte jen na jedné instanci a ve špičce nebo prostě přes den zapnete další 3 instance, dá se to naskriptovat a automatizovat, nebo má nově Azure funkci autoscale, která podle zátěže sama reguluje počet instancí, na kterých to běží.

Ohledně b2b, mají tam něco jako affiliate program, ale já to řeším tak, že to zákazníkům přefakturovává sám.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jak byh se pridal k ivone.

Takze tam neni mozne dostat provii s list price? musim ty ceny zvednou o svou provizi?

Radomir

nahlásit spamnahlásit spam 0 odpovědětodpovědět

O takové možnosti nevím, zkusím zjistit.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Jo jeste jedna vec, je mozne azure nakupovat jako b2b a pak prodavat mojim zakaznikum? - dostavat tedy provize?

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Verifikace kreditní karty

Ahoj,

včera jsem si zřídil trial verzi účtu na Azure. Dneska mi na účet přišla karetní transakce s odečtem 1 Eura označená jako MSFT *ONLINE. Jedná se o nějaký jednorázový poplatek spjatý s vytvořením účtu nebo je něco špatně nastavené?

Ondra

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Ne, oni jen někdy testují, že karta skutečně funguje, během pár dní by měli zpátky poslat refundaci.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Časová zóna

Hezký článek.

Jen drobné doplnění, že je ještě potřeba občas dát pozor na to, že servery, které web site (nebo cokoliv jiného na Windows Azure) hostují nemají nastavené české prostředí (to většinou nevadí, pokud není aplikace napsaná úplně spraseně, nebo to případně napraví element globalization ve web.config) a mohou běžet na jiné časové zóně než UTC+01:00, na kterou jsme v našich končinách tak nějak zvyklí.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

Chtěl jsem to řešit v dalších dílech, ale díky za doplnění.

Pokud aplikace nepoužívá IoC/DI, dá se to snadno řešit naimplementováním statické třídy DateTimeLocal s propertami Now a Today, která to vrátí v našem časovém pásmu, a pak už stačí jednoduchý search/replace v celém projektu.

Pokud aplikace používá IoC/DI, bude mít pravděpodobně nějaké rozhraní IDateTimeProvider, pak už je to jednoduché.

nahlásit spamnahlásit spam 0 odpovědětodpovědět

WebDeploy

Můžu potvrdit, že WebDeploy se supr věc, zavádím to všude, kde je to jen trochu možné. A s tím stáhnout si ten profil přímo to VS je to ještě lepší.

Bohužel poslední webík máme jen na "klasickém českém" hostingu, kde tuhle věc ještě neobjevili.

nahlásit spamnahlásit spam 0 odpovědětodpovědět
                       
Nadpis:
Antispam: Komu se občas házejí perly?
Příspěvek bude publikován pod identitou   anonym.

Nyní zakládáte pod článkem nové diskusní vlákno.
Pokud chcete reagovat na jiný příspěvek, klikněte na tlačítko "Odpovědět" u některého diskusního příspěvku.

Nyní odpovídáte na příspěvek pod článkem. Nebo chcete raději založit nové vlákno?

 

  • Administrátoři si vyhrazují právo komentáře upravovat či mazat bez udání důvodu.
    Mazány budou zejména komentáře obsahující vulgarity nebo porušující pravidla publikování.
  • Pokud nejste zaregistrováni, Vaše IP adresa bude zveřejněna. Pokud s tímto nesouhlasíte, příspěvek neodesílejte.

přihlásit pomocí externího účtu

přihlásit pomocí jména a hesla

Uživatel:  
Heslo:  

zapomenuté heslo

 

založit nový uživatelský účet

zaregistrujte se

 
zavřít

Nahlásit spam

Opravdu chcete tento příspěvek nahlásit pro porušování pravidel fóra?

Nahlásit Zrušit

Chyba

zavřít

feedback