Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/javascript/443.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Javascript 监视远程更改并在本地自动复制它们_Javascript_Node.js_Fs_Forever - Fatal编程技术网

Javascript 监视远程更改并在本地自动复制它们

Javascript 监视远程更改并在本地自动复制它们,javascript,node.js,fs,forever,Javascript,Node.js,Fs,Forever,我有一个Node.js项目,它是客户端机器的本地项目,我希望能够监视远程位置对两个文件(server.js和logging.js)的更改,自动停止节点服务器,在本地复制远程更改的文件,并使用新复制的本地文件重新启动服务器 这将在我们的生产环境中用于部署sprint测试结束的更改,这样我们就不必定期为我们的服务部门运行安装 我尝试过使用ever&Nodemon,这两个工具都很乐意监视远程文件的更改,但只重新启动本地(未更改)副本,所以这些更改不会传播到本地副本 我计划在生产环境中使用Forever

我有一个Node.js项目,它是客户端机器的本地项目,我希望能够监视远程位置对两个文件(server.js和logging.js)的更改,自动停止节点服务器,在本地复制远程更改的文件,并使用新复制的本地文件重新启动服务器

这将在我们的生产环境中用于部署sprint测试结束的更改,这样我们就不必定期为我们的服务部门运行安装

我尝试过使用ever&Nodemon,这两个工具都很乐意监视远程文件的更改,但只重新启动本地(未更改)副本,所以这些更改不会传播到本地副本

我计划在生产环境中使用Forever,以帮助解决我们偶尔遇到的本地服务器崩溃问题,因此理想情况下,任何解决方案都可以通过Forever的
-c
开关运行。我还研究了使用它们的底层代码,但没有看到在更改时复制文件的能力

我们的部署环境都是基于Windows的,所以我正在使用,但是,我们试图对我们正在运行的应用程序不依赖于平台

可能类似于:

forever start--watch\\server\share\server.js--watch\\server\share\logging.js-c[remote monitoring copy Local package name]server.js

我希望找到一个已经存在的NPM包,这样我就不必自己动手了

很接近我要找的,但他监控的是一个日志文件,而不是服务器本身


这与我想解决的问题非常相似。

这里需要两件事:

  • 将文件与某个远程位置同步
  • 当服务器发生更改时重新启动服务器
  • 你几乎没有办法做到这一点

    例如,您可以在服务器上托管一个git repo,并从某个远程位置推送到它,以更新代码并触发将重新部署和重新启动服务器的git钩子

    或者,您可以定期在服务器上运行脚本,以检查远程repo、更新本地repo并重新启动服务器

    或者,您可以使用一个连接到不断变化的repo的CI服务,运行测试并在测试通过时部署

    请注意,在大多数情况下,我谈论的是代码回购,而不仅仅是两个具有硬编码名称的文件,因为能够重构代码、添加文件等更能证明未来,但您也可以使用rsync、scp或sftp复制文件。有很多方法可以做到这一点,但在其中添加一些结构,并使用一些经过测试的工具是很有用的,这些工具可以扩展,并且从长远来看易于维护


    无论你做什么,只要记住一件事:确保你可以在运行之前验证你正在下载的内容。因此,除非您对所有内容都进行了加密签名,否则不要通过HTTP下载任何内容。并确保签名过程也是安全的。Git在这方面非常好,因为你可以验证你下载的内容。

    我们最终放弃了永远使用,我无法让它与Nodemon一起正常工作,同时观看远程目录。我们认为,能够在命令上推动代码更改比在服务器崩溃时重新启动服务器(这种情况根本不经常发生)更重要。当我们执行代码推送时,服务器在任何情况下都会重新启动

    我创建了一个名为serverMon.js的服务器监控文件,其中包含以下内容(请参阅下面的引文,以获取我为自己使用而修改的代码的链接):

    最后,我们在Taskmanager中运行了三个node.exe实例,一个运行nodemon,它在监视第二个serverMon.js的同时监视远程文件的更改,然后第三个server.js作为serverMon.js的子进程启动

    引文:

    const fs = require('fs');
    const child_process = require('child_process');
    
    //production path
    var widgetPath = '\\\\server\\share\\sbSerialWidget\\';
    
    var widgetFiles = ['sbNodeLog.js', 'server.js'];
    var passedInFileName, infile, outfile;
    
    for(var i = 0; i < widgetFiles.length; i++){
        fs.createReadStream(widgetPath + widgetFiles[i]).pipe(fs.createWriteStream(widgetFiles[i]));
    }
    //spawn server.js passing it's stdio, stderr, stdout back through this node instance
    server = child_process.spawn('node', ['server.js'], {stdio: 'inherit'}, function (error, stdout, stderr) {
        if (error) {
            console.log(error.stack);
            console.log('Error code: ' + error.code);
            console.log('Server.js error received: ' + error.signal);
        }   
        console.log('Server.js STDOUT: ' + stdout);
        console.log('Server.js STDERR: ' + stderr);  
    });
    
    server.on('exit', function (code) {
        server.kill('SIGTERM');
        console.log('Child process exited with exit code '+code);
    });
    
    REM @echo off
    REM cls
    GOTO START
    
    :START
    IF EXIST "%ProgramFiles%\sbserialwidget\server.js" GOTO WIN32
    IF EXIST "%ProgramFiles(x86)%\sbSerialWidget\server.js" GOTO WIN64
    ECHO End start
    GOTO END
    
    :WIN32
    cls
    echo Inside 32 bit
    PUSHD "%ProgramFiles%"\sbserialwidget
    GOTO RUNVBS
    GOTO END
    
    :WIN64
    echo Inside 64 bit
    PUSHD "%ProgramFiles(x86)%"\sbSerialWidget
    GOTO RUNVBS
    GOTO END
    
    :RUNVBS
    echo Inside RUNVBS
    start runNodemon.vbs
    GOTO END
    
    :END
    popd
    EXIT