简介

docker容器技术在17年可谓是炽手可热，docker不仅仅改变了传统软件服务的交付流程，更是为云计算和微服务大规模集群管理部署，提供了强有力的技术支撑。当今各大公司企业也是把容器化技术作为不可或缺的技术战略，于17年初我们也开始步入docker技术的生态圈，尝试进行对当前服务做容器化的改造，而持续交付作为项目开发流程中较为核心的一步，也是落地实践最早一步。

我们的问题

17年初，基于微服务的架构，仅我们团队内的服务单元已经过百，特别是经历网站的促销活动，机器扩容，资源分配等问题真的是苦不堪言，除此之外更是有一些困绕已久的问题等待解决：

1. 发布系统不统一

因为涉及到不同语言的系统开发，各个系统的构建流程都有不同，涉及到node，C#，Java还有python，发布到不同服务器上，需要通过对应的发布系统，各个系统之间记录关联很难核对，不便于追踪。

2. 多环境的管理

服务器资源新增，修改部署的配置比较多，包括打通与发布系统的环境相关联，基础服务的安装配，包括node，jdk和tomcat服务器等。

3. 环境的一致性

由于各种历史问题，导致项目发布的测试环境、集成环境和产线环境配置不一致，给系统问题的排查定位带来一定的难度，项目部署目录，服务启动用户，甚至包括jdk版本的问题，这些问题同时加重了运维工作的复杂度。

4. 资源的分配

主要是软资源的计算分配，因为服务单元非常多，每个服务单元的内存，端口分配问题会随着服务数量的增加，越来越难以计算和管理，CMDB统计不够实时，造成最终的结果就是资源利用率比较低。

微服务架构

选择docker一个重要的原因，就不得不提到微服务了，微服务相比传统的服务采用单体的架构方式，部署方式和开发模式上有很大优势。单体架构的方式，服务系统过于庞大臃肿，项目发布部署风险较高，迭代开发周期较长，而微服务按照业务维度进行功能模块拆分，使其各自成为一个可独立提供服务，可独立部署运行的单元模块，通过指定的网络协议模块之间进行通信，并且在开发模式上，也是相互独立，大幅提高了项目开发上线的周期，做到快速迭代。但是随着则业务复杂性的提升，微服务的集群数量也会急速上升，带来的问题就是面对如此多服务如何高效的管理，部署，监控等一些问题，而docker处理这些却有着得天独厚的优势。

我们微服务架构核心采用的框架是基于Spring Boot和Dubbo，并且是支持双协议的通信，http/https和Dubbo RPC的调用方式，Dubbo的主要是内部模块调用依赖，而http的接口主要是提供给异构系统的接入。整体的项目架构图如下：

容器化之路

如今再次说到docker的时候，我们往往已经不仅仅谈论的只是docker本身，因为docker engine 只是改变了应用运行时的状态管理，更多的我们还关注到服务的调度，编排，网络管理，存储，监控，配置管理等等一系列的服务，docker 俨然已经是一个庞大的技术生态圈，这个生态圈里面，大家比较关心的其中一个核心服务的就是容器编排了，因为容器编排彻底的改变了传统软件服务交付流程，而容器编排则又以k8s 和mesos 为主的居多，更确切的说，k8s已经不仅仅是作为一个编排工具了，此处暂时不做讨论，两者的选型介绍可后续关注，此次也不做过多讨论。

我们选择的容器编排是以mesos为主的，简单介绍一个以mesos为核心的各个组件以及服务依赖。

zk 注册中心，这个注册并不是服务的注册，而是用来管理mesos集群状态数据的中心服务，通过zk来构建一套高可用的mesos集群。

mesos-slave 部署在每个node（主机）节点的服务，用来采集服务器数据信息，执行指令。

mesos-master 管理服务器资源信息，分派mesos-slave资源调度指令。

marathon 资源计算服务，根据应用部署需要的资源信息，提供资源分配，并且提供了一套UI，通过UI可方便的进行管理操作。

各个组件服务结构如下图：

镜像

我们的服务，主要的包括Java和node两种类型的服务，所以基础镜像也根据不同的版本号，提供了多种类型。镜像基础使用的是alpine的版本，镜像文件非常小，jdk使用的openjdk，加上启动服务的脚本以及其他配置，配置内容，镜像最终大小100M左右，加上项目打包好以后的镜像，在150M上下，当然为了一些项目的特殊需求，也提供了oracle jdk的镜像版本，但是至今未使用过。

构建

我们的技术框架最初是基于Spring Boot，通过Spring Boot提供的打包插件，可以方便的把项目构建成一个运行时需要的jar包，启动jar包和指定的运行时的一些参数信息，是通过gitlab统一管理的一些shell文件，通过jenkins构建过程，动态的把项目的jar包和启动脚本，封装在一起，然后发布到应用服务器，解压启动。但是如果采用docker部署，这种方式就不可行了，因为docker部署面向的是镜像。

docker镜像的构建方式有多种，最合理的一种莫过于Dockerfile了，但此时我们产线运行的项目已经非常多了，一个个往里面添加Dockerfile已经不现实，所以就提供了一个Dockerfile模板，里面标注了基础镜像信息，在项目构建的流程中，通过获取一些项目参数，动态生成一个Dockerfile文件，最后通过docker build生成镜像文件，然后提交到镜像库，这个过程对于开发人员完全无感知，就这样悄无声息的完成了项目格式的转化，并且对于不同类型的项目，提供了不同类型的Dockerfile模板，甚至可以通过项目做定制化。

上面说Dockerfile是动态生成并且对开发人员无感知的，而这个构建过程，也是通过执行容器实现的，通过容器挂载的方式，把构建的结果显示在宿主机上，这整个的过程都做成了docker镜像，并且使用Dockerfile管理这些镜像，通过不同的Dockerfile轻而易举的自定义各个类型项目的构建过程，比如node项目的构建和Java的构建不同，就定义两个Dockerfile就可以了，统一在gitlab上管理，维护成本变得非常低。

发布

项目构建完成，容器的的编排部署，主要是通过marathon操作。marathon本身提供了一些对外开放的api接口，这个开放接口也是我们做自动化基石。项目构建完毕，流程并没有结束。marathon管理的服务编排，主要是配置文件，定义应用，内存，端口，以及健康监测都是在配置文件里面管理的，所以基于此，我按照格式定义了一个项目，专门来管理这些项目的配置，并且把这些配置提交到gitlab上进行管理，项目结构如下：

每一个环境对应的目录下，都是一个marathon的配置文件模板，之所以是模板，因为每次构建生成不同的镜像tag是系统自动生成的，会动态替换参数，并且调用marathon的api接口进行服务更新，服务的更新策略也都配置在marathon配置文件中的，整个的构建和发布流程，分为各自独立的两模块，通过一套shell完成，也可以独立使用，但还是为了考虑操作的简单性，接入了jenkins，并且通过jenkins增强了权限控制，并且对操作记录可追踪。构建流程结构如下图：

运行

一开始我们采用docker，只是拿了部分服务测试，并非一蹴而就，全部直接推广使用。项目测试运行刚上线，开始遇到第一个问题。写到这里，简单普及一下docker的网络模式，docker的网络模式默认的四种方式host，bridge，none和自定义的网络模式，host的方式就是容器和主机共享网络空间，容器和主机共用网络端口，这种方式的弊端不言而喻，就是部署应用的时候要关注服务器的端口分配。bridge的方式是采用的独立的网络空间，通过虚拟网桥的方式利用主机的网卡进行通信，容器的网络空间是独立的，容器内部服务端口和主机映射端口是随机的。none的形式就是关闭网络模式，这种适合于计算的服务类型。而自定义的网络模式，主要是来解决跨主机网络通信的问题，每个容器网络空间也是各自独立的，而我们的服务主要采用的就是种方式，问题也恰恰出在这里。

由于采用的是部分服务做docker化，老的服务可能需要访问新的服务，但是这个时候，老服务在利用Dubbo调用新服务的通信的时候，发现对方注册是IP地址无法访问，原因就是docker容器内的Dubbo提供的服务，注册上去的其实是个虚拟IP地址，和原有老的服务根本就不同一个网络内。所以网络单向是不通的，网络调用结构如下图：

既然是网络的问题，那么针对该问题的解决方案也列了几个：

方案一：所有服务进行docker容器化部署，这样的话所有服务就处于同一个虚拟网络段内，但是这个迁移的成本和风险非常大。

方案二：基于物理层面网络做修改配置，但是这种维护的成本较大，可扩展性不好。

方案三：更改容器内服务运行的网络，采用host的方式配置，这种方式其实并没有充分利用容器化带来的便利之处，但是确实最简单解决这个问题的方法，所以最终考虑，选择这个方案解决，而后期的优化方案，去Dubbo化。

其实针对容器网络的模块，这里也只是冰山一角，未来面临更复杂的产线环境，将会遇到更多网络的配置问题。

总结

容器化之路是，这里仅仅只是起点，本次只是简单的介绍了最开始容器化项目构建交付的流程，实际上在实践中遇到的问题不止如此，希望对大家有所帮助，思路上也希望能有共鸣，后续对相关细节问题还会再次介绍。