Finish the basic content for the underly chapter
parent
d83e318b8c
commit
b1e6415b8f
|
@ -1 +1,13 @@
|
||||||
|
#底层实现
|
||||||
|
|
||||||
Docker底层的核心技术包括Linux上的名字空间(Namespaces)、控制组(Control groups)、Union文件系统(Union file systems)和容器格式(Container format)。
|
Docker底层的核心技术包括Linux上的名字空间(Namespaces)、控制组(Control groups)、Union文件系统(Union file systems)和容器格式(Container format)。
|
||||||
|
|
||||||
|
我们知道,传统的虚拟机通过在宿主主机中运行hypervisor来模拟一整套完整的硬件环境提供给虚拟机的操作系统。虚拟机系统看到的环境是可限制的,也是彼此隔离的。
|
||||||
|
这种直接的做法实现了对资源最完整的封装,但很多时候往往意味着系统资源的浪费。
|
||||||
|
例如,以宿主机和虚拟机系统都为Linux系统为例,虚拟机中运行的应用其实可以利用宿主机系统中的运行环境。
|
||||||
|
|
||||||
|
我们知道,在操作系统中,包括内核、文件系统、网络、PID、UID、IPC、内存、硬盘、CPU等等,所有的资源都是应用进程直接共享的。
|
||||||
|
要想实现虚拟化,除了要实现对内存、CPU、网络IO、硬盘IO、存储空间等的限制外,还要实现文件系统、网络、PID、UID、IPC等等的相互隔离。
|
||||||
|
前者相对容易实现一些,后者则需要宿主机系统的深入支持。
|
||||||
|
|
||||||
|
随着Linux系统对于名字空间功能的完善实现,程序员已经可以实现上面的所有需求,让某些进程在彼此隔离的名字空间中运行。大家虽然都共用一个内核和某些运行时环境(例如一些系统命令和系统库),但是彼此却看不到,都以为系统中只有自己的存在。这种机制就是容器(Container),例如名字空间来做权限的隔离控制,利用cgroups来做资源分配。
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
##基本架构
|
## 基本架构
|
||||||
Docker采用了C/S架构,包括客户端和服务端。
|
Docker采用了C/S架构,包括客户端和服务端。
|
||||||
docker daemon作为服务端接受来自客户的请求,并处理这些请求(创建、运行、分发容器)。
|
docker daemon作为服务端接受来自客户的请求,并处理这些请求(创建、运行、分发容器)。
|
||||||
客户端和服务端既可以运行在一个机器上,也可通过socket或者RESTful API来进行通信。
|
客户端和服务端既可以运行在一个机器上,也可通过socket或者RESTful API来进行通信。
|
||||||
|
|
|
@ -1,3 +1,9 @@
|
||||||
##控制组
|
## 控制组
|
||||||
|
|
||||||
|
控制组([cgroups](http://en.wikipedia.org/wiki/Cgroups))是Linux内核的一个特性,主要用来隔离各个容器和宿主主机的资源利用。只有能控制分配到容器的资源,才能避免当多个容器同时运行时的彼此资源竞争。
|
||||||
|
|
||||||
|
控制组技术最早是由Google的程序员2006年起提出,Linux内核自2.6.24开始支持。
|
||||||
|
|
||||||
|
控制组可以提供对容器内内存、CPU、磁盘IO等资源的限制和计费管理。
|
||||||
|
|
||||||
|
|
||||||
主要用来隔离各个容器和宿主主机的资源利用。
|
|
||||||
|
|
|
@ -0,0 +1,4 @@
|
||||||
|
## 容器格式
|
||||||
|
最初,Docker采用了LXC中的容器格式。自1.20版本开始,Docker也开始支持新的`libcontainer`格式,并作为默认选项。
|
||||||
|
|
||||||
|
对更多容器格式的支持,还在进一步的发展中。
|
|
@ -1,4 +1,4 @@
|
||||||
##名字空间
|
## 名字空间
|
||||||
|
|
||||||
###pid 名字空间
|
###pid 名字空间
|
||||||
不同用户的进程就是通过pid名字空间隔离开的,且不同名字空间中可以有相同pid。所有的LXC进程在Docker中的父进程为Docker进程,每个LXC进程具有不同的名字空间。同时由于允许嵌套,因此可以很方便的实现嵌套的Docker容器。
|
不同用户的进程就是通过pid名字空间隔离开的,且不同名字空间中可以有相同pid。所有的LXC进程在Docker中的父进程为Docker进程,每个LXC进程具有不同的名字空间。同时由于允许嵌套,因此可以很方便的实现嵌套的Docker容器。
|
||||||
|
@ -16,4 +16,4 @@
|
||||||
UTS("UNIX Time-sharing System") 名字空间允许每个容器拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
|
UTS("UNIX Time-sharing System") 名字空间允许每个容器拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
|
||||||
|
|
||||||
###user 名字空间
|
###user 名字空间
|
||||||
每个容器可以有不同的用户和组id, 也就是说可以在容器内部用容器内部的用户执行程序而非Host上的用户。
|
每个容器可以有不同的用户和组id, 也就是说可以在容器内用容器内部的用户执行程序而非Host上的用户。
|
||||||
|
|
|
@ -0,0 +1,8 @@
|
||||||
|
## Union文件系统
|
||||||
|
Union文件系统([UionFS](http://en.wikipedia.org/wiki/UnionFS))是一种特殊的文件系统,它支持对文件系统的修改作为一次提交来一层层的叠加,同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。
|
||||||
|
|
||||||
|
这样,不同Docker容器就可以共享一些基础的文件系统层,同时再加上自己独有的改动层,大大提高了存储的效率。
|
||||||
|
|
||||||
|
Docker中使用的AUFS (AnotherUnionFS) 就是一种 Union FS。 AUFS支持为每一个成员目录(类似Git的分支)设定只读(readonly)、读写(readwrite)和写出(whiteout-able)权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。
|
||||||
|
|
||||||
|
Docker目前支持的Union文件系统种类包括AUFS, btrfs, vfs, 和DeviceMapper。
|
Loading…
Reference in New Issue