Přejít k navigační liště

Zdroják » PHP » PHP v cloudu III

PHP v cloudu III

Články PHP

Navážeme na předchozí dva díly seriálu a ukážeme si kontinuální nasazení aplikací z GIT do tzv. staging prostředí a přepnutí na produkční prostředí.

Seriál: PHP v cloudu (4 díly)

  1. PHP v cloudu I 13. 6. 2014
  2. PHP v cloudu II 25. 6. 2014
  3. PHP v cloudu III 2. 7. 2014
  4. PHP v cloudu IV 11. 7. 2014

Nálepky:

Jak správně nasazovat aplikaci

Pro bezpečné nasazování aplikací je doporučeno používat tři prostředí.

Vývojářské (dev) – plně pod kontrolou vývojáře, kde si může dělat, co chce a kde testuje a ladí svůj kód.

Předprodukční (staging) – na toto prostředí by neměl mít vývojář přístup a mělo by být 100% identické s produkčním prostředím. Pro toto prostředí vývojář připraví „instalační“ balíček a odpovědná osoba ho jasně daným postupem nasadí. Toto prostředí slouží pro finální testování před nasazením aplikace na produkční prostředí. Je to bariéra pro klasické „výmluvy“ vývojářů, mně to na mém počítači funguje, chyba je u vás.

Produkční prostředí (prod) – ostrý server pro uživatele. Na toto prostředí by se mělo nasazovat pouze z předprodukčního prostředí, a to identickým způsobem, jako se nasazuje na předprodukční prostředí. Pokud máte opravdu produkční a předprodukční prostředí na 100 % identické, stačí pouze změnit síťovou konfiguraci a z předprodukčního tak udělat prostředí produkční. Můžete se potkat s termínem „swap“.

Důvodem tohoto řetězce je zamezit nasazení nefunkční aplikace na produkční prostředí. Nejčastějším problémem při vynechání pře produkčního prostředí není chyba v aplikaci, ale chyba v konfiguraci, chybějící knihovny, špatně nastavené cesty atd.

Vytvoření předprodukčního prostředí

  1. Na záložce DASHBOARD klikněte na Add new deployment slot

     image1

  2. Pojmenujte nové prostředí

    image2 

  3. URL nově vytvořeného prostředí se složí z původního jména, pomlčky a jména „deployment slot“: stepanb-zdrojak-staging.azurewebsites.net

    image3 

Takto vytvořené prostředí je 100% identické jako původní prostředí. Můžete u něj samozřejmě změnit nastavení, nasadit aplikaci, třeba přes FTP, otestovat, a když je vše v pořádku, tak kliknutím na tlačítko SWAP zaměnit produkční a předprodukční prostředí. Záměna je udělána tak, že původní produkční prostředí dokončí obsloužení stávajících požadavků, zatímco nové požadavky jsou již směrovány na nové produkční prostředí. Ve chvíli, kdy jsou staré požadavky obslouženy, se původní produkční prostředí zruší. Uživatel by tedy neměl zaznamenat žádný výpadek.

 image4

Kontinuální nasazení

V každém okamžiku vývoje byste měli mít v předprodukčním prostředí funkční aplikaci v co nejaktuálnější verzi. Pokud udělá vývojář nějakou změnu, tu otestuje na svém prostředí a provedené změny uloží do systému správy zdrojových kódů, tak by se tato změna měla co nejdříve projevit v předprodukčním prostředí, aby se změna mohla okamžitě testovat v rámci celé aplikace. Jak již ale bylo řečeno, vývojář nemá co zasahovat do předprodukčního prostředí. Jak tedy provázat předprodukční prostředí se systémem správy zdrojových kódů? Microsoft Azure Web Sites tuto možnost přímo podporují.

  1. Otevřete vytvořené předprodukční prostředí a klikněte na Set up deployment from source control. Nikdy takto nepropojujte produkční prostředí. Snadno si ho pak můžete rozbít.

     image5

  2. Vyberte si z podporovaných systémů pro správu zdrojových kódů. Jednou z jednoduchých možností je využití Dropbox místo FTP.

     image6

  3. Pokud si vyberete Local Git repository, tak se přímo vytvoří Git repositář ve vašem předprodukčním prostředí.

     image7

  4. Nyní již stačí ve vašem prostředí nastavit přístup k nově vytvořenému Git repositáři.

     image8

  5. Pokud nyní uděláte synchronizaci lokálního repositáře s tím, který máte na Microsoft Azure, tak dojde k automatickému nasazení aplikace.

     image9

     image10

Nezapomínejte na možnost předprodukční prostředí vypínat a zapínat, abyste zbytečně neplatili za dobu, kdy na předprodukčním prostředí nepracujete.

Komentáře

Subscribe
Upozornit na
guest
17 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
zdenekmachek

Nejak stale nemuzu pochopit k cemu je clanek dobry. Cpat PHP na Azure mi prijde jako blbost, proto ze to jde neznamena ze je to dobry napad. Pokud chece clovek PHP v cloudu je rozumne jsi se podivat na AWS, Google App engine, Rackspace cloud nebo neco podobneho co jede na Linuxu.

zdenekmachek

Nemam, ale to je jako PHP na IIS, proboha proc? ;-)

Jirka Kosek

Nevím jak teď, už to nějakou dobu nesleduju, ale svého času bylo PHP+IIS podstatně rychlejší než PHP+Apache.

Karlos

Hlavne podstatne nekonfigurovatelny protoze hledat po internetu binarky php balicku v presne tom kterem biuldu byl mazec.

Karlos

A neexistence 64bit sqlsrv driveru pro php tomu davalo grady. Vergl linej to je (nutno vnimat cely ekosystem – provazani memcache, mongodb apod. wincache taky nestabilni jak prase, APC jsem rozjel jen na polovine serveru – zbytek s uplne stejnym konfigem proste nejel).

Trolda Trolovič

Kdysi jsme měli ve firmě PHP na IIS jelo tam pár webu … spíš se táhlo jak zelené z nosu. Nakonec jsme na stejné železo nahodili BSD jede tam už 20x víc webů a valí to jak z praku. Pokud je potřeba výkon tak widle NE.

Kinkos

S Microsoft Azure mám celkem zásadní problém, aniž bych ho musel přímo zkoušet – je to vidět i bez toho.

Jakou mi dá Microsoft záruku nějaké dlouhodobé stability? Jde o ceny, dostupnost služby, kvalitu a další parametry. Jde mi o to, že tohle je proprietární služba a poskytuje ji jen Microsoft, nikdo jiný.

Když ale budu mít hosting na Apachovi + PHP + MySQL/PostgreSQL, není to proprietární a existuje spousta dodavatelů poskytujících tyto komponenty a taky si můžu zprovoznit totožnou konfiguraci na vlastním železe.

Kinkos

BTW: cloud by měl být o tom, že IT služby jsou něco jako elektřina nebo voda – komodity u kterých můžu změnit dodavatele a nic se neděje (elektrické spotřebiče a vodovodní trubky v domě mi budou fungovat úplně stejně).

Martin Hassman

To je rozhodně pěkné! Ale které cloudy TAKHLE fungují?

Kinkos

Třeba OpenShift – můžete si ho stáhnout (včetně zdrojáků) a provozovat si ho sám nebo si najít jiného provozovatele než RedHat.

Taky se můžete podívat na Cloud Foundry a další. V oblasti IaaS je toho taky dost (OpenStack, Nimbus, Eucaliptus…).

Martin Hassman

Díky. Zajímavé by bylo znát podíl těhle platforem ze všech nasazení cloudů.

ah01

To by mělo jít i pro Azure, viz Windows Azure Pack.

Kinkos

Obávám se, že nešlo. Pod jakou je to licencí?

Vtip je v tom, že když dnes získám licenci Apache, PHP, MySQL, OpenStacku, OpenShiftu atd. tak si ten software můžu provozovat i za dvacet let, nikdo mi ho nemůže vzít, stejně tak ho můžu provozovat na libovolném počtu serverů pro libovolný počet uživatelů, aniž bych se musel někoho doprošovat a dohadovat se sním.

Kinkos

BTW: koukám, že diskuse pokračuje tady: Co pro vás znamená cloud?

Jan Pobořil

Znáte někoho, kdo používá continuous integration PHP appky s Azure?

Kinkos

Neznám nikoho, kdo používá Azure. Ale continuous integration a PHP používá celkem dost lidí. :-)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.