Azure címkéhez tartozó bejegyzések

Azure sebesség teszt

Ha aszerint akarod eldönteni, hogy melyik Windows Azure adatközpontban legyen az alkalmazásod, hogy melyik a leggyorsabb, akkor a Windows Azure Speed Test oldal segítségével összemérheted őket:

http://azurespeedtest.azurewebsites.net/

 

Köszönet a linkért Gál Tamásnak.

 

Technorati-címkék: ,
Reklámok

Több website-ot tartalmazó solution publikálása Azure-ra

Az Azure Websites egyik kiváló szolgáltatása, hogy közvetlenül hozzá lehet kapcsolni forráskód kezelő rendszerhez, így amikor a forráskód frissül, az automatikusan azonnal kikerülhet a felhőbe.

Ezt pofonegyszerű összevarázsolni, csak indítsuk el a New –> Compute –> Web Site –> Custom create varázslót:

multisite-new

Az első lépésben adjunk nevet a webhelynek, és pipáljuk be a Publish from source control jelölőnégyzetet:

multisite-name

Ennek hatására megjelenik a varázsló második lépése, ahol kiválaszthatjuk a forráskódkezelő rendszerünket, például GitHubot:

multisite-where

GitHub esetén egy OAuthos authentikáció következik, majd meg kell adnunk, hogy melyik repository-nak melyik ágát (már nem csak mastert lehet!) kívánjuk erre a webhelyre publikálni:

multisite-repo

A pipára kattintva meg is történik a varázslat, pár másodperc alatt létrejön a webhelyünk és már települ is rá az alkalmazás.

De mi van akkor, ha a forráskód olyan Visual Studio solutiont tartalmaz, amiben több webes projekt vagy több website van, melyik fog települni? Az első.

Azonban mi nem mindig ezt szeretnénk.

Ha az Azure website-ra mindig a solution egyik projektjét kívánjuk telepíteni, akkor létrehozhatunk a repo gyökerében egy .deployment nevű INI fájlt, amiben megadhatjuk a telepítendő projektet:

[config]
project = MySolution/MyWebProject.csproj

Előfordulhat azonban, hogy több Azure website-unk van, és az egyikre a solution egyik webes projektjét, a másikra a másik webes projektjét kívánjuk telepíteni. Ebben az esetben a beállítást nem drótozhatjuk bele a forráskódba, hanem a felhőben kell trükköznünk. Látogassunk el a CONFIGURE oldalon belül az app settings szekcióba, ahol vegyünk fel egy új beállítást Project néven:

multisite-appsettings

Az értékként adjuk meg a .csproj fájlra vagy az ASP.NET website mappájára mutató repo-gyökér relatív elérési utat.

Mentés után a következő deploymentnél már ennek figyelembe vételével fog történni a telepítés.

 

Technorati-címkék: ,,,

Azure AD számokban

Néhány érdekes szám az Azure AD-ról:

  • Több, mint 430 milliárd authentikáció, június óta 43%-os emelkedés.
  • 10 milliárd authentikáció/hét.
  • 1.4 millió vállalat, iskola, kormányhivatal és non-profit szervezet használja az Azure AD-t és ez a szám július óta duplázódott.
  • 240 millió felhasználói fiók
  • 127 országban
  • 14 adatközpontban

Forrás: http://blogs.technet.com/b/ad/archive/2013/10/04/an-update-on-dates-pricing-and-sharing-some-cool-data.aspx

Szerintem a legérdekesebb az, hogy a Microsoft felhőszolgáltatásai milyen rohamtempóban fejlődnek, főleg mióta ScottGu vezeti a csapatot.

 

Technorati-címkék:

Meglepő kapcsolat bontások SQL Azure-ban

Gyakran lehet találkozni azzal a ténnyel, hogy mivel az SQL Azure ugyanazt a tabular data stream (TDS) protokollt támogatja, mint a teljes SQL Server, a programozási modell teljesen azonos a két esetben. Ebből viszont – a közhiedelemmel ellentétben – nem következik az, hogy az alkalmazásunk felhőbe költöztetése mindössze annyiból áll, hogy átállítjuk a connection stringet!

Az SQL Azure ugyanis számos olyan esetben is hajlamos bontani a kapcsolatot, amihez nem vagyunk hozzászokva a saját szervereinken. Íme két példa:

  • 40197 – The service has encountered an error processing your request. Please try again.
  • 40501 – The service is currently busy. Retry the request after 10 seconds.

Ennek az alapvető okai a hibatűrésben és a rendelkezésre állásban keresendőek. Ha a kérés kiszolgálásában részt vevő valamelyik szereplő hibás lesz vagy épp frissül, akkor a felhőnek köszönhetően nem lesz tartós leállásunk, de szolgáltatás visszaállásáig (ami rövid idő) a kapcsolatokat bontani fogja a szerver. A másik ok, hogy mivel az adatbázisok osztoznak bizonyos erőforrásokon, az SQL Azure query és connection throttling szolgáltatásai biztosítják, hogy egyik ügyfél se akaszthassa le teljesen a kiszolgálást. Ha túllépjük a limitet, hibát fogunk kapni.

Mindennek az az eredménye, hogy időnként elszállnak az adatbázis lekérdezéseink, de mivel ezek okai alapvetően átmeneti jelenségek, bátran megismételhetjük a lekérdezést kicsit később. Ez sajnos nagyon kellemetlen, mert általában arra számítva írjuk meg az adatelérési rétegünket, hogy ha az adatbázis nem elérhető, akkor nagy baj van, és nem szoktunk arra számítani, hogy a hiba másodperceken belül megszűnik magától.

Magyarul: SQL Azure-on futó alkalmazások esetén gondoskodnunk kell ezeknek a hibáknak a kezeléséről, és a hiba jellegétől függően meg kell ismételnünk a lekérdezést. Ha korábban nem volt az alkalmazásunkban ilyen intelligens retry-logika, akkor a felhőbe költöztetéskor ezt bele kell tennünk.

Néhány segítség:

 

Technorati-címkék: ,,,

Virtuális gépek védelme a felhőben

Mikor a rendszereinket a felhőbe költöztetjük, annyira meg szoktunk örülni annak, hogy minden “megy magától”, hogy gyakran megfeledkezünk az alapvető biztonsági teendőkről (amiket pedig a saját gépeinken amúgy meg szoktunk tenni). Az első öröm általában akkor ér minket, amikor a varázslóval pikk-pakk létrehozunk egy új virtuális gépet az Azure-ban:

create-vm

A problémák – legalábbis részben – ebből az egyszerűségből fakadnak:

  • A rendszergazda felhasználónevet nem kell megadnunk, sőt nem is lehet (lásd fent, disabled), hiszen az minden esetben Administrator.
  • A gép IP címét nem kell megadnunk, hiszen az Azure a saját tartományából ad majd neki egyet.
  • A RDP-t nem kell beállítanunk, hiszen az minden esetben engedélyezve lesz az alapértelmezett 3389-es porton.

Sajnos ez a kényelem jelentősen megkönnyíti a támadók dolgát: csak végig kell nézniük az Azure IP tartományát és be kell próbálkozniuk a 3389-es porton az Administrator felhasználóval és valamilyen jelszóval. Ilyen RDP brute force támadásra számos eszköz létezik már, és sajnos van már hír olyan esetről is, amikor a támadók sikerrel jártak.

Amit mindenképp érdemes megtenni:

  • Az RDP ne az alapértelmezett porton fusson.
  • Célszerű beállítani, hogy milyen kliens IP címekről lehet RDP-zni a gépre.
  • A rendszergazda felhasználóneve ne az alapértelmezett legyen.
  • Az admin jelszó legyen erős.

Sandrino Di Mattia cikke részletesen leírja, hogy mindezt hogyan tehetjük meg.

 

Technorati-címkék: ,,

tfspreview.com

A Team Foundation Servernek létezik egy előfizetéses, felhőben (naná, hogy Azure-on) hosztolt változata, a Team Foundation Service. Mivel a szolgáltatás jelenleg preview fázisban van, ezért egyelőre teljesen ingyenes, azaz nulla forintért kapunk hozzáférést egy TFS-hez. Nem csak source controlról van szó, hanem a TFS-sel járó minden földi jóról. Aki nem hiszi, járjon utána a http://tfspreview.com oldalon.

tfspreview

Én már a legelső, nem nyilvános preview óta használom, és nekem nagyon bejött. Semmi perc alatt, böngészőből elkészítem az új projektet, és máris lehet hozzá kapcsolódni. Még egyfős projektek esetén is megéri és jobban hiszek benne, mint a saját gépemre telepített SVN-ben. Így jobban belegondolva, talán nem is túlzás az alábbi üzenet Mosolygó arc

love this

 

Windows Azure Mobile Services

A Microsoft Scott Guthrie blogján keresztül bejelentette a Windows Azure szolgáltatáscsalád legújabb tagját, a Windows Azure Mobile Servicest. Leegyszerűsítve a képletet: az új szolgáltatás segítségével a felhőben lévő SQL táblákban lévő adatainkat publikálhatjuk kliensek felé pillanatok alatt, méghozzá szerver oldali kód írása nélkül.

mobile-services-diagram

A kliens oldali kód megírásához pedig kapunk osztálykönyvtárat, így egészen minimális kódot kell írnunk, például (ScottGu posztjából kölcsönözve):

mobile-services-code

Néhány kiegészítés a cikkhez:

A bejelentés mindenhol Windows 8 kliensről szól, a fenti ábrán is ezek láthatók. Ez valójában egyelőre kizárólag WinRT alkalmazásokat jelent, mert az osztálykönyvtár erre készül.

A névben a “Mobile” szerintem nem kicsit félrevezető. Valójában bármilyen klienssel használható a szolgáltatás, alacsonyabb szinten ugyanis – egyáltalán nem meglepő módon – ODatás HTTP REST API van és JSON formátumú adatok. Hamarosan erről a REST API-ról is lesz leírás és a meghívásukat támogató osztálykönyvtár/metódusok.

Amitől talán valóban kicsit mobilos, az a push notification támogatás, amiben az az izgalmas kérdés, hogy mennyire csak WinRT és mennyire WP7.

Ha már mobil, akkor felmerül az offline elérés kérdése. Ezt jelenleg out-of-the-box nem támogatja a szolgáltatás, kézzel kell megcsinálni. Fontos, hogy a jelenleg.

Van lehetőség felhasználó azonosításra és jogosultság ellenőrzésre is, bár ezen a területen még várható fejlődés.

Lehet saját szerver oldali kódot adni a szolgáltatáshoz, pontosabban Insert, Update, Delete és Read műveletek esetén lefuthat egy általunk megadott JavaScript függvény, amit a Windows Azure Management Portalra kell bemásolnunk (ne ehhez mit szóltok?). Az adatok szerver oldali validálása is így valósítható meg.

A funkció már mindenki számára elérhető, pontosabban csak azoknak, akik engedélyezik a preview szolgáltatásokat a beállítások között. További információ a Windows Azure honlapon a mobile szekción belül a Tutorials and Resources oldalon érhető el.

 

A Windows Azure Mobile Services nyilván nagyon hasznos lesz azoknak, akik 5 perc alatt akarnak feladatlista alkalmazást készíteni Windows 8-ra. És szerintetek még mire?

 

Technorati-címkék: ,,,