我和docker的初相识（二）

温故：

在上一篇文章里面我和大家分享了什么是docker？简单的介绍了docker的概念，就是带大家认识了一下到底docker是干什么的？再学新的知识之前我们先回顾一下：

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器或Windows 机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。一个完整的Docker有以下几个部分组成：1.DockerClient客户端     2.Docker Daemon守护进程    3.Docker Image镜像   4.DockerContainer容器。

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。

Docker并非适合所有应用场景，Docker只能虚拟基于Linux的服务。Windows Azure 服务能够运行Docker实例，但到目前为止Windows服务还不能被虚拟化。

Docker 镜像(Images)	Docker 镜像是用于创建 Docker 容器的模板，比如 Ubuntu 系统。
Docker 容器(Container)	容器是独立运行的一个或一组应用，是镜像运行时的实体。
Docker 客户端(Client)	Docker 客户端通过命令行或者其他工具使用 Docker SDK (https://docs.docker.com/develop/sdk/) 与 Docker 的守护进程通信。
Docker 主机(Host)	一个物理或者虚拟的机器用于执行 Docker 守护进程和容器。
Docker Registry	Docker 仓库用来保存镜像，可以理解为代码控制中的代码仓库。 Docker Hub(https://hub.docker.com) 提供了庞大的镜像集合供使用。 一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。 通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。
Docker Machine	Docker Machine是一个简化Docker安装的命令行工具，通过一个简单的命令行即可在相应的平台上安装Docker，比如VirtualBox、 Digital Ocean、Microsoft Azure。

上一篇关于docker的链接如下：我和Docker的初相识

 

知新：

一、Docker解决的问题

云计算、大数据，移动技术的快速发展，加之企业业务需求的不断变化，导致企业架构要随时更改以适合业务需求，跟上技术更新的步伐。毫无疑问，这些重担都将压在企业开发人员身上；团队之间如何高效协调，快速交付产品，快速部署应用，以及满足企业业务需求，是开发人员亟需解决的问题。Docker技术恰好可以帮助开发人员解决这些问题。

为了解决开发人员和运维人员之间的协作关系，加快应用交付速度，越来越多的企业引入了DevOps这一概念。但是，传统的开发过程中，开发、测试、运维是三个独立运作的团队，团队之间沟通不畅，开发运维之间冲突时有发生，导致协作效率低下，产品交付延迟， 影响了企业的业务运行。Docker技术将应用以集装箱的方式打包交付，使应用在不同的团队中共享，通过镜像的方式应用可以部署于任何环境中。这样避免了各团队之间的协作问题的出现，成为企业实现DevOps目标的重要工具。以容器方式交付的Docker技术支持不断地开发迭代，大大提升了产品开发和交付速度。

此外，与通过Hypervisor把底层设备虚拟化的虚拟机不同，Docker直接移植于Linux内核之上，通过运行Linux进程将底层设备虚拟隔离，这样系统性能的损耗也要比虚拟机低的多，几乎可以忽略。同时，Docker应用容器的启停非常高效，可以支持大规模的分布系统的水平扩展，真正给企业开发带来福音。

正如中国惠普云计算集成云技术首席专家刘艳凯所说的那样：“任何一项技术的发展和它受到的追捧，都是因为它能够解决困扰人们的问题，”Docker正是这样的一种技术。Docker的解决问题能力虽然很强，但在企业中的实际应用却并不多，那么是什么问题阻碍了Docker在企业中的实践？

虽然Docker技术发展很快，但技术还不够成熟，对存储的灵活的支持、网络的开销和兼容性方面还存在限制，这是Docker没有被企业大范围使用的一个主要原因。另外一个原因是企业文化是否与DevOps运动一致，只有企业支持DevOps，才能更大地发挥Docker的价值。最后一个原因就是安全性问题，Docker对于Linux这一层的安全的隔离还有待改进，才能进一步得到企业的认可。

二、应用实例

还有就是前面把docker说的这么厉害，那么它都能干什么呢？有没有具体的实例呢？有！！！在docker的网站上提到了docker的典型场景：

• Automating the packaging and deployment of applications（使应用的打包与部署自动化）

• Creation of lightweight, private PAAS environments（创建轻量、私密的PAAS环境）

• Automated testing and continuous integration/deployment（实现自动化测试和持续的集成/部署）

• Deploying and scaling web apps, databases and backend services（部署与扩展webapp、数据库和后台服务）

                                                                举个“栗子”

Sandbox

作为sandbox大概是container的最基本想法了 - 轻量级的隔离机制, 快速重建和销毁, 占用资源少。用docker在开发者的单机环境下模拟分布式软件部署和调试，可谓又快又好。

同时docker提供的版本控制和image机制以及远程image管理，可以构建类似git的分布式开发环境。可以看到用于构建多平台image的packer以及同一作者的vagrant已经在这方面有所尝试了，笔者会后续的blog中介绍这两款来自同一geek的精致小巧的工具。

Docker已经不仅仅是DevOps人员手中的神器了，每一个开发者都应该学会如何使用Docker。 

PaaS

dotcloud、heroku以及cloudfoundry都试图通过container来隔离提供给用户的runtime和service，只不过dotcloud采用docker，heroku采用LXC，cloudfoundry采用自己开发的基于cgroup的warden。基于轻量级的隔离机制提供给用户PaaS服务是比较常见的做法 - PaaS 提供给用户的并不是OS而是runtime+service，因此OS级别的隔离机制向用户屏蔽的细节已经足够。而docker的很多分析文章提到『能够运行任何应用的“PaaS”云』只是从image的角度说明docker可以从通过构建 image实现用户app的打包以及标准服务service image的复用，而非常见的buildpack的方式。

由于对Cloud Foundry和docker的了解，接下来谈谈笔者对PaaS的认识。PaaS号称的platform一直以来都被当做一组多语言的runtime和一组常用的middleware，提供这两样东西

即可被认为是一个满足需求的PaaS。然而PaaS对能部署在其上的应用要求很高:

• 运行环境要简单 - buildpack虽然用于解决类似问题，但仍然不是很理想

• 要尽可能的使用service - 常用的mysql, apache倒能理解，但是类似log之类的如果也要用service就让用户接入PaaS平台，让用户难以维护

• 要尽可能的使用"平台” - 单机环境构建出目标PaaS上运行的实际环境比较困难，开发测试工作都离不开"平台”

• 缺少可定制性 - 可选的中间件有限，难于调优和debug。

综上所述部署在PaaS上的应用几乎不具有从老平台迁移到之上的可能，新应用也难以进入参数调优这种深入的工作。个人理解还是适合快速原型的展现，和短期应用的尝试。

然而docker确实从另一个角度(类似IaaS+orchestration tools)实现了用户运行环境的控制和管理，然而又基于轻量级的LXC机制，确实是一个了不起的尝试。

笔者也认为IaaS + 灵活的orchestration tools(深入到app层面的管理 如bosh)是交付用户环境最好的方式。

国内也已经开始出现基于Docker的PaaS。2015年3月11日，云雀Alauda云平台正式开启内测，对外提供基于Docker的PaaS服务。

 

 

                                               拓展

之前在上一篇文章中提到了一个名词“cgroup”,cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在 /cgroup目录下新建一个文件夹即可新建一个group，在此文件夹中新建task文件，并将pid写入该文件，即可实现对该进程的资源控制。具体的资源配置选项可以在该文件夹中新建子 subsystem ，{子系统前缀}.{资源项} 是典型的配置方法，如memory.usage_in_bytes 就定义了该group 在subsystem memory中的一个内存限制选项。另外，cgroups中的 subsystem可以随意组合，一个subsystem可以在不同的group中，也可以一个group包含多个subsystem - 也就是说一个 subsystem。

因为之前没有介绍它是如何实现对资源的配置的，我这里补充一下：

cpu : 在cgroup中，并不能像硬件虚拟化方案一样能够定义CPU能力，但是能够定义CPU轮转的优先级，因此具有较高CPU优先级的进程会更可能得到CPU运算。

通过将参数写入cpu.shares,即可定义改cgroup的CPU优先级 - 这里是一个相对权重，而非绝对值。当然在cpu这个subsystem中还有其他可配置项，手册中有详细说明。

cpusets : cpusets 定义了有几个CPU可以被这个group使用，或者哪几个CPU可以供这个group使用。在某些场景下，单CPU绑定可以防止多核间缓存切换，从而提高效率

memory : 内存相关的限制

blkio : block IO相关的统计和限制，byte/operation统计和限制(IOPS等)，读写速度限制等，但是这里主要统计的都是同步IO

net_cls， cpuacct , devices , freezer 等其他可管理项。

 

局限性

Docker在本质上是一个附加系统。使用文件系统的不同层构建一个应用是有可能的。每个组件被添加到之前已经创建的组件之上，可以比作为一个文件系统更明智。分层架构带来另一方面的效率提升，当你重建存在变化的Docker镜像时，不需要重建整个Docker镜像，只需要重建变化的部分。

可能更为重要的是，Docker旨在用于弹性计算。每个Docker实例的运营生命周期有限，实例数量根据需求增减。在一个管理适度的系统中，这些实例生而平等，不再需要时便各自消亡了。

针对Docker环境存在的不足，意味着在开始部署Docker前需要考虑如下几个问题。首先，Docker实例是无状态的。这意味着它们不应该承载任何交易数据，所有数据应该保存在数据库服务器中。

其次，开发Docker实例并不像创建一台虚拟机、添加应用然后克隆那样简单。为成功创建并使用Docker基础设施，管理员需要对系统管理的各个方面有一个全面的理解，包括Linux管理、编排及配置工具比如Puppet、Chef以及Salt。这些工具生来就基于命令行以及脚本。 

今天关于docker暂时就讲到这里，客栈歇业一天！

小二，关门 上闸板，睡觉