mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-10 11:54:37 +00:00
Fix naming of the chapter dir
This commit is contained in:
Baohua Yang
27
03_install/summary.md
Normal file
27
03_install/summary.md
Normal file
@@ -0,0 +1,27 @@
|
||||
## 3.11 本章小结
|
||||
|
||||
Docker 支持在多种平台上安装和使用，选择合适的安装方式是顺利使用 Docker 的第一步。
|
||||
|
||||
| 平台 | 推荐方式 | 说明 |
|
||||
|------|---------|------|
|
||||
| **Ubuntu/Debian** | 官方 APT 仓库 | 最完善的支持，推荐首选 |
|
||||
| **CentOS/Fedora** | 官方 YUM/DNF 仓库 | 注意关闭 SELinux 或配置策略 |
|
||||
| **macOS** | Docker Desktop | 图形化安装，包含 Compose 和 Kubernetes |
|
||||
| **Windows 10/11** | Docker Desktop (WSL 2) | 需启用 WSL 2 后端 |
|
||||
| **Raspberry Pi** | 官方安装脚本 | 支持 ARM 架构 |
|
||||
| **离线环境** | 二进制包安装 | 适用于无法联网的服务器 |
|
||||
|
||||
### 3.11.1 安装后验证
|
||||
|
||||
安装完成后，运行以下命令验证 Docker 是否正常工作：
|
||||
|
||||
```bash
|
||||
$ docker version
|
||||
$ docker run --rm hello-world
|
||||
```
|
||||
|
||||
### 3.11.2 延伸阅读
|
||||
|
||||
- [镜像加速器](3.9_mirror.md)：解决国内拉取镜像慢的问题
|
||||
- [开启实验特性](3.10_experimental.md)：使用最新功能
|
||||
- [Docker Hub](../06_repository/6.1_dockerhub.md)：官方镜像仓库
|
||||
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
@@ -1,6 +0,0 @@
|
||||
# 第八章数据与网络管理
|
||||
|
||||
本章将介绍 Docker 中的数据管理与网络配置。
|
||||
|
||||
* [数据管理](data/README.md)
|
||||
* [网络配置](network/README.md)
|
||||
@@ -1,344 +0,0 @@
|
||||
# 网络配置
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
## 8.6 Docker 网络概述
|
||||
|
||||
Docker 容器需要网络来：
|
||||
|
||||
- 与外部世界通信 (访问互联网、被外部访问)
|
||||
- 容器之间相互通信
|
||||
- 与宿主机通信
|
||||
|
||||
Docker 在安装时会自动配置网络基础设施，大多数情况下开箱即用。
|
||||
|
||||
## 8.6 默认网络架构
|
||||
|
||||
Docker 启动时自动创建以下网络组件：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Host [宿主机]
|
||||
eth0[物理网卡 eth0<br>192.168.1.100]
|
||||
docker0[docker0 网桥<br>172.17.0.1]
|
||||
|
||||
subgraph Containers
|
||||
subgraph ContainerA [容器 A]
|
||||
eth0_A[eth0<br>172.17.0.2]
|
||||
end
|
||||
subgraph ContainerB [容器 B]
|
||||
eth0_B[eth0<br>172.17.0.3]
|
||||
end
|
||||
end
|
||||
|
||||
eth0 <--> docker0
|
||||
docker0 <--> eth0_A
|
||||
docker0 <--> eth0_B
|
||||
end
|
||||
|
||||
Internet((互联网)) <--> eth0
|
||||
```
|
||||
|
||||
### 8.6.1 核心组件
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
| 组件 | 说明 |
|
||||
|------|------|
|
||||
| **docker0** | 虚拟网桥，充当交换机角色 |
|
||||
| **veth pair** | 虚拟网卡对，一端在容器内，一端连接网桥 |
|
||||
| **容器 eth0** | 容器内的网卡 |
|
||||
| **IP 地址** | 自动从 172.17.0.0/16 网段分配 |
|
||||
|
||||
### 8.6.2 数据流向
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Comm1 ["容器间通信"]
|
||||
direction LR
|
||||
C1A["容器 A (172.17.0.2)"] --> D0A["docker0"] --> C1B["容器 B (172.17.0.3)"]
|
||||
end
|
||||
|
||||
subgraph Comm2 ["访问外网"]
|
||||
direction LR
|
||||
C2A["容器 A (172.17.0.2)"] --> D0B["docker0"] --> Eth0A["eth0"] --> InternetA["互联网"]
|
||||
end
|
||||
|
||||
subgraph Comm3 ["被外部访问，需端口映射"]
|
||||
direction LR
|
||||
Req["外部请求"] --> Eth0B["eth0"] --> D0C["docker0"] --> C3A["容器 A"]
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.6 Docker 网络类型
|
||||
|
||||
查看默认网络：
|
||||
|
||||
```bash
|
||||
$ docker network ls
|
||||
NETWORK ID NAME DRIVER SCOPE
|
||||
abc123... bridge bridge local
|
||||
def456... host host local
|
||||
ghi789... none null local
|
||||
```
|
||||
|
||||
| 网络类型 | 说明 | 适用场景 |
|
||||
|---------|------|---------|
|
||||
| **bridge** | 默认类型，容器连接到虚拟网桥 | 大多数单机场景 |
|
||||
| **host** | 容器直接使用宿主机网络栈 | 需要最高网络性能时 |
|
||||
| **none** | 禁用网络 | 完全隔离的容器 |
|
||||
| **overlay** | 跨主机网络 | Docker Swarm 集群 |
|
||||
| **macvlan** | 容器拥有独立 MAC 地址 | 需要直接接入物理网络 |
|
||||
|
||||
---
|
||||
|
||||
## 8.6 用户自定义网络 (推荐)
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
### 8.6.1 为什么要用自定义网络
|
||||
|
||||
默认 bridge 网络的局限：
|
||||
|
||||
| 问题 | 自定义网络的优势 |
|
||||
|------|-----------------|
|
||||
| 只能用 IP 通信 | 支持容器名 DNS 解析 |
|
||||
| 所有容器在同一网络 | 更好的隔离性 |
|
||||
| 需要 --link (已废弃)| 原生支持服务发现 |
|
||||
|
||||
### 8.6.2 创建自定义网络
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
## 创建网络
|
||||
|
||||
$ docker network create mynet
|
||||
|
||||
## 查看网络详情
|
||||
|
||||
$ docker network inspect mynet
|
||||
```
|
||||
|
||||
### 8.6.3 使用自定义网络
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
## 启动容器并连接到自定义网络
|
||||
|
||||
$ docker run -d --name web --network mynet nginx
|
||||
$ docker run -d --name db --network mynet postgres
|
||||
|
||||
## 在 web 容器中可以直接用容器名访问 db
|
||||
|
||||
$ docker exec web ping db
|
||||
PING db (172.18.0.3): 56 data bytes
|
||||
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.083 ms
|
||||
```
|
||||
|
||||
### 8.6.4 容器名 DNS 解析
|
||||
|
||||
自定义网络自动提供 DNS 服务：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph MyNet ["mynet 网络 : web 容器可以用 'db' 作为主机名访问 db 容器"]
|
||||
direction LR
|
||||
Web["web<br/>172.18.0.2"] -- "DNS: 'db' → 172.18.0.3" --> DB["db<br/>172.18.0.3"]
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.6 容器互联
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
### 8.6.1 同一网络内的容器
|
||||
|
||||
同一自定义网络内的容器可以直接通信：
|
||||
|
||||
```bash
|
||||
## 创建网络
|
||||
|
||||
$ docker network create app-net
|
||||
|
||||
## 启动应用和数据库
|
||||
|
||||
$ docker run -d --name redis --network app-net redis
|
||||
$ docker run -d --name app --network app-net myapp
|
||||
|
||||
## app 容器中可以用 redis:6379 连接 Redis
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### 8.6.2 连接到多个网络
|
||||
|
||||
一个容器可以连接到多个网络：
|
||||
|
||||
```bash
|
||||
## 启动容器
|
||||
|
||||
$ docker run -d --name multi-net-container --network frontend nginx
|
||||
|
||||
## 再连接到另一个网络
|
||||
|
||||
$ docker network connect backend multi-net-container
|
||||
|
||||
## 查看容器的网络
|
||||
|
||||
$ docker inspect multi-net-container --format '{{json .NetworkSettings.Networks}}'
|
||||
```
|
||||
|
||||
### 8.6.3 ⚠️ --link 已废弃
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
## 旧方式（不推荐）
|
||||
|
||||
$ docker run --link db:database myapp
|
||||
|
||||
## 新方式（推荐）
|
||||
|
||||
$ docker network create mynet
|
||||
$ docker run --network mynet --name db postgres
|
||||
$ docker run --network mynet --name app myapp
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.6 端口映射
|
||||
|
||||
容器默认只能在 Docker 网络内访问。要从外部访问容器，需要端口映射：
|
||||
|
||||
### 8.6.1 基本语法
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
## -p 宿主机端口:容器端口
|
||||
|
||||
$ docker run -d -p 8080:80 nginx
|
||||
```
|
||||
|
||||
### 8.6.2 映射方式
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
| 参数 | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| `-p 8080:80` | 指定端口映射 | 宿主机 8080 → 容器 80 |
|
||||
| `-p 80` | 随机宿主机端口 | 随机端口 → 容器 80 |
|
||||
| `-P` | 自动映射所有暴露端口 | 随机端口 → 所有 EXPOSE 端口 |
|
||||
| `-p 127.0.0.1:8080:80` | 只绑定本地 | 仅本机可访问 |
|
||||
| `-p 8080:80/udp` | UDP 端口 | UDP 协议 |
|
||||
|
||||
### 8.6.3 查看端口映射
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
$ docker port mycontainer
|
||||
80/tcp -> 0.0.0.0:8080
|
||||
```
|
||||
|
||||
### 8.6.4 端口映射示意图
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Req["外部请求 http://宿主机IP:8080"] --> Host["宿主机:8080"]
|
||||
Host -- "iptables NAT" --> Container["容器 nginx:80"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.6 网络隔离
|
||||
|
||||
不同网络之间默认隔离：
|
||||
|
||||
```bash
|
||||
## 创建两个网络
|
||||
|
||||
$ docker network create frontend
|
||||
$ docker network create backend
|
||||
|
||||
## 容器 A 在 frontend
|
||||
|
||||
$ docker run -d --name web --network frontend nginx
|
||||
|
||||
## 容器 B 在 backend
|
||||
|
||||
$ docker run -d --name db --network backend postgres
|
||||
|
||||
## web 无法直接访问 db（不同网络）
|
||||
|
||||
$ docker exec web ping db
|
||||
ping: db: Name or service not known
|
||||
```
|
||||
|
||||
这种隔离有助于安全：前端容器无法直接访问数据库网络。
|
||||
|
||||
---
|
||||
|
||||
## 8.6 常用命令
|
||||
|
||||
运行以下命令：
|
||||
|
||||
```bash
|
||||
## 列出网络
|
||||
|
||||
$ docker network ls
|
||||
|
||||
## 创建网络
|
||||
|
||||
$ docker network create mynet
|
||||
|
||||
## 查看网络详情
|
||||
|
||||
$ docker network inspect mynet
|
||||
|
||||
## 连接容器到网络
|
||||
|
||||
$ docker network connect mynet mycontainer
|
||||
|
||||
## 断开网络连接
|
||||
|
||||
$ docker network disconnect mynet mycontainer
|
||||
|
||||
## 删除网络
|
||||
|
||||
$ docker network rm mynet
|
||||
|
||||
## 清理未使用的网络
|
||||
|
||||
$ docker network prune
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.6 本章小结
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **默认网络** | docker0 网桥，172.17.0.0/16 网段 |
|
||||
| **自定义网络** | 推荐使用，支持容器名 DNS 解析 |
|
||||
| **端口映射** | `-p 宿主机端口:容器端口` 暴露服务 |
|
||||
| **网络隔离** | 不同网络默认隔离，增强安全性 |
|
||||
| **--link** | 已废弃，使用自定义网络替代 |
|
||||
|
||||
## 8.6 延伸阅读
|
||||
|
||||
- [配置 DNS](dns.md)：自定义 DNS 设置
|
||||
- [端口映射](port_mapping.md)：高级端口配置
|
||||
- [Compose 网络](../../10_compose/10.5_compose_file.md)：Compose 中的网络配置
|
||||
@@ -1,26 +0,0 @@
|
||||
## 8.9 本章小结
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
| 场景 | DNS 行为 | 备注 |
|
||||
|------|----------|------|
|
||||
| **默认网络** | 继承宿主机 | 不支持容器名解析 |
|
||||
| **自定义网络** | Docker 嵌入式 DNS | ✅ 支持容器名解析 |
|
||||
| **手动指定** | 使用 `--dns` | 覆盖默认配置 |
|
||||
|
||||
### 8.9.1 延伸阅读
|
||||
|
||||
- [网络模式](README.md)：Docker 网络概览
|
||||
- [端口映射](port_mapping.md)：外部访问
|
||||
|
||||
| 要点 | 说明 |
|
||||
|------|------|
|
||||
| **-p** | 指定端口映射 (常用)，如 `8080:80` |
|
||||
| **-P** | 随机映射所有 EXPOSE 的端口 |
|
||||
| **安全性** | 默认监听所有 IP，敏感服务应绑定 `127.0.0.1` |
|
||||
| **查看** | 使用 `docker port` 或 `docker ps` |
|
||||
|
||||
### 8.9.2 延伸阅读
|
||||
|
||||
- [EXPOSE 指令](../../07_dockerfile/7.9_expose.md)：在 Dockerfile 中声明端口
|
||||
- [网络模式](README.md)：Host 模式不需要端口映射
|
||||
41
09_network/README.md
Normal file
41
09_network/README.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# 网络配置
|
||||
|
||||
Docker 容器需要网络来与外部世界通信、容器之间相互通信以及与宿主机通信。Docker 在安装时会自动配置网络基础设施，大多数情况下开箱即用。
|
||||
|
||||
## 概述
|
||||
|
||||
Docker 启动时自动创建以下网络组件：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Host [宿主机]
|
||||
eth0[物理网卡 eth0<br>192.168.1.100]
|
||||
docker0[docker0 网桥<br>172.17.0.1]
|
||||
|
||||
subgraph Containers
|
||||
subgraph ContainerA [容器 A]
|
||||
eth0_A[eth0<br>172.17.0.2]
|
||||
end
|
||||
subgraph ContainerB [容器 B]
|
||||
eth0_B[eth0<br>172.17.0.3]
|
||||
end
|
||||
end
|
||||
|
||||
eth0 <--> docker0
|
||||
docker0 <--> eth0_A
|
||||
docker0 <--> eth0_B
|
||||
end
|
||||
|
||||
Internet((互联网)) <--> eth0
|
||||
```
|
||||
|
||||
本章将详细介绍 Docker 网络配置的各个方面。
|
||||
|
||||
## 本章内容
|
||||
|
||||
* [配置 DNS](dns.md)
|
||||
* [外部访问容器](port_mapping.md)
|
||||
* [网络类型](network_types.md)
|
||||
* [自定义网络](custom_network.md)
|
||||
* [容器互联](container_linking.md)
|
||||
* [网络隔离](network_isolation.md)
|
||||
62
09_network/container_linking.md
Normal file
62
09_network/container_linking.md
Normal file
@@ -0,0 +1,62 @@
|
||||
## 9.5 容器互联
|
||||
|
||||
容器之间的网络通信是 Docker 网络的核心功能之一。本节介绍容器互联的几种方式。
|
||||
|
||||
### 9.5.1 同一网络内的容器
|
||||
|
||||
同一自定义网络内的容器可以直接通过容器名通信，这是推荐的容器互联方式：
|
||||
|
||||
```bash
|
||||
## 创建网络
|
||||
|
||||
$ docker network create app-net
|
||||
|
||||
## 启动应用和数据库
|
||||
|
||||
$ docker run -d --name redis --network app-net redis
|
||||
$ docker run -d --name app --network app-net myapp
|
||||
|
||||
## app 容器中可以用 redis:6379 连接 Redis
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
### 9.5.2 连接到多个网络
|
||||
|
||||
一个容器可以同时连接到多个网络，这对于需要跨网络通信的中间件容器特别有用：
|
||||
|
||||
```bash
|
||||
## 启动容器
|
||||
|
||||
$ docker run -d --name multi-net-container --network frontend nginx
|
||||
|
||||
## 再连接到另一个网络
|
||||
|
||||
$ docker network connect backend multi-net-container
|
||||
|
||||
## 查看容器的网络
|
||||
|
||||
$ docker inspect multi-net-container --format '{{json .NetworkSettings.Networks}}'
|
||||
```
|
||||
|
||||
### 9.5.3 ⚠️ --link 已废弃
|
||||
|
||||
`--link` 是 Docker 早期用于容器互联的方式，**已经被废弃**，不建议在新项目中使用。请使用自定义网络替代：
|
||||
|
||||
```bash
|
||||
## 旧方式（不推荐）
|
||||
|
||||
$ docker run --link db:database myapp
|
||||
|
||||
## 新方式（推荐）
|
||||
|
||||
$ docker network create mynet
|
||||
$ docker run --network mynet --name db postgres
|
||||
$ docker run --network mynet --name app myapp
|
||||
```
|
||||
|
||||
使用自定义网络的优势在于：
|
||||
|
||||
- 原生支持 DNS 解析
|
||||
- 不需要在容器启动时显式声明依赖
|
||||
- 更灵活，可以动态 connect/disconnect
|
||||
93
09_network/custom_network.md
Normal file
93
09_network/custom_network.md
Normal file
@@ -0,0 +1,93 @@
|
||||
## 9.4 用户自定义网络 (推荐)
|
||||
|
||||
在生产环境中，推荐使用用户自定义网络代替默认的 bridge 网络。自定义网络提供了更好的隔离性和服务发现能力。
|
||||
|
||||
### 9.4.1 为什么要用自定义网络
|
||||
|
||||
默认 bridge 网络存在以下局限，而自定义网络可以很好地解决这些问题：
|
||||
|
||||
| 问题 | 自定义网络的优势 |
|
||||
|------|-----------------|
|
||||
| 只能用 IP 通信 | 支持容器名 DNS 解析 |
|
||||
| 所有容器在同一网络 | 更好的隔离性 |
|
||||
| 需要 --link (已废弃)| 原生支持服务发现 |
|
||||
|
||||
### 9.4.2 创建自定义网络
|
||||
|
||||
使用 `docker network create` 命令可以创建自定义网络：
|
||||
|
||||
```bash
|
||||
## 创建网络
|
||||
|
||||
$ docker network create mynet
|
||||
|
||||
## 查看网络详情
|
||||
|
||||
$ docker network inspect mynet
|
||||
```
|
||||
|
||||
### 9.4.3 使用自定义网络
|
||||
|
||||
启动容器时通过 `--network` 参数指定连接的网络：
|
||||
|
||||
```bash
|
||||
## 启动容器并连接到自定义网络
|
||||
|
||||
$ docker run -d --name web --network mynet nginx
|
||||
$ docker run -d --name db --network mynet postgres
|
||||
|
||||
## 在 web 容器中可以直接用容器名访问 db
|
||||
|
||||
$ docker exec web ping db
|
||||
PING db (172.18.0.3): 56 data bytes
|
||||
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.083 ms
|
||||
```
|
||||
|
||||
### 9.4.4 容器名 DNS 解析
|
||||
|
||||
自定义网络自动提供 DNS 服务。Docker 守护进程在 `127.0.0.11` 运行了一个嵌入式 DNS 服务器，容器内的 DNS 请求会被转发到这里：
|
||||
|
||||
- 如果是容器名，解析为容器 IP
|
||||
- 如果是外部域名 (如 google.com)，转发给上游 DNS
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph MyNet ["mynet 网络 : web 容器可以用 'db' 作为主机名访问 db 容器"]
|
||||
direction LR
|
||||
Web["web<br/>172.18.0.2"] -- "DNS: 'db' → 172.18.0.3" --> DB["db<br/>172.18.0.3"]
|
||||
end
|
||||
```
|
||||
|
||||
### 9.4.5 常用网络命令
|
||||
|
||||
以下是 Docker 网络管理中常用的命令：
|
||||
|
||||
```bash
|
||||
## 列出网络
|
||||
|
||||
$ docker network ls
|
||||
|
||||
## 创建网络
|
||||
|
||||
$ docker network create mynet
|
||||
|
||||
## 查看网络详情
|
||||
|
||||
$ docker network inspect mynet
|
||||
|
||||
## 连接容器到网络
|
||||
|
||||
$ docker network connect mynet mycontainer
|
||||
|
||||
## 断开网络连接
|
||||
|
||||
$ docker network disconnect mynet mycontainer
|
||||
|
||||
## 删除网络
|
||||
|
||||
$ docker network rm mynet
|
||||
|
||||
## 清理未使用的网络
|
||||
|
||||
$ docker network prune
|
||||
```
|
||||
@@ -1,8 +1,8 @@
|
||||
## 8.7 配置 DNS
|
||||
## 9.2 配置 DNS
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
Docker 容器的 DNS 配置决定了容器如何解析域名。理解 DNS 机制对于容器网络的正确配置至关重要。
|
||||
|
||||
### 8.7.1 容器的 DNS 机制
|
||||
### 9.2.1 容器的 DNS 机制
|
||||
|
||||
Docker 容器的 DNS 配置有两种情况：
|
||||
|
||||
@@ -11,9 +11,9 @@ Docker 容器的 DNS 配置有两种情况：
|
||||
|
||||
---
|
||||
|
||||
### 8.7.2 嵌入式 DNS
|
||||
### 9.2.2 嵌入式 DNS
|
||||
|
||||
这是 Docker 网络最强大的功能之一。在自定义网络中，容器可以通过 “名字” 找到彼此，而不需要知道对方的 IP (因为 IP 可能会变)。
|
||||
这是 Docker 网络最强大的功能之一。在自定义网络中，容器可以通过 "名字" 找到彼此，而不需要知道对方的 IP (因为 IP 可能会变)。
|
||||
|
||||
```bash
|
||||
## 1. 创建自定义网络
|
||||
@@ -36,7 +36,7 @@ Docker 守护进程在 `127.0.0.11` 运行了一个 DNS 服务器。容器内的
|
||||
|
||||
---
|
||||
|
||||
### 8.7.3 配置 DNS 参数
|
||||
### 9.2.3 配置 DNS 参数
|
||||
|
||||
如果你需要手动配置容器的 DNS (例如使用内网 DNS 服务器)，可以在 `docker run` 中使用以下参数：
|
||||
|
||||
@@ -67,7 +67,7 @@ $ docker run -h myweb nginx
|
||||
|
||||
---
|
||||
|
||||
### 8.7.4 全局 DNS 配置
|
||||
### 9.2.4 全局 DNS 配置
|
||||
|
||||
如果希望所有容器都使用特定的 DNS 服务器 (而不是继承宿主机)，可以修改 `/etc/docker/daemon.json`：
|
||||
|
||||
@@ -84,9 +84,9 @@ $ docker run -h myweb nginx
|
||||
|
||||
---
|
||||
|
||||
### 8.7.5 常见问题
|
||||
### 9.2.5 常见问题
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
以下是使用容器 DNS 时常见的问题及解决方法：
|
||||
|
||||
#### Q：容器无法解析域名
|
||||
|
||||
81
09_network/network_isolation.md
Normal file
81
09_network/network_isolation.md
Normal file
@@ -0,0 +1,81 @@
|
||||
## 9.7 网络隔离
|
||||
|
||||
Docker 网络提供了天然的隔离能力，不同网络之间的容器默认无法通信。这是 Docker 网络安全的重要基础。
|
||||
|
||||
### 9.7.1 网络隔离原理
|
||||
|
||||
不同网络之间默认隔离，容器只能与同一网络中的容器直接通信：
|
||||
|
||||
```bash
|
||||
## 创建两个网络
|
||||
|
||||
$ docker network create frontend
|
||||
$ docker network create backend
|
||||
|
||||
## 容器 A 在 frontend
|
||||
|
||||
$ docker run -d --name web --network frontend nginx
|
||||
|
||||
## 容器 B 在 backend
|
||||
|
||||
$ docker run -d --name db --network backend postgres
|
||||
|
||||
## web 无法直接访问 db（不同网络）
|
||||
|
||||
$ docker exec web ping db
|
||||
ping: db: Name or service not known
|
||||
```
|
||||
|
||||
### 9.7.2 安全优势
|
||||
|
||||
这种隔离机制带来以下安全优势：
|
||||
|
||||
| 场景 | 说明 |
|
||||
|------|------|
|
||||
| **前后端分离** | 前端容器无法直接访问数据库网络 |
|
||||
| **微服务隔离** | 不同微服务组可以使用不同网络 |
|
||||
| **多租户** | 不同租户的容器在不同网络中完全隔离 |
|
||||
| **最小权限** | 容器只能访问必要的网络资源 |
|
||||
|
||||
### 9.7.3 跨网络通信
|
||||
|
||||
如果确实需要某个容器跨网络通信，可以将其同时连接到多个网络：
|
||||
|
||||
```bash
|
||||
## 创建一个中间件容器，连接到两个网络
|
||||
|
||||
$ docker run -d --name api --network frontend myapi
|
||||
$ docker network connect backend api
|
||||
|
||||
## 现在 api 容器既可以访问 frontend 中的 web，也可以访问 backend 中的 db
|
||||
```
|
||||
|
||||
这种方式让你可以精确控制哪些容器可以跨网络通信，遵循最小权限原则。
|
||||
|
||||
### 9.7.4 典型网络架构
|
||||
|
||||
一个典型的多层应用网络架构如下：
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph FrontendNet ["frontend 网络"]
|
||||
LB["负载均衡器"]
|
||||
Web1["Web 服务器 1"]
|
||||
Web2["Web 服务器 2"]
|
||||
end
|
||||
|
||||
subgraph BackendNet ["backend 网络"]
|
||||
API["API 服务器"]
|
||||
DB["数据库"]
|
||||
Cache["Redis 缓存"]
|
||||
end
|
||||
|
||||
LB --> Web1
|
||||
LB --> Web2
|
||||
Web1 -.-> API
|
||||
Web2 -.-> API
|
||||
API --> DB
|
||||
API --> Cache
|
||||
```
|
||||
|
||||
在这种架构中，API 服务器同时连接到 `frontend` 和 `backend` 网络，充当两个网络之间的桥梁。负载均衡器和 Web 服务器无法直接访问数据库，增强了安全性。
|
||||
78
09_network/network_types.md
Normal file
78
09_network/network_types.md
Normal file
@@ -0,0 +1,78 @@
|
||||
## 9.3 Docker 网络类型
|
||||
|
||||
Docker 提供了多种网络驱动来满足不同的使用场景。安装 Docker 后，系统会自动创建三个默认网络：
|
||||
|
||||
```bash
|
||||
$ docker network ls
|
||||
NETWORK ID NAME DRIVER SCOPE
|
||||
abc123... bridge bridge local
|
||||
def456... host host local
|
||||
ghi789... none null local
|
||||
```
|
||||
|
||||
### 9.3.1 网络类型对比
|
||||
|
||||
各网络类型的特点和适用场景如下：
|
||||
|
||||
| 网络类型 | 说明 | 适用场景 |
|
||||
|---------|------|---------|
|
||||
| **bridge** | 默认类型，容器连接到虚拟网桥 | 大多数单机场景 |
|
||||
| **host** | 容器直接使用宿主机网络栈 | 需要最高网络性能时 |
|
||||
| **none** | 禁用网络 | 完全隔离的容器 |
|
||||
| **overlay** | 跨主机网络 | Docker Swarm 集群 |
|
||||
| **macvlan** | 容器拥有独立 MAC 地址 | 需要直接接入物理网络 |
|
||||
|
||||
### 9.3.2 Bridge 网络 (默认)
|
||||
|
||||
Bridge 是 Docker 默认使用的网络模式。Docker 启动时会自动创建 `docker0` 虚拟网桥，所有未指定网络的容器都会连接到这个网桥上。
|
||||
|
||||
核心组件如下：
|
||||
|
||||
| 组件 | 说明 |
|
||||
|------|------|
|
||||
| **docker0** | 虚拟网桥，充当交换机角色 |
|
||||
| **veth pair** | 虚拟网卡对，一端在容器内，一端连接网桥 |
|
||||
| **容器 eth0** | 容器内的网卡 |
|
||||
| **IP 地址** | 自动从 172.17.0.0/16 网段分配 |
|
||||
|
||||
### 9.3.3 Host 网络
|
||||
|
||||
使用 `--network host` 参数启动的容器会直接使用宿主机的网络栈，不再拥有独立的网络命名空间。容器内的端口就是宿主机的端口，无需端口映射。
|
||||
|
||||
```bash
|
||||
$ docker run -d --network host nginx
|
||||
```
|
||||
|
||||
这种模式下网络性能最高，但容器之间和宿主机之间没有网络隔离。
|
||||
|
||||
### 9.3.4 None 网络
|
||||
|
||||
使用 `--network none` 参数启动的容器只有 `lo` 回环网卡，完全没有外部网络连接。适用于只需要运行计算任务、不需要网络的容器。
|
||||
|
||||
```bash
|
||||
$ docker run -it --network none alpine ip addr
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> ...
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
```
|
||||
|
||||
### 9.3.5 数据流向
|
||||
|
||||
容器网络中的数据流向可以分为以下几种情况：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Comm1 ["容器间通信"]
|
||||
direction LR
|
||||
C1A["容器 A (172.17.0.2)"] --> D0A["docker0"] --> C1B["容器 B (172.17.0.3)"]
|
||||
end
|
||||
|
||||
subgraph Comm2 ["访问外网"]
|
||||
direction LR
|
||||
C2A["容器 A (172.17.0.2)"] --> D0B["docker0"] --> Eth0A["eth0"] --> InternetA["互联网"]
|
||||
end
|
||||
|
||||
subgraph Comm3 ["被外部访问，需端口映射"]
|
||||
direction LR
|
||||
Req["外部请求"] --> Eth0B["eth0"] --> D0C["docker0"] --> C3A["容器 A"]
|
||||
end
|
||||
```
|
||||
@@ -1,10 +1,10 @@
|
||||
## 8.8 外部访问容器
|
||||
## 9.6 外部访问容器
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
容器运行在自己的隔离网络环境中 (通常是 Bridge 模式)。为了让外部网络访问容器内的服务，我们需要将容器的端口映射到宿主机的端口。
|
||||
|
||||
### 8.8.1 为什么要映射端口
|
||||
### 9.6.1 为什么要映射端口
|
||||
|
||||
容器运行在自己的隔离网络环境中 (通常是 Bridge 模式)。这意味着：
|
||||
容器的网络访问规则如下：
|
||||
|
||||
- **容器之间**：可以通过 IP 或容器名 (自定义网络) 互通。
|
||||
- **宿主机访问容器**：可以通过容器 IP 访问。
|
||||
@@ -21,16 +21,13 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 8.8.2 端口映射方式
|
||||
### 9.6.2 端口映射方式
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
Docker 提供了多种方式来指定端口映射。
|
||||
|
||||
#### 1。指定映射
|
||||
#### 1. 指定映射
|
||||
|
||||
Docker 提供了多种方式来指定端口映射，最常用的是 `-p` 参数。
|
||||
|
||||
|
||||
使用 `-p <宿主机端口>:<容器端口>` 格式。
|
||||
使用 `-p <宿主机端口>:<容器端口>` 格式：
|
||||
|
||||
```bash
|
||||
## 将宿主机的 8080 端口映射到容器的 80 端口
|
||||
@@ -49,12 +46,9 @@ $ docker run -d -p 8080:80 nginx
|
||||
| `hostPort:containerPort` | 绑定所有 IP (0.0.0.0) 的特定端口 | `-p 8080:80` (默认) |
|
||||
| `containerPort` | 绑定所有 IP 的随机端口 | `-p 80` |
|
||||
|
||||
#### 2。随机映射
|
||||
#### 2. 随机映射
|
||||
|
||||
如果您不关心宿主机使用哪个端口，可以使用随机映射功能。
|
||||
|
||||
|
||||
使用 `-P` (大写) 参数，Docker 会随机映射 Dockerfile 中 `EXPOSE` 指令暴露的所有端口到宿主机的高端口 (49000-49900)。
|
||||
如果不关心宿主机使用哪个端口，可以使用随机映射。使用 `-P` (大写) 参数，Docker 会随机映射 Dockerfile 中 `EXPOSE` 指令暴露的所有端口到宿主机的高端口 (49000-49900)。
|
||||
|
||||
```bash
|
||||
$ docker run -d -P nginx
|
||||
@@ -72,16 +66,13 @@ abc123456 0.0.0.0:49153->80/tcp
|
||||
|
||||
---
|
||||
|
||||
### 8.8.3 查看端口映射
|
||||
### 9.6.3 查看端口映射
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
可以使用以下命令查看容器的端口映射：
|
||||
|
||||
#### docker port
|
||||
|
||||
我们可以使用 `docker port` 命令来查看当前容器的端口映射规则。
|
||||
|
||||
|
||||
运行以下命令：
|
||||
运行 `docker port` 可以查看到指定容器的端口映射情况：
|
||||
|
||||
```bash
|
||||
$ docker port mycontainer
|
||||
@@ -91,7 +82,7 @@ $ docker port mycontainer
|
||||
|
||||
#### docker ps
|
||||
|
||||
运行以下命令：
|
||||
运行 `docker ps` 可以查看到所有容器的端口映射列表：
|
||||
|
||||
```bash
|
||||
$ docker ps
|
||||
@@ -101,14 +92,11 @@ abc123456 nginx 0.0.0.0:8080->80/tcp web
|
||||
|
||||
---
|
||||
|
||||
### 8.8.4 最佳实践与安全
|
||||
### 9.6.4 最佳实践与安全
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
#### 1。限制监听 IP
|
||||
|
||||
为了保证服务的安全性，我们应该谨慎选择绑定的 IP 地址。
|
||||
在配置端口映射时，需要注意以下安全事项：
|
||||
|
||||
#### 1. 限制监听 IP
|
||||
|
||||
默认情况下，`-p 8080:80` 会监听 `0.0.0.0:8080`，这意味着任何人只要能连接你的宿主机 IP，就能访问该服务。
|
||||
|
||||
@@ -120,7 +108,7 @@ abc123456 nginx 0.0.0.0:8080->80/tcp web
|
||||
$ docker run -d -p 127.0.0.1:3306:3306 mysql
|
||||
```
|
||||
|
||||
#### 2。避免端口冲突
|
||||
#### 2. 避免端口冲突
|
||||
|
||||
如果宿主机 8080 已经被占用了，容器将无法启动。
|
||||
|
||||
@@ -129,7 +117,7 @@ $ docker run -d -p 127.0.0.1:3306:3306 mysql
|
||||
- 更换宿主机端口：`-p 8081:80`
|
||||
- 让 Docker 自动分配：`-p 80`
|
||||
|
||||
#### 3。UDP 映射
|
||||
#### 3. UDP 映射
|
||||
|
||||
默认是 TCP 协议。如果要映射 UDP 服务 (如 DNS，Syslog)：
|
||||
|
||||
@@ -139,7 +127,7 @@ $ docker run -d -p 53:53/udp dns-server
|
||||
|
||||
---
|
||||
|
||||
### 8.8.5 实现原理
|
||||
### 9.6.5 实现原理
|
||||
|
||||
Docker 使用 `docker-proxy` 进程 (用户态) 或 `iptables` DNAT 规则 (内核态) 来实现端口转发。
|
||||
|
||||
24
09_network/summary.md
Normal file
24
09_network/summary.md
Normal file
@@ -0,0 +1,24 @@
|
||||
## 9.8 本章小结
|
||||
|
||||
本章介绍了 Docker 网络配置的各个方面：
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **DNS 配置** | 自定义网络支持嵌入式 DNS，可通过容器名解析 |
|
||||
| **网络类型** | bridge (默认)、host、none、overlay、macvlan |
|
||||
| **自定义网络** | 推荐使用，支持容器名 DNS 解析和更好的隔离 |
|
||||
| **容器互联** | 同一自定义网络内容器可直接通过容器名通信 |
|
||||
| **端口映射** | `-p 宿主机端口:容器端口` 暴露服务到外部 |
|
||||
| **网络隔离** | 不同网络默认隔离，增强安全性 |
|
||||
| **--link** | 已废弃，使用自定义网络替代 |
|
||||
|
||||
### 9.8.1 延伸阅读
|
||||
|
||||
- [配置 DNS](dns.md)：自定义 DNS 设置
|
||||
- [网络类型](network_types.md)：Bridge、Host、None 等网络模式
|
||||
- [自定义网络](custom_network.md)：创建和管理自定义网络
|
||||
- [容器互联](container_linking.md)：容器间通信方式
|
||||
- [端口映射](port_mapping.md)：高级端口配置
|
||||
- [网络隔离](network_isolation.md)：网络安全与隔离策略
|
||||
- [EXPOSE 指令](../07_dockerfile/7.9_expose.md)：在 Dockerfile 中声明端口
|
||||
- [Compose 网络](../11_compose/10.5_compose_file.md)：Compose 中的网络配置
|
||||
@@ -1,4 +1,4 @@
|
||||
## 9.1 使用 `BuildKit` 构建镜像
|
||||
## 10.1 使用 `BuildKit` 构建镜像
|
||||
|
||||
**BuildKit** 是下一代的镜像构建组件，在 https://github.com/moby/buildkit 开源。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
目前，Docker Hub 自动构建已经支持 BuildKit，具体请参考 https://github.com/docker-practice/docker-hub-buildx
|
||||
|
||||
### 9.1.1 `Dockerfile` 新增指令详解
|
||||
### 10.1.1 `Dockerfile` 新增指令详解
|
||||
|
||||
BuildKit 引入了多项新指令，旨在优化构建缓存和安全性。以下将详细介绍这些指令的用法。
|
||||
|
||||
@@ -159,12 +159,12 @@ $ ssh-add ~/.ssh/id_rsa
|
||||
$ docker build -t test --ssh default=$SSH_AUTH_SOCK .
|
||||
```
|
||||
|
||||
### 9.1.2 使用 `docker compose build` 与 BuildKit
|
||||
### 10.1.2 使用 `docker compose build` 与 BuildKit
|
||||
|
||||
Docker Compose 同样支持 BuildKit，这使得多服务应用的构建更加高效。
|
||||
|
||||
自 Docker 23.0 起，BuildKit 已默认启用，无需额外配置。如果使用旧版本，可设置 `DOCKER_BUILDKIT=1` 环境变量启用。
|
||||
|
||||
### 9.1.3 官方文档
|
||||
### 10.1.3 官方文档
|
||||
|
||||
* https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md
|
||||
@@ -1,8 +1,8 @@
|
||||
## 9.2 使用 Buildx 构建镜像
|
||||
## 10.2 使用 Buildx 构建镜像
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
### 9.2.1 使用
|
||||
### 10.2.1 使用
|
||||
|
||||
Buildx 的使用非常直观，绝大多数情况下可以替代 `docker build` 命令。
|
||||
|
||||
@@ -40,6 +40,6 @@ $ docker buildx build --sbom=true -t myimage .
|
||||
|
||||
该命令会在构建结果中包含 SPDX 或 CycloneDX 格式的 SBOM 数据。
|
||||
|
||||
### 9.2.2 官方文档
|
||||
### 10.2.2 官方文档
|
||||
|
||||
* https://docs.docker.com/engine/reference/commandline/buildx/
|
||||
@@ -1,8 +1,8 @@
|
||||
## 9.3 构建多种系统架构支持的 Docker 镜像
|
||||
## 10.3 构建多种系统架构支持的 Docker 镜像
|
||||
|
||||
Docker 镜像可以支持多种系统架构，这意味着你可以在 `x86_64`、`arm64` 等不同架构的机器上运行同一个镜像。这是通过一个名为 “manifest list” (或称为 “fat manifest”) 的文件来实现的。
|
||||
|
||||
### 9.3.1 Manifest List 是什么？
|
||||
### 10.3.1 Manifest List 是什么？
|
||||
|
||||
为了理解多架构镜像的原理，我们需要先了解 Manifest List 的概念。
|
||||
|
||||
@@ -40,7 +40,7 @@ $ docker manifest inspect hello-world
|
||||
}
|
||||
```
|
||||
|
||||
### 9.3.2 使用 `docker buildx` 构建多架构镜像
|
||||
### 10.3.2 使用 `docker buildx` 构建多架构镜像
|
||||
|
||||
`docker buildx` 是构建多架构镜像的最佳实践工具，它屏蔽了底层的复杂性，提供了一键构建多架构镜像的能力。
|
||||
|
||||
@@ -101,7 +101,7 @@ COPY bin/dist-${TARGETOS}-${TARGETARCH} /dist
|
||||
ENTRYPOINT ["/dist"]
|
||||
```
|
||||
|
||||
### 9.3.3 使用 `docker manifest` (底层工具)
|
||||
### 10.3.3 使用 `docker manifest` (底层工具)
|
||||
|
||||
除了 `docker buildx`，我们也可以直接操作 Manifest List 来手动组合不同架构的镜像。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 第九章 Docker Buildx
|
||||
# 第十章 Docker Buildx
|
||||
|
||||
Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持 [Moby BuildKit](9.1_buildkit.md) 提供的功能。提供了与 docker build 相同的用户体验，并增加了许多新功能。
|
||||
|
||||
19
10_buildx/summary.md
Normal file
19
10_buildx/summary.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## 10.4 本章小结
|
||||
|
||||
Docker Buildx 是 Docker 构建系统的重要进化，提供了高效、安全且支持多平台的镜像构建能力。
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **BuildKit** | 下一代构建引擎，Docker 23.0+ 默认启用 |
|
||||
| **缓存挂载** | `RUN --mount=type=cache` 加速依赖安装 |
|
||||
| **Secret 挂载** | `RUN --mount=type=secret` 安全传递密钥 |
|
||||
| **buildx build** | 替代 `docker build`，支持更多构建功能 |
|
||||
| **多架构构建** | `--platform` 参数一键构建多种架构镜像 |
|
||||
| **Manifest List** | 多架构镜像的索引文件 |
|
||||
| **SBOM** | 通过 `--sbom=true` 生成软件物料清单 |
|
||||
|
||||
### 10.4.1 延伸阅读
|
||||
|
||||
- [Dockerfile 指令详解](../07_dockerfile/README.md)：Dockerfile 编写基础
|
||||
- [多阶段构建](../07_dockerfile/7.17_multistage_builds.md)：优化镜像体积
|
||||
- [Dockerfile 最佳实践](../appendix/20.1_best_practices.md)：编写高效 Dockerfile
|
||||
@@ -1,4 +1,4 @@
|
||||
## 10.1 Compose 简介
|
||||
## 11.1 Compose 简介
|
||||
|
||||
`Compose` 项目是 Docker 官方的开源项目，负责实现对 Docker 容器集群的快速编排。从功能上看，跟 `OpenStack` 中的 `Heat` 十分类似。
|
||||
|
||||
@@ -10,11 +10,11 @@
|
||||
|
||||
`Compose` 恰好满足了这样的需求。它允许用户通过一个单独的 `compose.yaml` (历史默认名也常见为 `docker-compose.yml`) 模板文件 (YAML 格式) 来定义一组相关联的应用容器为一个项目 (project)。
|
||||
|
||||
### 10.1.1 概述
|
||||
### 11.1.1 概述
|
||||
|
||||
总体概述了以下内容。
|
||||
|
||||
### 10.1.2 模板文件规范
|
||||
### 11.1.2 模板文件规范
|
||||
|
||||
Compose 模板文件采用 YAML 格式，扩展名为 `.yml` 或 `.yaml`。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 10.2 安装与卸载
|
||||
## 11.2 安装与卸载
|
||||
|
||||
`Compose` 是 Docker 官方的开源项目，负责实现对 Docker 容器集群的快速编排。
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
Linux 系统请使用以下介绍的方法安装。
|
||||
|
||||
### 10.2.1 Linux
|
||||
### 11.2.1 Linux
|
||||
|
||||
在 Linux 上，你可以通过下载 Docker Compose CLI 插件 (二进制文件名为 `docker-compose`) 来安装。
|
||||
|
||||
@@ -32,7 +32,7 @@ $ curl -SL https://github.com/docker/compose/releases/download/v5.0.2/docker-com
|
||||
$ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
|
||||
```
|
||||
|
||||
### 10.2.2 测试安装
|
||||
### 11.2.2 测试安装
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -41,7 +41,7 @@ $ docker compose version
|
||||
Docker Compose version v5.0.2
|
||||
```
|
||||
|
||||
### 10.2.3 bash 补全命令
|
||||
### 11.2.3 bash 补全命令
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -49,7 +49,7 @@ Docker Compose version v5.0.2
|
||||
$ curl -L https://raw.githubusercontent.com/docker/compose/v5.0.2/contrib/completion/bash/docker-compose | sudo tee /etc/bash_completion.d/docker-compose > /dev/null
|
||||
```
|
||||
|
||||
### 10.2.4 卸载
|
||||
### 11.2.4 卸载
|
||||
|
||||
如果是二进制包方式安装的，删除二进制文件即可。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 10.3 使用
|
||||
## 11.3 使用
|
||||
|
||||
本节将通过一个具体的 Web 应用案例，介绍 Docker Compose 的基本概念和使用方法。
|
||||
|
||||
### 10.3.1 术语
|
||||
### 11.3.1 术语
|
||||
|
||||
首先介绍几个术语。
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
可见，一个项目可以由多个服务 (容器) 关联而成，`Compose` 面向项目进行管理。
|
||||
|
||||
### 10.3.2 场景
|
||||
### 11.3.2 场景
|
||||
|
||||
最常见的项目是 web 网站，该项目应该包含 web 应用和缓存。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 10.4 Compose 命令说明
|
||||
## 11.4 Compose 命令说明
|
||||
|
||||
Docker Compose 提供了丰富的命令来管理项目和容器。本节将详细介绍这些命令的使用格式和常用选项。
|
||||
|
||||
### 10.4.1 命令对象与格式
|
||||
### 11.4.1 命令对象与格式
|
||||
|
||||
对于 Compose 来说，大部分命令的对象既可以是项目本身，也可以指定为项目中的服务或者容器。如果没有特别的说明，命令对象将是项目，这意味着项目中所有的服务都会受到命令影响。
|
||||
|
||||
@@ -14,7 +14,7 @@ Docker Compose 提供了丰富的命令来管理项目和容器。本节将详
|
||||
docker compose [-f=<arg>...] [options] [COMMAND] [ARGS...]
|
||||
```
|
||||
|
||||
### 10.4.2 命令选项
|
||||
### 11.4.2 命令选项
|
||||
|
||||
* `-f, --file FILE` 指定使用的 Compose 模板文件。默认会自动识别 `compose.yaml` (也兼容 `docker-compose.yml` 等)，并且可以多次指定。
|
||||
|
||||
@@ -24,7 +24,7 @@ docker compose [-f=<arg>...] [options] [COMMAND] [ARGS...]
|
||||
|
||||
* `-v, --version` 打印版本并退出。
|
||||
|
||||
### 10.4.3 命令使用说明
|
||||
### 11.4.3 命令使用说明
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 10.5 Compose 模板文件
|
||||
## 11.5 Compose 模板文件
|
||||
|
||||
模板文件是使用 `Compose` 的核心，涉及到的指令关键字也比较多。但大家不用担心，这里面大部分指令跟 `docker run` 相关参数的含义都是类似的。
|
||||
|
||||
@@ -20,7 +20,7 @@ services:
|
||||
|
||||
下面分别介绍各个指令的用法。
|
||||
|
||||
### 10.5.1 `build`
|
||||
### 11.5.1 `build`
|
||||
|
||||
指定 `Dockerfile` 所在文件夹的路径 (可以是绝对路径，或者相对 Compose 文件的路径)。`Compose` 将会利用它自动构建这个镜像，然后使用这个镜像。
|
||||
|
||||
@@ -56,7 +56,7 @@ build:
|
||||
- corp/web_app:3.14
|
||||
```
|
||||
|
||||
### 10.5.2 `cap_add, cap_drop`
|
||||
### 11.5.2 `cap_add, cap_drop`
|
||||
|
||||
指定容器的内核能力 (capacity) 分配。
|
||||
|
||||
@@ -74,7 +74,7 @@ cap_drop:
|
||||
- NET_ADMIN
|
||||
```
|
||||
|
||||
### 10.5.3 `command`
|
||||
### 11.5.3 `command`
|
||||
|
||||
覆盖容器启动后默认执行的命令。
|
||||
|
||||
@@ -82,11 +82,11 @@ cap_drop:
|
||||
command: echo "hello world"
|
||||
```
|
||||
|
||||
### 10.5.4 `configs`
|
||||
### 11.5.4 `configs`
|
||||
|
||||
`configs` 来自 Compose Specification。它在 Swarm 中是原生对象；在本地 `docker compose` 模式下通常以文件挂载的形式实现，具体能力取决于 Compose 版本与运行平台。
|
||||
|
||||
### 10.5.5 `cgroup_parent`
|
||||
### 11.5.5 `cgroup_parent`
|
||||
|
||||
指定父 `cgroup` 组，意味着将继承该组的资源限制。
|
||||
|
||||
@@ -96,7 +96,7 @@ command: echo "hello world"
|
||||
cgroup_parent: cgroups_1
|
||||
```
|
||||
|
||||
### 10.5.6 `container_name`
|
||||
### 11.5.6 `container_name`
|
||||
|
||||
指定容器名称。默认将会使用 `项目名称_服务名称_序号` 这样的格式。
|
||||
|
||||
@@ -106,11 +106,11 @@ container_name: docker-web-container
|
||||
|
||||
>注意：指定容器名称后，该服务将无法进行扩展 (scale)，因为 Docker 不允许多个容器具有相同的名称。
|
||||
|
||||
### 10.5.7 `deploy`
|
||||
### 11.5.7 `deploy`
|
||||
|
||||
`deploy` 用于描述副本数、更新策略、资源限制等部署参数。该字段在 Swarm 中支持最完整；在本地 `docker compose up` 场景下通常只有部分字段生效。
|
||||
|
||||
### 10.5.8 `devices`
|
||||
### 11.5.8 `devices`
|
||||
|
||||
指定设备映射关系。
|
||||
|
||||
@@ -119,7 +119,7 @@ devices:
|
||||
- "/dev/ttyUSB1:/dev/ttyUSB0"
|
||||
```
|
||||
|
||||
### 10.5.9 `depends_on`
|
||||
### 11.5.9 `depends_on`
|
||||
|
||||
解决容器的依赖、启动先后的问题。以下例子中会先启动 `redis` `db` 再启动 `web`
|
||||
|
||||
@@ -140,7 +140,7 @@ services:
|
||||
|
||||
>注意：`web` 服务不会等待 `redis` `db` “完全启动” 之后才启动。
|
||||
|
||||
### 10.5.10 `dns`
|
||||
### 11.5.10 `dns`
|
||||
|
||||
自定义 `DNS` 服务器。可以是一个值，也可以是一个列表。
|
||||
|
||||
@@ -152,7 +152,7 @@ dns:
|
||||
- 114.114.114.114
|
||||
```
|
||||
|
||||
### 10.5.11 `dns_search`
|
||||
### 11.5.11 `dns_search`
|
||||
|
||||
配置 `DNS` 搜索域。可以是一个值，也可以是一个列表。
|
||||
|
||||
@@ -164,7 +164,7 @@ dns_search:
|
||||
- domain2.example.com
|
||||
```
|
||||
|
||||
### 10.5.12 `tmpfs`
|
||||
### 11.5.12 `tmpfs`
|
||||
|
||||
挂载一个 tmpfs 文件系统到容器。
|
||||
|
||||
@@ -175,7 +175,7 @@ tmpfs:
|
||||
- /tmp
|
||||
```
|
||||
|
||||
### 10.5.13 `env_file`
|
||||
### 11.5.13 `env_file`
|
||||
|
||||
从文件中获取环境变量，可以为单独的文件路径或列表。
|
||||
|
||||
@@ -200,7 +200,7 @@ env_file:
|
||||
PROG_ENV=development
|
||||
```
|
||||
|
||||
### 10.5.14 `environment`
|
||||
### 11.5.14 `environment`
|
||||
|
||||
设置环境变量。你可以使用数组或字典两种格式。
|
||||
|
||||
@@ -222,7 +222,7 @@ environment:
|
||||
y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
|
||||
```
|
||||
|
||||
### 10.5.15 `expose`
|
||||
### 11.5.15 `expose`
|
||||
|
||||
暴露端口，但不映射到宿主机，只被连接的服务访问。
|
||||
|
||||
@@ -234,7 +234,7 @@ expose:
|
||||
- "8000"
|
||||
```
|
||||
|
||||
### 10.5.16 `external_links`
|
||||
### 11.5.16 `external_links`
|
||||
|
||||
>注意：不建议使用该指令。
|
||||
|
||||
@@ -247,7 +247,7 @@ external_links:
|
||||
- project_db_1:postgresql
|
||||
```
|
||||
|
||||
### 10.5.17 `extra_hosts`
|
||||
### 11.5.17 `extra_hosts`
|
||||
|
||||
类似 Docker 中的 `--add-host` 参数，指定额外的 host 名称映射信息。
|
||||
|
||||
@@ -264,7 +264,7 @@ extra_hosts:
|
||||
52.1.157.61 dockerhub
|
||||
```
|
||||
|
||||
### 10.5.18 `healthcheck`
|
||||
### 11.5.18 `healthcheck`
|
||||
|
||||
通过命令检查容器是否健康运行。
|
||||
|
||||
@@ -276,7 +276,7 @@ healthcheck:
|
||||
retries: 3
|
||||
```
|
||||
|
||||
### 10.5.19 `image`
|
||||
### 11.5.19 `image`
|
||||
|
||||
指定为镜像名称或镜像 ID。如果镜像在本地不存在，`Compose` 将会尝试拉取这个镜像。
|
||||
|
||||
@@ -286,7 +286,7 @@ image: orchardup/postgresql
|
||||
image: a4bc65fd
|
||||
```
|
||||
|
||||
### 10.5.20 `labels`
|
||||
### 11.5.20 `labels`
|
||||
|
||||
为容器添加 Docker 元数据 (metadata) 信息。例如可以为容器添加辅助说明信息。
|
||||
|
||||
@@ -297,11 +297,11 @@ labels:
|
||||
com.startupteam.release: "rc3 for v1.0"
|
||||
```
|
||||
|
||||
### 10.5.21 `links`
|
||||
### 11.5.21 `links`
|
||||
|
||||
>注意：不推荐使用该指令。容器之间应通过 Docker 网络 (networks) 进行互联。
|
||||
|
||||
### 10.5.22 `logging`
|
||||
### 11.5.22 `logging`
|
||||
|
||||
配置日志选项。
|
||||
|
||||
@@ -328,7 +328,7 @@ options:
|
||||
max-file: "10"
|
||||
```
|
||||
|
||||
### 10.5.23 `network_mode`
|
||||
### 11.5.23 `network_mode`
|
||||
|
||||
设置网络模式。使用和 `docker run` 的 `--network` 参数一样的值。
|
||||
|
||||
@@ -340,7 +340,7 @@ network_mode: "service:[service name]"
|
||||
network_mode: "container:[container name/id]"
|
||||
```
|
||||
|
||||
### 10.5.24 `networks`
|
||||
### 11.5.24 `networks`
|
||||
|
||||
配置容器连接的网络。
|
||||
|
||||
@@ -358,7 +358,7 @@ networks:
|
||||
other-network:
|
||||
```
|
||||
|
||||
### 10.5.25 `pid`
|
||||
### 11.5.25 `pid`
|
||||
|
||||
跟主机系统共享进程命名空间。打开该选项的容器之间，以及容器和宿主机系统之间可以通过进程 ID 来相互访问和操作。
|
||||
|
||||
@@ -366,7 +366,7 @@ networks:
|
||||
pid: "host"
|
||||
```
|
||||
|
||||
### 10.5.26 `ports`
|
||||
### 11.5.26 `ports`
|
||||
|
||||
暴露端口信息。
|
||||
|
||||
@@ -382,7 +382,7 @@ ports:
|
||||
|
||||
*注意：当使用 `HOST:CONTAINER` 格式来映射端口时，如果你使用的容器端口小于 60 并且没放到引号里，可能会得到错误结果，因为 `YAML` 会自动解析 `xx:yy` 这种数字格式为 60 进制。为避免出现这种问题，建议数字串都采用引号包括起来的字符串格式。*
|
||||
|
||||
### 10.5.27 `secrets`
|
||||
### 11.5.27 `secrets`
|
||||
|
||||
存储敏感数据，例如 `mysql` 服务密码。
|
||||
|
||||
@@ -405,7 +405,7 @@ secrets:
|
||||
external: true
|
||||
```
|
||||
|
||||
### 10.5.28 `security_opt`
|
||||
### 11.5.28 `security_opt`
|
||||
|
||||
指定容器模板标签 (label) 机制的默认属性 (用户、角色、类型、级别等)。例如配置标签的用户名和角色名。
|
||||
|
||||
@@ -415,7 +415,7 @@ security_opt:
|
||||
- label:role:ROLE
|
||||
```
|
||||
|
||||
### 10.5.29 `stop_signal`
|
||||
### 11.5.29 `stop_signal`
|
||||
|
||||
设置另一个信号来停止容器。在默认情况下使用的是 SIGTERM 停止容器。
|
||||
|
||||
@@ -423,7 +423,7 @@ security_opt:
|
||||
stop_signal: SIGUSR1
|
||||
```
|
||||
|
||||
### 10.5.30 `sysctls`
|
||||
### 11.5.30 `sysctls`
|
||||
|
||||
配置容器内核参数。
|
||||
|
||||
@@ -437,7 +437,7 @@ sysctls:
|
||||
- net.ipv4.tcp_syncookies=0
|
||||
```
|
||||
|
||||
### 10.5.31 `ulimits`
|
||||
### 11.5.31 `ulimits`
|
||||
|
||||
指定容器的 ulimits 限制值。
|
||||
|
||||
@@ -451,7 +451,7 @@ sysctls:
|
||||
hard: 40000
|
||||
```
|
||||
|
||||
### 10.5.32 `volumes`
|
||||
### 11.5.32 `volumes`
|
||||
|
||||
数据卷所挂载路径设置。可以设置为宿主机路径 (`HOST:CONTAINER`) 或者数据卷名称 (`VOLUME:CONTAINER`)，并且可以设置访问模式 (`HOST:CONTAINER:ro`)。
|
||||
|
||||
@@ -477,7 +477,7 @@ volumes:
|
||||
mysql_data:
|
||||
```
|
||||
|
||||
### 10.5.33 其它指令
|
||||
### 11.5.33 其它指令
|
||||
|
||||
此外，还有包括 `domainname, entrypoint, hostname, ipc, mac_address, privileged, read_only, shm_size, restart, stdin_open, tty, user, working_dir` 等指令，基本跟 `docker run` 中对应参数的功能一致。
|
||||
|
||||
@@ -537,7 +537,7 @@ stdin_open: true
|
||||
tty: true
|
||||
```
|
||||
|
||||
### 10.5.34 读取变量
|
||||
### 11.5.34 读取变量
|
||||
|
||||
Compose 模板文件支持动态读取主机的系统环境变量和当前目录下的 `.env` 文件中的变量。
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
## 10.6 使用 Django
|
||||
## 11.6 使用 Django
|
||||
|
||||
> 本小节内容适合 `Python` 开发人员阅读。
|
||||
|
||||
本节将使用 Docker Compose 配置并运行一个 **Django + PostgreSQL** 应用。笔者不仅会介绍具体步骤，还会解释每个配置项的作用，以及开发环境和生产环境的差异。
|
||||
|
||||
### 10.6.1 架构概览
|
||||
### 11.6.1 架构概览
|
||||
|
||||
在开始之前，先看整体架构 (如图 10-1 所示)：
|
||||
|
||||
@@ -40,7 +40,7 @@ flowchart TD
|
||||
- 两个服务通过 Docker Compose 自动创建的网络相互通信
|
||||
- `web` 服务可以通过服务名 `db` 访问数据库 (Docker 内置 DNS)
|
||||
|
||||
### 10.6.2 准备工作
|
||||
### 11.6.2 准备工作
|
||||
|
||||
创建一个项目目录并进入：
|
||||
|
||||
@@ -50,7 +50,7 @@ $ mkdir django-docker && cd django-docker
|
||||
|
||||
我们需要创建三个文件：`Dockerfile`、`requirements.txt` 和 `compose.yaml`。
|
||||
|
||||
### 10.6.3 步骤 1：创建 Dockerfile
|
||||
### 11.6.3 步骤 1：创建 Dockerfile
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
@@ -90,7 +90,7 @@ COPY . /code/
|
||||
|
||||
> 💡 **笔者建议**：总是将变化频率低的文件先复制，变化频率高的后复制。这样可以最大化利用 Docker 的构建缓存。
|
||||
|
||||
### 10.6.4 步骤 2：创建 requirements.txt
|
||||
### 11.6.4 步骤 2：创建 requirements.txt
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
@@ -108,7 +108,7 @@ gunicorn>=21.0,<22.0
|
||||
| `psycopg[binary]` | PostgreSQL 数据库驱动 (推荐使用 psycopg 3)|
|
||||
| `gunicorn` | 生产环境 WSGI 服务器 (可选，开发时可不用)|
|
||||
|
||||
### 10.6.5 步骤 3：创建 compose.yaml
|
||||
### 11.6.5 步骤 3：创建 compose.yaml
|
||||
|
||||
配置如下：
|
||||
|
||||
@@ -192,7 +192,7 @@ web:
|
||||
| `depends_on` + `healthcheck` | 启动顺序 | 确保数据库就绪后 Django 才启动，避免连接错误 |
|
||||
| `environment` | 环境变量 | 推荐用环境变量管理配置，避免硬编码 |
|
||||
|
||||
### 10.6.6 步骤 4：创建 Django 项目
|
||||
### 11.6.6 步骤 4：创建 Django 项目
|
||||
|
||||
运行以下命令创建新的 Django 项目：
|
||||
|
||||
@@ -225,7 +225,7 @@ django-docker/
|
||||
|
||||
> 💡 **Linux 用户注意**：如果遇到权限问题，执行 `sudo chown -R $USER:$USER .`
|
||||
|
||||
### 10.6.7 步骤 5：配置数据库连接
|
||||
### 11.6.7 步骤 5：配置数据库连接
|
||||
|
||||
修改 `mysite/settings.py`，配置数据库连接：
|
||||
|
||||
@@ -252,7 +252,7 @@ ALLOWED_HOSTS = ['*']
|
||||
|
||||
在 Docker Compose 中，各服务通过服务名相互访问。Docker 内置的 DNS 会将 `db` 解析为 db 服务容器的 IP 地址。这是 Docker Compose 的核心功能之一。
|
||||
|
||||
### 10.6.8 步骤 6：启动应用
|
||||
### 11.6.8 步骤 6：启动应用
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -275,7 +275,7 @@ web-1 | Starting development server at http://0.0.0.0:8000/
|
||||
|
||||
打开浏览器访问 http://localhost:8000，可以看到 Django 欢迎页面！
|
||||
|
||||
### 10.6.9 常用开发命令
|
||||
### 11.6.9 常用开发命令
|
||||
|
||||
在另一个终端窗口执行：
|
||||
|
||||
@@ -299,7 +299,7 @@ $ docker compose exec db psql -U django_user -d django_db
|
||||
|
||||
> 💡 笔者建议使用 `exec` 而不是 `run`。`exec` 在已运行的容器中执行命令，`run` 会创建新容器。
|
||||
|
||||
### 10.6.10 常见问题排查
|
||||
### 11.6.10 常见问题排查
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -338,7 +338,7 @@ $ docker compose logs db
|
||||
$ sudo chown -R $USER:$USER .
|
||||
```
|
||||
|
||||
### 10.6.11 开发 vs 生产：关键差异
|
||||
### 11.6.11 开发 vs 生产：关键差异
|
||||
|
||||
笔者特别提醒，本节的配置是 **开发环境** 配置。生产环境需要以下调整：
|
||||
|
||||
@@ -366,7 +366,7 @@ services:
|
||||
|
||||
```
|
||||
|
||||
### 10.6.12 延伸阅读
|
||||
### 11.6.12 延伸阅读
|
||||
|
||||
- [Compose 模板文件详解](10.5_compose_file.md)：深入理解 Compose 文件的所有配置项
|
||||
- [使用 WordPress](10.8_wordpress.md)：另一个 Compose 实战案例
|
||||
@@ -1,10 +1,10 @@
|
||||
## 10.7 使用 Rails
|
||||
## 11.7 使用 Rails
|
||||
|
||||
> 本小节内容适合 Ruby 开发人员阅读。
|
||||
|
||||
本节使用 Docker Compose 配置并运行一个 **Rails + PostgreSQL** 应用。
|
||||
|
||||
### 10.7.1 架构概览
|
||||
### 11.7.1 架构概览
|
||||
|
||||
如图 10-2 所示，Rails 与 PostgreSQL 在同一 Compose 网络中协同工作。
|
||||
|
||||
@@ -33,7 +33,7 @@ flowchart TD
|
||||
|
||||
图 10-2 Rails + PostgreSQL 的 Compose 架构
|
||||
|
||||
### 10.7.2 准备工作
|
||||
### 11.7.2 准备工作
|
||||
|
||||
创建项目目录：
|
||||
|
||||
@@ -43,7 +43,7 @@ $ mkdir rails-docker && cd rails-docker
|
||||
|
||||
需要创建三个文件：`Dockerfile`、`Gemfile` 和 `compose.yaml`。
|
||||
|
||||
### 10.7.3 步骤 1：创建 Dockerfile
|
||||
### 11.7.3 步骤 1：创建 Dockerfile
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
@@ -80,7 +80,7 @@ COPY . /myapp
|
||||
| `nodejs` | Rails Asset Pipeline 需要 |
|
||||
| 先复制 Gemfile | 只有依赖变化时才重新 `bundle install` |
|
||||
|
||||
### 10.7.4 步骤 2：创建 Gemfile
|
||||
### 11.7.4 步骤 2：创建 Gemfile
|
||||
|
||||
创建一个初始的 `Gemfile`，稍后会被 `rails new` 覆盖：
|
||||
|
||||
@@ -95,7 +95,7 @@ gem 'rails', '~> 7.1'
|
||||
$ touch Gemfile.lock
|
||||
```
|
||||
|
||||
### 10.7.5 步骤 3：创建 compose.yaml
|
||||
### 11.7.5 步骤 3：创建 compose.yaml
|
||||
|
||||
配置如下：
|
||||
|
||||
@@ -133,7 +133,7 @@ volumes:
|
||||
| `depends_on: db` | 确保数据库先启动 |
|
||||
| `DATABASE_URL` | Rails 12-factor 风格的数据库配置 |
|
||||
|
||||
### 10.7.6 步骤 4：生成 Rails 项目
|
||||
### 11.7.6 步骤 4：生成 Rails 项目
|
||||
|
||||
使用 `docker compose run` 生成项目骨架：
|
||||
|
||||
@@ -160,7 +160,7 @@ compose.yaml bin db public
|
||||
|
||||
> ⚠️ **Linux 用户**：如遇权限问题，执行 `sudo chown -R $USER:$USER .`
|
||||
|
||||
### 10.7.7 步骤 5：重新构建镜像
|
||||
### 11.7.7 步骤 5：重新构建镜像
|
||||
|
||||
由于生成了新的 Gemfile，需要重新构建镜像以安装完整依赖：
|
||||
|
||||
@@ -168,7 +168,7 @@ compose.yaml bin db public
|
||||
$ docker compose build
|
||||
```
|
||||
|
||||
### 10.7.8 步骤 6：配置数据库连接
|
||||
### 11.7.8 步骤 6：配置数据库连接
|
||||
|
||||
修改 `config/database.yml`：
|
||||
|
||||
@@ -192,7 +192,7 @@ production:
|
||||
|
||||
> 💡 使用 `DATABASE_URL` 环境变量配置数据库，符合 12-factor 应用原则，便于在不同环境间切换。
|
||||
|
||||
### 10.7.9 步骤 7：启动应用
|
||||
### 11.7.9 步骤 7：启动应用
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -212,7 +212,7 @@ web-1 | Puma starting in single mode...
|
||||
web-1 | * Listening on http://0.0.0.0:3000
|
||||
```
|
||||
|
||||
### 10.7.10 步骤 8：创建数据库
|
||||
### 11.7.10 步骤 8：创建数据库
|
||||
|
||||
在另一个终端执行：
|
||||
|
||||
@@ -224,7 +224,7 @@ Created database 'myapp_test'
|
||||
|
||||
访问 http://localhost:3000 查看 Rails 欢迎页面。
|
||||
|
||||
### 10.7.11 常用开发命令
|
||||
### 11.7.11 常用开发命令
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -250,7 +250,7 @@ $ docker compose exec web rails generate scaffold Post title:string body:text
|
||||
$ docker compose exec web bash
|
||||
```
|
||||
|
||||
### 10.7.12 常见问题
|
||||
### 11.7.12 常见问题
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -281,7 +281,7 @@ $ docker compose exec web rm -f tmp/pids/server.pid
|
||||
$ docker compose run --rm web bundle update
|
||||
```
|
||||
|
||||
### 10.7.13 开发 vs 生产
|
||||
### 11.7.13 开发 vs 生产
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -292,7 +292,7 @@ $ docker compose run --rm web bundle update
|
||||
| 静态资源 | 动态编译 | 预编译 (`rails assets:precompile`) |
|
||||
| 数据库密码 | 明文配置 | 使用 Secrets 管理 |
|
||||
|
||||
### 10.7.14 延伸阅读
|
||||
### 11.7.14 延伸阅读
|
||||
|
||||
- [使用 Django](10.6_django.md)：Python Web 框架实战
|
||||
- [Compose 模板文件](10.5_compose_file.md)：配置详解
|
||||
@@ -1,10 +1,10 @@
|
||||
## 10.8 实战 WordPress
|
||||
## 11.8 实战 WordPress
|
||||
|
||||
WordPress 是全球最流行的内容管理系统 (CMS)。使用 Docker Compose 可以在几分钟内搭建一个包含数据库、Web 服务和持久化存储的生产级 WordPress 环境。
|
||||
|
||||
---
|
||||
|
||||
### 10.8.1 项目结构
|
||||
### 11.8.1 项目结构
|
||||
|
||||
如下代码块所示，展示了相关示例：
|
||||
|
||||
@@ -18,7 +18,7 @@ wordpress/
|
||||
|
||||
---
|
||||
|
||||
### 10.8.2 编写 `compose.yaml`
|
||||
### 11.8.2 编写 `compose.yaml`
|
||||
|
||||
这是一个生产可用的最小化配置：
|
||||
|
||||
@@ -79,7 +79,7 @@ networks:
|
||||
|
||||
---
|
||||
|
||||
### 10.8.3 配置文件详解
|
||||
### 11.8.3 配置文件详解
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -115,7 +115,7 @@ max_execution_time = 600
|
||||
|
||||
---
|
||||
|
||||
### 10.8.4 启动与运行
|
||||
### 11.8.4 启动与运行
|
||||
|
||||
1. 启动服务：
|
||||
|
||||
@@ -134,7 +134,7 @@ $ docker compose logs -f
|
||||
|
||||
---
|
||||
|
||||
### 10.8.5 生产环境最佳实践
|
||||
### 11.8.5 生产环境最佳实践
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -192,7 +192,7 @@ WordPress 支持 Redis 缓存以提高性能。
|
||||
|
||||
---
|
||||
|
||||
### 10.8.6 常见问题
|
||||
### 11.8.6 常见问题
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -214,7 +214,7 @@ $ docker compose restart wordpress
|
||||
|
||||
---
|
||||
|
||||
### 10.8.7 延伸阅读
|
||||
### 11.8.7 延伸阅读
|
||||
|
||||
- [Compose 模板文件](10.5_compose_file.md)：深入了解配置项
|
||||
- [数据卷](../08_data_network/data/volume.md)：理解数据持久化
|
||||
@@ -1,3 +1,3 @@
|
||||
## 10.9 使用 Compose 搭建 LNMP 环境
|
||||
## 11.9 使用 Compose 搭建 LNMP 环境
|
||||
|
||||
本项目的维护者 [khs1994](https://github.com/khs1994) 的开源项目 [khs1994-docker/lnmp](https://github.com/khs1994-docker/lnmp) 使用 Docker Compose 搭建了一套 LNMP 环境，各位开发者可以参考该项目在 Docker 或 Kubernetes 中运行 LNMP。
|
||||
@@ -1,4 +1,4 @@
|
||||
# 第十章 Docker Compose
|
||||
# 第十一章 Docker Compose
|
||||
|
||||
`Docker Compose` 是 Docker 官方编排 (Orchestration) 项目之一，负责快速的部署分布式应用。
|
||||
|
||||
21
11_compose/summary.md
Normal file
21
11_compose/summary.md
Normal file
@@ -0,0 +1,21 @@
|
||||
## 11.10 本章小结
|
||||
|
||||
Docker Compose 是管理多容器应用的利器，通过 YAML 文件声明式地定义服务、网络和数据卷。
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **核心概念** | 服务 (service) 和项目 (project) |
|
||||
| **配置文件** | `compose.yaml` (推荐) 或 `docker-compose.yml` |
|
||||
| **版本** | Compose V2 为 Go 编写的 CLI 插件，通过 `docker compose` 使用 |
|
||||
| **启动** | `docker compose up -d` 启动所有服务 |
|
||||
| **停止** | `docker compose down` 停止并移除容器 |
|
||||
| **查看状态** | `docker compose ps` 查看服务状态 |
|
||||
| **查看日志** | `docker compose logs` 查看服务日志 |
|
||||
| **模板文件** | 支持 `services`、`networks`、`volumes` 等顶级配置 |
|
||||
|
||||
### 11.10.1 延伸阅读
|
||||
|
||||
- [Compose 模板文件](10.5_compose_file.md)：详细模板语法参考
|
||||
- [Compose 命令说明](10.4_commands.md)：完整命令列表
|
||||
- [网络配置](../09_network/README.md)：Docker 网络基础
|
||||
- [数据管理](../08_data/README.md)：数据卷管理
|
||||
@@ -1,8 +1,8 @@
|
||||
## 11.1 基本架构
|
||||
## 12.1 基本架构
|
||||
|
||||
Docker 的架构设计简洁而高效，主要由客户端和服务端两部分组成。
|
||||
|
||||
### 11.1.1 核心架构图
|
||||
### 12.1.1 核心架构图
|
||||
|
||||
Docker 采用了 **C/S (客户端/服务端)** 架构。Client 向 Daemon 发送请求，Daemon 负责构建、运行和分发容器。
|
||||
|
||||
@@ -23,7 +23,7 @@ graph LR
|
||||
|
||||
---
|
||||
|
||||
### 11.1.2 组件详解
|
||||
### 12.1.2 组件详解
|
||||
|
||||
Docker 的内部架构如同洋葱一样分层，每一层专注解决特定问题：
|
||||
|
||||
@@ -66,7 +66,7 @@ Docker 的大脑。
|
||||
|
||||
---
|
||||
|
||||
### 11.1.3 容器启动流程
|
||||
### 12.1.3 容器启动流程
|
||||
|
||||
当执行 `docker run -d nginx` 时，内部发生了什么？
|
||||
|
||||
@@ -110,7 +110,7 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 11.1.4 Docker Engine v29+ 变化
|
||||
### 12.1.4 Docker Engine v29+ 变化
|
||||
|
||||
从 Docker Engine v29 (2025/2026) 开始，架构进一步简化和标准化：
|
||||
|
||||
@@ -119,7 +119,7 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 11.1.5 Docker Desktop 架构
|
||||
### 12.1.5 Docker Desktop 架构
|
||||
|
||||
在 macOS 和 Windows 上，因为内核差异，架构稍微复杂：
|
||||
|
||||
@@ -140,7 +140,7 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 11.1.6 总结
|
||||
### 12.1.6 总结
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -152,7 +152,7 @@ flowchart TD
|
||||
| **Shim** | 监工 | 保持 IO，允许无守护进程重启 |
|
||||
| **Runc** | 工人 | 真正干活 (创建容器)，干完就走 |
|
||||
|
||||
### 11.1.7 延伸阅读
|
||||
### 12.1.7 延伸阅读
|
||||
|
||||
- [命名空间](./11.2_namespace.md)：Runc 如何隔离容器
|
||||
- [控制组](./11.3_cgroups.md)：Runc 如何限制资源
|
||||
@@ -1,6 +1,6 @@
|
||||
命名空间 (Namespace) 是 Linux 内核的一个强大特性，为容器提供了隔离的运行环境。
|
||||
|
||||
## 11.2 什么是 Namespace
|
||||
## 12.2 什么是 Namespace
|
||||
|
||||
> **Namespace 是 Linux 内核提供的资源隔离机制，它让容器内的进程仿佛运行在独立的操作系统中。** Namespace 是容器技术的核心基础之一。它回答了一个关键问题：**如何让一个进程 “以为” 自己独占整个系统？**
|
||||
|
||||
@@ -24,7 +24,7 @@ flowchart LR
|
||||
H4 -. "（实际是宿主机的 1234）" .- C1
|
||||
```
|
||||
|
||||
### 11.2.1 Namespace 的类型
|
||||
### 12.2.1 Namespace 的类型
|
||||
|
||||
Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
|
||||
|
||||
@@ -40,7 +40,7 @@ Linux 内核提供了以下几种 Namespace，Docker 容器使用了全部：
|
||||
|
||||
---
|
||||
|
||||
### 11.2.2 PID Namespace
|
||||
### 12.2.2 PID Namespace
|
||||
|
||||
PID Namespace 负责进程 ID 的隔离，使得容器内的进程彼此不可见。
|
||||
|
||||
@@ -75,7 +75,7 @@ PID USER COMMAND
|
||||
|
||||
---
|
||||
|
||||
### 11.2.3 NET Namespace
|
||||
### 12.2.3 NET Namespace
|
||||
|
||||
NET Namespace 负责网络栈的隔离，包括网卡、路由表和 iptables 规则等。
|
||||
|
||||
@@ -112,7 +112,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.2.4 MNT Namespace
|
||||
### 12.2.4 MNT Namespace
|
||||
|
||||
MNT Namespace 负责文件系统挂载点的隔离，确保容器看到独立的文件系统视图。
|
||||
|
||||
@@ -149,7 +149,7 @@ MNT Namespace 负责文件系统挂载点的隔离，确保容器看到独立的
|
||||
|
||||
---
|
||||
|
||||
### 11.2.5 UTS Namespace
|
||||
### 12.2.5 UTS Namespace
|
||||
|
||||
UTS Namespace 主要用于隔离主机名和域名。
|
||||
|
||||
@@ -177,7 +177,7 @@ UTS = “UNIX Time-sharing System”，是历史遗留的名称。
|
||||
|
||||
---
|
||||
|
||||
### 11.2.6 IPC Namespace
|
||||
### 12.2.6 IPC Namespace
|
||||
|
||||
IPC Namespace 用于隔离进程间通信资源，如 System V IPC 和 POSIX 消息队列。
|
||||
|
||||
@@ -198,7 +198,7 @@ IPC Namespace 用于隔离进程间通信资源，如 System V IPC 和 POSIX 消
|
||||
|
||||
---
|
||||
|
||||
### 11.2.7 USER Namespace
|
||||
### 12.2.7 USER Namespace
|
||||
|
||||
USER Namespace 允许将容器内的用户 ID 映射到宿主机的不同用户 ID。
|
||||
|
||||
@@ -236,7 +236,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.2.8 动手实验：体验 Namespace
|
||||
### 12.2.8 动手实验：体验 Namespace
|
||||
|
||||
使用 `unshare` 命令可以在不使用 Docker 的情况下体验 Namespace：
|
||||
|
||||
@@ -301,7 +301,7 @@ $ ip addr
|
||||
|
||||
---
|
||||
|
||||
### 11.2.9 Namespace 的局限性
|
||||
### 12.2.9 Namespace 的局限性
|
||||
|
||||
Namespace 提供了隔离但不是安全边界：
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 11.3 控制组
|
||||
## 12.3 控制组
|
||||
|
||||
控制组 (Cgroups) 是 Linux 内核提供的另一种关键机制，主要用于资源的限制和审计。
|
||||
|
||||
### 11.3.1 什么是控制组
|
||||
### 12.3.1 什么是控制组
|
||||
|
||||
控制组 (Control Groups，简称 cgroups) 是 Linux 内核的一个特性，用于 **限制、记录和隔离** 进程组的资源使用 (CPU、内存、磁盘 I/O、网络等)。
|
||||
|
||||
@@ -31,7 +31,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.3.2 cgroups 的历史
|
||||
### 12.3.2 cgroups 的历史
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -44,7 +44,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.3.3 cgroups 可以限制的资源
|
||||
### 12.3.3 cgroups 可以限制的资源
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -58,7 +58,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.3.4 Docker 中的资源限制
|
||||
### 12.3.4 Docker 中的资源限制
|
||||
|
||||
Docker 提供了丰富的参数来配置容器的资源限制，主要包括内存、CPU、磁盘 I/O 等。
|
||||
|
||||
@@ -142,7 +142,7 @@ $ docker run --pids-limit=100 myapp
|
||||
|
||||
---
|
||||
|
||||
### 11.3.5 查看容器资源使用
|
||||
### 12.3.5 查看容器资源使用
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -165,7 +165,7 @@ $ docker inspect mycontainer --format '{{json .HostConfig}}' | jq
|
||||
|
||||
---
|
||||
|
||||
### 11.3.6 资源限制的效果
|
||||
### 12.3.6 资源限制的效果
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -209,7 +209,7 @@ $ docker run --rm --cpus=1 stress --cpu 4
|
||||
|
||||
---
|
||||
|
||||
### 11.3.7 cgroups v1 vs v2
|
||||
### 12.3.7 cgroups v1 vs v2
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -245,7 +245,7 @@ nodev cgroup2
|
||||
|
||||
---
|
||||
|
||||
### 11.3.8 在 Compose 中设置限制
|
||||
### 12.3.8 在 Compose 中设置限制
|
||||
|
||||
在 Compose 中设置限制配置如下：
|
||||
|
||||
@@ -265,7 +265,7 @@ services:
|
||||
|
||||
---
|
||||
|
||||
### 11.3.9 最佳实践
|
||||
### 12.3.9 最佳实践
|
||||
|
||||
在使用 Cgroups 限制资源时，遵循一些最佳实践可以避免潜在的问题。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 11.4 联合文件系统
|
||||
## 12.4 联合文件系统
|
||||
|
||||
联合文件系统 (UnionFS) 是 Docker 镜像分层存储的基础，它允许将多个目录挂载为同一个虚拟文件系统。
|
||||
|
||||
### 11.4.1 什么是联合文件系统
|
||||
### 12.4.1 什么是联合文件系统
|
||||
|
||||
联合文件系统 (UnionFS) 是一种 **分层、轻量级** 的文件系统，它将多个目录 “联合” 挂载到同一个虚拟目录，形成一个统一的文件系统视图。
|
||||
|
||||
@@ -24,7 +24,7 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 11.4.2 为什么 Docker 使用联合文件系统
|
||||
### 12.4.2 为什么 Docker 使用联合文件系统
|
||||
|
||||
Docker 选择联合文件系统作为其存储驱动，主要基于以下几个核心优势。
|
||||
|
||||
@@ -62,7 +62,7 @@ COPY . . # 层4：应用代码
|
||||
|
||||
---
|
||||
|
||||
### 11.4.3 Copy-on-Write (写时复制)
|
||||
### 12.4.3 Copy-on-Write (写时复制)
|
||||
|
||||
当容器修改只读层中的文件时：
|
||||
|
||||
@@ -92,7 +92,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
### 11.4.4 Docker 支持的存储驱动
|
||||
### 12.4.4 Docker 支持的存储驱动
|
||||
|
||||
Docker 可使用多种联合文件系统实现：
|
||||
|
||||
@@ -128,7 +128,7 @@ Storage Driver: overlay2
|
||||
|
||||
---
|
||||
|
||||
### 11.4.5 overlay2 工作原理
|
||||
### 12.4.5 overlay2 工作原理
|
||||
|
||||
overlay2 是目前最推荐的存储驱动：
|
||||
|
||||
@@ -169,7 +169,7 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 11.4.6 查看镜像层
|
||||
### 12.4.6 查看镜像层
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -198,7 +198,7 @@ $ docker inspect nginx:alpine --format '{{json .GraphDriver.Data}}' | jq
|
||||
|
||||
---
|
||||
|
||||
### 11.4.7 最佳实践
|
||||
### 12.4.7 最佳实践
|
||||
|
||||
为了构建高效、轻量的镜像，我们在使用联合文件系统时应注意以下几点。
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
## 11.5 容器格式
|
||||
## 12.5 容器格式
|
||||
|
||||
最初，Docker 采用了 `LXC` 中的容器格式。从 0.7 版本以后开始去除 LXC，转而使用自行开发的 [libcontainer](https://github.com/docker/libcontainer)，从 1.11 开始，则进一步演进为使用 [runC](https://github.com/opencontainers/runc) 和 [containerd](https://github.com/containerd/containerd)。
|
||||
@@ -1,8 +1,8 @@
|
||||
## 11.6 Docker 网络实现
|
||||
## 12.6 Docker 网络实现
|
||||
|
||||
Docker 的网络实现其实就是利用了 Linux 上的网络命名空间和虚拟网络设备 (特别是 veth pair)。建议先熟悉了解这两部分的基本概念再阅读本章。
|
||||
|
||||
### 11.6.1 基本原理
|
||||
### 12.6.1 基本原理
|
||||
|
||||
首先，要实现网络通信，机器需要至少一个网络接口 (物理接口或虚拟接口) 来收发数据包；此外，如果不同子网之间要进行通信，需要路由机制。
|
||||
|
||||
@@ -11,7 +11,7 @@ Linux 通过在内核中进行数据复制来实现虚拟接口之间的数据
|
||||
|
||||
Docker 容器网络就利用了这项技术。它在本地主机和容器内分别创建一个虚拟接口，并让它们彼此连通 (这样的一对接口叫做 `veth pair`)。
|
||||
|
||||
### 11.6.2 创建网络参数
|
||||
### 12.6.2 创建网络参数
|
||||
|
||||
Docker 创建一个容器的时候，会执行如下操作：
|
||||
|
||||
@@ -29,7 +29,7 @@ Docker 创建一个容器的时候，会执行如下操作：
|
||||
* `--net=container:NAME_or_ID` 让 Docker 将新建容器的进程放到一个已存在容器的网络栈中，新容器进程有自己的文件系统、进程列表和资源限制，但会和已存在的容器共享 IP 地址和端口等网络资源，两者进程可以直接通过 `lo` 环回接口通信。
|
||||
* `--net=none` 让 Docker 将新容器放到隔离的网络栈中，但是不进行网络配置。之后，用户可以自己进行配置。
|
||||
|
||||
### 11.6.3 网络配置细节
|
||||
### 12.6.3 网络配置细节
|
||||
|
||||
用户使用 `--net=none` 后，可以自行配置网络，让容器达到跟平常一样具有访问网络的权限。通过这个过程，可以了解 Docker 配置网络的细节。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 第十一章 底层实现
|
||||
# 第十二章 底层实现
|
||||
|
||||
Docker 底层的核心技术包括 Linux 上的命名空间 (Namespaces)、控制组 (Control groups)、Union 文件系统 (Union file systems) 和容器格式 (Container format)。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 11.7 本章小结
|
||||
## 12.7 本章小结
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
| IPC | 进程间通信 | 容器间 IPC 隔离 |
|
||||
| USER | 用户 ID | 容器 root ≠ 宿主机 root |
|
||||
|
||||
### 11.7.1 延伸阅读
|
||||
### 12.7.1 延伸阅读
|
||||
|
||||
- [控制组 (Cgroups)](11.3_cgroups.md)：资源限制机制
|
||||
- [联合文件系统](11.4_ufs.md)：分层存储的实现
|
||||
@@ -26,7 +26,7 @@
|
||||
| **磁盘 I/O** | `--device-write-bps` | `--device-write-bps /dev/sda:10mb` |
|
||||
| **进程数** | `--pids-limit` | `--pids-limit=100` |
|
||||
|
||||
### 11.7.2 延伸阅读
|
||||
### 12.7.2 延伸阅读
|
||||
|
||||
- [命名空间](11.2_namespace.md)：资源隔离
|
||||
- [安全](../17_security/README.md)：容器安全概述
|
||||
@@ -39,7 +39,7 @@
|
||||
| **overlay2** | Docker 默认推荐的存储驱动 |
|
||||
| **分层好处** | 镜像复用、快速构建、快速启动 |
|
||||
|
||||
### 11.7.3 延伸阅读
|
||||
### 12.7.3 延伸阅读
|
||||
|
||||
- [镜像](../02_basic_concept/2.1_image.md)：理解镜像分层
|
||||
- [容器](../02_basic_concept/2.2_container.md)：容器存储层
|
||||
|
Before Width: | Height: | Size: 217 KiB After Width: | Height: | Size: 217 KiB |
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 153 KiB After Width: | Height: | Size: 153 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
@@ -1,8 +1,8 @@
|
||||
## 12.4 Kubernetes 高级特性
|
||||
## 13.4 Kubernetes 高级特性
|
||||
|
||||
掌握了 Kubernetes 的核心概念 (Pod，Service，Deployment) 后，我们需要了解更多高级特性以构建生产级应用。
|
||||
|
||||
### 12.4.1 Helm - 包管理工具
|
||||
### 13.4.1 Helm - 包管理工具
|
||||
|
||||
[Helm](https://helm.sh/) 被称为 Kubernetes 的包管理器 (类似于 Linux 的 apt/yum)。它将一组 Kubernetes 资源定义文件打包为一个 **Chart**。
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
* **版本管理**：轻松回滚应用的发布版本。
|
||||
* **模板化**：支持复杂的应用部署逻辑配置。
|
||||
|
||||
### 12.4.2 Ingress - 服务的入口
|
||||
### 13.4.2 Ingress - 服务的入口
|
||||
|
||||
Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress** 提供了 7 层 (HTTP/HTTPS) 路由能力，充当集群的网关。
|
||||
|
||||
@@ -20,7 +20,7 @@ Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress**
|
||||
|
||||
常见的 Ingress Controller 有 Nginx Ingress Controller，Traefik，Istio Gateway 等。
|
||||
|
||||
### 12.4.3 Persistent Volume 与 StorageClass
|
||||
### 13.4.3 Persistent Volume 与 StorageClass
|
||||
|
||||
容器内的文件是临时的。对于有状态应用 (如数据库)，需要持久化存储。
|
||||
|
||||
@@ -28,7 +28,7 @@ Service 虽然提供了负载均衡，但通常是 4 层 (TCP/UDP)。**Ingress**
|
||||
* **PV (Persistent Volume)**：实际的存储资源 (NFS，AWS EBS，Ceph 等)。
|
||||
* **StorageClass**：定义存储类，支持动态创建 PV。
|
||||
|
||||
### 12.4.4 Horizontal Pod Autoscaling
|
||||
### 13.4.4 Horizontal Pod Autoscaling
|
||||
|
||||
HPA 根据 CPU 利用率或其他指标 (如内存、自定义指标) 自动扩缩 Deployment 或 ReplicaSet 中的 Pod 数量。
|
||||
|
||||
@@ -53,7 +53,7 @@ spec:
|
||||
averageUtilization: 50
|
||||
```
|
||||
|
||||
### 12.4.5 ConfigMap 与 Secret
|
||||
### 13.4.5 ConfigMap 与 Secret
|
||||
|
||||
* **ConfigMap**：存储非机密的配置数据 (配置文件、环境变量)。
|
||||
* **Secret**：存储机密数据 (密码、Token、证书)，在 Etcd 中加密存储。
|
||||
@@ -1,4 +1,4 @@
|
||||
## 12.2 基本概念
|
||||
## 13.2 基本概念
|
||||
|
||||
如图 12-2 所示，Kubernetes 由控制平面与工作节点构成。
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
* web 界面 (`ux`)：用户可以通过 web 界面操作 Kubernetes。
|
||||
* 命令行操作 (`cli`)：`kubectl` 命令。
|
||||
|
||||
### 12.2.1 节点
|
||||
### 13.2.1 节点
|
||||
|
||||
在 `Kubernetes` 中，节点是实际工作的点，节点可以是虚拟机或者物理机器，依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组，并且它们都可以通过主节点来管理。必要服务包括 Docker，kubelet 和代理服务。
|
||||
|
||||
@@ -69,7 +69,7 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
|
||||
|
||||
节点控制有一个同步轮询，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 `--node_sync_period` 标志来控制该轮询。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines` 标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点，两者是相同的。通过设置 `--sync_nodes=false` 标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。
|
||||
|
||||
### 12.2.2 容器组
|
||||
### 13.2.2 容器组
|
||||
|
||||
在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。一个容器组使用相同的 Docker 容器并共享卷 (挂载点)。一个容器组是一个特定应用的打包集合，包含一个或多个容器。
|
||||
|
||||
@@ -179,30 +179,30 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接
|
||||
* 节点控制器标记容器组 `failed`
|
||||
* 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
|
||||
|
||||
### 12.2.3 Replication Controllers
|
||||
### 13.2.3 Replication Controllers
|
||||
|
||||
> 注：Replication Controller (RC) 是早期的控制器类型，现代 Kubernetes 更推荐使用 ReplicaSet/Deployment。
|
||||
|
||||
### 12.2.4 服务
|
||||
### 13.2.4 服务
|
||||
|
||||
> 注：服务 (Service) 定义一组 Pod 的逻辑集合和访问它们的策略。
|
||||
|
||||
### 12.2.5 卷
|
||||
### 13.2.5 卷
|
||||
|
||||
> 注：卷 (Volume) 包含可被 Pod 中容器访问的数据的目录。
|
||||
|
||||
### 12.2.6 标签
|
||||
### 13.2.6 标签
|
||||
|
||||
> 注：标签 (Label) 是附加到对象 (如 Pods) 上的键值对，用于组织和选择对象子集。
|
||||
|
||||
### 12.2.7 接口权限
|
||||
### 13.2.7 接口权限
|
||||
|
||||
> 注：接口权限通过认证、授权和准入控制来保护 Kubernetes API 的访问。
|
||||
|
||||
### 12.2.8 web 界面
|
||||
### 13.2.8 web 界面
|
||||
|
||||
> 注：Kubernetes Dashboard 是一个基于 Web 的用户界面，用于管理集群。
|
||||
|
||||
### 12.2.9 命令行操作
|
||||
### 13.2.9 命令行操作
|
||||
|
||||
> 注：kubectl 是 Kubernetes 的命令行工具，用于与集群进行交互。
|
||||
@@ -1,8 +1,8 @@
|
||||
## 12.3 架构设计
|
||||
## 13.3 架构设计
|
||||
|
||||
任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。
|
||||
|
||||
### 12.3.1 基本考虑
|
||||
### 13.3.1 基本考虑
|
||||
|
||||
如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的：
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
* 一套资源调度系统，管理哪个容器该分配到哪个节点上；
|
||||
* 一套对容器内服务进行抽象和 HA 的系统。
|
||||
|
||||
### 12.3.2 运行原理
|
||||
### 13.3.2 运行原理
|
||||
|
||||
如图 12-3 所示，该图完整展示了 Kubernetes 的运行原理。
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
从这张图上，我们没有能发现 Kubernetes 中对于控制平面的分布式实现，但是由于数据后端自身就是一套分布式的数据库 Etcd，因此可以很容易扩展到分布式实现。
|
||||
|
||||
### 12.3.3 控制平面
|
||||
### 13.3.3 控制平面
|
||||
|
||||
控制平面 (Control Plane) 是 Kubernetes 集群的大脑，负责做出全局决策 (如调度) 以及检测和响应集群事件。
|
||||
|
||||
@@ -45,7 +45,7 @@
|
||||
|
||||
组件可以自动的去侦测 Etcd 中的数值变化来获得通知，并且获得更新后的数据来执行相应的操作。
|
||||
|
||||
### 12.3.4 工作节点
|
||||
### 13.3.4 工作节点
|
||||
|
||||
* kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
|
||||
* kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod (同一类标签)。
|
||||
@@ -1,4 +1,4 @@
|
||||
## 12.1 Kubernetes 简介
|
||||
## 13.1 Kubernetes 简介
|
||||
|
||||
如图 12-1 所示，Kubernetes 使用舵手图标作为项目标识。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
图 12-1 Kubernetes 项目标识
|
||||
|
||||
### 12.1.1 什么是 Kubernetes
|
||||
### 13.1.1 什么是 Kubernetes
|
||||
|
||||
Kubernetes (常简称为 K8s) 是 Google 开源的容器编排引擎。如果说 Docker 解决了 “如何打包和运送集装箱” 的问题，那么 Kubernetes 解决的就是 “如何管理海量集装箱的调度、运行和维护” 的问题。
|
||||
|
||||
@@ -16,7 +16,7 @@ Kubernetes (常简称为 K8s) 是 Google 开源的容器编排引擎。如果说
|
||||
|
||||
---
|
||||
|
||||
### 12.1.2 为什么需要 Kubernetes
|
||||
### 13.1.2 为什么需要 Kubernetes
|
||||
|
||||
当我们在单机运行几个容器时，Docker Compose 就足够了。但在生产环境中，我们需要面对：
|
||||
|
||||
@@ -30,7 +30,7 @@ Kubernetes 完美解决了这些问题。
|
||||
|
||||
---
|
||||
|
||||
### 12.1.3 核心概念
|
||||
### 13.1.3 核心概念
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -56,7 +56,7 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密
|
||||
|
||||
---
|
||||
|
||||
### 12.1.4 Docker 用户如何过渡
|
||||
### 13.1.4 Docker 用户如何过渡
|
||||
|
||||
如果你已经熟悉 Docker，学习 K8s 会很容易：
|
||||
|
||||
@@ -69,7 +69,7 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密
|
||||
|
||||
---
|
||||
|
||||
### 12.1.5 架构
|
||||
### 13.1.5 架构
|
||||
|
||||
Kubernetes 也是 C/S 架构，由 **Control Plane (控制平面)** 和 **Worker Node (工作节点)** 组成：
|
||||
|
||||
@@ -78,7 +78,7 @@ Kubernetes 也是 C/S 架构，由 **Control Plane (控制平面)** 和 **Worker
|
||||
|
||||
---
|
||||
|
||||
### 12.1.6 学习建议
|
||||
### 13.1.6 学习建议
|
||||
|
||||
Kubernetes 的学习曲线较陡峭。建议的学习路径：
|
||||
|
||||
@@ -89,7 +89,7 @@ Kubernetes 的学习曲线较陡峭。建议的学习路径：
|
||||
|
||||
---
|
||||
|
||||
### 12.1.7 延伸阅读
|
||||
### 13.1.7 延伸阅读
|
||||
|
||||
- [Minikube 安装](../setup/README.md)：本地体验 K8s
|
||||
- [Kubernetes 官网](https://kubernetes.io/)：官方文档
|
||||
@@ -1,14 +1,14 @@
|
||||
## 12.5 Kubernetes 实战练习
|
||||
## 13.5 Kubernetes 实战练习
|
||||
|
||||
本章将通过一个具体的案例：部署一个 Nginx 网站，并为其配置 Service 和 Ingress，来串联前面学到的知识。
|
||||
|
||||
### 12.5.1 目标
|
||||
### 13.5.1 目标
|
||||
|
||||
1. 部署一个 Nginx Deployment。
|
||||
2. 创建一个 Service 暴露 Nginx。
|
||||
3. (可选) 通过 Ingress 访问服务。
|
||||
|
||||
### 12.5.2 步骤 1：创建 Deployment
|
||||
### 13.5.2 步骤 1：创建 Deployment
|
||||
|
||||
创建一个名为 `nginx-deployment.yaml` 的文件：
|
||||
|
||||
@@ -42,7 +42,7 @@ spec:
|
||||
kubectl apply -f nginx-deployment.yaml
|
||||
```
|
||||
|
||||
### 12.5.3 步骤 2：创建 Service
|
||||
### 13.5.3 步骤 2：创建 Service
|
||||
|
||||
创建一个名为 `nginx-service.yaml` 的文件：
|
||||
|
||||
@@ -75,7 +75,7 @@ kubectl get svc nginx-service
|
||||
|
||||
如果输出端口是 `80:30080/TCP`，你可以通过 `http://<NodeIP>:30080` 访问 Nginx。
|
||||
|
||||
### 12.5.4 步骤 3：模拟滚动更新
|
||||
### 13.5.4 步骤 3：模拟滚动更新
|
||||
|
||||
修改 `nginx-deployment.yaml`，将镜像版本改为 `nginx:1.27-alpine`。
|
||||
|
||||
@@ -89,7 +89,7 @@ kubectl apply -f nginx-deployment.yaml
|
||||
kubectl rollout status deployment/nginx-deployment
|
||||
```
|
||||
|
||||
### 12.5.5 步骤 4：清理资源
|
||||
### 13.5.5 步骤 4：清理资源
|
||||
|
||||
练习结束后，记得清理资源：
|
||||
|
||||
19
13_kubernetes_concepts/summary.md
Normal file
19
13_kubernetes_concepts/summary.md
Normal file
@@ -0,0 +1,19 @@
|
||||
## 13.6 本章小结
|
||||
|
||||
Kubernetes 是当前最主流的容器编排平台，其声明式管理模型和丰富的 API 为大规模容器化应用提供了坚实的基础。
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **Pod** | 最小调度单位，包含一组共享网络和存储的容器 |
|
||||
| **Deployment** | 管理 Pod 副本集，支持滚动更新和回滚 |
|
||||
| **Service** | 为 Pod 提供稳定的网络访问入口和负载均衡 |
|
||||
| **Namespace** | 资源隔离和多租户支持 |
|
||||
| **ConfigMap/Secret** | 配置与敏感信息的管理 |
|
||||
| **Master 节点** | 运行 API Server、Scheduler、Controller Manager |
|
||||
| **Worker 节点** | 运行 kubelet、kube-proxy 和容器运行时 |
|
||||
|
||||
### 13.6.1 延伸阅读
|
||||
|
||||
- [部署 Kubernetes](../14_kubernetes_setup/README.md)：搭建 Kubernetes 集群
|
||||
- [Etcd](../15_etcd/README.md)：Kubernetes 使用的分布式存储
|
||||
- [底层实现](../12_implementation/README.md)：容器技术原理
|
||||
@@ -1,10 +1,10 @@
|
||||
## 13.7 Kubernetes Dashboard
|
||||
## 14.7 Kubernetes Dashboard
|
||||
|
||||
[Kubernetes Dashboard](https://github.com/kubernetes/dashboard) 是基于网页的 Kubernetes 用户界面。
|
||||
|
||||
|
||||
|
||||
### 13.7.1 部署
|
||||
### 14.7.1 部署
|
||||
|
||||
执行以下命令即可部署 Dashboard：
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml
|
||||
```
|
||||
|
||||
### 13.7.2 访问
|
||||
### 14.7.2 访问
|
||||
|
||||
通过命令行代理访问，执行以下命令：
|
||||
|
||||
@@ -22,7 +22,7 @@ $ kubectl proxy
|
||||
|
||||
到 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 即可访问。
|
||||
|
||||
### 13.7.3 登录
|
||||
### 14.7.3 登录
|
||||
|
||||
目前，Dashboard 仅支持使用 Bearer 令牌登录。下面教大家如何创建该令牌：
|
||||
|
||||
@@ -40,6 +40,6 @@ echo ${DASHBOARD_LOGIN_TOKEN}
|
||||
|
||||
将结果粘贴到登录页面，即可登录。
|
||||
|
||||
### 13.7.4 参考文档
|
||||
### 14.7.4 参考文档
|
||||
|
||||
* [官方文档](https://kubernetes.io/zh/docs/tasks/access-application-cluster/web-ui-dashboard/)
|
||||
@@ -1,8 +1,8 @@
|
||||
## 13.3 Docker Desktop 启用 Kubernetes
|
||||
## 14.3 Docker Desktop 启用 Kubernetes
|
||||
|
||||
使用 Docker Desktop 可以很方便的启用 Kubernetes。
|
||||
|
||||
### 13.3.1 启用 Kubernetes
|
||||
### 14.3.1 启用 Kubernetes
|
||||
|
||||
在 Docker Desktop 设置页面，点击 `Kubernetes`，选择 `Enable Kubernetes`，稍等片刻，看到左下方 `Kubernetes` 变为 `running`，Kubernetes 启动成功。
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
> 注意：Kubernetes 的镜像存储在 `registry.k8s.io`，如果国内网络无法直接访问，可以在 Docker Desktop 配置中的 `Docker Engine` 处配置镜像加速器，或者利用国内云服务商的镜像仓库手动拉取镜像并 retag。
|
||||
|
||||
### 13.3.2 测试
|
||||
### 14.3.2 测试
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
## 13.5 K3s - 轻量级 Kubernetes
|
||||
## 14.5 K3s - 轻量级 Kubernetes
|
||||
|
||||
[K3s](https://k3s.io/) 是一个轻量级的 Kubernetes 发行版，由 Rancher Labs 开发。它专为边缘计算、物联网、CI、ARM 等资源受限的环境设计。K3s 被打包为单个二进制文件，只有不到 100MB，但通过了 CNCF 的一致性测试。
|
||||
|
||||
### 13.5.1 核心特性
|
||||
### 14.5.1 核心特性
|
||||
|
||||
* **轻量级**：移除过时的、非必须的 Kubernetes 功能 (如传统的云提供商插件)，使用 SQLite 作为默认数据存储 (也支持 Etcd/MySQL/Postgres)。
|
||||
* **单一二进制**：所有组件 (API Server，Controller Manager，Scheduler，Kubelet，Kube-proxy) 打包在一个进程中运行。
|
||||
* **开箱即用**：内置 Helm Controller、Traefik Ingress controller、ServiceLB、Local-Path-Provisioner。
|
||||
* **安全**：默认启用安全配置，基于 TLS 通信。
|
||||
|
||||
### 13.5.2 安装
|
||||
### 14.5.2 安装
|
||||
|
||||
K3s 的安装非常简单，官方提供了便捷的安装脚本。
|
||||
|
||||
@@ -37,7 +37,7 @@ NAME STATUS ROLES AGE VERSION
|
||||
k3s-master Ready control-plane,master 1m v1.35.1+k3s1
|
||||
```
|
||||
|
||||
### 13.5.3 快速使用
|
||||
### 14.5.3 快速使用
|
||||
|
||||
K3s 内置了 `kubectl` 命令 (通过 `k3s kubectl` 调用)，为了方便，通常会建立别名或配置 `KUBECONFIG`。
|
||||
|
||||
@@ -51,7 +51,7 @@ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
kubectl get pods -A
|
||||
```
|
||||
|
||||
### 13.5.4 清理卸载
|
||||
### 14.5.4 清理卸载
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 13.4 Kind - Kubernetes IN Docker
|
||||
## 14.4 Kind - Kubernetes IN Docker
|
||||
|
||||
[Kind](https://kind.sigs.k8s.io/) (Kubernetes in Docker) 是一个使用 Docker 容器作为节点运行本地 Kubernetes 集群的工具。主要用于测试 Kubernetes 本身，也非常适合本地开发和 CI 环境。
|
||||
|
||||
### 13.4.1 为什么选择 Kind
|
||||
### 14.4.1 为什么选择 Kind
|
||||
|
||||
Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势：
|
||||
|
||||
@@ -11,7 +11,7 @@ Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势：
|
||||
* **多版本支持**：支持指定 Kubernetes 版本进行测试。
|
||||
* **HA 支持**：支持模拟高可用集群 (多 Control Plane)。
|
||||
|
||||
### 13.4.2 安装 Kind
|
||||
### 14.4.2 安装 Kind
|
||||
|
||||
Kind 是一个二进制文件，并在 PATH 中即可使用。以下是不同系统的安装方法。
|
||||
|
||||
@@ -35,7 +35,7 @@ chmod +x ./kind
|
||||
sudo mv ./kind /usr/local/bin/kind
|
||||
```
|
||||
|
||||
### 13.4.3 创建集群
|
||||
### 14.4.3 创建集群
|
||||
|
||||
最简单的创建方式：
|
||||
|
||||
@@ -49,7 +49,7 @@ kind create cluster
|
||||
kind create cluster --name my-cluster
|
||||
```
|
||||
|
||||
### 13.4.4 与集群交互
|
||||
### 14.4.4 与集群交互
|
||||
|
||||
Kind 会自动将 kubeconfig 合并到 `~/.kube/config`。
|
||||
|
||||
@@ -58,7 +58,7 @@ kubectl cluster-info --context kind-kind
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
### 13.4.5 高级用法：配置集群
|
||||
### 14.4.5 高级用法：配置集群
|
||||
|
||||
创建一个 `kind-config.yaml` 来定制集群，例如映射端口到宿主机：
|
||||
|
||||
@@ -81,7 +81,7 @@ nodes:
|
||||
kind create cluster --config kind-config.yaml
|
||||
```
|
||||
|
||||
### 13.4.6 删除集群
|
||||
### 14.4.6 删除集群
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 13.2 使用 kubeadm 部署 Kubernetes (使用 Docker)
|
||||
## 14.2 使用 kubeadm 部署 Kubernetes (使用 Docker)
|
||||
|
||||
`kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令，作为快速创建 `Kubernetes` 集群的最佳实践。
|
||||
|
||||
@@ -6,11 +6,11 @@
|
||||
>
|
||||
> 本文档主要用于历史环境/学习目的：如果你确实需要在较新版本中继续使用 Docker Engine，通常需要额外部署 `cri-dockerd` 并在 `kubeadm init/join` 中指定 `--cri-socket`。
|
||||
|
||||
### 13.2.1 安装 Docker
|
||||
### 14.2.1 安装 Docker
|
||||
|
||||
参考[安装 Docker](../../03_install/README.md) 一节安装 Docker。
|
||||
|
||||
### 13.2.2 安装 **kubelet****kubeadm****kubectl**
|
||||
### 14.2.2 安装 **kubelet****kubeadm****kubectl**
|
||||
|
||||
需要在每台机器上安装以下的软件包：
|
||||
|
||||
@@ -56,7 +56,7 @@ EOF
|
||||
$ sudo yum install -y kubelet kubeadm kubectl
|
||||
```
|
||||
|
||||
### 13.2.3 修改内核的运行参数
|
||||
### 14.2.3 修改内核的运行参数
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -99,7 +99,7 @@ EOF
|
||||
$ sysctl --system
|
||||
```
|
||||
|
||||
### 13.2.4 配置 kubelet
|
||||
### 14.2.4 配置 kubelet
|
||||
|
||||
为了让 kubelet 正确运行，我们需要对其进行一些必要的配置。
|
||||
|
||||
@@ -127,7 +127,7 @@ ExecStartPre=-/sbin/modprobe ip_vs_sh
|
||||
$ sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
### 13.2.5 部署
|
||||
### 14.2.5 部署
|
||||
|
||||
安装配置完成后，我们将分别在 Master 节点和 Worker 节点上进行部署操作。
|
||||
|
||||
@@ -182,7 +182,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
|
||||
--discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe
|
||||
```
|
||||
|
||||
### 13.2.6 查看服务
|
||||
### 14.2.6 查看服务
|
||||
|
||||
所有服务启动后，查看本地实际运行的 Docker 容器。这些服务大概分为三类：主节点服务、工作节点服务和其它服务。
|
||||
|
||||
@@ -202,7 +202,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
|
||||
|
||||
* Etcd 是所有状态的存储数据库；
|
||||
|
||||
### 13.2.7 使用
|
||||
### 14.2.7 使用
|
||||
|
||||
将 `/etc/kubernetes/admin.conf` 复制到 `~/.kube/config`
|
||||
|
||||
@@ -210,7 +210,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
|
||||
|
||||
由于未部署 CNI 插件，CoreDNS 未正常启动。如何使用 Kubernetes，请参考后续章节。
|
||||
|
||||
### 13.2.8 部署 CNI
|
||||
### 14.2.8 部署 CNI
|
||||
|
||||
这里以 `flannel` 为例进行介绍。
|
||||
|
||||
@@ -235,7 +235,7 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
### 13.2.9 master 节点默认不能运行 pod
|
||||
### 14.2.9 master 节点默认不能运行 pod
|
||||
|
||||
如果用 `kubeadm` 部署一个单节点集群，默认情况下无法使用，请执行以下命令解除限制
|
||||
|
||||
@@ -253,6 +253,6 @@ $ kubectl taint nodes --all node-role.kubernetes.io/master-
|
||||
...
|
||||
```
|
||||
|
||||
### 13.2.10 参考文档
|
||||
### 14.2.10 参考文档
|
||||
|
||||
* [官方文档](https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
|
||||
@@ -1,10 +1,10 @@
|
||||
## 13.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd)
|
||||
## 14.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd)
|
||||
|
||||
`kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令，作为快速创建 `Kubernetes` 集群的最佳实践。
|
||||
|
||||
> **版本说明**：Kubernetes 版本更新较快 (约每 4 个月一个新版本)，本文档基于 Kubernetes 1.35 编写。请访问 [Kubernetes 官方发布页](https://kubernetes.io/releases/)获取最新版本信息。
|
||||
|
||||
### 13.1.1 安装 containerd
|
||||
### 14.1.1 安装 containerd
|
||||
|
||||
参考[安装 Docker](../../03_install/README.md) 一节添加 apt/yum 源，之后执行如下命令。
|
||||
|
||||
@@ -18,7 +18,7 @@ $ sudo apt install containerd.io
|
||||
$ sudo yum install containerd.io
|
||||
```
|
||||
|
||||
### 13.1.2 配置 containerd
|
||||
### 14.1.2 配置 containerd
|
||||
|
||||
新建 `/etc/systemd/system/cri-containerd.service` 文件
|
||||
|
||||
@@ -228,7 +228,7 @@ oom_score = 0
|
||||
async_remove = false
|
||||
```
|
||||
|
||||
### 13.1.3 安装 **kubelet****kubeadm****kubectl****cri-tools****kubernetes-cni**
|
||||
### 14.1.3 安装 **kubelet****kubeadm****kubectl****cri-tools****kubernetes-cni**
|
||||
|
||||
需要在每台机器上安装以下的软件包：
|
||||
|
||||
@@ -274,7 +274,7 @@ EOF
|
||||
$ sudo yum install -y kubelet kubeadm kubectl cri-tools kubernetes-cni
|
||||
```
|
||||
|
||||
### 13.1.4 修改内核的运行参数
|
||||
### 14.1.4 修改内核的运行参数
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -317,7 +317,7 @@ EOF
|
||||
$ sysctl --system
|
||||
```
|
||||
|
||||
### 13.1.5 配置 kubelet
|
||||
### 14.1.5 配置 kubelet
|
||||
|
||||
为了让 kubelet 正确运行，我们需要对其进行一些必要的配置。
|
||||
|
||||
@@ -345,7 +345,7 @@ ExecStartPre=-/sbin/modprobe ip_vs_sh
|
||||
$ sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
### 13.1.6 部署
|
||||
### 14.1.6 部署
|
||||
|
||||
安装配置完成后，我们将分别在 Master 节点和 Worker 节点上进行部署操作。
|
||||
|
||||
@@ -412,7 +412,7 @@ $ kubeadm join 192.168.199.100:6443 \
|
||||
--cri-socket /run/cri-containerd/cri-containerd.sock
|
||||
```
|
||||
|
||||
### 13.1.7 查看服务
|
||||
### 14.1.7 查看服务
|
||||
|
||||
所有服务启动后，通过 `crictl` 查看本地实际运行的容器。这些服务大概分为三类：主节点服务、工作节点服务和其它服务。
|
||||
|
||||
@@ -436,7 +436,7 @@ CONTAINER_RUNTIME_ENDPOINT=/run/cri-containerd/cri-containerd.sock crictl ps -a
|
||||
|
||||
* Etcd 是所有状态的存储数据库；
|
||||
|
||||
### 13.1.8 使用
|
||||
### 14.1.8 使用
|
||||
|
||||
将 `/etc/kubernetes/admin.conf` 复制到 `~/.kube/config`
|
||||
|
||||
@@ -444,7 +444,7 @@ CONTAINER_RUNTIME_ENDPOINT=/run/cri-containerd/cri-containerd.sock crictl ps -a
|
||||
|
||||
由于未部署 CNI 插件，CoreDNS 未正常启动。如何使用 Kubernetes，请参考后续章节。
|
||||
|
||||
### 13.1.9 部署 CNI
|
||||
### 14.1.9 部署 CNI
|
||||
|
||||
这里以 `flannel` 为例进行介绍。
|
||||
|
||||
@@ -469,7 +469,7 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
### 13.1.10 master 节点默认不能运行 pod
|
||||
### 14.1.10 master 节点默认不能运行 pod
|
||||
|
||||
如果用 `kubeadm` 部署一个单节点集群，默认情况下无法使用，请执行以下命令解除限制
|
||||
|
||||
@@ -487,7 +487,7 @@ $ kubectl taint nodes --all node-role.kubernetes.io/master-
|
||||
...
|
||||
```
|
||||
|
||||
### 13.1.11 参考文档
|
||||
### 14.1.11 参考文档
|
||||
|
||||
* [官方文档](https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)
|
||||
* [Container runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)
|
||||
@@ -8,74 +8,74 @@ kubectl [flags]
|
||||
kubectl [command]
|
||||
```
|
||||
|
||||
## 13.8 get
|
||||
## 14.8 get
|
||||
|
||||
显示一个或多个资源
|
||||
|
||||
## 13.8 describe
|
||||
## 14.8 describe
|
||||
|
||||
显示资源详情
|
||||
|
||||
## 13.8 create
|
||||
## 14.8 create
|
||||
|
||||
从文件或标准输入创建资源
|
||||
|
||||
## 13.8 update
|
||||
## 14.8 update
|
||||
|
||||
从文件或标准输入更新资源
|
||||
|
||||
## 13.8 delete
|
||||
## 14.8 delete
|
||||
|
||||
通过文件名、标准输入、资源名或者 label selector 删除资源
|
||||
|
||||
## 13.8 logs
|
||||
## 14.8 logs
|
||||
|
||||
输出 pod 中一个容器的日志
|
||||
|
||||
## 13.8 rollout
|
||||
## 14.8 rollout
|
||||
|
||||
对 Deployment 等资源执行滚动更新/回滚
|
||||
|
||||
## 13.8 exec
|
||||
## 14.8 exec
|
||||
|
||||
在容器内部执行命令
|
||||
|
||||
## 13.8 port-forward
|
||||
## 14.8 port-forward
|
||||
|
||||
将本地端口转发到 Pod
|
||||
|
||||
## 13.8 proxy
|
||||
## 14.8 proxy
|
||||
|
||||
为 Kubernetes API server 启动代理服务器
|
||||
|
||||
## 13.8 run
|
||||
## 14.8 run
|
||||
|
||||
在集群中使用指定镜像启动容器
|
||||
|
||||
## 13.8 expose
|
||||
## 14.8 expose
|
||||
|
||||
将 replication controller service 或 pod 暴露为新的 Kubernetes service
|
||||
|
||||
## 13.8 label
|
||||
## 14.8 label
|
||||
|
||||
更新资源的 label
|
||||
|
||||
## 13.8 config
|
||||
## 14.8 config
|
||||
|
||||
修改 Kubernetes 配置文件
|
||||
|
||||
## 13.8 cluster-info
|
||||
## 14.8 cluster-info
|
||||
|
||||
显示集群信息
|
||||
|
||||
## 13.8 api-versions
|
||||
## 14.8 api-versions
|
||||
|
||||
以 “组/版本” 的格式输出服务端支持的 API 版本
|
||||
|
||||
## 13.8 version
|
||||
## 14.8 version
|
||||
|
||||
输出服务端和客户端的版本信息
|
||||
|
||||
## 13.8 help
|
||||
## 14.8 help
|
||||
|
||||
显示各个命令的帮助信息
|
||||
17
14_kubernetes_setup/summary.md
Normal file
17
14_kubernetes_setup/summary.md
Normal file
@@ -0,0 +1,17 @@
|
||||
## 14.9 本章小结
|
||||
|
||||
部署 Kubernetes 集群有多种方式，应根据使用场景选择合适的方案。
|
||||
|
||||
| 部署方式 | 适用场景 | 特点 |
|
||||
|---------|---------|------|
|
||||
| **kubeadm** | 生产环境 | 官方推荐的集群部署工具 |
|
||||
| **Docker Desktop** | 本地开发 | 一键启用，开箱即用 |
|
||||
| **Kind** | CI/CD 测试 | Kubernetes IN Docker，快速创建集群 |
|
||||
| **K3s** | 边缘计算/IoT | 轻量级，资源占用少 |
|
||||
| **手动部署** | 学习原理 | 逐步配置每个组件，加深理解 |
|
||||
|
||||
### 14.9.1 延伸阅读
|
||||
|
||||
- [容器编排基础](../13_kubernetes_concepts/README.md)：Kubernetes 核心概念
|
||||
- [Dashboard](dashboard.md)：部署可视化管理界面
|
||||
- [kubectl](kubectl.md)：命令行工具使用指南
|
||||
@@ -1,3 +1,3 @@
|
||||
## 13.6 一步步部署 Kubernetes 集群
|
||||
## 14.6 一步步部署 Kubernetes 集群
|
||||
|
||||
可以参考 [opsnull/follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster) 项目一步步部署 Kubernetes 集群。
|
||||
|
Before Width: | Height: | Size: 4.4 KiB After Width: | Height: | Size: 4.4 KiB |
@@ -1,4 +1,4 @@
|
||||
## 14.3 etcd 集群
|
||||
## 15.3 etcd 集群
|
||||
|
||||
下面我们使用 [Docker Compose](../../10_compose/README.md) 模拟启动一个 3 节点的 `etcd` 集群。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 14.4 使用 etcdctl
|
||||
## 15.4 使用 etcdctl
|
||||
|
||||
`etcdctl` 是一个命令行客户端，它能提供一些简洁的命令，供用户直接跟 `etcd` 服务打交道，而无需基于 `HTTP API` 方式。这在某些情况下将很方便，例如用户对服务进行测试或者手动修改数据库内容。我们也推荐在刚接触 `etcd` 时通过 `etcdctl` 命令来熟悉相关的操作，这些操作跟 `HTTP API` 实际上是对应的。
|
||||
|
||||
@@ -81,7 +81,7 @@ OPTIONS:
|
||||
-w, --write-out="simple" set the output format (fields, json, protobuf, simple, table)
|
||||
```
|
||||
|
||||
### 14.4.1 数据库操作
|
||||
### 15.4.1 数据库操作
|
||||
|
||||
数据库操作围绕对键值和目录的 CRUD (符合 REST 风格的一套操作：Create) 完整生命周期的管理。
|
||||
|
||||
@@ -125,7 +125,7 @@ $ etcdctl del testkey
|
||||
1
|
||||
```
|
||||
|
||||
### 14.4.2 非数据库操作
|
||||
### 15.4.2 非数据库操作
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 14.2 安装
|
||||
## 15.2 安装
|
||||
|
||||
本节将介绍 etcd 的几种常见安装方式，包括二进制安装、Docker 镜像运行以及在 macOS 上的安装。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
>注意：本章节内容基于 etcd `3.4.x` 版本
|
||||
|
||||
### 14.2.1 二进制文件方式下载
|
||||
### 15.2.1 二进制文件方式下载
|
||||
|
||||
编译好的二进制文件都在 [github.com/etcd-io/etcd/releases](https://github.com/etcd-io/etcd/releases/) 页面，用户可以选择需要的版本，或通过下载工具下载。
|
||||
|
||||
@@ -61,7 +61,7 @@ hello world
|
||||
|
||||
说明 etcd 服务已经成功启动了。
|
||||
|
||||
### 14.2.2 Docker 镜像方式运行
|
||||
### 15.2.2 Docker 镜像方式运行
|
||||
|
||||
镜像名称为 `quay.io/coreos/etcd`，可以通过下面的命令启动 `etcd` 服务监听到 `2379` 和 `2380` 端口。
|
||||
|
||||
@@ -89,7 +89,7 @@ quay.io/coreos/etcd:v3.4.0 \
|
||||
|
||||
打开新的终端按照上一步的方法测试 `etcd` 是否成功启动。
|
||||
|
||||
### 14.2.3 macOS 中运行
|
||||
### 15.2.3 macOS 中运行
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 14.1 简介
|
||||
## 15.1 简介
|
||||
|
||||
如图 12-5 所示，etcd 项目使用该标识。
|
||||
|
||||
17
15_etcd/summary.md
Normal file
17
15_etcd/summary.md
Normal file
@@ -0,0 +1,17 @@
|
||||
## 15.5 本章小结
|
||||
|
||||
etcd 是 Kubernetes 的核心存储组件，为分布式系统提供可靠的键值存储和服务发现能力。
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **定位** | 分布式键值存储系统，用于配置管理和服务发现 |
|
||||
| **协议** | 基于 Raft 一致性算法，保证数据强一致 |
|
||||
| **API** | 提供 gRPC 和 HTTP API |
|
||||
| **集群** | 建议使用奇数节点 (3 或 5 个) 部署 |
|
||||
| **etcdctl** | 命令行管理工具，支持 put/get/del/watch 等操作 |
|
||||
| **安全** | 支持 TLS 加密通信和 RBAC 访问控制 |
|
||||
|
||||
### 15.5.1 延伸阅读
|
||||
|
||||
- [容器编排基础](../13_kubernetes_concepts/README.md)：Kubernetes 如何使用 etcd
|
||||
- [部署 Kubernetes](../14_kubernetes_setup/README.md)：在集群中部署 etcd
|
||||
|
Before Width: | Height: | Size: 445 KiB After Width: | Height: | Size: 445 KiB |
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 8.2 KiB After Width: | Height: | Size: 8.2 KiB |
@@ -1,4 +1,4 @@
|
||||
## 15.3 阿里云
|
||||
## 16.3 阿里云
|
||||
|
||||
如图 13-3 所示，阿里云是国内主流云服务平台之一。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 15.4 亚马逊云
|
||||
## 16.4 亚马逊云
|
||||
|
||||
如图 13-1 所示，AWS 是全球主流云服务平台之一。
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
## 15.1 简介
|
||||
## 16.1 简介
|
||||
|
||||
随着容器技术的普及，目前主流的云计算服务商都提供了成熟的容器服务。与容器相关的云计算服务主要分为以下几种类型：
|
||||
|
||||
### 15.1.1 容器编排托管服务
|
||||
### 16.1.1 容器编排托管服务
|
||||
|
||||
这是目前最主流的形式。云厂商托管 Kubernetes 的控制平面 (Master 节点)，用户只需管理工作节点 (Worker Node)。
|
||||
|
||||
* **优势**：降低了 Kubernetes 集群的维护成本，高可用性由厂商保证。
|
||||
* **典型服务**：AWS EKS，Azure AKS，Google GKE，阿里云 ACK，腾讯云 TKE。
|
||||
|
||||
### 15.1.2 容器实例服务
|
||||
### 16.1.2 容器实例服务
|
||||
|
||||
这一类服务通常被称为 CaaS (Container as a Service)。用户无需管理底层服务器 (EC2/CVM)，只需提供镜像和配置即可运行容器。
|
||||
|
||||
* **优势**：极致的弹性，按秒计费，零运维。
|
||||
* **典型服务**：AWS Fargate，Azure Container Instances，Google Cloud Run，阿里云 ECI。
|
||||
|
||||
### 15.1.3 镜像仓库服务
|
||||
### 16.1.3 镜像仓库服务
|
||||
|
||||
提供安全、可靠的私有 Docker 镜像存储服务，通常与云厂商的 CI/CD 流水线深度集成。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
## 15.6 多云部署策略比较
|
||||
## 16.6 多云部署策略比较
|
||||
|
||||
企业在选择容器云平台时，通常会在 AWS EKS，Azure AKS，Google GKE 以及国内的阿里云 ACK，腾讯云 TKE 之间进行权衡。
|
||||
|
||||
### 15.6.1 三大公有云 Kubernetes 服务对比
|
||||
### 16.6.1 三大公有云 Kubernetes 服务对比
|
||||
|
||||
相关信息如下表：
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
| **网络模型** | VPC-native, 性能优秀 | AWS VPC CNI, Pod 直接获取 VPC IP | Azure CNI (消耗 IP 多) 或 Kubenet |
|
||||
| **集成度** | 与 GCP 数据分析、AI 服务集成紧密 | 与 AWS IAM, ALB, CloudWatch 集成深度高 | 与 Active Directory, Azure DevOps 集成好 |
|
||||
|
||||
### 15.6.2 多云部署策略
|
||||
### 16.6.2 多云部署策略
|
||||
|
||||
随着企业业务的扩展，单一云平台可能无法满足所有需求，多云部署成为趋势。
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
* **工具**：Google Anthos，AWS Outposts，Azure Arc 都是为了解决混合云统一管理而生。
|
||||
|
||||
### 15.6.3 建议
|
||||
### 16.6.3 建议
|
||||
|
||||
* **技术选型**：尽量使用标准的 Kubernetes API，避免过度依赖特定云厂商的 CRD 或专有服务，以保持应用的可移植性。
|
||||
* **IaC 管理**：使用 Terraform 或 Pulumi 等工具统一管理多云基础设施。
|
||||
@@ -1,4 +1,4 @@
|
||||
## 15.5 本章小结
|
||||
## 16.5 本章小结
|
||||
|
||||
本章介绍了公有云服务对 Docker 的积极支持，以及新出现的容器云平台。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 15.2 腾讯云
|
||||
## 16.2 腾讯云
|
||||
|
||||
如图 13-5 所示，腾讯云提供完整的云基础设施与容器能力。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 第十六章 容器其它生态
|
||||
# 第十七章 容器其它生态
|
||||
|
||||
本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
## 16.2 安装 Fedora CoreOS
|
||||
## 17.2 安装 Fedora CoreOS
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
### 16.2.1 下载 ISO
|
||||
### 17.2.1 下载 ISO
|
||||
|
||||
在[下载页面](https://getfedora.org/coreos/download/) `Bare Metal & Virtualized` 标签页下载 ISO。
|
||||
|
||||
### 16.2.2 编写 FCC
|
||||
### 17.2.2 编写 FCC
|
||||
|
||||
FCC 是 Fedora CoreOS Configuration (Fedora CoreOS 配置) 的简称。
|
||||
|
||||
@@ -24,7 +24,7 @@ passwd:
|
||||
|
||||
将 `ssh-rsa AAAA...` 替换为自己的 SSH 公钥 (位于 `~/.ssh/id_rsa.pub`)。
|
||||
|
||||
### 16.2.3 转换 FCC 为 Ignition
|
||||
### 17.2.3 转换 FCC 为 Ignition
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -32,7 +32,7 @@ passwd:
|
||||
$ docker run -i --rm quay.io/coreos/fcct:v0.5.0 --pretty --strict < example.fcc > example.ign
|
||||
```
|
||||
|
||||
### 16.2.4 挂载 ISO 启动虚拟机并安装
|
||||
### 17.2.4 挂载 ISO 启动虚拟机并安装
|
||||
|
||||
> 虚拟机需要分配 3GB 以上内存，否则会无法启动。
|
||||
|
||||
@@ -44,7 +44,7 @@ $ sudo coreos-installer install /dev/sda --ignition-file example.ign
|
||||
|
||||
安装之后重新启动即可使用。
|
||||
|
||||
### 16.2.5 使用
|
||||
### 17.2.5 使用
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -54,6 +54,6 @@ $ ssh core@虚拟机IP
|
||||
$ docker --version
|
||||
```
|
||||
|
||||
### 16.2.6 参考链接
|
||||
### 17.2.6 参考链接
|
||||
|
||||
* [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/)
|
||||
@@ -1,8 +1,8 @@
|
||||
## 16.1 Fedora CoreOS 介绍
|
||||
## 17.1 Fedora CoreOS 介绍
|
||||
|
||||
[Fedora CoreOS](https://getfedora.org/coreos/) 是一个自动更新的，最小的，整体的，以容器为中心的操作系统，不仅适用于集群，而且可独立运行，并针对运行 Kubernetes 进行了优化。它旨在结合 CoreOS Container Linux 和 Fedora Atomic Host 的优点，将 Container Linux 中的 [Ignition](https://github.com/coreos/ignition) 与 [rpm-ostree](https://github.com/coreos/rpm-ostree) 和 Project Atomic 中的 SELinux 强化等技术相集成。其目标是提供最佳的容器主机，以安全，大规模地运行容器化的工作负载。
|
||||
|
||||
### 16.1.1 FCOS 特性
|
||||
### 17.1.1 FCOS 特性
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -24,7 +24,7 @@ FCOS 使用 rpm-ostree 系统进行事务性升级。无需像 yum 升级那样
|
||||
|
||||
对于诸如构建，复制和其他管理容器的任务，FCOS 用一组容器工具代替了 **Docker CLI**。**podman CLI** 工具支持许多容器运行时功能，例如运行，启动，停止，列出和删除容器和镜像。**skopeo CLI** 工具可以复制，认证和签名镜像。您还可以使用 **crictl CLI** 工具来处理 CRI-O 容器引擎中的容器和镜像。
|
||||
|
||||
### 16.1.2 参考文档
|
||||
### 17.1.2 参考文档
|
||||
|
||||
* [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/)
|
||||
* [openshift 官方文档](https://docs.openshift.com/container-platform/4.3/architecture/architecture-rhcos.html)
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
[`podman`](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发，旨在提供一个更安全的容器运行环境。
|
||||
|
||||
## 16.3 Podman vs Docker
|
||||
## 17.3 Podman vs Docker
|
||||
|
||||
Podman 和 Docker 在设计理念上存在显著差异，主要体现在架构和权限模型上。
|
||||
|
||||
@@ -13,11 +13,11 @@ Podman 和 Docker 在设计理念上存在显著差异，主要体现在架构
|
||||
| **生态** | 完整的生态系统 (Compose, Swarm) | 专注单机容器，配合 Kubernetes 使用 |
|
||||
| **镜像构建** | `docker build` | `podman build` 或 `buildah` |
|
||||
|
||||
## 16.3 安装
|
||||
## 17.3 安装
|
||||
|
||||
Podman 支持多种操作系统，安装过程也相对简单。
|
||||
|
||||
### 16.3.1 CentOS / RHEL
|
||||
### 17.3.1 CentOS / RHEL
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -25,7 +25,7 @@ Podman 支持多种操作系统，安装过程也相对简单。
|
||||
$ sudo yum -y install podman
|
||||
```
|
||||
|
||||
### 16.3.2 macOS
|
||||
### 17.3.2 macOS
|
||||
|
||||
macOS 上需要安装 Podman Desktop 或通过 Homebrew 安装：
|
||||
|
||||
@@ -35,11 +35,11 @@ $ podman machine init
|
||||
$ podman machine start
|
||||
```
|
||||
|
||||
## 16.3 使用
|
||||
## 17.3 使用
|
||||
|
||||
`podman` 的命令行几乎与 `docker` 完全兼容，大多数情况下，你只需将 `docker` 替换为 `podman` 即可。
|
||||
|
||||
### 16.3.1 运行容器
|
||||
### 17.3.1 运行容器
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -49,7 +49,7 @@ $ podman machine start
|
||||
$ podman run -d -p 80:80 nginx:alpine
|
||||
```
|
||||
|
||||
### 16.3.2 列出容器
|
||||
### 17.3.2 列出容器
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -57,7 +57,7 @@ $ podman run -d -p 80:80 nginx:alpine
|
||||
$ podman ps
|
||||
```
|
||||
|
||||
### 16.3.3 构建镜像
|
||||
### 17.3.3 构建镜像
|
||||
|
||||
运行以下命令：
|
||||
|
||||
@@ -65,7 +65,7 @@ $ podman ps
|
||||
$ podman build -t myimage .
|
||||
```
|
||||
|
||||
## 16.3 Pods 的概念
|
||||
## 17.3 Pods 的概念
|
||||
|
||||
与 Docker 不同，Podman 支持 “Pod” 的概念 (类似于 Kubernetes 的 Pod)，允许你在同一个网络命名空间中运行多个容器。
|
||||
|
||||
@@ -79,7 +79,7 @@ $ podman pod create --name mypod -p 8080:80
|
||||
$ podman run -d --pod mypod --name webbing nginx
|
||||
```
|
||||
|
||||
## 16.3 迁移到 Podman
|
||||
## 17.3 迁移到 Podman
|
||||
|
||||
如果你习惯使用 `docker` 命令，可以简单地设置别名：
|
||||
|
||||
@@ -87,7 +87,7 @@ $ podman run -d --pod mypod --name webbing nginx
|
||||
$ alias docker=podman
|
||||
```
|
||||
|
||||
### 16.3.1 进阶用法
|
||||
### 17.3.1 进阶用法
|
||||
|
||||
本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
|
||||
|
||||
@@ -118,7 +118,7 @@ $ pip3 install podman-compose
|
||||
$ podman-compose up -d
|
||||
```
|
||||
|
||||
### 16.3.2 参考
|
||||
### 17.3.2 参考
|
||||
|
||||
* [Podman 官方网站](https://podman.io/)
|
||||
* [Podman GitHub 仓库](https://github.com/containers/podman)
|
||||
25
17_ecosystem/summary.md
Normal file
25
17_ecosystem/summary.md
Normal file
@@ -0,0 +1,25 @@
|
||||
## 17.4 本章小结
|
||||
|
||||
Docker 并非容器生态的唯一选择，了解其他工具有助于根据场景做出合适的技术选型。
|
||||
|
||||
| 项目 | 定位 | 特点 |
|
||||
|------|------|------|
|
||||
| **Fedora CoreOS** | 容器化操作系统 | 自动更新、不可变基础设施、专为运行容器设计 |
|
||||
| **Podman** | 容器引擎 | 无守护进程、兼容 Docker CLI、支持 Rootless 模式 |
|
||||
|
||||
### 17.4.1 Podman vs Docker
|
||||
|
||||
两者的主要区别：
|
||||
|
||||
| 对比项 | Docker | Podman |
|
||||
|--------|--------|--------|
|
||||
| **守护进程** | 需要 dockerd | 无需守护进程 |
|
||||
| **权限** | 默认需要 root | 原生支持 Rootless |
|
||||
| **CLI 兼容** | - | 与 Docker 命令兼容 |
|
||||
| **Pod 支持** | 不支持 | 原生支持 Pod 概念 |
|
||||
| **Compose** | docker compose | podman-compose 或兼容模式 |
|
||||
|
||||
### 17.4.2 延伸阅读
|
||||
|
||||
- [底层实现](../12_implementation/README.md)：容器技术的内核基础
|
||||
- [安全](../18_security/README.md)：容器安全实践
|
||||
@@ -1,4 +1,4 @@
|
||||
## 17.2 控制组
|
||||
## 18.2 控制组
|
||||
|
||||
控制组是 Linux 容器机制的另外一个关键组件，负责实现资源的审计和限制。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
## 17.3 Docker 服务端的防护
|
||||
## 18.3 Docker 服务端的防护
|
||||
|
||||
运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限，因此其安全性十分关键。
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user