docker在保险行业持续交付的难点？

持续交付的技术难度很高。很多人意识不到。这也是过去很多交付技术方案效果不佳的原因。

持续交付的压力来源于：需要快速迭代以及交付次数庞大(频次x项目数)

那么技术难度在哪里？很多人一提到虚拟化存储或sdn觉得技术牛，但是持续交付，不就是脚本拼拼凑凑的事吗？

大错特错！甚至有人认为通过vm模版将应用软件提前部署进去不就可以了吗？同样大错特错。

持续交付的核心在于：软件配置管理的自动化，这里的配置包含资源提供、软件包、版本、环境配置（不同层次的配置，从kernel到应用）、以及日志策略、管理单元等等，这种整体性交付能够适应不同阶段（dev/test/prod），这是非常巨大的挑战。

有些复杂系统你可能觉得我手工部署挺容易的，那是建立在你对该系统已经掌握的情况下，但是如何让“技术小白”能够自助部署一套hadoop／部署一个oracle RAC，实现更好的技术分工，对于一些人员来说，没有必要去掌握hadoop的配置，他只是使用者，快速交付最终让“管”和“用”这两类人真正的分离开来。但是过去写脚本的用脚本，用脚本的写脚本，这是局限性。

持续交付为何复杂：

•应用需要和硬件、OS解耦
•部署具有可重复性和一致性
•部署能处理不同环境和数据中心的差异
•部署要能够支持各种集群HA/LB/MS/Sharding
•部署的服务之间要能够相互感知，且能够正确处理好依赖

只有将以上的问题都很好的处理完成，才能做好持续交付！越是复杂的系统，越需要持续交付，越是简单的需求越小。

我认为现在docker在保险也持续交付的难点在于按照docker的传统方法在目前敏捷开发、快速迭代的情况下会有大量的镜像需要维护，且需要频繁推送更新镜像。此问题建议可将程序包映射到主机上，这样发布就不需要去更新维护镜像，但这样带来的问题就是一个完整的运行环境就不是镜像，而是镜像+程序。