node windows
1.0.0-beta.8
Esta biblioteca se puede usar para instalar/iniciar/detener/desinstalar scripts de nodo como servicios de fondo de Windows para entornos de producción . Esta no es una herramienta para desarrollar aplicaciones, es una herramienta para liberarlas. Esta herramienta genera un ejecutable que ejecutará su aplicación con cualquier versión de Node.js está instalada en la computadora.
Consulte Node-MAC y Node-Linux si necesita admitir esos sistemas operativos.
Tweet Me (@GoldGlovecb) si me necesita.
 |  |  |  |
¿No puede patrocinar? Considere nominar a @coreybutler para una estrella de GitHub. | |||
Las siguientes funciones están disponibles en Node-Windows:
exec como un sudoer.La forma recomendada de instalar Node-Windows es con NPM, utilizando el indicador global:
npm install -g node-windows
Luego, en la raíz de su proyecto, ejecute:
npm link node-windows
Sin embargo; Es posible usar Node-Windows sin el indicador global (es decir, instalar directamente en la raíz del proyecto). Más detalles sobre por qué este no es el enfoque recomendado están disponibles en todo este readme.
Usar módulos de nodo nativo en Windows puede apestar. La mayoría de los módulos nativos no se distribuyen en un formato binario. En su lugar, estos módulos se basan en npm para construir el proyecto, utilizando el nodo-GYP. Esto significa que los desarrolladores deben tener instalado Visual Studio (y potencialmente otro software) en el sistema, solo para instalar un módulo nativo. Esto es portátil, pero doloroso ... principalmente porque Visual Studio en sí mismo tiene más de 2 GB.
Node-Windows no usa módulos nativos. Hay algunas utilidades binarias/EXE, pero todo lo necesario para ejecutar tareas más complejas está empaquetada y distribuida en un formato fácilmente utilizable. Entonces, no hay necesidad de Visual Studio ... al menos no para este módulo.
Node-Windows tiene una utilidad para ejecutar scripts Node.js como servicios de Windows. Tenga en cuenta que, como todos los servicios de Windows, la creación de uno requiere privilegios administrativos. Para crear un servicio con Node-Windows, prepare un script como:
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 ( ) ; El código anterior crea un nuevo objeto Service , que proporciona un nombre y una descripción bonitos. El atributo script identifica el script Node.js que debería ejecutarse como un servicio. Al ejecutar esto, el script será visible desde la utilidad de servicios de Windows.
El objeto Service emite los siguientes eventos:
En el ejemplo anterior, el script escucha el evento install . Dado que este evento se dispara cuando se completa una instalación de servicio, es seguro iniciar el servicio.
Los servicios creados por Node-Windows son similares a la mayoría de los otros servicios que se ejecutan en Windows. Se pueden iniciar/detener desde la utilidad de servicio de Windows, a través de comandos NET START o NET STOP , o incluso administrarse utilizando la utilidad SC.
Se puede desear especificar interruptores de línea de comandos a su script. Puede hacer esto configurando las scriptOptions dentro de la configuración del servicio:
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'
} ) ;A veces es posible que desee proporcionar un servicio con datos estáticos, transmitidos en la creación del servicio. Puede hacerlo configurando variables de entorno en la configuración del servicio, como se muestra a continuación:
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
}
} ) ;También puede suministrar una matriz para establecer múltiples variables de entorno:
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
} ]
} ) ; Hay momentos en que puede especificar un ejecutable node específico para usar para ejecutar su script. Puede hacerlo configurando el execPath en la configuración del servicio, como se muestra a continuación:
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 necesita especificar un usuario específico o credenciales particulares para administrar un servicio, los siguientes atributos pueden ser útiles.
El atributo user es un objeto con tres claves: domain , account y password . Esto se puede usar para identificar qué usuario debe usar la biblioteca de servicios para realizar comandos del sistema. Por defecto, el dominio se establece en el nombre de la computadora local, pero se puede anular con un dominio Active Directory o LDAP. Por ejemplo:
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' ;
... Tanto la cuenta como la contraseña deben definirse explícitamente si desea que el módulo de servicio ejecute comandos como un usuario específico. De manera predeterminada, se ejecutará utilizando la cuenta de usuario que inició el proceso (es decir, quién inició node app.js ).
Si desea instruir a WinSW para permitir los inicios de sesión de la cuenta de servicio, especifique allowServiceLogon: true . Esto está deshabilitado de forma predeterminada ya que algunos usuarios han experimentado problemas que ejecutan esto sin inicios de sesión de servicio.
El otro atributo es sudo . Este atributo tiene una sola propiedad llamada password . Al proporcionar esto, el módulo de servicio intentará ejecutar comandos utilizando la cuenta de usuario que inició el proceso y la contraseña para esa cuenta. Esto solo debe usarse para cuentas con privilegios administrativos.
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' ;
...El servicio también se puede hacer dependiente de otros servicios de Windows.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
dependsOn : [ "serviceA" ]
} ) ;Desinstalar un servicio creado previamente es sintácticamente similar a la instalación.
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 ( ) ;El proceso de desinstalación solo elimina los archivos específicos del proceso. ¡No elimina su script node.js!
¡Muchas cosas!
Procesos de ejecución larga y monitoreo:
La recuperación de servicio incorporada para los servicios de Windows es bastante limitada y no se puede configurar fácilmente desde el código. Por lo tanto, Node-Windows crea un envoltorio alrededor del script Node.js. Este envoltorio es responsable de reiniciar un servicio fallido de manera inteligente y configurable. Por ejemplo, si su script se bloquea debido a un error desconocido, Node-Windows intentará reiniciarlo. Por defecto, esto ocurre cada segundo. Sin embargo; Si el script tiene un defecto fatal que hace que se bloquee repetidamente, agrega una sobrecarga innecesaria al sistema. Windows de nodo maneja esto aumentando el intervalo de tiempo entre los reinicios y limitando el número máximo de reinicios.
Smarter se reinicia que no golpearán su servidor:
Usando la configuración predeterminada, Node-Windows agrega un 25% al intervalo de espera cada vez que necesita reiniciar el script. Con la configuración predeterminada (1 segundo), el primer intento de reinicio ocurre después de un segundo. El segundo ocurre después de 1.25 segundos. El tercero después de 1.56 segundos (1.25 aumentó en un 25%) y así sucesivamente. Tanto el tiempo de espera inicial como la tasa de crecimiento son opciones de configuración que se pueden pasar a un nuevo Service . Por ejemplo:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
wait : 2 ,
grow : .5
} ) ;En este ejemplo, el período de espera comenzará a los 2 segundos y aumentará en un 50%. Entonces, el segundo intento sería 3 segundos después, mientras que el cuarto sería de 4.5 segundos después.
¡No te digas!
El reciclaje repetitivo podría continuar para siempre con un mal guión. Para manejar estas situaciones, Node-Windows admite dos tipos de tapas. El uso de maxRetries limitará el número máximo de intentos de reinicio. Por defecto, esto es ilimitado. Configurarlo en 3 le diría al proceso que ya no reinicie un proceso después de que haya fallado 3 veces. Otra opción es maxRestarts , que limita el número de reinicios intentados en 60 segundos. Por ejemplo, si esto se establece en 3 (el valor predeterminado) y el proceso se bloquea/se reinicia repetidamente, Node-Windows dejará de reiniciar los intentos después del tercer ciclo en una ventana de 60 segundos. Se pueden establecer ambas opciones de configuración, al igual que wait o grow .
Finalmente, un atributo llamado abortOnError se puede configurar en true si desea que su script no se reinicie cuando salga con un error.
Node-Windows utiliza la utilidad WinSW para crear un .exe único para cada script Node.js implementado como un servicio. Un directorio llamado daemon está creado y poblado con myappname.exe y myappname.xml . El archivo XML es una configuración para el ejecutable. Además, winsw creará algunos registros para sí mismo en este directorio (que se pueden ver en el registro de eventos).
El archivo myappname.exe inicia el contenedor de nodo-windows, que es responsable de monitorear y administrar el script. Dado que este archivo es parte de Node-Windows, mover el directorio de Node-Windows podría dar como resultado que el archivo .exe no pueda encontrar el script Node.js. Sin embargo; Esto no debería ser un problema si Node-Windows está instalado a nivel mundial, según las instrucciones de instalación recomendadas.
Todos estos archivos específicos de demonio se crean en un subdirectorio llamado daemon , que se crea en el mismo directorio donde se guarda el script Node.js. Desinstalar un servicio eliminará estos archivos.
Registro de eventos
Los servicios creados con Node-Windows tienen dos registros de eventos que se pueden ver a través del visor de eventos de Windows. Una fuente de registro llamada myappname.exe proporciona registro básico para el archivo ejecutable. Se puede usar para ver cuándo se inicia/se detiene todo el servicio o tiene errores. El segundo registro, llamado así por el nombre de su servicio (es decir, el nombre de mi aplicación), es utilizado por el monitor Node-Windows. Es posible escribir en este registro desde el script Node.js utilizando el registro de eventos de nodo-windows.
Nuevo a partir de v0.1.0 es una utilidad de registro de eventos no basada en ++ . Esta utilidad puede escribir en el registro de eventos, haciendo que sus registros sean visibles desde el visor de eventos. Utiliza EventCreate debajo del capó.
Para crear un registrador:
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.' ) ;Se parece a:
Algunas opciones menos utilizadas también están disponibles a través del registro de eventos de Node-Windows.
log . auditSuccess ( 'AUser Login Success' ) ;
log . auditFailure ( 'AUser Login Failure' ) ; Cada método de tipo de registro (información, advertencia, error, auditoría y auditFailure) acepta opcionalmente dos argumentos adicionales, incluido un código y devolución de llamada . Por defecto, el código de evento es 1000 si no se especifica de otra manera. Para proporcionar un código de evento personalizado con un mensaje de registro y escribir ese mensaje en la consola, se podría usar el siguiente código:
Aviso: parece que EventCreate solo admite ID de Custom <= 1000.
log . info ( 'Something different happened!' , 700 , function ( ) {
console . log ( 'Something different happened!' ) ;
} ) ; Por defecto, los registros de eventos son parte del alcance de la APPLICATION . Sin embargo; También es posible usar el registro SYSTEM . Para hacer esto, se debe pasar un objeto de configuración al nuevo registro:
var EventLogger = require ( 'node-windows' ) . EventLogger ;
var log = new EventLogger ( {
source : 'My Event Log' ,
eventLog : 'SYSTEM'
} ) ;Los registros de eventos de advertencia que producen el envoltorio se pueden suprimir deshabilitándolo al crear el servicio. Los registros de advertencia están habilitados de forma predeterminada.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
disableWarningLogs : true ,
} ) ;Node-Windows se envía con varios comandos para simplificar las tareas en MS Windows.
Elevate es similar a sudo en Linux/Mac. Intenta elevar los privilegios del usuario actual a un administrador local. Usar esto no requiere una contraseña, pero sí requiere que el usuario actual tenga privilegios administrativos. Sin estos privilegios, el comando fallará con un error access denied .
En los sistemas con UAC habilitado, esto puede solicitar al usuario que permita el permiso:
Sintaxis :
elevate(cmd[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . Sudo actúa de manera similar a sudo en Linux/Mac. A diferencia de Elevate , requiere una contraseña, pero no solicitará al usuario que permita el permiso. Al igual que Elevate , esto todavía requiere privilegios administrativos para el usuario, de lo contrario, el comando fallará. La principal diferencia entre esto y Elevate () es el aviso.
Sintaxis :
sudo(cmd,password[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . Este comando asincrónico determina si el usuario actual tiene privilegios administrativos. Pasa un valor booleano a la devolución de llamada, devolviendo true si el usuario es un administrador o false si no es así.
Ejemplo
var wincmd = require ( 'node-windows' ) ;
wincmd . isAdminUser ( function ( isAdmin ) {
if ( isAdmin ) {
console . log ( 'The user has administrative privileges.' ) ;
} else {
console . log ( 'NOT AN ADMIN' ) ;
}
} ) ; El método de lista consulta el sistema operativo para una lista de procesos en ejecución.
var wincmd = require ( 'node-windows' ) ;
wincmd . list ( function ( svc ) {
console . log ( svc ) ;
} , true ) ; Esto devuelve una variedad de procesos de ejecución. El suministro del argumento true opcional en el ejemplo anterior proporciona una lista con salida detallada. La salida es específica para la versión del sistema operativo. Aquí hay un ejemplo de salida detallada en una computadora 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 salida regular (no verbosa) típicamente proporciona el ImageName , PID , SessionName , Session# , MemUsage y CPUTime .
Este método matará un proceso por PID .
var wincmd = require ( 'node-windows' ) ;
wincmd . kill ( 12345 , function ( ) {
console . log ( 'Process Killed' ) ;
} ) ; En este ejemplo, el ID de proceso 12345 sería asesinado. Es importante tener en cuenta que la cuenta de usuario que ejecuta este script de nodo puede requerir privilegios administrativos.
Si está experimentando problemas con los ejemplos, revise el archivo TESTS.md .
Si se encuentra con el evento InvalidInstallation , eche un vistazo al directorio daemon que se crea durante la instalación para asegurarse de que los archivos .exe y .xml estén allí. En algunas circunstancias, principalmente durante _UN_Installation, es posible que el proceso bloquee temporalmente un archivo de registro, lo que evita que Windows lo elimine. En este escenario, simplemente ejecute la desinstalación nuevamente. En la mayoría de los casos, esto solucionará el problema. Si no, elimine manualmente el directorio daemon antes de ejecutar la instalación nuevamente.
Ha habido muchos colaboradores que han hecho todo, desde comprometer características hasta ayudar a recoger Slack mientras me han inundado. Estoy increíblemente aprecio por la ayuda.
Un agradecimiento especial a @arthurblake cuyas modificaciones finalmente se han agregado. Gracias a @hockeytim11, que ayudó a compilar y actualizar un montón de problemas sobresalientes y comenzó a brindar apoyo a las otras bibliotecas de nodo-*.
Winsw y Sudowin son los derechos de autor de sus respectivos dueños. WinSW se distribuye bajo una licencia MIT. Sudowin se distribuye bajo una licencia BSD.
Todos los demás scripts son derechos de autor (c) Corey Butler bajo una licencia MIT.
(La licencia del MIT)
Copyright (c) 2013 Corey Butler
El permiso se otorga, de forma gratuita, a cualquier persona que obtenga una copia de este software y los archivos de documentación asociados (el 'software'), para tratar el software sin restricción, incluidos los derechos de los derechos de usar, copiar, modificar, fusionar, publicar, distribuir, sublicense y/o vender copias del software, y para permitir que las personas a quienes se les proporciona el software para hacerlo, sujeto a las siguientes condiciones: las siguientes condiciones: las siguientes condiciones:
El aviso de derechos de autor anterior y este aviso de permiso se incluirán en todas las copias o porciones sustanciales del software.
El software se proporciona 'tal cual', sin garantía de ningún tipo, expresa o implícita, incluidas, entre otros, las garantías de comerciabilidad, idoneidad para un propósito particular y no infracción. En ningún caso los autores o titulares de derechos de autor serán responsables de cualquier reclamo, daños u otra responsabilidad, ya sea en una acción de contrato, agravio o de otro tipo, que surge, de o en relación con el software o el uso u otros tratos en el software.
