把树莓派当服务器用这件事我前前后后折腾了五六年。最早是在一张32G的SD卡上装好Raspbian系统接着按教程一条一条跑命令装nginx、装PHP、装MySQL再折腾一圈配置把个人博客跑起来。那时候感觉挺有成就感的一台小卡片机就是一个真正的网页服务器了。可后来做着做着问题全来了博客要升级依赖面板要换个PHP版本Python脚本的库互相冲突一不小心把系统搞崩了就得重新烧镜像再从头手搓一遍环境。这种体验反复来几次之后我开始认真研究有没有一种方式能让整个网页服务的部署和运行跟底下的系统解耦让我不用天天担心“动一下这里会不会把那里搞坏”。答案就是Docker。这篇是“树莓派 Docker 化网页服务器”系列的第一篇重点不急着教怎么把所有服务都塞进容器而是先把一个最根本的问题聊透为什么我们已经有了完整的系统镜像还需要Docker系统镜像和服务增长之间到底存在什么不可调和的矛盾如果你也玩树莓派或者手里还有一台吃灰的小主机看完这篇应该能对“要不要上Docker”这个问题做出判断顺便也能拿到一套可以直接照抄的Docker基础部署方案。1. 项目背景与核心思路拆解1.1 我在树莓派上是怎么把服务器“叠”起来的先说场景。大多数人玩树莓派第一步都是刷系统、连SSH然后装个Web服务软件跑一个站点出来。我也不例外。最早那台树莓派3B我从apt源里装了nginx和mariadb然后把一个WordPress博客扔上去开放到内网用。当时感觉挺好系统也很稳定。但人总是贪心的。博客跑顺了之后我又给树莓派加了其他任务一个内网导航页、一个下载机管理面板、一个给手机同步照片的Web应用。你会发现一个很自然的趋势树莓派作为网页服务器的职能会从“单站点”迅速膨胀成“多站点、多服务”。树莓派的CPU、内存好歹能扛真正先扛不住的往往是系统本身。这时候我还在沿用老套路apt install、编辑配置文件、重启服务。家里有智能插座、有门磁、有摄像头我都想把它们的管理页面塞到这块板子上。每加一个服务系统里就多一组依赖、多一份配置、多一个常驻进程。有一次我升级了一个Python库连带把系统的某个依赖版本顶掉了nginx直接起不来。更难受的是我不知道它原来是怎么配的了——没有记录没有版本管理全靠记忆和运气。1.2 系统镜像的本质一张一次性快照我们平时说“树莓派系统镜像”本质上是一个完整的、预先打包好的操作系统快照。这份镜像保证了你烧录之后系统能够以某个确定的状态启动。听起来很完美对吧问题在于这份确定的状态只存在于你烧录完成的那一刻。之后的每一次操作——apt install、源码编译、改配置、装运行库——都是在系统原有的基础上再叠加一层“不可追踪的修改”。这些修改分散在根文件系统的各个角落/etc、/usr/lib、/var/www、/opt甚至会覆盖系统默认的Python版本。这和Docker的核心思路正好相反。Docker容器做的事情是把“应用的运行环境”当作一个单独的镜像层来管理应用本身、依赖库、配置文件、运行所需的内核接口全部打包进镜像。我们可以为每个服务构建镜像也可以直接使用社区维护的镜像。镜像是可重复构建、可随时销毁重建的“鸡蛋”宿主系统只是提供一块能孵化的“热炕”。运行环境变成了一种资产而不是系统的附属品。1.3 为什么是Docker不是虚拟机也不是LXC我在决定“把树莓派上的服务全部容器化”之前也认真对比过其他方案。虚拟机方案像QEMU/KVM隔离性是极好的但缺点太明显树莓派总共就那么点内存跑一台虚拟机光系统开销就要吃掉几GB还要模拟硬件性能损耗大。我的树莓派4B只有4G内存实在烧不起这个代价。LXC类方案本质上是运行在共享内核上的系统容器资源占用确实低。但LXC在树莓派社区里的镜像质量和生态没有Docker好而且它的管理工具链相对复杂一些对个人用户并不友好。最后是Docker。它的优势在我看来有三个具体层面镜像分层机制构建缓存在更新只用拉取增量层节省SD卡空间和带宽。声明式编排用docker-compose.yml把服务、端口、数据卷、网络关系一次写清楚同组服务一键起停。社区生态成熟几乎任何常见开源网页服务官方或社区都提供了适用于ARM的镜像省去大量编译时间。再加上Docker在树莓派上运行的开销非常小容器直接使用宿主内核进程隔离靠Linux内核的namespace和cgroups完成。它不是完美的但它是目前能让树莓派这种人门级硬件获得最好体验的容器方案。2. 系统镜像遇上服务增长两大核心痛点2.1 痛点一系统镜像无法解决“环境不可重建”我知道有些人会说跑网页服务器而已不用把环境搞得那么复杂大不了坏了就重刷系统。这话在服务只有一两个的时候确实站得住脚。一旦你跑的东西多起来重刷系统意味着什么经历过的人一定懂。重装之后要做什么先换源再装nginx、装PHP、装数据库然后把旧服务器的配置从记忆里一点一点“考古”出来站点配置文件、伪静态规则、PHP-FPM的进程数、数据库用户权限、证书路径、定时任务……这些配置写在分散的文件里而且很可能是经历了多次升级、打了多个补丁之后的状态。你亲手配置过一遍认真做笔记的花可能还能恢复个八成可如果当初是照着某篇博客随便配的那么很大概率第二次复现时会失败在某几个未知参数上。Docker处理这个问题的方式完全不同环境被固化成镜像文件镜像可以打标签、导成tar包、推到镜像仓库。换机器时docker run一条命令从镜像拉起来就是一模一样的环境。这套逻辑解放的不仅是“重装”更是日常维护——你可以放心大胆地在容器里折腾改坏了就删掉重新建环境还原成本几乎为零。2.2 痛点二服务增长带来的“依赖地狱”服务增长到一定数量之后系统的“依赖冲突”会集中爆发。我举个例子我有个项目A需要PHP 7.4和对应的nginx拓展。另一个管理面板项目B只支持PHP 8.1。如果不用Docker你就要在同一个系统里装两套PHP。方式不是没有通常是编译安装到不同目录然后手工切换再把nginx的fastcgi_pass指到不同的socket。操作起来很繁琐而且每次系统更新都可能把环境搞崩。还有更常见的Python场景。树莓派用户基本都会用Python写点自动化脚本或者跑个小Web服务。脚本1要装Home Assistant相关库脚本2要装机器学习库两个库对numpy的版本要求冲突。不用Docker的话只能借助venv、conda做环境隔离但这反过来又增加了部署时的复杂度。Docker对依赖冲突的处理方式极其简单粗暴每个容器自带一套专属的依赖环境和版本。PHP 7.4跑一个容器PHP 8.1跑另一个容器端口和目录彼此隔离。两个Python服务哪怕一个要numpy旧版一个要新版也互不干扰。在树莓派这种单机服务器上这种隔离能大幅省去“服务间互相踩脚”的烦恼。2.3 备份和迁移整卡镜像不是银弹我早期备份树莓派系统方式非常原始把SD卡拔出来用dd命令做整卡镜像。这个方案稳妥确实稳妥但缺点也很多。首先是体积问题。一张32G的SD卡即使实际数据只用了8Gdd出来的镜像也会接近卡的总容量。如果你为了保险每周做一次那么你会迅速积累几百GB的备份文件存储成本和备份耗时都相当夸张。其次是恢复问题。整卡恢复听起来简单把镜像写回去就好。但如果你换了更大容量的SD卡恢复之后还要处理分区扩容如果你换了一台不同型号的树莓派某些在旧硬件上运行良好的内核模块和驱动可能在恢复后不兼容。Docker化的部署模式天然适合备份和迁移。通常只需要备份两部分内容docker-compose.yml文件或其他编排文件记录服务的定义。需要持久化的数据卷比如数据库文件、上传目录、配置文件的外部挂载目录。真正执行迁移时新机器上只要装了Docker把备份的数据目录拷过去docker compose up -d服务就能以几乎无感的方式恢复。这个体验和整卡镜像相比完全是两个时代的产品。3. Docker化网页服务器的总体设计与架构3.1 Docker在树莓派ARM平台上是怎么运行的要把树莓派上的Docker用好得先搞清楚它的底层逻辑否则遇到问题都不知道怎么排查。Docker引擎由几个核心组件组成dockerd守护进程、containerd容器运行时、runcOCI运行时实现。当你在树莓派上执行docker run时流程大致是docker客户端向dockerd发送指令dockerd从远程拉取镜像解包为分层文件系统然后通过runc创建进程并启动容器。树莓派本身用的是ARM处理器。传统的树莓派3B及更早型号是32位armv7l树莓派4B和5支持64位的arm64指令集。Docker镜像也区分架构标签比如nginx:latest这个标签下面同时存在linux/arm64和linux/arm/v7的变体。拉取时Docker会根据当前系统的架构自动选择对应变体这就是为什么我们在树莓派上使用官方镜像基本不需要做额外处理。存储驱动方面树莓派SD卡上Docker默认使用overlay2。这个驱动利用内核的UnionFS能力把镜像的只读层和容器的可写层叠加在一起。多个容器共享基础层可以有效减少磁盘占用但可写层的频繁写入依然会损耗SD卡寿命这一点我后面会专门展开。3.2 服务目录与数据卷的规划我见过很多玩树莓派的人上Docker之后依然很随性docker run参数随手敲容器到处乱建数据散落在系统各个目录。这种用法用久了Docker会从“解决混乱”变成“制造混乱”。我的做法是所有项目统一目录管理。比如我把网页服务都放在/opt/services下面每个服务一个子目录目录里放docker-compose.yml和一个data子目录。data目录用于存放该服务需要持久化保存的数据。举个我自己的目录结构/opt/services/ ├── blog/ │ ├── docker-compose.yml │ └── data/ │ ├── nginx/ # 站点配置和日志 │ └── mysql/ # 数据库数据文件 ├── nav/ │ ├── docker-compose.yml │ └── data/ │ └── app/ # 导航页应用数据 └── photo/ ├── docker-compose.yml └── data/ └── uploads/ # 照片上传目录这么做的原因是当服务需要迁移或者容器需要删掉重建时数据还在宿主机上不会因为容器消失而丢数据。这也就是Docker“无状态容器”的概念——容器本身可以被任意销毁和重建数据全部留在宿主机挂载的目录或者数据卷里。3.3 服务拆分粒度不要从一个极端走到另一个极端Docker容易让人上头有些人会陷入“万物皆容器”的狂热一个服务里跑nginx拆成容器A跑PHP-FPM拆成容器B跑数据库客户端再拆个容器C。拆太细的结果是容器数量暴增联合编排复杂度提高内存占用也跟着上去。树莓派本来就资源有限这个极端完全没必要走。反过来也有人图省事把nginx、PHP、数据库全部塞进同一个容器通过supervisor管理多个进程。这种玩法虽然也能使用Docker的镜像分发能力但失去了进程隔离和独立扩容的优势不够“正统”后续维护也容易踩坑。我个人的判断标准是有独立生命周期、独立配置、可能单独升级的组件就分开成容器。比如nginx和php-fpmnginx负责静态资源和高并发接入php-fpm负责动态解析它们解耦后的升级补丁可以互不影响。而一些辅助工具比如在容器里加个cron任务定期清理日志这种就依赖宿主机的cron没必要额外起容器。最终我留在生产环境里的服务一般一个业务模块拆成两到三个容器既能保证好用又不至于把资源浪费在大量容器进程的内耗上。4. 实操在树莓派上完成Docker基础部署4.1 第一步烧录系统并完成基础配置Docker要在树莓派上稳定运行系统层面最好是一个干净的64位系统。我更推荐Raspberry Pi OS Lite它是无桌面版省下的内存都留给容器用。烧录工具直接用官方的Raspberry Pi Imager选择操作系统时找到Raspberry Pi OS Lite64-bit再选择SD卡。烧录前可以在自动配置界面里提前开启SSH、设置用户名和密码、配置WiFi这样可以插电后直接通过SSH登录省去接显示器键鼠的麻烦。系统启动后第一件事是换apt源。默认源在海外国内访问经常很慢。我习惯改成清华源或阿里云源。修改之前先备份原文件sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak然后编辑/etc/apt/sources.list把网址里的deb.debian.org替换成mirrors.tuna.tsinghua.edu.cn或者mirrors.aliyun.com。需要说明的是如果系统是最新的bookworm源格式可能涉及Debian的deb822多文件结构具体的文件路径是/etc/apt/sources.list.d/raspi.list和/etc/apt/sources.list.d/debian.sources操作前先看清楚现有配置不要一刀切割断所有源。改完执行sudo apt update sudo apt full-upgrade -y4.2 第二步安装Docker引擎安装Docker有多种方式官方推荐的是添加Docker官方apt仓库后安装docker-ce但考虑到网络环境和“能用就用”的原则在树莓派上我很推荐直接用Debian仓库自带的docker.io包。它的优势有两个一是版本经过了发行版测试稳定性和依赖兼容性有保障二是默认仓库就在本地源里换过国内源后下载速度很快不需要额外添加第三方仓库。安装命令sudo apt install -y docker.io docker-compose-v2docker-compose-v2提供的是docker compose插件命令注意这个包名在不同版本里可能叫docker-compose-plugin。装完之后验证一下docker --version docker compose version再把当前用户加入docker组这样不用每次执行docker命令都加sudosudo usermod -aG docker $USER执行完这条命令记得重新登录SSH或者重启一下用户组权限才会生效。然后设置Docker开机自启sudo systemctl enable docker sudo systemctl start docker4.3 第三步配置镜像加速与日志清理策略树莓派上跑Docker最影响体验的一个问题就是拉镜像慢。由于某些大家都懂的网络原因直接连接Docker官方镜像仓库经常超时。在国内环境里最稳妥的做法是配置registry mirror。编辑/etc/docker/daemon.json如果文件不存在就创建{ registry-mirrors: [https://你的专属加速地址.mirror.aliyuncs.com] }阿里云容器镜像服务个人版提供免费的镜像加速地址配置方法是登录阿里云控制台在容器镜像服务的镜像工具页面找到“镜像加速器”会显示一串专属地址。把它填进去保存后重启Dockersudo systemctl daemon-reload sudo systemctl restart docker除了镜像加速日志清理策略同样重要。默认情况下Docker会采用json-file日志驱动把容器的标准输出保存到宿主机的日志文件里。如果某个容器写日志的频率很高一段时间后日志文件会膨胀到几GB直接写爆SD卡剩余空间。我的daemon.json会同时加上日志大小限制{ registry-mirrors: [https://你的专属加速地址.mirror.aliyuncs.com], log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这样每个容器最多保留30MB日志3个文件每个10MB旧日志自动被旋转删除。对网页服务器来说这个量级足够排查问题又不会把存储空间耗尽。4.4 第四步跑起第一个网页容器验证环境Docker环境装好之后先用一个最简的网页容器验证整套链路能跑通。我会用nginx官方镜像做测试docker run -d --name test-nginx -p 8080:80 --restart unless-stopped nginx:stable-alpine这里解释一下参数含义-d后台运行--name给容器命名-p 8080:80把宿主机的8080端口映射到容器的80端口--restart unless-stopped除了手动停止以外容器异常退出或开机时都自动重启镜像跑起来后在浏览器里访问http://树莓派IP:8080如果能看到nginx的欢迎页就说明安装成功。接下来验证数据挂载。我们把宿主机上的静态页面目录挂载进容器mkdir -p ~/web-demo echo h1Hello from Raspberry Pi Docker/h1 ~/web-demo/index.html docker run -d --name web-demo -p 8081:80 -v ~/web-demo:/usr/share/nginx/html:ro --restart unless-stopped nginx:stable-alpine访问http://树莓派IP:8081如果能看到自定义页面说明宿主机目录和容器目录的挂载关系已经生效。有了这条链路后面所有复杂的网页服务部署本质上都是在这个基础上叠加数据库容器、应用容器、反向代理容器而已。5. 常见问题与避坑实录5.1 拉取镜像太慢、超时或失败这是新手遇到最多的拦路虎。症状通常是docker pull卡在等待很久最后报connection refused或timeout。排查思路第一步确认daemon.json里的registry-mirrors配置是否生效。可以执行docker info在输出的Registry Mirrors一栏查看已加载的镜像加速地址。第二步检查指定的镜像是否存在。某些特殊镜像只针对x86架构发布在树莓派上拉取时会提示no matching manifest for linux/arm64。这时候需要到Docker Hub搜索确认是否有arm64或arm/v7标签。第三步考虑换标签。比如nginx的latest标签体积较大可以指定nginx:stable-alpine或nginx:alpine镜像更小拉取速度也会快不少。5.2 内存不足导致容器随机被杀树莓派4B通常有4G或8G内存跑三五个容器问题不大。但如果你同时跑数据库、Python应用、多个Web服务或者把树莓派3B这种1G内存的机型也塞进多个容器就很容易触发OOM。最直观的症状是docker ps看到的容器状态正常但访问服务时网络不通后面去查dmesg会看到oom-killer把某个进程杀掉了。解决办法有几种增加swap空间。Raspberry Pi OS默认会启用一个名为swap的交换分区但容量不大。可以在/etc/dphys-swapfile里调整CONF_SWAPSIZE的大小改完之后重启dphys-swapfile服务。给单个容器设置内存上限。在docker run里加--memory参数例如docker run -d --memory512m --memory-swap756m --name web-demo -p 8081:80 nginx:stable-alpine这样容器最多只能用到512MB物理内存和额外256MB的swap超过限制就会被内核杀死而不是拖垮整个宿主系统。在docker-compose.yml里对应写法是deploy.resources.limits只是自建compose文件时注意该字段在非Swarm模式下默认会被忽略需要使用docker compose版本较新时用--compatibility标志或者直接在compose里写mem_limit的旧式顶层字段。还有一招是限制并发进程数尤其在跑PHP-FPM或Python Gunicorn这类服务时worker数量设太多会直接吞光内存。宁可让worker少一点也不要在树莓派上盲目追求并发。5.3 SD卡写坏风险SD卡作为树莓派唯一的存储介质最怕的就是频繁写入。Docker容器的可写层、日志文件、数据库文件、以及镜像分层缓存都会持续产生写入。长期高强度使用后SD卡很可能出现文件系统只读或校验错误。我有两套应对方案第一套是减少写入。把容器日志都限制大小前面配置的log-opts就是这个目的。把/tmp、/var/log目录挂载到内存文件系统tmpfs减少对SD卡的写入。如果是跑数据库容器尽量把数据文件放在外接移动硬盘或NVMe固态上而不是SD卡。第二套是给SD卡留足余量。选择A2级别的UHS-I SD卡或者直接使用树莓派官方推荐的SD卡型号不要贪便宜买一些杂牌低速卡。定期创建数据卷和配置文件的备份这样即使SD卡损坏也能在换一张卡后迅速恢复系统和服务。5.4 容器内时间不对跑网页服务时如果后端业务对时间敏感比如记录日志、生成签名、处理cookie容器内的时区不正确会带来很大麻烦。很多官方镜像默认的时区是UTC和国内东八区差了8小时。日志里看到的时间总是比实际时间早8小时排查线上问题时会很懵。解决办法有两个思路一是在docker run或compose里设置TZ环境变量environment: - TZAsia/Shanghai二是把宿主机的时区文件挂载进容器volumes: - /etc/localtime:/etc/localtime:ro两种方式我都在用比较推荐第一种因为只需要在环境变量里声明一句不需要依赖宿主机的文件结构。5.5 docker.sock权限问题每次执行docker命令都要加sudo很影响操作效率所以加入docker用户组是个常规操作。但把用户加入docker组等价于给了这个用户对Docker守护进程的完整控制权因为它可以通过docker run启动一个挂载宿主系统根目录的容器从而直接读写宿主机的文件。这个权限级别已经接近root了。所以建议只在受控的、单用户使用的树莓派上执行这个操作并且要管好自己的SSH密钥。如果你的树莓派暴露在公网上建议先将SSH设置为密钥登录并禁用密码登录再谈docker组权限的事。另外不要在容器里忘记做端口映射配置而把数据库端口直接暴露到公网这是很多树莓派被入侵的主要原因之一。6. 写在后面这个系列的下一步把Docker基础环境搭起来只是“树莓派 Docker 化网页服务器”这系列文章的第一步。按照我自己的规划后续会逐步把博客、导航页、照片同步服务这些实际业务逐个迁移进容器并针对每个服务给出可复用的docker-compose配置以及如何用nginx容器统一做反向代理、如何配置HTTPS证书、如何用健康检查实现容器自动重启这些都是把“能跑的服务器”升级成“稳定可维护的服务器”必须跨过的坎。我个人在实际操作中最深的体会是Docker不是银弹它不能帮你在SD卡已经损坏时找回数据也不能解决你业务本身设计上的问题。但它实实在在解决了一个非常痛的问题——让你在树莓派上跑的每一个服务都拥有一个可重生的环境、可打包的描述、可搬家的能力。系统镜像给你一个起点Docker帮你管理之后的每一次变化。如果你手头正好有一台树莓派建议按这篇文章把Docker环境跑起来用nginx挂一个静态页面感受一下容器的创建、销毁、重建过程。先把这种感觉建立起来后面学什么都快。