2017年1月每日阅读

那什么叫“涟漪效应”？简单解释一下就是，当我们把一项技术初期推出去的时候，可能它并不是一项在大面积上都能达到完全使用水平的。但是，它仍然会接触到一小部分用户。

对于这一小部分用户来说，如果我们能够快速地到达他们，而且如果系统能够基于这部分用户的反馈形成数据。我们据此再形成一个二轮的迭代，马上就会有第二滴水滴下来，涟漪就会进一步地放大。它的适用群体的范围就会比初期的有所增长。而这样的一个过程，我们如果持续地去强化它，就是“涟漪效应”。

1. 不要在容器中存储数据－容器可以被停止，销毁，或者替换。一个1.0版的应用应该很容易的就被替换成1.1而不应有任何影响和数据丢失。基于这个原因，如果你需要存储数据，把它存储在宿主的硬盘上，但是要避免两个容器同时写数据，造成数据异常，确保你的应用是将数据写到共享的数据路径的。
   
2. 不要把你的应用分成两部分－因为很多人把容器当虚拟机使用，所以他们的做法是部署应用到已经在运行的容器中。也许开发中确实如此，因为你要不间断的部署和调试，但是在正式的QA和生产环节流程中，你的应用应该是容器的一部分。请记住：容器应该是不可变更的。
   
3. 不要创建过大的镜像－镜像过大不易分发。请确认你只包含了必要的文件和库，不要包含不必要的开发包，也不要在容器运行时运行”updates”(yum update)。
   
4. 不要使用单层的镜像－合理的使用分层的文件系统，OS是一层，安全和用户定义组件是一层，库文件是一层，配置文件是一层，最后是你的应用独立为一层。这样将使镜像的重建和管理变的容易同时易于分发。
   
5. 不要从运行的容器中创建镜像－换个说法，不要用”docker commit”去创建镜像。这样创建的镜像不可准确重建和版本化管理，应该彻底避免。要使用Dockerfile或者其他可重建的S2I(source to image)方式。
   
6. 不要只使用最新标签的版本－最新的标签就想maven中的”SNAPSHOT”。应该使用特定的标签的版本。我想你应该不想在你2个月后重新编译镜像时，收到惊奇，发现你的应用不能运行是因为顶层的layer使用了新的版本，没有向前兼容或者最新的版本是有问题的。当部署容器到生产环境时也要避免使用新的版本。
   
7. 不要在一个容器中运行多于1个的进程－容积最好是运行单一的进程（http守护进程，应用服务器，数据库）。当你运行多个时，你将会遇到要单独管理，处理日志，以及更新的困难。
   
8. 不要存储身份数据到镜像中，尽量使用环境变量－你应该不希望直接存储你的用户名，密码到镜像中。所以使用容器外的环境变量去获取相关的信息，一个较好的例子是postres image。
   
9. 请使用非root权限运行进程－“docker默认是以root身份运行的。当docker运行时，将会获取到默认的安全选项。而被他人获取root是危险的，并且也不是所有环境都支持的。你的镜像应该使用 USER 指令去指定一个非root用户来运行容器”（摘自Guidance for Docker image Authors）。
   
10. 不要依赖特定的IP－每一个容器都有它们自己的内部ip，而且这个ip可能在开启或者停止时变化。假如你的应用或者微服务需要和其他的容器通讯，请使用名称或者环境变量去传递相关的信息。