Tomcat部署策略

Question

这是关于Tomcat部署的一个不同的问题。它已被部分早期问题所覆盖，但我想在那里实际完成Tomcat部署。

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

1. WAR部署到Tomcat webapps 目录。停止Tomcat，重命名现有WAR文件，删除webapps（ appBase ）下的现有app目录，复制新WAR并重新启动Tomcat。 好处：每个人都可以理解部署WAR。 我可以看到两个缺点。

   答：如果WAR包含特定于部署的部署信息，例如数据库连接信息，则开发环境需要某种版本和构建控件，以确保将正确的特定于部署的信息放入WAR文件中。这可能会变得复杂。

   B.许多步骤，并不困难，但每一步都是潜在的错误点。

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

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

谢谢， - = B

Answer 1

我是这样做的：

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

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

-Denvironment=production。

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

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

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

Answer 2

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

在较大的商店中，dev和ops之间通常有一个巨大的中国墙，第二种方法被选中。不允许开发人员接触生产服务器。

Answer 3

我使用kwateeSDCM自动化参数实例化，例如DB连接信息和tomcat上的部署。有一篇有趣的博客文章讨论deploying war on multiple tomcat instances。