容器的编排管理编排工具的选型：
图4：编排工具选型对比
Rancher图形化管理界面，部署简单、方便， 可以与AD、LDAP、GITHUB集成，基于用户或用户组进行访问控制，快速将系统的编排工具升级至Kubernetes或者Swarm，同时有专业的技术团队进行支持，降低容器技术入门的难度。
图5: Rancher架构图
基于以上优点我们选择Rancher作为我们容器云平台的编排工具，在对应用的容器实例进行统一的编排调度时，配合Docker-Compose组件，可以在同一时间对多台宿主机执行调度操作。同时，在服务访问出现峰值和低谷时，利用特有的rancher-compose.yml文件调用“SCALE”特性，对应用集群执行动态扩容和缩容，让应用按需求处理不同的请求。https:/zhuanlan.zhihu.com/p/29093407
容器网络模型选型：
图6: 容器网络模型选型
由于后端开发基于阿里的HSF框架，生产者和消费者之间需要网络可达，对网络要求比较高，需要以真实IP地址进行注册和拉取服务。所以在选择容器网络时，我们使用了Host模式，在容器启动过程中会执行脚本检查宿主机并分配给容器一个独立的端口，来避免冲突的问题。
持续集成与持续部署
持续集成， 监测代码提交状态，对代码进行持续集成，在集成过程中执行单元测试，代码Sonar和安全工具进行静态扫描，将结果通知给开发同学同时部署集成环境，部署成功后触发自动化测试（自动化测试部分后续会更新https://zhuanlan.zhihu.com/idevops）。
图7:持续集成示意图
静态扫描结果：
图8: 持续集成结果示意图
持续部署，是一种能力，这种能力非常重要，把一个包快速部署在你想要的地方。平台采用分布式构建、部署，master管理多个slave节点，每个slave节点分属不同的环境。在master上安装并更新插件、创建job、管理各开发团队权限。slave用于执行job。
图9: 持续部署架构图
基于上述图9架构，我们定义了持续部署规范的流程：
（1）开发同学向gitlab提交代码；
（2）拉取项目代码和配置项文件，执行编译任务；
（3）拉取基础镜像，将编译好的应用包打入生成最新的应用镜像，推送到镜像仓库；
（4）根据当前应用及所属环境定制化生成docker-compose.yml文件，基于这个文件执行rancher-compose命令，将应用镜像部署到预发环境（发布生产前的测试环境，相关配置、服务依赖关系和生产环境一致）。
（6）预发环境测试通过后将应用镜像部署至线上环境，测试结果通知后端测试同学。
容器的运行管理
应用容器现在已经部署到线上环境，那么在整个容器的生命周期中，还需要解决下面两个问题：
（1） 如何保存应用程序产生的运行日志和其它业务日志；
（2） 如何在后端服务出现变化后nginx能够自动发现并完成配置更新。
日志管理
容器在运行时会在只读层之上创建读写层，所有对应用程序的写操作都在这层进行。当容器重启后，读写层中的数据（包含日志）也会一并被清除。虽然可以通过将容器中日志目录挂载到宿主机解决此类问题，但当容器在多个宿主机间频繁漂移时，每个宿主机上都会有留存应用名的部分日志，增加了开发同学查看、排查问题的难度。