我们有一个生产环境，其中外部负载平衡的 Tomcat 服务器在多台服务器上运行，提供 HTTP 请求并维护持续会话。
由于缺乏完整的构建和部署流程（不幸的是，我看不到这在不久的将来在任何地方发生！），有一个 Ops 团队负责复制 JSP / 类 / 静态资源 / 属性文件，甚至手动更改 struts-config.xml（有时是 web.xml ！）。我们不构建 WAR！！
由于这是手动密集型工作，人为错误会产生很多问题，因为必须在多个环境中执行相同的步骤（在部署日，至少可能需要大约 10 台机器），这使得调试更加复杂。
我确实知道我们远非理想的生产环境（就此而言，甚至是实际的生产环境），但我只是在集思广益，并认为如果我们可以在高速 SAN 上安装（复制）Tomcat 并将其作为共享驱动器安装在每台服务器上，这样至少更改将同时传输到所有节点。
请让我知道您的想法，尤其是对这种方法的批评。
谢谢。
答案1
虽然可以在 Tomcat 部署中共享一些目录（请参阅这个问题)，共享您想要共享的内容并不安全，并且如果您小心地本地化 ./work 和 ./temp 目录，它可能会起作用，但是如果您尝试这样做，您将遇到难以排除故障的问题，更不用说给您的基础设施引入单点故障了。
作为一名开发/运营人员，我很幸运能够与开发人员密切合作，并且已经为许多非常复杂和混乱的应用程序提出了自动化部署。我在这方面的建议是，如果您能让团队接受自动化部署的目标，那么就从小处做起，每次迭代都自动化一点，随着您的开发团队和运营团队习惯了这个过程并解决了问题。
对于您在此处遇到的具体问题，我给出的建议是，如果可以在生产机器上安装单个共享驱动器，那么最好的解决方案可能是在共享驱动器上维护 tomcat 设置的规范映像，然后编写一些（可能非常简单的）脚本，在发生更改时更新每个应用服务器上部署的全部或部分 tomcat。这样可以更轻松地逐步推出更改（如果您这样做），中止不起作用的更改，并验证所有应用服务器上的所有内容是否同步。
如果您的开发人员可以获得该共享驱动器的写入权限，您甚至可以帮助操作人员，为他们省去容易出错的编辑过程，只需要求他们部署特定文件或目录即可。一旦您拥有了该基础设施和流程，您就可以开始自动化：开发人员可以编写自动化脚本并将其保存在共享驱动器上，供操作人员运行并从那里构建。
答案2
我对 tomcat 不太感兴趣，但也许我可以分享我为类似任务所做的事情：
只需准备包含所有更新的文件夹（就像我可能有的
seed12/etc/apache2/apache2.conf和seed12/var/www/index.php） - 只有您更新的文件，放在相应的文件夹中，始终从根目录开始。然后编写对每台机器执行此操作的简单脚本
scp -r。如果需要，您可以向脚本添加一些 ssh 命令来重新启动服务。
一个额外的优点是它在某种程度上是自我文档化的——只需保留那些“种子”文件夹，从而记录所有更改。
至于对您的方法的批评（您问的！） - 它会在您原本多余的设置中增加不必要的故障点。
答案3
您不想这样做，因为它可能会一次性迁移所有内容，日志记录会很复杂，回滚也会变得混乱。使用 murder gem 来解决这个问题。