Wdrażanie nowego kodu na żywo

Jaka jest najlepsza praktyka wdrażania nowego kodu w witrynie działającej na żywo (e-commerce)?

Na razie zatrzymałem apache na +/- 10 sekund podczas zmiany nazwy katalogu public_html_newna public_htmlstary i na stary public_html_old. To powoduje krótkie przestoje, zanim ponownie uruchomię Apache.

To samo pytanie dotyczy użycia Git do pobrania nowego repozytorium do katalogu na żywo. Czy mogę pobrać repo, gdy strona jest aktywna? Co powiesz na to, że muszę też skopiować bazę danych?

Podczas kompresji tar (kopii zapasowej) witryny działającej na żywo zauważyłem, że nastąpiły zmiany w katalogu multimediów. To wskazało mi, że pliki zmieniają się okresowo. A jeśli zmiany te mogą przeszkadzać, jeśli Apache nie zostanie zatrzymany podczas wdrażania.

Korzystanie z modułu równoważenia obciążenia jest dobrym pomysłem. Jeśli witryna jest wystarczająco ważna, aby martwić się o kilka sekund przestoju, wystarczy, aby martwić się tolerancją na awarie.

Poza tym, jeśli jest to system UNIX, możesz zawiesić Apache podczas zmiany nazwy (lub aktualizacji dowiązania symbolicznego itp.):

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

Dzięki temu Apache nie będzie akceptował nowych żądań podczas zmiany nazwy. Jeśli wolisz dowiązania symboliczne lub inne podejście, możesz zastosować ten sam pomysł:

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

Pamiętaj, że wszelkie oczekujące połączenia lub pakiety będą się kolejkować w systemie operacyjnym. W przypadku bardzo obciążonej witryny rozważ dostrojenie ListenBacklog, jeśli jest to odpowiednie dla twojego typu roboczego httpd, i sprawdź ustawienia systemu operacyjnego związane z zaległościami TCP nasłuchu.

Możesz także zmienić DocumentRoot w httpd.conf i wykonać płynny restart ( apachectl graceful). Wadą tego jest zwiększone ryzyko błędów, ponieważ trzeba będzie również zaktualizować dowolną Directorykonfigurację.

Najszybszym i najłatwiejszym jest użycie katalogu wersji takiego jak

/var/www/version/01
/var/www/version/02

i użyj aktualnego dowiązania symbolicznego jako twojego html_root:

/var/www/html -> /var/www/version/02

Ta technika doskonale integruje się z systemem kontroli wersji (svn, git, mercurial, ...), ponieważ możesz sprawdzać gałęzie i tagi, zmieniać łącze symboliczne i ponownie ładować Apache. Przestoju jest minimalny przy użyciu tej techniki i umożliwia bardzo łatwy wycofywania .

Dobrze integruje się również z bardziej złożonym systemem wdrażania, takim jak pakiety RPM lub infrastruktura zarządzania zmianami konfiguracji (szef kuchni, kukiełka itp.).

Powinna również działać zmiana nazwy katalogów bez wyłączania Apache. To znacznie skróci okno. mv public_html public_html_old && mv public_html_new public_htmlpowinien zakończyć się w ułamku sekundy.

Kilka wad polega na tym, że takie podejście da 404każdemu żądaniu, które wciąż zdarza się podczas okna. A jeśli uruchomisz powyższe polecenie bez public_html_newkatalogu, zakończy się ono niepowodzeniem i pozostawi stronę z podaniem 404na każde żądanie.

Robienie tego atomowo z katalogami nie jest obsługiwane. Ale możesz to zrobić za pomocą dowiązań symbolicznych. Zamiast mieć katalog o nazwie public_html, nazwij go public_html.version-numberi wywołaj dowiązanie symboliczne public_htmlwskazujące na ten katalog. Teraz możesz utworzyć katalog o nazwie public_html.new-version-numberi nowe łącze symboliczne o nazwie public_html.new.

Następnie możesz zmienić nazwę public_html.newna, public_htmlaby przełączać atomowo. Zauważ, że mvjest „zbyt inteligentny”, aby wykonać tę zmianę nazwy, ale można to zrobić za pomocą os.renamePythona lub czegokolwiek innego, co wywoła wywołanie renamesystemowe, nie próbując być mądrym.

To, co zrobić z bazą danych, zależy od bazy danych, z której korzystasz i do czego jej używasz. Musisz podać o wiele więcej szczegółów na temat bazy danych, abyśmy mogli udzielić ci właściwej odpowiedzi na tę część pytania.

Symlinks i mv to twoi przyjaciele, jednak jeśli naprawdę chcesz uniknąć sytuacji, w której użytkownicy końcowi otrzymają stronę błędu podczas wdrażania nowej wersji, powinieneś mieć odwrotny serwer proxy lub moduł równoważenia obciążenia przed co najmniej 2 serwerami zaplecza (apache) w Twoim przypadku).

Podczas wdrażania wystarczy zatrzymać jeden backend na raz, wdrożyć nowy kod, zrestartować go, a następnie wykonać iterację na pozostałych backendach.

Użytkownicy końcowi zawsze będą kierowani do dobrych backendów przez proxy.

Jeśli regularnie wprowadzasz zmiany w systemie produkcyjnym, zadbam o uporządkowany cykl życia. Dobrą praktyką jest Capistrano http://capistranorb.com/ . Jest to rozwiązanie typu open source do wdrażania oprogramowania na co najmniej jednym serwerze na kilku platformach i konfiguracjach.

Dla Magento istnieje nawet wtyczka: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

W przypadku pojedynczego serwera i prawie płynnych przejść zalecam użycie dowiązań symbolicznych.

Sposób, w jaki to robię, polega na zatwierdzaniu zmian z lokalnego środowiska programistycznego do internetowego repozytorium Git, takiego jak Github. Moje środowisko produkcyjne działa ze zdalnego repozytorium, więc wszystko, co muszę zrobić, to ssh na serwerze i uruchomić, git pullaby sprowadzić najnowsze zmiany. Nie musisz zatrzymywać serwera.

Jeśli masz w projekcie pliki, których ustawienia i / lub treść różnią się od wersji lokalnej (np. Pliki konfiguracyjne i przesyłanie multimediów), możesz użyć zmiennych środowiskowych i / lub dodać te pliki / katalogi do .gitignorepliku, aby zapobiec synchronizacji z repozytorium.

Mój pierwszy pomysł to:

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

Dobrym rozwiązaniem było użycie rsync. Zmieniło tylko naprawdę zmienione pliki. Uwaga, ukośniki na końcu ścieżek są tutaj ważne.

Zwykle apache nie wymaga restartu, to nie jest świat Java. Sprawdza zmiany każdego pliku php na żądanie i automatycznie odczytuje (i ponownie tokenizuje) przy zmianie.

Pull Git był podobny, choć nieco trudniejszy do napisania. Oczywiście umożliwiło to szerokie spektrum różnych możliwości wykrywania łączenia / zmiany.

To rozwiązanie będzie bezproblemowo tylko wtedy, gdy nie będzie tak naprawdę poważnych zmian - jeśli są duże zmiany we wdrożeniu, nie można wyeliminować odrobiny zagrożenia, ponieważ nie ma nieistotnego odstępu czasu, kiedy kod zostanie częściowo zmieniony a w szczególności nie.

Jeśli są duże zmiany, moja propozycja była twoim początkowym rozwiązaniem (dwie zmiany nazwy).

Oto trochę hardcorowe, ale w 100% atomowe rozwiązanie:

(1) wykonaj naprzemienne podłączanie niektórych systemów plików, w których odbywa się magento:

mount /dev/sdXY /mnt/tmp

(2) wykonaj --bindpodłączenie swojej public_html_new do public_html:

mount --bind /path/to/public_html_new /path/to/public_html

Od tego momentu apache zobaczy Twoje nowe wdrożenie. Każda zmiana 404 jest niemożliwa.

(3) wykonaj synchronizację z rsync, ale w alternatywnym punkcie montowania):

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

(4) zdejmij mocowanie bindowania

umount /path/to/public_html

Przenoszenie / zastępowanie http_publicfolderu można wykonać za pomocą prostego mvlubln -s poleceń lub równoważne, gdy serwer http ciągle pracuje. Możesz wykonać skrypty, aby znacznie skrócić czas przestoju, ale jeśli zautomatyzujesz ten proces, dokładnie sprawdź kody zwrotne swoich poleceń w skrypcie.

To powiedziawszy, jeśli nie chcesz przestoju, Twoja aplikacja musi również go obsługiwać. Większość aplikacji korzysta z bazy danych w celu zachowania trwałości. Zablokowanie wersji N aplikacji w wersji N + 1 (lub odwrotnej) modelu danych może zepsuć się, jeśli zespół programistyczny tego nie przewidzi.

Z doświadczenia, utrzymanie takiej spójności poprzez uaktualnienia nie jest dane dla większości aplikacji. Prawidłowe wyłączenie, pomimo przestoju, jest dobrym sposobem na uniknięcie problemów ze spójnością.