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 后更改属性。它还允许将数据库密码等敏感信息完全排除在源代码控制之外。