1. 一个重启后的噩梦从“能跑”到“崩了”只差一次升级先描述一个真实场景。有一台树莓派 4B8GB 内存SD 卡 128GB上面跑着一个网页服务器用的还是最经典的 nginx PHP-FPM 组合。这个服务器服务着一个不大不小的内部管理系统白天有人访问晚上有定时任务备份数据库。整套系统跑了三个多月一直都很稳。稳到什么程度呢就是我已经开始把它当成不会坏的设备日常维护只有一句话sudo apt-get upgrade偶尔跑一下。直到某个周五晚上。我照例升级完系统顺手sudo reboot重启然后用手机一访问页面直接 502 Bad Gateway。我以为是 PHP-FPM 没起来SSH 进去systemctl status php7.4-fpm提示服务不存在。查了一下才发现apt-get upgrade时把 PHP 从 7.4 升到了 8.1fpm 服务名和配置文件路径全变了旧配置全部失效。更麻烦的是原来项目里有几个依赖 PHP 7.4 特性的老扩展库在 PHP 8.1 下直接编译不过。当时项目上线时是别人帮我装的服务器环境SD 卡里还留着当时执行过的一堆历史命令但哪些是必要的、哪些是装了又卸掉的已经分不清了。我花了大概四个小时才把服务原地救回来最后还是降级回 7.4因为那几条业务逻辑代码不是我写的我根本不敢保证升到 8.1 之后语义还一致。这件事给我最大的触动是传统模式下系统、环境、服务三者的耦合太紧了。操作系统层一升级服务环境跟着被动变更服务环境一旦被改具体应用就跟着遭殃。而在树莓派上这种耦合的代价又被 SD 卡的脆弱体质放大——你甚至没法像 x86 服务器那样先把系统盘做成快照再动手。于是我开始认真研究 Docker 化。这里的Docker 化不是赶时髦也不是看别人都在用所以我也要用而是确确实实被系统镜像遇上服务增长这个组合拳打疼了才决定换一条路。经过一段时间的迁移实践我确认这条路是树莓派跑网页服务器的最优解之一至少在中小规模里Docker 带来的收益是压倒性的。这篇文章是这个系列的第一篇核心目的就是想清楚一个问题树莓派这种低功耗、少资源的小机器为什么反而更需要 Docker2. 一台小机器为什么也会陷入“环境地狱”ARM 平台的放大效应很多人对环境地狱的理解停留在 x86 服务器上Python 2 和 Python 3 打架Ruby 版本冲突Node 依赖让人崩溃。总觉得树莓派这种玩具级设备上跑的服务少不至于陷入这种混乱。但实际用下来树莓派上环境混乱的严重程度是 x86 的好几倍原因有三点。2.1 ARM 架构下的软件生态缺口树莓派和绝大多数 PC 服务器一样跑的是 Linux但 CPU 架构不同。PC 是 amd64x86_64树莓派 3B/4B/5 是 arm64或 armhf。这个差异在日常使用中几乎感觉不到但在软件安装时就是天壤之别。很多开源项目发布二进制安装包.deb、.rpm默认只构建 amd64 版本。比如某个监控面板项目官方 README 里写得很清楚sudo curl -fsSL ... | sudo dpkg -i xxx_1.2.3_amd64.deb你照抄到树莓派上会直接得到wrong architecture错误。这时可选的路只有三条找社区非官方打包的 arm64 版本可信度存疑从源码自己编译耗时长、依赖多还经常因为某个编译参数不匹配失败或者干脆放弃这个软件换个替代品。这三条路都会消耗大量时间而 Docker 的出现让这三条路可以全部避开——直接在 Docker Hub 上拉取别人构建好的 arm64 镜像就行。2.2 apt 源与上游版本严重脱节树莓派 OS 基于 Debianapt 仓库里的软件版本通常落后上游一到两个大版本。如果你只是跑跑网页服务器落后一两个版本可能无所谓。但问题在于开发机上已经用新版本的框架写好项目了部署到树莓派上却找不到能满足要求的运行时版本。这时候被迫去折腾是常有的事手动编译最新版 PHP或者添加第三方源。而第三方源是环境混乱的重灾区。一个第三方源背后可能关联着几十个依赖包安装时它会顺手升级系统里的其他基础库。等装完系统里一堆包来自不同来源下一次apt-get upgrade时可能直接触发依赖冲突。我在树莓派上不止一次遇到apt 已经把系统里某个库升级到 A 版本但第三方源编译的软件需要 B 版本这种死锁。2.3 SD 卡 I/O 弱点让编译生态更难做很多人忽略了树莓派的存储瓶颈。SD 卡的随机写入速度只有几十 MB/s 级别而编译大型软件的过程会产生大量临时文件、中间代码和临时输出对 I/O 的要求相当高。在树莓派上用 GCC 编译一个稍微大一点的库比如 PHP 的一个扩展常常要等好几十分钟期间系统负载居高不下网页服务器的响应时间暴涨。如果编译过程中 SD 卡满了或者树莓派过热降频编译还会直接失败。请注意这不只是慢一点的问题而是慢到改变了你的运维习惯。在 x86 服务器上遇到缺失环境你可能会毫不迟疑地源码编译但在树莓派上每一次从源码编译都是一场对耐心和 SD 卡寿命的考验。经历了这些之后你会自然地想有没有办法让一套环境从宿主机上动态安装变成预先打包好拿来即用这就是 Docker 容器镜像天然具备的能力。综合以上三点在树莓派上每台机器上手工维护一套环境的成本相对于 x86 是显著更高的。一个服务至少消耗一次环境搭建的时间如果环境在被调好之后又碰上系统升级、程序改动需要新版本运行时那每次调整都可能把整套环境重新搅一遍。和鸡蛋不能放在同一个篮子里的道理一样服务和宿主机环境也不能捆绑在同一层系统快照里而这种松绑只需要给每个服务一层隔离边界即可实现——这正是 Docker 的出发点。3. Docker 给树莓派服务器带来的三个质变隔离、可复现、可迁移如果你搜为什么用 Docker看到最多的说法是环境隔离、部署方便、资源隔离。这些说法没有错但太笼统了。在树莓派网页服务器这个具体场景下Docker 带来的三个质变每一条都能对应到前面提到的具体痛点。3.1 将“环境依赖”从“操作系统”里彻底剥离在没有 Docker 的传统部署方式里服务运行所需的运行时、扩展库、配置文件全部直接安装在宿主机操作系统上。服务一多环境就变成一个大杂烩这个服务要 PHP 7.4那个服务要 PHP 8.1另外一个服务要 Python 3.9再加一个 Node 14 的老应用。全部装在同一台树莓派上哪怕只是想想都会头疼。用 Docker 之后每个服务进入各自独立的容器。容器里面装着对应的运行时和依赖宿主机只需要一个底层的操作系统和 Docker Engine。举个例子我现在这台树莓派上同时跑着一个老 PHP7.4应用和一个新 PHP8.2应用services: legacy-web: image: php:7.4-fpm volumes: - ./legacy-app:/var/www/html # 老项目专用 modern-web: image: php:8.2-fpm volumes: - ./modern-app:/var/www/html # 新项目专用这两个容器互不干扰各自跑各自的。这在传统部署模式下几乎不可想象——手工维护两套 PHP-FPM、两套扩展库、两套配置还都得兼容同一套系统库配置冲突只是时间问题。而在容器模式下隔离边界是强制的不需要靠管理员自觉去维护环境。3.2 部署过程变成“配置代码”可复现性拉满传统部署的问题是过程没有记录。你确实可以通过翻 bash history 看到当时敲过哪些命令但历史的顺序、哪些命令失败后又重试、哪些依赖其实没有装全全都是不可靠的记忆。整个环境就是一坨只有当时装过、没有如何复现的混沌。Docker 把这一整套部署过程变成了一个Dockerfile它本质上就是环境部署的文档而且是可以执行的文档。举一个简单的示例构建一个带 PHP 和 Nginx 的网页服务器镜像FROM php:8.2-fpm-alpine AS php # 安装项目需要的扩展 RUN docker-php-ext-install pdo_mysql opcache # 复制项目源码 COPY ./app /var/www/html FROM nginx:1.27-alpine AS web # 复制 Nginx 配置 COPY ./nginx.conf /etc/nginx/conf.d/default.conf # 复制 PHP-FPM 产生的静态文件 COPY --fromphp /var/www/html /usr/share/nginx/html这个 Dockerfile 写完之后在任何一台安装了 Docker 的机器上构建拿到的是完全一致的环境。之前那种在这台机器上能跑在另一台上跑不起来的问题从根本上被消灭了。而且这个 Dockerfile 可以被提交到 git 里做版本管理环境的每一次变迁都有迹可循。对树莓派来说可复现还有一个额外含义如果 SD 卡坏了传统模式下整个系统都要重装然后凭记忆恢复到原来的状态Docker 模式下只需要重装系统 Docker再通过docker-compose.yml和几个构建脚本拉起全部镜像整个环境基本可以在半小时内恢复服务质量损失被降到最低。3.3 镜像与数据分离迁移和备份的成本大幅降低传统树莓派备份方式通常是对 SD 卡做整卡镜像。我这张 128GB 的 SD 卡实际使用约 12GB但用dd整卡备份时处理的是 128GB 的全盘数据生成的文件在压缩后也还有近 10GB。备份一次要折腾很久恢复时还得写回 SD 卡。如果只是想简单地把某个服务搬到另一台设备上这种整卡方案就显得相当笨重。Docker 化之后服务的逻辑资产被拆分成了两部分资产类型传统部署Docker 化服务程序与运行时散落在系统各个目录容器镜像几百MB用户数据散落在应用目录数据库目录宿主机上的数据卷volume环境配置需要记住一堆命令docker-compose.yml 文件系统依赖手工安装无记录Dockerfile 定义迁移方式整卡 dd 备份或重装环境镜像 save/load 或拉取复制 volume迁移时新树莓派只需要安装 Docker、复制项目目录、执行docker compose up -d然后把数据卷一并拷贝过去即可。对比起来从备份整张 SD 卡变成了备份项目目录 数据卷体积小、速度快、可控性强。4. 对性能开销的理性判断树莓派真的“带得动” Docker 吗在树莓派这种资源有限的设备上引入 Docker最自然的疑虑是会不会太重了毕竟树莓派不像 x86 服务器那样有十几 GB 内存、多个 CPU 核心它不过是一块信用卡大小的板子。我在决定迁移之前也做过比较认真的实测和分析这里把数据摊开说。4.1 实测Docker Engine 本身的额外开销很小我用的环境是树莓派 4B8GB 内存版本系统是 Raspberry Pi OS Lite64 位关闭桌面环境只做服务器用途。项目迁移前我先安装了 Docker Engine不带 Docker Desktop树莓派上也没有 Docker Desktop然后测量资源占用情况状态内存占用说明纯系统启动后约 320MB无桌面、无额外服务启动 Docker Engine 后约 440MBdockerd containerd 相关进程运行 1 个 Nginx 容器约 480MBNginx 进程本身约 20-30MB运行 1 个 WordPress含 MySQL约 900MBMySQL 是大头约 300-400MB也就是说 Docker Engine 本身的内存开销大约是 120MB 左右相对系统基础占用来说可以接受。在 8GB 内存版本上跑三到四个中小型服务是完全不愁的就算用的是 2GB 或 4GB 内存的树莓派 4B只要别同时跑太多大型数据库也能应付。有人可能担心 Docker 进程的 CPU 占用。实际观察下来空闲状态下 CPU 占用率基本是 0%只有容器内的服务在处理请求时才会有 CPU 消耗。相比传统方式Docker 网络层NAT 和端口映射带来的额外开销非常小在树莓派这种低流量规模的场景下几乎感知不到。4.2 性能瓶颈不在 Docker而在 I/O 和内存优化习惯如果说 Docker 化真的有性能代价那么主要体现在两个地方。一是磁盘 I/ODocker 使用 overlay2 存储驱动每次容器读写文件系统时会有一些额外开销特别是在写操作上。树莓派的 SD 卡本来就不快这种额外开销会让写密集型操作感觉到轻微变慢。二是镜像体积如果随意使用大而全的基础镜像如 node:latest、php:latest甚至带桌面环境的完整发行版镜像SD 卡空间会被快速占满进而影响 I/O 表现。这两个代价都有对策。关于镜像体积最有效的做法是尽量使用 Alpine 变体如php:8.2-fpm-alpine、nginx:1.27-alpine基础镜像体积能小一半以上同时可以使用多阶段构建前面 Dockerfile 示例就是只把运行时需要的二进制和代码复制进最终镜像构建工具和中间产物不保留。关于 I/O 瓶颈一个实用的小技巧是把数据卷放在更快的存储上——如果你只有 SD 卡那就要确保 Docker 的存储目录写操作不会频繁发生比如 MySQL 这类频繁写盘的容器可以考虑把它的数据目录用 tmpfs 挂载到内存中但要接受数据重启丢失的风险或者至少把日志轮转配置好避免日志把 SD 卡写满。树莓派 5 或者 4B 如果使用 USB 3.0 移动硬盘或者 NVMe SSD通过转接板磁盘 I/O 会大幅改善这种硬件升级对 Docker 化服务器带来的实际体验提升比 CPU 升级还明显。没有条件的话从 SD 卡本身下手——买 A2 读写等级的卡——也能起到一定的缓解作用。4.3 一个容易忽视的好习惯给容器加内存限制传统部署模式下一个服务如果出现内存泄漏默默吞噬系统内存直到把整台树莓派卡死往往是运维事故里最难预判的。Docker 里有一种很简单的治理手段给每个容器设置mem_limit。比如 PHP-FPM 容器限制最多使用 256MBMySQL 限制最多使用 512MB一旦超过限制内核会直接把容器内超出部分的进程杀掉表现为 OOM Killed宿主机本身的安全不受影响。services: web: image: nginx:alpine mem_limit: 256m db: image: mysql:8.0 mem_limit: 512m这样以来就算某个容器内部出问题其他容器和宿主机也不会被拖垮。这实际上是 Docker 化的一层隐性收益——用资源配额硬隔离替代了传统模式下所有服务赛跑抢资源的局面。在树莓派这种资源敏感的平台上这层保护的价值甚至比在 x86 服务器上还要大。5. 不止是技术选型更是运维心态的转变我的迁移路径与后续规划我最后想聊的不是 Docker 的某个具体命令而是整个迁移过程和心态调整。因为对一个已经稳定运行了几个月的系统你不可能也不应该为了上 Docker 而上 Docker真正合理的路径是让新问题驱动你向前走。5.1 不要追求一步到位从最痛的服务开始我在做迁移时没有把树莓派上所有服务一次性全 Docker 化。那种全有或全无的做法风险很高万一某个服务在容器环境下表现和裸机不同而你又依赖它来管理其他服务整个迁移就会陷入僵局。我建议的路线是先把那个最让你头疼、最容易因环境变化而崩掉的服务迁到容器里跑上一两周确认稳定再逐步迁移其他服务。就我自己来说第一个被迁进来的是那个 PHP 7.4 的老项目。因为当时刚被 apt 升级坑过对它最没安全感。迁移成功后我直接把宿主机上对应的 PHP 包卸载掉系统环境立刻清爽了不少。这种逐渐推进的方式每一阶段的收益都能立刻看到风险也在可控范围内。5.2 volume、备份与运维习惯树莓派 Docker 网页服务器长跑下来的关键其实不在怎么把镜像跑起来而在数据怎么管。我的习惯是所有容器产生的持久化数据全部放到宿主机上的 volume 或绑定挂载目录里有名有姓的路径里比如/srv/docker/nginx/html、/srv/docker/mysql/data。然后在系统层做一个 cron 任务每天凌晨把/srv/docker打包压缩同步到另一个位置我用的是一个挂载的外接硬盘 远端备份。这个习惯是 Docker 给我带来的最大改变它把需要保护的东西从一个无形的系统状态变成了几个看得见、摸得着、可复制的目录。备份变得简单意味着我会更经常去做备份而更经常备份意味着灾难恢复时我心不慌。5.3 从操作系统管理员变成服务定义者传统模式下我对待树莓派的态度是它是一个需要小心翼翼维护的系统每次升级系统前都要祈祷不要出问题。Docker 化之后我的心态完全变了树莓派的操作系统只是承载 Docker 的基础设施真正重要的资产是那些 Dockerfile 和 docker-compose.yml——它们定义了每一个服务该长什么样。系统本身坏了重刷 SD 卡装好 Docker然后用 Compose 文件把服务拉起来半小时搞定。这种从管理员心态到服务定义者心态的转变是比任何技术细节都重要的底层变化。它让我敢于重装系统敢于尝试新镜像也敢于在一个小机器上同时管理多个项目而不再担心它们互相干扰。这个系列的第一篇就聊到这里。整个系列我打算按这条线往下走接下来的第二篇是基础篇讲在树莓派上怎么安装 Docker Engine、怎么配置镜像源、怎么解决不同硬件平台上 arm64 镜像不可以用的问题目标是把第一个网页服务器容器跑起来。再往后我会单独写 Docker Compose 做多服务编排、卷与数据备份方案、日志管理、反向代理对就是在树莓派上用 Nginx 反代多个容器以及实测过程中遇到的各种坑和排查方法。如果你也在盘算要不要把自己的树莓派服务 Docker 化欢迎先照着上面那些判断标准评估一下自己的处境——如果你的服务环境已经因为系统升级或者多应用并存变得一团糟那这个系列后面的内容就是为你准备的。