经典方法是具有多个属性文件，每个属性文件都基于环境，并且基于环境变量（DEV，PROD ...），则可以在启动应用程序时选择读取它们的位置（例如使用Spring概要文件）。另一方面，如果您使用容器来部署应用程序，据说这种配置应该来自环境本身（使用应用程序读取的环境变量），因此映像在环境之间不会改变。
每种方法的优缺点是什么？容器方案是否有“最佳”方法？
#1 楼
谁说属性文件和环境变量在哪里互斥？“我的应用程序配置存储在哪里？”之间有区别。而“我的应用程序将配置从哪里获取？”
最可能的结果是，每个人都可能应该只是继续使用配置文件作为存储机制来做（考虑长期，持续的状态只要环境存在即可。
但是，与其将配置文件放到应用程序上下文中并让它运行应用程序，不应该只是期望那些变量在环境中已经可用。它启动。
这意味着您需要两个部署工作流程-
我要通过X变更控制过程将应用程序部署到环境中，并且不管用Z工具执行Y审阅。
我通过执行变更控制流程，并使用C工具进行B审阅，相同的过程，不同的结果，从而将环境配置部署到环境中。
在c之类的工具中使用管理环境变量作为键值对的示例onsul，如果您将配置文件存储在git中，则使用git2consul之类的工具在更新配置时将其保存到环境中。配置文件，那么您可以通过使用consul-template之类的东西构建部署过程来避免随应用程序一起发送配置文件的多个副本，该部署过程具有将consul值转换回文件的功能。
#2 楼
我们的方法是每个运行的应用程序都有3个部分（或工件）。
我们正在开发的应用程序。无论环境如何，都是一样的。为了匹配您的示例，将Spring应用程序作为jar / war。
将运行该应用程序的容器。无论环境如何，都是一样的。如果使用Spring Boot，则不再需要Tomcat，而不再需要Java运行时。因此，请使用openjdk Docker容器。
应用程序所需的配置。这是唯一在不同环境之间不同的东西。在Spring应用程序中，您可能会使用属性文件。
配置文件位于单独的源代码控件中。这曾经是Git，但我们现在使用的是我们在http://www.configapp.com上构建的名为Config的SaaS。 Config的核心功能是易于处理特定于环境的配置。为了在新服务器上运行我们的应用程序，我们提取了该环境的Docker容器，应用程序工件和配置文件。在容器中，我们将安装应用程序和配置文件的目录装入容器中，作为容器运行的一部分。我们的应用程序是相同的。我们的容器/图像是相同的。只有配置文件不同。
关于配置文件与环境变量。最长的时间是我们使用配置文件。当我们使用PaaS / cloud时，我们使用了环境变量。如果您有很多配置，这是额外的工作，因此我们最终使用环境变量来确定正确的配置文件。我们有一个将属性转换为环境变量的应用程序，但这是非典型的。如果我们有公司认可的集中式配置服务器，则使用该服务器，否则我们将喜欢配置文件的简单性。
因此，总而言之，我们提取app.jar，app.properties，openjdk Docker。然后，我们运行openjdk Docker，安装app.jar和app.properties的位置。唯一特定于环境的是app.properties。为了轻松管理app.properties，无论有多少个属性键，环境，群集/区域实例，我们都使用Config。
评论
是什么让您认为基于环境变量选择文件与使用环境变量不一致，因此图像不会改变？ （主要缺点是将生产者凭证保留在dev和qa容器中比什么都重要）