Question

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

当我的团队继续扩展时，有更好的方法吗？我已经考虑过编译器标志/ args，但它似乎并不健全。

Answer 1

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

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

你已经发现了环境变量，这几乎是“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”的系统属性，否则将使用它，此时App将加载它

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

SHIP IT！

Answer 2

我可以看到两个场景

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

假设您的应用名为foo

解决方案1 

它的优势在于您的应用程序可以按原样放置在任何受支持的服务器上（所有服务器都包含属性文件）。您的商家名称为foo.dev.properties，foo.test.properties，foo.prod.properties，foo.damien.properties，foo.bob.properties。

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

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

解决方案2

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

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

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

您可以安全地混合使用这些解决方案，以便获得您和您的团队更灵活的感觉。

在多个服务器上运行一个文件

2 个答案: