0

现在我的团队处理大约 4-5 个不同的服务器和大约 2-3 个不同的数据库服务器，我们正在使用环境变量来决定我们在哪个服务器上以及要使用什么服务器配置。

随着我的团队不断扩大，有没有更好的方法来做到这一点？我已经考虑过编译器标志/参数，但它似乎并不那么健壮。

4

2 回答 2

1

从我的角度来看，在 java 中，你基本上有 3 种方法来破解这个 cookie：

  1. 环境变量
  2. -D JVM 参数（系统属性）
  3. 属性文件

您已经发现了环境变量，这几乎是获得您想要的效果的“unix 方式”；与通用二进制文件不同的配置，为正在执行的环境定制正在运行的应用程序。

系统属性实际上是环境变量的 Java“道德等价物”。它们通过应用程序命令行上的 -D 参数进入，例如...

java -Dlogback.configurationFile=/opt/dm/logback.xml -cp app.jar org.rekdev.App

在 Java 中处理http://docs.oracle.com/javase/tutorial/essential/environment/properties.html的显式属性文件是您经常看到的第三种变体，它与 -D 结合使用可以获得类似默认行为的东西，可以在从命令行运行时。这就是上面 logback.xml 配置的基本情况，JAR 文件里面有一个 logback.xml 将被使用，除非存在名为“logback.configurationFile”的系统属性，此时应用程序将加载它.

当您尝试弄清楚如何在多服务器环境中保持这一切同步并正常工作时，请考虑使用 chef http://wiki.opscode.com/display/chef/Home进行部署并将每个厨师控制的特定环境的定制。将厨师“食谱”放在版本控制中，瞧，配置管理。

装运它！

于 2012-09-06T19:42:57.673 回答
0

我可以看到两种情况

  1. 您在包中嵌入了所有不同的属性（可以是 war、ear、jar 或文件系统/yourapp/etc/）
  2. 您只嵌入了一个属性文件，并且这个属性文件是在构建期间创建的（使用 ant 或 maven）

假设您的应用名为foo

解决方案 1

它的优点是您的应用程序可以按原样放置在任何受支持的服务器上（所有在您的应用程序包中都有属性文件的服务器）。您的属性将被命名为foo.dev.properties, foo.test.properties, foo.prod.properties, foo.damien.properties, foo.bob.properties。

另一个优点是每个工作的开发人员都有自己的开发文件，他可以安全地推送到 svn/git/whatever 上，并确保其他开发人员不会破坏他的配置。

在运行时，应用程序可以检查-D参数甚至动态检索主机名，以便加载正确的属性文件。

解决方案 2

它的优点是您的包不会被不必要的属性文件污染。

您必须配置很多 ant 任务/maven 目标才能为特定环境构建。您的源目录中还将包含环境的属性文件，但您的应用程序只会附带一个。这个foo.properties只有值的占位符，并且将使用foo.ENV.properties正确的 ant 任务/maven 目标在其中推断值。

在我的实际工作和之前的工作中，我们确实使用了解决方案 1，我认为它带来了灵活性。某些参数（如数据库用户/密码）是直接从 Unix 服务器上的环境变量中获取的（因此只有服务器管理员知道凭据）。

您可以安全地混合这些解决方案，以达到您认为对您和您的团队有更大灵活性的地方。

于 2012-09-06T19:43:08.217 回答