mirror of
https://github.com/yeasy/docker_practice.git
synced 2025-08-01 05:21:46 +00:00
Fix issue#20, format following the guidelines
This commit is contained in:
Baohua Yang
@@ -1,13 +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来模拟一整套完整的硬件环境提供给虚拟机的操作系统。虚拟机系统看到的环境是可限制的，也是彼此隔离的。
|
||||
我们知道，传统的虚拟机通过在宿主主机中运行 hypervisor 来模拟一整套完整的硬件环境提供给虚拟机的操作系统。虚拟机系统看到的环境是可限制的，也是彼此隔离的。
|
||||
这种直接的做法实现了对资源最完整的封装，但很多时候往往意味着系统资源的浪费。
|
||||
例如，以宿主机和虚拟机系统都为Linux系统为例，虚拟机中运行的应用其实可以利用宿主机系统中的运行环境。
|
||||
例如，以宿主机和虚拟机系统都为 Linux 系统为例，虚拟机中运行的应用其实可以利用宿主机系统中的运行环境。
|
||||
|
||||
我们知道，在操作系统中，包括内核、文件系统、网络、PID、UID、IPC、内存、硬盘、CPU等等，所有的资源都是应用进程直接共享的。
|
||||
我们知道，在操作系统中，包括内核、文件系统、网络、PID、UID、IPC、内存、硬盘、CPU 等等，所有的资源都是应用进程直接共享的。
|
||||
要想实现虚拟化，除了要实现对内存、CPU、网络IO、硬盘IO、存储空间等的限制外，还要实现文件系统、网络、PID、UID、IPC等等的相互隔离。
|
||||
前者相对容易实现一些，后者则需要宿主机系统的深入支持。
|
||||
|
||||
随着Linux系统对于名字空间功能的完善实现，程序员已经可以实现上面的所有需求，让某些进程在彼此隔离的名字空间中运行。大家虽然都共用一个内核和某些运行时环境（例如一些系统命令和系统库），但是彼此却看不到，都以为系统中只有自己的存在。这种机制就是容器（Container），例如名字空间来做权限的隔离控制，利用cgroups来做资源分配。
|
||||
随着 Linux 系统对于名字空间功能的完善实现，程序员已经可以实现上面的所有需求，让某些进程在彼此隔离的名字空间中运行。大家虽然都共用一个内核和某些运行时环境（例如一些系统命令和系统库），但是彼此却看不到，都以为系统中只有自己的存在。这种机制就是容器（Container），例如名字空间来做权限的隔离控制，利用 cgroups 来做资源分配。
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
## 基本架构
|
||||
Docker采用了C/S架构，包括客户端和服务端。
|
||||
docker daemon作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。
|
||||
客户端和服务端既可以运行在一个机器上，也可通过socket或者RESTful API来进行通信。
|
||||
Docker 采用了 C/S架构，包括客户端和服务端。
|
||||
Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。
|
||||
客户端和服务端既可以运行在一个机器上，也可通过 socket 或者 RESTful API 来进行通信。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Docker daemon一般在宿主主机后台运行，等待接收来自客户端的消息。
|
||||
Docker客户端则为用户提供一系列可执行命令，用户用这些命令实现跟docker daemon交互。
|
||||
Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。
|
||||
Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
## 控制组
|
||||
|
||||
控制组（[cgroups](http://en.wikipedia.org/wiki/Cgroups)）是Linux内核的一个特性，主要用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，才能避免当多个容器同时运行时的对系统资源的竞争。
|
||||
控制组（[cgroups](http://en.wikipedia.org/wiki/Cgroups)）是 Linux 内核的一个特性，主要用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，才能避免当多个容器同时运行时的对系统资源的竞争。
|
||||
|
||||
控制组技术最早是由Google的程序员2006年起提出，Linux内核自2.6.24开始支持。
|
||||
控制组技术最早是由 Google 的程序员 2006 年起提出，Linux 内核自 2.6.24 开始支持。
|
||||
|
||||
控制组可以提供对容器内内存、CPU、磁盘IO等资源的限制和计费管理。
|
||||
控制组可以提供对容器内内存、CPU、磁盘 IO 等资源的限制和计费管理。
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 容器格式
|
||||
最初，Docker采用了LXC中的容器格式。自1.20版本开始，Docker也开始支持新的`libcontainer`格式，并作为默认选项。
|
||||
最初，Docker 采用了 LXC 中的容器格式。自 1.20 版本开始，Docker 也开始支持新的 `libcontainer` 格式，并作为默认选项。
|
||||
|
||||
对更多容器格式的支持，还在进一步的发展中。
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
## 名字空间
|
||||
名字空间是Linux内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响。
|
||||
名字空间是 Linux 内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响。
|
||||
|
||||
### pid 名字空间
|
||||
不同用户的进程就是通过pid名字空间隔离开的，且不同名字空间中可以有相同pid。所有的LXC进程在Docker中的父进程为Docker进程，每个LXC进程具有不同的名字空间。同时由于允许嵌套，因此可以很方便的实现嵌套的Docker容器。
|
||||
不同用户的进程就是通过 pid 名字空间隔离开的，且不同名字空间中可以有相同 pid。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的名字空间。同时由于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。
|
||||
|
||||
### net 名字空间
|
||||
有了pid名字空间, 每个名字空间中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net名字空间实现的， 每个net名字空间有独立的 网络设备, IP地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker默认采用veth的方式，将容器中的虚拟网卡同host上的一个Docker网桥docker0连接在一起。
|
||||
有了 pid 名字空间, 每个名字空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 名字空间实现的， 每个 net 名字空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将容器中的虚拟网卡同 host 上的一 个Docker 网桥 docker0 连接在一起。
|
||||
|
||||
### ipc 名字空间
|
||||
容器中进程交互还是采用了Linux常见的进程间交互方法(interprocess communication - IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是host上具有相同pid 名字空间中的进程间交互，因此需要在IPC资源申请时加入名字空间信息，每个IPC资源有一个唯一的32位id。
|
||||
容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication - IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 名字空间中的进程间交互，因此需要在 IPC 资源申请时加入名字空间信息，每个 IPC 资源有一个唯一的 32 位 id。
|
||||
|
||||
### mnt 名字空间
|
||||
类似chroot，将一个进程放到一个特定的目录执行。mnt 名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间 中的进程所看到的文件目录就被隔离开了。同chroot不同，每个名字空间中的容器在/proc/mounts的信息只包含所在名字空间的mount point。
|
||||
类似 chroot，将一个进程放到一个特定的目录执行。mnt 名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间 中的进程所看到的文件目录就被隔离开了。同 chroot 不同，每个名字空间中的容器在 /proc/mounts 的信息只包含所在名字空间的 mount point。
|
||||
|
||||
### uts 名字空间
|
||||
UTS("UNIX Time-sharing System") 名字空间允许每个容器拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
|
||||
UTS("UNIX Time-sharing System") 名字空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非 主机上的一个进程。
|
||||
|
||||
### user 名字空间
|
||||
每个容器可以有不同的用户和组id, 也就是说可以在容器内用容器内部的用户执行程序而非Host上的用户。
|
||||
每个容器可以有不同的用户和组 id, 也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。
|
||||
|
||||
*注：关于Linux上的名字空间，[这篇文章](http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/)介绍的很好。
|
||||
*注：关于 Linux 上的名字空间，[这篇文章](http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/) 介绍的很好。
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
##Docker网络实现
|
||||
## Docker 网络实现
|
||||
|
||||
Docker的网络实现其实就是利用了Linux上的网络名字空间和虚拟网络设备（特别是veth pair）。建议先熟悉了解这两部分的基本概念再阅读本章。
|
||||
Docker 的网络实现其实就是利用了 Linux 上的网络名字空间和虚拟网络设备（特别是 veth pair）。建议先熟悉了解这两部分的基本概念再阅读本章。
|
||||
|
||||
### 基本原理
|
||||
首先，要实现网络通信，机器需要至少一个网络接口（物理接口或虚拟接口）来收发数据包；此外，如果不同子网之间要进行通信，需要路由机制。
|
||||
|
||||
Docker中的网络接口默认都是虚拟的接口。虚拟接口的优势之一是转发效率较高。
|
||||
Linux通过在内核中进行数据复制来实现虚拟接口之间的数据转发，发送接口的发送缓存中的数据包被直接复制到接收接口的接收缓存中。对于本地系统和容器内系统看来就像是一个正常的以太网卡，只是它不需要真正同外部网络设备通信，速度要很快。
|
||||
Docker 中的网络接口默认都是虚拟的接口。虚拟接口的优势之一是转发效率较高。
|
||||
Linux 通过在内核中进行数据复制来实现虚拟接口之间的数据转发，发送接口的发送缓存中的数据包被直接复制到接收接口的接收缓存中。对于本地系统和容器内系统看来就像是一个正常的以太网卡，只是它不需要真正同外部网络设备通信，速度要很快。
|
||||
|
||||
Docker容器网络就利用了这项技术。它在本地主机和容器内分别创建一个虚拟接口，并让它们彼此连通（这样的一对接口叫做“veth pair”）。
|
||||
Docker 容器网络就利用了这项技术。它在本地主机和容器内分别创建一个虚拟接口，并让它们彼此连通（这样的一对接口叫做 `veth pair`）。
|
||||
|
||||
### 创建网络参数
|
||||
Docker创建一个容器的时候，会执行如下操作：
|
||||
Docker 创建一个容器的时候，会执行如下操作：
|
||||
* 创建一对虚拟接口，分别放到本地主机和新容器中;
|
||||
* 本地主机一端桥接到默认的docker0或指定网桥上，并具有一个唯一的名字，如veth65f9;
|
||||
* 容器一端放到新容器中，并修改名字作为eth0。这个接口只在容器的名字空间可见；
|
||||
* 从网桥可用地址段中获取一个空闲地址分配给容器的eth0，并配置默认路由到桥接网卡veth65f9。
|
||||
* 本地主机一端桥接到默认的 docker0 或指定网桥上，并具有一个唯一的名字，如 veth65f9;
|
||||
* 容器一端放到新容器中，并修改名字作为 eth0。这个接口只在容器的名字空间可见；
|
||||
* 从网桥可用地址段中获取一个空闲地址分配给容器的 eth0，并配置默认路由到桥接网卡 veth65f9。
|
||||
|
||||
完成这些之后，容器就可以使用这eth0虚拟网卡来连接其他容器和其他网络。
|
||||
完成这些之后，容器就可以使用 eth0 虚拟网卡来连接其他容器和其他网络。
|
||||
|
||||
可以在`docker run`的时候通过`--net`参数来指定容器的网络配置，有4个可选值：
|
||||
可以在 `docker run` 的时候通过 `--net` 参数来指定容器的网络配置，有4个可选值：
|
||||
* `--net=bridge` 这个是默认值，连接到默认的网桥。
|
||||
* `--net=host` 告诉Docker不要将容器网络放到隔离的名字空间中，即不要容器化容器内的网络。此时容器使用本地主机的网络，它拥有完全的本地主机接口访问权限。容器进程可以跟主机其它root进程一样可以打开低范围的端口，可以访问本地网络服务比如D-bus，还可以让容器做一些影响整个主机系统的事情，比如重启主机。因此使用这个选项的时候要非常小心。如果进一步的使用`--privileged=true`，容器会被允许直接配置主机的网络堆栈。
|
||||
* `--net=container:NAME_or_ID` 让Docker将新建容器的进程放到一个已存在容器的网络栈中，新容器进程有自己的文件系统、进程列表和资源限制，但会和已存在的容器共享ip地址和端口等网络资源，两者进程可以直接通过`lo`环回接口通信。
|
||||
* `--net=none` 让Docker将新容器放到隔离的网络栈中，但是不进行网络配置。之后，用户可以自己进行配置。
|
||||
* `--net=host` 告诉 Docker 不要将容器网络放到隔离的名字空间中，即不要容器化容器内的网络。此时容器使用本地主机的网络，它拥有完全的本地主机接口访问权限。容器进程可以跟主机其它 root 进程一样可以打开低范围的端口，可以访问本地网络服务比如 D-bus，还可以让容器做一些影响整个主机系统的事情，比如重启主机。因此使用这个选项的时候要非常小心。如果进一步的使用 `--privileged=true`，容器会被允许直接配置主机的网络堆栈。
|
||||
* `--net=container:NAME_or_ID` 让 Docker 将新建容器的进程放到一个已存在容器的网络栈中，新容器进程有自己的文件系统、进程列表和资源限制，但会和已存在的容器共享 IP 地址和端口等网络资源，两者进程可以直接通过 `lo` 环回接口通信。
|
||||
* `--net=none` 让 Docker 将新容器放到隔离的网络栈中，但是不进行网络配置。之后，用户可以自己进行配置。
|
||||
|
||||
### 网络配置细节
|
||||
用户使用`--net=none`后，可以自行配置网络，让容器达到跟平常一样具有访问网络的权限。通过这个过程，可以了解Docker配置网络的细节。
|
||||
用户使用 `--net=none` 后，可以自行配置网络，让容器达到跟平常一样具有访问网络的权限。通过这个过程，可以了解 Docker 配置网络的细节。
|
||||
|
||||
首先，启动一个`/bin/bash`容器，指定`--net=none`参数。
|
||||
首先，启动一个 `/bin/bash` 容器，指定 `--net=none` 参数。
|
||||
```
|
||||
$ sudo docker run -i -t --rm --net=none base /bin/bash
|
||||
root@63f36fc01b5f:/#
|
||||
```
|
||||
在本地主机查找容器的进程id，并为它创建网络命名空间。
|
||||
在本地主机查找容器的进程 id，并为它创建网络命名空间。
|
||||
```
|
||||
$ sudo docker inspect -f '{{.State.Pid}}' 63f36fc01b5f
|
||||
2778
|
||||
@@ -41,20 +41,20 @@ $ pid=2778
|
||||
$ sudo mkdir -p /var/run/netns
|
||||
$ sudo ln -s /proc/$pid/ns/net /var/run/netns/$pid
|
||||
```
|
||||
检查桥接网卡的IP和子网掩码信息。
|
||||
检查桥接网卡的 IP 和子网掩码信息。
|
||||
```
|
||||
$ ip addr show docker0
|
||||
21: docker0: ...
|
||||
inet 172.17.42.1/16 scope global docker0
|
||||
...
|
||||
```
|
||||
创建一对“veth pair”接口A和B，绑定A到网桥`docker0`，并启用它
|
||||
创建一对 “veth pair” 接口 A 和 B，绑定 A 到网桥 `docker0`，并启用它
|
||||
```
|
||||
$ sudo ip link add A type veth peer name B
|
||||
$ sudo brctl addif docker0 A
|
||||
$ sudo ip link set A up
|
||||
```
|
||||
将B放到容器的网络命名空间，命名为eth0，启动它并配置一个可用IP（桥接网段）和默认网关。
|
||||
将B放到容器的网络命名空间，命名为 eth0，启动它并配置一个可用 IP（桥接网段）和默认网关。
|
||||
```
|
||||
$ sudo ip link set B netns $pid
|
||||
$ sudo ip netns exec $pid ip link set dev B name eth0
|
||||
@@ -62,8 +62,8 @@ $ sudo ip netns exec $pid ip link set eth0 up
|
||||
$ sudo ip netns exec $pid ip addr add 172.17.42.99/16 dev eth0
|
||||
$ sudo ip netns exec $pid ip route add default via 172.17.42.1
|
||||
```
|
||||
以上，就是Docker配置网络的具体过程。
|
||||
以上，就是 Docker 配置网络的具体过程。
|
||||
|
||||
当容器结束后，Docker会清空容器，容器内的eth0会随网络命名空间一起被摧毁，A 接口也被自动从`docker0`卸载。
|
||||
当容器结束后，Docker 会清空容器，容器内的 eth0 会随网络命名空间一起被摧毁，A 接口也被自动从 `docker0` 卸载。
|
||||
|
||||
此外，用户可以使用`ip netns exec`命令来在指定网络名字空间中进行配置，从而配置容器内的网络。
|
||||
此外，用户可以使用 `ip netns exec` 命令来在指定网络名字空间中进行配置，从而配置容器内的网络。
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
## Union文件系统
|
||||
## Union 文件系统
|
||||
Union文件系统（[UnionFS](http://en.wikipedia.org/wiki/UnionFS)）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。
|
||||
|
||||
Union文件系统是Docker镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
|
||||
Union 文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
|
||||
|
||||
另外，不同Docker容器就可以共享一些基础的文件系统层，同时再加上自己独有的改动层，大大提高了存储的效率。
|
||||
另外，不同 Docker 容器就可以共享一些基础的文件系统层，同时再加上自己独有的改动层，大大提高了存储的效率。
|
||||
|
||||
Docker中使用的AUFS（AnotherUnionFS）就是一种 Union FS。 AUFS支持为每一个成员目录（类似Git的分支）设定只读（readonly）、读写（readwrite）和写出（whiteout-able）权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。
|
||||
Docker 中使用的 AUFS（AnotherUnionFS）就是一种 Union FS。 AUFS 支持为每一个成员目录（类似 Git 的分支）设定只读（readonly）、读写（readwrite）和写出（whiteout-able）权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。
|
||||
|
||||
Docker目前支持的Union文件系统种类包括AUFS, btrfs, vfs, 和DeviceMapper。
|
||||
Docker 目前支持的 Union 文件系统种类包括 AUFS, btrfs, vfs 和 DeviceMapper。
|
||||
|
||||
Reference in New Issue
Block a user