Tomcat部署策略

Question

这是一个关于Tomcat部署的稍微不同的问题。前面的问题已经部分讨论了这个问题，但我想从实际完成Tomcat部署的那些人那里谈谈。

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

1. WAR部署到Tomcat的webapps DIR。 Tomcat停止，现有的WAR文件被重命名，webapps（appBase）下的现有应用程序目录被删除，新的WAR被复制并且Tomcat重新启动。好处：部署WAR似乎被大家所了解。 我可以看到两个缺点。如果WAR包含部署特定信息（如数据库连接信息），则开发环境需要某种版本和构建控制，以确保正确的特定于部署的信息进入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和针对不同部署环境的配置文件。构建工具确保可重复构建并防止您犯错误。

在较大的商店中，开发者和操作者之间通常会有一个很大的中国墙，选择第二种方法。开发人员不允许触摸生产服务器。

Answer 3

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