在同一构建过程中为 Tomcat 创建和部署环境特定的 war 构建

发布于 2024-09-08 23:36:13 字数 564 浏览 7 评论 0原文

我希望能够构建一个 war 文件并将其部署在多个环境中。我知道我可以创建一个 ant 任务来获取环境,并将文件包含在 war 中,或者根据需要替换令牌。然而,这会导致与环境(开发、QA、DR、产品等)一样多的不同 war 文件。这似乎会创建一个从未经过测试的生产战争文件。是的,只有环境特定的属性应该更改,但是如果出现问题,则无法仅在开发中部署该 war 文件。

有没有一种简单的方法来创建一个 war 文件并使所有配置文件成为外部文件?我应该在startup.sh 脚本中设置该位置吗?这似乎需要更改代码才能从该外部位置获取文件,并且我不确定这如何与某些特定于框架的项目(例如数据库配置)一起使用。目前,我使用开发配置创建一个 war 文件,然后将其部署到每个环境,以便它分解,然后运行一个脚本来复制环境特定的属性文件,然后重新启动 tomcat 以便这些属性生效,但这并没有这似乎不是一个好的解决方案。

我需要的属性文件是数据库配置、应用程序特定属性(例如邮件服务器的位置)和 log4j.properties。

我将它们部署在运行 Tomcat 的 Linux 服务器上,并且我拥有对服务器的完全访问权限,因此我可以创建我需要的任何 ant、bash 等脚本。

I want to be able to build a war file and deploy it in multiple environments. I know I can create an ant task to get the environment and either include the files in the war, or replace the tokens as necessary. However, this would lead to as many different war files as environments (dev, QA, DR, prod, etc...). It seems that this would create say a production war file that has never been tested. Yes, only the environment specific properties should change, but there's no way to just deploy that war file in dev if there are issues.

Is there an easy way to create one war file and make all of the config files external? Should I set there location in the startup.sh script? This would seem to require code changes to get the files from that external location, and I'm not sure how this would work with some framework specific items, like the database config. Currently, I create one war file with the dev config, then I deploy it to each environment so it gets exploded, then I run a script to copy the environment specific properties files, then restart tomcat so these properties take effect, but this doesn't seem like a good solution.

The properties files I need are the database configuration, application specific properties like location of the mail server, and the log4j.properties.

I'm deploying these on Linux servers running Tomcat and I have full access to the servers, so I can create any ant, bash, etc. scripts that I need.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

枫以 2024-09-15 23:36:13
  1. 您可以做的一件事是将 JNDI 用于数据源等内容,以便您的应用程序从容器获取资源。但该解决方案不适用于所有已配置的内容。

总的来说,我认为为每个环境创建一个战争/耳朵是“正常”的做法。我不同意你的说法,即你正在“部署一个从未经过测试的战争文件”。您正在部署一个 war 文件,其中的配置尚未经过测试更准确。也许您可以编写一些单元测试来验证生产配置并在构建产品战争时运行它们,以便您可以检查“测试产品战争”要求...

  1. One thing you can do is use JNDI for things like data sources, so your application gets its resources from the container. but that solution wont work for all things that get configured.

In general I think it is 'normal' practice to create a war/ear for each environment. I don't agree with your statement that you are 'deploying a war file that's never been tested'. You are deploying a war file where the configuration hasn't been tested is more accurate. Maybe you can write some unit tests that verify the production configurations and run them when you build your prod war so you can check off your 'test prod war' requirement...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文