node windows
1.0.0-beta.8
Esta biblioteca pode ser usada para instalar/desinstalar/desinstalar scripts como serviços de fundo do Windows para ambientes de produção . Esta não é uma ferramenta para o desenvolvimento de aplicativos, é uma ferramenta para liberá -los. Esta ferramenta gera um executável que executará seu aplicativo com qualquer versão do Node.js estiver instalada no computador.
Consulte Node-MAC e Node-Linux se precisar suportar esses sistemas operacionais.
Tweet -me (@GoldGloveCB) se você precisar de mim.
 |  |  |  |
Não pode patrocinar? Considere nomear @coreybutler para uma estrela do Github. | |||
Os seguintes recursos estão disponíveis no Node Windows:
exec como sudoer.A maneira recomendada de instalar o Node-Windows é com o NPM, usando a bandeira global:
npm install -g node-windows
Então, na sua raiz do projeto, execute:
npm link node-windows
No entanto; É possível usar o Node Windows sem o sinalizador global (ou seja, instalar diretamente na raiz do projeto). Mais detalhes sobre por que essa não é a abordagem recomendada está disponível ao longo deste Readme.
O uso de módulos de nós nativos no Windows pode ser péssimo. A maioria dos módulos nativos não é distribuída em um formato binário. Em vez disso, esses módulos dependem do npm para construir o projeto, utilizando o Node-GYP. Isso significa que os desenvolvedores precisam instalar o Visual Studio (e potencialmente outros softwares) no sistema, apenas para instalar um módulo nativo. Isso é portátil, mas doloroso ... principalmente porque o próprio Visual Studio tem mais de 2 GB.
O Node-Windows não usa módulos nativos. Existem alguns utilitários binários/exe, mas tudo o necessário para executar tarefas mais complexas é embalado e distribuído em um formato prontamente utilizável. Portanto, não há necessidade de Visual Studio ... pelo menos não para este módulo.
O Node-Windows tem um utilitário para executar scripts Node.js como Serviços Windows. Observe que, como todos os serviços do Windows, criar um requer privilégios administrativos. Para criar um serviço com Windows Node, prepare um 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 ( ) ; O código acima cria um novo objeto Service , fornecendo um nome e uma descrição bonitos. O atributo script identifica o script node.js que deve ser executado como um serviço. Ao executar isso, o script será visível no utilitário do Windows Services.
O objeto Service emite os seguintes eventos:
No exemplo acima, o script ouve o evento install . Como este evento é demitido quando uma instalação de serviço está concluída, é seguro iniciar o serviço.
Os serviços criados pelo Node-Windows são semelhantes à maioria dos outros serviços em execução no Windows. Eles podem ser iniciados/interrompidos no utilitário de serviço do Windows, por meio de comandos NET START ou NET STOP ou até mesmo gerenciados usando o utilitário SC.
Pode-se desejar especificar os interruptores da linha de comando para o seu script. Você pode fazer isso definindo as scriptOptions na configuração do serviço:
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'
} ) ;Às vezes, você pode fornecer um serviço com dados estáticos, passados sobre a criação do serviço. Você pode fazer isso definindo variáveis de ambiente na configuração do serviço, como mostrado abaixo:
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
}
} ) ;Você também pode fornecer uma matriz para definir várias variáveis de ambiente:
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
} ]
} ) ; Há momentos em que você pode especificar um node específico para o uso para executar seu script. Você pode fazer isso definindo o execPath na configuração do serviço, como mostrado abaixo:
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'
} ) ;Se você precisar especificar um usuário específico ou credenciais específicas para gerenciar um serviço, os seguintes atributos podem ser úteis.
O atributo user é um objeto com três teclas: domain , account e password . Isso pode ser usado para identificar qual usuário a biblioteca de serviços deve usar para executar comandos do sistema. Por padrão, o domínio é definido como o nome do computador local, mas pode ser substituído por um domínio do Active Directory ou LDAP. Por exemplo:
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' ;
... A conta e a senha devem ser explicitamente definidas se você deseja que o módulo de serviço execute os comandos como um usuário específico. Por padrão, ele será executado usando a conta de usuário que lançou o processo (ou seja, que lançou node app.js ).
Se você deseja instruir o Winsws a permitir logins de conta de serviço, especifique allowServiceLogon: true . Isso é desativado por padrão, pois alguns usuários tiveram problemas executando isso sem logons de serviço.
O outro atributo é sudo . Este atributo possui uma única propriedade chamada password . Ao fornecer isso, o módulo de serviço tentará executar comandos usando a conta de usuário que iniciou o processo e a senha dessa conta. Isso deve ser usado apenas para contas com privilégios 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' ;
...O serviço também pode ser dependente de outros serviços do Windows.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
dependsOn : [ "serviceA" ]
} ) ;A desinstalação de um serviço criado anteriormente é sintaticamente semelhante à instalação.
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 ( ) ;O processo de desinstalação remove apenas arquivos específicos do processo. Ele não exclui seu script node.js!
Muitas coisas!
Processos e monitoramento de longa execução:
A recuperação de serviço integrada para o Windows Services é bastante limitada e não pode ser facilmente configurada a partir do código. Portanto, o Node-Windows cria um invólucro ao redor do script node.js. Este invólucro é responsável por reiniciar um serviço com falha de maneira inteligente e configurável. Por exemplo, se o seu script travar devido a um erro desconhecido, as janelas do nó tentarão reiniciá-lo. Por padrão, isso ocorre a cada segundo. No entanto; Se o script tiver uma falha fatal que o coloque repetidamente, ele adicionará uma sobrecarga desnecessária ao sistema. O Node-Windows lida com isso aumentando o intervalo de tempo entre as reinicializações e o limite máximo de reinicializações.
Reinicia mais inteligente que não atingirá seu servidor:
Usando as configurações padrão, o Node-Windows adiciona 25% ao intervalo de espera sempre que precisar reiniciar o script. Com a configuração padrão (1 segundo), a primeira tentativa de reinicialização ocorre após um segundo. O segundo ocorre após 1,25 segundos. O terceiro após 1,56 segundos (1,25 aumentou 25%) e assim por diante. Tanto o tempo de espera inicial quanto a taxa de crescimento são opções de configuração que podem ser passadas para um novo Service . Por exemplo:
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
script : 'C:\path\to\helloworld.js' ,
wait : 2 ,
grow : .5
} ) ;Neste exemplo, o período de espera começará em 2 segundos e aumentará em 50%. Portanto, a segunda tentativa seria 3 segundos depois, enquanto a quarta seria 4,5 segundos depois.
Não faça você mesmo!
A reciclagem repetitiva pode continuar para sempre com um roteiro ruim. Para lidar com essas situações, o Node Windows suporta dois tipos de tampas. O uso de maxRetries limitará o número máximo de tentativas de reinicialização. Por padrão, isso é ilimitado. Definê -lo como 3 diria ao processo para não reiniciar um processo depois de falhar 3 vezes. Outra opção é maxRestarts , que limita o número de reinicializações tentadas em 60 segundos. Por exemplo, se isso estiver definido como 3 (o padrão) e o processo trava/reiniciará repetidamente, o Node-Windows interromperá as tentativas de reinicialização após o terceiro ciclo em uma janela de 60 segundos. Ambas as opções de configuração podem ser definidas, assim como wait ou grow .
Por fim, um atributo chamado abortOnError pode ser definido como true se você quiser que seu script não seja reiniciado quando sair com um erro.
O Node-Windows usa o utilitário winsw para criar um .exe exclusivo para cada script node.js implantado como um serviço. Um diretório chamado daemon é criado e preenchido com myappname.exe e myappname.xml . O arquivo XML é uma configuração para o executável. Além disso, winsw criará alguns logs para si neste diretório (que são visíveis no log de eventos).
O arquivo myappname.exe inicia o wrapper Node-Windows, responsável pelo monitoramento e gerenciamento do script. Como esse arquivo faz parte do Node Windows, a movimentação do diretório Node-Windows pode resultar no arquivo .exe não conseguir encontrar o script node.js. No entanto; Isso não deve ser um problema se o Node Windows for instalado globalmente, de acordo com as instruções de instalação recomendadas.
Todos esses arquivos específicos de daemon são criados em um subdiretório chamado daemon , criado no mesmo diretório em que o script Node.js é salvo. A desinstalação de um serviço removerá esses arquivos.
Registro de eventos
Os serviços criados com o Node Windows têm dois logs de eventos que podem ser vistos através do Visualizador de Eventos do Windows. Uma fonte de log denominada myappname.exe fornece log básico para o arquivo executável. Pode ser usado para ver quando todo o serviço inicia/pare ou tem erros. Um segundo log, nomeado após o nome do seu serviço (ou seja, o nome do meu aplicativo), é usado pelo monitor Node-Windows. É possível gravar neste log no script Node.js usando o log de eventos Node-Windows.
O novo a partir da v0.1.0 é um utilitário de log de eventos não baseado em C ++ . Esse utilitário pode gravar no log de eventos, tornando seus logs visíveis no visualizador de eventos. Ele usa EventCreate sob o capô.
Para criar um 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.' ) ;Parece parecido com:
Algumas opções menos usadas também estão disponíveis no registro de eventos Node-Windows.
log . auditSuccess ( 'AUser Login Success' ) ;
log . auditFailure ( 'AUser Login Failure' ) ; Cada método de tipo de log (informação, aviso, erro, auditoria e auditfailure) aceita opcionalmente dois argumentos adicionais, incluindo um código e retorno de chamada . Por padrão, o código do evento é 1000 , se não for especificado de outra forma. Para fornecer um código de evento personalizado com uma mensagem de log e escrever essa mensagem no console, o código a seguir pode ser usado:
Aviso: parece que o EventCreate suporta apenas IDs personalizados <= 1000.
log . info ( 'Something different happened!' , 700 , function ( ) {
console . log ( 'Something different happened!' ) ;
} ) ; Por padrão, os logs de eventos fazem parte do escopo APPLICATION . No entanto; Também é possível usar o log SYSTEM . Para fazer isso, um objeto de configuração deve ser passado para o novo log:
var EventLogger = require ( 'node-windows' ) . EventLogger ;
var log = new EventLogger ( {
source : 'My Event Log' ,
eventLog : 'SYSTEM'
} ) ;Os logs de eventos de aviso produzidos pelo invólucro podem ser suprimidos desativando -o ao criar o serviço. Os logs de aviso são ativados por padrão.
var svc = new Service ( {
name : 'Hello World' ,
description : 'The nodejs.org example web server.' ,
disableWarningLogs : true ,
} ) ;Node Windows Navios com vários comandos para simplificar tarefas no MS Windows.
Elevate é semelhante ao sudo no Linux/Mac. Ele tenta elevar os privilégios do usuário atual a um administrador local. Usar isso não requer uma senha, mas exige que o usuário atual tenha privilégios administrativos. Sem esses privilégios, o comando falhará com um erro access denied .
Em sistemas com o UAC ativado, isso pode levar ao usuário permissão para prosseguir:
Sintaxe :
elevate(cmd[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . O sudo age de maneira semelhante ao sudo no Linux/Mac. Ao contrário do Elevate , requer uma senha, mas não solicitará ao usuário permissão para prosseguir. Como o Elevate , isso ainda requer privilégios administrativos para o usuário, caso contrário, o comando falhará. A principal diferença entre isso e elevate () é o prompt.
Sintaxe :
sudo(cmd,password[,options,callback])
require('child_process').exec(cmd,<OPTIONS>,callback) .require('child_process').exec(cmd,options,<CALLBACK>) . Este comando assíncrono determina se o usuário atual possui privilégios administrativos. Ele passa um valor booleano para o retorno de chamada, retornando true se o usuário for um administrador ou false se não for.
Exemplo
var wincmd = require ( 'node-windows' ) ;
wincmd . isAdminUser ( function ( isAdmin ) {
if ( isAdmin ) {
console . log ( 'The user has administrative privileges.' ) ;
} else {
console . log ( 'NOT AN ADMIN' ) ;
}
} ) ; O método da lista consulta o sistema operacional para uma lista de processos em execução.
var wincmd = require ( 'node-windows' ) ;
wincmd . list ( function ( svc ) {
console . log ( svc ) ;
} , true ) ; Isso retorna uma variedade de processos de execução. O fornecimento do argumento true opcional no exemplo acima fornece uma lista com saída detalhada. A saída é específica para a versão do sistema operacional. Aqui está um exemplo de saída detalhada em um computador 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'
} ] A saída regular (não verbose) normalmente fornece o ImageName , PID , SessionName , Session# , MemUsage e CPUTime .
Este método matará um processo por PID .
var wincmd = require ( 'node-windows' ) ;
wincmd . kill ( 12345 , function ( ) {
console . log ( 'Process Killed' ) ;
} ) ; Neste exemplo, o ID do processo 12345 seria morto. É importante observar que a conta de usuário que executa esse script de nó pode exigir privilégios administrativos.
Se você estiver com problemas com os exemplos, revise o arquivo TESTS.md
Se você estiver encontrando o evento InvalidInstallation , dê uma olhada no diretório daemon criado durante a instalação para garantir que os arquivos .exe e .xml estejam lá. Em algumas circunstâncias, principalmente durante _un_installation, é possível que o processo bloqueie temporariamente um arquivo de log, que impede que as janelas o removam. Nesse cenário, basta executar a desinstalação novamente. Na maioria dos casos, isso resolverá o problema. Caso contrário, remova manualmente o diretório daemon antes de executar a instalação novamente.
Houve muitos colaboradores que fizeram de tudo, desde cometer recursos até ajudar a pegar folga enquanto eu estava inundado. Agradeço incrivelmente pela ajuda.
Agradecimentos especiais a @arthurblake, cujas modificações foram finalmente adicionadas. Graças a @hockeytim11, que ajudou a compilar e atualizar vários problemas pendentes e começou a trazer suporte para as outras bibliotecas de nó.
Winsw e Sudowin são os direitos autorais de seus respectivos proprietários. O Winsws é distribuído sob uma licença do MIT. Sudowin é distribuído sob uma licença BSD.
Todos os outros scripts são direitos autorais (c) Corey Butler sob uma licença do MIT.
(A licença do MIT)
Copyright (c) 2013 Corey Butler
A permissão é concedida, gratuita, a qualquer pessoa que obtenha uma cópia deste software e arquivos de documentação associados (o 'software'), para lidar com o software sem restrição, inclusive sem limitação os direitos de usar, copiar, modificar, mesclar, publicar, distribuir, mobilizar o software e/ou vender cópias do software e permitir que as pessoas a quem
O aviso de direitos autorais acima e este aviso de permissão devem ser incluídos em todas as cópias ou em partes substanciais do software.
O software é fornecido 'como está', sem garantia de qualquer tipo, expresso ou implícito, incluindo, entre outros, as garantias de comercialização, aptidão para uma finalidade específica e não innoculação. Em nenhum caso os autores ou detentores de direitos autorais serão responsáveis por qualquer reclamação, danos ou outro passivo, seja em uma ação de contrato, delito ou não, decorrente de, fora ou em conexão com o software ou o uso ou outras negociações no software.
