From 99c56217f51cdbf6574daaa2c74e66fcd55423e5 Mon Sep 17 00:00:00 2001 From: yeasy Date: Wed, 29 Apr 2026 05:21:02 +0000 Subject: [PATCH] Fix Chinese curly quote direction --- 07_dockerfile/7.4_cmd.md | 4 ++-- 10_buildx/10.2_buildx.md | 2 +- 17_ecosystem/17.5_skopeo.md | 2 +- 17_ecosystem/17.6_containerd.md | 2 +- 17_ecosystem/17.7_secure_runtime.md | 2 +- 18_security/18.1_kernel_ns.md | 2 +- 19_observability/README.md | 2 +- 19_observability/summary.md | 2 +- 21_case_devops/README.md | 2 +- 9 files changed, 10 insertions(+), 10 deletions(-) diff --git a/07_dockerfile/7.4_cmd.md b/07_dockerfile/7.4_cmd.md index a567778..1889cf5 100644 --- a/07_dockerfile/7.4_cmd.md +++ b/07_dockerfile/7.4_cmd.md @@ -6,8 +6,8 @@ 这是 Dockerfile 使用中最常见的困惑之一。简单的答案是： -- **CMD**：定义容器的”默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖 -- **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分 +- **CMD**：定义容器的“默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖 +- **ENTRYPOINT**：定义容器的“入口脚本”。通常用于启动应用的某个特定部分 **决策树**： diff --git a/10_buildx/10.2_buildx.md b/10_buildx/10.2_buildx.md index 019b2e1..f008c98 100644 --- a/10_buildx/10.2_buildx.md +++ b/10_buildx/10.2_buildx.md @@ -39,7 +39,7 @@ $ docker buildx build --sbom=true -t myimage . > **⚠️ 注意与失败模式**： > 要使 SBOM (或其它 attestation 元数据) 成功附着并可见，对底层的存储格式有前置要求：默认的 classic image store 不支持 manifest list/index 这种存放 attestation 的结构。 > -> 如果只简单运行上述命令，你可能会面临 **”命令成功执行，但本地镜像中看不到 SBOM”** 的体会落差。 +> 如果只简单运行上述命令，你可能会面临 **“命令成功执行，但本地镜像中看不到 SBOM”** 的体会落差。 > > **正确的解决路径有两条**： > 1. **推送到远端仓库**：使用 `docker buildx build --sbom=true --push -t myimage:tag` 时，SBOM 会正确保存到远端仓库。远端 OCI 兼容的镜像仓库能够完整存储这些元数据。 diff --git a/17_ecosystem/17.5_skopeo.md b/17_ecosystem/17.5_skopeo.md index 3d04ce4..a9cd9cf 100644 --- a/17_ecosystem/17.5_skopeo.md +++ b/17_ecosystem/17.5_skopeo.md @@ -8,7 +8,7 @@ Skopeo 是一个由 Red Hat 赞助开源的命令行工具，它可以在不需要运行容器守护进程（如 Docker Daemon）的前提下，对容器镜像进行极其高效的操作和管理，包括：检查、复制、删除和签名等操作。 -Skopeo 最大的特点是其可以在”不将镜像拉取到本地”的情况下，直接在远端 Registry（镜像仓库）之间完成检查和搬运，从而大幅度节省带宽和磁盘空间。这也是它在容器运维和分发领域非常受欢迎的原因。 +Skopeo 最大的特点是其可以在“不将镜像拉取到本地”的情况下，直接在远端 Registry（镜像仓库）之间完成检查和搬运，从而大幅度节省带宽和磁盘空间。这也是它在容器运维和分发领域非常受欢迎的原因。 ### 17.5.2 核心特性 diff --git a/17_ecosystem/17.6_containerd.md b/17_ecosystem/17.6_containerd.md index ccf41c9..f384b86 100644 --- a/17_ecosystem/17.6_containerd.md +++ b/17_ecosystem/17.6_containerd.md @@ -40,7 +40,7 @@ Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行时的实现差异，引入了 CRI（Container Runtime Interface）标准。 - 早期版本中，Kubernetes 默认使用 docker 作为运行时，通过一个名为 `dockershim` 的桥接组件对接 Docker，Docker 再对接 containerd。 -- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes 1.24+ 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。参见 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)。 +- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes 1.24+ 开始“弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。参见 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)。 - containerd 2.0+ 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 1.26+ 仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3+ 是 2.x 系列首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。详见 [containerd 发布说明](https://github.com/containerd/containerd/releases)。 ### 17.6.3 为什么直接使用 containerd？ diff --git a/17_ecosystem/17.7_secure_runtime.md b/17_ecosystem/17.7_secure_runtime.md index 6f301ae..5a81203 100644 --- a/17_ecosystem/17.7_secure_runtime.md +++ b/17_ecosystem/17.7_secure_runtime.md @@ -10,7 +10,7 @@ 尽管这种方式在性能和启动速度上拥有巨大优势，但也带来了一个显著的缺点：**隔离性（Isolation）不足**。如果某个容器内的恶意进程利用了宿主机内核的漏洞完成了越狱（Privilege Escalation），它将对整个宿主机以及其上运行的所有其他容器造成毁灭性威胁。 -如果在公有云环境（多租户场景）或运行不可信的第三方代码时，共享内核显然是不够安全的。为了解决这一问题，社区推出了”安全容器（Secure Containers/Sandboxed Containers）”的概念。安全容器的核心理念是：提供类似虚拟机的强隔离性，同时保持类似容器的轻量、快速启动和标准化管理。 +如果在公有云环境（多租户场景）或运行不可信的第三方代码时，共享内核显然是不够安全的。为了解决这一问题，社区推出了“安全容器（Secure Containers/Sandboxed Containers）”的概念。安全容器的核心理念是：提供类似虚拟机的强隔离性，同时保持类似容器的轻量、快速启动和标准化管理。 ### 17.7.2 什么是 Kata Containers？ diff --git a/18_security/18.1_kernel_ns.md b/18_security/18.1_kernel_ns.md index 915f97e..003d715 100644 --- a/18_security/18.1_kernel_ns.md +++ b/18_security/18.1_kernel_ns.md @@ -14,7 +14,7 @@ Docker 守护进程在启动容器时，会在后台为容器创建一套独立 尽管命名空间提供了很好的隔离性，但我们必须认识到：**所有的容器依然共享同一个宿主机的 Linux 内核**。 -这意味着，一旦宿主机的内核存在提权漏洞（如著名的 Dirty COW 漏洞），攻击者有可能通过突破 Namespace 的限制，直接在内核层面执行恶意代码，从而实现”容器逃逸”。 +这意味着，一旦宿主机的内核存在提权漏洞（如著名的 Dirty COW 漏洞），攻击者有可能通过突破 Namespace 的限制，直接在内核层面执行恶意代码，从而实现“容器逃逸”。 > [!WARNING] > 为了缓解内核漏洞带来的威胁，生产环境务必保持宿主机 Linux 内核的及时修补与更新，或者借助诸如 gVisor、Kata Containers 等提供了独立内核的安全容器技术。同时，需要及时修补容器运行时（如 runC）的漏洞。2025 年 11 月披露的一系列 runC 容器逃逸漏洞（CVE-2025-31133、CVE-2025-52565、CVE-2025-52881）就表明，即使内核保持更新，运行时层的缺陷仍然可能导致容器隔离被突破。 diff --git a/19_observability/README.md b/19_observability/README.md index b96c112..5cee76a 100644 --- a/19_observability/README.md +++ b/19_observability/README.md @@ -9,7 +9,7 @@ - **容器监控**：以 Prometheus 为主，讲解如何采集和展示容器性能指标。 - **日志管理**：以 ELK (Elasticsearch, Logstash, Kibana) 套件为例，介绍集中式日志收集平台。 -为了让读者能够在生产环境中真正用起来，本章会补齐以下”最小闭环”： +为了让读者能够在生产环境中真正用起来，本章会补齐以下“最小闭环”： * 关键指标与日志的验证方法 * 常见故障排查路径 diff --git a/19_observability/summary.md b/19_observability/summary.md index ea6156f..b6466b9 100644 --- a/19_observability/summary.md +++ b/19_observability/summary.md @@ -5,7 +5,7 @@ * **指标监控**：以 Prometheus + Grafana 为主，完成指标采集、存储与可视化。 * **日志管理**：以 EFK/ELK 为例，完成容器日志的集中采集、检索与分析。 -生产环境中，建议将”可观测性”当成一个完整闭环：**采集 -> 存储 -> 展示 -> 告警 -> 排错 -> 容量治理**。 +生产环境中，建议将“可观测性”当成一个完整闭环：**采集 -> 存储 -> 展示 -> 告警 -> 排错 -> 容量治理**。 ## 扩展阅读：Docker 日志驱动 diff --git a/21_case_devops/README.md b/21_case_devops/README.md index 3d58c78..df8b115 100644 --- a/21_case_devops/README.md +++ b/21_case_devops/README.md @@ -12,7 +12,7 @@ ## DevOps 背景介绍 -DevOps 是一种重要的开发和运维文化，强调开发团队和运维团队之间的协作和自动化。它致力于通过自动化和流程优化，加快软件交付速度，同时提高系统的稳定性和可靠性。Docker 作为容器化技术的领导者，已成为现代 DevOps 工作流中不可或缺的工具。通过容器化应用，开发团队可以确保”一次构建，处处运行”，消除开发、测试和生产环境的差异，大大简化了部署流程。 +DevOps 是一种重要的开发和运维文化，强调开发团队和运维团队之间的协作和自动化。它致力于通过自动化和流程优化，加快软件交付速度，同时提高系统的稳定性和可靠性。Docker 作为容器化技术的领导者，已成为现代 DevOps 工作流中不可或缺的工具。通过容器化应用，开发团队可以确保“一次构建，处处运行”，消除开发、测试和生产环境的差异，大大简化了部署流程。 ## Docker 在 DevOps 中的角色