赞
踩
Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中。然后发布到任何流行的 Linux或Windows 机器上,也可以实现虚拟化。 容器是完全使用沙箱机制,相互之间不会有任何接口。
一个完整的Docker有以下几个部分组成:
DockerClient客户端
Docker Daemon守护进程
Docker Image镜像
DockerContainer容器
Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎,源代码托管在 Github 上, 基于go语言并遵从Apache2.0协议开源。
Docker自2013年以来非常火热,无论是从 github 上的代码活跃度,还是Redhat在RHEL6.5中集成对Docker的支持, 就连 Google 的 Compute Engine 也支持 docker 在其之上运行。
一款开源软件能否在商业上成功,很大程度上依赖三件事 - 成功的 user case(用例), 活跃的社区和一个好故事。
dotCloud 自家的 PaaS 产品建立在docker之上,长期维护且有大量的用户,社区也十分活跃,接下来我们看看docker的故事。
- 环境管理复杂 - 从各种OS到各种中间件到各种app, 一款产品能够成功作为开发者需要关心的东西太多,且难于管理,这个问题几乎在所有现代IT相关行业都需要面对。
- 云计算时代的到来 - AWS的成功, 引导开发者将应用转移到 cloud 上, 解决了硬件管理的问题,然而中间件相关的问题依然存在 (所以openstack HEAT和 AWS cloudformation 都着力解决这个问题)。开发者思路变化提供了可能性。
- 虚拟化手段的变化 - cloud 时代采用标配硬件来降低成本,采用虚拟化手段来满足用户按需使用的需求以及保证可用性和隔离性。然而无论是KVM还是Xen在 docker 看来,都在浪费资源,因为用户需要的是高效运行环境而非OS, GuestOS既浪费资源又难于管理, 更加轻量级的LXC更加灵活和快速
- LXC的移动性 - LXC在 linux 2.6 的 kernel 里就已经存在了,但是其设计之初并非为云计算考虑的,缺少标准化的描述手段和容器的可迁移性,决定其构建出的环境难于迁移和标准化管理(相对于KVM之类image和snapshot的概念)。docker 就在这个问题上做出实质性的革新。这是docker最独特的地方。
Docker 属于 Linux 容器的一种封装,提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案,网易云也在使用Docker。而 Linux 容器是 Linux 发展出的另一种虚拟化技术,简单来讲, Linux 容器不是模拟一个完整的操作系统,而是对进程进行隔离,相当于是在正常进程的外面套了一个保护层。对于容器里面的进程来说,它接触到的各种资源都是虚拟的,从而实现其与底层系统的隔离。
Docker 将应用程序与该程序的依赖打包在一个文件里面。运行这个文件,就会生成一个虚拟容器。程序在这个虚拟容器里运行,就好像在真实的物理机上运行一样。有了 Docker ,就不用担心环境问题。
总体来说, Docker 的接口相当简单,用户可以方便地创建和使用容器,把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改,就像管理普通的代码一样。
服务器虚拟化解决的核心问题是资源调配,而容器解决的核心问题是应用开发、测试和部署。
虚拟机Virtual Machine与容器化技术(代表Docker)都是虚拟化技术,而容器化技术并不是虚拟机。
容器技术:对于容器,它首先是一个相对独立的运行环境,在这一点有点类似于虚拟机,但是不像虚拟机那样彻底。在容器内,应该最小化其对外界的影响,比如不能在容器内把宿主机上的资源全部消耗,这就是资源控制。容器技术严格来说并不是虚拟化,没有隔离操作系统,是共享内核的。
- 从两者的架构图上看,虚拟机是在硬件级别进行虚拟化,模拟硬件搭建操作系统;而Docker是在操作系统的层面虚拟化,复用操作系统,运行Docker容器。
- Docker的速度很快,秒级,而虚拟机的速度通常要按分钟计算。
- Docker所用的资源更少,性能更高。同样一个物理机器,Docker运行的镜像数量远多于虚拟机的数量。
- 虚拟机实现了操作系统之间的隔离,Docker算是进程之间的隔离,虚拟机隔离级别更高、安全性方面也更强。
虚拟机是在物理资源层面实现的隔离,相对于虚机,Docker是APP层面实现的隔离,并且省去了虚拟机操作系统(Guest OS),从而节省了一部分的系统资源;Docker守护进程可以直接与主操作系统进行通信,为各个Docker容器分配资源;它还可以将容器与主操作系统隔离,并将各个容器互相隔离。虚拟机启动需要数分钟,而Docker容器可以在数毫秒内启动。由于没有臃肿的从操作系统,Docker可以节省大量的磁盘空间以及其他系统资源。
虚拟机与容器docker的区别,在于虚拟机多了一层guest OS,虚拟机的Hypervisor会对硬件资源也进行虚拟化,而容器Docker会直接使用宿主机的硬件资源。
服务器:比作一个大型的仓管基地,包含场地与零散的货物——相当于各种服务器资源。
虚拟机技术:比作仓库,拥有独立的空间堆放各种货物或集装箱,仓库之间完全独立——仓库相当于各种系统,拥有独立的应用系统和操作系统。虚拟机技术通过Hypervisor层抽象底层基础设施资源,提供相互隔离的虚拟机,通过统一配置、统一管理,计算资源的可运维性,以及资源利用率都能够得到有效的提升。同时,虚拟机提供客户机操作系统,客户机变化不会影响宿主机,能够提供可控的测试环境,更能够屏蔽底层硬件甚至基础软件的差异性,让应用做到的广泛兼容。然而,再牛逼的虚拟化技术,都不可避免地出现计算、IO、网络性能损失,毕竟多了一层软件,毕竟要运行一个完整的客户机操作系统。
Docker:比作集装箱,操作各种货物的打包——将各种应用程序和他们所依赖的运行环境打包成标准的容器,容器之间隔离。容器可以视为软件供应链的集装箱,能够把应用需要的运行环境、缓存环境、数据库环境等等封装起来,以最简洁的方式支持应用运行,轻装上阵,使性能更佳。Docker镜像特性则让这种方式简单易行。因为共享内核,容器隔离性也没有虚拟机那么好。
序号 | 优势 |
---|---|
1 | docker 启动快速属于秒级别,虚拟机通常需要几分钟去启动 |
2 | docker 需要的资源更少, docker 在操作系统级别进行虚拟化, docker 容器和内核交互,几乎没有性能损耗,性能优于通过 Hypervisor 层与内核层的虚拟化 |
3 | docker 更轻量, docker 的架构可以共用一个内核与共享应用程序库,所占内存极小。同样的硬件环境, Docker 运行的镜像数远多于虚拟机数量,对系统的利用率 |
4 | 与虚拟机相比, docker 隔离性更弱, docker 属于进程之间的隔离,虚拟机可实现系统级别隔离 |
5 | 安全性: docker 的安全性也更弱。 Docker 的租户 root 和宿主机 root 等同,一旦容器内的用户从普通用户权限提升为root权限,它就直接具备了宿主机的root权限,进而可进行无限制的操作。虚拟机租户 root 权限和宿主机的 root 虚拟机权限是分离的,并且虚拟机利用如 Intel 的 VT-d 和 VT-x 的 ring-1 硬件隔离技术,这种隔离技术可以防止虚拟机突破和彼此交互,而容器至今还没有任何形式的硬件隔离,这使得容器容易受到攻击 |
6 | 可管理性: docker 的集中化管理工具还不算成熟。各种虚拟化技术都有成熟的管理工具,例如 VMware vCenter 提供完备的虚拟机管理能力 |
7 | 高可用和可恢复性: docker 对业务的高可用支持是通过快速重新部署实现的。虚拟化具备负载均衡,高可用,容错,迁移和数据保护等经过生产实践检验的成熟保障机制, VMware 可承诺虚拟机 99.999% 高可用,保证业务连续性 |
8 | 快速创建、删除:虚拟化创建是分钟级别的, Docker 容器创建是秒级别的, Docker 的快速迭代性,决定了无论是开发、测试、部署都可以节约大量时间 |
9 | 交付、部署:虚拟机可以通过镜像实现环境交付的一致性,但镜像分发无法体系化。 Docker 在 Dockerfile 中记录了容器构建过程,可在集群中实现快速分发和快速部署 |
以上可总结归纳为:
特性 | 启动 | 磁盘使用 | 性能 | 系统支持量 |
---|---|---|---|---|
容器 | 秒级 | 一般为MB | 接近原生 | 单机支持上千个容器 |
虚拟机 | 分钟级 | 一般为GB | 弱于 | 一般是几十个 |
Image—镜像
Container—容器
Repository—仓库
从左边可以看到多个只读层重叠在一起。除了最下面一层,其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节,并且能够在主机(译者注:运行Docker的机器)的文件系统上访问到。统一文件系统(union file system)技术能够将不同的层整合成一个文件系统,为这些层提供了一个统一的视角,这样就隐藏了多层的存在,在用户的角度看来,只存在一个文件系统。我们可以在图片的右边看到这个视角的形式。
可以在自己的主机文件系统上找到有关这些层的文件。需要注意的是,在一个运行中的容器内部,这些层是不可见的。在我的主机上它们存在于/var/lib/docker/aufs目录下。
# sudo tree -L 1 /var/lib/docker/
/var/lib/docker/
├── aufs
├── containers
├── graph
├── init
├── linkgraph.db
├── repositories-aufs
├── tmp
├── trust
└── volumes
7 directories, 2 files
容器 = 镜像 + 读写层
容器的定义并没有提及是否要
运行容器
。接下来,我们讨论的是运行态容器。
一个运行态容器(如上图)被定义为一个可读写的统一文件系统加上隔离的进程空间和包含其中的进程。
正是文件系统隔离技术
使得Docker成为了一个前途无量的技术。一个容器中的进程可能会对文件进行修改、删除、创建,这些改变都将作用于可读写层(read-write layer)。如下图:
>
镜像层(Image Layer Definition)
的作用是:将零星的数据整合起来。
通过图片我们能够发现一个层并不仅仅包含文件系统的改变,它还能包含了其他重要信息。例如元数据
、指向父层的指针
等。
元数据(metadata)(如上图)就是关于这个层的额外信息,它不仅能够让Docker获取运行和构建时的信息,还包括父层的层次信息。需要注意的是,只读层和读写层都包含元数据。
除元数据外,每一层都有一个指向父层的指针(如上图)。如果一层没有指向父层的指针,就说明它处于最底层。
Metadata Location:
在我的主机上,镜像层的元数据被保存在名为”json”的文件中,比如说:/var/lib/docker/graph/f733e312ab319.../json
其中`f733e312ab319...`就是这层的ID。
一个容器的元数据好像是被分成了很多文件,但或多或少能够在/var/lib/docker/containers/目录下找到,就是一个可读层的ID。这个目录下的文件大多是运行时的数据,例如网络文件、日志文件等。
有时候会把
仓库 (Repository)
和仓库注册服务器 (Registry)
混为一谈,并不严格区分。Docker 仓库的概念跟 Git 类似,注册服务器可以理解为 GitHub 这样的托管服务。实际上,一个 Docker Registry 中可以包含多个仓库 (Repository) ,每个仓库可以包含多个标签,每个标签对应着一个镜像。所以说,镜像仓库是 Docker 用来集中存放镜像文件的地方类似于我们之前常用的代码仓库。
通常,一个仓库会包含同一个软件不同版本的镜像,而标签就常用于对应该软件的各个版本 。我们可以通过
<仓库名>:<标签>
的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签,将以latest
作为默认标签.。
仓库又可以分为两种形式:
Docker Registry 公有仓库是开放给用户使用、允许用户管理镜像的 Registry 服务。一般这类公开服务允许用户免费上传、下载公开的镜像,并可能提供收费服务供用户管理私有镜像。
除了使用公开服务外,用户还可以在本地搭建私有 Docker Registry 。Docker 官方提供了 Docker Registry 镜像,可以直接使用做为私有 Registry 服务。当用户创建了自己的镜像之后就可以使用 push 命令将它上传到公有或者私有仓库,这样下次在另外一台机器上使用这个镜像时候,只需要从仓库上 pull 下来就可以了。
把 Docker 的一些常见概念如 镜像 ,容器,仓库 做了详细的阐述,也从传统虚拟化方式的角度阐述了 Docker 的优势,从下图我们可以直观地看到 Docker 的架构:
Docker 使用 C/S 结构
,即 客户端/服务器
体系结构。 Docker 客户端与 Docker 服务器进行交互,Docker服务端负责构建、运行和分发 Docker 镜像。 Docker 客户端和服务端可以运行在一台机器上,也可以通过 RESTful 、 stock 或网络接口与远程 Docker 服务端进行通信。
上图展示了 Docker 客户端、服务端和 Docker 仓库(即 Docker Hub 和 Docker Cloud ),默认情况下Docker 会在 Docker 中央仓库寻找镜像文件,这种利用仓库管理镜像的设计理念类似于 Git 。当然,这个仓库是可以通过修改配置来指定的,甚至我们可以创建我们自己的私有仓库。
Docker 使用客户端-服务器 (C/S) 架构
模式,使用远程API来管理和创建Docker容器。
Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。
Docker | 容器 | 镜像 |
---|---|---|
面向对象编程 | 对象 | 类 |
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。