Tomcat部署策略

Question

这是一个关于 Tomcat 部署的稍微不同的问题。之前的问题已经部分涵盖了它，但我想从那些实际做过 Tomcat 部署的人那里来。

在我的组织中，我看到了两种类型的部署。

1. WAR 部署到 Tomcat webapps 目录。 Tomcat 停止，现有的 WAR 文件被重命名，webapps (appBase) 下的现有应用程序目录被移除，新的 WAR 被复制进来，并重新启动 Tomcat。 好处：部署 WAR 似乎每个人都理解。 我可以看到两个缺点。

   A. 如果 WAR 包含特定于部署的信息，例如 DB 连接信息，则开发环境需要某种版本和构建控制，以确保正确的特定于部署的信息进入 WAR 文件。这可能会变得复杂。

   B. 很多步骤，不难，但每一步都有潜在的错误点。

2. appBase 指向应用程序文件系统，特定于部署的信息保存在其他地方。应用程序可部署文件系统或 WAR 文件被复制到 Tomcat 框上的某个位置。 Tomcats Servlet.xml 中应用程序的 appBase 属性被修改为指向新部署的代码。复制后Tomcat会重启。 所有特定于部署的配置信息都保存在不受部署影响的 [tomcat_root] 下的单独目录中。如果需要任何更改，可以随时进行编辑，然后重新启动 Tomcat 以获取更改。优点：非常简单，通常只有一步，最多两步 缺点：可能需要在部署机器上编辑文件。这在许多生产环境中是不允许的，或者必须由系统管理员而不是部署人员来完成。如果发生某些事情，可能会导致延误、政治问题和指责 出错了。

正如我上面所说，我想听听任何一种方法的真实体验。我绝对赞成第二种方法。我想知道第一个的吸引力是什么 它似乎更容易出错。

谢谢， -=b

Answer 1

我是这样做的：

在源代码管理中，我有每个环境的属性文件。例如production-environment.properties、qa-environment.properties等。所有属性文件都在resources源目录中，并包含在WAR文件中。

Tomcat 以选择环境的系统属性启动，例如：

-Denvironment=production.

应用程序根据系统属性选择在运行时使用的属性文件。

不需要特殊的构建或部署步骤。每个构建一个 WAR 文件用于所有环境。

这种方法的另一个方面是 WAR 文件中的属性可以被系统属性覆盖。这允许操作在 WAR 部署后更改属性。它还允许将数据库密码等敏感信息完全排除在源代码控制之外。

Answer 2

第一种方法可以通过自动化打包过程来管理。我通常将 Maven 与针对不同部署环境的配置文件一起使用。构建工具可确保可重现的构建并防止您犯错误。

在较大的商店中，通常在 dev 和 ops 之间有一堵巨大的中国墙，因此选择了第二种方法。不允许开发者接触生产服务器。

Answer 3

我使用 kwateeSDCM 来自动化参数实例化，例如数据库连接信息和在 tomcat 上的部署。有一篇有趣的博客文章谈到了deploying war on multiple tomcat instances。