PHP v cloudu II

Posledně jsme si v úvodním dílu seriálu představili konkrétní situace, kdy je vhodné hostovat aplikace v cloudu a jaké nám to přináší výhody. Dnešní díl bude již více praktický, budeme se totiž věnovat nasazení vlastní PHP aplikace do prostředí Microsoft Azure.
Seriál: PHP v cloudu (4 díly)
- PHP v cloudu I 13. 6. 2014
- PHP v cloudu II 25. 6. 2014
- PHP v cloudu III 2. 7. 2014
- PHP v cloudu IV 11. 7. 2014
Posledně jsme si v úvodním dílu seriálu představili konkrétní situace, kdy je vhodné hostovat aplikace v cloudu a jaké nám to přináší výhody. Dnešní díl bude již více praktický, budeme se totiž věnovat nasazení vlastní PHP aplikace do prostředí Microsoft Azure (jak získat zkušební verzi Microsoft Azure na měsíc zdarma, najdete na konci prvního dílu). Využijeme k tomu službu Microsoft Azure Web Sites a zaměříme se zejména na konfiguraci prostředí pro vysokou dostupnost.
Vytvoření prostoru pro web aplikaci
V prvním kroku si připravíme prostor pro nasazení PHP web aplikace.
- Přihlaste se do administračního portálu.
- Otevřete záložku Web Sites.
- V levém dolním rohu klikněte na NEW.
- Pokud byste zvolili FROM GALLERY, tak si můžete vybrat z mnoha předpřipravených aplikací, které můžete automaticky nasadit a používat. Nás zajímá volba QUICK CREATE, která vytvoří prázdný prostor pro aplikaci.
- URL aplikace je asi jasné. Aplikace se nejdříve nasadí na doménu třetí úrovně, které pak můžete nastavit doménu druhé úrovně. Pole WEB HOSTING PLAN vám umožňuje sdružovat Web Sites z hlediska nastavení. V poli REGION vyberete datové centrum, kam chcete aplikaci nasadit. Po chvilce máte prostor připravený.
- Kliknutím na jméno Web Sites se dostanete do konfigurace.
Základní konfigurace
Zatím nás bude zajímat jen záložka CONFIGURE. Na této záložce si vyberete verzi PHP a můžete zapnout různé typy logování chyb na serveru. Některé vlastnosti jsou dostupné pouze pro placené varianty Web Sites.
Při prvním vytvoření běží aplikace v režimu Free, který má celou řadu omezení, ale pro první testy a seznámení s platformou stačí. Pro ostrý provoz bude třeba aplikaci přepnout do režimu SHARED, BASIC nebo STANDARD. To se dělá na záložce SCALE.
Jednotlivé režimy mají opět různé vlastnosti. Nejzásadnější rozdíl je, jestli máte pro svou aplikaci vyhrazený vlastní virtuální stroj nebo ho s někým sdílíte. Podle toho se samozřejmě odvíjí i cena.
Změna výchozí konfigurace PHP
Pokud potřebujete změnit výchozí konfiguraci PHP, tak stačí do kořenového adresáře aplikace přidat soubor .user.ini
a v něm nastavit nové hodnoty.
Aplikace může také využívat i další rozšíření, která nejsou součástí výchozí konfigurace.
- Vytvořte adresář bin v kořenovém adresáři aplikace.
- Do adresáře nahrajte rozšíření. Tato rozšíření musí být VC9 a non-thread-safe (nts).
- Seznam rozšíření je třeba přidat do konfigurace (záložka CONFIGURE). Jednotlivá rozšíření se oddělují čárkou.
Nasazení aplikace
Na záložce DASBOARD najdete vše potřebné pro nasazení aplikace. To nejjednodušší je využití FTP. V dalším díle si ukážeme propojení s GIT pro kontinuální nasazení.
Vlastní aplikace se pak nahraje do adresáře /site/wwwroot.
Nyní již stačí zkopírovat vaši aplikaci. Podívejte se na výpis phpinfo().
Nastavení scénářů očekávaná a neočekávaná zátěž
Zatím jste neviděli nic, co by se nějak významně lišilo od běžného hostingu, tedy kromě poskytované bezpečnosti a dostupnosti vyplývající z nasazení aplikace do skutečného cloudu.
Tím, že při automatickém škálování dochází k přidávání a ubírání instancí webové aplikace, tak nic nesmíte ukládat přímo v instanci, např. na lokální disk. Za pár okamžiků už konkrétní instance vaší aplikace nemusí existovat a o data přijdete. Server, který zajišťuje load balancing, je totálně „hloupý“ a vůbec neřeší, aby požadavky jednoho klienta chodily na stále stejnou instanci. Nezapomínejte na to!
Pokud potřebujete aplikaci automaticky škálovat, ať už v závislosti na vytížení CPU nebo čase, vše potřebné najdete na záložce SCALE.
- Přepněte Web Site do režimu STANDARD.
- Vyberte si požadovanou INSTANCE SIZE, výkon serveru, na kterém poběží vaše Web Site.
- Automatické škálování se nastavuje na základě vytížení CPU. Pokud zátěž CPU přesáhne horní hranici, tak se přidá další instance, pokud klesne pod dolní hranici, tak se jedna instance odebere. Minimální a maximální počet instancí nastavujete volbou INSTANT COUNT.
Zálohování
Na záložce BACKUP můžete nastavit automatické zálohování aplikace.
Zálohování můžete provést taky ručně, a to kliknutím na BACKUP NOW v dolní části. Po kliknutí na tlačítko RESTORE NOW si můžete vybrat verzi, ke které se chcete vrátit.
Obnovení ze zálohy můžete udělat do aktuální instance nebo do nové instance s jiným doménovým jménem, abyste nenarušili produkční prostředí. Využívá se tady tzv. staging prostředí, ale o tom až v dalším díle.
Ale uplně nechápu k čemu php cloud slouží, úzké hrdlo aplikace bývá na 99% v batabázi a tu mi je php cloud naprosto k ničemu, ba naopak pokud použiju na cachování apc, tak to cloud totálně odvaří, takže se bude muset použít memcache(d) podle toho kdo co rád, a počítám že to bude za příplatek.
Sorry php neni java abych kvůli pár uživatelům potřeboval hromadu ram a procesorů a pokud to tak někdo má měl by se dosti zamyslet nad tím co napsal.
O databázích, resp. datových úložištích, bude ve čtvrtém dílu.
budu se tesit
Jak je to třeba se Session? Plati stejná omezeni jako v případě ukládání na lokální disk?
Tipoval bych že z důvodu těch více instancí bude nutné držet SESSION v nějakém jiném uložišti než na disku. Asi pouze databáze?
Jak píše pifilis. Session je třeba držet v nějakém perzistentním úložišti – databáze nebo Azure Storage. O těchto úložištích bude čtvrtý díl seriálu.
Ty sessions by to chtělo více rozvést. Pokud Azure Storage neumí adresáře, pak se těžko nastaví php session dir.
Navíc by bylo hezké vědět, zda Azure umí sticky sessions, tj. zda již vytvořenou session směruje na tentýž backend server, kde byla session vytvořena. To by se hodilo, kdybychom si chtěli držet něco navíc v memcache.
Provozovat PHP na Windows (IIS)? v ostrem provozu je zhovadilost.
Chcete-li PHP v cloudu pouzijte AWS nebo Google App engine.
Přesně tak, vůbec nechápu proč tu neni seriál například o AWS. Bylo by to mnohem přínosnější. Nevidim jedinej důvod proč hostovat PHP ve windows cloudu. Fakt ne.
Proč tu není seriál o AWS říkáte? Důvod tu je. Ale nechám vás hádat. 8-)
Mohl byste trochu rozvést co myslíte tím:
nějak si nedokáži představit tu bezpečnost a ten skutečný cloud, stačí mi i odkazy
Bezpečnost: http://azure.microsoft.com/en-us/support/trust-center/compliance/
Skutečný cloud – podívejte se na můj první článek, jak by se měl cloud chovat, např. během výpadku jednoho datového centra nebo jeho části
Zvláštní je, že ereg v PHP je deprecated od verze 5.3.0, ale v phpinfo s verzí 5.4.23 modul existuje. Microsoft magic? :-)
Funkci označenou jako „deprecated“ je doporučeno nepoužívat, protože bude v budoucnu odstraněna. Taková funkce typicky přežívá ještě několik verzí kvůli zpětné kompatibilitě a souběžně se připravuje její náhrada, aby byl čas upravit existující aplikace.
Jako sorry, ale doporucovat nekomu PHP na widlich? No hezky takovy clovek jednou podekuje.
Azure je pomala sracka kde PHP poradne nefunguje. Zkuste napsat http://mojestranka.cz/ěščřžýá co vam IIS to posle do PHP. Ale je mozny ze uz to spravili. Ale jako PR to tady asi plni svuj ucel.
Muzete prosim popsat konkretni technicke problemy, s kterymi jste se potkal pri behu PHP na Microsft Azure? Zejmena vykonostni problemy, o kterych pisete.
Drupal 7. Zakladni instalace – prumerny pageload 5-10 sekund. Pak zapnout modul Path, vytvorit node a dat mu v URL aliasu ceskou diakritiku. IIS+PHP udela papa – illegal character set. To mixovani ruznych kodovani jsem testoval na vice strojich s IIS 7.5 asi pred rokem a vsude to padalo, staci si debugova promennou $_SERVER a je tam videt, jak to mrvi. Tu pomalost jsem mozna jen chytl pretizeny server, kdo vi, ale nikde jinde krom wedosu jsem to nevidel jet tak pomalu.
http://stepanb-drupal.azurewebsites.net/
Nemyslím si, že by to bylo pomalé a to používám sdílenou instanci. Jede to na MS SQL a http://stepanb-drupal.azurewebsites.net/čřžřýžýáý server nijak neovlivní.
muzes tam jeste udelat nejaky skutecny node ktery bude mit url prave takhle s diakritikou?