it-swarm-eu.dev

Nasazení kódu na více front-end serverů

Máme situaci, kdy máme více vyrovnaných zátěží serverů směřujících do společné databáze.

V běžném běhu věcí to funguje dobře a dává to nadbytečnost, škálovatelnost atd.

Zjišťujeme však, že nasazení je trochu fuška.

Používáme funkce značně a pokoušíme se automatizovat nasazení. Nasazení v tuto chvíli není příliš spolehlivé.

Ve zjednodušené podobě má implementační skript pro každý server dvě fáze

  1. Aktualizujte soubory

  2. Vrátit funkce (které budou spravovat závislosti, změny nastavení atd.)

Existují nějaké osvědčené postupy pro nasazení na více serverech, aniž by byly v nekonzistentním stavu?

Pokud vidím, zda nasadíte kroky 1 a 2 na server A, způsobí to rozbití serveru B, pokud zkusíte krok jeden na obou serverech před pokračováním ke kroku 2, oba budou chvíli přerušeny.

9
Jeremy French

Pravděpodobně byste se měli podívat na Aegir , což je zdaleka nejflexibilnější a nejvýkonnější Drupal systém pro správu/nasazení webu. Je schopen spravovat „platformy“, které pokrývají akry více webových hlav nebo „shluků“, jakož i celou řadu dalších konfigurací.

Navrhoval bych si přečíst jejich komunitní dokumentaci což je obecně docela dobré, stejně jako přečíst mig5 je vynikající přehled a úvodní článek a některé z jeho dalších článků jako tento .

Dobrou podporu můžete získat také na kanálu #aegir IRC).

Bude to trochu změna pracovního postupu, což vám určitě může nějakou dobu trvat, než se rozjedete, ale jakmile tam budete, nebudete se ohlédnout.

6
Tom Kirkpatrick

V naší společnosti udržujeme spoustu Drupal webů), naše aktuální nastavení vypadá takto:

  • Codebase každého webu má vlastní repetici git
  • Nové funkce, které pravděpodobně nebudou dostatečně stabilní pro příští vydání, získají svou vlastní větev funkcí v gitu

Výše uvedené bych řekl, že je docela běžné pro většinu Drupal stránek).

V naší společnosti děláme speciální debian balíček pro nasazení pomocí vlastního příkazu drush - ' Drush Debian Packaging '.

Drush Debian Packaging poskytuje příkaz Drush pro vytváření balíčků Debian na Drupal sites) jako prostředek rozmístění Drupal sites na servery Debian nebo Ubuntu).

Drush Debian Packaging využívá systém Drupal hooks) k vytvoření balíčku Debian, který nejlépe vyhovuje vašim potřebám.

  • Automatická konfigurace virtuálního hostitele pro webové servery Apache2 a Nginx
  • Nastavení Cronu v /etc/cron.d
  • Automatické nasazení kódu s rozdělení oddílů pro weby/výchozí/soubory
  • Automatická konfigurace pomocí nástroje pro nastavení debconf dpkg
  • Proces automatizovaného nasazení
  • vlastní obsluha Git VCS pro vytváření balíčků od společnosti Git

Co to znamená?

Vytvoření vydání:

cd /path/to/drupal-root
drush dh-make

Chcete-li implementovat vydání, nejprve SCP .deb na všechny webové servery v klastru. Poté na všech webových serverech spusťte (můžete použít balíček linux cssh k zadání příkazu na všechny servery ve farmě současně):

Sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Na jednom spuštěném webovém serveru:

cd /path/to/drupal-root
Sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Hotovo

Samozřejmě, že je to z pohledu kódové základny triviální, stačí nainstalovat předchozí verzi .deb na všechny webové servery a vrátit databázi.

Rádi zodpovíme všechny dotazy týkající se tohoto

4
wiifm

Která část procesu nasazení je fuška/nespolehlivá?

Pokud se jedná o problém „aktualizační server A pak B/nekonzistence“, co uvedení stránky údržby po dobu trvání vašich zásahů? Údržba stránky nahoru, aktualizace kódu na obou webových hlavách, spusťte update.php na jedné z nich, stránka údržby dolů. To je docela snadno skriptovatelné.

Další možnost: v závislosti na druhu webu, který provozujete, můžete vytvořit „režim jen pro čtení“, který bude kopat všechny uživatele offline a deaktivovat přihlášení/registraci. Klonujte vaši DB do druhé DB ve stejném db boxu, naklonujte váš front-end do nového docrootu, proveďte tam aktualizace, pak docmotujte Apache do nového front-endu. Pracovní postup je něco jako:

  1. Režim jen pro čtení je zapnutý
  2. VYBRAT aktuální_db INTO new_db
  3. cp -R current_docroot new_docroot
  4. new.yourdomain.com ==>/new_docroot
  5. aktualizujte kód na new_docroot
  6. update.php
  7. symlink/new_docroot ==> aktuální_docroot
  8. Režim jen pro čtení je vypnutý.
3
Entendu

Bude to záležet na změnách, které provádíte, jak navrhuje Entendu. Jaký podíl aktualizací kódu lze spustit, aniž by došlo k chybám, pokud databáze dosud není aktualizována? U všeho, co nezávisí na aktualizacích databáze (a možná můžete trochu změnit vývojový proces, aby to bylo běžnější), není nic zvláštního. Předpokládám, že chcete provádět nasazení s minimálními prostoji, jinak by to jen vyžadovalo některé základní operace synchronizace. V tomto případě bude vždy nějaký časový úsek s nežádoucími účinky (i když je to pouze s webem v režimu jen pro čtení), ale myslím, že by to mohlo být po většinu času docela malé.

Můžete provést základní optimalizaci, jako je nastavení "nového" adresáře na každém serveru v předstihu a pak je přepnout na všechny body, aby ukazovaly na nový adresář ve stejnou dobu (například pomocí symbolických odkazů jako v odpovědi Entendu), abyste mohli získat všechny servery se přepnuly ​​na nové soubory během 5-10 sekund.

To ponechává problém s aktualizací databáze. Pokud se jedná o ten typ, který je třeba provést pouze z jednoho serveru, možná budete chtít uvést ostatní do režimu údržby nebo upravit vyvažovač zatížení tak, aby je nepoužívali, když k tomu dojde. Samozřejmě, pokud je nelze provést, když jsou uživatelé aktivní na webu, musíte mít vše v režimu údržby, ale pro jednoduché aktualizace to může být něco, co můžete udělat asi za 30 sekund nebo méně.

Může být vhodné mít různé skripty nasazení pro různé typy změn, takže můžete spustit potřebný minimální proces, ať už jde pouze o kopírování souborů, spuštění malé aktualizace databáze, nebo o významnou změnu databáze.

Pokud můžete optimalizovat aktualizace souborů a databází a podívat se na to, zda existují jednoduché změny ve způsobu vývoje věcí, které by vás mohly přiblížit, ale nevím, zda je pro vás něco nového :)

2
richardg

Aegir je užitečná správa sítě webů. Použil jsem jej k nasazení a správě více než 2000 webů pro jednoho klienta.

Vaše otázka naznačuje, že chcete spravovat jeden web s více hlavami webů. V takovém případě může být pro vás Aegir méně užitečný. Místo toho bych vám doporučil podívat se na souborový systém, který podporuje síťování. Nejen, že to zajistí, že váš kód bude udržován synchronizován, což znamená, že vaše nahrání jsou k dispozici na všech uzlech.

V minulosti lidé používali NFS, který umožňuje sdílení systému souborů jednoho serveru s ostatními uzly. Bohužel to představuje jediný bod selhání, protože pokud se server NFS zamkne nebo zemře, váš web nebude možné zobrazit.

Pokud jste ochotni kompromitovat malý výkon ve prospěch spolehlivějšího serveru, doporučuji GlusterFS . Použil jsem v několika produkčních prostředích. Není to dokonalé, ale je lepší než NFS. Gluster umožňuje webheadu vždy číst lokálně a zápisy jsou pak replikovány do ostatních uzlů.

Pokud jde o vaši strategii nasazení, měli byste mít jako první nástroj na svém seznamu drush . S drush byste měli být schopni automatizovat kroky vašeho nasazení. Měli byste zvážit přidání Jenkins do mixu, abyste mohli sledovat své úlohy nasazení a identifikovat vzory, pokud se věci nezdaří. Capistrano může být užitečný pro automatizaci kroků zapojených do nasazení. Pokud děláte věci správně, můžete to udělat, aby vaši uživatelé nikdy nevěděli, že jste provedli nasazení.

0
skwashd