Add more tools

17_ecosystem/17.4_buildah.md

@@ -0,0 +1,88 @@
+## 17.4 Buildah - 容器镜像构建工具
+
+本节介绍 Buildah，包括其基础概念、应用场景以及基本指令。
+
+### Buildah 简介
+
+Buildah 是一个用于构建 OCI（Open Container Initiative）兼容格式容器镜像的开源命令行工具。与 Docker 需要一直运行的守护进程（daemon）不同，Buildah 的设计初衷是无需守护进程（daemonless）即可工作，并且也不强制要求 root 权限（rootless）。这使得在持续集成/持续部署（CI/CD）环境中构建镜像时能够更加轻量且安全。
+
+Buildah 由 Red Hat 主导开发，通常和 Podman、Skopeo 一起使用，被认为是构建、运行和管理容器的一套现代化工具链。在很多需要增强安全性和无需依赖守护进程的场景中，Buildah 是 `docker build` 命令的最佳替代方案。
+
+### 核心特性
+
+- **无守护进程（Daemonless）**：Buildah 直接通过系统调用拉取、构建和推送镜像，减少了单点故障的风险和资源开销。
+- **构建效率高**：可以挂载镜像的根文件系统到本地，并直接利用宿主机的工具对其进行操作，非常灵活。
+- **兼容性**：不仅支持处理传统的 Dockerfile，还能完全兼容 OCI（Open Container Initiative）标准和 Docker 格式。
+- **与 Podman 集成**：Podman 自身构建镜像的命令 `podman build` 底层实际上也是依赖 Buildah 库来实现的。
+
+### 安装 Buildah
+
+在许多主流的 Linux 发行版中都可以通过包管理器直接安装 Buildah。
+
+以 Fedora/CentOS/RHEL 为例：
+
+```bash
+$ sudo dnf install -y buildah
+```
+
+以 Ubuntu/Debian 为例（需引入官方源后）：
+
+```bash
+$ sudo apt-get update
+$ sudo apt-get -y install buildah
+```
+
+### 基础用法示例
+
+#### 1. 从现有的 Dockerfile 构建镜像
+
+Buildah 最常见的用法就是像 Docker 一样根据 `Dockerfile` 来构建镜像，可以直接使用 `buildah bud`（或者 `buildah build-using-dockerfile`）命令：
+
+```bash
+$ buildah bud -t my-app:latest .
+```
+
+可以看到在这点上，它与 `docker build` 的体验完全一致。
+
+#### 2. 交互式从空镜像开始构建
+
+除了使用 Dockerfile，Buildah 最强大的功能来自于它的交互式和脚本化构建机制。我们可以从一个极简的镜像（或基础镜像）开始构建：
+
+```bash
+# 获取一个基础镜像
+$ container=$(buildah from alpine:latest)
+
+# 获取挂载点，并查看其路径
+$ mnt=$(buildah mount $container)
+$ echo $mnt
+/var/lib/containers/storage/overlay/xxx/merged
+
+# 利用宿主机直接创建文件，而不需要在容器内部运行命令
+$ echo "Hello Buildah" > $mnt/hello.txt
+
+# 添加一些配置和命令
+$ buildah config --cmd "cat /hello.txt" $container
+
+# 将容器提交为镜像
+$ buildah commit $container my-hello-image:latest
+
+# 构建完成后可以卸载并清理容器上下文
+$ buildah unmount $container
+$ buildah rm $container
+```
+
+这种模式在自动化流水线中极为有用，因为我们可以将上述过程编写成标准的 bash 脚本，无需为了构建镜像而撰写只在其独立语法中运行的 Dockerfile 指令。
+
+#### 3. 查看和推送镜像
+
+通过 `buildah images` 可以查看当前环境中的镜像。推送镜像到外部 Registry 也十分安全方便：
+
+```bash
+# 查看本地构建的镜像
+$ buildah images
+
+# 推送镜像到 Docker Hub（注意需要先登录）
+$ buildah push my-hello-image:latest docker://docker.io/username/my-hello-image:latest
+```
+
+结合其无需特权和灵活脚本的优点，Buildah 正变得越来越受到构建和分发 OCI 镜像的用户喜爱。

17_ecosystem/17.5_skopeo.md

@@ -0,0 +1,79 @@
+## 17.5 Skopeo - 容器镜像管理工具
+
+本节介绍 Skopeo，包括其基础概念、应用场景以及基本指令。
+
+### Skopeo 简介
+
+Skopeo 是一个由 Red Hat 赞助开源的命令行工具，它可以在不需要运行容器守护进程（如 Docker Daemon）的前提下，对容器镜像进行极其高效的操作和管理，包括：检查、复制、删除和签名等操作。
+
+Skopeo 最大的特点是其可以在“不将镜像拉取到本地”的情况下，直接在远端 Registry（镜像仓库）之间完成检查和搬运，从而大幅度节省带宽和磁盘空间。这也是它在容器运维和分发领域非常受欢迎的原因。
+
+### 核心特性
+
+- **远程巡检**：通过 `skopeo inspect` 可以查看远端仓库中镜像的元数据（例如包含哪些层、环境变量信息、入口命令等），而完全无需拉取该镜像。
+- **镜像复制与同步**：支持各种格式之间的相互传输，如在不同的容器仓库之间、或者从仓库拉取到本地的目录、或者存储为 OCI 布局结构等。
+- **镜像删除**：可以远程删除仓库中的镜像（需要拥有权限）。
+- **签名验证**：支持在分发镜像前进行数字签名以保障安全性。
+
+### 安装 Skopeo
+
+类似于 Buildah，Skopeo 也直接包含在大部分主流的 Linux 源中。
+
+在 Fedora/CentOS/RHEL 等发行版中：
+
+```bash
+$ sudo dnf install -y skopeo
+```
+
+在 Ubuntu/Debian 中：
+
+```bash
+$ sudo apt-get update
+$ sudo apt-get -y install skopeo
+```
+
+如果是 macOS 环境，可以通过 Homebrew 安装：
+
+```bash
+$ brew install skopeo
+```
+
+### 基础用法示例
+
+#### 1. 远程检查镜像（Inspect）
+
+有时候我们只想知道远端镜像的详细信息，并不想拉取它。下面是检查 Docker Hub 上的 Alpine 镜像的例子：
+
+```bash
+$ skopeo inspect docker://docker.io/library/alpine:latest
+```
+
+这个命令会返回一段 JSON 格式的数据，其中包含了诸如镜像摘要（Digest）、创建时间、架构（Architecture）、标签（Tags）等丰富信息。在自动化的工具和系统审查环境中，这是一个不可或缺的利器。
+
+#### 2. 同步与复制镜像（Copy）
+
+`skopeo copy` 是使用最为广泛的命令。它可以在不同的仓库、不同的格式之间无缝搬运镜像。
+
+例如，从一个公共仓库直接搬运镜像到一个私有企业仓库（无需将其先 `docker pull` 到本地，再 `docker push`）：
+
+```bash
+$ skopeo copy docker://docker.io/library/alpine:latest docker://registry.example.com/library/alpine:latest
+```
+
+又或者，你可以将远程镜像拉取到本地，只为了检查其拆解后的格式，比如将镜像解压到本地某个目录下以 OCI 规范存放：
+
+```bash
+$ skopeo copy docker://docker.io/library/alpine:latest oci:alpine-oci
+```
+
+如果我们要将本地的某个目录下的打包好的镜像再次推向 Registry 或转换为其它存储类型也是完全支持的，诸如：
+- `docker://` 远端 Registry
+- `docker-archive:` / `docker-daemon:` Docker 对应的归档文件或本地守护进程
+- `oci:` / `oci-archive:` OCI 相关文件格式
+- `dir:` 本地纯目录
+
+#### 3. 校验机制与安全
+
+如果你不信任公开仓库上的镜像，或是需要通过特定的 TLS 证书和鉴权，Skopeo 的功能也是能很好的支持的，比如它可以直接传递诸如 `--src-creds` 或 `--dest-tls-verify=false` 等参数，这在进行网络隔离的复杂镜像搬运操作中常常会用到。
+
+对于复杂的容器环境或那些纯粹用于镜像资产管理的节点来说，Skopeo 提供了一个直接而强大的数据“搬运工”。

17_ecosystem/17.6_containerd.md

@@ -0,0 +1,69 @@
+## 17.6 containerd - 核心容器运行时
+
+本节介绍 containerd，它是现代容器技术栈中最为核心的基础组件之一。了解 containerd 有助于更深入地理解 Docker 和 Kubernetes 的底层运行机制。
+
+### containerd 简介
+
+[containerd](https://containerd.io/) 是一个行业标准的容器运行时，它最初是由 Docker 引擎中剥离出来的一个核心组件，后来 Docker 将其捐赠给了云原生计算基金会（CNCF），目前已经是一个 CNCF 毕业（Graduated）项目。
+
+它的主要职责是管理单个宿主机上完整的容器生命周期，包括：
+- 镜像的传输和存储
+- 容器执行和管理
+- 存储和网络接口的管理
+
+简单来说，当你在使用 Docker 或者 Kubernetes 时，真正去底层调用操作系统接口（如 Linux 的 Namespace 和 Cgroups）来启动和管理容器进程的，往往是 containerd（及它所调用的 runc 组件）。
+
+### 与 Docker 和 Kubernetes 的关系
+
+理解 containerd，首先要理清它与用户日常操作的 Docker 以及 Kubernetes 的关系。
+
+#### Docker 的架构
+
+在早期，Docker 引擎是一个包含了所有功能的单体架构。随着技术的发展和标准化要求，Docker 将底层关于容器运行时的部分解耦出来，形成了 `containerd` 和 `runc`。
+
+当你执行一个 `docker run` 命令时，调用链路大致如下：
+1. Docker Client 发送请求给 Docker Daemon（`dockerd`）。
+2. `dockerd` 将请求转发给 `containerd`。
+3. `containerd` 准备好镜像和容器的必要环境，然后调用 `runc`。
+4. `runc` 负责按照 OCI（Open Container Initiative）标准，拉起并运行真正的容器进程。
+
+因此，Docker 现在实际上是构建在 containerd 之上的一个包含更多开发者友好特性（如构建镜像、Compose 管理等）的增强平台。
+
+#### Kubernetes 与 CRI
+
+Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行时的实现差异，引入了 CRI（Container Runtime Interface）标准。
+
+- 早期版本中，Kubernetes 默认使用 docker 作为运行时，通过一个名为 `dockershim` 的桥接组件对接 Docker，Docker 再对接 containerd。
+- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes v1.24 开始“弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。
+
+### 为什么直接使用 containerd？
+
+对普通应用开发者来说，Docker 依然是本地开发和测试的首选。但对于构建云平台、自动化流水线或深度管理 Kubernetes 集群的系统工程师来说，直接使用 containerd 可以带来：
+- **更高的性能与更少的开销**：去掉了 Docker Daemon 等附加组件的资源占用，链路更短。
+- **更强的稳定性**：作为专注于运行时的底层组件，它的核心功能极为稳定且更新受控。
+- **直接符合 Kubernetes CRI 标准**：在生产级 Kubernetes 集群中作为标准配置。
+
+### 基础用法与工具介绍
+
+不同于 `docker` 命令行工具，containerd 提供了不同的客户端来满足不同的使用场景：
+
+- **ctr**：containerd 自带的调试用客户端。它功能比较基础，主要用于开发者在开发 containerd 时进行快速调试，一般不作为最终用户的日常管理工具。
+- **crictl**：Kubernetes 提供的 CRI 命令行工具。它用于排查 Kubernetes 节点上的容器和沙箱（Pod）问题。
+- **nerdctl**：这是一个由系统社区成员（主要是 containerd 项目的维护者）开发的，完全兼容 Docker CLI 体验的 containerd 命令行客户端。对于习惯了 `docker run/ps/build` 命令的用户来说，`nerdctl` 可以作为直接操作 containerd 的理想替代品，并且它还支持直接构建镜像（依赖 BuildKit）。
+
+#### nerdctl 使用示例
+
+安装完 containerd 和 nerdctl 后，你可以体验到几乎与 Docker 完全一致的命令行：
+
+```bash
+# 启动一个 nginx 容器
+$ nerdctl run -d -p 8080:80 --name my-nginx nginx:alpine
+
+# 查看运行中的容器
+$ nerdctl ps
+
+# 查看本地镜像
+$ nerdctl images
+```
+
+对于那些希望在生产服务器上剥离 Docker 庞大体积，但又想要保留类似 Docker 方便的命令行体验的用户，`containerd` + `nerdctl` 是一个极佳的组合。

17_ecosystem/17.7_secure_runtime.md

@@ -0,0 +1,53 @@
+## 17.7 安全容器运行时
+
+本节介绍容器技术生态中的安全运行时机制，主要探讨在隔离性和安全性上比标准 Linux 容器更进一步的方案，重点介绍 Kata Containers 和 gVisor。
+
+### 为什么需要安全容器？
+
+标准的 Linux 容器（如 Docker、Podman 或基础的 containerd/runc 所提供的）依赖于 Linux 内核的 **Namespace（命名空间）** 和 **Cgroups（控制组）** 来实现进程级别的隔离与资源限制。这种轻量级的虚拟化方式共享同一个宿主机的内核。
+
+尽管这种方式在性能和启动速度上拥有巨大优势，但也带来了一个显著的缺点：**隔离性（Isolation）不足**。如果某个容器内的恶意进程利用了宿主机内核的漏洞完成了越狱（Privilege Escalation），它将对整个宿主机以及其上运行的所有其他容器造成毁灭性威胁。
+
+如果在公有云环境（多租户场景）或运行不可信的第三方代码时，共享内核显然是不够安全的。为了解决这一问题，社区推出了“安全容器（Secure Containers/Sandboxed Containers）”的概念。安全容器的核心理念是：提供类似虚拟机的强隔离性，同时保持类似容器的轻量、快速启动和标准化管理。
+
+### 什么是 Kata Containers？
+
+[Kata Containers](https://katacontainers.io/) 是一个开源项目，由 OpenStack Foundation（现更名为 OpenInfra Foundation）托管。它将早期的两个项目——Intel Clear Containers 和 Hyper runV 结合而成。
+
+Kata Containers 的核心思路是：**使用轻量级的虚拟机（Lightweight VM）来运行每一个容器或者 Pod**。
+
+#### 工作原理
+
+当使用 Kata Containers 时，它不是在宿主机上启动一个普通的独立进程，而是调用一个精简高度优化的虚拟机管理程序（如 QEMU、Firecracker 或 Cloud Hypervisor）启动一个小型的虚拟机。容器内的应用进程运行在这个虚拟机拥有独立特制内核的沙箱中。
+
+- **高度隔离**：因为拥有自己的独立内核，即使容器内的应用利用内核漏洞溢出，它也只能破坏虚拟机虚拟出来的内核，根本无法触及宿主机真正的内核。
+- **兼容性**：Kata Containers 完全实现了 OCI（Open Container Initiative）规范和 CRI（Container Runtime Interface）标准。这意味着它可以作为 `containerd` 或 `Docker` 的底层运行时无缝替换默认的 `runc`。
+- **与 Kubernetes 集成**：在 Kubernetes 中，你可以为一个特定的 Pod 指定 `runtimeClassName: kata`，让高敏感的任务自动运行在虚拟机级别的隔离环境中。
+
+### 什么是 gVisor？
+
+[gVisor](https://gvisor.dev/) 是由 Google 开发并开源的一种不同流派的沙箱容器运行时方案。
+
+它采取了与 Kata Containers 完全不同的技术路线，它不是启动完整的虚拟机，而是提供了一个 **应用态内核（User-space Kernel）**。
+
+#### 工作原理
+
+gVisor 的核心组件是一个名为 **Sentry** 的用户空间进程。Sentry 扮演了一个“内核代理”的角色。
+
+- 当容器内的应用想要进行系统调用（System Call，比如读写文件、网络通信）时，这些调用会被 Sentry 拦截并进行一层虚拟化处理，然后再由 Sentry 把经过安全过滤和转换的请求转发给宿主机内核。
+- 因为 Sentry 在用户态实现了一套 Linux 系统调用接口，它极大减少了应用直接接触底层操作系统内核的表面积。这样就有效防御了利用底层内核漏洞突破隔离的攻击方式。
+- gVisor 同样兼容 OCI 规范，其核心运行时组件称为 `runsc`，可以作为底层运行时与 Docker 或 Kubernetes 进行集成。
+
+### 总结与对比
+
+| 特性 | 标准 Linux 容器 (runc) | Kata Containers | gVisor (runsc) |
+| :--- | :--- | :--- | :--- |
+| **隔离技术** | Namespace & Cgroups | 轻量级虚拟机 (独立内核) | 用户态内核 (系统调用拦截) |
+| **安全性** | 较低（共享宿主机内核） | 极高（硬件级虚拟化隔离） | 高（减少内核攻击面） |
+| **性能开销** | 极小（原生进程） | 中等（因轻量化而优于传统 VM） | 中等到较高（取决于系统调用频率开销） |
+| **启动速度** | 极快（毫秒/秒级） | 快（秒级之内） | 快（接近原生容器） |
+| **兼容性** | 完美（所有系统调用均支持原始实现） | 极好（拥有完整内核） | 好（但在极少数复杂的未被拦截支持的系统调用中可能报错） |
+
+如今，诸如 AWS 这样的云厂商也推出了针对无服务器容器功能（Serverless Containers）的高度优化的轻量级虚拟机管理器 **Firecracker**，可以看作是安全容器生态中与 Kata 类似方案的底层基石。
+
+对于普通的微服务开发来说可能不需要考虑使用安全容器，但在提供多租户平台即服务（PaaS）、运行无状态边缘计算函数（FaaS）等对安全隔离要求极高的场景中，以 Kata Containers 和 gVisor 为代表的安全容器技术展现出了巨大的价值。

17_ecosystem/17.8_wasm.md

@@ -0,0 +1,43 @@
+## 17.8 WebAssembly 与容器
+
+本节介绍 WebAssembly (简写为 Wasm) 以及它为何成为现代容器生态中备受瞩目的前沿技术路线。
+
+### 什么是 WebAssembly？
+
+[WebAssembly (Wasm)](https://webassembly.org/) 最初是由 W3C 主导的一项为了解决网页中 JavaScript 性能瓶颈而发明的技术标准。它是一种小体积的、加载极快的、提供安全沙盒的高效二进制格式的指令集架构。通过将 C/C++、Rust、Go 等高级语言编译成 `.wasm` 格式，这些程序可以直接在所有现代的浏览器中以接近原生代码的速度安全地运行。
+
+然而，一项原本用于前端领域的技术，为何如今却与容器云计算生态产生了强烈的化学反应？
+
+因为开源社区很快意识到，Wasm 所具备的核心特性完美契合了云原生后端的诉求。人们制定了诸如 **WASI (WebAssembly System Interface)** 这样的标准，将其能力从浏览器扩展到了服务器端操作系统上。
+
+### Wasm 与容器特性的完美契合
+
+将 Wasm 应用于服务端时，它展现出了一些可能比传统 Linux 容器更为优异的特性：
+
+1. **极速的冷启动性能**：
+   传统 Linux 容器虽然比虚拟机轻量很多，但它启动依然需要建立 Namespace 和 Cgroups 以及一整套文件系统，通常需要近百毫秒到几秒。而 Wasm 模块不需要这样庞杂的环境初始化，能够在几毫秒之内完成从加载到执行，这对于无服务器函数（Serverless Functions）而言是巨大的提升。
+
+2. **跨平台性 (Write Once, Run Anywhere)**：
+   我们知道 Docker 等容器通常是绑定架构的。如果是 x86_64 平台上打出的镜像，通常无法直接在基于 ARM 的系统（如苹果 M 系列芯片甚至树莓派）上直接运行原生代码，除非使用 QEMU 进行低效转译或者专门构建多架构（Multi-arch）镜像和 manifests。
+   而 Wasm 二进制本身是平台无关的平台中间语言代码形式！你编译出来的一份 `.wasm` 可执行模块，不用做任何修改，就可以在 x86 的 Linux 服务器、ARM 的边缘设备、甚至是 Windows 和 macOS 上直接通过 Wasm 运行时来驱动和执行。真正做到了“编写一次，到处运行”。
+
+3. **天然的安全沙箱机制**：
+   Wasm 设计之初就是在不被信任的浏览器沙盒环境中运行未知代码的，因此执行环境非常安全，采用了极好的能力导向安全模型。应用只能访问它被明确授予权限的文件或能力。其默认安全隔离性比起依靠 Namespaces 机制的共享内核的 Linux 容器更加坚固。
+
+4. **极小的包体积**：
+   Linux 容器需要打包一整套依赖甚至是简化的 OS 根目录结构。而一个编译好的功能完善的 Wasm 模块体积常常不到几兆甚至仅仅几十 Kb，极大地加快了存储及网络利用效率。
+
+### 当 Docker 遇上 WebAssembly
+
+在现代的容器生态系统中，Wasm 并不被看作是要被取代传统的 Docker 或者 Kubernetes 的技术，而是成为了一种 **与 Linux 容器互补并且共生** 的全新工作负载类型。
+
+目前，这通过 OCI (Open Container Initiative) 和 CRI 标准实现了集成上的统一：
+
+1. **将 Wasm 打包为 OCI 镜像**：虽然内容并非传统的 Linux RootFS，但是通过标准化的打包工具同样可以将应用程序及其 `.wasm` 构建结果转化为一个可以被推送至 Docker Hub 或其他 registry 的标准化镜像规范。
+2. **通过容器运行时直接执行**：Docker 已经与如 [WasmEdge](https://wasmedge.org/) 和 [Spin](https://developer.fermyon.com/spin) 等高性能的企业级 Wasm 运行时进行了官方集成合作。
+
+如今在 Docker Desktop 或者集成了 `containerd` 的环境中，我们可以十分简易地以类似普通镜像的形式去拉取并运行一个基于 Wasm 编译的后端服务（通过指定相应的 `--platform` 或者是特别的 `--runtime=io.containerd.wasmedge.v1` 设置），将其如同对待一个标准应用进程一样让 Docker 为其接管日志、配置相关的网络端口映射，甚至通过 Docker Compose 将一个普通的数据库容器实例与一个 Wasm 微服务实例协同起来混布。
+
+### 总结
+
+随着技术底座如 WASI 规范不断的成熟完善（例如提供完备的套接字网络支持以及系统资源访问支持），我们有理由相信不仅是边缘计算与无服务器调用，会有越来越多对于速度和安全性有极高指标要求的云原生后端微服务开始采用这一颠覆传统边界的轻量级“微型智能体”架构。在可见的将来，Wasm 势必成为云原生与 Docker 生态的重要拼图。