1. 一次系统重装的噩梦为什么我开始怀疑直接装服务这条路我的树莓派4B已经稳稳当当跑了快一年上面住着好几个住户一个内网网页服务器用来挂开发笔记、一个定时脚本抓取天气数据存进SQLite、还有frpc把局域网里的某个端口映射出去方便外面访问。平时相安无事我也很放心觉得树莓派这东西就是皮实给它通电就能一直干活。直到那天我鬼使神差地执行了一句sudo apt upgrade然后重启然后屏幕上的彩虹方块一闪而过接着就进入了无限重启的循环。树莓派开机亮彩虹方块是正常的但持续几分钟还进不了系统就明显不对劲了。我盯着那块小小的ARM开发板心里一阵发凉——这一年攒下来的配置、数据、脚本、定时任务全都在那张32GB的SD卡上。当时的第一反应是赶紧把卡拆下来插到电脑上抢救数据。好在Linux的分区在Windows下用读卡器也能读出来我拉回了大部分文件。可问题来了系统坏了服务要重新搭而每一个服务当初是怎么装上去的我脑子里只有模糊的印象。WordPress那套是照着网上的教程敲的apt install apache2 php mysqlPHP版本当时选的7.4还是8.0来着记不清了。内网穿透那个frpc的配置文件是用nano直接改的/etc/frp/frpc.ini改完没做备份。天气脚本用的是Python 3.7里面还pip装了一个第三方库那个库又依赖一个C编译的环境天知道我当时是怎么把那东西编译过去的。重装一次系统等于把过去一年所有的配置记忆全部清零。而那一年恰恰是我往里加服务加得最勤的时候——一个网页服务器项目拆出了前端预览、后端接口、数据库三个组件每次改动都直接往SD卡里写文件。那次事故之后我做了一个决定把所有服务全部Docker化。任何新服务先Docker化再上线旧服务迁移的过程就是逐步容器化的过程。这篇文章就是这个系列的第一篇我想先把为什么讲透——不是说直接装服务就一定不行而是当系统镜像还在原地踏步、服务却在不断增长时旧方式会把你拖进一个越陷越深的泥潭。提示如果你手里只有一台树莓派只跑一个固定的服务比如单纯当下载机那你确实不需要Docker。但如果你和我一样把树莓派当成一台真正的服务器在用今天加一个网页应用明天装一个数据库那么这篇就是给你写的。2. 直接装在系统里慢得像在旧地基上盖十层楼房2.1 系统镜像的初始状态决定了它不擅长长期多服务树莓派官方系统镜像Raspberry Pi OS本身是一个完整的Linux发行版它出厂时就带了一套比较干净的Debian环境。干净是好事但它有一个天然问题它是无状态的镜像而你的每一次apt install、每一次改配置文件都是在往这个无状态镜像里塞入有状态的东西。你可以试试在一台用了很久的树莓派上跑一下df -h再看看系统分区被多少软件堆满了。你可能装过LibreOffice、装过某些GUI工具、为了一个包装了某个不常用的依赖库这些全都会留在系统里。某一天你搜索树莓派磁盘满了怎么办然后发现/boot分区只剩几十MB、/var/log里躺着一堆日志、apt的缓存占掉几百MB。这些还不是最可怕的最可怕的是你不知道哪些东西可以删、哪些东西删了会导致某个正在跑的服务挂掉。网页服务器场景尤其明显。我见过有人在一台树莓派上直接装上Apache、Nginx、MySQL、PostgreSQL、PHP 7、PHP 8、Node.js、Redis……图的就是全都装一遍要用哪个用哪个。等真要用的时候Apache占了80端口、Nginx要去改listen端口避开它MySQL和PostgreSQL都要吃内存树莓派4B的8GB版本还好4GB版本直接卡成幻灯片PHP 7的项目需要旧版扩展库但apt源里已经把这个库升级成只支持PHP 8的版本了。系统镜像本身并没有错错的是把它当成了无限扩容的软件仓库。它就像一个二手房地基你可以在上面一次性盖好房子但当你要不断往上加楼层、不断改内部管线时这个地基的每一个原始设计都会变成限制。2.2 真实案例我一个月内踩的三个依赖冲突这些不是假设是我在那个灾难月之前真实遇到的问题。第一个天气脚本需要python3-requests这个包在apt源里版本比较旧我是用pip直接升级的。升级后系统里同时存在两个版本某些系统工具用的是旧的我脚本用的是新的平时看不出问题但有一次系统自动升级把它俩搞混了脚本开始报SSL证书验证失败。修了一晚上最后是重装Python环境才解决。第二个为了给博客服务器加一个Markdown解析功能我用gem install装了一个Ruby的包结果它依赖的那个C扩展库要求GCC版本不能高于某个值。而我先前为了给某个PHP扩展编译已经把GCC升级到了新版本。两个项目对编译器版本的要求直接打架我想降级GCC却发现系统里一堆东西依赖新版GCC。第三个最经典我装了一个轻量级MQTT Broker用于采集传感器数据它自动把mosquitto这个用户加进了系统占用了/etc/ssl下某个目录的权限导致我后来安装另一个用证书的服务时怎么配都报权限错误。每一条单看都不致命但累积起来就是为什么树莓派跑几个服务后越来越慢、越改越乱的根源。Docker之所以能够解决这个问题根子就在于它把系统这件事本身从共享改成了隔离。每个容器里可以有自己的lib库、自己的编译器版本、自己的Python环境它们互不干扰。2.3 为什么说新装一遍不等于恢复很多人觉得重装系统再重新配置一遍不就行了。如果你只有一两个服务确实可以。但服务多起来之后重新配置一遍是一句噩梦级的空话。你用WordPress搭过一个站点你自己能回忆起当时在wp-config.php里改了哪些数据库前缀、哪些缓存插件参数吗你能想起来frpc那个隧道的加密方式、压缩协议具体是怎么写的吗你的Python脚本里有没有依赖一个你早就忘了的requirements.txt直接装在系统里的服务配置是隐式的——它和系统融为一体缺少一份明确的、可由机器复现的装配单。Docker镜像恰好提供了这份装配单。Dockerfile就是一份清单它明确地写着先装什么库、再改什么配置、最后启动什么进程。有了这份清单重建一个完全相同的服务只需要一条docker run命令而不是在脑内搜索过去几个月甚至几年的记忆。3. 网页服务器增长背后的隐形膨胀端口、版本和存储空间三重压力3.1 端口冲突只是表象根子在共享任何一台服务器上同一个端口只能被一个进程监听。网页服务器又是特别依赖端口的——80、443、8080、3000、8000每个Web框架都有自己的默认端口习惯。如果你直接在系统里装每启动一个新服务第一件事就是去看看哪个端口没被占。这是不是意味着你可以手动分配端口当然可以但这不是根本问题。真正的根子是所有服务都共享同一个网络命名空间和同一个进程空间。Docker把每个容器放进自己的网络命名空间里你可以让容器内部的Nginx依然监听80端口外部的时候映射到宿主机的8080。这样做最大的好处是每个容器认为自己拥有一个独立的服务器环境。你不用为了给新服务腾端口而去改旧服务的配置旧服务不经过你同意就突然变了个端口导致的隐性失联问题也随之消失。3.2 版本矩阵一个项目四个组件组合方式是指数级的我那个网页服务器项目后来拆成了四个部分Nginx做反向代理、Vue前端构建后生成静态文件、Node.js提供API接口、PostgreSQL存数据。每个部分都有自己的版本要求。如果全部直接装在系统里我需要保证Nginx的版本和我的配置语法兼容Node.js的版本能在当前系统镜像里用apt装到或者去源码编译PostgreSQL的版本不能太新也不能太旧因为驱动库要能匹配。一次升级所有组件都要跟着验证一轮。而Docker镜像各自锁定版本Nginx容器用官方nginx:1.24-alpineNode.js容器用node:18-bookwormPostgreSQL用postgres:15-alpine。每个镜像都固定了里面的软件版本。想升级某个组件不需要动系统里的任何东西直接拉一个新版本镜像重新起一个容器如果出问题还能回滚到旧容器。这就像一个好了杂乱的工具间——你不必为了用一把新螺丝刀把整个墙上所有工具重新布局一遍。3.3 SD卡存储系统镜像本身在涨但服务更吃磁盘树莓派系统镜像的大小每年都在增长。Raspberry Pi OS的完整版镜像现在解压后已经超过4GB加上你装的软件和日志一张32GB卡用不了太久就会告急。直接装服务时每个软件包都会在系统分区写入可执行文件、配置文件、依赖库和日志而且这些数据之间还有大量重复。对比一下Docker镜像本身也占空间但镜像采用分层存储多个镜像可以共享基础层。举个例子我从官方仓库拉取了nginx:alpine和node:alpine它们共享同一个Alpine Linux基础层实际占用的空间比单独拉取两个完整镜像要小得多。这在存储空间本来就紧张的树莓派上意义重大。此外Docker容器把可写层限定在容器的临时层里日志和数据通常通过volume挂载到宿主机指定目录。这种拆分方式让备份变得非常简单——你需要备份的是卷和配置而不是整个乱七八糟的系统分区。4. Docker 核心原理速览集装箱、分层镜像和可丢弃容器4.1 用集装箱的类比理解 DockerDocker最常用的类比是集装箱。以前你在港口运输不同货物得用不同的船、不同的装卸方式货物还可能相互污染。集装箱的统一标准让运输变得高效、隔离、可复用。Docker之于软件服务也是一样的思路把你的软件连同它需要的操作系统级依赖、配置、运行命令全部打包进一个标准化的箱子——镜像。而这个箱子最大的特点就是可以在任何装有Docker引擎的机器上原样运行。你在树莓派上构建好一个镜像拿到另一台ARM架构的设备上比如香橙派、瑞芯微开发板一样能跑。这也解决了树莓派和x86平台之间跨架构部署的一部分痛点——同一套编排文件只要都是ARM架构设备直接跑即可。4.2 镜像分层为什么拉镜像不重构建镜像方便Docker镜像由一层层只读文件系统叠加而成。Dockerfile里每一条RUN、COPY、ADD指令都会生成一个新层。层与层之间按顺序叠加最终形成一个完整的文件系统视图。层的好处有两个一是共享不同镜像之间如果基础层相同宿主机只需要存一份二是构建时利用缓存改动的只是变化的那几层。我在写网页服务器镜像时最常感受到这个特性改一下后端代码重新构建时只需要替换包含代码的那一层前面装依赖的层还能命中缓存几秒钟就能重新出一个镜像。4.3 容器是可丢弃的数据放volume里新手最容易困惑的问题容器里写的文件容器删了是不是就没了答案是默认是但推荐的做法是别把重要数据写在容器可写层里。Docker容器本身应该是无状态的像一台用一次就格式化掉的小型沙盒。网页服务器的程序文件可以烘焙进镜像但用户上传的图片、数据库文件、日志要挂载到宿主机目录-v参数或者Docker Volume里面。这样容器可以随时删除、重建、升级而数据留在外面不受影响。我所有跑网页服务的容器都是这个模式docker run -v /home/pi/data:/data把数据目录挂进去。删除容器、换新版本镜像数据还在。这比直接在系统里装服务要安全得多因为你不用担心卸载软件时把数据目录一并清空了。4.4 树莓派上跑 Docker 的性能顾虑要打消很多人觉得树莓派性能有限Docker这种虚拟化是不是会增加开销其实Docker不是虚拟机它底层用的是Linux内核的命名空间Namespace和控制组Cgroups机制。它和宿主机共享同一个内核并没有像虚拟机那样给每个容器分配一套完整的虚拟硬件。相比直接在系统里跑进程Docker带来的性能损耗很小通常可以忽略不计——主要是额外的系统调用开销一般不到百分之几。在树莓派4B上跑一个Nginx Node.js PostgreSQL组成的站Docker化的版本和直接装的版本在用户体验上几乎没有差异但前者在部署、维护、升级方面的体验好太多了。5. 树莓派网页服务器 Docker 化的实际红利备份、迁移、SD卡寿命和实验自由5.1 一键备份和一键恢复我在那场系统重装噩梦之后给整套网页服务器做了Docker Compose编排。目录结构大致是这样~/webstack/ ├── docker-compose.yml ├── nginx/ │ └── conf.d/ │ └── default.conf ├── app/ │ └── (Node.js 应用代码) └── data/ ├── postgres/ └── uploads/备份的时候只需要打包这个目录volume数据 配置文件 镜像清单。恢复时新机器上装好Docker和Compose把打包的目录解压回去执行一条docker compose up -d整套服务就在几分钟内恢复了。你是没体会过手工配置一整晚第二天跑起来还是不对的憋屈。能用一条命令解决的问题千万不要去手敲。5.2 大版本升级的优雅姿势传统方式升级网页服务器先apt update再apt upgrade然后祈祷依赖不出问题、PHP和MySQL版本兼容、旧网站的某些函数不被新版本废弃。Docker方式先检查新版镜像的release notes然后修改docker-compose.yml里的镜像tag执行docker compose pull拉取新镜像再docker compose up -d。启动后先访问一下页面看看是否正常有问题就改回旧的tag再执行一次。整个升级过程的时间窗口非常短因为旧容器在启动新容器之前还在运行新容器起来后旧容器才被停止。这个体验带来的安心感是直接在系统里装服务完全无法比的。5.3 降低实验和折腾成本换来SD卡的寿命树莓派用SD卡当系统盘有个致命的缺点SD卡没有机械硬盘或SSD那种磨损均衡Wear Leveling机制反复写入会加速坏块。直接在系统里频繁apt install、写日志、更新软件包实际上就是在消耗SD卡的寿命。Docker能不能完全避免这个问题不能但能把写入集中到镜像层和可写层而且你可以通过把容器的日志输出到内存tmpfs或限制日志大小来减少写入。我的网页服务器容器统一限制了日志大小加上镜像构建时的缓存层在一次构建后就不再变化实际运行时的系统写入量比裸装方式少不少。5.4 实验的自由翻车了就直接删掉重来在树莓派上试一个新框架或新数据库时最大的心理障碍是如果我把它装坏了会不会影响正在跑的服务。Docker给了你一个安全区拉一个新镜像起一个容器映射一个临时端口测试完直接docker rm。如果新镜像有问题删掉容器旧的照常跑着。环境变量的配置修改直接改docker-compose.yml里的一行重新 up 一个容器原来的坏容器都不用管。这让我的开发流程彻底改变了以前改坏一个配置要小心翼翼去想我怎么改回来现在直接docker compose down docker compose up -d。6. 不盲目跟风什么情况下真不需要 Docker6.1 单一服务且不频繁改动如果你的树莓派只当一个Web服务器上面只跑一个固定的页面一年都用不到维护几次。这种情况下引入Docker确实有点杀鸡用牛刀。你只需要把默认的Nginx或Apache装好把网页文件丢进去配上开机自启完事。额外的Docker层只是增加你记忆的负担。6.2 极低配设备树莓派Zero、树莓派Pico这种内存只有512MB甚至更低的设备上Docker引擎本身要占掉不少内存和CPU资源。此时直接在系统里运行单个轻量级服务是最合理的。Docker引擎 基础镜像的常驻内存开销在低配设备上不能忽略。6.3 需要直接操作硬件和低层内核Docker容器可以访问GPIO吗可以通过挂载/dev/gpiochip0或使用--privileged模式来部分实现但如果你做的项目本质是一个实时控制程序对I/O延迟和内核模块的依赖非常高直接在宿主机系统里跑更合适。树莓派做GPIO控制、PWM输出、摄像头模组直读这类项目时我不会推荐Docker化。这也正好回应标题里的当系统镜像遇上服务增长Docker是用来解决服务数量增多、环境互相制约的问题的不是用来解决实时硬件控制问题的。工具要用在合适的场景里。7. 从这台树莓派开始为后面几篇文章做个小铺垫写到这里相信你已经理解了我为什么在网页服务器这个项目上选择和Docker站在一起。服务永远在增长系统镜像却在原地踏步不想办法把服务之间的环境依赖彻底隔开迟早有一天会被乱七八糟的配置追着跑。如果你也打算在树莓派上折腾网页服务器并且预感未来会不止一个服务那我的建议很明确从第一天就拥抱Docker。不用急着把现有服务全部容器化但新服务一定要先容器化再部署。后面我准备写的是怎么在树莓派上把Docker和Docker Compose装好有哪些坑比如换源的问题、ARM架构镜像拉取的问题如何用Docker部署一个包含前端、后端、数据库的完整网页服务器如何用Compose编排多容器服务让它们自动互相通信如何把容器里的数据妥善管理好做到清清爽爽迁移和备份我在实际折腾树莓派和Docker的过程中踩过不少坑也总结过不少经验。这个系列会尽量把这些实战细节都记下来让有同样需求的朋友少走弯路。这一篇的核心意思就一句话当你的树莓派不再只是玩具而是真的要成为一台服务器时别把服务直接塞进系统的胃里要把它们装进一个个标准化的集装箱里。下一篇文章我们正式在这块小ARM主板上装Docker。