Węzeł.konfiguracja js dla łatwego wdrażania i aktualizacji
Obecnie rozwijamy stronę internetową (TYPO3 pod Apache) dla Klienta, która jest obsługiwana przez aplikację node. js/socket. io, która zapewnia aktualizacje treści serwowanych z CMS w czasie rzeczywistym.
Ponieważ jest to nasz pierwszy węzeł.js project Nie mam żadnych najlepszych praktyk, jeśli chodzi o "idealną konfigurację", więc spędziłem trochę czasu na badaniu technik wdrażania.
Kilka pytań pozostaje dla mnie, aby osiągnąć dobrą konfigurację które:
Jest łatwy do wdrożenia przez klienta . Jest to bardzo ważne, ponieważ nasza strona internetowa zostanie zintegrowana z ich instalacją "na żywo" TYPO3, która obsługuje mnóstwo stron internetowych i działa na serwerach, które nie są zarządzane przez klienta, ale inną (scentralizowaną) organizację, która sprawia, że połączenia wsparcia i zmiany serwera są powolne.
Powinna być łatwa do aktualizacji. Jak już wspomniałem o ponownym uruchomieniu i zrobieniu serwera zmiany są procesem powolnym, więc idealy instalacja węzła powinna ponownie uruchomić / zaktualizować, gdy otrzyma zmiany, które są wpychane do instalacji na żywo za pomocą
git
.
Wdrożenie
Ogólny konsensus wydaje się być używany forever
, jeśli chodzi o wdrażanie aplikacji węzłowych, aby utrzymać je w działaniu. Przetestowałem forever
i wydaje się, że działa dobrze po zainstalowaniu przez npm install forever -g
(global). Wymagałoby to pomocy zewnętrznej, aby globalnie zainstalować na żywo jednak środowisko, więc wolałbym, aby działało z katalogu node_modules
aplikacji, ale nie byłem w stanie stworzyć solidnego wrappera, aby to zrobić.
Dodatkowo, forever
działa dobrze, ale musi być uruchomiony ręcznie. Jakie byłoby najlepsze podejście, aby zapewnić, że zostanie uruchomiony podczas rozruchu serwera i będzie działał?
- prosty
init.d
skrypt? - piszesz watchdog wrapper?
- zadanie schedulera TYPO3, które sprawdza status
forever
?
Szybki rozwój / Restart przy aktualizacji
Jesteśmy obecnie w fazie rozwoju projektu i za każdym razem, gdy wprowadzam zmiany w węźle.aplikacja js ręcznie restartuję node
lub forever
. To działa, ale jest dalekie od ideału.
Istnieje kilka mniejszych modułów npm
, które sprawdzają modyfikacje plików i restartują node
po wykryciu zmian, takich jak:
- Nodemon
- węzeł.js Supervisor
- Bounce
-
guzki (które nie wymagają ponownego uruchamiania węzła, więc może być łatwiejsze do połączenia z
forever
) - do góry
Czy ktoś ma doświadczenie z którymś z nich?
Aktualizacja: dlaczego po prostu nie użyjesz klastra?
Moduł klastra zapewnia podobną funkcjonalność poprzez mechanizm reload, ale nie działa z węzłem 0.5+. Na core Cluster module (Node 0.6+) który zastąpił go nie ma wszystkich tych funkcji, a jedynie zapewnia klastrowanie. Który z kolei nie gra dobrze z socket.io. przynajmniej nie bez użycia Redis (co jest dla nas problemem, ponieważ nie możemy wymusić kolejnej usługi prereq dla klienta).
--
Oczywiście staram się znaleźć najbardziej stabilne rozwiązanie, które łączy update-restarter z forever
przed przekazaniem projektu klientowi i mam nadzieję, że ktoś stworzył sprawdzoną kombinację technik.
3 answers
Łącząc całą zgromadzoną wiedzę (wielkie podziękowania dla Juliana Knighta za pomysły) i metody Przetestowane w zeszłym tygodniu, postanowiłem zadowolić się rozwiązaniem wdrożeniowym opisanym poniżej (pomyślałem, że chętnie podzielę się z innymi, aby pomóc innym w porównywalnych pytaniach): {]}
Automatyczne restartowanie przy błędach skryptuoraz automatyczne przeładowanie przy zmianach skryptu obsługiwane jest przez forever, ponieważ zawiera również skrypt zegarka, o ile Forever jest zrodzony z wewnątrz węzła.skrypt js.
Aby to zrobić, dodałem server.js
aby uruchomić skrypt app.js
, który chcemy uruchomić:
Serwer.js
var forever = require('forever'),
child = new(forever.Monitor)('app.js', {
'silent': false,
'pidFile': 'pids/app.pid',
'watch': true,
'watchDirectory': '.', // Top-level directory to watch from.
'watchIgnoreDotFiles': true, // whether to ignore dot files
'watchIgnorePatterns': [], // array of glob patterns to ignore, merged with contents of watchDirectory + '/.foreverignore' file
'logFile': 'logs/forever.log', // Path to log output from forever process (when daemonized)
'outFile': 'logs/forever.out', // Path to log output from child stdout
'errFile': 'logs/forever.err'
});
child.start();
forever.startServer(child);
Śledzi wszystkie pliki w katalogu aplikacji pod kątem zmian i uruchamia ponownie skrypt uruchomiony w forever
, gdy tylko się zmieni. Ponieważ logi i pidfile znajdują się w podkatalogach aplikacji, należy je zignorować z pliku watch, w przeciwnym razie skrypt zapętli się restart:
.foreverignore
pids/**
logs/**
Aby wszystko zaczęło się od rozruchu systemu i umożliwiło nam łatwe kontrolowanie usługi za pomocą start node-app
i stop node-app
używamyUbuntu ' s Upstart .
Połączyłem dwa przykłady ( ten i ten jeden) w jeden, który całkiem dobrze wykonuje swoją pracę:
/etc / init / node-app.conf
# This is an upstart (http://upstart.ubuntu.com/) script
# to run the node.js server on system boot and make it
# manageable with commands such as
# 'start node-app' and 'stop node-app'
#
# This script is to be placed in /etc/init to work with upstart.
#
# Internally the 'initctl' command is used to manage:
# initctl help
# initctl status node-app
# initctl reload node-app
# initctl start node-app
description "node.js forever server for node-app"
author "Remco Overdijk <[email protected]>"
version "1.0"
expect fork
# used to be: start on startup
# until we found some mounts weren't ready yet while booting:
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
env HOME=/home/user/node-app-dir
script
# Not sure why $HOME is needed, but we found that it is:
export HOME=$HOME
chdir $HOME
exec /usr/local/bin/node server.js > logs/node.log &
end script
#post-start script
# # Optionally put a script here that will notifiy you node has (re)started
# # /root/bin/hoptoad.sh "node.js has started!"
#end script
Jak wspomina Kevin w swoim artykule nierozsądne jest uruchamianie node jako root, więc zmienimy to do exec sudo -u www-data /usr/local/bin/node
kiedy przenosimy się na nowe serwery w przyszłym tygodniu.
Tak więc, forever
jest uruchamiany automatycznie przez node server.js
, który jest uruchamiany przez upstart
, i monitoruje awarie i zmiany plików, utrzymując całą konfigurację tak długo, jak chcemy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:17:57
Ponieważ moja ostatnia odpowiedź jest na przyszłość! Oto kilka innych linków do pomocy:
- https://serverfault.com/questions/274857/how-to-use-node-js-as-a-production-web-server
- http://www.slideshare.net/the_undefined/nodejs-best-practices-10428790 (patrz slajd 35)
- http://www.slideshare.net/the_undefined/nodejs-in-production (slajdy 31 do końca)
- gdy węzeł.js idzie w dół, jak mogę go przywrócić automatycznie?
Wydaje się, że nie ma jeszcze doskonałej odpowiedzi, ale istnieje wiele osób uruchamiających instancje węzłów produkcyjnych. Mam nadzieję, że to wskaże ci właściwy kierunek.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:34:19
Może lepiej, do użytku produkcyjnego, spojrzeć na coś w rodzaju klastra . Możesz nie chcieć funkcji klastra, ale zawiera również inne funkcje produkcyjne, takie jak restart zerowego przestoju, logowanie, pracownicy itp.
Jak mówisz, Forever jest w porządku do testowania, ale tak naprawdę nie ma tego, czego potrzeba do produkcji.
Wydaje mi się, że mgliście pamiętam, że klaster lub coś podobnego może zostać zaadoptowany do samego węzła come v0.7
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-18 20:26:54