一文扫盲Docker

た入场券 2024-03-23 17:03 33阅读 0赞

![format_png][]

输麻了，

隔壁组的大哥给实习生妹妹讲**Docker**，

把实习生妹妹忽悠得一愣一愣的，

实习生妹妹看隔壁组大哥那崇拜的小眼神，

我属实是特别嫉妒，

为了扳回一局，

我决定好好整理一下**Docker**的文档。

--------------------

### 前言 ###

本文将对**Docker**的镜像，**Dockerfile**的关键指令，**Docker**的容器进行关键概念总结，整体内容不会很深，但也绝不是停留在指令介绍的层面。

本文将重点分析如下内容。

1.  镜像的分层结构及大小；
2.  **CMD**指令和**ENTRYPOINT**指令的关系；
3.  如何让容器中的主进程的**PID**是1；
4.  容器的分层结构及大小。

参考：[Docker官方文档][Docker]

### 正文 ###

#### 一. Linux Namespace ####

1. 概念说明

**Namespace**是**Linux**的**资源隔离方案**，用于将某种全局资源通过**Namespace**进行隔离，使得**Namespace**下的**资源**仅由该**Namespace**下的进程共享。

**Linux**内核实现了如下六种**Namespace**。

<table> 
 <thead> 
  <tr> 
   <th>Namespace类型</th> 
   <th>隔离的资源</th> 
   <th>容器下的效果</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>Mount</strong></td> 
   <td>文件系统挂载点</td> 
   <td>不同容器中可以看到不同的目录结构</td> 
  </tr> 
  <tr> 
   <td><strong>Network</strong></td> 
   <td>例如网络设备，端口等网络相关资源</td> 
   <td>容器拥有独立的网络设备，<strong>IP</strong>地址，端口号等，这就使得同一宿主机上不同容器的进程可以绑定到相同端口上</td> 
  </tr> 
  <tr> 
   <td><strong>UTS</strong></td> 
   <td><strong>Hostname</strong>和<strong>Domainname</strong></td> 
   <td>容器可以拥有自己的主机名和域名</td> 
  </tr> 
  <tr> 
   <td><strong>IPC</strong></td> 
   <td>信号量，消息队列和共享内存等进程间通信资源</td> 
   <td>不同容器里的进程无法直接进行进程间通信</td> 
  </tr> 
  <tr> 
   <td><strong>PID</strong></td> 
   <td>进程编号</td> 
   <td>容器中的进程可以有独立的<strong>PID</strong>，以及容器中的进程会有两个<strong>PID</strong>：宿主机上一个<strong>PID</strong>和容器里一个<strong>PID</strong></td> 
  </tr> 
  <tr> 
   <td><strong>User</strong></td> 
   <td>用户和用户组</td> 
   <td>宿主机和容器中可以有两套用户和用户组</td> 
  </tr> 
 </tbody> 
</table>

2. Docker中的使用

当**Docker**创建一个容器时，**Docker**就会去创建上述六种**Namespace**实例，然后容器中的所有进程就会被放到创建出来的**Namespace**中，从而容器中的进程只能使用当前容器的**Namespace**下的资源，不同容器之间实现了资源隔离。

#### 二. Linux Control Groups ####

1. 概念说明

**Namespace**让容器中的进程拥有了独立的运行环境，现在还需要限制这些进程使用的**CPU**，**内存**，**磁盘**和**网络**等资源，而**cgroup**（**Control Groups**）就能实现这样的功能。

**cgroup**是**Linux**提供的用于将进程分组管理的功能，针对每个组里的进程，提供如下能力。

1.  限制组里进程使用的**CPU**核数和使用率；
2.  限制组里进程使用的**内存**大小；
3.  限制组里进程对物理设备的使用，例如**磁盘**；
4.  为组里进程分配**网络带宽**。

可以进入到宿主机的/**sys**/**fs**/**cgroup**目录，观察到有如下目录。

![format_png 1][]

每个目录都是**cgroup**可以控制的资源类型，说明如下。

1.  **blkio**。限制**cgroup**中的进程对块设备（例如磁盘）的**IO**速度；
2.  **cpu**。限制**cgroup**中的进程对**CPU**的使用率；
3.  **cpuacct**。统计**cgroup**中的进程对**CPU**的使用率；
4.  **cpuset**。为**cgroup**中的进程分配**CPU**核数；
5.  **devices**。限制**cgroup**中的进程使用物理设备的权限；
6.  **freezer**。挂起或恢复**cgroup**中的所有进程；
7.  **hugetlb**。限制**cgroup**中的进程对大页的使用数量（4**KB**称为小页，反之例如2**MB**或1**GB**称为大页）；
8.  **memory**。限制**cgroup**中的进程使用的内存大小，并生成使用报告；
9.  **net\_cls**。为**cgroup**中的进程的所有网络包添加**classid**标记符号，用于**iptables**（网络包过滤）和**TC**（**Traffic Control**，流量控制）；
10. **perf\_event**。监控**cgroup**中的进程的性能。

2. Docker中的使用

在**Docker**中，启动一个容器后，会在宿主机的/**sys**/**fs**/**cgroup**目录下的相关资源目录下创建以容器**id**为名字的目录，如下所示。

![format_png 2][]

容器中的进程的**PID**（容器进程在宿主机中的**PID**）会被记录到**tasks**文件中，如下所示。

![format_png 3][]

现在再查看一下**cpu.cfs\_quota\_us**，如下所示。

![format_png 4][]

\-1表示无限制，可以在使用**docker run**时通过-**c**来指定**CPU**限制相关参数，参数说明如下所示。

![format_png 5][]

#### 三. 镜像Image ####

镜像，是**Docker**中的容器的**静态表示**。镜像中包含着容器运行时的**代码**和**运行依赖**，是一个多层结构，且每一层都是**只读**的，所以镜像一旦创建，就无法被修改。

下面将从多个维度来说明**镜像**的概念。

1. 基础镜像

基础镜像，有如下两个特点。

1.  **不依赖其它镜像**；
2.  **其它镜像可基于基础镜像做扩展**。

那么可以联想到，通常基础镜像就是那些系统级镜像例如**CentOS**镜像，**Ubuntu**镜像等，这些镜像会作为地基，为容器中的程序运行提供操作系统（下面讨论的基础镜像均指系统级镜像）。

那么现在宿主机上有一个安装好的操作系统，宿主机上运行的一个容器中也有基础镜像提供的操作系统，这两个操作系统是否是一样的呢。说一样也行，说不一样也行，说明如下。

1.  **一样**。是因为容器中由镜像提供的操作系统底层使用的内核（**Kernel**）其实就是宿主机安装好的操作系统的内核。那么试问**Linux**的虚拟机上能运行使用**Windows**作为基础镜像的容器吗，那自然是不能的；
2.  **不一样**。是因为例如**Red Hat**系统的虚拟机上，可以运行使用**Ubuntu**作为基础镜像的容器，容器和宿主机上的**Linux**是不一样的**发行版**。

（**Linux**的不同发行版本都会采用相同的**Linux**内核，然后不同的发行版会在**Linux**内核的基础上加入各自的改动）

既然都能使用宿主机的操作系统内核了，那么为啥还需要基础镜像呢。这里其实就又会涉及到两个概念：**bootfs**和**rootfs**。

1.  **bootfs**，是**Linux**启动时需要加载的内容，由内核提供，属于**内核空间**。所以基础镜像中的操作系统需要依赖宿主机操作系统中的内核所提供的**bootfs**，才能将容器中的操作系统运行起来；
2.  **rootfs**，是基本的命令，类库或者工具（例如包管理工具**yum**，**apt-get**等），属于**用户空间**。由于容器中的文件系统通常是和宿主机上的文件系统隔离的，所以容器中运行的应用程序是无法访问到宿主机上的相关类库或者工具，基于这样的情况，基础镜像中就需要包含**rootfs**相关的内容。

到这里，基本就理清了基础镜像中的操作系统和宿主机上的操作系统的关系，简单点说就是：基础镜像中的操作系统是不完整的，缺少内核，需要使用宿主机上的操作系统的内核。（一个**Ubuntu**镜像才201**MB**，一个**Ubuntu 18.4**的安装包2**GB**，少了啥自己想）

2. 镜像组成

现在通过**docker save -o filename.tar imagename:version**将一个镜像打为**tar**并解压，解压后目录如下所示。

![format_png 6][]

每种文件说明如下。

1.  **repositories**。包含镜像名称，版本号，以及最上层的哈希值；
2.  **manifest.json**。镜像（假）元数据**Json**文件，包含镜像真正的元数据文件的文件名，以及镜像每一层的哈希值等；
3.  **各种文件夹**。镜像每一层对应的文件夹，是一个镜像真正占用空间大小的内容；
4.  **ac0f3e4255c186822ea64dcb267bea7c897d44ace98c61cd3faaffdb9479114f.json**。镜像真正的元数据文件。

基于**Dockerfile**构建出来的镜像，真正占用磁盘空间的层，要么是基础镜像层，要么是使用了**ADD，COPY**或者**RUN**指令而构建出来的层，而像**ENV**，**CMD**等指令，虽然也会构建镜像的层，但其实是一个空层，这些指令的真正作用是会修改构建出来的镜像的元数据。

3. RUN指令对镜像大小的影响

首先上一张图。

![format_png 7][]

在**Dockerfile**

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/f1c5a39876cf43f19de1fcb864feaed7.png
[Docker]: https://link.juejin.cn/?target=https%3A%2F%2Fdocs.docker.com%2F
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/bc52af63e34b49bdbd0562d1b4ce0875.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d164b74cc57d42958d0b82ff24d9a0cd.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/338958722f4c437ab78e3a4620085e63.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/f566c557ed9e46b496b3b8e8d71872d9.png
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/4db7d53878e34338b5c63737ac694968.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/321b289faa134813939d20df7d8f8b08.png
[format_png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/6d9f826bb0d34842a6bb21151e9ba955.png