939 lines
52 KiB
Markdown
939 lines
52 KiB
Markdown
# 01.Docker介绍与安装
|
||
|
||
## 01.Docker介绍与安装
|
||
|
||
### 1. Docker是什么？
|
||
|
||
Docker是一个在2013年开源的应用程序，并且是一个基于go语言编写的PAAS服务。
|
||
|
||
Docker最早采用LXC技术，之后改为自己研发并开源的runc技术运行容器。
|
||
|
||
Docker相比虚拟机的交付速度更快，资源消耗更低，Docker采用客户端、服务端架构，使用远程api来管理和创建Docker容器。
|
||
|
||
Docker的三大理念是build（构建）、ship（运输）、run（运行）。
|
||
|
||
Docker通过namespace、cgroup等技术来提供容器的资源隔离与安全保障。
|
||
|
||
### 2. Docker与虚拟机之间的对比
|
||
|
||
|
||
|
||
| **虚拟化** | **容器** |
|
||
| ------------------------------------------------ | ------------------------------------------------------- |
|
||
| 隔离性强，有独立的GUEST OS | 共享内核和OS，隔离性弱! |
|
||
| 虚拟化性能差(>15%) | 计算/存储无损耗，无Guest OS内存开销(~200M) |
|
||
| 虚拟机镜像庞大(十几G~几十G), 且实例化时不能共享 | Docker容器镜象200~300M，且公共基础镜象实例化时可以共享 |
|
||
| 虚拟机镜象缺乏统一标准 | Docker提供了容器应用镜象事实标准，OCI推动进一 步标准化 |
|
||
| 虚拟机创建慢(>2分钟) | 秒级创建(<10s)相当于建立索引 |
|
||
| 虚拟机启动慢(>30s) 读文件逐个加载 | 秒级(<1s,不含应用本身启动) |
|
||
| 资源虚拟化粒度低，单机10~100虚拟机 | 单机支持1000+容器密度很高，适合大规模的部署 |
|
||
|
||
- 资源利用率更高：一台物理机可以运行数百个容器，但一般只能运行数十个虚拟机
|
||
- 开销更小：不需要启动单独的虚拟机占用硬件资源
|
||
- 启动速度更快：可以在数秒内完成启动
|
||
|
||
### 3. Docker的组成
|
||
|
||
官网：https://docs.docker.com/get-started/overview/
|
||
|
||
Docker主机 host：一个物理机或者虚拟机，用于运行docker服务进程和容器
|
||
|
||
Docker服务端 Server：Docker守护进程，运行docker容器
|
||
|
||
Docker客户端 client：客户端使用docker命令或其他工具调用docker api
|
||
|
||
Docker仓库 registry：保存镜像的仓库，类似于git或svn这样的版本控制器
|
||
|
||
Docker镜像 images：镜像可以理解为创建实例使用的模板
|
||
|
||
Docker容器 container：容器是从镜像生成对外提供服务的一个或一组服务
|
||
|
||
|
||
|
||
|
||
|
||
### 4. Docker服务端软件选择
|
||
|
||
Docker CE（Community Edition，社区版）和 Docker EE（Enterprise Edition，企业版）是 Docker 产品的两个主要版本，它们之间的主要区别在于目标用户、功能集、支持和维护等方面：
|
||
|
||
1. **目标用户**：
|
||
- **Docker CE**：面向个人开发者、小团队以及技术爱好者，主要用于开发和测试环境。
|
||
- **Docker EE**：面向大型企业和组织，提供企业级的功能和支持。
|
||
2. **功能集**：
|
||
- **Docker CE**：提供基本的容器化功能，包括构建、运行和共享容器。
|
||
- **Docker EE**：除了包含 CE 版本的所有功能外，还提供了额外的企业级特性，如增强的安全、管理、可扩展性和集成性。
|
||
3. **支持和维护**：
|
||
- **Docker CE**：社区支持，适合自我解决问题的开发者。
|
||
- **Docker EE**：提供商业支持和专业服务，适合需要稳定运行环境的企业。
|
||
4. **安全性**：
|
||
- **Docker CE**：安全性相对较低，适合非生产环境。
|
||
- **Docker EE**：提供更高级的安全特性，如镜像扫描、安全策略和合规性报告。
|
||
5. **管理**：
|
||
- **Docker CE**：通常不需要复杂的管理工具。
|
||
- **Docker EE**：提供 Docker Universal Control Plane (UCP) 和 Docker Trusted Registry (DTR) 等管理工具，帮助企业更有效地管理容器环境。
|
||
6. **成本**：
|
||
- **Docker CE**：免费。
|
||
- **Docker EE**：需要购买许可证。
|
||
7. **更新和生命周期**：
|
||
- **Docker CE**：更新频繁，可能包含实验性功能，生命周期较短。
|
||
- **Docker EE**：更新周期更稳定，更注重稳定性和兼容性，生命周期较长。
|
||
|
||
### 5. Docker安装
|
||
|
||
- 安装docker-ce
|
||
|
||
```bash
|
||
[root@localhost ~]# yum install -y yum-utils
|
||
[root@localhost ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
|
||
[root@localhost ~]# sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo
|
||
[root@localhost ~]# yum install docker-ce -y
|
||
```
|
||
|
||
- 启动docker
|
||
|
||
```bash
|
||
[root@localhost ~]# systemctl enable --now docker
|
||
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service.
|
||
[root@localhost ~]# systemctl status docker
|
||
● docker.service - Docker Application Container Engine
|
||
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: disabled)
|
||
Active: active (running) since Sun 2025-03-23 23:36:27 CST; 10s ago
|
||
TriggeredBy: ● docker.socket
|
||
Docs: https://docs.docker.com
|
||
Main PID: 29081 (dockerd)
|
||
Tasks: 10
|
||
Memory: 25.7M
|
||
CPU: 141ms
|
||
CGroup: /system.slice/docker.service
|
||
└─29081 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
|
||
```
|
||
|
||
#### 5.1 镜像加速配置
|
||
|
||
由于Docker Image仓库在国外，目前，从23年底开始，国内陆续访问不到了，所以要通过一些镜像加速器才能获取到镜像
|
||
|
||
```bash
|
||
[root@localhost ~]# docker pull nginx
|
||
Error response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded
|
||
|
||
# 无法从docker官方镜像仓库，docker.io获取镜像
|
||
```
|
||
|
||
**使用国内镜像加速器**（不稳定，会经常变化）
|
||
|
||
```bash
|
||
[root@localhost ~]# mkdir -p /etc/docker
|
||
[root@localhost ~]# vim /etc/docker/daemon.json
|
||
{
|
||
"registry-mirrors": [
|
||
"https://docker.m.daocloud.io"
|
||
]
|
||
}
|
||
|
||
# 重启容器服务
|
||
[root@localhost ~]# systemctl daemon-reload
|
||
[root@localhost ~]# systemctl restart docker
|
||
|
||
# 可选加速地址（不一定有用，随时会跑路）：
|
||
1、https://docker.m.daocloud.io
|
||
2、https://docker.1panelproxy.com
|
||
3、https://atomhub.openatom.cn
|
||
4、https://docker.1panel.live
|
||
5、https://dockerhub.jobcher.com
|
||
6、https://hub.rat.dev
|
||
7、https://docker.registry.cyou
|
||
8、https://docker.awsl9527.cn
|
||
9、https://do.nark.eu.org/
|
||
10、https://docker.ckyl.me
|
||
11、https://hub.uuuadc.top
|
||
12、https://docker.chenby.cn
|
||
13、https://docker.ckyl.me
|
||
|
||
|
||
# 实在不行的话，可以在拉去的时候手动加上镜像加速器，因为有时候写到daemon.json中也有可能访问不到
|
||
[root@localhost ~]# docker pull nginx
|
||
[root@localhost ~]# docker pull docker.m.daocloud.io/nginx
|
||
[root@localhost ~]# docker images
|
||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||
nginx latest 53a18edff809 6 weeks ago 192MB
|
||
```
|
||
|
||
#### 5.2 快速开始
|
||
|
||
```bash
|
||
[root@localhost ~]# docker pull nginx
|
||
[root@localhost ~]# docker images
|
||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||
nginx latest d1a364dc548d 5 days ago 133MB
|
||
[root@localhost ~]# docker run -d -p 80:80 nginx
|
||
e617ca1db9a5d242e6b4145b9cd3dff9f7955c6ab1bf160f13fb6bec081a29e4
|
||
[root@localhost ~]# docker ps
|
||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||
e617ca1db9a5 nginx "/docker-entrypoint.…" 6 seconds ago Up 5 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp intelligent_turing
|
||
[root@localhost ~]# docker exec -it e617ca1db9a5 bash
|
||
root@e617ca1db9a5:/# cd /usr/share/nginx/html/
|
||
root@e617ca1db9a5:/usr/share/nginx/html# ls
|
||
50x.html index.html
|
||
root@e617ca1db9a5:/usr/share/nginx/html# echo 'docker nginx test' > index.html
|
||
[root@localhost ~]# curl 192.168.88.10
|
||
docker nginx test
|
||
|
||
[root@admin ~]# docker ps
|
||
CONTAINER ID IMAGE COMMAND CREATED NAMES
|
||
e0a818c40b7e nginx "/docker-entrypoint.…" About an hour ago 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp determined_sanderson
|
||
9b066ef4bcd2 nginx "/docker-entrypoint.…" About an hour ago 90->80/tcp, :::90->80/tcp vigorous_hypatia
|
||
[root@admin ~]# docker stop e0a818c40b7e
|
||
e0a818c40b7e
|
||
[root@localhost ~]# docker ps
|
||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||
```
|
||
|
||
- **`-i`（`--interactive`）**：
|
||
- **功能**：保持标准输入（stdin）打开，即使没有附加终端。
|
||
- **作用**：允许用户与容器内的命令进行交互。
|
||
- **`-t`（`--tty`）**：
|
||
- **功能**：分配一个伪终端（TTY）。
|
||
- **作用**：为用户创建一个类似本地终端的交互环境，支持颜色显示、光标操作等终端特性。
|
||
|
||
##### 5.2.1 Docker快速搭建RPG小游戏
|
||
|
||
```bash
|
||
[root@localhost ~]# docker pull registry.cn-guangzhou.aliyuncs.com/welldene/games:rpg_game
|
||
[root@localhost ~]# docker run -d -p 8000:8000 -p 8787:8787 --name rpg -e HOST_IP=192.168.88.10 registry.cn-guangzhou.aliyuncs.com/welldene/games:rpg_game
|
||
9c4bc95c98836a1df0453c282196083e4cb0b5d06e507d5d4567a4c018c13272
|
||
[root@localhost ~]# docker ps
|
||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||
35a6b44d5645 registry.cn-guangzhou.aliyuncs.com/welldene/games:rpg_game "bash run.sh" 3 seconds ago Up 2 seconds 0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp, 0.0.0.0:8787->8787/tcp, [::]:8787->8787/tcp rpg
|
||
```
|
||
|
||
**浏览器访问: http://IP:8787**
|
||
|
||
|
||
|
||
##### 5.2.2 Docker参数说明
|
||
|
||
```bash
|
||
-d, --detach: 以守护进程方式运行容器
|
||
-p, --publish: 映射容器端口到宿主机端口
|
||
格式: `-p [hostPort]:[containerPort]`
|
||
|
||
-P（大写）：随机端口映射
|
||
|
||
-v, --volume: 挂载数据卷
|
||
格式: `-v [hostPath]:[containerPath]`
|
||
|
||
-e, --env: 设置环境变量
|
||
--name: 为容器指定名称
|
||
--network: 指定容器所属网络
|
||
--restart: 容器退出时的重启策略
|
||
可选值: `no`, `on-failure`, `unless-stopped`, `always`
|
||
|
||
-i, --interactive: 保持标准输入打开
|
||
-t, --tty: 分配一个伪终端
|
||
-u, --user: 指定运行容器的用户
|
||
--entrypoint: 覆盖容器的默认入口点
|
||
--rm: 容器退出后自动删除
|
||
--hostname: 设置容器主机名
|
||
--add-host: 添加自定义主机名到 IP 的映射
|
||
--link: 添加到另一个容器的链接
|
||
--expose: 暴露容器端口
|
||
--volume-driver: 指定数据卷驱动程序
|
||
--cpu-shares: 设置 CPU 权重
|
||
--memory: 设置容器内存限制
|
||
```
|
||
|
||
### 6. Docker核心技术
|
||
|
||
#### 6.1 Linux namespace技术
|
||
|
||
如果一个宿主机运行了N个容器，多个容器带来的以下问题怎么解决：
|
||
|
||
1. 怎么样保证每个容器都有不同的文件系统并且能互不影响？
|
||
2. 一个docker主进程内的各个容器都是其子进程，那么如何实现同一个主进程下不同类型的子进程？各个子进程间通信能相互访问吗？
|
||
3. 每个容器怎么解决IP以及端口分配的问题？
|
||
4. 多个容器的主机名能一样吗？
|
||
5. 每个容器都要不要有root用户？怎么解决账户重名问题呢？
|
||
|
||
以上问题怎么解决
|
||
|
||
Docker 的 Namespace 技术是实现容器隔离的核心机制之一。它通过 Linux Namespace 提供的隔离功能，为每个容器创建独立的资源视图，从而实现容器之间的隔离
|
||
|
||
**namespace**是Linux系统的底层概念，在内核层实现，即有一些不同类型的命名空间都部署在核内，**各个docker容器运行在同一个docker主进程并且共用同一个宿主机系统内核**，各个docker容器运行在宿主机的用户空间，每个容器都要有类似于虚拟机一样的相**互隔离的运行空间**，但是容器技术是在一个进程内实现运行指定服务的运行环境，并且还可以保护宿主机内核不受其他进程的干扰和影响，如文件系统、网络空间、进程空间等，目前主要通过以下技术实现容器运行空间的相互隔离：
|
||
|
||
| 隔离类型 | 功能 | 系统调用参数 | 内核 |
|
||
| -------------------------------------------- | ---------------------------------- | ------------- | ------ |
|
||
| MNT Namespace（mount） | 提供磁盘挂载点和文件系统的隔离能力 | CLONE_NEWNS | 2.4.19 |
|
||
| IPC Namespace（Inter-Process Communication） | 提供进程间通信的隔离能力 | CLONE_NEWIPC | 2.6.19 |
|
||
| UTS Namespace（UNIX Timesharing System） | 提供主机名隔离能力 | CLONE_NEWUTS | 2.6.19 |
|
||
| PID Namespace（Process Identification） | 提供进程隔离能力 | CLONE_NEWPID | 2.6.24 |
|
||
| Net Namespace（network） | 提供网络隔离能力 | CLONE_NEWNET | 2.6.29 |
|
||
| User Namespace（user） | 提供用户隔离能力 | CLONE_NEWUSER | 3.8 |
|
||
|
||
##### 6.1.1 MNT Namespace
|
||
|
||
每个容器都要有独立的根文件系统有独立的用户空间，以实现容器里面启动服务并且使用容器的运行环境。
|
||
|
||
- 启动三个容器
|
||
|
||
```bash
|
||
[root@localhost ~]# docker run -d --name nginx-1 -p 80:80 nginx
|
||
0e72f06bba417073d1d4b2cb53e62c45b75edc699b737e46a157a3249f3a803e
|
||
[root@localhost ~]# docker run -d --name nginx-2 -p 81:80 nginx
|
||
c8ce6a0630b66e260eef16d8ecf48049eed7b893b87459888b634bf0e9e40f23
|
||
[root@localhost ~]# docker run -d --name nginx-3 -p 82:80 nginx
|
||
1cddbd412b5997f8935815c2f588431e100b752595ceaa92b95758ca45179096
|
||
[root@localhost ~]# docker ps
|
||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||
b42378a51c40 nginx "/docker-entrypoint.…" 2 seconds ago Up 1 second 0.0.0.0:82->80/tcp, [::]:82->80/tcp nginx-3
|
||
d30f033c2f29 nginx "/docker-entrypoint.…" 5 seconds ago Up 5 seconds 0.0.0.0:81->80/tcp, [::]:81->80/tcp nginx-2
|
||
d34a012dcebc nginx "/docker-entrypoint.…" 10 seconds ago Up 10 seconds 0.0.0.0:80->80/tcp, [::]:80->80/tcp nginx-1
|
||
```
|
||
|
||
- 连接进入某一个容器中，并创建一个文件
|
||
|
||
```bash
|
||
[root@localhost ~]# docker exec -it nginx-1 bash
|
||
root@d34a012dcebc:/# echo 'hello world test!' > /opt/test_nginx-1
|
||
root@d34a012dcebc:/# exit
|
||
```
|
||
|
||
- 宿主机是使用了chroot技术把容器锁定到一个指定的运行目录里
|
||
|
||
```bash
|
||
[root@localhost ~]# find / -name test_nginx-1
|
||
/var/lib/docker/overlay2/075b51fb5d33011d4b449fde8c14199c1e30f86224862f68a6116b1cb1dacfdf/diff/opt/test_nginx-1
|
||
/var/lib/docker/overlay2/075b51fb5d33011d4b449fde8c14199c1e30f86224862f68a6116b1cb1dacfdf/merged/opt/test_nginx-1
|
||
```
|
||
|
||
在 Docker 中，文件系统是通过分层存储机制实现的，这与 Docker 的镜像和容器的架构有关。看到的两个文件路径反映了 Docker 的存储驱动（如 Overlay2）的工作原理。
|
||
|
||
###### 6.1.1.1 Docker 的存储架构
|
||
|
||
1. **镜像层（Read-Only）**：
|
||
- Docker 镜像是由多个只读层组成的。每一层代表了镜像的某个状态或修改。
|
||
- 这些层是不可变的，一旦创建，不会被修改。
|
||
2. **容器层（Read-Write）**：
|
||
- 当你运行一个容器时，Docker 会在镜像层之上添加一个可写层。
|
||
- 容器的所有写操作（如创建文件、修改文件等）都会在这个可写层中进行，而不会影响下面的镜像层。
|
||
|
||
###### 6.1.1.2 Overlay2 存储驱动
|
||
|
||
Docker 默认使用 Overlay2 存储驱动（在支持的系统上）。Overlay2 的工作机制如下：
|
||
|
||
- **`merged` 目录**：
|
||
- 这是容器的根文件系统，是镜像层和容器层的联合视图。
|
||
- 当你在容器中访问文件时，看到的是 `merged` 目录中的内容。
|
||
- 例如，你在容器中创建的文件 `/opt/test_nginx-1`，在宿主机上可以通过 `/var/lib/docker/overlay2/<id>/merged/opt/test_nginx-1` 访问。
|
||
- **`diff` 目录**：
|
||
- 这是容器的可写层，记录了容器对文件系统的修改。
|
||
- 当你在容器中创建或修改文件时，实际的文件数据会存储在 `diff` 目录中。
|
||
- 例如，你在容器中创建的文件 `/opt/test_nginx-1`，其实际数据存储在 `/var/lib/docker/overlay2/<id>/diff/opt/test_nginx-1`。
|
||
|
||
- 当你在容器中创建文件 `/opt/test_nginx-1` 时：
|
||
- 文件的实际数据被写入到 `diff` 目录中。
|
||
- 在 `merged` 目录中，通过联合文件系统（OverlayFS）的机制，将 `diff` 目录中的文件映射到 `merged` 目录中，让你在容器中看到完整的文件系统视图。
|
||
|
||
##### 6.1.2 IPC Namespace
|
||
|
||
一个容器内的进程间通信，允许一个容器内的不同进程数据互相访问，但是不能跨容器访问其他容器的数据
|
||
|
||
UTS Namespace包含了运行内核的名称、版本、底层体系结构类型等信息用于系统表示，其中包含了hostname和域名，它使得一个容器拥有属于自己hostname标识，这个主机名标识独立于宿主机系统和其上的其他容器。
|
||
|
||
##### 6.1.3 PID Namespace
|
||
|
||
Linux系统中，有一个pid为1的进程（init/systemd）是其他所有进程的父进程，那么在每个容器内也要有一个父进程来管理其下属的进程，那么多个容器的进程通PID namespace进程隔离
|
||
|
||
- 安装软件包
|
||
|
||
```bash
|
||
[root@localhost ~]# docker exec -it 065f06e5caa4 bash
|
||
root@0e72f06bba41:/# apt update
|
||
# ifconfig
|
||
root@0e72f06bba41:/# apt install -y net-tools
|
||
root@0e72f06bba41:/# apt install -y procps
|
||
root@0e72f06bba41:/# ps -ef
|
||
UID PID PPID C STIME TTY TIME CMD
|
||
root 10 0 03:20 ? 00:00:00 nginx: master process nginx -g d
|
||
nginx 32 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 33 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 34 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 35 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 36 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 37 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 38 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
nginx 39 1 0 03:20 ? 00:00:00 nginx: worker process
|
||
root 59 0 0 03:35 pts/0 00:00:00 bash
|
||
root 503 59 0 03:42 pts/0 00:00:00 ps -ef
|
||
```
|
||
|
||
**那么宿主机的PID与容器内的PID是什么关系？**
|
||
|
||
```bash
|
||
[root@localhost ~]# yum install psmisc
|
||
[root@localhost ~]# pstree -p
|
||
[root@localhost ~]# pstree -p
|
||
systemd(1)─┬─NetworkManager(769)─┬─{NetworkManager}(772)
|
||
│ └─{NetworkManager}(775)
|
||
├─agetty(817)
|
||
├─atd(799)
|
||
├─auditd(693)─┬─sedispatch(695)
|
||
│ ├─{auditd}(694)
|
||
│ └─{auditd}(696)
|
||
├─bluetoothd(742)
|
||
├─chronyd(753)
|
||
├─containerd(28884)─┬─{containerd}(28886)
|
||
│ ├─{containerd}(28887)
|
||
│ ├─{containerd}(28888)
|
||
│ ├─{containerd}(28889)
|
||
│ ├─{containerd}(28890)
|
||
│ ├─{containerd}(28891)
|
||
│ ├─{containerd}(28892)
|
||
│ └─{containerd}(28894)
|
||
├─containerd-shim(30330)─┬─bash(30801)
|
||
│ ├─nginx(30353)─┬─nginx(30426)
|
||
│ │ ├─nginx(30427)
|
||
│ │ ├─nginx(30428)
|
||
│ │ └─nginx(30429)
|
||
│ ├─{containerd-shim}(30332)
|
||
│ ├─{containerd-shim}(30333)
|
||
│ ├─{containerd-shim}(30334)
|
||
│ ├─{containerd-shim}(30335)
|
||
│ ├─{containerd-shim}(30336)
|
||
│ ├─{containerd-shim}(30337)
|
||
│ ├─{containerd-shim}(30338)
|
||
│ ├─{containerd-shim}(30339)
|
||
│ ├─{containerd-shim}(30340)
|
||
│ ├─{containerd-shim}(30703)
|
||
│ └─{containerd-shim}(30909)
|
||
├─containerd-shim(30447)─┬─nginx(30469)─┬─nginx(30546)
|
||
│ │ ├─nginx(30547)
|
||
│ │ ├─nginx(30548)
|
||
│ │ └─nginx(30549)
|
||
│ ├─{containerd-shim}(30448)
|
||
│ ├─{containerd-shim}(30449)
|
||
│ ├─{containerd-shim}(30450)
|
||
│ ├─{containerd-shim}(30451)
|
||
│ ├─{containerd-shim}(30452)
|
||
│ ├─{containerd-shim}(30453)
|
||
│ ├─{containerd-shim}(30454)
|
||
│ ├─{containerd-shim}(30455)
|
||
│ ├─{containerd-shim}(30456)
|
||
│ └─{containerd-shim}(30705)
|
||
├─containerd-shim(30566)─┬─nginx(30587)─┬─nginx(30662)
|
||
│ │ ├─nginx(30663)
|
||
│ │ ├─nginx(30664)
|
||
│ │ └─nginx(30665)
|
||
│ ├─{containerd-shim}(30567)
|
||
│ ├─{containerd-shim}(30568)
|
||
│ ├─{containerd-shim}(30569)
|
||
│ ├─{containerd-shim}(30570)
|
||
│ ├─{containerd-shim}(30571)
|
||
│ ├─{containerd-shim}(30572)
|
||
│ ├─{containerd-shim}(30573)
|
||
│ ├─{containerd-shim}(30574)
|
||
│ ├─{containerd-shim}(30593)
|
||
│ ├─{containerd-shim}(30706)
|
||
│ └─{containerd-shim}(30780)
|
||
├─crond(801)
|
||
├─dbus-broker-lau(719)───dbus-broker(723)
|
||
├─dockerd(29156)─┬─docker-proxy(30381)─┬─{docker-proxy}(30382)
|
||
│ │ ├─{docker-proxy}(30383)
|
||
│ │ ├─{docker-proxy}(30384)
|
||
│ │ ├─{docker-proxy}(30385)
|
||
│ │ ├─{docker-proxy}(30386)
|
||
│ │ └─{docker-proxy}(30388)
|
||
│ ├─docker-proxy(30387)─┬─{docker-proxy}(30389)
|
||
│ │ ├─{docker-proxy}(30390)
|
||
│ │ ├─{docker-proxy}(30391)
|
||
│ │ ├─{docker-proxy}(30392)
|
||
│ │ ├─{docker-proxy}(30393)
|
||
│ │ ├─{docker-proxy}(30394)
|
||
│ │ ├─{docker-proxy}(30395)
|
||
│ │ └─{docker-proxy}(30396)
|
||
│ ├─docker-proxy(30497)─┬─{docker-proxy}(30498)
|
||
│ │ ├─{docker-proxy}(30499)
|
||
│ │ ├─{docker-proxy}(30500)
|
||
│ │ ├─{docker-proxy}(30501)
|
||
│ │ ├─{docker-proxy}(30502)
|
||
│ │ ├─{docker-proxy}(30503)
|
||
│ │ ├─{docker-proxy}(30504)
|
||
│ │ └─{docker-proxy}(30505)
|
||
│ ├─docker-proxy(30506)─┬─{docker-proxy}(30507)
|
||
│ │ ├─{docker-proxy}(30508)
|
||
│ │ ├─{docker-proxy}(30509)
|
||
│ │ ├─{docker-proxy}(30510)
|
||
│ │ ├─{docker-proxy}(30511)
|
||
│ │ ├─{docker-proxy}(30512)
|
||
│ │ └─{docker-proxy}(30513)
|
||
│ ├─docker-proxy(30616)─┬─{docker-proxy}(30617)
|
||
│ │ ├─{docker-proxy}(30618)
|
||
│ │ ├─{docker-proxy}(30619)
|
||
│ │ ├─{docker-proxy}(30620)
|
||
│ │ ├─{docker-proxy}(30621)
|
||
│ │ ├─{docker-proxy}(30622)
|
||
│ │ ├─{docker-proxy}(30624)
|
||
│ │ └─{docker-proxy}(30625)
|
||
│ ├─docker-proxy(30623)─┬─{docker-proxy}(30626)
|
||
│ │ ├─{docker-proxy}(30627)
|
||
│ │ ├─{docker-proxy}(30628)
|
||
│ │ ├─{docker-proxy}(30629)
|
||
│ │ ├─{docker-proxy}(30630)
|
||
│ │ ├─{docker-proxy}(30631)
|
||
│ │ └─{docker-proxy}(30632)
|
||
│ ├─{dockerd}(29157)
|
||
│ ├─{dockerd}(29159)
|
||
│ ├─{dockerd}(29161)
|
||
│ ├─{dockerd}(29163)
|
||
│ ├─{dockerd}(29407)
|
||
│ ├─{dockerd}(29420)
|
||
│ ├─{dockerd}(29430)
|
||
│ ├─{dockerd}(29537)
|
||
│ ├─{dockerd}(29711)
|
||
│ ├─{dockerd}(29712)
|
||
│ ├─{dockerd}(29823)
|
||
│ ├─{dockerd}(29844)
|
||
│ ├─{dockerd}(29845)
|
||
│ ├─{dockerd}(30633)
|
||
│ └─{dockerd}(30683)
|
||
├─irqbalance(729)───{irqbalance}(738)
|
||
├─lsmd(730)
|
||
├─mcelog(734)
|
||
├─polkitd(944)─┬─{polkitd}(975)
|
||
│ ├─{polkitd}(976)
|
||
│ ├─{polkitd}(979)
|
||
│ ├─{polkitd}(980)
|
||
│ ├─{polkitd}(981)
|
||
│ ├─{polkitd}(982)
|
||
│ └─{polkitd}(1004)
|
||
├─rsyslogd(1063)─┬─{rsyslogd}(1095)
|
||
│ └─{rsyslogd}(1096)
|
||
├─sshd(786)─┬─sshd(1527)───sshd(1541)───bash(1542)───docker(30781)─┬─{docker}(30782)
|
||
│ │ ├─{docker}(30783)
|
||
│ │ ├─{docker}(30784)
|
||
│ │ ├─{docker}(30785)
|
||
│ │ ├─{docker}(30786)
|
||
│ │ ├─{docker}(30787)
|
||
│ │ ├─{docker}(30788)
|
||
│ │ └─{docker}(30807)
|
||
│ └─sshd(30928)───sshd(30932)───bash(30933)───pstree(31158)
|
||
├─systemd(1532)───(sd-pam)(1534)
|
||
├─systemd-journal(635)
|
||
├─systemd-logind(739)
|
||
├─systemd-udevd(648)
|
||
└─tuned(791)─┬─{tuned}(1106)
|
||
├─{tuned}(1137)
|
||
└─{tuned}(1138)
|
||
|
||
[root@localhost ~]# ps aux | grep b42378a51c40
|
||
root 30566 0.0 0.9 1237984 16524 ? Sl 18:42 0:00 /usr/bin/containerd-shim-runc-v2 -namespace moby -id b42378a51c402d7ffa408d331a61ebdefe1b920eb723cd343ebc8e5781bec03d -address /run/containerd/containerd.sock
|
||
root 31171 0.0 0.1 3880 2048 pts/1 S+ 18:54 0:00 grep --color=auto b42378a51c40
|
||
```
|
||
|
||
**在宿主机上查看容器的进程**
|
||
|
||
```bash
|
||
[root@localhost ~]# docker top nginx-1
|
||
UID PID PPID C STIME TTY TIME CMD
|
||
root 30353 30330 0 18:42 ? 00:00:00 nginx: master process nginx -g daemon off;
|
||
101 30426 30353 0 18:42 ? 00:00:00 nginx: worker process
|
||
101 30427 30353 0 18:42 ? 00:00:00 nginx: worker process
|
||
101 30428 30353 0 18:42 ? 00:00:00 nginx: worker process
|
||
101 30429 30353 0 18:42 ? 00:00:00 nginx: worker process
|
||
root 30801 30330 0 18:46 pts/0 00:00:00 bash
|
||
```
|
||
|
||
首先，可以看到容器内的进程在宿主机上的 PID。容器内的进程只能看到自己命名空间中的进程，而无法看到宿主机或其他容器的进程
|
||
|
||
所以说明docker采用PID Namespace技术将容器内部的进程与宿主机的进程进行了隔离
|
||
|
||
并且，容器内部的进程和宿主机上的进程还存在一定的对应或者映射关系
|
||
|
||
1. **独立的 PID 命名空间**:
|
||
- 每个 Docker 容器都有自己独立的 PID 命名空间。
|
||
- 容器内的进程 PID 从 1 开始编号,与宿主机上的 PID 是相互独立的。
|
||
2. **PID 映射**:
|
||
- 容器内的进程 PID 与宿主机上的进程 PID 之间是有映射关系的。
|
||
3. **PID 可见性**:
|
||
- 容器内的进程只能看到容器内部的 PID。
|
||
- 宿主机上的进程可以看到容器内部的 PID,但容器内的进程无法看到宿主机上的 PID。
|
||
4. **PID 隔离**:
|
||
- 容器内的进程无法访问或影响宿主机上的其他进程。
|
||
- 宿主机上的进程可以访问和管理容器内的进程。
|
||
|
||
##### 6.1.4 Net Namespace
|
||
|
||
每一个容器都类似于虚拟机一样有自己的网卡、监听端口、TCP/IP协议栈等，Docker使用network namespace启动一个vethX接口，这样容器将拥有它自己的桥接IP地址，通常是docker0，而docker0实质就是linux的虚拟网桥。
|
||
|
||
查看容器内部的IP网络信息，发现有一个eth0的网卡
|
||
|
||
```bash
|
||
root@d34a012dcebc:/# ifconfig
|
||
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet 172.17.0.2 netmask 255.255.0.0 broadcast 172.17.255.255
|
||
ether ce:f2:f5:63:47:16 txqueuelen 0 (Ethernet)
|
||
RX packets 4713 bytes 10994487 (10.4 MiB)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 3888 bytes 212050 (207.0 KiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
|
||
inet 127.0.0.1 netmask 255.0.0.0
|
||
inet6 ::1 prefixlen 128 scopeid 0x10<host>
|
||
loop txqueuelen 1000 (Local Loopback)
|
||
RX packets 0 bytes 0 (0.0 B)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 0 bytes 0 (0.0 B)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
```
|
||
|
||
而我们的宿主机上的网卡中，多了个docker0的虚拟网桥，这样以来，通过Net Namespace将容器的网络与宿主机的网络进行隔离，并且通过虚拟网桥docker0与容器进行网络通信
|
||
|
||
```bash
|
||
[root@localhost ~]# ifconfig
|
||
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
|
||
inet6 fe80::38a5:cdff:fe6b:7dbc prefixlen 64 scopeid 0x20<link>
|
||
ether 3a:a5:cd:6b:7d:bc txqueuelen 0 (Ethernet)
|
||
RX packets 5820 bytes 11520579 (10.9 MiB)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 9483 bytes 11508761 (10.9 MiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet 192.168.88.10 netmask 255.255.255.0 broadcast 192.168.88.255
|
||
inet6 fe80::20c:29ff:fe26:8384 prefixlen 64 scopeid 0x20<link>
|
||
ether 00:0c:29:26:83:84 txqueuelen 1000 (Ethernet)
|
||
RX packets 235433 bytes 340010957 (324.2 MiB)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 54812 bytes 14709198 (14.0 MiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
|
||
inet 127.0.0.1 netmask 255.0.0.0
|
||
inet6 ::1 prefixlen 128 scopeid 0x10<host>
|
||
loop txqueuelen 1000 (Local Loopback)
|
||
RX packets 0 bytes 0 (0.0 B)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 0 bytes 0 (0.0 B)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
veth51c3173: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet6 fe80::d8fa:18ff:fe0f:d176 prefixlen 64 scopeid 0x20<link>
|
||
ether da:fa:18:0f:d1:76 txqueuelen 0 (Ethernet)
|
||
RX packets 3888 bytes 212050 (207.0 KiB)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 4714 bytes 10994557 (10.4 MiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
veth813b530: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet6 fe80::e498:2eff:fe08:2c5b prefixlen 64 scopeid 0x20<link>
|
||
ether e6:98:2e:08:2c:5b txqueuelen 0 (Ethernet)
|
||
RX packets 3 bytes 126 (126.0 B)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 15 bytes 1118 (1.0 KiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
|
||
vethc11c399: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
|
||
inet6 fe80::a482:dfff:fe74:dec7 prefixlen 64 scopeid 0x20<link>
|
||
ether a6:82:df:74:de:c7 txqueuelen 0 (Ethernet)
|
||
RX packets 3 bytes 126 (126.0 B)
|
||
RX errors 0 dropped 0 overruns 0 frame 0
|
||
TX packets 18 bytes 1244 (1.2 KiB)
|
||
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
||
```
|
||
|
||
- **`docker0` 网桥**：
|
||
- 它是 Docker 默认创建的一个虚拟网桥，用于管理容器的网络通信。
|
||
- 它为连接到它的容器提供了一个内部网络环境，允许容器之间通过这个网桥进行通信。
|
||
- **`veth3ad3c5b` 接口**：
|
||
- 这是一个虚拟以太网接口，用于连接容器和宿主机的网络。
|
||
- 它的一端连接到 `docker0` 网桥，另一端连接到容器的网络命名空间。
|
||
- 当容器启动时，Docker 会自动创建这样的 veth pair，并将一端连接到 `docker0`，另一端连接到容器的网络命名空间。
|
||
|
||
逻辑图
|
||
|
||
|
||
|
||
##### 6.1.5 User Namespace
|
||
|
||
各个容器内可能会出现重名的用户和用户组名称，或重复的用户UID或者GID，那么怎么隔离各个容器内的用户空间呢？
|
||
|
||
User Namespace允许在宿主机的各个容器空间内创建相同的用户名以及相同的uid和gid，只是此用户的有效范围仅仅是当前的容器内，不能访问另外一个容器内的文件系统，即相互隔离、互不影响、永不相见
|
||
|
||
#### 6.2 Linux control groups
|
||
|
||
在一个容器内部，如果不对其做任何资源限制，则宿主机会允许其占用无限大的内存空间，有时候会因为代码bug程序会一直申请内存，直到把宿主机内存占完，为了避免此类的问题出现，宿主机有必要对容器进行资源分配限制，比如cpu、内存等，Linux Cgroups的全称是Linux control Groups，它最重要的作用就是限制一个进程组能够使用的资源上线，包括cpu、内存、磁盘、网络等等。
|
||
|
||
- 验证系统内核层已经默认开启cgroup功能
|
||
|
||
```bash
|
||
[root@localhost ~]# cat /boot/config-5.14.0-427.13.1.el9_4.x86_64 | grep cgroup -i
|
||
CONFIG_CGROUPS=y
|
||
# CONFIG_CGROUP_FAVOR_DYNMODS is not set
|
||
CONFIG_BLK_CGROUP=y
|
||
CONFIG_CGROUP_WRITEBACK=y
|
||
CONFIG_CGROUP_SCHED=y
|
||
CONFIG_CGROUP_PIDS=y
|
||
CONFIG_CGROUP_RDMA=y
|
||
CONFIG_CGROUP_FREEZER=y
|
||
CONFIG_CGROUP_HUGETLB=y
|
||
CONFIG_CGROUP_DEVICE=y
|
||
CONFIG_CGROUP_CPUACCT=y
|
||
CONFIG_CGROUP_PERF=y
|
||
CONFIG_CGROUP_BPF=y
|
||
CONFIG_CGROUP_MISC=y
|
||
# CONFIG_CGROUP_DEBUG is not set
|
||
CONFIG_SOCK_CGROUP_DATA=y
|
||
CONFIG_BLK_CGROUP_RWSTAT=y
|
||
CONFIG_BLK_CGROUP_IOLATENCY=y
|
||
CONFIG_BLK_CGROUP_FC_APPID=y
|
||
# CONFIG_BLK_CGROUP_IOCOST is not set
|
||
# CONFIG_BLK_CGROUP_IOPRIO is not set
|
||
# CONFIG_BFQ_CGROUP_DEBUG is not set
|
||
CONFIG_NETFILTER_XT_MATCH_CGROUP=m
|
||
CONFIG_NET_CLS_CGROUP=y
|
||
CONFIG_CGROUP_NET_PRIO=y
|
||
CONFIG_CGROUP_NET_CLASSID=y
|
||
# CONFIG_DEBUG_CGROUP_REF is not set
|
||
```
|
||
|
||
- 关于内存的模块
|
||
|
||
```bash
|
||
[root@localhost ~]# cat /boot/config-3.10.0-957.el7.x86_64 | grep mem -i | grep cg -i
|
||
CONFIG_MEMCG=y
|
||
CONFIG_MEMCG_SWAP=y
|
||
CONFIG_MEMCG_SWAP_ENABLED=y
|
||
CONFIG_MEMCG_KMEM=y
|
||
```
|
||
|
||
扩展阅读：
|
||
|
||
https://blog.csdn.net/qyf158236/article/details/110475457
|
||
|
||
##### 6.2.1 Docker 中的 cgroups 资源限制
|
||
|
||
###### 6.2.1.1 **CPU 资源限制**
|
||
|
||
Docker 提供了多种方式来限制容器的 CPU 使用：
|
||
|
||
- **`--cpus`**：限制容器可以使用的 CPU 核心数量。例如，`--cpus="1.5"` 表示容器最多可以使用 1.5 个 CPU。
|
||
- **`--cpu-shares`**：设置容器的 CPU 使用权重。默认值为 1024，值越高，分配的 CPU 时间片越多。
|
||
- **`--cpu-period` 和 `--cpu-quota`**：更细粒度地控制 CPU 时间片。`--cpu-period` 设置 CPU 时间片的周期（单位为微秒），`--cpu-quota` 设置每个周期内容器可以使用的 CPU 时间。
|
||
|
||
###### 6.2.1.2 **内存资源限制**
|
||
|
||
Docker 可以通过以下参数限制容器的内存使用：
|
||
|
||
- **`-m` 或 `--memory`**：限制容器的物理内存使用量。例如，`-m 512m` 表示限制容器使用 512MB 的物理内存。
|
||
- **`--memory-swap`**：限制容器的总内存使用量（物理内存 + 交换空间）。例如，`--memory-swap=1g` 表示容器可以使用 1GB 的总内存。
|
||
|
||
###### 6.2.1.3 **磁盘 I/O 资源限制**
|
||
|
||
Docker 可以限制容器的磁盘 I/O 使用：
|
||
|
||
- **`--blkio-weight`**：设置容器的块设备 I/O 权重，范围为 10 到 1000。
|
||
- **`--device-read-bps` 和 `--device-write-bps`**：限制特定设备的读写速率。例如，`--device-read-bps /dev/sda:1mb` 表示限制容器对 `/dev/sda` 的读取速率为 1MB/s。
|
||
|
||
##### 6.2.2 查看和管理 cgroups 资源限制
|
||
|
||
- **查看 cgroups 配置**：可以通过访问 `/sys/fs/cgroup` 目录来查看容器的 cgroups 配置。例如，`/sys/fs/cgroup/cpu/docker/<container_id>` 目录下包含了容器的 CPU 资源限制文件。
|
||
- **动态调整资源限制**：在容器运行时，可以通过修改 cgroups 文件的内容来动态调整资源限制。
|
||
|
||
##### 6.2.3 使用压缩工具测试
|
||
|
||
```plain
|
||
[root@bogon ~]# docker pull lorel/docker-stress-ng
|
||
Using default tag: latest
|
||
latest: Pulling from lorel/docker-stress-ng
|
||
c52e3ed763ff: Pull complete
|
||
a3ed95caeb02: Pull complete
|
||
7f831269c70e: Pull complete
|
||
Digest: sha256:c8776b750869e274b340f8e8eb9a7d8fb2472edd5b25ff5b7d55728bca681322
|
||
Status: Downloaded newer image for lorel/docker-stress-ng:latest
|
||
```
|
||
|
||
###### 6.2.3.1 测试CPU
|
||
|
||
不限制cpu使用
|
||
|
||
```bash
|
||
[root@bogon ~]# docker container run --name stress -it --rm lorel/docker-stress-ng:latest --cpu 4
|
||
stress-ng: info: [1] defaulting to a 86400 second run per stressor
|
||
stress-ng: info: [1] dispatching hogs: 8 cpu
|
||
[root@bogon ~]# docker stats
|
||
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
|
||
92b0b8d916c1 stress 101.54% 15.81MiB / 983.3MiB 1.61% 648B / 0B 0B / 0B 9
|
||
[root@bogon ~]# top
|
||
top - 19:15:49 up 2 days, 2:38, 2 users, load average: 7.02, 3.00, 1.15
|
||
Tasks: 131 total, 10 running, 121 sleeping, 0 stopped, 0 zombie
|
||
%Cpu(s): 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
|
||
KiB Mem : 1006892 total, 100680 free, 320704 used, 585508 buff/cache
|
||
KiB Swap: 2097148 total, 2096628 free, 520 used. 422732 avail Mem
|
||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||
40035 root 20 0 6908 4180 252 R 12.6 0.4 0:12.79 stress-ng-cpu
|
||
40037 root 20 0 6908 4180 252 R 12.6 0.4 0:12.78 stress-ng-cpu
|
||
40038 root 20 0 6908 2136 252 R 12.6 0.2 0:12.78 stress-ng-cpu
|
||
40040 root 20 0 6908 2136 252 R 12.6 0.2 0:12.78 stress-ng-cpu
|
||
40036 root 20 0 6908 2136 252 R 12.3 0.2 0:12.77 stress-ng-cpu
|
||
40039 root 20 0 6908 2136 252 R 12.3 0.2 0:12.78 stress-ng-cpu
|
||
40041 root 20 0 6908 4180 252 R 12.3 0.4 0:12.77 stress-ng-cpu
|
||
40042 root 20 0 6908 2136 252 R 12.3 0.2 0:12.77 stress-ng-cpu
|
||
1 root 20 0 128484 7208 4196 S 0.0 0.7 0:10.12 systemd
|
||
```
|
||
|
||
可以看到，cpu使用已经满了
|
||
|
||
重新启动容器加入CPU限制参数
|
||
|
||
```bash
|
||
[root@bogon ~]# docker container run --name stress --cpus=0.5 -it --rm lorel/docker-stress-ng:latest --cpu 8
|
||
stress-ng: info: [1] defaulting to a 86400 second run per stressor
|
||
stress-ng: info: [1] dispatching hogs: 8 cpu
|
||
[root@bogon ~]# docker stats
|
||
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
|
||
845220ef9982 stress 51.57% 20.05MiB / 983.3MiB 2.04% 648B / 0B 0B / 0B 9
|
||
```
|
||
|
||
### 7. 容器规范
|
||
|
||
#### 7.1 容器技术及其标准化组织 OCI
|
||
|
||
容器技术是一种轻量级的虚拟化技术，用于隔离应用程序及其依赖项，使其能够在不同的环境中一致地运行。除了 Docker 之外，还有其他多种容器运行时和工具，例如 CoreOS 的 rkt、阿里的 Pouch 和红帽的 Podman。为了确保容器生态系统的标准性和可持续发展，Linux 基金会、Docker、微软、红帽、谷歌和 IBM 等公司在 2015 年 6 月共同成立了 **Open Container Initiative (OCI)** 组织。
|
||
|
||
##### 7.1.1 **OCI 的目标**
|
||
|
||
OCI 的主要目标是制定开放的容器规范，以确保不同容器技术之间的可移植性和互操作性。目前，OCI 已经发布了两个核心规范：
|
||
|
||
1. **Runtime Spec**：定义了容器运行时的规范，包括容器的生命周期管理、资源隔离和安全等。
|
||
2. **Image Format Spec**：定义了容器镜像的格式和元数据，确保镜像可以在不同的容器运行时之间共享和运行。
|
||
|
||
通过遵循这些规范，不同的容器运行时和工具可以实现互操作性，从而推动容器技术的标准化和健康发展。
|
||
|
||
##### 7.1.2 主流容器运行时
|
||
|
||
容器运行时是真正运行容器的地方，它需要与操作系统的内核紧密合作，为容器提供隔离的运行环境。以下是目前主流的三种容器运行时：
|
||
|
||
###### 7.1.2.1 **LXC (Linux Containers)**
|
||
|
||
- **简介**：LXC 是 Linux 上早期的容器运行时，它利用 Linux 内核的 Namespace 和 Cgroups 技术来实现进程隔离和资源管理。
|
||
- **特点**：
|
||
- 提供了完整的 Linux 系统环境，支持多种 Linux 发行版。
|
||
- 早期 Docker 也曾使用 LXC 作为其默认的运行时。
|
||
- **适用场景**：适用于需要完整 Linux 系统环境的容器化应用。
|
||
|
||
###### 7.1.2.2 **Runc**
|
||
|
||
- **简介**：Runc 是目前 Docker 默认的容器运行时，它是一个轻量级的命令行工具，用于运行和管理容器。
|
||
- **特点**：
|
||
- 完全遵循 OCI 的 Runtime Spec 规范，确保与 OCI 标准的兼容性。
|
||
- 由于其轻量级和高性能的特点，Runc 已经成为许多容器运行时的底层实现。
|
||
- **适用场景**：适用于需要高性能和轻量级容器运行环境的场景。
|
||
|
||
###### 7.1.2.3 **Rkt (Rocket)**
|
||
|
||
- **简介**：Rkt 是由 CoreOS 开发的容器运行时，旨在提供一个安全、可靠且符合 OCI 规范的容器运行环境。
|
||
- **特点**：
|
||
- 与 Docker 不同，Rkt 本身是一个独立的容器运行时，不依赖 Docker 的守护进程。
|
||
- 提供了更好的安全性和隔离性，例如通过 AppArmor 和 SELinux 等安全机制。
|
||
- **适用场景**：适用于对安全性要求较高的容器化应用。
|
||
|
||
容器技术的发展离不开标准化的推动。OCI 通过制定 Runtime Spec 和 Image Format Spec，为容器运行时和工具提供了统一的标准，确保了不同容器技术之间的互操作性和可移植性。目前主流的容器运行时（如 LXC、Runc 和 Rkt）都遵循这些规范，从而推动了容器技术的广泛应用和发展。
|
||
|
||
### 8. docker info信息
|
||
|
||
```bash
|
||
[root@localhost ~]# docker info
|
||
Client:
|
||
Context: default
|
||
Debug Mode: false
|
||
Plugins:
|
||
app: Docker App (Docker Inc., v0.9.1-beta3)
|
||
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
|
||
scan: Docker Scan (Docker Inc.)
|
||
|
||
Server:
|
||
Containers: 2 # 当前主机运行容器总数
|
||
Running: 1 # 有几个容器是正在运行的
|
||
Paused: 0 # 有几个容器是暂停的
|
||
Stopped: 1 # 有几个容器是停止的
|
||
Images: 1 # 当前服务器的镜像数
|
||
Server Version: 20.10.6 # 服务端版本
|
||
Storage Driver: overlay2 # 正在使用的存储引擎
|
||
Backing Filesystem: xfs # 后端文件系统，即服务器的磁盘文件系统
|
||
Supports d_type: true # 是否支持d_type
|
||
Native Overlay Diff: true # 是否支持差异数据存储
|
||
userxattr: false
|
||
Logging Driver: json-file # 日志文件类型
|
||
Cgroup Driver: cgroupfs # cgroups类型
|
||
Cgroup Version: 1
|
||
Plugins: # 插件
|
||
Volume: local # 卷
|
||
Network: bridge host ipvlan macvlan null overlay
|
||
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
|
||
Swarm: inactive # 是否支持swarm
|
||
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
|
||
Default Runtime: runc # 默认的runtime
|
||
Init Binary: docker-init # 初始化容器的守护进程
|
||
containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
|
||
runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
|
||
init version: de40ad0
|
||
Security Options: # 安全选项
|
||
seccomp
|
||
Profile: default
|
||
Kernel Version: 3.10.0-693.el7.x86_64 # 宿主机内核版本
|
||
Operating System: CentOS Linux 7 (Core) # 宿主机操作系统
|
||
OSType: linux # 宿主机操作系统类型
|
||
Architecture: x86_64 # 宿主机架构
|
||
CPUs: 1 # 宿主机cpu数量
|
||
Total Memory: 1.781GiB # 宿主机总内存
|
||
Name: docker-server # 宿主机主机名
|
||
ID: ARN5:ESPO:FEZ4:KDZ6:RWGG:WQ3X:SIXN:3FVG:ATXH:JAXA:ENGH:RAVE
|
||
Docker Root Dir: /var/lib/docker # 宿主机数据保存目录
|
||
Debug Mode: false
|
||
Registry: https://index.docker.io/v1/ # 镜像仓库
|
||
Labels:
|
||
Experimental: false # 是否是测试版
|
||
Insecure Registries:
|
||
127.0.0.0/8
|
||
Live Restore Enabled: false # 是否开启活动容器（重启不关闭容器）
|
||
```
|
||
|
||
### 9. docker 存储引擎
|
||
|
||
Docker 的存储引擎是 Docker 平台中用于管理容器和镜像数据的核心组件。它负责容器的文件系统、网络配置、权限管理等，以及其他与容器运行相关的任务。以下是对 Docker 存储引擎的详细介绍：
|
||
|
||
#### 9.1 **核心概念及工作原理**
|
||
|
||
Docker 存储引擎的核心思想是“层”的概念。镜像是由多个只读层组成的，而容器则在镜像的基础上添加了一个可读写的层。这种分层架构使得镜像的复用和部署变得非常方便，同时减少了容器的体积。
|
||
|
||
Docker 使用联合文件系统（Union File System）来管理容器的文件系统。联合文件系统允许将多个目录（或文件系统）合并为一个统一的文件系统视图。Docker 的存储引擎通过这种机制，将镜像层和容器层合并在一起，使得容器能够看到一个完整的文件系统。
|
||
|
||
Docker 支持多种存储引擎，每种存储引擎都有其特点和适用场景。以下是一些常见的存储引擎：
|
||
|
||
**AUFS（Another Union File System）**
|
||
|
||
- **特点**：AUFS 是一种文件级的存储驱动，允许多个目录共享相同的文件系统层次结构。它通过联合挂载技术将多个目录挂载到一个单一的文件系统上。
|
||
- **适用场景**：AUFS 曾是 Docker 早期版本的默认存储驱动，但在较新的 Docker 版本中已被 Overlay2 替代。
|
||
|
||
**OverlayFS**
|
||
|
||
- **特点**：OverlayFS 是一种更现代的联合文件系统，从 Linux 内核 3.18 开始支持。它将文件系统简化为两层：一个只读的下层（lowerdir）和一个可读写的上层（upperdir），统一后的视图称为合并层（merged）。
|
||
- **优势**：OverlayFS 支持页缓存共享，多个容器如果读取相同层的同一个文件，可以共享页缓存，从而提高内存利用率。此外，OverlayFS 在性能和稳定性方面表现更好，是目前 Docker 的默认存储驱动。
|
||
|
||
#### 9.2 Docker 的 Overlay2 存储驱动介绍
|
||
|
||
1. **什么是 Overlay2？**
|
||
|
||
Overlay2 是 Docker 中的一种存储驱动，用于管理容器和镜像的文件系统。它是 OverlayFS 的改进版本，解决了早期 Overlay 驱动可能遇到的 inode 耗尽问题。Overlay2 使用联合文件系统（Union File System）技术，将多个文件系统层合并为一个统一的文件系统视图，从而实现高效的容器文件系统管理。
|
||
|
||
2. **Overlay2 的工作原理**
|
||
|
||
Overlay2 通过以下三个主要目录来管理文件系统：
|
||
|
||
- **`LowerDir`**：只读层，包含基础镜像的文件系统。可以有多个只读层，每层都是独立的。
|
||
- **`UpperDir`**：读写层，用于存储容器运行时的文件系统变更（即 diff 层）。
|
||
- **`MergedDir`**：联合挂载后的视图，容器看到的完整文件系统。它将 `LowerDir` 和 `UpperDir` 合并为一个统一的文件系统视图。
|
||
- **`WorkDir`**：工作目录，用于联合挂载的内部操作，挂载后内容被清空。
|
||
|
||
当启动一个容器时，Overlay2 会将镜像层（`LowerDir`）和容器层（`UpperDir`）联合挂载到 `MergedDir`，容器通过这个目录看到完整的文件系统。 |