正文
-
开发同学交付一个编译之后的二进制文件，源文件（解释执行）或者代码仓库中某一个tag，同时附带一个release notes；
-
测试同学拿到开发同学交付的内容后，就将其部署在自己的测试环境中，如果release notes中说明了有配置信息需要更新或依赖文件版本需要升级，会依照文件进行调整；
-
如果测试通过，确定可以投产，那么就将其交付给运维同学进行生产部署。
此时有一个问题，开发、测试、运维每个环节都会自己维护配置文件，如果使用了容器，那么配置文件管理就是很麻烦的问题了，因为配置文件被放到了容器里，若想修改配置文件就不是那么简单的事情了，所以这就是传统应用在容器化时面临的第一个问题，当然这个问题也不是不能解决，一般而言，有以下几种解决方案：
容器时代配置管理的正确打开方式
以上分析了传统应用容器化基本都会遇到的一个问题，而且也没有给出很好的解决方案，下面我们来谈下容器化时代配置管理的正确打开方式。
其实通过上面问题的描述，我们可以很容易的找到问题的根本原因：配置文件本身是一个本地存储状态，要对其做无状态改造，对于配置管理的无状态改造一般是通过配置中心来完成的，即应用通过配置中心获取配置信息，无需读取本地配置文件，但是这个问题更麻烦，要解决这个问题需要首先解决两个问题：
随着容器的普及，未来配置中心肯定会逐渐成为程序的标配。
最终选择的解决方案
关于容器时代配置文件的问题，上边大概提到了3种方案，在最终落地的时候选择的是哪一种呢？答案是第二种——生成新的镜像。这是一个很low的方案，为什么没有选择另外两种呢？ 我们来解释下原因：
总结
虽然这个选择从技术上来看很low，但是个人认为，使用一个不太优雅的方案帮助一个新技术快速落地，然后推动其快速前进，比一直纠结于方案是否高大上，是否优雅等，而导致新的技术一直被悬在空中更好，就像大家一直在争论Mesos、Kubernetes、Swarm究竟哪个更好，现在也没有一个结论，与其争论这么多虚的，不如仔细想一下自己的问题是什么，究竟哪个技术更适合自己。
目前使用ELK作为日志方案。
传统应用的坑
一般而言，传统的应用都是把日志写到一个指定的路径下，然后通过Logstash采集日志并送入Elasticsearch进行存储，但是这种应用如果直接容器化之后就会带来一个问题——应用的日志文件应该如何存储。
