style: apply global formatting fixes (struct, spacing, zhlint)

2026-03-11 04:14:38 +00:00 · 2026-02-21 11:08:52 -08:00
parent ad68b2d973
commit 79ac9c639a
159 changed files with 1708 additions and 882 deletions
--- a/11_ops/README.md
+++ b/11_ops/README.md
@@ -1,4 +1,4 @@
-# 第十一章 运维管理
+# 第十一章运维管理

 本章将介绍 Docker 的运维管理，包括监控、日志与安全。

--- a/11_ops/logs/README.md
+++ b/11_ops/logs/README.md
@@ -4,23 +4,23 @@

 ## Docker 日志驱动

-Docker 提供了多种日志驱动（Log Driver）机制，允许我们将容器日志转发到不同的后端。
+Docker 提供了多种日志驱动 (Log Driver) 机制，允许我们将容器日志转发到不同的后端。

 常见的日志驱动包括：

-* `json-file`: 默认驱动，将日志以 JSON 格式写入本地文件。
-* `syslog`: 将日志转发到 syslog 服务器。
-* `journald`: 将日志写入 systemd journal。
-* `fluentd`: 将日志转发到 fluentd 收集器。
-* `gelf`: 支持 GELF 协议的日志后端（如 Graylog）。
-* `awslogs`: 发送到 Amazon CloudWatch Logs。
+* `json-file`：默认驱动，将日志以 JSON 格式写入本地文件。
+* `syslog`：将日志转发到 syslog 服务器。
+* `journald`：将日志写入 systemd journal。
+* `fluentd`：将日志转发到 fluentd 收集器。
+* `gelf`：支持 GELF 协议的日志后端 (如 Graylog)。
+* `awslogs`：发送到 Amazon CloudWatch Logs。

 ## 日志管理方案

 对于大规模的容器集群，我们通常会采用 EFK (Elasticsearch + Fluentd + Kibana) 或 ELK (Elasticsearch + Logstash + Kibana) 方案。

-* **Elasticsearch**: 负责日志的存储和全文检索。
-* **Fluentd/Logstash**: 负责日志的采集、过滤和转发。
-* **Kibana**: 负责日志的可视化展示。
+* **Elasticsearch**：负责日志的存储和全文检索。
+* **Fluentd/Logstash**：负责日志的采集、过滤和转发。
+* **Kibana**：负责日志的可视化展示。

 本章将介绍如何使用 EFK 方案来处理 Docker 容器日志。
--- a/11_ops/logs/elk.md
+++ b/11_ops/logs/elk.md
@@ -1,23 +1,23 @@
 ## ELK/EFK 堆栈

-ELK (Elasticsearch, Logstash, Kibana) 是目前业界最流行的开源日志解决方案。而在容器领域，由于 Fluentd 更加轻量级且对容器支持更好，EFK (Elasticsearch, Fluentd, Kibana) 组合也变得非常流行。
+ELK (Elasticsearch，Logstash，Kibana) 是目前业界最流行的开源日志解决方案。而在容器领域，由于 Fluentd 更加轻量级且对容器支持更好，EFK (Elasticsearch，Fluentd，Kibana) 组合也变得非常流行。

 ### 方案架构

 我们将采用以下架构：

-1. **Docker Container**: 容器将日志输出到标准输出 (stdout/stderr)。
-2. **Fluentd**: 作为 Docker 的 Logging Driver 或运行为守护容器，收集容器日志。
-3. **Elasticsearch**: 存储从 Fluentd 接收到的日志数据。
-4. **Kibana**: 从 Elasticsearch 读取数据并进行可视化展示。
+1. **Docker Container**：容器将日志输出到标准输出 (stdout/stderr)。
+2. **Fluentd**：作为 Docker 的 Logging Driver 或运行为守护容器，收集容器日志。
+3. **Elasticsearch**：存储从 Fluentd 接收到的日志数据。
+4. **Kibana**：从 Elasticsearch 读取数据并进行可视化展示。

 ### 部署流程

 我们将使用 Docker Compose 来一键部署整个日志堆栈。

-#### 1. 编写 Compose 文件
+#### 1。编写 Compose 文件

-1. 编写 `compose.yaml`（或 `docker-compose.yml`）配置如下：
+1. 编写 `compose.yaml` (或 `docker-compose.yml`) 配置如下：

 ```yaml
 services:
@@ -71,9 +71,9 @@ networks:
  logging:
 ```

-#### 2. 配置 Fluentd
+#### 2。配置 Fluentd

-创建 `fluentd/conf/fluent.conf`:
+创建 `fluentd/conf/fluent.conf`：

 ```ini
 <source>
@@ -102,9 +102,9 @@ networks:
 </match>
 ```

-#### 3. 配置应用容器使用 fluentd 驱动
+#### 3。配置应用容器使用 fluentd 驱动

-启动一个测试容器，指定日志驱动为 `fluentd`:
+启动一个测试容器，指定日志驱动为 `fluentd`：

 ```bash
 docker run -d \
@@ -115,9 +115,9 @@ docker run -d \
  nginx
 ```

-**注意**: 确保 `fluentd` 容器已经启动并监听在 `localhost:24224`。在生产环境中，如果你是在不同机器上，需要将 `localhost` 替换为运行 fluentd 的主机 IP。
+**注意**：确保 `fluentd` 容器已经启动并监听在 `localhost:24224`。在生产环境中，如果你是在不同机器上，需要将 `localhost` 替换为运行 fluentd 的主机 IP。

-#### 4. 在 Kibana 中查看日志
+#### 4。在 Kibana 中查看日志

 1. 访问 `http://localhost:5601`。
 2. 进入 **Management**->**Kibana**->**Index Patterns**。
--- a/11_ops/monitor/README.md
+++ b/11_ops/monitor/README.md
@@ -4,13 +4,17 @@

 在传统架构中，我们通常关注主机的 CPU、内存、磁盘 IO 等指标。而在容器环境下，除了主机层面的监控，我们更关注容器级别的资源使用情况、服务的运行状态以及编排系统的健康状况。

+## 概述
+
+总体概述了以下内容。
+
 ## 常见的监控方案

 目前主流的容器监控方案包括：

-* **cAdvisor**: Google 开源的容器资源监控工具，Docker 原生支持。
-* **Prometheus**: CNCF 毕业项目，云原生时代最流行的监控系统。
-* **Grafana**: 强大的可视化平台，常与 Prometheus 配合使用。
-* **ELK/EFK Stack**: 主要用于日志管理，但也能提供一定的监控能力。
+* **cAdvisor**：Google 开源的容器资源监控工具，Docker 原生支持。
+* **Prometheus**：CNCF 毕业项目，云原生时代最流行的监控系统。
+* **Grafana**：强大的可视化平台，常与 Prometheus 配合使用。
+* **ELK/EFK Stack**：主要用于日志管理，但也能提供一定的监控能力。

 本章将重点介绍如何使用 Prometheus 和 Grafana 搭建一套完整的容器监控系统。
--- a/11_ops/monitor/prometheus.md
+++ b/11_ops/monitor/prometheus.md
@@ -8,18 +8,18 @@ Prometheus 和 Grafana 是目前最流行的开源监控组合，前者负责数

 Prometheus 的主要组件包括：

-* **Prometheus Server**: 核心组件，负责收集和存储时间序列数据。
-* **Exporters**: 负责向 Prometheus 暴露监控数据（如 Node Exporter, cAdvisor）。
-* **Alertmanager**: 处理报警发送。
-* **Pushgateway**: 用于支持短生命周期的 Job 推送数据。
+* **Prometheus Server**：核心组件，负责收集和存储时间序列数据。
+* **Exporters**：负责向 Prometheus 暴露监控数据 (如 Node Exporter，cAdvisor)。
+* **Alertmanager**：处理报警发送。
+* **Pushgateway**：用于支持短生命周期的 Job 推送数据。

 ### 快速部署

 我们可以使用 Docker Compose 快速部署一套 Prometheus + Grafana 监控环境。

-#### 1. 准备配置文件
+#### 1。准备配置文件

-创建 `prometheus.yml`:
+创建 `prometheus.yml`：

 ```yaml
 global:
@@ -39,9 +39,9 @@ scrape_configs:
      - targets: ['cadvisor:8080']
 ```

-#### 2. 编写 Docker Compose 文件
+#### 2。编写 Docker Compose 文件

-创建 `compose.yaml`（或 `docker-compose.yml`）:
+创建 `compose.yaml` (或 `docker-compose.yml`)：

 ```yaml
 services:
@@ -88,7 +88,7 @@ networks:
  monitoring:
 ```

-#### 3. 启动服务
+#### 3。启动服务

 运行以下命令：

@@ -99,11 +99,11 @@ $ docker compose up -d
 启动后，访问以下地址：

 * Prometheus: `http://localhost:9090`
-* Grafana: `http://localhost:3000` (默认账号密码: admin/admin)
+* Grafana：`http://localhost:3000` (默认账号密码：admin/admin)

 ### 配置 Grafana 面板

 1. 在 Grafana 中添加 Prometheus 数据源，URL 填写 `http://prometheus:9090`。
-2. 导入现成的 Dashboard 模板，例如 [Node Exporter Full](https://grafana.com/grafana/dashboards/1860) (ID: 1860) 和 [Docker Container](https://grafana.com/grafana/dashboards/193) (ID: 193)。
+2. 导入现成的 Dashboard 模板，例如 [Node Exporter Full](https://grafana.com/grafana/dashboards/1860) (ID：1860) 和 [Docker Container](https://grafana.com/grafana/dashboards/193) (ID：193)。

 这样，你就拥有了一个直观的容器监控大屏。
--- a/11_ops/security/README.md
+++ b/11_ops/security/README.md
@@ -28,7 +28,9 @@ flowchart LR

 ## 核心安全机制

-### 1. 命名空间（Namespace）
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
+### 1。命名空间

 提供进程、网络、文件系统等资源的隔离：

@@ -41,9 +43,9 @@ flowchart LR
 | IPC | 进程通信 | 隔离共享内存 |
 | UTS | 主机名 | 独立主机名 |

-详见 [命名空间](../../14_implementation/14.2_namespace.md) 章节。
+详见[命名空间](../../14_implementation/14.2_namespace.md)章节。

-### 2. 控制组（Cgroups）
+### 2。控制组

 限制容器的资源使用，防止资源耗尽攻击：

@@ -61,7 +63,7 @@ $ docker run --cpus=1.5 myapp
 $ docker run --device-write-bps /dev/sda:10mb myapp
 ```

-### 3. 能力机制（Capabilities）
+### 3。能力机制

 Linux 将 root 权限拆分为多个细粒度的能力。Docker 默认禁用危险能力：

@@ -87,6 +89,8 @@ $ docker exec myapp cat /proc/1/status | grep Cap

 ## 镜像安全

+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
 ### 使用可信镜像

 运行以下命令：
@@ -149,7 +153,9 @@ $ cosign verify --key cosign.pub $IMAGE

 ## 运行时安全

-### 1. 非 root 用户运行
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
+### 1。非 root 用户运行

 > 笔者强调：这是最重要的安全实践之一。

@@ -179,7 +185,7 @@ CMD ["node", "server.js"]
 $ docker run -u 1001:1001 myapp
 ```

-### 2. 只读文件系统
+### 2。只读文件系统

 运行以下命令：

@@ -193,7 +199,7 @@ $ docker run --read-only myapp
 $ docker run --read-only --tmpfs /tmp --tmpfs /var/run myapp
 ```

-### 3. 禁用特权模式
+### 3。禁用特权模式

 运行以下命令：

@@ -207,7 +213,7 @@ $ docker run --privileged myapp
 $ docker run --cap-add=SYS_TIME myapp
 ```

-### 4. 限制资源
+### 4。限制资源

 运行以下命令：

@@ -220,7 +226,7 @@ $ docker run \
    myapp
 ```

-### 5. 网络隔离
+### 5。网络隔离

 运行以下命令：

@@ -239,7 +245,9 @@ $ docker run --network=isolated_net myapp

 ## Dockerfile 安全实践

-### 1. 使用精简基础镜像
+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
+### 1。使用精简基础镜像

 Dockerfile 内容如下：

@@ -255,7 +263,7 @@ FROM node:22               # ~1GB
 FROM ubuntu:24.04          # ~78MB
 ```

-### 2. 多阶段构建
+### 2。多阶段构建

 Dockerfile 内容如下：

@@ -275,7 +283,7 @@ USER node
 CMD ["node", "/app/server.js"]
 ```

-### 3. 不存储敏感信息
+### 3。不存储敏感信息

 Dockerfile 内容如下：

@@ -292,7 +300,7 @@ COPY .env /app/
 ...
 ```

-### 4. 固定依赖版本
+### 4。固定依赖版本

 Dockerfile 内容如下：

@@ -329,6 +337,8 @@ RUN apk add curl

 ## 高级安全方案

+本节涵盖了相关内容与详细描述，主要探讨以下几个方面：
+
 ### Seccomp 系统调用过滤

 限制容器可以使用的系统调用：
@@ -345,7 +355,7 @@ $ docker run --security-opt seccomp=/path/to/profile.json myapp
 $ docker run --security-opt apparmor=docker-default myapp
 ```

-### 安全容器（gVisor / Kata）
+### 安全容器 (gVisor / Kata)

 需要更强隔离时：

@@ -361,18 +371,18 @@ $ docker run --runtime=runsc myapp

 随着软件供应链攻击日益频繁，仅保障运行时安全已不足够。

-### 1. SBOM（软件物料清单）
+### 1。SBOM (软件物料清单)

 SBOM 类似于食品的配料表，列出了容器镜像中包含的所有软件包及其版本。

- **生成 SBOM**: 使用 `docker buildx build --sbom` 或 `docker scout sbom`。
- **管理 SBOM**: 确保持续监控 SBOM 中的组件是否存在新披露的漏洞。
+- **生成 SBOM**：使用 `docker buildx build --sbom` 或 `docker scout sbom`。
+- **管理 SBOM**：确保持续监控 SBOM 中的组件是否存在新披露的漏洞。

-### 2. 镜像签名（Sigstore / Notary v2）
+### 2。镜像签名 (Sigstore / Notary v2)

 确保镜像在构建后未被篡改，且确实来自可信的发布者。

- **Cosign**: Sigstore 项目的一部分，用于签署和验证容器镜像。
+- **Cosign**：Sigstore 项目的一部分，用于签署和验证容器镜像。
 ```bash
 ## 使用有写权限的仓库地址
 $ export IMAGE=<你的仓库地址>/myimage:tag
--- a/11_ops/security/control_group.md
+++ b/11_ops/security/control_group.md
@@ -4,6 +4,6 @@

 它提供了很多有用的特性；以及确保各个容器可以公平地分享主机的内存、CPU、磁盘 IO 等资源；当然，更重要的是，控制组确保了当容器内的资源使用产生压力时不会连累主机系统。

-尽管控制组不负责隔离容器之间相互访问、处理数据和进程，它在防止拒绝服务（DDOS）攻击方面是必不可少的。尤其是在多用户的平台（比如公有或私有的 PaaS）上，控制组十分重要。例如，当某些应用程序表现异常的时候，可以保证一致地正常运行和性能。
+尽管控制组不负责隔离容器之间相互访问、处理数据和进程，它在防止拒绝服务 (DDOS) 攻击方面是必不可少的。尤其是在多用户的平台 (比如公有或私有的 PaaS) 上，控制组十分重要。例如，当某些应用程序表现异常的时候，可以保证一致地正常运行和性能。

 控制组机制始于 2006 年，内核从 2.6.24 版本开始被引入。
--- a/11_ops/security/daemon_sec.md
+++ b/11_ops/security/daemon_sec.md
@@ -1,19 +1,19 @@
-## Docker服务端的防护
+## Docker 服务端的防护

 运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限，因此其安全性十分关键。

-首先，确保只有可信的用户才可以访问 Docker 服务。Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录`/`映射到容器的 `/host` 目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。这听起来很疯狂？但是事实上几乎所有虚拟化系统都允许类似的资源共享，而没法禁止用户共享主机根文件系统到虚拟机系统。
+首先，确保只有可信的用户才可以访问 Docker 服务。Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录 `/` 映射到容器的 `/host` 目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。这听起来很疯狂？但是事实上几乎所有虚拟化系统都允许类似的资源共享，而没法禁止用户共享主机根文件系统到虚拟机系统。

-这将会造成很严重的安全后果。因此，当提供容器创建服务时（例如通过一个 web 服务器），要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性的容器。
+这将会造成很严重的安全后果。因此，当提供容器创建服务时 (例如通过一个 web 服务器)，要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性的容器。

-为了加强对服务端的保护，Docker 的 REST API（客户端用来跟服务端通信）在 0.5.2 之后使用本地的 Unix 套接字机制替代了原先绑定在 127.0.0.1 上的 TCP 套接字，因为后者容易遭受跨站脚本攻击。现在用户使用 Unix 权限检查来加强套接字的访问安全。
+为了加强对服务端的保护，Docker 的 REST API (客户端用来跟服务端通信) 在 0.5.2 之后使用本地的 Unix 套接字机制替代了原先绑定在 127.0.0.1 上的 TCP 套接字，因为后者容易遭受跨站脚本攻击。现在用户使用 Unix 权限检查来加强套接字的访问安全。

-用户仍可以利用 HTTP 提供 REST API 访问。建议使用安全机制，确保只有可信的网络或 VPN，或证书保护机制（例如受保护的 stunnel 和 ssl 认证）下的访问可以进行。此外，还可以使用 [ HTTPS 和证书](https://docs.docker.com/engine/security/https/) 来加强保护。
+用户仍可以利用 HTTP 提供 REST API 访问。建议使用安全机制，确保只有可信的网络或 VPN，或证书保护机制 (例如受保护的 stunnel 和 ssl 认证) 下的访问可以进行。此外，还可以使用 [HTTPS 和证书](https://docs.docker.com/engine/security/https/)来加强保护。

 最近改进的 Linux 命名空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。

 终极目标是改进 2 个重要的安全特性：
-* 将容器的 root 用户 [映射到本地主机上的非 root 用户](https://docs.docker.com/engine/security/userns-remap/)，减轻容器和主机之间因权限提升而引起的安全问题；
-* 允许 Docker 服务端在 [非 root 权限(rootless 模式)](https://docs.docker.com/engine/security/rootless/) 下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。
+* 将容器的 root 用户[映射到本地主机上的非 root 用户](https://docs.docker.com/engine/security/userns-remap/)，减轻容器和主机之间因权限提升而引起的安全问题；
+* 允许 Docker 服务端在[非 root 权限 (rootless 模式)](https://docs.docker.com/engine/security/rootless/) 下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。

-最后，建议采用专用的服务器来运行 Docker 和相关的管理服务（例如管理服务比如 ssh 监控和进程监控、管理工具 nrpe、collectd 等）。其它的业务服务都放到容器中去运行。
+最后，建议采用专用的服务器来运行 Docker 和相关的管理服务 (例如管理服务比如 ssh 监控和进程监控、管理工具 nrpe、collectd 等)。其它的业务服务都放到容器中去运行。
--- a/11_ops/security/kernel_capability.md
+++ b/11_ops/security/kernel_capability.md
@@ -1,22 +1,22 @@
 ## 内核能力机制

-Docker 利用 Linux 的能力机制（Capabilities）来限制容器的权限，从而提高系统的安全性。
+Docker 利用 Linux 的能力机制 (Capabilities) 来限制容器的权限，从而提高系统的安全性。

-[能力机制（Capability）](https://man7.org/linux/man-pages/man7/capabilities.7.html) 是 Linux 内核一个强大的特性，可以提供细粒度的权限访问控制。
+[能力机制 (Capability)](https://man7.org/linux/man-pages/man7/capabilities.7.html) 是 Linux 内核一个强大的特性，可以提供细粒度的权限访问控制。
 Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加细粒度的操作能力，既可以作用在进程上，也可以作用在文件上。

 例如，一个 Web 服务进程只需要绑定一个低于 1024 的端口的权限，并不需要 root 权限。那么它只需要被授权 `net_bind_service` 能力即可。此外，还有很多其他的类似能力来避免进程获取 root 权限。

 默认情况下，Docker 启动的容器被严格限制只允许使用内核的一部分能力。

-使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块（例如负载模块）、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。
-* ssh 访问被主机上ssh服务来管理；
+使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块 (例如负载模块)、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。
+* ssh 访问被主机上 ssh 服务来管理；
 * cron 通常应该作为用户进程执行，权限交给使用它服务的应用来处理；
 * 日志系统可由 Docker 或第三方服务管理；
 * 硬件管理无关紧要，容器中也就无需执行 udevd 以及类似服务；
 * 网络管理也都在主机上设置，除非特殊需求，容器不需要对网络进行配置。

-从上面的例子可以看出，大部分情况下，容器并不需要“真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。
+从上面的例子可以看出，大部分情况下，容器并不需要 “真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。
 * 完全禁止任何 mount 操作；
 * 禁止直接访问本地主机的套接字；
 * 禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等；
@@ -24,5 +24,5 @@ Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加

 这样，就算攻击者在容器中取得了 root 权限，也不能获得本地主机的较高权限，能进行的破坏也有限。

-默认情况下，Docker采用 [白名单](https://github.com/moby/moby/blob/master/oci/caps/defaults.go) 机制，禁用必需功能之外的其它权限。
+默认情况下，Docker 采用[白名单](https://github.com/moby/moby/blob/master/oci/caps/defaults.go)机制，禁用必需功能之外的其它权限。
 当然，用户也可以根据自身需求来为 Docker 容器启用额外的权限。
--- a/11_ops/security/kernel_ns.md
+++ b/11_ops/security/kernel_ns.md
@@ -1,18 +1,18 @@
 ## 内核命名空间

-命名空间（Namespace）是 Linux 容器隔离的基础，它确保了容器内的进程无法干扰主机或其他容器。
+命名空间 (Namespace) 是 Linux 容器隔离的基础，它确保了容器内的进程无法干扰主机或其他容器。

 Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。当用 `docker run` 启动一个容器时，在后台 Docker 为容器创建了一个独立的命名空间和控制组集合。

 命名空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。

-每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的 sockets 或接口。不过，如果主机系统上做了相应的设置，容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用 links 来连接 2 个容器时，容器就可以相互通信了（可以根据配置来限制通信的策略）。
+每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的 sockets 或接口。不过，如果主机系统上做了相应的设置，容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用 links 来连接 2 个容器时，容器就可以相互通信了 (可以根据配置来限制通信的策略)。

 从网络架构的角度来看，所有的容器通过本地主机的网桥接口相互通信，就像物理机器通过物理交换机通信一样。

 那么，内核中实现命名空间和私有网络的代码是否足够成熟？

-内核命名空间从 2.6.15 版本（2008 年 7 月发布）之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。
+内核命名空间从 2.6.15 版本 (2008 年 7 月发布) 之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。

 实际上，命名空间的想法和设计提出的时间要更早，最初是为了在内核中引入一种机制来实现 [OpenVZ](https://en.wikipedia.org/wiki/OpenVZ) 的特性。
 而 OpenVZ 项目早在 2005 年就发布了，其设计和实现都已经十分成熟。
--- a/11_ops/security/other_feature.md
+++ b/11_ops/security/other_feature.md
@@ -2,11 +2,11 @@

 除了上述机制，Linux 内核还提供了一系列安全增强功能，可以进一步保护容器环境。

-除了能力机制之外，还可以利用一些现有的安全机制来增强使用 Docker 的安全性，例如 TOMOYO, AppArmor, Seccomp, SELinux, GRSEC 等。
+除了能力机制之外，还可以利用一些现有的安全机制来增强使用 Docker 的安全性，例如 TOMOYO，AppArmor，Seccomp，SELinux，GRSEC 等。

 Docker 当前默认只启用了能力机制。用户可以采用多种方案来加强 Docker 主机的安全，例如：
 * 在内核中启用 GRSEC 和 PAX，这将增加很多编译和运行时的安全检查；通过地址随机化避免恶意探测等。并且，启用该特性不需要 Docker 进行任何配置。
 * 使用一些有增强安全特性的容器模板，比如带 AppArmor 的模板和 Redhat 带 SELinux 策略的模板。这些模板提供了额外的安全特性。
 * 用户可以自定义访问控制机制来定制安全策略。

-跟其它添加到 Docker 容器的第三方工具一样（比如网络拓扑和文件系统共享），有很多类似的机制，在不改变 Docker 内核情况下就可以加固现有的容器。
+跟其它添加到 Docker 容器的第三方工具一样 (比如网络拓扑和文件系统共享)，有很多类似的机制，在不改变 Docker 内核情况下就可以加固现有的容器。
--- a/11_ops/security/summary.md
+++ b/11_ops/security/summary.md
@@ -4,4 +4,4 @@ Docker 的安全性依赖于多层隔离机制的协同工作，同时需要用

 总体来看，Docker 容器还是十分安全的，特别是在容器内不使用 root 权限来运行进程的话。

-另外，用户可以使用现有工具，比如 [Apparmor](https://docs.docker.com/engine/security/apparmor/), [Seccomp](https://docs.docker.com/engine/security/seccomp/), SELinux, GRSEC 来增强安全性；甚至自己在内核中实现更复杂的安全机制。
+另外，用户可以使用现有工具，比如 [Apparmor](https://docs.docker.com/engine/security/apparmor/)，[Seccomp](https://docs.docker.com/engine/security/seccomp/)，SELinux，GRSEC 来增强安全性；甚至自己在内核中实现更复杂的安全机制。