Docker 与 PAAS

一 容器的由来

随着云计算的发展，IAAS服务已经趋于成熟，我们很容易从IAAS供应商获得虚拟机、存储、数据库资源。如果以虚拟机VM为单位进行管理，总是显得很厚重，资源利用率并不高。

为了充分使用操作系统的资源，LXC（linux container）是基于linux内核提供的cgroups 和 namespace进行的用户态的隔离机制。通过LXC，我们可以控制进程的内存、cpu竞争、独立的名字空间(网络、mnt、pid、ipc等)。这样，运行在同一个操作系统上的进程，可以认为是看不到彼此的。

而对于应用开发者而言，他们关心的是如何将他们的产品能够快速部署、更新，能够高效的运维，甚至自动化运维。一个产品，会包括多个组件，可能会有分布式部署的形态，如何将产品能够快速部署到操作系统中，并且能够充分使用操作系统资源呢。

容器的出现，最大的贡献是将应用的部署标准化，从而应用可以快速部署，与此同时将应用作为资源调度的单元，提供了能够被调度的可能。

容器化应用的发布流程为：

1 build  将应用所需的配置，应用环境打包为docker image。

2 ship  发布，将docker image 发布到镜像仓库docker registry中。

3 run   在操作系统中，执行docker run，将镜像仓库中的image 拉到本地，通过docker engine执行。

二 容器的应用场景

1 docker 与VM的差异

docker是非常轻量级的，docker的启动时间是秒级。与虚拟机的全虚拟化和半虚拟化，是操作系统级别的轻量级虚拟化。

docker image往往不大，docker image 是一层层的，可以只更新差量。 而VM的image 往往非常大。

docker 是基于LXC，只有基本的内存、名字空间的隔离。和VM提供的虚拟化能力是相差较大。

docker 由于还是进程级别的，运行在同一操作系统上的容器本质上还是共享同一个操作系统的资源，并且也很容易访问操作系统的所有资源。容器会共享操作系统，资源包括内存、系统库实际上都是共享的，只不过通过cgroup实现了虚拟的隔离和限制，本质上还是共享。

2 docker典型的应用场景：

a 自动化应用的打包和部署

b 创建轻量级的私有PAAS环境

c 自动化测试和可持续交付的集成

d 部署web应用 、 数据库、后端服务。

3 docker的限制：

由于docker实现的机制，也限定了docker 不适合的场景

a 由于docker基于lxc，cpu和网络的隔离都比较弱，目前最主要还是内存的调度。

b docker容器的状态。 docker 容器内运行的进程写的数据，如果不通过docker的数据卷，数据会写在union fs的一个目录下，当容器销毁后，数据难以维护。而使用数据卷时，需要考虑共享访问的问题。容器中的日志如何进行收集，往往是一个需要解决的问题。

c docker的安全控制。  通过docker容器很容易访问系统的的根目录，一旦取得root权限，将有机会可以破坏其他容器的运行。 

三 docker与PAAS

PAAS ： Platform as a Service。 PAAS是面向软件开发者的，帮助软件开发者更快速的完成软件的开发。比较典型的PAAS服务是Google的GAE，个人认为目前最成功的PAAS当属AWS的Lambda。

以Lambda为例，将业务代码(目前支持Node.js java 和 Python)提交后，结合实现特定的Lambda函数，AWS Lambda就会根据定制需求计算资源，自动执行，自动的伸缩扩容、监控等功能。具体可以移步AWS页面，

docker的出现极大了加快了PAAS的发展，企业私有PAAS构建蓬勃发展起来。可以看到PAAS核心是解决软件代码完成后部署运行运维到监控的所有事情。

我们先说其中的运维的发展脉络：

1 产品简单，人工进行配置环境，部署。

2 产品逐渐复杂，组件变多，涉及分布式部署， 这个阶段有必要进行脚本自动化，以进行一定程度自动化的运维。

3 公司的产品逐渐变多，资源管理分散，运维效率很低，管理混乱。 这个阶段，我们需要平台化，规范化、标准化产品的发布，通过平台进行自动化运维。

而一个软件的完整生命过程是：

在这个过程中，开发人员完成开发后，将产品提交给QA进行测试，QA测试可能会有一些反馈到开发，软件测试完成后，产品经理和运维人员进行产品的发布，上线更新。后续软件过程出了问题，运维人员会进行运维和反馈。

上述过程看似简单，但随着产品的复杂，每一个环节的递交成本都会变的很高。开发人员自行在开发环境上进行测试，发布打包给QA后，QA根据运行环境的要求，进行配置和测试。当产品发布，进行上线时，运维人员又需严格的进行环境配置部署或者在线升级。更重要的是，还有以下问题，如何保证测试环境与线上运行环境的一致？ 如何进行产品的自动化灰度更新？ 如果进行代码与产品发布版本的管理？ 产品上线出现问题后，怎样才能快速回滚？这些功能，都是PAAS平台所应提供的。

回到我们最开始的PAAS平台，如何实现上述所说的AWS Lambda功能呢？ 这里简单阐述下我们进行的PAAS实践：

PAAS平台的组成：

上述图中引入了新的角色，CD/CI

Continuous Integration  可持续集成 ： 开发人员提交代码到正式的分支后，就进行构建、测试，根据测试结果以判定此次代码提交能否和原有系统进行集成。

Continuous Delivery      可持续交付： 可持续集成完成后，将代码部署到类真实环境中，进行进一步的测试验证。

开发人员提交代码到代码仓库中。CD/CI负责代码托管，测试人员或者运维人员，输入要测试/发布的代码版本，部署环境，CD/CI开始构建产品包，提交到PAAS-Engine， PAAS-Engine负责管理集群的资源池，根据产品定义的模板，创建容器，在容器中创建配置，运行组件，将容器化的组件在资源池中部署运行。自动化告警系统(AUTO ALARMS)负责监控容器化服务的状态，将故障反馈给运维人员或者PAAS-Engine进行处理。

开发、测试、产品、运维都可以通过上述平台快速的进行产品的部署、上线，更新等。自动化测试很容易在CD/CI阶段完成。

CI使用的系统是Jenkins, AUTO ALARMS 是我们结合基础监控工具nagios、zabbix收集的基础监控信息开发的自动告警平台。

PAAS Engine由下面三部分组成： 

这里的核心是google的 kubernetes， kubernetes提供了容器的编排功能，即容器的部署，管理，服务发现，某个组件具体部署到资源池中的哪个节点，由kubernetes负责管理。容器出现异常偶，kubernetes提供了一定的自愈能力，自动重启。kubernetes会根据资源池的使用情况，选择合适的节点运行容器。

当我们发布一个产品时，该产品会有多个组件组成，进行分布式部署，组件之间可能会有依赖关系，灰度更新的控制等，由Openstack heat为我们提供。

Engine 作为中间层，与CI的 Jkenins进行交互，提供REST API 供前端页面访问， 一些业务定制化的功能逻辑也在这里实现。

PAAS的其他方案：

mesos + marathon + docker 或者 mesos + kubernetes 

mesos是资源管理中心，多种资源调度框架。mesos引入后，能够管理规模较大，集群资源非常复杂的情况。