node windows
1.0.0-beta.8
Cette bibliothèque peut être utilisée pour installer / démarrer / stop / désinstaller des scripts de nœuds comme services d'arrière-plan Windows pour les environnements de production . Ce n'est pas un outil pour développer des applications, c'est un outil pour les libérer. Cet outil génère un exécutable qui exécutera votre application avec la version de Node.js est installée sur l'ordinateur.
Voir Node-Mac et Node-Linux si vous devez prendre en charge ces systèmes d'exploitation.
Tweetez-moi (@goldglovecb) si vous avez besoin de moi.
 |  |  |  |
Vous ne pouvez pas parrainer? Envisagez de nommer @CoreyButler pour une étoile GitHub. | |||
Les fonctionnalités suivantes sont disponibles en nœud-windows:
exec en tant que sudoer.La façon recommandée d'installer Node-Windows est avec NPM, en utilisant le drapeau global:
npm install -g node-windows
Ensuite, dans la racine de votre projet, exécutez:
npm link node-windows
Cependant; Il est possible d'utiliser des nœuds sans le drapeau global (c'est-à-dire installer directement dans la racine du projet). Plus de détails sur la raison pour laquelle il ne s'agit pas de l'approche recommandée est disponible tout au long de cette lecture.
L'utilisation de modules de nœuds natifs sur Windows peut être nul. La plupart des modules natifs ne sont pas distribués dans un format binaire. Au lieu de cela, ces modules reposent sur npm pour construire le projet, en utilisant le Node-GYP. Cela signifie que les développeurs doivent que Visual Studio (et potentiellement d'autres logiciels) soit installé sur le système, juste pour installer un module natif. C'est portable, mais douloureux ... principalement parce que Visual Studio lui-même est supérieur à 2 Go.
Node-Windows n'utilise pas de modules natifs. Il existe des utilitaires binaires / EXE, mais tout ce qui est nécessaire pour exécuter des tâches plus complexes est emballé et distribué dans un format facilement utilisable. Donc, pas besoin de Visual Studio ... du moins pas pour ce module.
Node-Windows a un utilitaire pour exécuter les scripts Node.js en tant que services Windows. Veuillez noter que, comme tous les services Windows, en créant un nécessite des privilèges administratifs. Pour créer un service avec Node-Windows, préparez un script comme:
var Service = require ( 'node-windows' ) . Service ;
// Create a new service object
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
nodeOptions : [
'--harmony' ,
'--max_old_space_size=4096'
]
//, workingDirectory: '...'
//, allowServiceLogon: true
} ) ;
// Listen for the "install" event, which indicates the
// process is available as a service.
svc . on ( 'install' , function ( ) {
svc . start ( ) ;
} ) ;
svc . install ( ) ; Le code ci-dessus crée un nouvel objet Service , fournissant un joli nom et une description. L'attribut script identifie le script node.js qui devrait s'exécuter en tant que service. En exécutant cela, le script sera visible à partir de l'utilitaire Windows Services.
L'objet Service émet les événements suivants:
Dans l'exemple ci-dessus, le script écoute l'événement install . Étant donné que cet événement est licencié lorsqu'une installation de service est terminée, il est sûr de démarrer le service.
Les services créés par Node-Windows sont similaires à la plupart des autres services exécutés sur Windows. Ils peuvent être démarrés / arrêtés de l'utilitaire de service Windows, via les commandes NET START ou NET STOP , ou même gérées à l'aide de l'utilitaire SC.
Il peut être souhaité de spécifier des commutateurs de ligne de commande à votre script. Vous pouvez le faire en définissant les scriptOptions dans la configuration du service:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
scriptOptions : '-c C:\path\to\somewhere\special -i'
} ) ;Parfois, vous pouvez fournir un service avec des données statiques, transmise sur la création du service. Vous pouvez le faire en définissant des variables d'environnement dans la configuration du service, comme indiqué ci-dessous:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
env : {
name : "HOME" ,
value : process . env [ "USERPROFILE" ] // service is now able to access the user who created its' home directory
}
} ) ;Vous pouvez également fournir un tableau pour définir plusieurs variables d'environnement:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
env : [ {
name : "HOME" ,
value : process . env [ "USERPROFILE" ] // service is now able to access the user who created its' home directory
} ,
{
name : "TEMP" ,
value : path . join ( process . env [ "USERPROFILE" ] , "/temp" ) // use a temp directory in user's home directory
} ]
} ) ; Il y a des moments où vous voudrez peut-être spécifier un node spécifique exécutable à utiliser pour exécuter votre script. Vous pouvez le faire en définissant le execPath dans la configuration du service, comme indiqué ci-dessous:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
execPath : 'C:\path\to\specific\node.exe'
} ) ;Si vous devez spécifier un utilisateur spécifique ou des informations d'identification particulières pour gérer un service, les attributs suivants peuvent être utiles.
L'attribut user est un objet avec trois clés: domain , account et password . Cela peut être utilisé pour identifier le utilisateur que la bibliothèque de services doit utiliser pour effectuer des commandes système. Par défaut, le domaine est défini sur le nom de l'ordinateur local, mais il peut être remplacé par un domaine Active Directory ou LDAP. Par exemple:
app.js
var Service = require ( 'node-windows' ) . Service ;
// Create a new service object
var svc = new Service ( {
name : 'Hello World' ,
script : require ( 'path' ) . join ( __dirname , 'helloworld.js' ) ,
//, allowServiceLogon: true
} ) ;
svc . logOnAs . domain = 'mydomain.local' ;
svc . logOnAs . account = 'username' ;
svc . logOnAs . password = 'password' ;
... Le compte et le mot de passe doivent être explicitement définis si vous souhaitez que le module de service exécute les commandes en tant qu'utilisateur spécifique. Par défaut, il s'exécutera à l'aide du compte utilisateur qui a lancé le processus (c'est-à-dire qui a lancé node app.js ).
Si vous souhaitez instruire Winsw pour autoriser les connexions du compte de service, spécifiez allowServiceLogon: true . Ceci est désactivé par défaut, car certains utilisateurs ont connu des problèmes qui exécutent cela sans connexion de service.
L'autre attribut est sudo . Cet attribut a une seule propriété appelée password . En fournissant cela, le module de service tentera d'exécuter des commandes à l'aide du compte utilisateur qui a lancé le processus et le mot de passe de ce compte. Cela ne doit être utilisé que pour des comptes avec des privilèges administratifs.
app.js
var Service = require ( 'node-windows' ) . Service ;
// Create a new service object
var svc = new Service ( {
name : 'Hello World' ,
script : require ( 'path' ) . join ( __dirname , 'helloworld.js' )
} ) ;
svc . sudo . password = 'password' ;
...Le service peut également être rendu en fonction d'autres services Windows.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
dependsOn : [ "serviceA" ]
} ) ;La désinstallation d'un service précédemment créé est syntaxiquement similaire à l'installation.
var Service = require ( 'node-windows' ) . Service ;
// Create a new service object
var svc = new Service ( {
name : 'Hello World' ,
script : require ( 'path' ) . join ( __dirname , 'helloworld.js' )
} ) ;
// Listen for the "uninstall" event so we know when it's done.
svc . on ( 'uninstall' , function ( ) {
console . log ( 'Uninstall complete.' ) ;
console . log ( 'The service exists: ' , svc . exists ) ;
} ) ;
// Uninstall the service.
svc . uninstall ( ) ;Le processus de désinstallation supprime uniquement les fichiers spécifiques au processus. Il ne supprime pas votre script Node.js!
Beaucoup de choses!
Processus de longue durée et surveillance:
La récupération de service intégrée pour Windows Services est assez limitée et ne peut pas être facilement configurée à partir du code. Par conséquent, Node-Windows crée un wrapper autour du script Node.js. Cet emballage est responsable du redémarrage d'un service raté de manière intelligente et configurable. Par exemple, si votre script se bloque en raison d'une erreur inconnue, Node-Windows tentera de le redémarrer. Par défaut, cela se produit chaque seconde. Cependant; Si le script a un défaut fatal qui le fait s'écraser à plusieurs reprises, il ajoute des frais généraux inutiles au système. Node-Windows gère cela en augmentant l'intervalle de temps entre les redémarrages et le plafonnement du nombre maximum de redémarrages.
Des redémarrages plus intelligents qui ne frappent pas votre serveur:
En utilisant les paramètres par défaut, Node-Windows ajoute 25% à l'intervalle d'attente chaque fois qu'il doit redémarrer le script. Avec le paramètre par défaut (1 seconde), la première tentative de redémarrage se produit après une seconde. La seconde se produit après 1,25 seconde. Le troisième après 1,56 seconde (1,25 a augmenté de 25%) et ainsi de suite. Le temps d'attente initial et le taux de croissance sont des options de configuration qui peuvent être transmises à un nouveau Service . Par exemple:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
wait : 2 ,
grow : .5
} ) ;Dans cet exemple, la période d'attente commencera à 2 secondes et augmentera de 50%. Ainsi, la deuxième tentative serait de 3 secondes plus tard, tandis que le quatrième serait de 4,5 secondes plus tard.
Ne vous dos pas!
Le recyclage répétitif pourrait potentiellement durer éternellement avec un mauvais script. Pour gérer ces situations, Node-Windows prend en charge deux types de plafonds. L'utilisation maxRetries plafonnera le nombre maximum de tentatives de redémarrage. Par défaut, c'est illimité. Le régler sur 3 indiquerait que le processus ne redémarre pas un processus après avoir échoué 3 fois. Une autre option est maxRestarts , ce qui limite le nombre de redémarrages tentés dans les 60 secondes. Par exemple, si cela est défini sur 3 (par défaut) et que le processus se bloque / redémarre à plusieurs reprises, le nœud-windows cessera de redémarrer les tentatives après le 3e cycle dans une fenêtre de 60 secondes. Ces deux options de configuration peuvent être définies, tout comme wait ou grow .
Enfin, un attribut appelé abortOnError peut être défini sur true si vous souhaitez que votre script ne redémarre pas du tout lorsqu'il sort avec une erreur.
Node-Windows utilise l'utilitaire WINSW pour créer un .exe unique pour chaque script node.js déployé en tant que service. Un répertoire appelé daemon est créé et rempli de myappname.exe et myappname.xml . Le fichier XML est une configuration pour l'exécutable. De plus, winsw créera des journaux pour lui-même dans ce répertoire (qui sont visibles dans le journal des événements).
Le fichier myappname.exe lance le wrapper de nœuds-windows, qui est responsable de la surveillance et de la gestion du script. Étant donné que ce fichier fait partie de Node-Windows, le déplacement du répertoire Node-Windows pourrait entraîner le fichier .exe sans pouvoir trouver le script node.js. Cependant; Cela ne devrait pas être un problème si le nœud-windows est installé globalement, selon les instructions d'installation recommandées.
Tous ces fichiers spécifiques au démon sont créés dans un sous-répertoire appelé daemon , qui est créé dans le même répertoire où le script Node.js est enregistré. La désinstallation d'un service supprimera ces fichiers.
Journalisation de l'événement
Les services créés avec Node-Windows ont deux journaux d'événements qui peuvent être affichés via la visionneuse d'événements Windows. Une source de journal nommée myappname.exe fournit une journalisation de base pour le fichier exécutable. Il peut être utilisé pour voir quand l'ensemble du service démarre / s'arrête ou a des erreurs. Un deuxième journal, nommé d'après le nom de votre service (c'est-à-dire le nom de mon application), est utilisé par le moniteur Node-Windows. Il est possible d'écrire à ce journal à partir du script Node.js à l'aide de la journalisation de l'événement Node-Windows.
Nouveau à partir de v0.1.0 est un utilitaire de journalisation d'événements non-C ++ . Cet utilitaire peut écrire au journal des événements, ce qui rend vos journaux visibles à partir de la visionneuse d'événements. Il utilise EventCreate sous le capot.
Pour créer un enregistreur:
var EventLogger = require ( 'node-windows' ) . EventLogger ;
var log = new EventLogger ( 'Hello World' ) ;
log . info ( 'Basic information.' ) ;
log . warn ( 'Watch out!' ) ;
log . error ( 'Something went wrong.' ) ;Ressemble à:
Certaines options moins utilisées sont également disponibles via la journalisation des événements de nœuds.
log . auditSuccess ( 'AUser Login Success' ) ;
log . auditFailure ( 'AUser Login Failure' ) ; Chaque type de journal (Info, Warn, Error, AuditSuccess et AuditFailure) Méthode accepte éventuellement deux arguments supplémentaires, y compris un code et un rappel . Par défaut, le code d'événement est 1000 si ce n'est pas spécifié autrement. Pour fournir un code d'événement personnalisé avec un message de journal et rédiger ce message à la console, le code suivant pourrait être utilisé:
AVIS: Il semble que EventCreate prenne uniquement en charge les ID personnalisés <= 1000.
log . info ( 'Something different happened!' , 700 , function ( ) {
console . log ( 'Something different happened!' ) ;
} ) ; Par défaut, les journaux d'événements font tous partie de la portée APPLICATION . Cependant; Il est également possible d'utiliser le journal SYSTEM . Pour ce faire, un objet de configuration doit être transmis au nouveau journal:
var EventLogger = require ( 'node-windows' ) . EventLogger ;
var log = new EventLogger ( {
source : 'My Event Log' ,
eventLog : 'SYSTEM'
} ) ;Les journaux d'événements d'avertissement produits par l'emballage peuvent être supprimés en le désactivant lors de la création du service. Les journaux d'avertissement sont activés par défaut.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
disableWarningLogs : true ,
} ) ;Node-Windows est livré avec plusieurs commandes pour simplifier les tâches sur MS Windows.
Elevate est similaire à sudo sur Linux / Mac. Il tente d'élever les privilèges de l'utilisateur actuel à un administrateur local. L'utilisation de cela ne nécessite pas de mot de passe, mais il faut que l'utilisateur actuel ait des privilèges administratifs. Sans ces privilèges, la commande échouera avec une erreur access denied .
Sur les systèmes avec UAC activés, cela peut inciter l'utilisateur à procéder:
Syntaxe :
elevate(cmd[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . Sudo agit de manière similaire à sudo sur Linux / Mac. Contrairement à Elevate , il nécessite un mot de passe, mais il n'en incitera pas la permission pour continuer. Comme Elevate , cela nécessite toujours des privilèges administratifs pour l'utilisateur, sinon la commande échouera. La principale différence entre cela et Elevate () est l'invite.
Syntaxe :
sudo(cmd,password[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . Cette commande asynchrone détermine si l'utilisateur actuel a des privilèges administratifs. Il passe une valeur booléenne au rappel, renvoyant true si l'utilisateur est un administrateur ou false si ce n'est pas le cas.
Exemple
var wincmd = require ( 'node-windows' ) ;
wincmd . isAdminUser ( function ( isAdmin ) {
if ( isAdmin ) {
console . log ( 'The user has administrative privileges.' ) ;
} else {
console . log ( 'NOT AN ADMIN' ) ;
}
} ) ; La méthode de liste interroge le système d'exploitation pour une liste de processus en cours.
var wincmd = require ( 'node-windows' ) ;
wincmd . list ( function ( svc ) {
console . log ( svc ) ;
} , true ) ; Cela renvoie un tableau de processus en cours d'exécution. La fourniture de l'argument true en option dans l'exemple ci-dessus fournit une liste avec une sortie verbale. La sortie est spécifique à la version du système d'exploitation. Voici un exemple de sortie verbeux sur un ordinateur Windows 8.
[ {
ImageName : 'cmd.exe' ,
PID : '12440' ,
SessionName : 'Console' ,
'Session#' : '1' ,
MemUsage : '1,736 K' ,
Status : 'Unknown' ,
UserName : 'Machine\Corey' ,
CPUTime : '0:00:00' ,
WindowTitle : 'N/A'
} , {
ImageName : 'tasklist.exe' ,
PID : '1652' ,
SessionName : 'Console' ,
'Session#' : '1' ,
MemUsage : '8,456 K' ,
Status : 'Unknown' ,
UserName : 'Machine\Corey' ,
CPUTime : '0:00:00' ,
WindowTitle : 'N/A'
} ] La sortie régulière (non verbale) fournit généralement l' ImageName , PID , SessionName , Session# , MemUsage et CPUTime .
Cette méthode tuera un processus par PID .
var wincmd = require ( 'node-windows' ) ;
wincmd . kill ( 12345 , function ( ) {
console . log ( 'Process Killed' ) ;
} ) ; Dans cet exemple, l'ID de processus 12345 serait tué. Il est important de noter que l'exécution du compte utilisateur de ce script de nœud peut nécessiter des privilèges administratifs.
Si vous rencontrez des problèmes avec les exemples, veuillez consulter le fichier TESTS.md .
Si vous rencontrez l'événement invalidinstallation , jetez un œil au répertoire daemon créé lors de l'installation pour vous assurer que les fichiers .exe et .xml sont là. Dans certaines circonstances, principalement pendant _un_installation, il est possible que le processus verrouille temporairement un fichier journal, ce qui empêche Windows de le supprimer. Dans ce scénario, exécutez à nouveau la désinstallation. Dans la plupart des cas, cela résoudra le problème. Sinon, retirez manuellement le répertoire daemon avant d'exécuter à nouveau l'installation.
Il y a eu de nombreux contributeurs qui ont tout fait, de la création de fonctionnalités à aider à ramasser Slack pendant que j'ai été submergé. Je suis incroyablement reconnaissant pour l'aide.
Un merci spécial à @arthurblake dont les modifications ont finalement été ajoutées. Grâce à @ hockeytim11, qui a aidé à compiler et à mettre à jour un tas de problèmes en suspens et a commencé à apporter un support aux autres bibliothèques de nœuds.
Winsw et Sudowin sont les droits d'auteur de leurs propriétaires respectifs. Winsw est distribué sous une licence du MIT. Sudowin est distribué sous une licence BSD.
Tous les autres scripts sont le droit d'auteur (C) Corey Butler sous une licence MIT.
(La licence MIT)
Copyright (C) 2013 Corey Butler
L'autorisation est accordée gratuitement, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le `` logiciel ''), pour traiter le logiciel sans restriction, y compris sans limiter les droits d'utilisation, de copie, de modification, de fusion, de publication, de distribution, de sublince et de vente de copies des conditions suivantes: les conditions suivantes:
L'avis de droit d'auteur ci-dessus et le présent avis d'autorisation sont inclus dans toutes les copies ou des parties substantielles du logiciel.
Le logiciel est fourni «tel quel», sans garantie d'aucune sorte, express ou implicite, y compris, mais sans s'y limiter, les garanties de qualité marchande, d'adéquation à un usage particulier et de non-contrefaçon. En aucun cas, les auteurs ou les détenteurs de droits d'auteur ne seront pas responsables de toute réclamation, dommage ou autre responsabilité, que ce soit dans une action de contrat, de délit ou autre, découlant de, hors du logiciel ou de l'utilisation ou d'autres relations dans le logiciel.
