在以AWS、Google、阿里等为代表的公有云发展的同时，很多大大小小的公司由于一些客观、主观的原因只能采用传统的硬件环境架构，我们北京盛学成长科技有限公司就是这样一家公司。由于业务性质的限制，不能采用例如阿里云这样的开箱即用的主机资源。我公司现有硬件资源在很早以前就实现了esxi+vcenter这样的虚拟机私有云平台。百分九十的业务都是运行在虚拟机之上的，利用虚拟化基础架构技术，可以不断整合工作负载，从而充分利用服务器并降低运营成本。该基础架构技术不但使系统管理员能够管理更多的服务器，而且在置备新的软件服务和维护现有软件服务时，具有更高的灵活性，响应也更快速。最重要的是，它实现了各种基于 x86 的环境下管理工作的标准化和简化，这包括 Microsoft Windows、Linux、及Solaris x86 等操作系统。

　　虚拟机主要是解决了系统资源的灵活运用，这样看起来很美妙。

　　那么我们为什么需要容器化?

　　第一是我们之前的业务系统随着时间的发展越来越多，不同的组件需要协同去做不同的工作，给运维带来了巨大的挑战，有 JAVA 写的程序，还有些程序制定了必须用 JDK7，有的需要JDK8，还有些业务是用 PHP 写的，这对运维来讲是一个挑战，我们必须要给各种各样的程序准备各种各样的环境，维护，迁移都非常麻烦。

　　配置混乱，当你应用的服务器数量越来越多，每个应用的管理程序都不一样 , 有些程序可能只是个定时任务。最终的结果是操作系统中的配置文件和各种黑科技补丁脚本散落在系统的各个角落，没人能找得到，也没人搞得懂。

　　环境不匹配导致测试跟生产环境不一样，比如生产环境是 JDK8 跑的，某一个开发者本地用 JDK7 测试的程序，上去发现这个东西根本不对，虽然 JDK7 和 JDK8 的兼容性已经是99%以上，但是一个严谨的业务系统必须要做到测试环境跟生产环境是一致的。

　　所以我们需要容器，但是对于一个企业来说，使用容器并不是简单的使用docker把环境装上，把代码放进去，然后把程序跑起来。我们更应该从分布式、代码快速构建、快速部署、秒级迁移、代码灰度发布这些角度去考虑我们的平台。

　　简而言之我们更希望我们的应用是：

　　1.高可用的：应用的可用性不依赖某一个容器主机节点的存活性。

　　2.持续集成、快速部署：从源码到环境部署的自动化。

　　3.迁移方便：应用快速迁移。

　　理想很美好，但是需要达成这些目标，我们需要做的很多。我们前期对容器化进行了调研，例如容器编排、监控方案、日志收集、网络方案等等。出于成本的考虑，我们决定前期使用rancher+cattle作为我们的容器平台。容器间互联采用了rancher自带的网络解决方案，私有仓库采用wmware的harbor。监控采用了业界比较流行的prometheus。至于持续集成我们决定使用Jenkins，没有使用rancher自带的流水线，因为公司的代码都是放在svn上。

　　平台的架构规划图：

　　项目示意图：

　　prometheus监控图：

　　这些远远不够，例如日志的自动收集与呈现，容器的服务注册与自动发现、代码的持续集成还需要后期完善。当然在kubernetes统治一切的时代，切换到kubernetes只是时间问题。