mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-03-13 21:31:09 +00:00
Compare commits
13 Commits
ae398a88d8
...
40ded62baa
| Author | SHA1 | Date | |
|---|---|---|---|
|
40ded62baa | ||
|
|
89b0dc4425 | ||
|
|
330e084e00 | ||
|
|
e62b203f1a | ||
|
|
cb6bf74a2e | ||
|
|
a980e34276 | ||
|
|
3d33e00802 | ||
|
|
1a820c8c8b | ||
|
|
585b364574 | ||
|
|
a0a5de7f11 | ||
|
|
83ba6b7b47 | ||
|
|
53f20dede7 | ||
|
|
48c8b50cf7 |
12
.gitignore
vendored
12
.gitignore
vendored
@@ -21,11 +21,7 @@ docker-compose.override.yml
|
||||
__pycache__/
|
||||
|
||||
# Check scripts
|
||||
check_project_rules.py
|
||||
check_dashes.py
|
||||
checker.py
|
||||
find_lists_no_space.py
|
||||
fix_missing_spaces.py
|
||||
fix_project_rules.py
|
||||
fixer.py
|
||||
format_headings.py
|
||||
check*.py
|
||||
find*.py
|
||||
fix*.py
|
||||
format*.py
|
||||
|
||||
@@ -102,7 +102,7 @@ $ docker compose up
|
||||
|
||||
Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
|
||||
- **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
|
||||
- **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
|
||||
- **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
@@ -6,3 +6,6 @@
|
||||
- Docker 推动了容器技术的标准化 (OCI) 和生态发展
|
||||
|
||||
Docker 的核心价值可以用一句话概括：**让应用的开发、测试、部署保持一致，同时极大提高资源利用效率。** 笔者认为，对于现代软件开发者来说，Docker 已经不是 “要不要学” 的问题，而是 **必备技能**。无论你是前端、后端、运维还是全栈开发者，掌握 Docker 都能让你的工作更高效。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -56,7 +56,7 @@ flowchart TB
|
||||
一个完整的 Docker 镜像名称由 Registry 地址、用户名/组织名、仓库名和标签组成。了解其结构有助于我们更准确地定位镜像。基本格式如下：
|
||||
|
||||
```bash
|
||||
[registry地址/][用户名/]仓库名[:标签]
|
||||
[registry 地址/][用户名/]仓库名[:标签]
|
||||
```
|
||||
|
||||
示例：
|
||||
|
||||
@@ -28,10 +28,13 @@
|
||||
- [Dockerfile 最佳实践](../appendix/best_practices.md)：构建高质量镜像的技巧
|
||||
- [底层实现 - 联合文件系统](../12_implementation/12.4_ufs.md)：深入理解分层存储的技术原理
|
||||
- [启动容器](../05_container/5.1_run.md)：详细的容器启动选项
|
||||
- [后台运行](../05_container/5.2_daemon.md)：理解容器为什么会"立即退出"
|
||||
- [后台运行](../05_container/5.2_daemon.md)：理解容器为什么会“立即退出”
|
||||
- [进入容器](../05_container/5.4_attach_exec.md)：如何操作运行中的容器
|
||||
- [数据管理](../08_data/README.md)：Volume 和数据持久化详解
|
||||
- [Docker Hub](../06_repository/6.1_dockerhub.md)：Docker Hub 的详细使用
|
||||
- [私有仓库](../06_repository/6.2_registry.md)：搭建私有 Registry
|
||||
- [私有仓库高级配置](../06_repository/6.3_registry_auth.md)：认证、TLS 配置
|
||||
- [镜像加速器](../03_install/3.9_mirror.md)：配置镜像加速
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
|
||||
下载好之后双击 `Docker Desktop Installer.exe` 开始安装。
|
||||
|
||||
**使用** [**winget**](https://docs.microsoft.com/zh-cn/windows/package-manager/) **安装**
|
||||
**使用**[**winget**](https://docs.microsoft.com/zh-cn/windows/package-manager/)**安装**
|
||||
|
||||
```powershell
|
||||
$ winget install Docker.DockerDesktop
|
||||
|
||||
Binary file not shown.
@@ -25,3 +25,6 @@ $ docker run --rm hello-world
|
||||
- [镜像加速器](3.9_mirror.md)：解决国内拉取镜像慢的问题
|
||||
- [开启实验特性](3.10_experimental.md)：使用最新功能
|
||||
- [Docker Hub](../06_repository/6.1_dockerhub.md)：官方镜像仓库
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -31,3 +31,6 @@
|
||||
- [镜像](../02_basic_concept/2.1_image.md)：理解镜像概念
|
||||
- [删除容器](../05_container/5.6_rm.md)：清理容器
|
||||
- [数据卷](../08_data/8.1_volume.md)：清理数据卷
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -28,3 +28,6 @@
|
||||
- [数据管理](../08_data/README.md)：数据持久化方案
|
||||
- [删除镜像](../04_image/4.3_rm.md)：清理镜像
|
||||
- [数据卷](../08_data/8.1_volume.md)：数据卷管理
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -77,9 +77,9 @@ $ docker push username/myapp:v1
|
||||
| **免费账户** (已登录) | 每 6 小时 200 次请求 |
|
||||
| **Pro/Team 账户** | 无限制 |
|
||||
|
||||
#### 滥用限流 (Abuse Rate Limit)
|
||||
#### 滥用限流
|
||||
|
||||
除了上述针对特定账号拉取镜像数量的 Pull Rate Limit 之外，Docker Hub 对所有用户（包含已认证及付费用户）还实施了**滥用保护限流 (Abuse Rate Limiting)**。它是根据网络出口 IP (IPv4 或 IPv6 /64 子网) 计算整体请求频率，阈值动态触发（通常为每分钟数千级别请求）。
|
||||
除了上述针对特定账号拉取镜像数量的 Pull Rate Limit 之外，Docker Hub 对所有用户（包含已认证及付费用户）还实施了 **滥用保护限流 (Abuse Rate Limiting)**。它是根据网络出口 IP (IPv4 或 IPv6 /64 子网) 计算整体请求频率，阈值动态触发（通常为每分钟数千级别请求）。
|
||||
|
||||
**两类的差异与排查方法**：
|
||||
- **Pull Rate Limit**：针对拉取量达到上限。报错返回 `429 Too Many Requests`，并且 HTTP 返回体/CLI 错误提示中会带有明确的 `toomanyrequests: You have reached your pull rate limit` 提示，常附有账户升级链接。
|
||||
@@ -102,6 +102,7 @@ $ docker push username/myapp:v1
|
||||
在 Account Settings -> Security 中启用 2FA，保护账号安全。启用后，CLI 登录需要使用 **Access Token** 而非密码。
|
||||
|
||||
#### 2. 使用 Access Token
|
||||
|
||||
> **⚠️ 警告**：绝不要在脚本或 CI/CD 系统中，直接使用 `-p` 参数传递密码或 Token (类似 `docker login -p xxx`)！这会导致凭证直接暴露在系统的命令历史、进程列表和终端输出中。
|
||||
|
||||
1. 在 Docker Hub -> Account Settings -> Security -> Access Tokens 创建 Token (PAT)。
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@@ -5,7 +5,7 @@
|
||||
| 功能 | 说明 |
|
||||
|------|------|
|
||||
| **官方镜像** | 优先使用的基础镜像 |
|
||||
| **拉取限制** | 匿名 100次/6h，登录 200次/6h |
|
||||
| **拉取限制** | 匿名 100 次/6h，登录 200 次/6h |
|
||||
| **安全** | 推荐开启 2FA 并使用 Access Token |
|
||||
| **自动化** | 支持 Webhooks 和自动构建 |
|
||||
|
||||
@@ -13,3 +13,6 @@
|
||||
|
||||
- [私有仓库](6.2_registry.md)：搭建自己的 Registry
|
||||
- [镜像加速器](../03_install/3.9_mirror.md)：加速下载
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -1,7 +1,36 @@
|
||||
## 7.16 参考文档
|
||||
|
||||
* `Dockerfile` 官方文档：https://docs.docker.com/engine/reference/builder/
|
||||
### 官方文档
|
||||
|
||||
* `Dockerfile` 最佳实践文档：https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
|
||||
* `Dockerfile` 官方参考手册：https://docs.docker.com/engine/reference/builder/
|
||||
|
||||
* `Docker` 官方镜像 `Dockerfile`：https://github.com/docker-library/docs
|
||||
* `Dockerfile` 最佳实践指南：https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
|
||||
|
||||
* `Docker` 官方镜像 `Dockerfile` 库：https://github.com/docker-library/docs
|
||||
|
||||
### 常用指令总结
|
||||
|
||||
Dockerfile 中的常用指令包括：
|
||||
|
||||
- **FROM**: 指定基础镜像，必须是第一条指令
|
||||
- **RUN**: 在镜像中执行命令，用于安装软件包等
|
||||
- **WORKDIR**: 设置工作目录
|
||||
- **COPY/ADD**: 复制文件到镜像中
|
||||
- **EXPOSE**: 声明容器监听的端口
|
||||
- **ENV**: 设置环境变量
|
||||
- **ENTRYPOINT**: 容器启动时的入口点
|
||||
- **CMD**: 容器默认执行的命令
|
||||
|
||||
### 最佳实践建议
|
||||
|
||||
1. 使用具体的基础镜像版本标签而非 latest
|
||||
2. 最小化镜像层数，合并 RUN 指令
|
||||
3. 使用 .dockerignore 文件排除不必要的文件
|
||||
4. 安装必要的软件包后清理缓存
|
||||
5. 使用多阶段构建减小最终镜像体积
|
||||
6. 避免以 root 身份运行容器应用
|
||||
|
||||
### 相关资源
|
||||
|
||||
- Docker 官方镜像库：https://hub.docker.com/
|
||||
- Docker 镜像构建最佳实践：https://docs.docker.com/build/building/best-practices/
|
||||
|
||||
@@ -268,3 +268,7 @@ COPY . .
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **🔥 踩坑实录**
|
||||
>
|
||||
> 某公司在优化 Node.js 应用的 Docker 镜像时，发现构建出来的镜像体积超过了 2GB，远远超过生产部署的需求。排查发现，Dockerfile 中使用了 `COPY . .` 把整个构建上下文复制进镜像，导致 `node_modules/`、`.git/` 目录和大量测试数据全部被打包进镜像。最初他们没有创建 `.dockerignore` 文件，默认会复制所有文件。解决方案是添加一个 `.dockerignore` 文件，排除这些不必要的目录，使镜像缩小到了 200MB。这个教训深刻地说明了：`.dockerignore` 和 `.gitignore` 一样重要，应该在项目初始化时就创建，而不是等到出现问题时才想起来。建议的标准做法是先复制 `package.json` 和 `package-lock.json` 安装依赖，再复制应用代码，同时在 `.dockerignore` 中明确列出 `node_modules`、`.git`、test 目录等。
|
||||
|
||||
@@ -103,7 +103,7 @@ VOLUME /data
|
||||
RUN echo "hello" > /data/test.txt
|
||||
```
|
||||
|
||||
**原因**：VOLUME 指令之后，Docker 将该目录视为外部挂载点，不再记录对它的修改。
|
||||
**原因**：在构建过程中，VOLUME 指令会为该目录创建一个临时的匿名卷。后续 RUN 指令对该目录的写入实际发生在这个临时卷中，而非镜像层。当该 RUN 指令结束后，临时卷被丢弃，因此写入的内容不会保存到最终镜像中。注意：这与容器运行时创建的匿名卷是不同的——运行时创建的卷会在容器生命周期内持续存在。
|
||||
|
||||
#### 正确做法
|
||||
|
||||
|
||||
@@ -28,3 +28,6 @@
|
||||
- [Dockerfile 最佳实践](../appendix/best_practices.md)：编写指南
|
||||
- [安全](../18_security/README.md)：容器安全实践
|
||||
- [Compose 模板文件](../11_compose/11.5_compose_file.md)：Compose 中的配置
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -139,10 +139,10 @@ $ docker run -d \
|
||||
|------|---------|-----|
|
||||
| 语法 | 键值对，更清晰 | 冒号分隔，更简洁 |
|
||||
| **数据卷 (Volume)** 挂载行为 | 卷不存在会自动创建，与 `-v` 结果一致 | 卷不存在会自动创建 |
|
||||
| **绑定挂载 (Bind Mount)** 行为 | ⭐ **宿主机路径不存在会报错**，不会自动创建 | 宿主机路径不存在会**自动创建为目录** |
|
||||
| **绑定挂载 (Bind Mount)** 行为 | ⭐**宿主机路径不存在会报错**，不会自动创建 | 宿主机路径不存在会 **自动创建为目录** |
|
||||
| 推荐程度 | ✅ 推荐 (更明确安全，避免误创建)| 常用 (更简洁)|
|
||||
|
||||
> **提示**：官方更推荐使用 `--mount`。除了语法格式可读性更好之外，最重要的行为差异发生在 **绑定挂载 (Bind Mount)** 时：如果挂载的宿主机源路径尚未存在，`-v` 会擅自将其自动创建为一个空目录；而 `--mount` 则会严格检查并直接报错。这能有效避免因路径拼写错误而在宿主机上留下垃圾目录（以及导致的容器访问空目录问题）。而对于本节的**数据卷 (Volume)** 挂载而言，两者在目标指定的卷不存在时皆会自动创建卷，产生的结果是**完全一致**的。
|
||||
> **提示**：官方更推荐使用 `--mount`。除了语法格式可读性更好之外，最重要的行为差异发生在 **绑定挂载 (Bind Mount)** 时：如果挂载的宿主机源路径尚未存在，`-v` 会擅自将其自动创建为一个空目录；而 `--mount` 则会严格检查并直接报错。这能有效避免因路径拼写错误而在宿主机上留下垃圾目录（以及导致的容器访问空目录问题）。而对于本节的 **数据卷 (Volume)** 挂载而言，两者在目标指定的卷不存在时皆会自动创建卷，产生的结果是 **完全一致** 的。
|
||||
|
||||
#### 只读挂载
|
||||
|
||||
|
||||
@@ -74,10 +74,10 @@ $ docker run -d \
|
||||
| 特性 | --mount | -v |
|
||||
|------|---------|-----|
|
||||
| 语法 | 键值对，更清晰 | 冒号分隔，更简洁 |
|
||||
| 路径不存在时 | 直接报错 (Fail Fast) | 静默自动创建**目录** |
|
||||
| 路径不存在时 | 直接报错 (Fail Fast) | 静默自动创建 **目录** |
|
||||
| 推荐程度 | ✅ 推荐 | 常用 |
|
||||
|
||||
> **⚠️ 陷阱**：如果不小心挂载了一个不存在的宿主机路径，使用 `-v` 会在宿主机上静默创建一个**空目录**（即使你本来想挂载的是一个文件），这常常会导致权限错误或应用无法正常读取。这也正是为什么 Docker 官方更推荐使用 `--mount` 的原因：它会遵循“Fail Fast”原则直接报错，避免弄巧成拙。
|
||||
> **⚠️ 陷阱**：如果不小心挂载了一个不存在的宿主机路径，使用 `-v` 会在宿主机上静默创建一个 **空目录**（即使你本来想挂载的是一个文件），这常常会导致权限错误或应用无法正常读取。这也正是为什么 Docker 官方更推荐使用 `--mount` 的原因：它会遵循“Fail Fast”原则直接报错，避免弄巧成拙。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -10,16 +10,20 @@
|
||||
|
||||
### 8.3.2 基本用法
|
||||
|
||||
```bash
|
||||
$ docker run --tmpfs /run:rw,noexec,nosuid,size=64m nginx
|
||||
```
|
||||
|
||||
也可以使用 `--mount` 语法：
|
||||
使用 `--mount` 语法（推荐）：
|
||||
|
||||
```bash
|
||||
$ docker run --mount type=tmpfs,destination=/run,tmpfs-size=67108864 nginx
|
||||
$ docker run --mount type=tmpfs,destination=/run,tmpfs-size=67108864,tmpfs-mode=1770 nginx
|
||||
```
|
||||
|
||||
也可以使用 `--tmpfs` 简写语法：
|
||||
|
||||
```bash
|
||||
$ docker run --tmpfs /run:size=64m nginx
|
||||
```
|
||||
|
||||
> **注意**：`--tmpfs` 支持的选项有限，主要为 `size` 和 `mode`。如果需要更精细的控制（如 `noexec`、`nosuid`），推荐使用 `--mount` 语法并通过 `tmpfs-mode` 参数设置权限。
|
||||
|
||||
### 8.3.3 注意事项
|
||||
|
||||
- 容器停止后，`tmpfs` 数据会丢失。
|
||||
|
||||
@@ -24,3 +24,6 @@
|
||||
- [tmpfs 挂载](8.3_tmpfs.md)：内存中的临时存储
|
||||
- [存储驱动](../12_implementation/12.4_ufs.md)：Docker 存储的底层原理
|
||||
- [Compose 数据管理](../11_compose/11.5_compose_file.md)：Compose 中的挂载配置
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -9,7 +9,7 @@ Docker 1.10.0 以后，内建了一个 DNS 服务器，使得容器可以直接
|
||||
Docker 容器的 DNS 配置有两种情况：
|
||||
|
||||
1. **默认 Bridge 网络**：继承宿主机的 DNS 配置 (`/etc/resolv.conf`)。
|
||||
2. **自定义网络** (推荐)：使用 Docker 嵌入式 DNS 服务器 (Embedded DNS)，支持通过 **容器名** 进行服务发现。
|
||||
2. **自定义网络**(推荐)：使用 Docker 嵌入式 DNS 服务器 (Embedded DNS)，支持通过 **容器名** 进行服务发现。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -91,3 +91,9 @@ $ docker network rm mynet
|
||||
|
||||
$ docker network prune
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **🔥 踩坑实录**
|
||||
>
|
||||
> 一个新手开发者通过 `docker-compose` 部署了两个容器化服务：服务 A 和服务 B。他在服务 A 的代码中尝试用 `localhost:3000` 访问服务 B，结果始终连接超时。这个错误非常隐蔽——在本地单机开发时看不出问题，因为他可能在同一个进程中测试。排查时他错误地认为是防火墙或网络配置问题。实际原因是：每个容器都有独立的网络命名空间，`localhost` 在容器内部只指向容器自己，不是宿主机也不是其他容器。正确的做法是使用 docker-compose 自动创建的服务名作为主机名：`http://service-b:3000`。`docker-compose` 会自动在网络中注册服务名的 DNS，这样容器间通信才能正确解析。改动仅需一行代码，问题随之消失。
|
||||
|
||||
@@ -22,3 +22,6 @@
|
||||
- [网络隔离](9.6_network_isolation.md)：网络安全与隔离策略
|
||||
- [EXPOSE 指令](../07_dockerfile/7.9_expose.md)：在 Dockerfile 中声明端口
|
||||
- [Compose 网络](../11_compose/11.5_compose_file.md)：Compose 中的网络配置
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -41,11 +41,11 @@ $ docker buildx build --sbom=true -t myimage .
|
||||
> **⚠️ 注意与失败模式**：
|
||||
> 要使 SBOM (或其它 attestation 元数据) 成功附着并可见，对底层的存储格式有前置要求：默认的 classic image store 不支持 manifest list/index 这种存放 attestation 的结构。
|
||||
>
|
||||
> 如果只简单运行上述命令，你可能会面临**“命令成功执行，但本地镜像中看不到 SBOM”**的体会落差。
|
||||
> 如果只简单运行上述命令，你可能会面临 **“命令成功执行，但本地镜像中看不到 SBOM”** 的体会落差。
|
||||
>
|
||||
> **正确的解决路径有两条**：
|
||||
> 1. 在 Docker 守护进程中启用 `containerd image store` 特性（现代 Docker Desktop 默认推荐）。
|
||||
> 2. 或者使用 `docker-container` driver 的构建器，并直接**加上 `--push` 参数**将产物推送到远端支持 OCI 的镜像仓库，仓库会正确保存这些元数据。
|
||||
> 2. 或者使用 `docker-container` driver 的构建器，并直接 **加上 `--push` 参数** 将产物推送到远端支持 OCI 的镜像仓库，仓库会正确保存这些元数据。
|
||||
|
||||
### 10.2.2 官方文档
|
||||
|
||||
|
||||
@@ -17,3 +17,6 @@ Docker Buildx 是 Docker 构建系统的重要进化，提供了高效、安全
|
||||
- [Dockerfile 指令详解](../07_dockerfile/README.md)：Dockerfile 编写基础
|
||||
- [多阶段构建](../07_dockerfile/7.17_multistage_builds.md)：优化镜像体积
|
||||
- [Dockerfile 最佳实践](../appendix/best_practices.md)：编写高效 Dockerfile
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -18,12 +18,12 @@ Linux 系统请使用以下介绍的方法安装。
|
||||
|
||||
> **提示**：版本更新较快，请访问上述链接获取最新版本号，替换下方命令中的版本号。
|
||||
|
||||
例如，在 Linux 64 位系统上直接下载对应的二进制包 (以 v5.0.2 为例)。
|
||||
例如，在 Linux 64 位系统上直接下载对应的二进制包 (以 v5.1.0 为例)。
|
||||
|
||||
```bash
|
||||
$ DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
|
||||
$ mkdir -p $DOCKER_CONFIG/cli-plugins
|
||||
$ curl -SL https://github.com/docker/compose/releases/download/v5.0.2/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose
|
||||
$ curl -SL https://github.com/docker/compose/releases/download/v5.1.0/docker-compose-linux-x86_64 -o $DOCKER_CONFIG/cli-plugins/docker-compose
|
||||
```
|
||||
|
||||
之后，执行
|
||||
@@ -36,13 +36,13 @@ $ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
|
||||
|
||||
```bash
|
||||
$ docker compose version
|
||||
Docker Compose version v5.0.2
|
||||
Docker Compose version v5.1.0
|
||||
```
|
||||
|
||||
### 11.2.3 bash 补全命令
|
||||
|
||||
```bash
|
||||
$ 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
|
||||
$ curl -L https://raw.githubusercontent.com/docker/compose/v5.1.0/contrib/completion/bash/docker-compose | sudo tee /etc/bash_completion.d/docker-compose > /dev/null
|
||||
```
|
||||
|
||||
### 11.2.4 卸载
|
||||
|
||||
@@ -19,3 +19,6 @@ Docker Compose 是管理多容器应用的利器，通过 YAML 文件声明式
|
||||
- [Compose 命令说明](11.4_commands.md)：完整命令列表
|
||||
- [网络配置](../09_network/README.md)：Docker 网络基础
|
||||
- [数据管理](../08_data/README.md)：数据卷管理
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -35,10 +35,11 @@ flowchart LR
|
||||
|
||||
| 时间 | 事件 |
|
||||
|------|------|
|
||||
| 2006 | Google 工程师提出 cgroups 概念 |
|
||||
| 2008 | Linux 2.6.24 正式支持 cgroups v1 |
|
||||
| 2006 | Google 工程师提出 "process containers" 概念 |
|
||||
| 2007 | 为避免与 Linux 容器概念混淆，更名为 "control groups" (cgroups) |
|
||||
| 2008 | Linux 2.6.24（2008年1月）正式合并 cgroups v1 |
|
||||
| 2016 | Linux 4.5 引入 cgroups v2 |
|
||||
| 现在 | Docker 默认使用 cgroups v2 (如系统支持)|
|
||||
| 现在 | Docker 在宿主机支持 cgroups v2 时会自动使用 v2，否则回退到 v1 |
|
||||
|
||||
---
|
||||
|
||||
@@ -265,7 +266,7 @@ $ docker run -d --name cadvisor \
|
||||
-v /var/run:/var/run:ro \
|
||||
-v /sys:/sys:ro \
|
||||
-v /var/lib/docker:/var/lib/docker:ro \
|
||||
gcr.io/cadvisor/cadvisor
|
||||
ghcr.io/google/cadvisor
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -34,3 +34,6 @@
|
||||
- [镜像](../02_basic_concept/2.1_image.md)：理解镜像分层
|
||||
- [容器](../02_basic_concept/2.2_container.md)：容器存储层
|
||||
- [构建镜像](../04_image/4.5_build.md)：Dockerfile 层的创建
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -17,3 +17,6 @@ Kubernetes 是当前最主流的容器编排平台，其声明式管理模型和
|
||||
- [部署 Kubernetes](../14_kubernetes_setup/README.md)：搭建 Kubernetes 集群
|
||||
- [Etcd](../15_etcd/README.md)：Kubernetes 使用的分布式存储
|
||||
- [底层实现](../12_implementation/README.md)：容器技术原理
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -445,7 +445,7 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
```
|
||||
|
||||
```bash
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.1/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
### 14.1.10 master 节点默认不能运行 pod
|
||||
|
||||
@@ -215,7 +215,7 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
```
|
||||
|
||||
```bash
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.1/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
### 14.2.9 master 节点默认不能运行 pod
|
||||
|
||||
@@ -15,3 +15,6 @@
|
||||
- [容器编排基础](../13_kubernetes_concepts/README.md)：Kubernetes 核心概念
|
||||
- [Dashboard](14.7_dashboard.md)：部署可视化管理界面
|
||||
- [kubectl](14.8_kubectl.md)：命令行工具使用指南
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
`etcd` 基于 `Go` 语言实现，因此，用户可以从[项目主页](https://github.com/etcd-io/etcd)下载源代码自行编译，也可以下载编译好的二进制文件，甚至直接使用制作好的 `Docker` 镜像文件来体验。
|
||||
|
||||
>注意：本章节内容基于 etcd `3.4.x` 版本
|
||||
>注意：本章节内容基于 etcd `3.4.x` 版本编写。etcd 3.4 的官方支持将于 **2026 年 5 月 15 日结束**，新部署建议使用 etcd `3.5` 或 `3.6` 版本。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本。
|
||||
|
||||
### 15.2.1 二进制文件方式下载
|
||||
|
||||
|
||||
@@ -15,3 +15,6 @@ etcd 是 Kubernetes 的核心存储组件，为分布式系统提供可靠的键
|
||||
|
||||
- [容器编排基础](../13_kubernetes_concepts/README.md)：Kubernetes 如何使用 etcd
|
||||
- [部署 Kubernetes](../14_kubernetes_setup/README.md)：在集群中部署 etcd
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -15,3 +15,199 @@
|
||||
|
||||
|
||||
图 13-6 腾讯云容器服务示意图
|
||||
|
||||
### 腾讯云容器服务 (TKE) 简介
|
||||
|
||||
腾讯云容器服务 (TKE, Tencent Kubernetes Engine) 是一款容器编排平台，基于原生 Kubernetes 提供，支持自动扩展、负载均衡、多可用区高可用等企业级功能。TKE 帮助开发者快速部署和管理容器化应用，消除集群运维的复杂度。
|
||||
|
||||
### 基本使用步骤
|
||||
|
||||
#### 1. 创建集群
|
||||
|
||||
登录腾讯云控制台，进入容器服务模块：
|
||||
- 选择 "创建集群"，配置集群名称、地域和网络
|
||||
- 选择节点配置（云服务器规格和数量）
|
||||
- 设置 Kubernetes 版本和安全组
|
||||
- 完成创建后获得集群 kubeconfig 文件
|
||||
|
||||
```bash
|
||||
# 下载 kubeconfig 文件后，配置本地环境
|
||||
export KUBECONFIG=/path/to/kubeconfig.yaml
|
||||
kubectl cluster-info
|
||||
```
|
||||
|
||||
#### 2. 部署容器应用
|
||||
|
||||
创建 Deployment 部署应用：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: nginx-app
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx:latest
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
应用配置文件：
|
||||
|
||||
```bash
|
||||
kubectl apply -f deployment.yaml
|
||||
kubectl get pods
|
||||
kubectl get svc
|
||||
```
|
||||
|
||||
#### 3. 管理镜像
|
||||
|
||||
通过腾讯云容器镜像服务 (TCR) 存储和管理私有镜像：
|
||||
|
||||
```bash
|
||||
# 登录腾讯云镜像仓库
|
||||
docker login ccr.ccs.tencentyun.com -u <username>
|
||||
|
||||
# 标记本地镜像
|
||||
docker tag my-app:latest ccr.ccs.tencentyun.com/namespace/my-app:latest
|
||||
|
||||
# 推送镜像到腾讯云
|
||||
docker push ccr.ccs.tencentyun.com/namespace/my-app:latest
|
||||
```
|
||||
|
||||
### 腾讯云 Docker 镜像加速器配置
|
||||
|
||||
为了加快镜像拉取速度，腾讯云提供了镜像加速服务。配置方法如下：
|
||||
|
||||
#### Linux 系统配置
|
||||
|
||||
编辑 `/etc/docker/daemon.json` 文件（如果不存在则创建）：
|
||||
|
||||
```bash
|
||||
# 创建或编辑配置文件
|
||||
sudo mkdir -p /etc/docker
|
||||
sudo nano /etc/docker/daemon.json
|
||||
```
|
||||
|
||||
添加以下内容：
|
||||
|
||||
```json
|
||||
{
|
||||
"registry-mirrors": [
|
||||
"https://mirror.ccs.tencentyun.com"
|
||||
],
|
||||
"insecure-registries": []
|
||||
}
|
||||
```
|
||||
|
||||
重启 Docker 服务：
|
||||
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
验证配置：
|
||||
|
||||
```bash
|
||||
# 查看镜像源是否生效
|
||||
docker info | grep -A 5 "Registry Mirrors"
|
||||
```
|
||||
|
||||
#### Windows/Mac 配置
|
||||
|
||||
对于 Docker Desktop，在设置界面中：
|
||||
1. 打开 Docker Desktop 设置
|
||||
2. 导航到 "Docker Engine"
|
||||
3. 在 JSON 配置中添加上述 `registry-mirrors` 字段
|
||||
4. 点击 "Apply & Restart"
|
||||
|
||||
### 腾讯云容器镜像服务 (TCR)
|
||||
|
||||
腾讯云容器镜像服务 (TCR) 提供企业级容器镜像存储和分发能力：
|
||||
|
||||
- **私有镜像仓库**：支持命名空间隔离，完整的访问权限控制
|
||||
- **镜像扫描**：自动扫描镜像漏洞，提供安全建议
|
||||
- **镜像加速**：支持跨地域镜像分发和加速
|
||||
- **Webhook 通知**：镜像推送时自动触发 CI/CD 流程
|
||||
- **镜像版本管理**：标签管理、镜像清理策略、生命周期管理
|
||||
|
||||
#### 快速开始
|
||||
|
||||
1. 在腾讯云控制台创建个人版或企业版 TCR 实例
|
||||
2. 创建命名空间和镜像仓库
|
||||
3. 配置 Docker 登录凭证
|
||||
4. 本地构建镜像并推送到 TCR
|
||||
5. 在 TKE 集群部署时引用 TCR 镜像地址
|
||||
|
||||
#### 完整推送/拉取示例
|
||||
|
||||
```bash
|
||||
# 登录到腾讯云 TCR（使用 API 密钥）
|
||||
docker login ccr.ccs.tencentyun.com \
|
||||
--username <腾讯云账号ID> \
|
||||
--password <API_KEY>
|
||||
|
||||
# 拉取公开镜像
|
||||
docker pull ccr.ccs.tencentyun.com/library/nginx:latest
|
||||
|
||||
# 构建本地镜像
|
||||
docker build -t my-app:v1.0 .
|
||||
|
||||
# 标记镜像为 TCR 地址
|
||||
docker tag my-app:v1.0 \
|
||||
ccr.ccs.tencentyun.com/my-namespace/my-app:v1.0
|
||||
|
||||
# 推送镜像到 TCR
|
||||
docker push ccr.ccs.tencentyun.com/my-namespace/my-app:v1.0
|
||||
|
||||
# 在 Dockerfile 中使用 TCR 镜像
|
||||
FROM ccr.ccs.tencentyun.com/my-namespace/my-app:v1.0
|
||||
RUN echo "使用腾讯云镜像作为基础镜像"
|
||||
```
|
||||
|
||||
#### TKE 集群中使用 TCR 镜像
|
||||
|
||||
配置镜像拉取凭证后，在 Deployment 中直接引用 TCR 镜像：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: my-app-deployment
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: my-app
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: my-app
|
||||
spec:
|
||||
imagePullSecrets:
|
||||
- name: tcr-secret # 需提前创建该 Secret
|
||||
containers:
|
||||
- name: my-app
|
||||
image: ccr.ccs.tencentyun.com/my-namespace/my-app:v1.0
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
resources:
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "100m"
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
```
|
||||
|
||||
@@ -15,3 +15,256 @@
|
||||
|
||||
|
||||
图 13-4 阿里云容器服务示意图
|
||||
|
||||
### 阿里云容器服务 ACK 简介
|
||||
|
||||
阿里云容器服务 Kubernetes 版 (ACK, Container Service for Kubernetes) 是一款托管式 Kubernetes 服务，基于开源 Kubernetes 构建，提供企业级的容器编排和管理能力。ACK 集成了阿里云存储、网络和安全能力，支持多种应用部署模式和持续交付流程。
|
||||
|
||||
### 基本使用步骤
|
||||
|
||||
#### 1. 创建集群
|
||||
|
||||
登录阿里云控制台，进入容器服务 > Kubernetes 集群：
|
||||
- 点击 "创建集群"，选择集群配置
|
||||
- 配置集群名称、地域、可用区和节点类型
|
||||
- 选择节点规格和数量（支持弹性伸缩）
|
||||
- 配置网络参数和安全设置
|
||||
- 完成创建，下载 kubeconfig 文件
|
||||
|
||||
```bash
|
||||
# 配置本地 kubectl
|
||||
export KUBECONFIG=/path/to/kubeconfig.yaml
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
#### 2. 部署容器应用
|
||||
|
||||
通过 Deployment 部署应用示例：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: web-server
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: web
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: web
|
||||
spec:
|
||||
containers:
|
||||
- name: web
|
||||
image: registry.cn-hangzhou.aliyuncs.com/myapp/web:v1
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
resources:
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
```
|
||||
|
||||
部署应用：
|
||||
|
||||
```bash
|
||||
kubectl apply -f deployment.yaml
|
||||
kubectl get pods -o wide
|
||||
kubectl logs <pod-name>
|
||||
```
|
||||
|
||||
#### 3. 暴露服务
|
||||
|
||||
创建 Service 暴露应用：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: web-service
|
||||
spec:
|
||||
type: LoadBalancer
|
||||
ports:
|
||||
- port: 80
|
||||
targetPort: 8080
|
||||
selector:
|
||||
app: web
|
||||
```
|
||||
|
||||
应用：
|
||||
|
||||
```bash
|
||||
kubectl apply -f service.yaml
|
||||
kubectl get svc web-service
|
||||
```
|
||||
|
||||
### 阿里云 Docker 镜像加速器配置
|
||||
|
||||
为了加快从阿里云镜像源拉取官方镜像的速度，可以配置镜像加速器。阿里云为容器服务 ACK 用户提供了免费的镜像加速服务。
|
||||
|
||||
#### 获取加速器地址
|
||||
|
||||
登录阿里云容器镜像服务控制台，在 "镜像工具" > "镜像加速器" 中可获取个人的加速器地址（类似于 `https://xxxxxx.mirror.aliyuncs.com`）。
|
||||
|
||||
#### Linux 系统配置
|
||||
|
||||
编辑或创建 `/etc/docker/daemon.json` 文件：
|
||||
|
||||
```bash
|
||||
sudo mkdir -p /etc/docker
|
||||
sudo nano /etc/docker/daemon.json
|
||||
```
|
||||
|
||||
添加或修改以下内容（替换为你的加速器地址）：
|
||||
|
||||
```json
|
||||
{
|
||||
"registry-mirrors": [
|
||||
"https://xxxxxx.mirror.aliyuncs.com"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
重新加载并重启 Docker：
|
||||
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
验证配置生效：
|
||||
|
||||
```bash
|
||||
docker info | grep -A 5 "Registry Mirrors"
|
||||
```
|
||||
|
||||
#### Windows/Mac 配置
|
||||
|
||||
在 Docker Desktop 的 Settings 中：
|
||||
1. 进入 "Docker Engine" 标签
|
||||
2. 编辑 JSON 配置，添加 `registry-mirrors` 字段
|
||||
3. 点击 "Apply & Restart"
|
||||
|
||||
#### 测试加速效果
|
||||
|
||||
```bash
|
||||
# 从加速器拉取镜像（速度应该明显提升）
|
||||
docker pull nginx:latest
|
||||
time docker pull alpine:latest
|
||||
```
|
||||
|
||||
### 阿里云容器镜像服务 (ACR)
|
||||
|
||||
阿里云容器镜像服务 (ACR, Container Registry) 是企业级的容器镜像存储和分发平台：
|
||||
|
||||
- **私有镜像仓库**：支持多个命名空间，细粒度权限控制
|
||||
- **镜像构建**：云端编译和构建，支持自动化 CI/CD
|
||||
- **镜像扫描**：自动检测镜像中的漏洞和恶意代码
|
||||
- **跨地域复制**：支持镜像在多个地域的同步和加速
|
||||
- **集成 ACK**：与 ACK 无缝集成，自动身份认证
|
||||
- **镜像版本管理**：标签管理、镜像过期清理、保留策略
|
||||
|
||||
#### 完整推送/拉取示例
|
||||
|
||||
```bash
|
||||
# 登录阿里云镜像仓库（使用 Docker 登录）
|
||||
# 使用阿里云账户 ID 和 RAM 访问密钥或密码
|
||||
docker login registry.cn-hangzhou.aliyuncs.com \
|
||||
--username=<阿里云账户ID>
|
||||
|
||||
# 拉取阿里云公开镜像
|
||||
docker pull registry.cn-hangzhou.aliyuncs.com/library/nginx:latest
|
||||
|
||||
# 构建本地镜像
|
||||
docker build -t my-app:v1.0 .
|
||||
|
||||
# 标记镜像为阿里云仓库地址
|
||||
docker tag my-app:v1.0 \
|
||||
registry.cn-hangzhou.aliyuncs.com/myapp/my-app:v1.0
|
||||
|
||||
# 推送镜像到阿里云 ACR
|
||||
docker push registry.cn-hangzhou.aliyuncs.com/myapp/my-app:v1.0
|
||||
|
||||
# 在 Dockerfile 中使用 ACR 镜像
|
||||
FROM registry.cn-hangzhou.aliyuncs.com/myapp/my-app:v1.0
|
||||
COPY . /app
|
||||
RUN echo "已成功使用阿里云镜像"
|
||||
```
|
||||
|
||||
#### ACK 集群中使用 ACR 镜像
|
||||
|
||||
在 ACK 集群中，需要先配置镜像拉取凭证（Secret），然后在 Deployment 中引用：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: web-server
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: web
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: web
|
||||
spec:
|
||||
# 如果是私有镜像，需配置镜像拉取凭证
|
||||
imagePullSecrets:
|
||||
- name: acr-secret
|
||||
containers:
|
||||
- name: web
|
||||
image: registry.cn-hangzhou.aliyuncs.com/myapp/web:v2.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
resources:
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "100m"
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
affinity:
|
||||
# 配置 Pod 反亲和性，分散到不同节点
|
||||
podAntiAffinity:
|
||||
preferredDuringSchedulingIgnoredDuringExecution:
|
||||
- weight: 100
|
||||
podAffinityTerm:
|
||||
labelSelector:
|
||||
matchExpressions:
|
||||
- key: app
|
||||
operator: In
|
||||
values:
|
||||
- web
|
||||
topologyKey: kubernetes.io/hostname
|
||||
```
|
||||
|
||||
#### 创建镜像拉取凭证
|
||||
|
||||
在 ACK 集群中创建 Secret，用于拉取私有镜像：
|
||||
|
||||
```bash
|
||||
# 创建镜像拉取 Secret
|
||||
kubectl create secret docker-registry acr-secret \
|
||||
--docker-server=registry.cn-hangzhou.aliyuncs.com \
|
||||
--docker-username=<阿里云账户ID> \
|
||||
--docker-password=<RAM访问密钥或密码> \
|
||||
--docker-email=<邮箱地址>
|
||||
|
||||
# 查看创建的 Secret
|
||||
kubectl get secret acr-secret
|
||||
kubectl describe secret acr-secret
|
||||
```
|
||||
|
||||
#### ACR 优势
|
||||
|
||||
- 在 ACK 集群中与镜像仓库无缝集成，简化身份认证
|
||||
- 支持 Helm Chart 存储和版本管理，方便应用交付
|
||||
- 提供完整的图形化镜像仓库管理界面
|
||||
- 完整的审计日志和操作追踪功能
|
||||
- 支持镜像自动扫描和漏洞报告
|
||||
|
||||
@@ -11,3 +11,6 @@
|
||||
* 利用公有云和 Docker 的特性更加方便的迁移和扩展应用。
|
||||
|
||||
同时，容器将作为与虚拟机类似的业务直接提供给用户使用，极大的丰富了应用开发和部署的场景。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -21,4 +21,3 @@ FCOS 使用 rpm-ostree 系统进行事务性升级。无需像 yum 升级那样
|
||||
#### 容器工具
|
||||
|
||||
对于诸如构建，复制和其他管理容器的任务，FCOS 用一组容器工具代替了 **Docker CLI**。**podman CLI** 工具支持许多容器运行时功能，例如运行，启动，停止，列出和删除容器和镜像。**skopeo CLI** 工具可以复制，认证和签名镜像。您还可以使用 **crictl CLI** 工具来处理 CRI-O 容器引擎中的容器和镜像。
|
||||
|
||||
|
||||
Binary file not shown.
@@ -28,3 +28,6 @@ Docker 并非容器生态的唯一选择，了解其他工具有助于根据场
|
||||
|
||||
- [底层实现](../12_implementation/README.md)：容器技术的内核基础
|
||||
- [安全](../18_security/README.md)：容器安全实践
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 18.1 内核命名空间
|
||||
|
||||
命名空间 (Namespace) 是 Linux 容器隔离的基础，它确保了容器内的进程无法直接干扰主机或其他容器。虽然在本书第 12 章中我们已经从底层实现的角度介绍了 Namespace，但在本节中，我们将重点探讨其**安全意义**及相关配置。
|
||||
命名空间 (Namespace) 是 Linux 容器隔离的基础，它确保了容器内的进程无法直接干扰主机或其他容器。虽然在本书第 12 章中我们已经从底层实现的角度介绍了 Namespace，但在本节中，我们将重点探讨其 **安全意义** 及相关配置。
|
||||
|
||||
### 18.1.1 隔离的安全本质
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## 18.2 控制组
|
||||
|
||||
控制组 (Cgroups) 是 Linux 容器机制的另外一个关键组件。如果说命名空间 (Namespace) 决定了容器能**看到**什么，那么控制组就决定了容器能**使用**多少资源。
|
||||
控制组 (Cgroups) 是 Linux 容器机制的另外一个关键组件。如果说命名空间 (Namespace) 决定了容器能 **看到** 什么，那么控制组就决定了容器能 **使用** 多少资源。
|
||||
|
||||
在安全领域中，资源的不可用性本身就是一种安全威胁。控制组负责实现资源的审计和限制，这对于抵御资源耗尽型攻击（如拒绝服务攻击 DoS）至关重要。
|
||||
|
||||
@@ -17,7 +17,7 @@
|
||||
|
||||
### 18.2.2 核心资源限制实战
|
||||
|
||||
为了确保多租户平台（如公有或私有的 PaaS 平台）的稳定性，或者在生产环境防止服务级联故障，我们要养成在启动容器时**显式声明资源上限**的习惯。
|
||||
为了确保多租户平台（如公有或私有的 PaaS 平台）的稳定性，或者在生产环境防止服务级联故障，我们要养成在启动容器时 **显式声明资源上限** 的习惯。
|
||||
|
||||
#### 1. 内存限制
|
||||
|
||||
|
||||
@@ -83,4 +83,4 @@ $ docker version
|
||||
|
||||
### 18.3.4 结语
|
||||
|
||||
保障 Docker 服务端的安全主要是做减法：关闭不必要的网络监听点，严管 Socket 访问权限。而一旦基础系统条件允许，**毫不犹豫地在生产环境启用 Rootless 模式**将是一项划算的安全加固选择。
|
||||
保障 Docker 服务端的安全主要是做减法：关闭不必要的网络监听点，严管 Socket 访问权限。而一旦基础系统条件允许，**毫不犹豫地在生产环境启用 Rootless 模式** 将是一项划算的安全加固选择。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
### 18.4.1 容器内置的 Capability 白名单
|
||||
|
||||
在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的**一小部分“白名单”能力**。
|
||||
在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。
|
||||
|
||||
常见的 Linux Capabilities 包含：
|
||||
- `CAP_CHOWN`: 修改文件所有者。
|
||||
@@ -14,7 +14,7 @@
|
||||
- `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
|
||||
- `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。
|
||||
|
||||
为了在**“最小特权原则”**的指导下加强安全，Docker 默认**移除了**大量可能导致容器大范围破坏宿主机的能力，例如：
|
||||
为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
|
||||
* 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
|
||||
* 禁止修改内核模块。
|
||||
* 禁止直接访问硬件套接字。
|
||||
@@ -27,7 +27,7 @@
|
||||
|
||||
#### 实战场景一：构建极限安全的 Web 靶机
|
||||
|
||||
假设你正在提供一个公共的 Web 容器。你不希望里面的任何恶意脚本修改进程权限或者创建设备节点，你可以通过命令先移除**所有**默认能力，然后再按需授权该守护进程一个仅仅能绑端口的能力。
|
||||
假设你正在提供一个公共的 Web 容器。你不希望里面的任何恶意脚本修改进程权限或者创建设备节点，你可以通过命令先移除 **所有** 默认能力，然后再按需授权该守护进程一个仅仅能绑端口的能力。
|
||||
|
||||
```bash
|
||||
$ docker run -d \
|
||||
@@ -56,7 +56,7 @@ $ docker run -it --rm \
|
||||
我们只授予了所需的网络管理控制（NET_ADMIN）和侦听底层套接字的权限（NET_RAW），而免去了赋予整个容器终极杀器 `--privileged` 参数。
|
||||
|
||||
> [!WARNING]
|
||||
> 大量开发人员遇到了“权限遭到拒绝”的错误时，往往习惯性图省事添加 `--privileged` 这个核选项。但这将把**宿主机上一切特权和所有访问设备完全投射给容器内的根用户**，其危险性等价于根本没有做隔离！请务必查明进程出错的实际原因，精准施加必要的隔离 `CAP_*` 能力。
|
||||
> 大量开发人员遇到了“权限遭到拒绝”的错误时，往往习惯性图省事添加 `--privileged` 这个核选项。但这将把 **宿主机上一切特权和所有访问设备完全投射给容器内的根用户**，其危险性等价于根本没有做隔离！请务必查明进程出错的实际原因，精准施加必要的隔离 `CAP_*` 能力。
|
||||
|
||||
### 18.4.3 总结
|
||||
|
||||
|
||||
@@ -85,4 +85,4 @@ Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 1, CRITICAL: 0)
|
||||
|
||||
### 18.5.4 容器核心层基石结语
|
||||
|
||||
到这里，Docker 为保障宿主和容器界限安全的几个护城河：从**资源剥离限制** (`Cgroups`) 到**进程/网络/身份蒙蔽** (`Namespace`)、到**特权能力回收** (`Capabilities`) 再到**内核强制策略拦截管制** (`Seccomp`/`AppArmor`) 已悉数交代完毕。虽然绝没有“100% 免疫网络穿刺的防线”，只要开发者牢记 **权限最小化原则** ，容器的堡垒就可以做到令攻击者望洋兴叹。
|
||||
到这里，Docker 为保障宿主和容器界限安全的几个护城河：从 **资源剥离限制**(`Cgroups`) 到 **进程/网络/身份蒙蔽**(`Namespace`)、到 **特权能力回收**(`Capabilities`) 再到 **内核强制策略拦截管制**(`Seccomp`/`AppArmor`) 已悉数交代完毕。虽然绝没有“100% 免疫网络穿刺的防线”，只要开发者牢记 **权限最小化原则** ，容器的堡垒就可以做到令攻击者望洋兴叹。
|
||||
|
||||
@@ -300,7 +300,7 @@ FROM ubuntu:latest
|
||||
RUN apt-get update && apt-get install -y curl
|
||||
|
||||
# ✓ 推荐：固定基础镜像版本和摘要
|
||||
FROM ubuntu:22.04@sha256:a6d2b38300ce017add71440577d5b0a90460d0e6...
|
||||
FROM ubuntu:22.04@sha256:a6d2b38300ce017add71440577d5b0a90460d0e6e0e14...（完整 64 位哈希）
|
||||
RUN apt-get update && apt-get install -y curl=7.68.0-1ubuntu1
|
||||
```
|
||||
|
||||
@@ -320,7 +320,7 @@ RUN apk add --no-cache curl && \
|
||||
|
||||
RUN go build -o app .
|
||||
|
||||
FROM alpine:3.17@sha256:abcd...
|
||||
FROM alpine:3.17@sha256:abcd1234...（请替换为实际完整的 64 位摘要哈希）
|
||||
COPY --from=builder /app/app /app
|
||||
```
|
||||
|
||||
@@ -405,13 +405,13 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v3
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v2
|
||||
uses: docker/setup-buildx-action@v3
|
||||
|
||||
- name: Build Docker image
|
||||
uses: docker/build-push-action@v4
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
push: false
|
||||
@@ -427,7 +427,7 @@ jobs:
|
||||
severity: 'HIGH,CRITICAL'
|
||||
|
||||
- name: Upload Trivy results to GitHub Security tab
|
||||
uses: github/codeql-action/upload-sarif@v2
|
||||
uses: github/codeql-action/upload-sarif@v3
|
||||
with:
|
||||
sarif_file: 'trivy-results.sarif'
|
||||
|
||||
@@ -439,28 +439,26 @@ jobs:
|
||||
output-file: sbom-cyclonedx.json
|
||||
|
||||
- name: Upload SBOM
|
||||
uses: actions/upload-artifact@v3
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: sbom
|
||||
path: sbom-cyclonedx.json
|
||||
|
||||
- name: Sign image with Cosign
|
||||
if: github.event_name == 'push'
|
||||
env:
|
||||
COSIGN_EXPERIMENTAL: 1
|
||||
run: |
|
||||
cosign sign --yes ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
|
||||
|
||||
- name: Login to Registry and Push
|
||||
if: github.event_name == 'push'
|
||||
uses: docker/login-action@v2
|
||||
uses: docker/login-action@v3
|
||||
with:
|
||||
registry: ${{ env.REGISTRY }}
|
||||
username: ${{ github.actor }}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Push image
|
||||
uses: docker/build-push-action@v4
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
push: true
|
||||
|
||||
@@ -5,3 +5,6 @@ Docker 的安全性依赖于多层隔离机制的协同工作，同时需要用
|
||||
总体来看，Docker 容器还是十分安全的，特别是在容器内不使用 root 权限来运行进程的话。
|
||||
|
||||
另外，用户可以使用现有工具，比如 [Apparmor](https://docs.docker.com/engine/security/apparmor/)，[Seccomp](https://docs.docker.com/engine/security/seccomp/)，SELinux，GRSEC 来增强安全性；甚至自己在内核中实现更复杂的安全机制。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -89,7 +89,7 @@ services:
|
||||
- monitoring
|
||||
|
||||
cadvisor:
|
||||
image: gcr.io/cadvisor/cadvisor:latest
|
||||
image: ghcr.io/google/cadvisor:latest
|
||||
ports:
|
||||
- "8080:8080"
|
||||
volumes:
|
||||
|
||||
@@ -22,10 +22,11 @@ ELK (Elasticsearch，Logstash，Kibana) 是目前业界最流行的开源日志
|
||||
```yaml
|
||||
services:
|
||||
elasticsearch:
|
||||
image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
|
||||
image: docker.elastic.co/elasticsearch/elasticsearch:8.17.0
|
||||
container_name: elasticsearch
|
||||
environment:
|
||||
- "discovery.type=single-node"
|
||||
- "xpack.security.enabled=false"
|
||||
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
|
||||
ports:
|
||||
- "9200:9200"
|
||||
@@ -35,7 +36,7 @@ services:
|
||||
- logging
|
||||
|
||||
kibana:
|
||||
image: docker.elastic.co/kibana/kibana:7.17.0
|
||||
image: docker.elastic.co/kibana/kibana:8.17.0
|
||||
container_name: kibana
|
||||
environment:
|
||||
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
|
||||
@@ -47,7 +48,7 @@ services:
|
||||
- logging
|
||||
|
||||
fluentd:
|
||||
image: fluent/fluentd-kubernetes-daemonset:v1.14.3-debian-elasticsearch7-1.0
|
||||
image: fluent/fluentd-kubernetes-daemonset:v1.17-debian-elasticsearch8-1
|
||||
container_name: fluentd
|
||||
environment:
|
||||
- "FLUENT_ELASTICSEARCH_HOST=elasticsearch"
|
||||
|
||||
@@ -101,11 +101,9 @@ cAdvisor 是 Google 开发的容器监控工具，提供比 `docker stats` 更
|
||||
**Docker Compose 部署 cAdvisor：**
|
||||
|
||||
```yaml
|
||||
version: '3.9'
|
||||
|
||||
services:
|
||||
cadvisor:
|
||||
image: gcr.io/cadvisor/cadvisor:v0.47.0
|
||||
image: ghcr.io/google/cadvisor:v0.51.0
|
||||
container_name: cadvisor
|
||||
ports:
|
||||
- "8080:8080"
|
||||
@@ -165,8 +163,6 @@ scrape_configs:
|
||||
**完整监控栈部署：**
|
||||
|
||||
```yaml
|
||||
version: '3.9'
|
||||
|
||||
services:
|
||||
prometheus:
|
||||
image: prom/prometheus:latest
|
||||
@@ -200,7 +196,7 @@ services:
|
||||
- monitoring
|
||||
|
||||
cadvisor:
|
||||
image: gcr.io/cadvisor/cadvisor:v0.47.0
|
||||
image: ghcr.io/google/cadvisor:v0.51.0
|
||||
container_name: cadvisor
|
||||
ports:
|
||||
- "8080:8080"
|
||||
@@ -376,7 +372,6 @@ docker run -m 512m --memory-swap 1g myapp:latest
|
||||
# 如果不设置 --memory-swap，则等于 --memory 值
|
||||
|
||||
# Docker Compose 配置
|
||||
version: '3.9'
|
||||
services:
|
||||
app:
|
||||
image: myapp:latest
|
||||
@@ -395,7 +390,6 @@ services:
|
||||
# limits：绝不能超过的最大值
|
||||
# reservations：Compose 排期时的参考值
|
||||
|
||||
version: '3.9'
|
||||
services:
|
||||
web:
|
||||
memory: 512M # 限制
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
* **指标监控**：以 Prometheus + Grafana 为主，完成指标采集、存储与可视化。
|
||||
* **日志管理**：以 EFK/ELK 为例，完成容器日志的集中采集、检索与分析。
|
||||
|
||||
生产环境中，建议将“可观测性”当成一个完整闭环：**采集 -> 存储 -> 展示 -> 告警 -> 排错 -> 容量治理**。
|
||||
生产环境中，建议将”可观测性”当成一个完整闭环：**采集 -> 存储 -> 展示 -> 告警 -> 排错 -> 容量治理**。
|
||||
|
||||
## 19.3 Docker 日志驱动
|
||||
## 扩展阅读：Docker 日志驱动
|
||||
|
||||
Docker 提供了多种日志驱动 (Log Driver)，用于将容器标准输出的日志转发到不同后端。
|
||||
|
||||
@@ -47,3 +47,6 @@ Docker 提供了多种日志驱动 (Log Driver)，用于将容器标准输出的
|
||||
* Elasticsearch 数据目录已持久化，并有明确的日志保留周期与容量上限策略。
|
||||
* Kibana 能查询到最新日志；当 UI 异常时能用 Elasticsearch API 验证入库。
|
||||
* 可观测性组件未直接暴露到公网，访问已加鉴权或置于内网。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -1,9 +1,45 @@
|
||||
# 第二十章 实战案例 - 操作系统
|
||||
|
||||
本章将介绍 Docker 在不同操作系统镜像场景下的实战案例。
|
||||
## 章节概述
|
||||
|
||||
* [Busybox](20.1_busybox.md)
|
||||
* [Alpine](20.2_alpine.md)
|
||||
* [Debian Ubuntu](20.3_debian.md)
|
||||
* [CentOS Fedora](20.4_centos.md)
|
||||
本章将介绍 Docker 在不同操作系统镜像场景下的实战案例。当你构建容器化应用时，选择合适的基础镜像至关重要。不同的操作系统镜像在大小、功能和性能方面各有特点，适用于不同的使用场景。本章通过具体的案例，详细讲解如何在 Docker 中使用主流操作系统镜像，包括轻量级镜像 (Busybox、Alpine) 和完整功能镜像 (Debian、Ubuntu、CentOS 等)。
|
||||
|
||||
## 为什么选择合适的操作系统镜像很重要
|
||||
|
||||
在容器化应用开发中，选择合适的基础操作系统镜像直接影响容器的大小、启动速度、安全性和运行性能。不同的镜像提供了不同的功能集和资源占用：
|
||||
|
||||
- **轻量级镜像** (Busybox、Alpine) - 镜像大小仅几 MB，启动快速，适合微服务、IoT 设备和对资源敏感的环境。Busybox 是最小的选择，集成了常见的 Unix 工具；Alpine 则提供了完整的包管理器，方便安装额外工具。
|
||||
- **通用镜像** (Debian、Ubuntu) - 提供完整的 Linux 功能和丰富的软件生态，镜像大小通常在 100-300 MB 之间。适合需要灵活安装各种依赖和工具的应用场景。
|
||||
- **企业级镜像** (CentOS、Fedora) - 基于 Red Hat 生态，广泛应用于企业环境和复杂系统应用。提供了 yum 包管理器和强大的系统管理工具。
|
||||
|
||||
选择镜像的关键原则是 "小而够用"——选择满足应用需求的最小镜像。这样可以减少安全漏洞表面积、加快镜像拉取和推送速度、降低存储成本，同时也使容器更便于分发和部署。
|
||||
|
||||
## 常用操作系统镜像对比
|
||||
|
||||
| 镜像 | 大小 | 包管理器 | 适用场景 | 优势 |
|
||||
|------|------|--------|--------|------|
|
||||
| **Busybox** | ~1 MB | 无 | 最小化工具集、initrd | 极致轻量，启动秒级 |
|
||||
| **Alpine** | ~5 MB | apk | 微服务、静态应用 | 体积小，有包管理器 |
|
||||
| **Debian** | ~100 MB | apt-get | 通用应用、开发环境 | 软件包丰富，稳定性强 |
|
||||
| **Ubuntu** | ~80 MB | apt-get | 类似 Debian，现代化系统 | 更新频繁，用户多 |
|
||||
| **CentOS** | ~200 MB | yum | 企业应用、兼容性需求 | 企业级支持，稳定性高 |
|
||||
| **Fedora** | ~200 MB | dnf | 新特性需求、开发环境 | 最新技术栈，创新性强 |
|
||||
|
||||
## 学习目标
|
||||
|
||||
通过学习本章内容，你将能够：
|
||||
|
||||
- 理解不同操作系统镜像的特点、大小和适用场景
|
||||
- 掌握在 Docker 中使用各类操作系统镜像的方法和最佳实践
|
||||
- 学习如何根据实际需求选择合适的基础镜像，实现镜像优化
|
||||
- 了解如何在不同操作系统容器中安装、配置和管理应用程序
|
||||
- 掌握多阶段构建等高级技巧，最小化最终镜像大小
|
||||
- 学会使用 Docker Compose 编排多个操作系统容器环境
|
||||
|
||||
## 章节内容导航
|
||||
|
||||
* [Busybox](20.1_busybox.md) — 超轻量级工具集镜像，适合嵌入式和最小化容器
|
||||
* [Alpine](20.2_alpine.md) — 轻量级 Linux 镜像，广泛用于生产环境微服务
|
||||
* [Debian Ubuntu](20.3_debian.md) — 功能完整的通用 Linux 镜像，生态丰富
|
||||
* [CentOS Fedora](20.4_centos.md) — 企业级 Linux 镜像，适合复杂系统应用
|
||||
* [本章小结](summary.md)
|
||||
|
||||
@@ -9,3 +9,6 @@
|
||||
* 官方镜像体积都比较小，只带有一些基本的组件。精简的系统有利于安全、稳定和高效的运行，也适合进行个性化定制。
|
||||
|
||||
* 出于安全考虑，几乎所有官方制作的镜像都没有安装 SSH 服务，无法通过用户名和密码直接登录到容器中。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
@@ -81,7 +81,7 @@ deploy_staging:
|
||||
1. **不可变基础设施**：一旦镜像构建完成，在各个环境（Dev、Staging、Prod）中都应该使用同一个镜像 tag（通常是 commit hash），而不是重新构建。
|
||||
2. **配置分离**：使用 ConfigMap 和 Secret 管理环境特定的配置，不要打包进镜像。
|
||||
3. **应对 Docker Hub 限额 (Rate Limits)**：
|
||||
- Docker Hub 对匿名拉取实施了严格的限制 (6小时内约100次)。若在 CI/CD 中频繁构建，极易触发 `toomanyrequests` 错误。
|
||||
- Docker Hub 对匿名拉取实施了严格的限制 (6 小时内约 100 次)。若在 CI/CD 中频繁构建，极易触发 `toomanyrequests` 错误。
|
||||
- **最佳策略**：
|
||||
- 在流水线开头始终执行安全的身份认证 (使用 PAT，而非密码)。
|
||||
- 将常用的基础镜像缓存到自建的 Harbor/Nexus，使用 Pull-Through Cache。
|
||||
|
||||
@@ -1,12 +1,43 @@
|
||||
# 第二十一章 实战案例 - DevOps
|
||||
|
||||
本章将介绍 Docker 在 DevOps 场景下的实战案例。
|
||||
## DevOps 背景介绍
|
||||
|
||||
* [DevOps 完整工作流](21.1_devops_workflow.md)
|
||||
* [GitHub Actions](21.2_github_actions.md)
|
||||
* [Drone](21.3_drone.md)
|
||||
* [Drone Demo](21.4_drone_demo.md)
|
||||
* [在 IDE 中使用 Docker](21.5_ide.md)
|
||||
* [VS Code](21.6_vsCode.md)
|
||||
* [实战例子](21.7_practical_examples.md)
|
||||
DevOps 是一种重要的开发和运维文化，强调开发团队和运维团队之间的协作和自动化。它致力于通过自动化和流程优化，加快软件交付速度，同时提高系统的稳定性和可靠性。Docker 作为容器化技术的领导者，已成为现代 DevOps 工作流中不可或缺的工具。通过容器化应用，开发团队可以确保"一次构建，处处运行"，消除开发、测试和生产环境的差异，大大简化了部署流程。
|
||||
|
||||
## Docker 在 DevOps 中的角色
|
||||
|
||||
Docker 在 DevOps 工作流中承担多个关键角色。首先，它标准化了应用的开发和部署环境，使得团队成员在相同的 Docker 容器中工作，避免了"在我的机器上可以运行"的问题。其次，Docker 与 CI/CD 流程无缝集成，通过自动化的镜像构建、测试和部署，实现快速的迭代周期。此外，Docker 还支持微服务架构和容器编排，使团队能够更灵活地扩展应用和管理基础设施。
|
||||
|
||||
## CI/CD 管道的重要性
|
||||
|
||||
持续集成与持续部署 (CI/CD) 是现代 DevOps 的核心。通过自动化的代码检测、测试、构建和部署流程，团队可以更加频繁地发布新版本，同时保持系统的稳定性和可靠性。Docker 在 CI/CD 中扮演了重要角色：
|
||||
|
||||
- **标准化构建环境** - Docker 确保开发、测试和生产环境完全一致，消除了环境差异带来的问题
|
||||
- **加速流水线** - 容器的快速启动和轻量级特性，大幅加快了 CI/CD 流程的执行效率
|
||||
- **灵活的测试框架** - 可以轻松创建短生命周期的测试容器，并行运行多个测试
|
||||
- **自动化镜像发布** - CI/CD 工具可以自动构建、扫描、标记和推送 Docker 镜像到仓库
|
||||
- **蓝绿部署和金丝雀发布** - 利用容器的隔离性和可重复性，实现高级发布策略
|
||||
|
||||
本章将通过介绍 GitHub Actions、Drone 等流行的 CI/CD 工具，展示如何在实际项目中构建完整的自动化流水线。我们还将演示如何在本地开发环境中集成 Docker，使用 IDE 的容器开发插件，加快本地迭代周期。
|
||||
|
||||
## 本章学习目标
|
||||
|
||||
通过学习本章内容，你将能够：
|
||||
|
||||
- 理解 DevOps 文化、CI/CD 流程和容器化的紧密关系
|
||||
- 掌握完整的 Docker 工作流，从代码提交到线上部署的每一个环节
|
||||
- 学习如何使用 GitHub Actions 实现自动化 CI/CD，以及工作流的编写和优化
|
||||
- 了解 Drone 等第三方 CI/CD 工具的架构、部署和配置方式
|
||||
- 学会在本地 IDE (VS Code) 中集成 Docker，利用容器开发工具提升开发效率
|
||||
- 掌握实战中常见的 DevOps 场景、最佳实践和故障排查方法
|
||||
|
||||
## 章节内容导航
|
||||
|
||||
* [DevOps 完整工作流](21.1_devops_workflow.md) — 从代码到部署的全流程
|
||||
* [GitHub Actions](21.2_github_actions.md) — 使用 GitHub Actions 实现 CI/CD
|
||||
* [Drone](21.3_drone.md) — Drone CI/CD 平台简介和配置
|
||||
* [Drone Demo](21.4_drone_demo.md) — Drone 实战演示和应用
|
||||
* [在 IDE 中使用 Docker](21.5_ide.md) — IDE 与 Docker 集成的好处
|
||||
* [VS Code](21.6_vsCode.md) — Visual Studio Code 容器开发指南
|
||||
* [实战例子](21.7_practical_examples.md) — 真实项目中的 DevOps 应用案例
|
||||
* [本章小结](summary.md)
|
||||
|
||||
@@ -14,3 +14,6 @@
|
||||
|
||||
* 已在用 GitHub：优先补全 Actions 的缓存、制品、发布策略。
|
||||
* 自建体系：结合私有 Registry、Kubernetes 与 GitOps 工具完善部署与审计。
|
||||
---
|
||||
|
||||
> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/docker_practice/issues) 或 [PR](https://github.com/yeasy/docker_practice/pulls)。
|
||||
|
||||
47
README.md
47
README.md
@@ -2,7 +2,7 @@
|
||||
|
||||
[](https://github.com/yeasy/docker_practice) [](https://github.com/yeasy/docker_practice/releases) [](https://docs.docker.com/engine/release-notes/) [][1]
|
||||
|
||||
**v1.6.3**
|
||||
**v1.6.4**
|
||||
|
||||
[Docker](https://www.docker.com) 是个划时代的开源项目，它彻底释放了计算虚拟化的威力，极大提高了应用的维护效率，降低了云计算应用开发的成本！使用 Docker，可以让应用的部署、测试和分发都变得前所未有的高效和轻松！
|
||||
|
||||
@@ -17,6 +17,40 @@
|
||||
* **深入原理**：第 12 ~ 17 章介绍其底层实现技术，深入探讨容器编排体系 (Kubernetes、Etcd)，并延伸涉及容器与云计算及其它关键生态项目 (Fedora CoreOS、Podman 等)。
|
||||
* **实战扩展**：第 18 ~ 21 章重点讨论容器安全防护机制、监控与日志聚合系统 (Prometheus、ELK)，并展示操作系统、CI/CD 自动化构建等典型实践案例。
|
||||
|
||||
## 五分钟快速上手
|
||||
|
||||
"5分钟运行第一个容器"——跟随以下步骤快速体验 Docker：
|
||||
|
||||
1. **安装 Docker**（第1章）：根据操作系统完成 Docker 的安装与验证
|
||||
2. **第一个容器**：执行 `docker run hello-world`，体验最简单的容器运行
|
||||
3. **交互式容器**：执行 `docker run -it ubuntu bash`，进入容器内部与系统交互
|
||||
4. **镜像与仓库**（第2-3章）：理解镜像的概念、查找镜像、拉取和使用官方镜像
|
||||
5. **自定义镜像**（第5章）：学习如何编写 Dockerfile 创建自己的镜像
|
||||
|
||||
## 学习路线图
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
Start[Docker 学习入口] --> Ch1[第1章：基础安装]
|
||||
|
||||
Ch1 --> Role1["运维新手<br/>第1-4章"]
|
||||
Ch1 --> Role2["开发者<br/>第1-3章 → 第5-8章"]
|
||||
Ch1 --> Role3["DevOps 工程师<br/>第1章 → 第9-14章 → 第18章"]
|
||||
Ch1 --> Role4["架构师<br/>第1章 → 第15-21章"]
|
||||
|
||||
Role1 --> End1["掌握基本操作"]
|
||||
Role2 --> End2["构建与部署应用"]
|
||||
Role3 --> End3["自动化与运维"]
|
||||
Role4 --> End4["设计容器方案"]
|
||||
```
|
||||
|
||||
| 读者角色 | 学习重点 | 核心成果 |
|
||||
|---------|---------|---------|
|
||||
| **运维新手** | 第1-4章 | 掌握容器的基本概念与操作 |
|
||||
| **开发者** | 第1-3章 → 第5-8章 | 学会容器化应用的构建与部署 |
|
||||
| **DevOps 工程师** | 第1章 → 第9-14章 → 第18章 | 实现容器编排与自动化部署流程 |
|
||||
| **架构师** | 第1章 → 第15-21章 | 设计高可用、高性能的容器基础设施 |
|
||||
|
||||
## 阅读方式
|
||||
|
||||
本书按需提供多种阅读模式，具体如下：
|
||||
@@ -78,13 +112,22 @@ npx honkit serve
|
||||
* [京东图书][1]
|
||||
* [天猫图书](https://detail.tmall.com/item.htm?id=997383773726&skuId=6143496614475)
|
||||
|
||||
## 推荐阅读
|
||||
|
||||
本书是技术丛书的一部分。以下书籍与本书形成互补：
|
||||
|
||||
| 书名 | 与本书的关系 |
|
||||
|------|------------|
|
||||
| [《区块链技术指南》](https://github.com/yeasy/blockchain_guide) | 利用 Docker 部署区块链节点 |
|
||||
| [《OpenClaw 从入门到精通》](https://github.com/yeasy/openclaw_guide) | 利用 Docker 部署 AI 智能体 |
|
||||
|
||||
## 鼓励项目
|
||||
|
||||
<p align="center">
|
||||
<img width="200" src="https://github.com/yeasy/docker_practice/raw/master/_images/donate.jpeg">
|
||||
</p>
|
||||
|
||||
<p align="center"><strong>欢迎鼓励项目一杯 coffee~</strong></p>
|
||||
<p align=“center”><strong>欢迎鼓励项目一杯 coffee~</strong></p>
|
||||
|
||||
## Star History
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 1. 安全与凭据处理
|
||||
|
||||
任何示例文档中都**严禁出现将凭据以明文形式直接传递给命令参数**的做法。
|
||||
任何示例文档中都 **严禁出现将凭据以明文形式直接传递给命令参数** 的做法。
|
||||
|
||||
* **错误示例**：`docker login -u myuser -p mysecretpassword` (这会导致密码泄露到历史记录及进程列表中)
|
||||
* **正确示例（交互式）**：推荐读者直接使用 `docker login` (优先使用官方 Device Code Flow)。
|
||||
@@ -17,7 +17,7 @@
|
||||
* **明确声明前置条件**：例如，“此功能需要开启 containerd image store” 或 “需要额外配置 `--push`”。
|
||||
* **描述失败现象**：明确告诉读者，“如果你不这么配置，命令仍会提示成功，但产物将不可见/被丢弃”。
|
||||
|
||||
## 3. 统一使用 "docker compose" 命令
|
||||
## 3. 统一使用 “docker compose” 命令
|
||||
|
||||
早期 Python 编写的 `docker-compose` (V1) 已停止支持。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user