容器是这两年最热的一个话题，去年大家都在谈Mesos、Kubernetes、Swarm，究竟哪家的挖掘技术强，今年容器技术的进一步普及，更多的人更关心容器技术如何落地，下面我们就基于一个实际的案例来聊一下容器落地遇到的问题。
背景：某银行数据中心计划搭建一个基于容器的PaaS平台
持续集成是容器一个绕不过去的话题，无论哪家容器厂商都一定会谈到，数人云关于持续集成，最开始用的是drone，一个小众的持续集成工具，将drone内置在平台上，通过平台的持续集成功能可以方便的实现持续集成的配置和管理。
drone 的坑
一开始我们觉得这是一个很好的工具，但是后来发现其实没有想象中的那么美好，它的问题：
Jenkins是个好工具
Jenkins是一个好工具，功能强大且稳定，基于Jenkins实现的持续集成基本没有花费什么开发的时间，通过脚本将代码构建和平台连接在一起即可轻松实现CI/CD。
总结
往往用户需要的并不是那些看起来很酷的功能，真正需要的是能够实际解决问题的方案，即使这个方案很low。
在我看来，容器是一个革命性的产物，改变了软件交付的方式，它开箱即用的特性消灭了程序员常说的一句话 “在我这里运行时正常的啊！”； 它快速部署，环境无关的特性帮助运维人员提高了工作效率，但是任何事情都有其两面性，它的开箱即用，环境无关带来好处的同时，也带来了问题——配置文件。
传统应用在容器时代面临的第一个问题
一般而言，每个程序都会有一个或多个配置文件，里边记录着DB地址、账号、密码、缓存地址等信息，在容器时代之前，应用程序一般的流转方式是“从开发->测试->生产”：
开发同学交付一个编译之后的二进制文件，源文件（解释执行）或者代码仓库中某一个tag，同时附带一个release notes；
测试同学拿到开发同学交付的内容后，就将其部署在自己的测试环境中，如果release notes中说明了有配置信息需要更新或依赖文件版本需要升级，会依照文件进行调整；
如果测试通过，确定可以投产，那么就将其交付给运维同学进行生产部署。
此时有一个问题，开发、测试、运维每个环节都会自己维护配置文件，如果使用了容器，那么配置文件管理就是很麻烦的问题了，因为配置文件被放到了容器里，若想修改配置文件就不是那么简单的事情了，所以这就是传统应用在容器化时面临的第一个问题，当然这个问题也不是不能解决，一般而言，有以下几种解决方案：
容器时代配置管理的正确打开方式
以上分析了传统应用容器化基本都会遇到的一个问题，而且也没有给出很好的解决方案，下面我们来谈下容器化时代配置管理的正确打开方式。
其实通过上面问题的描述，我们可以很容易的找到问题的根本原因：配置文件本身是一个本地存储状态，要对其做无状态改造，对于配置管理的无状态改造一般是通过配置中心来完成的，即应用通过配置中心获取配置信息，无需读取本地配置文件，但是这个问题更麻烦，要解决这个问题需要首先解决两个问题：
随着容器的普及，未来配置中心肯定会逐渐成为程序的标配。
最终选择的解决方案
关于容器时代配置文件的问题，上边大概提到了3种方案，在最终落地的时候选择的是哪一种呢？答案是第二种——生成新的镜像。这是一个很low的方案，为什么没有选择另外两种呢？ 我们来解释下原因：
总结
虽然这个选择从技术上来看很low，但是个人认为，使用一个不太优雅的方案帮助一个新技术快速落地，然后推动其快速前进，比一直纠结于方案是否高大上，是否优雅等，而导致新的技术一直被悬在空中更好，就像大家一直在争论Mesos、Kubernetes、Swarm究竟哪个更好，现在也没有一个结论，与其争论这么多虚的，不如仔细想一下自己的问题是什么，究竟哪个技术更适合自己。
目前使用ELK作为日志方案。
传统应用的坑
一般而言，传统的应用都是把日志写到一个指定的路径下，然后通过Logstash采集日志并送入Elasticsearch进行存储，但是这种应用如果直接容器化之后就会带来一个问题——应用的日志文件应该如何存储。
两种方案都有一些问题：
容器时代日志的正确打开方式
按照之前的惯例，我们先提出在容器时代，日志的正确处理方式，如果应用使用Docker进行交付，不建议写日志文件，直接将日志写入标准输出即可，然后Logstash通过Docker的log-driver捕获日志，这样日志文件既不需要落盘，也使日志文件摆脱了状态，可以更容易的横向扩缩。
最终选择的解决方案
最终我们实现的是方案三，因为用户在我们的建议下，选择了将日志输出到标准输出。
新的问题
写日志的目的是为了看的，这是一个无比正确的废话，但是如何实时的看到需要的日志却成了我们面临的一个新问题。在容器时代之前，我们一般是通过tail来实时的看日志或者通过Kibana来分析日志。
在容器的时代，通过Kibana看日志的方式没什么变化，但是看实时日志就有了一些问题，在用户采取了我们的建议将日志写入标准输出后可以比较优雅的处理日志了，但是另外一个问题出现了，实时日志没有了，因为日志已经被log-driver收走了，怎么办？虽然依然可以从ES中找到日志，但是由于ELK本身的机制，不能通过ELK看到实时日志。
新的解决办法
新的问题，需要新的办法来解决，如何解决，其实说穿了也简单，实现了一个log-agent的功能，可以将日志送到两个地方，Logstash和实时日志。
总结
事情就是这样，我们以为解决了一个问题的时候，往往一个新的问题又摆在前面，像容器落地这种事情，对传统应用的整体工作方式和流程都有很大的冲击，所以一定也会遇到同等规模的问题需要解决。
银行对监控是非常重视的，尤其是运维部门，所以为了满足客户的需求，我们实现了：
监控本身是我们平台很重要的一个部分，但是在实际实施过程中发现，客户其实不是很在意做的监控页面，仪表盘等监控数据，他们自身有健全的监控平台，其实我们需要做的事情就是将我们的数据吐到他的平台上即可。
总结
世事难料，你永远不知道下一块巧克力什么味道，这个我们自身投入了很大精力和时间来实现的功能在用户那里就变成了一个对接的任务。
弹性扩缩一直是容器厂家喜欢谈的一个口号，曾经有一度我们认为基于Docker的特性来实行弹性扩缩是一件很容易的事情，但是后来发现，这里其实有一个大坑。
扩很容易，缩很难
弹性扩容是一件比较容易的事情，我们只要对接监控数据，然后配置一些规则，即可触发应用容器个数增加，实现扩容，但是缩容就会面临几个问题：
什么时候缩容，这个问题相对来说还不是特别麻烦，可以设定一个指标，比如CPU，内存，IO等指标来触发缩容，这里只要做一些带有缓冲的规则，避免由于规则简单而导致的扩缩抖动即可。
如何安全的缩容相当麻烦，缩容在本质上是要停掉一些容器的，如何判断这个容器是可以停止的，如果一个容器没有流量了，那么应该是可以被停止的，如何让一个容器的流量停止？可以通过前端负载进行控制，不往这个容器分发流量，那么前端的负载是如何判断应该如何往后端分发流量呢？这个有多重因素：
从以上简单的分析中我们可以发现，缩容不是简单的条件符合了就可以做的事情，要想在不影响业务的情况下实现缩容，是一件非常麻烦的事情，它与平台架构，运行的程序的业务逻辑有很深的耦合。
总结
要实现自动的扩缩容，不是一件简单的事情，而是一个系统的工程。
以上内容是基于数人云在某银行实施过程中总结出来的一些感悟，如果能给大家一些帮助，我们非常高兴，如果有问题，请指出来，我们共同提高，Docker到现在大概有3年多的历史，个人看来它距离真正落地还有很大一段路程要走，我们必须不停的摸索。
Q：我想问一下，日志打两份的话具体是怎么实现的呢，用到了哪些技术或现有的工具呢？
A：我们自己实现了一个log-agent, 然后log-agent 可以实现这个功能。
Q：如果应用有自己的写的日志，如log4j的，输出不到标准输出，还怎么处理？
A：log4j貌似是可通过配置输出到标准输出的，另外如果有些应用不能输出到标准输出的，可以配置日志文件路径，我们会去读文件。
Q：缩容的产生条件是否有比较好的解决方案，比如根据CPU、内存甚至业务规则多维度的进行考察？
A：缩容很容易，但是麻烦的是如何安全的缩容，我理解这个环节其实是跟应用的逻辑有直接关系的，如果应用是一个无状态的应用，那么缩容非常简单，只需要在前端控制流量，然后停止容器即可，但是如果是有状态的应用，那么就有可能对用户造成影响。
Q：配置管理这块，不断的覆盖会增加镜像体积，如何最大化减少镜像大小呢？
A：首先，一个镜像最多被覆盖2，3次，测试镜像一次，生产镜像一次，而且配置文件一般是很小的，几乎对镜像大小没有影响。
Q：测试环境配置文件覆盖开发环境镜像，是只用测试环境的docket file 吗？ 如果每天打版，会很麻烦吗？
A：通过覆盖测试文件来解决环境问题，只是一个思路，不一定非要使用开发测试环境的信息，这个可以具体情况具体分析。
Q：log-agent具体实现呢，日志直接打给log-agent还是log-agent读取本地日志文件呢？或者说log-agent读取标准输出的内容呢？
A：log-agent可以通过Docker的log-driver获取标准输出的日志，同时也可以直接读取日志文件的日志。
本次培训涉及：Kubernetes概述和架构、部署和核心机制分析、进阶篇——Kubernetes工作原理和代码分析等，扫描下方二维码可查看具体培训内容。
点击阅读原文链接可直接报名。
