DroidTV MX Android 4.2.2 Dvoujádrový XBMC. Google TV, G-Box Midnight MX2, Apple TV 2,3 generace

Je to aplikace PHP. Jak mohu minimalizovat prostoje při aktualizaci celé databáze?

To, co v práci obecně děláme, je:

  • před aktualizací je kořen dokumentu serveru:
    • v /www/app-2009-09-01
    • ale je přístupný přes symbolický odkaz, tzv /www/application
  • dali jsme celou novou základnu kódu /www/app-2009-09-08
  • jakmile je tam celá kódová základna:
    • odstraníme starý symbolický odkaz
    • vytvoříme nový symbolický odkaz, který se stále nazývá /www/application, ale který poukazuje na nové zdroje: /www/app-2009-09-08
  • znovu načteme apache, abychom vynutili zohlednění úpravy.

Celý tento proces se provádí pomocí automatického skriptu (jedinou neautomatickou věcí je to, že jej v případě potřeby spustíme). To znamená :

  • Všechno jde rychle (zejména přepínání symbolického odkazu, který je důležitou součástí)
  • Žádné riziko chyby: skript byl dobře otestován a funguje měsíce / roky


Další výhodou této priority symbolických odkazů je, že je velmi snadné „vrátit“ aktualizaci, pokud si všimneme katastrofické chyby až po uvedení nové verze zdrojů do výroby: stačí přepnout symbolické odkazy zpět.

To vám samozřejmě nezabrání otestovat novou verzi na pracovním serveru před uvedením do výroby - ale kdoví ... Někdy je tu opravdu velká chyba, kterou nikdo nemohl vidět, zatímco testování :-(
Například proto, že na pracovním počítači není pravidelně prováděno žádné testování zátěže.
(Viděl jsem, že věc „rollback“ použila něco jako 4 nebo 5krát za 3 roky - pokaždé to zachránilo den - a webové stránky ^ ^)


Zde je nějaký rychlý příklad: Předpokládejme, že mám tento VirtualHost v mé konfiguraci Apache:

 ServerName example.com DocumentRoot /www/application  # Whatever you might need here (this example is copy-pasted from a test server and test application ^^ ) Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch AllowOverride All php_value error_reporting 6135 php_value short_open_tag on   

Docela „standardní“ ... Jediná věc je /www/application není skutečný adresář: je ​​to jen symbolický odkaz na aktuální verzi zdrojů.
Což znamená, že když zdroj umístíte na server, ale ještě jste jej nepřepnuli, budete mít něco jako toto:

[email protected]:/www # ll total 8 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08 lrwxrwxrwx 1 root root 19 2009-09-08 22:08 application -> /www/app-2009-09-01 

Všimněte si, že symlinc ukazuje na „starou verzi“

Nyní, když byla nová verze zcela nahrána na server, přepneme:

[email protected]:/www # rm /www/application [email protected]:/www # ln -s /www/app-2009-09-08 /www/application 

A teď /www/application poukazuje na novou verzi zdrojů:

[email protected]:/www # ll total 8 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08 lrwxrwxrwx 1 root root 19 2009-09-08 22:09 application -> /www/app-2009-09-08 

A musíme restartovat Apache:

[email protected]:/www # /etc/init.d/apache2 restart * Restarting web server apache2 

Tři kroky “odstranit odkaz; vytvořit nový odkaz; restartujte Apache„by mělo být provedeno rychle, tj. automatizovaným skriptem, nikoli člověkem.

Pomocí tohoto řešení:

  • můžete si vzít tolik času, kolik potřebujete nahrát novou verzi zdrojů: apache je nebude používat, dokud nebude změněn symlic
  • když je vše v pořádku, jednoduše přepněte symbolický odkaz: půjde to rychleji než změnit i 1 nebo 2 soubory ... Což znamená prakticky žádné prostoje :-)

A pokud používáte nějakou opcode-cache jako APC s možností stat na 0, může to znamenat ještě menší riziko prostojů, předpokládám.


Samozřejmě se jedná o „jednoduchou“ verzi - pokud máte například nějaké nahrané soubory, budete muset někde použít jiný symbolický odkaz nebo jiný VirtualHost nebo cokoli jiného ...


Doufám, že je to jasnější :-)

  • Je to také druh výměny serverů. :-)
  • mod_rewrite pro správu symbolických odkazů?
  • @gAMBOOKa: no: jen otázka Apache's DocumentRoot (nebo VirtualHost DocumentRoot), což je / www / application ;; tj. symbolický odkaz - bez ohledu na to, kam směřuje.
  • 2 Úžasná odpověď. Ještě jeden tip: můžete vytvořit symbolický odkaz, aniž byste jej odpojili. Citováno: „Tyto tři kroky… by měly být provedeny rychle; tj. Automatizovaným skriptem, nikoli člověkem.“ Příkaz mv je atomová operace, takže můžete vytvořit symbolický odkaz jako 'ln -s / www / app-2011-01-28 / www / application-temp' a poté udělat 'mv -T / www / application-temp / www / aplikace '.
  • 1 Existuje něco, co metoda symlink nepokryla. Vaše cesta funguje s Apache + mod_php, ale na lighttpd + fastcgi by to mohlo selhat. Na webu s vysokým provozem bude požadavek doručen uprostřed výměny odkazu, že závislost php kódu selže u smíšené verze.

Nemůžete převzít stávající kód a migrovat projekt do samostatného testovacího souboru php a použít ho při provádění aktualizací? Mám na mysli, že byste měli mít testovací server a produkční server, takže když budete muset provést aktualizaci, nevzniknou vám žádné prostoje.

Nastavte druhý server s aktualizovanou základnou kódů a přepněte je co nejrychleji. :-)

Pokud to není možné, ujistěte se, že je vaše základna kódu rozdělena na desítky menších částí. Pak by prostoje byly omezeny pouze na jednu podčást. Menší kódové bloky se snadněji vyměňují a většina z nich bude i nadále fungovat bez problémů. Nejprve to však vyzkoušejte na testovacím prostředí!

  • Protože aplikace nebyla testována s fragmentovanými moduly, může to mít za následek neočekávané scénáře.
  • Což znamená, že by to bylo na vašem seznamu úkolů po této aktualizaci. :-) Udělejte to více modulární a můžete aktualizovat každý modul.
  • 1 To je na seznamu úkolů, ale je to dlouhodobý cíl. Jsme mladý startup, takže organizace v týmu vývojářů bude přirozeně chvíli trvat. = D

Nejprve často používám metodu podobnou reakci Pascala MARTINA.

Další metodou, která se mi také líbí, je použití mého SCM k zasunutí nového kódu. Přesný proces závisí na vašem typu SCM (git vs svn vs ...). Pokud používáte svn, rád bych vytvořil „online“ nebo „produkční“ větev, kterou pokladnu jako kořen dokumentu na serveru. Pak, kdykoli chci vložit nový kód z jiné větve / značky / kufru, stačí nový kód zavázat do větve „online“ a spustit aktualizaci svn v kořenovém adresáři dokumentu. To umožňuje velmi snadné vrácení zpět, protože existuje kompletní protokol revizí o tom, co se na serveru dělo nahoru / dolů a kdo a kdy to udělal. Tuto „online“ větev můžete také snadno spustit na testovacím boxu, což vám umožní prověřit aplikaci, kterou se chystáte odeslat.

Proces je podobný pro git a další styly SCM, pouze upravené, aby byly přirozenější pro jejich styl pracovního toku.

Chcete stahovat / hlasovat místo toho, abyste tlačili aktualizace? Stačí mít úlohu cron nebo jiný, chytřejší mechanismus automaticky spustí aktualizaci svn.

Další: Tento proces můžete také použít k zálohování souborů, které vaše aplikace zapsala na disk. Stačí mít úlohu cron nebo nějaký jiný mechanismus spustit svn commit. Nyní jsou soubory, které vytvořila vaše aplikace, zálohovány ve vašem SCM, zaznamenány revize atd. (Např. Pokud uživatel aktualizuje soubor na disku, ale chce, abyste jej vrátili, stačí poslat starou revizi).

Podobně používám i přístup Pascala MARTINA. Ale místo nahrání více verzí mé aplikace na produkční server ponechávám „sestavení“ za bránou firewall, každý v samostatném adresáři s číslem a datem sestavení. Když chci nahrát novou verzi, použiji jednoduchý skript, který obsahuje „rsync -avh --delay-updates“. Příznak „delay = updates“ nahraje vše (to je jiné) do dočasné složky, dokud tam nebudou všechny aktualizace, a poté na konci přenosu vše přesune najednou na své správné cesty, takže aplikace nikdy nebude v napůl starý napůl nový stát. Má stejný účinek jako výše uvedená metoda, kromě toho, že na produkčním webu chovám pouze jednu verzi aplikace (nejlepší je mít na produkčním serveru IMO pouze holé základní soubory).

Pracoval pro vás: Charles Robertson | Chcete nás kontaktovat?