Wdrażanie kodu na wielu serwerach frontonu

Mamy sytuację, w której mamy wiele serwerów z równoważeniem obciążenia wskazujących na wspólną bazę danych.

W normalnym biegu rzeczy działa to dobrze i zapewnia redundancję, skalowalność itp.

Jednak uważamy, że wdrożenie jest trochę uciążliwe.

Szeroko korzystamy z funkcji i staramy się zautomatyzować wdrażanie. W tej chwili wdrożenie nie jest bardzo niezawodne.

W uproszczonej formie skrypt wdrażania dla każdego serwera ma dwa etapy

1. Zaktualizuj pliki

2. Przywróć funkcje (które będą zarządzać zależnościami, zmianami ustawień itp.)

Czy są jakieś sprawdzone metody wdrażania na wielu serwerach bez powodowania niespójności?

O ile widzę, jeśli wdrożysz kroki 1 i 2 na serwerze A, spowoduje to uszkodzenie serwera B, jeśli spróbujesz wykonać krok pierwszy na obu serwerach przed przejściem do kroku 2, oba zostaną na chwilę zepsute.

Prawdopodobnie powinieneś przyjrzeć się Aegir , który jest zdecydowanie najbardziej elastycznym i wydajnym systemem zarządzania / wdrażania Drupal. Jest w stanie zarządzać „platformami” obejmującymi wiele głowic internetowych lub „klastrów”, a także wiele innych konfiguracji.

Sugeruję przeczytanie ich dokumentacji społeczności, która jest na ogół całkiem dobra, a także przeczytanie doskonałego przeglądu mig5 i artykułu wprowadzającego oraz niektórych innych jego artykułów, takich jak ten .

Możesz również uzyskać dobre wsparcie na kanale IRC #aegir.

Będzie to trochę zmiana przepływu pracy, która zdecydowanie może zająć trochę czasu, ale kiedy już tam będziesz, nie będziesz oglądać się za siebie.

W naszej firmie utrzymujemy DUŻO witryn Drupal, nasza obecna konfiguracja wygląda mniej więcej tak:

• Baza kodów każdej witryny ma swoje własne repozytorium git
• Nowe funkcje, które prawdopodobnie nie będą wystarczająco stabilne w następnej wersji, mają własną gałąź funkcji w git

Powyższe powiedziałbym, że jest dość powszechne w większości witryn Drupal.

W naszej firmie specjalizujemy się w tym, aby debian pakował witryny do wdrożenia przy użyciu niestandardowego polecenia drush - „ Drush Debian Packaging ”.

Drush Debian Packaging udostępnia komendę Drush do budowania pakietów Debiana stron Drupal jako sposób wdrażania stron Drupal na serwerach Debian lub Ubuntu.

Drush Debian Packaging korzysta z systemu haków Drupal, aby zbudować pakiet Debian, który najlepiej odpowiada Twoim potrzebom. Dodatki zawarte:

• Automatyczna konfiguracja wirtualnego hosta dla serwerów Apache2 i Nginx
• Konfiguracja Crona w /etc/cron.d
• Zautomatyzowane wdrażanie kodu z podziałem partycji dla witryn / domyślnych / plików
• Zautomatyzowana konfiguracja za pomocą narzędzia ustawień debconf dpkg
• Zautomatyzowany proces wdrażania
• niestandardowa procedura obsługi Git VCS do budowania pakietów z Git

Co to znaczy?

Aby zbudować wersję:

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

Aby wdrożyć wersję, najpierw SCP .deb na wszystkich serwerach internetowych w klastrze. Następnie uruchom wszystkie serwery WWW (możesz użyć pakietu linux cssh, aby wpisać polecenie na wszystkich serwerach w farmie w tym samym czasie):

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

Na jednym serwerze WWW uruchom:

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

Gotowy

Oczywiście wycofanie tego jest teraz banalne z punktu widzenia bazy kodu, wystarczy zainstalować poprzednią wersję .deb na wszystkich serwerach WWW i przywrócić bazę danych.

Z przyjemnością odpowiem na wszelkie pytania na ten temat

Która część procesu wdrażania jest uciążliwa / zawodna?

Jeśli jest to problem z serwerem aktualizacji A, a następnie B / niespójnością, co powiesz na wyświetlenie strony konserwacji na czas wypychania? Strona obsługi w górę, zaktualizuj kod na obu stronach, uruchom update.php na jednej z nich, strona konserwacji w dół. To dość łatwe do skryptu.

Inna opcja: w zależności od rodzaju prowadzonej witryny można utworzyć „tryb tylko do odczytu”, który wyłączy wszystkich użytkowników w trybie offline i wyłączy logowanie / rejestrację. Sklonuj swoją bazę danych na drugą bazę danych na tym samym polu bazy danych, sklonuj swój interfejs użytkownika do nowego pliku docroot, zrób tam aktualizacje, a następnie dowiązaj symboliczny plik danych Apache do nowego pliku dbroot. Przepływ pracy jest podobny do:

1. Tryb tylko do odczytu włączony
2. WYBIERZ current_db INTO new_db
3. cp -R bieżący_dokroot nowy_dokroot
4. new.twojadomena.com ==> / new_docroot
5. zaktualizuj kod do new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Tryb tylko do odczytu wyłączony.

Będzie to zależeć od wprowadzanych zmian, jak sugeruje Entendu. Jaką część aktualizacji kodu można uruchomić bez powodowania błędów, jeśli baza danych nie jest jeszcze zaktualizowana? W przypadku wszystkiego, co nie zależy od aktualizacji bazy danych (a być może możesz nieco zmienić proces programowania, aby był bardziej powszechny), tak naprawdę nie ma nic specjalnego do roboty. Zakładam, że chcesz wykonywać wdrożenia przy minimalnym przestoju, w przeciwnym razie wystarczyłoby kilka podstawowych operacji synchronizacji. W takim przypadku zawsze będzie trochę czasu z niepożądanymi efektami (nawet jeśli strona ma tylko tryb do odczytu), ale sądzę, że przez większość czasu może być dość mała.

Możesz przeprowadzić podstawową optymalizację, na przykład skonfigurować „nowy” katalog na każdym serwerze z wyprzedzeniem, a następnie przełączyć je na wszystkie, aby wskazać nowy katalog w tym samym czasie (być może korzystając z dowiązań symbolicznych jak w odpowiedzi Entendu), aby uzyskać wszystkie serwery przełączyły się na nowe pliki w ciągu 5-10 sekund.

Pozostawia to problem aktualizacji bazy danych. Jeśli są to czynności, które należy wykonać tylko z jednego serwera, możesz ustawić inne w trybie konserwacji lub wyregulować moduł równoważenia obciążenia, aby nie używać ich w tym czasie. Oczywiście, jeśli nie można tego zrobić, gdy użytkownicy są aktywni w witrynie, wystarczy mieć wszystko w trybie konserwacji, ale w przypadku prostych aktualizacji może to być coś, co można zrobić w około 30 sekund lub krócej.

Być może warto mieć różne skrypty wdrażania dla różnych typów zmian, abyś mógł uruchomić minimalny wymagany proces, czy to tylko kopiowanie plików, uruchomienie małej aktualizacji bazy danych, czy dokonanie poważnej zmiany bazy danych.

Jeśli możesz zoptymalizować aktualizacje plików i baz danych i sprawdzić, czy istnieją proste zmiany, które możesz wprowadzić w sposobie opracowywania, może cię to przybliżyć, ale nie wiem, czy coś takiego jest dla ciebie nowe :)

Aegir przydaje się do zarządzania siecią witryn. Użyłem go do wdrożenia i zarządzania ponad 2000 witryn dla jednego klienta.

Twoje pytanie sugeruje, że chcesz zarządzać jedną witryną z wieloma głowicami WWW. W takim przypadku Aegir może być mniej przydatny. Zamiast tego sugeruję skorzystanie z systemu plików obsługującego sieć. Zapewnia to nie tylko synchronizację kodu, ale oznacza, że ​​przesłane pliki są dostępne we wszystkich węzłach.

Historycznie ludzie używali NFS, który umożliwia współdzielenie systemu plików jednego serwera z innymi węzłami. Niestety wprowadza to jeden punkt awarii, ponieważ jeśli serwer NFS zostanie zamknięty lub zginie, nie można obsłużyć witryny.

Jeśli chcesz nieco obniżyć wydajność io na rzecz bardziej niezawodnego serwera, polecam GlusterFS . Użyłem w kilku środowiskach produkcyjnych. Nie jest idealny, ale jest lepszy niż NFS. Gluster pozwala głowicy internetowej zawsze czytać lokalnie, a zapisy są następnie replikowane do innych węzłów.

Jeśli chodzi o strategię wdrażania, powinieneś mieć drush jako pierwsze narzędzie na liście. Dzięki drush powinieneś być w stanie zautomatyzować etapy wdrożenia. Należy rozważyć dodanie Jenkinsa do mieszanki, aby móc śledzić zadania wdrażania i identyfikować wzorce, jeśli coś się nie powiedzie. Capistrano może być przydatny do automatyzacji etapów wdrożenia. Jeśli robisz wszystko poprawnie, możesz to zrobić, aby użytkownicy nigdy nie wiedzieli, że wykonałeś wdrożenie.