Docker简介
Docker是一种遵从Apache2.0协议开源的Linux容器管理解决方案,它通过进程和进程通信技术对操作系统的文件资源和网络的进行隔离,实现了包含文件资源、系统资源(shell环境等)以及网络资源的容器创建和管理。每一个容器都有一个唯一的进程,当该进程结束的时候,容器也会完全的停止。
其他信息
Go语言编写
仅适用于Linux平台
Docker 官网:http://www.docker.com
Github Docker 源码:https://github.com/docker/docker
帮助文档:https://docs.docker.com
Docker的实现思想
Docker的思想来自于集装箱,集装箱解决了什么问题?
现在都流行云计算了,云计算就好比大货轮,docker就是集装箱。
举几个日常开发会经常遇到问题的场景,docker能解决这些问题:
1.不同的应用程序可能会有不同的应用环境,比如.net开发的网站和php开发的网站依赖的软件就不一样,如果把他们依赖的软件都安装在一个服务器上就要调试很久,而且很麻烦,还会造成一些冲突。
比如IIS和Apache访问端口冲突。
这个时候你就要隔离.net开发的网站和php开发的网站。
常规来讲,我们可以在服务器上创建不同的虚拟机在不同的虚拟机上放置不同的应用,但是虚拟机开销比较高。
docker可以实现虚拟机隔离应用环境的功能,并且开销比虚拟机小,小就意味着省钱了。
2.我们在本地测试部署hadoop或者ceph存储集群的时候用的是centos,但是生产环境服务器上的系统都是Ubuntu,运维在按照我们的安装文档从开发测试环境转移到生产环境的时候就会遇到一些centos转Ubuntu的问题。
Centos与Ubuntu的使用习惯和命令上还是有很多的不同,下面简单列举一下:
一. centos中新建的非root用户是没有sudo的权限的,如果需要使用sudo权限必须在/etc/sudoers 中加入账户和权限,所以切换到root账号的时候只需要输入:su,加入root账号的密码即可。 在Ubuntu中,一般使用sudo+命令,如果是第一次使用会提示输入当前用户的密码(而不是root的密码)
二. 在线安装软件中,centos使用的是yum命令,而ubuntu中使用的是apt-get命令。除此之外yum中还有一个从软件源中搜索摸个软件的方法:yum search + 软件名
三. centos是来自于redhat,所以centos支持rpm格式的安装,而ubuntu显然是不支持的。
四. 毕竟是不同的公司做的不同的发行版,很多配置文件的位置和默认的文件路径都有很大区别,这个需要使用过程中慢慢体会了。
比如:有某条命令,只有centos支持,Ubuntu不支持,在转移的过程当中运维就得想办法解决这样的问题。
这时候要是有docker我们就可以把开发环境直接封装转移给运维,运维直接部署你给他的docker就可以了。而且部署速度快。
3.在服务器负载方面,如果你单独开一个虚拟机,那么虚拟机会占用空闲内存的,docker部署的话,这些内存就会利用起来。
总之docker就是集装箱的思想。
一些基本概念和共识
container: 容器,是指image的运行时,包含了文件资源(image展开)和系统资源(变成process存在于系统中)
image: 镜像,是指将应用打包好之后的存储方式,一个image包含多层layer
layer: 在Dockerfile中每一步都会产生一层layer,每一步的结果产出变成文件
Dockerfile: 一种构建image的文件的DSL
docker: 可以通过Dockerfile构建image,也可以将image运行,使其变成container
moby: docker项目的新名字,docker公司的一步棋
docker-compose: Python写的一个docker编排工具
docker swarm: docker公司推出的容器调度平台
kubernetes: google主导的容器调度平台
容器调度平台: 一般来说是由M个master和N个worker节点组成的一个集群,上面可以整合宿主机资源,完成网络、存储、CPU、内存等资源的管理,将容器运行在不同的主机上。
关于跨平台
我们在简介时说到docker适用于Linux平台(仅适用),但是又能在windows和OS X mac等系统上安装,为什么呢?
其实docker并没有跨平台,它运行依赖Linux内核,在OS X和windows运行docker会先产生一个Linux虚拟机。至于所谓的跨平台,其实添加了一层间接,如java,运行在不同的os中的jvm上,而不是直接在os里运行。
docker如VM,image就是你装vm虚拟机时的iso文件,容器就是正在vm中运行的虚拟机,这个虚拟机可以备份为一个vmdk文件,在其它vm中运行。现在win和mac都可以体验docker了,可以装来玩玩,写dockerfile才是docker的重点。
对 Docker 最简单并且带有一定错误的认知就是 “Docker 是一种性能非常好的虚拟机”。Docker 相比于传统虚拟机的技术来说先进了不少,具体表现在 Docker 不是在宿主机上虚拟出一套硬件后再虚拟出一个操作系统,而是让 Docker 容器里面的进程直接运行在宿主机上(Docker 会做文件、网络等的隔离),这样一来 Docker 会 “体积更轻、跑的更快、同宿主机下可创建的个数更多”。
Docker的目标
Docker项目的目标是实现轻量级的操作系统虚拟化解决方案,创建软件程序可移植的轻量容器。
Docker是一个开源项目,也是一个产品。
如果你是产品经理,肯定要知道它的目标用户以及目标场景。
官方对自己的定位一直很简单:an open platform to build, ship, and run any app, anywhere。
这是官方定义的Docker也是他们的初衷。
Docker真正火起来的原因是什么了?
What can Docker do for me,有几个重要的点:
1、Get a well-defined, reproducible environment
2、Define this environment in a Dockerfile
3、Build this Dockerfile into a container image
4、Run this container image anywhere
好的产品一定是解决了某一个需求,而Docker也不例外,Docker的亮点是可以通过镜像来定义环境,实现隔离的,跨平台的,快速复制运行。
Docker优点
1、Docker提供隔离的运行环境
文件系统隔离
网络隔离
进程号隔离
进程间通信隔离
2、容器性能开销极低
Docker技术虽然是虚拟化技术,却几乎不消耗除容器中的应用程序外的其他资源,可以达到近乎裸机的运行能力,达到秒级/微秒级的部署,一台实体机可以运行几百甚至上千个docker容器。
3、容易移植
有很高的移植性,可以在任何平台运行(包括物理机、虚拟机、云平台)。
过去需要用数天乃至数周的环境移植任务,在Docker容器的处理下,只需要数秒就能完成。
Docker缺点
1、Docker容器受到的资源限制
CPU计算资源
内存资源
磁盘I/O资源等
Docker的应用场景
Web 应用的自动化打包和发布。
自动化测试和持续集成、发布。
多环境的部署切换。
复杂环境一键配置。
在服务型环境中部署和调整数据库或其他的后台应用。
在openstack等iaas云平台上搭建自己的PaaS环境。
从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。
同应用多版本隔离、文件隔离。
Docker的价值
更快交付你的应用(Faster delivery of your applications)
让部署和测试更简单(Deploying and scaling more easily)
实现更高密度和更多的负载(Achieving higher density and running more workloads)
Docker与虚拟机的关系和区别
每个虚拟机不仅包括程序、程序需要的包,而且还包含了一个操作系统,但是Docker容器是共享一个操作系统内核(kernel)的,这些容器通过命名空间相互独立。
在图中我们可以看到Docker和Virtual Machine在实现资源隔离和环境隔离的方式完全不同。
虚拟机实现资源隔离和环境隔离的方法是利用独立的OS,并利用Hypervisor(Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可允许多个操作系统和应用共享一套基础物理硬件。当服务器启动并执行Hypervisor时,它会给每一台虚拟机分配适量的内存、CPU、网络和磁盘,并加载所有虚拟机的客户操作系统。)虚拟化CPU、内存、IO设备等实现的。
例如,为了虚拟CPU,Hypervisor会为每个虚拟的CPU创建一个数据结构,模拟CPU的全部寄存器的值,在适当的时候跟踪并修改这些值。需要指出的是在大多数情况下,虚拟机软件代码是直接跑在硬件上的,而不需要Hypervisor介入。只有在一些权限高的请求下,Guest OS需要运行内核态修改CPU的寄存器数据,Hypervisor会介入,修改并维护虚拟的CPU状态。 Hypervisor虚拟化内存的方法是创建一个shadow page table。正常的情况下,一个page table可以用来实现从虚拟内存到物理内存的翻译。在虚拟化的情况下,由于所谓的物理内存仍然是虚拟的,因此shadow page table就要做到:虚拟内存->虚拟的物理内存->真正的物理内存。 对于IO设备虚拟化,当Hypervisor接到page fault,并发现实际上虚拟的物理内存地址对应的是一个I/O设备,Hypervisor就用软件模拟这个设备的工作情况,并返回。比如当CPU想要写磁盘时,Hypervisor就把相应的数据写到一个host OS的文件上,这个文件实际上就模拟了虚拟的磁盘。
对比虚拟机实现资源和环境隔离的方案,Docker就显得简练很多。Docker Engine可以简单看成对Linux的NameSpace、Cgroup、镜像管理文件系统操作的封装。Docker并没有和虚拟机一样利用一个完全独立的Guest OS实现环境隔离,它利用的是目前Linux内核本身支持的容器方式实现资源和环境隔离。简单的说,Docker利用namespace实现系统环境的隔离;利用Cgroup实现资源限制;利用镜像实现根目录环境的隔离。
Docker有着比虚拟机更少的抽象层。由于Docker不需要Hypervisor实现硬件资源虚拟化,运行在Docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上Docker将会在效率上有优势。
Docker利用的是宿主机的内核,而不需要Guest OS。因此,当新建一个容器时,Docker不需要和虚拟机一样重新加载一个操作系统内核。我们知道,引导、加载操作系统内核是一个比较费时费资源的过程,当新建一个虚拟机时,虚拟机软件需要加载Guest OS,这个新建过程是分钟级别的。而Docker由于直接利用宿主机的操作系统,则省略了这个过程,因此新建一个Docker容器只需要几秒钟。另外,现代操作系统是复杂的系统,在一台物理机上新增加一个操作系统的资源开销是比较大的,因此,Docker对比虚拟机在资源消耗上也占有比较大的优势。
虚拟机隔离得好,但是消耗大(每个虚拟机都需要维护一个单独的OS操作系统),docker则放弃某些隔离效果换来低消耗:
同样的物理机,同时运行10个虚拟机,可能就力不从心了,docker相当于轻量级的虚拟机,同样的物理机,同时运行成千上万个docker都可能,而且启动非常快。
虚拟机都有一个“硬件”自检、OS启动的过程;docker基本无这个过程,因为是直接运行在物理机的OS上的。
但虚拟机可以在OS1上同时运行出n个OS1和m个OS2、p个OS3,也就是虚拟机之间可以使用不同的操作系统,而docker只能在OS1上同时运行x个OS1(虽然x>>n+m+p+…),它依赖于原操作系统。
Docker的结构
Docker 使用客户端-服务器 (C/S) 架构模式,使用远程API来管理和创建Docker容器。
Docker 容器通过 Docker 镜像来创建。
容器与镜像的关系类似于面向对象编程中的对象与类。
Docker 守护进程(daemon)
Docker Daemon是Docker架构中运行在后台的守护进程,Docker daemon运行在宿主机上,用户不能直接操作daemon,只能通过docker client转达。
Docker 镜像(Images)
Docker 镜像是用于创建 Docker 容器的模板。
Docker 容器(Container)
容器是独立运行的一个或一组应用。
Docker 客户端(Client)
Docker 客户端通过命令行或者其他工具使用 Docker API (https://docs.docker.com/reference/api/docker_remote_api) 与 Docker 的守护进程通信。
Docker 主机(Host)
一个物理或者虚拟的机器用于执行 Docker 守护进程和容器。
Docker 仓库(Registry)
Docker 仓库用来保存镜像,可以理解为代码控制中的代码仓库。
Docker Hub(https://hub.docker.com) 提供了庞大的镜像集合供使用。
Docker Machine
Docker Machine是一个简化Docker安装的命令行工具,通过一个简单的命令行即可在相应的平台上安装Docker,比如VirtualBox、 Digital Ocean、Microsoft Azure。
Docker的组件
Docker Engine:提供了docker 创建镜像和运行容器等的核心方法。
Docker Hub:类似于gitHub的东西,不过上面是docker 镜像
Docker Machine :在云端或者其他网络环境中的Docker主机。
Docker Compose:用于定义多容器的应用。相当于省去了Docker container容器启动时输入的参数,让多种容器之间的关系更加清晰,构建多个容器更加方便。
Docker Toolbox:在Mac和Windows安装上的Docker安装程序,正常大家安装的Docker就是它,整合了所有的Docker 组件和工具,例如:Engine、Machine、Compose 还有Kitematic(可视化工具)。
Docker Trusted Registry;创建私有的专用的镜像仓库。
Docker Registry:创建开源的镜像仓库。
Docker Swarm:和Docker Machine一起配合做Docker集群相关的工作。
Docker网络
Docker的网络功能相对简单,没有过多复杂的配置,Docker默认使用birdge桥接方式与容器通信,启动Docker后,宿主机上会产生docker0这样一个虚拟网络接口, docker0不是一个普通的网络接口, 它是一个虚拟的以太网桥,可以为绑定到docker0上面的网络接口自动转发数据包,这样可以使容器与宿主机之间相互通信。每次Docker创建一个容器,会产生一对虚拟接口,在宿主机上执行ifconfig,会发现多了一个类似veth****这样的网络接口,它会绑定到docker0上,由于所有容器都绑定到docker0上,容器之间也就可以通信。
在宿主机上执行ifconfig,会看到docker0这个网络接口, 启动一个container,再次执行ifconfig, 会有一个类似veth***的interface,每个container的缺省路由是宿主机上docker0的ip,在container中执行netstat -r可以看到如下图所示内容:
容器中的默认网关跟docker0的地址是一样的:
当容器退出之后,veth虚拟接口也会被销毁。
除bridge方式,Docker还支持host、container、none三种网络通信方式,使用其它通信方式,只要在Docker启动时,指定–net参数即可,比如:
docker run -i -t --net=host ubuntu /bin/bash
host方式可以让容器无需创建自己的网络协议栈,而直接访问宿主机的网络接口,在容器中执行ip addr会发现与宿主机的网络配置是一样的,host方式让容器直接使用宿主机的网络接口,传输数据的效率会更加高效,避免bridge方式带来的额外开销,但是这种方式也可以让容器访问宿主机的D-bus等网络服务,可能会带来意想不到的安全问题,应谨慎使用host方式;container方式可以让容器共享一个已经存在容易的网络配置; none方式不会对容器的网络做任务配置,需要用户自己去定制。
每个进程容器运行在自己的网络命名空间里,拥有自己的虚拟接口和IP地址。
注意:docker的端口映射有一个坑,在非Linux上安装docker(比如Windows和MacOS),都是在本机上安装Linux的虚拟机,所有当你在docker运行tomcat时,访问“localhost:8080” 是不会有响应的,你应该把localhost换成运行此docker的Linux虚拟机的IP地址。但是在Linux上,就可以通过”localhost:8080” 访问到tomcat。
Docker的运行流程
正如上图所示,当我们想运行一个容器的时候,docker会:
1、拉取镜像,若本地已经存在该镜像,则不用到网上去拉取
2、创建新的容器
3、分配union文件系统并且挂着一个可读写的层,任何修改容器的操作都会被记录在这个读写层上,你可以保存这些修改成新的镜像,也可以选择不保存,那么下次运行改镜像的时候所有修改操作都会被消除
4、分配网络\桥接接口,创建一个允许容器与本地主机通信的网络接口
5、设置ip地址,从池中寻找一个可用的ip地址附加到容器上,换句话说,localhost并不能访问到容器
6、运行你指定的程序
7、捕获并且提供应用输出,包括输入、输出、报错信息
Docker核心技术和原理
Docker核心是一个操作系统级虚拟化方法, 理解起来可能并不像VM那样直观。我们从虚拟化方法的四个方面:隔离性、可配额/可度量、便携性、安全性来详细介绍Docker的技术细节。
隔离性: Linux Namespace(ns)
每个用户实例之间相互隔离, 互不影响。 一般的硬件虚拟化方法给出的方法是VM,而LXC给出的方法是container,更细一点讲就是kernel namespace。其中pid、net、ipc、mnt、uts、user等namespace将container的进程、网络、消息、文件系统、UTS(“UNIX Time-sharing System”)和用户空间隔离开。
- pid namespace
不同用户的进程就是通过pid namespace隔离开的,且不同 namespace 中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程,每个lxc进程具有不同的namespace。同时由于允许嵌套,因此可以很方便的实现 Docker in Docker。
- net namespace
有了 pid namespace, 每个namespace中的pid能够相互隔离,但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的, 每个net namespace有独立的 network devices, IP addresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge: docker0连接在一起。
- ipc namespace
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是,container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互,因此需要在IPC资源申请时加入namespace信息 - 每个IPC资源有一个唯一的 32 位 ID。
- mnt namespace
类似chroot,将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同,这样每个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不同,每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
- uts namespace
UTS(“UNIX Time-sharing System”) namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
- user namespace
每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户。
可配额/可度量 - Control Groups (cgroups)
cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单,提供类似文件的接口,在 /cgroup目录下新建一个文件夹即可新建一个group,在此文件夹中新建task文件,并将pid写入该文件,即可实现对该进程的资源控制。groups可以限制blkio、cpu、cpuacct、cpuset、devices、freezer、memory、net_cls、ns九大子系统的资源,以下是每个子系统的详细说明:
blkio 这个子系统设置限制每个块设备的输入输出控制。例如:磁盘,光盘以及usb等等。
cpu 这个子系统使用调度程序为cgroup任务提供cpu的访问。
cpuacct 产生cgroup任务的cpu资源报告。
cpuset 如果是多核心的cpu,这个子系统会为cgroup任务分配单独的cpu和内存。
devices 允许或拒绝cgroup任务对设备的访问。
freezer 暂停和恢复cgroup任务。
memory 设置每个cgroup的内存限制以及产生内存资源报告。
net_cls 标记每个网络包以供cgroup方便使用。
ns 名称空间子系统。
以上九个子系统之间也存在着一定的关系.详情请参阅官方文档。
便携性: AUFS
AUFS (AnotherUnionFS) 是一种 Union FS, 简单来说就是支持将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)的文件系统, 更进一步的理解, AUFS支持为每一个成员目录(类似Git Branch)设定readonly、readwrite 和 whiteout-able 权限, 同时 AUFS 里有一个类似分层的概念, 对 readonly 权限的 branch 可以逻辑上进行修改(增量地, 不影响 readonly 部分的)。通常 Union FS 有两个用途, 一方面可以实现不借助 LVM、RAID 将多个disk挂到同一个目录下, 另一个更常用的就是将一个 readonly 的 branch 和一个 writeable 的 branch 联合在一起,Live CD正是基于此方法可以允许在 OS image 不变的基础上允许用户在其上进行一些写操作。Docker 在 AUFS 上构建的 container image 也正是如此,接下来我们从启动 container 中的 linux 为例来介绍 docker 对AUFS特性的运用。
典型的启动Linux运行需要两个FS: bootfs + rootfs:
bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引导加载kernel, 当boot成功后 kernel 被加载到内存中后 bootfs就被umount了. rootfs (root file system) 包含的就是典型 Linux 系统中的 /dev, /proc,/bin, /etc 等标准目录和文件。
对于不同的linux发行版, bootfs基本是一致的, 但rootfs会有差别, 因此不同的发行版可以公用bootfs 如下图:
典型的Linux在启动后,首先将 rootfs 设置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite” 供用户使用。在Docker中,初始化时也是将 rootfs 以readonly方式加载并检查,然而接下来利用 union mount 的方式将一个 readwrite 文件系统挂载在 readonly 的rootfs之上,并且允许再次将下层的 FS(file system) 设定为readonly 并且向上叠加, 这样一组readonly和一个writeable的结构构成一个container的运行时态, 每一个FS被称作一个FS层。如下图:
得益于AUFS的特性, 每一个对readonly层文件/目录的修改都只会存在于上层的writeable层中。这样由于不存在竞争, 多个container可以共享readonly的FS层。 所以Docker将readonly的FS层称作 “image” - 对于container而言整个rootfs都是read-write的,但事实上所有的修改都写入最上层的writeable层中, image不保存用户状态,只用于模板、新建和复制使用。
上层的image依赖下层的image,因此Docker中把下层的image称作父image,没有父image的image称作base image。因此想要从一个image启动一个container,Docker会先加载这个image和依赖的父images以及base image,用户的进程运行在writeable的layer中。所有parent image中的数据信息以及 ID、网络和lxc管理的资源限制等具体container的配置,构成一个Docker概念上的container。如下图:
安全性: AppArmor, SELinux, GRSEC
安全永远是相对的,这里有三个方面可以考虑Docker的安全特性:
由kernel namespaces和cgroups实现的Linux系统固有的安全标准;
Docker Deamon的安全接口;
Linux本身的安全加固解决方案,类如AppArmor, SELinux;
由于安全属于非常具体的技术,这里不在赘述,请直接参阅Docker官方文档。
Docker生态
随着Docker迅速火遍全球, 以Docker为基础的生态系统也迅速的发展起来,从以部署和运行container为基础的CoreOS到各种各样的管理工具和PaaS软件,Docker以及生态产品都在迅猛发展,以下介绍几个代表性的软件。
首先介绍CoreOS,它的出现极大地推动了Docker技术的推广和发展,CoreOS是专门为大规模服务部署而设计的一种新的Linux发行版,通过运行轻量级的容器方便扩展和维护大规模的服务。它具有以下特点:
CoreOS使用container管理服务(容器即服务),即以容器的角度去管理服务,服务的代码和依赖都打包到容器里,打包后的容器直接在CoreOS上运行管理。通过容器用户不再需要关注虚拟机环境等,极大地降低了服务和系统环境的耦合性。另外部署在CoreOS的多个容器都运行在各自独立的环境中,不会相互影响。
CoreOS专门为cluster等大规模部署而设计,提供了Etcd进行服务发现,以及Fleet管理容器保证服务可用。
CoreOS更加精简,比如RAM使用比普通Linux低40%。
CoreOS采用双分区模式(Dual-Partition),主分区为主动模式,负责系统运行,被动模式分区负责系统更新,更新时将整个CoreOS系统下载下来。
CoreOS是为集群服务而设计的,提供了Etcd、Fleet等管理工具管理容器和服务。Etcd是一种类似Zookeeper的分布式key/value存储服务,用于服务发现和配置管理。Fleet是容器管理工具,保证服务的可用性,当某个机器的服务不可用时,Fleet会将服务迁移到其它机器上运行。
Docker生态中还有一个非常重要的容器管理工具–Kubernetes,它是Google开源的用于在集群环境中管理、维护、自动扩展容器,通过Kubernetes可以很方便地在多个机器上管理和部署容器服务。现在已经得到IBM、Microsoft、RedHat等多个大公司的支持。
在Kubernetes中pod是一个基本单元,一个pod可以是提供相同功能的多个container,这些容器会被部署在同一个minion上。Replication controller定义了多个pod或者容器需要运行,如果当前集群中运行的pod或容器达不到配置的数量,replication controller会调度容器在多个minion上运行,保证集群中的pod数量。service则定义真实对外提供的服务,一个service会对应后端运行的多个container。Kubernetes的架构由一个master和多个minion组成,master通过api提供服务,接受kubectl的请求来调度管理整个集群。minion是运行Kubelet的机器,它接受master的指令创建pod或者容器。
最后介绍一下基于Docker实现的PaaS软件,Docker PaaS软件中以Deis和Flynn最为知名。Deis是基于Docker和CoreOS实现的轻量级的PaaS,受到Heroku的启发,遵循“十二要素”构建应用方法。Deis是以应用程序为中心设计的,分为build、release、run三个阶段,用户执行”git push”后,Deis使用Docker 容器编译并将编译结果保存在Docker镜像;发布阶段,一次build和配置文件产生一个数字标识的发布镜像,将发布镜像保存到Docker registry中以供后续发布到线上运行;运行阶段应用镜像会被调度到主机上运行,并更新相应的路由。Flynn与Deis类似,也是以应用为中心,Flynn组件分为两层,layer0是底层资源的抽象,主要负责资源调度以及服务发现等,为上层应用容器的运行提供底层资源调度支持;layer1处理具体应用,通过Docker容器编译、部署和维护上层应用程序。
Docker从2013年发布第一个版本以来,已经火遍全球,技术迭代也比较频繁,其周边产品和技术也越来越丰富,由于Docker更新频繁,会出现新版本有时不兼容旧版本的情况,Docker周边产品基本都处于开发阶段还不具备生产环境下使用。
Docker的轻量级容器不仅实现了资源隔离,而且几乎可以运行在任何地方,使得部署和扩展变得非常容易,随着Docker的日趋完善,希望Docker被越来越多的公司应用到生产环境中。