gVisor + Docker 实战：用 runsc 沙箱运行时部署 WordPress 站点

gVisor + Docker 实战：用 runsc 沙箱运行时部署 WordPress 站点

【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor

本文基于 gVisor 官方教程，讲解如何在 Docker 中使用runsc（gVisor 容器运行时）部署一个由 WordPress 前端 + MySQL 后端组成的两容器站点。读完你将掌握：runsc install如何将 gVisor 注册为 Docker 运行时、--runtime=runsc下 WordPress 与 MySQL 的完整部署流程，以及"gVisor 只沙箱化前端、不沙箱化数据库"这一生产取舍背后的性能原理。

前置条件：安装并注册 runsc 运行时

按照 gVisor 的 Docker 快速入门 完成安装（要求 Docker 17.09.0 或更高版本），并假定运行时名称为runsc。核心步骤：

1. 用runsc install将 gVisor 注册为名为runsc的 Docker 运行时（它会向/etc/docker/daemon.json写入运行时条目）：

sudo runsc install

2. 重启 Docker 守护进程使配置生效：

sudo systemctl restart docker

源码解析：runsc install到底做了什么

从 runsc/cmd/install.go 的源码可以确认该命令的具体行为：

• 默认目标配置文件为/etc/docker/daemon.json（--config_file可覆盖），运行时默认名为runsc（--runtime可自定义，如runsc-debug）；
• 命令会把runtimes映射中指定运行时的path（当前 runsc 可执行文件绝对路径）与runtimeArgs（--之后透传给 runsc 的参数，如--debug、--strace）写入 daemon 配置，见 doInstallConfig；
• 写入前会把旧配置备份为daemon.json~，失败可回滚，见 defaultWriteConfig；
• 对应地，仓库提供了uninstall子命令，用于从 daemon.json 中移除runsc运行时条目。

因此，runsc install --runtime runsc-debug -- --debug --strace这类命令实际是"注册一个带调试参数透传的运行时"，这也是 Docker 快速入门文档中调试模式的实现原理。

部署架构与沙箱策略

WordPress 站点需要两个容器：前端 Web 服务器（WordPress + Apache）与后端 MySQL 数据库。本教程的部署策略是：

• WordPress 前端使用--runtime=runsc沙箱化：前端是对外暴露面积最大、攻击面最关键的组件，gVisor 在这里的安全/性能权衡最划算；
• MySQL 后端不使用 runsc：gVisor 会带来额外的运行时开销，官方在生产指南中明确不建议把数据库放进沙箱，因为数据库属于 I/O 密集型负载。

这一建议有性能模型上的依据。根据 Performance Guide，gVisor 的开销分为两类：

1. 结构性开销（structural costs）：Sentry 内核引入额外内存，且系统调用必须穿越更多软件层。对"系统调用密集型"应用（高性能数据存储、静态网络服务）影响显著——MySQL 正是这类负载，小型操作（类似 redis 中的短命令）相对开销最大；
2. 实现性开销（implementation costs）：gVisor 是独立的系统调用面实现，网络栈与内部 VFS 仍在持续优化。

相反，gVisor 对纯内存访问和 CPU 指令执行不引入额外开销，前端这类"每请求做较多用户态工作"的 Web 服务受影响相对较小。完整的权衡讨论可参考 Production guide。

部署 WordPress 站点

第 1 步：定义共享环境变量

两个容器通过以下环境变量共享数据库凭据：

export MYSQL_PASSWORD=${YOUR_SECRET_PASSWORD_HERE?} export MYSQL_DB=wordpress export MYSQL_USER=wordpress

其中${VAR?}是 bash 语法：若MYSQL_PASSWORD未设置会直接报错退出，避免空密码被静默写入。

第 2 步：启动 MySQL 后端容器

# If you want to sandbox the database, add --runtime=runsc to this command. $ docker run --name mysql -d \ -e MYSQL_RANDOM_ROOT_PASSWORD=1 \ -e MYSQL_PASSWORD="${MYSQL_PASSWORD}" \ -e MYSQL_DATABASE="${MYSQL_DB}" \ -e MYSQL_USER="${MYSQL_USER}" \ mysql:5.7 # Wait until this message appears in the log. $ docker logs mysql |& grep 'port: 3306 MySQL Community Server (GPL)'

参数说明：

参数	作用
--name mysql	指定容器名为mysql，后续前端通过--link用这个名字解析主机名
-d	后台运行
-e MYSQL_RANDOM_ROOT_PASSWORD=1	让官方 MySQL 镜像随机生成 root 密码
-e MYSQL_PASSWORD / MYSQL_DATABASE / MYSQL_USER	创建应用数据库wordpress及专用账号wordpress

注意此命令没有--runtime=runsc：数据库走原生 runc 运行时。若确实需要沙箱化数据库，按注释加上该参数即可，但如上文所述并不推荐。

第二条命令会阻塞等待，直到 MySQL 初始化完成、日志中出现port: 3306 MySQL Community Server (GPL)提示，这是前端连接前的健康检查点。

第 3 步：启动 WordPress 前端容器（runsc 沙箱）

$ docker run --runtime=runsc --name wordpress -d \ --link mysql:mysql \ -p 8080:80 \ -e WORDPRESS_DB_HOST=mysql \ -e WORDPRESS_DB_USER="${MYSQL_USER}" \ -e WORDPRESS_DB_PASSWORD="${MYSQL_PASSWORD}" \ -e WORDPRESS_DB_NAME="${MYSQL_DB}" \ -e WORDPRESS_TABLE_PREFIX=wp_ \ wordpress

参数说明：

参数	作用
--runtime=runsc	使用 gVisor 作为本容器的容器运行时（前提是该运行时已在 daemon.json 注册）
--link mysql:mysql	将前一步的mysql容器链接到本容器，并在容器内以主机名mysql可达
-p 8080:80	把宿主机 8080 端口映射到容器内 80 端口，浏览器通过http://localhost:8080访问
-e WORDPRESS_DB_HOST=mysql	WordPress 通过链接得到的主机名连接数据库
-e WORDPRESS_DB_USER / WORDPRESS_DB_PASSWORD / WORDPRESS_DB_NAME	与 MySQL 侧变量一致，完成账号、库名配对
-e WORDPRESS_TABLE_PREFIX=wp_	设置数据表前缀

第 4 步：验证访问

打开浏览器访问http://localhost:8080，进入 WordPress 安装向导即可完成部署。

验证容器确实在 gVisor 中运行

在沙箱内执行dmesg，会看到 gVisor 特有的启动日志而非宿主机内核日志：

$ docker run --runtime=runsc -it ubuntu dmesg [ 0.000000] Starting gVisor... ... [ 2.610538] Rewriting operating system in Javascript... [ 2.613217] Ready!

需要强调（官方文档原话）：这种特征很容易被攻击者伪造，因此安全敏感的上下文里应用绝不应依赖dmesg来判定自己是否在沙箱中。

从单容器命令走向编排：Compose 与 Kubernetes

本教程用裸docker run完成演示，官方还给出了两种演进路径：

• Docker Compose：见 Wordpress with Docker Compose。用一份docker-compose.yaml声明db与wordpress两个服务，WordPress 侧通过runtime: "runsc"指定沙箱。该文档特别提醒了一个 gVisor 特有的坑：Compose 默认自建网络并用127.0.0.11提供内部 DNS，而该地址在 gVisor 沙箱内不可达，因此需要显式配置dns: [8.8.8.8]并使用允许路由到该地址的网络；另外 docker-compose 3.x 早期版本移除了服务级runtime字段，需使用 2.x 格式或 docker-compose >= 1.27.0。
• Kubernetes / GKE Sandbox：见 WordPress with Kubernetes。思路相同——仅给 WordPress Deployment 加runtimeClassName: gvisor，MySQL 保持注释掉的默认运行时，用 Secret 共享密码，并用kubectl get runtimeclass/gvisor验证节点上 gVisor 运行时已就绪。

上线生产前的检查清单

在把这套部署推向生产之前，建议通读 Production guide，要点包括：

• 先通过网络隔离、服务网格等手段收敛对外攻击面，再决定哪些组件需要沙箱化；
• 平台选择是对性能影响最大的决策：裸机推荐 KVM 平台，虚拟机中推荐systrap平台；
• 文件 I/O 与网络通常是受沙箱化影响最大的两项，可分别通过 文件系统配置 与网络栈选项（如半可信负载的网络直通）进一步调优；
• I/O 密集（数据库）、网络密集（负载均衡）负载性能受损最明显，CPU 密集型负载几乎无感——这正是本教程"前端进沙箱、数据库留在宿主机"的部署依据。

至此，你已经完整走通了 gVisor + Docker 的 WordPress 部署：理解了runsc运行时的注册机制、两容器的环境变量与网络串联，以及沙箱化边界划分背后的安全与性能权衡。

【免费下载链接】gvisorApplication Kernel for Containers项目地址: https://gitcode.com/GitHub_Trending/gv/gvisor