我们有一个生产环境，在多台服务器上运行外部负载均衡的Tomcat服务器，为HTTP请求提供服务，并维护stick会话。
由于缺乏完整的构build和部署过程（不幸的是我不会在近期任何地方看到这种情况），还有一个Ops团队负责复制JSP / Classes /静态资源/属性文件，甚至是改变struts – config.xml（有时是web.xml！）手动。 我们不build立战争！
由于是人工密集型工作，因为人为错误会产生很多问题，因为在多个环境中必须执行相同的步骤（在部署当天，可能至less有10台左右的机器），这使得debugging更为复杂。
我明白我们远非理想的生产环境（就此而言甚至是实际的生产环境），但是我只是头脑风暴，想如果我们可以在高速SAN上安装（复制）Tomcat并将其作为共享驱动器安装服务器，以便至less这些更改将同时转到所有节点上。
请让我知道你的想法，特别是在这种方法的批评。
谢谢。
尽pipe可以共享Tomcat部署中的某些目录（请参阅此问题 ），但共享您希望共享的目录并不安全，而如果您注意本地化./work和./temp目录，如果您尝试使用它，则会要求您尝试排除故障，更不要说为您的基础架构引入单点故障。
作为一名开发/操作人员，我很幸运能够与开发人员密切合作，并为一些非常复杂和杂乱的应用程序提供了自动部署。 我在这方面的build议是，如果你可以让你的团队购买到部署自动化的目标，那么每当你的开发团队和你的操作团队习惯了这个过程，解决这个问题。
对于我在这里提出的确切问题的build议，如果可以在生产计算机上安装一个共享驱动器，最好的解决办法可能是在共享驱动器上维护tomcat安装的规范映像，然后写入一些（可能是简单的）脚本在更改时更新每个应用程序服务器上部署的全部或部分tomcats。 这样可以更轻松地逐步推出更改（如果这样做的话），放弃不能解决的更改并validation所有应用程序服务器上的所有内容都是同步的。
如果您的开发人员可以访问该共享驱动器，您甚至可以帮助操作人员摆脱容易出错的编辑过程，只需要让他们部署特定的文件或目录即可。 一旦你获得了这个基础架构和stream程，你就可以开始自动化事情了：开发者可以编写自动化脚本，并将它们保存在共享驱动器上供操作人员运行，然后从那里开始构build。
我不是进入tomcat，但也许我可以分享我正在做的类似的任务：
只准备所有的更新文件夹（如我可能有seed12/etc/apache2/apache2.conf和seed12/var/www/index.php ） – 只有你更新的文件，放在相应的文件夹，始终从根。
然后制作一个简单的脚本，对每台机器执行scp -r 。 如果需要，您可以添加一些ssh命令来重新启动服务。
一个额外的好处是它有点自我logging – 只是保留这些“种子”文件夹，因此有所有更改的日志。
至于批评（你问！）你的方法 – 它增加了不必要的失败点到你的其他冗余设置。
你不想这样做，它可以一次性迁移一切，日志会变得复杂，回滚会变得混乱。 使用谋杀gem分开这一点。