18 komentářů k článku Deploy PHP aplikací, bez výpadku a pod (velkou) zátěží:

  1. MichalKleiner

    Diky za pekne shrnuti. Jsem rad, ze takrka stejny system pouzivame pro deploy nasich aplikaci. Stale ale pouzivame Apache. Zmenu symlinku provadime atomicky presne jak je uvedeno v clanku, coz funguje na Debianu nebo podobnych Linux distribucich (stejneho chovani nelze dosahnout na MACu – pri vyvoji nastroje pro deploy me to trochu matlo, samozrejme pro produkci mac nepouzivame).

    O kompletnim prechodu na nginx uvazujeme stale intenzivneji, musime ale podporovat i .htaccess pro starsi weby, nekde jsou desitky pravidel. Vi nekdo o ceste, jak .htaccess pravidla prelozit nebo zprovoznit pro nginx, treba pres nejakou proxy nebo wrapper? Pouzivame treba mod_proxy pravidla pro nacteni obsahu z jine url bez presmerovani. Diky za pripadne tipy.

    1. karel

      Re:
      zkusenost prechodu z apache na nginx, prave kvuli htaccess byl prvni zpusob prechodu takovy napul nginx sem pouzival jako revers proxy pro apache kde bezela aplikace, ale staticka data uz serviroval nginx.
      postupem casu jsem upravil pravidla z htaccess na pravidla v nginxu a php zpustil pres php-fpm a zabavil se apache uplne.
      jinak revers proxy je v nginxu v zakladu vcetne pekne fungujicich cachy, pozot pro ty co by to ladili na windows nevim jak ted ale jeste donedavna cachovani na win moc dobre nejelo.

    2. Luk83

      Re:
      Spíš bych uvažoval o přepisu pravidel do configu Nginx a použít moduly přímo vyvynuté pro něj. I když se to může zdát jako složitější jednorázový řešení a něco jako wrapper pro moduly apache by existovalo (to nevim a silně pochybuju) tak se do budoucna vyvaruješ nekompatibility při upgradu sw, což by ve finále vyšlo mnohem dráž.

      Jinak po menšim googlování jsem našel minimálně jeden converter pro rewrite pravidla.

      http://www.usethefuckinggoogle.com/?q=nginx+htaccess

      1. David Kudera

        Re:
        Některé ty převodníky jsem zkoušel, ale u jen trošku složitějších pravidel už to nefungovalo. Nakonec bylo fakt lepší dát si trochu času s ručním přepsáním pro nginx

        1. Jakub TrmotaAutor příspěvku

          Re:
          Souhlasím s vámi, při přechodu na nginx jsme také pár převodníku vyzkoušeli (alespoň pro inspiraci to nebylo špatné), ale nakonec jsme to přepsali celé ručně.

          Přechod na nginx mohu z naší zkušenosti vřele doporučit. U nás už Apache neběží nikde a zatím se nám nestýská :-)

    1. Jakub TrmotaAutor příspěvku

      Re:
      Myslíte něco takového, kdy mám load balancer, vyřádím z něj jeden webový server, nasadím na něj novou verzi aplikace, server vrátím a toto opakuji pro všechny webové servery? Pokud ano, uznávám, že je to asi čistší řešení než webovému serveru pod rukama měnit symlink, ale teď mě nenapadá jediná věc, kterou to řeší navíc oproti nasazování popsaném v článku a přijde mi to složitější na implementaci.

      1. alesroubicek

        Re:
        Ne. :) Myslím takové řešení, kdy mi na jednom nodu běží dva virtuální servery, jeden se starou verzí, druhej s novou a v reverzní proxy změním nasměrování na port nového serveru. Samozřejmě je potřeba mít synchronizované sessions. Krom reverzní proxy se nic jiného nemění, jen se vytváří nové weby a staré následně mažou. Umožňuje to i snadný rollback v případě zjištěných kritických defektů v produkci.

  2. Luk83

    Ve finále, to že Nette nemá odlazený a jednoduchý deployovací nástroje mě nepřekvapuje. Pro Symfony je tu klon Capistrana známý jako Capifony s jednoduchým configem nebo konkrétně teď používáme Webistrano. Tam očekávám, že podobný probs vyřešila o dost větší komunita a nebudu hodiny a dny řešit byť minimální výpadek přehozením symlinků. Oba zmíněné nástroje používají stejný mechanizmus.

    1. Jakub TrmotaAutor příspěvku

      Re:
      Capistrano mi už někdo zmiňoval, zatím jsem na to koukal jen tak zběžně, ale určitě až bude čas, tak se na to podívám pořádně.

      1. Oldřich Vetešník

        Re:
        Otázka je, jestli Capistrano řeší něco navíc a jestli to má cenu. Plus musíte mít všude Ruby (na serverech i na klientech), což je někdy, é, lehce problematické. Mně je sympatický „git push production“ s hooky jako má Heroku, ale zatím jsem to nezkoušel nastavovat u sebe, tak nevím, jak je to náročné.

        1. Jakub TrmotaAutor příspěvku

          Re:
          Deploy přes GIT používám na některých svých menších projektech. Je to fajn a „stačí to“, ale přiznám se, že na větší projekt bych to asi nepoužil.

  3. tomaspolz

    Neni lepsi CI ?
    To o čem tu píšete mi ani jako deploy metoda nepripadá. Osobne si pod tim predstavuji neco sofistikovanejsiho.

    My napřiklad na jednom projektu v praci pouzivame pro deplay aplikace CI nastroj Jenkins od Jetbrains.
    Mame specialni deploy server, ktery is z svn stahne produkcni vetvi a pomoci rsync nahraje data na konrektni nody.
    Dale umi nahat DB patche, minifikovat CSS a JS? vytvorit konfiguracni skripty dle prostredi, provadet ruzne testy atd. To vse na jedno kliknuti, pokud si date praci s uvodnim nastavenim.

    Rozhodne bych vyuzitit CI nastroje doporucil kvli siroke skale moznych tasku, které v ramci buildu muze vykonat .

    Jakym zpusobem resite databazove patche, testovani apod ?

    1. Jakub TrmotaAutor příspěvku

      Re: Neni lepsi CI ?
      V článku jsem popisoval pouze samotný deploy aplikace na webový server. Ve skutečnosti je samozřejmě celý proces zbuildění aplikace a její následné nasazení o něco složitější.

      Pro automatizování testování, tvorbu buildů a nasazování používáme také Jenkins CI (jenom upřesním, není od firmy Jetbrains, ta má svůj vlastní CI server TeamCity). Máme všechno nastaveno ne na jedno, ale dvě kliknutí :-) Jedno vytvoří build (z GITu) – ze kterého vzniknou dva balíky – jeden se samotnou aplikací a druhý s assety (ty se při tvorbě buildu minifikují a spojují dle potřeby). Konkrétní build pak na druhé kliknutí můžeme nasadit na test/produkci. Balík s aplikací se rozdistribuuje na všechny webové servery a nasadí bez výpadku služeb pomocí metody, kterou zjednodušeně popisuji ve článku. Balík s assety se nasadí na zvláštní server.

      Databázové změny děláme zpětně kompatibilní, ale nějaké udělátko na jejich automatické nasazování zatím nemáme.

      1. tomaspolz

        Re: Neni lepsi CI ?
        Díky za odpoved.
        Mate pravdu, s tím JetBrainsem jsem se spletl. Uvazujeme o TeamCity pro deploy ostatnich projektu, tak proto ta zamena :)

  4. Jan Forman

    htaccess
    .htaccess a i ty symlinky jsou zásadní brzda, už jen proto, že server musí vyhledat všechny soubory v cestě.
    v případě symlinku to pořád probíhá stylem sáhnu na symlink, sáhnu na soubor.
    .htaccess tam je to zase stylem: sáhnu na jeden soubor a on načte dalších třeba pět v cestě (i když tam nejsou musí je zkusit).

    Je to prostě 2x a víckrát pomalejší, ale poznat to jde jen na opravdu zatíženém systému – dochází mu zdroje.
    A další CPU ani RAM mu už tak moc nepomůžou… místo aby otevřel třeba 10tisíc souborů musí jich otevřít třeba 50tisíc najednou.

    NGINX se snaží otevírat co nejméně souborů a používat co nejméně paměti. Tam kde Apache sežere 8GB RAM a začne tuhnout, NGINX v pohodě používá klidně 512MB RAM a ani nehne brvou.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=12801