几年前我拿到第一块树莓派时想法特别朴素烧一张系统镜像装好 Nginx、PHP 和数据库把网页服务器跑起来就完事。说实话最初那段日子确实省心镜像刷进去几条apt install命令敲完博客就能访问了。可后来的事很多人应该也遇到过同一个树莓派上服务从一两个涨到七八个系统镜像里的依赖开始互相打架升级一个软件包可能把另一个服务搞挂重装系统又心疼数据。也是从那时候起我认真开始研究 Docker并最终把所有网页服务全部容器化。这个系列的第一篇我想先把“为什么我们需要 Docker”这件事讲透而不是急着丢一堆 Dockerfile 出来。适合的是那些已经能在树莓派上搭好一个网页服务器、但隐隐觉得系统越来越乱的同学。1. 只靠系统镜像跑网页服务器是怎么从“省心”走到“闹心”的1.1 一张镜像装好一切的最初快感树莓派玩网页服务器最经典的上手方式就是“刷镜像 装环境”。我当时用的是 Raspberry Pi OS烧录后开机先改软件源然后执行sudo apt update sudo apt install -y nginx mariadb-server php-fpm再简单配置一下 Nginx 的默认站点把网站文件丢进/var/www/html一个能对外访问的网页服务器就诞生了。整个过程不超过半小时对于当时只想挂一个个人博客的我来说这个体验非常好。这套模式的核心逻辑是把整个操作系统镜像当作“运行底座”所有服务共享同一个系统环境。服务少的时候完全没问题因为 Nginx、PHP、MySQL 各自安装路径固定、配置路径明确默认行为也能满足需求。我当时还在 SD 卡上做了个简单的分区备份觉得系统镜像就是最可靠的环境交付方式坏了就重刷多简单。1.2 需求上涨后系统开始“不听话”真正的转折点是我在同一个树莓派上加了第二个网站、第三个网站后来又跑了一个内部 API 服务和一个小型定时任务脚本。依赖问题首先爆发。第一个问题就是版本冲突。博客需要 PHP 7.4新的应用却要求 PHP 8.1 或者 Node.js 18。树莓派官方源里的 PHP 版本只有一个主线你装上 8.1旧程序可能因为某个函数行为变化直接报错你要是为了旧程序锁版本新服务又跑不起来。第二个问题是全局文件系统变乱。今天装个 Python 包明天给 Nginx 加个模块后天发现/var/www/html的权限被某个安装脚本改掉了。到后来我已经记不清哪些文件是由哪个软件包安装的哪些配置是我手动改的哪些又是某个服务启动时自动生成的。印象最深的一次是我为了给一个新产品装扩展执行了apt upgrade结果把 PHP-FPM 从 7.4 升到了 8.1第二天博客页面直接白屏。排查了半天才意识到是某个旧插件不兼容新版本。那一刻我才理解系统镜像只保证了“初始状态”是干净的但它不会阻止你后续在系统里堆积越来越多的改动直到整个环境变成一团乱麻。1.3 重装系统的“后悔药”也不好用遇到系统乱套最本能的反应是重刷镜像重来一遍。这个思路在只有一个服务时可行但服务多了以后就会发现重装根本不解决问题。重刷镜像后你要重新安装所有软件、改回所有配置、恢复网站文件、导入数据库。更棘手的是你当初修改过哪些配置文件、安装过哪些软件可能早就忘了。我试过一次“从备份恢复”把旧网站目录直接拷回去但数据库版本不一致导致数据表打不开前后花了一个周末才弄干净。而且树莓派这种设备SD 卡随时可能出问题换一块卡、换一台树莓派就得手动重演一次整个部署过程。这套流程非常依赖人的记忆只要漏掉一个软件包服务的表现就会不一样。到了这个阶段我发现问题根本不是“我会不会装服务”而是“怎么把一个干净的服务环境从混乱的系统里独立出来”。2. “系统镜像”思维的三个核心缺陷2.1 依赖关系是全局共享的而不是按应用隔离的树莓派默认的软件安装方式无论是apt还是pip、npm默认都是安装到全局环境中。每个软件包在系统里只有一份升级或删除一个包影响的是所有依赖它的服务。这就好比一个厨房里好几道菜共用同一口锅、同一套刀具。你想给其中一道菜换一种不粘锅结果其他菜也在这个锅里炒只能被迫一起适应新锅你要是把锅撤了所有菜都得停火。系统包管理器本质上是依赖全局共享的它在做依赖解析时会优先考虑“系统所有软件的总依赖”而不是“某一个具体服务的依赖”。对于网页服务器来说这种全局共享带来的后果很现实你为了 A 项目安装了某个共享库的新版本结果 B 项目在启动时报“找不到符号”你为了 B 项目回退版本A 项目又无法正常运行。我后来拆解树莓派上的几个服务时发现libssl、libxml2这些底层库的版本冲突几乎是最常见的问题来源。2.2 系统状态是“累加态”没有任何回滚点系统镜像只负责记录最初刷入系统时的状态之后所有变更都是“累加”的。今天改一个配置明天装一个软件后天删掉一个目录系统都会逐步偏离镜像的初始状态。可是镜像本身并不会告诉你“你改了什么、当前状态和上次备份差多少”。有人会说我定期打快照。但树莓派上做整卡镜像备份耗时不说恢复时还必须关停服务整个过程像是给一台正在运行的机器换心脏。而且你无法精准地只回滚某一个服务比如“只把 Nginx 配置退回到上周”因为系统上下文早就变了。Docker 的价值在这里非常直观容器是镜像的实例镜像分层构建。你可以直接docker run跑旧版本镜像相当于把整个运行环境回滚到过去某个“封装好的时间点”不需要影响其他服务。2.3 环境一致性和迁移性差玩树莓派的人多少都有过“从一个环境搬到另一个环境”的经历。树莓派 3B、4B、5、甚至 x86 的小主机CPU 架构、系统版本、可用内存都不一样。直接在系统里手动部署一套网页服务器换一台设备必须重新走一遍部署流程。还有一个更隐蔽的问题你手动安装的服务组合可能只在你当前这套系统上能跑。一旦你想把博客从树莓派迁移到一台云服务器或者从 32 位系统换到 64 位系统很多软件包源、编译路径、依赖关系都会出现差异。系统镜像不是环境交付物它只是“一台机器的底片”。真正可复现的环境交付物应该包括“操作系统 应用代码 所有依赖 配置”而不是一台机器的完整快照。3. Docker 不是虚拟机它是把“应用 运行环境”封装成一个标准交付物3.1 核心抽象镜像、容器、Dockerfile很多第一次接触 Docker 的人会把它理解成轻量虚拟机这个比喻部分正确但不准确。虚拟机需要模拟完整硬件、运行完整操作系统内核而 Docker 容器只是共享宿主机内核在用户态做了文件系统、进程、网络的隔离。Docker 里最核心的三个概念是镜像、容器和 Dockerfile。镜像可以理解成一个“只读的打包好的运行环境”。它里面包含了你希望应用运行所需的操作系统基础库、代码、依赖和配置。你可以把镜像想象成一份“蛋糕模具”或者一个集装箱模板。容器则是镜像运行起来后的实例它是可写、可启动、可停止、可删除的。Dockerfile 则是定义“如何一层层构建镜像”的配方文件。关键在于镜像不是一个大文件塞进来直接用而是分层存储的。每一行 Dockerfile 指令基本会生成一层运行时这些层叠加在一起并通过写时复制机制生成可写层。这种分层设计让镜像可以复用多个容器共用相同的基础层只在上层保存差异拉取新镜像时也能利用本地已有缓存。3.2 为什么它恰好能治“依赖冲突”每个容器独立文件系统、独立依赖依赖冲突的根源是全局共享Docker 解决它的方式也很简单每个容器都有自己独立的文件系统容器与容器之间互不感知。同一个树莓派上你可以同时跑一个基于 Debian、内置 PHP 7.4 的容器再跑一个基于 Alpine、内置 PHP 8.1 的容器。这两个环境里的/usr、/etc完全彼此独立A 容器里升级任何库都不会影响 B 容器。我之前有个在树莓派上跑的 Nextcloud 需要 PHP 7.4另一个新开发的接口服务要 PHP 8.1。传统方式下这是不可能的至少会折腾很久。但在 Docker 下我只是定义了两个拥有不同基础镜像的容器Nginx 做反向代理按照不同域名把请求转发到不同容器几分钟就搞定。这种感觉非常奇妙的——不是我在“管理依赖版本”而是我把每个服务连同它的依赖一起关进了一间独立的房子门牌号不同水电端口和网络由外部统一分配。3.3 在树莓派上的轻量性共享宿主内核几乎无额外性能开销树莓派的内存普遍不大4GB 已经算宽敞2GB 也依然常见。虚拟机在派上不现实因为每个虚拟机动辄几百 MB 到 1GB 内存同时跑两三个就会卡。而 Docker 容器只是进程级隔离没有一整份操作系统的内存开销。一个最小化的 Alpine Linux 容器基础镜像可能只有几 MB即便跑一个 Nginx 容器内存占用通常也就是二三十 MB 的量级。树莓派上跑三五个容器完全可行这和跑三五个系统进程的感受是相似的。当然这不意味着 Docker 没有开销。镜像占用磁盘、运行时会有额外的存储驱动层、网络转发也会消耗少量 CPU。但相比虚拟机它已经轻了不止一个量级。对于树莓派这种资源紧张的小机器来说Docker 是目前在“环境隔离”和“资源占用”之间最平衡的选项。4. 把网页服务器搬进 Docker第一次跑通 Nginx 容器的过程4.1 准备系统64 位系统是现代 Docker 的默认要求早期树莓派系统默认是 32 位但如今官方系统已经提供 64 位版本树莓派 5 更是全面支持 64 位。如果你打算正经跑 Docker我建议直接用 64 位 Raspberry Pi OS或者 Ubuntu 22.04 的 64 位镜像。为什么强调这个Docker Hub 上的官方镜像很多对arm64架构有更好的支持。32 位系统只能跑armhf或兼容层镜像选择更少性能也更差。我自己在树莓派 4B 和树莓派 5 上都试过64 位系统拉取官方nginx、php镜像都很顺利。刷好系统镜像后先更新系统避免后期因为软件源索引太旧出现依赖错误sudo apt update sudo apt upgrade -y国内网络环境下如果拉取镜像慢可以按 Docker 官方文档提示配置一个合规的镜像加速地址。这里注意加速地址要以你实际可用的为准别用网上来路不明的配置。4.2 安装 Docker Engine树莓派上安装 Docker 有两种常见方式。第一种是直接用官方安装脚本curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh这种方式装的是 Docker Engine 社区版版本较新步骤简单。另一种是通过 Debian/Ubuntu 软件源安装sudo apt install -y docker.iodocker.io的好处是随系统源走安装方便但版本可能偏旧。我个人的建议是如果树莓派不是用来做生产环境docker.io就够用如果想跟新的 Compose 特性和 Docker 功能保持一致用官方脚本更好。安装完成后再做两件事把当前用户加入docker组避免每次敲命令都要sudo设置开机自启。sudo usermod -aG docker $USER sudo systemctl enable --now docker注意加入docker组后需要重新登录一次才能生效。4.3 运行第一个 Nginx 容器跑通网页服务器最直观的方式是先拉一个 Nginx 镜像然后启动容器。docker run -d --name web-blog -p 8080:80 nginx:stable这条命令里的参数含义分别是-d后台运行容器--name web-blog给容器起个名字方便管理-p 8080:80把宿主机的 8080 端口映射到容器内的 80 端口nginx:stable使用 Nginx 官方稳定版镜像启动成功后在浏览器里访问http://树莓派IP:8080就能看到 Nginx 默认欢迎页。这一步看起来很简单它背后的一次关键变化是以前我是在系统里安装 Nginx现在则是运行一个“自带 Nginx 的系统”。宿主机里没有任何 Nginx 进程没有/etc/nginx没有/var/www/html但网页服务就是能跑通。4.4 容器常用操作与日志排查容器跑起来后日常操作和直接管系统服务略有不同。查看所有容器docker ps -a查看某个容器的日志docker logs web-blog进入容器内部docker exec -it web-blog bash注意容器内部是一个精简环境很多调试工具默认没有。比如 Nginx 镜像里可能没有vim、没有curl需要apt install后才有。这也是刚开始用 Docker 的人经常疑惑的地方。我觉得新手最容易踩的坑是总想进入容器“修东西”这其实是把容器当虚拟机用了。更合理的做法是通过 Dockerfile 重新构建镜像或者在宿主机上用数据卷挂载配置。进入容器一般是临场排查不是常规运维手段。4.5 实测资源占用我在树莓派 4B4GB 内存上实测跑一个 Nginx 容器空闲时内存占用大约 20~30MBCPU 几乎为 0。作为对比直接在系统里跑原生 Nginx内存占用可能更低但那只是一份服务开销。如果你有多个网站、多个应用每个应用要是都在系统里装一遍完整运行环境内存很容易爆而用容器每个服务只额外增加十几兆到几十兆。这一点彻底改变了我对树莓派部署服务的预期以前我会谨慎计算“系统本身 数据库 Nginx 应用”的内存余量现在我更多考虑“容器运行时 数据卷 端口映射”一套环境交付物可以随时复制到另一台派上。5. 当服务真正增长时Docker Compose 是第一个要学的编排工具5.1 为什么不能继续用一长串 docker rundocker run适合跑单个容器但网页服务通常不止一个容器。典型的博客系统可能是nginxphp-fpmmariadb三个容器每个容器都有端口、环境变量、数据卷和依赖关系。如果全靠docker run管理每次重启树莓派后你要手动恢复所有容器还要记住每个容器的参数。更麻烦的是容器之间的启动顺序有讲究如果数据库没起来应用先起来就会反复报错。这时候 Docker Compose 就很有用。它用一份 YAML 文件描述整套服务把镜像、端口、环境变量、数据卷、重启策略都写在文件里然后一行命令拉起所有服务。这份配置文件还能放进 git 管理环境变化有据可查。5.2 一个 Web 服务器组合的 docker-compose.yml 示例下面是一个我常用的树莓派网页服务器组合包含 Nginx、PHP-FPM 和 MariaDBversion: 3.8 services: nginx: image: nginx:stable container_name: web_nginx ports: - 80:80 - 443:443 volumes: - ./www:/var/www/html - ./nginx/conf.d:/etc/nginx/conf.d - ./ssl:/etc/nginx/ssl depends_on: - php restart: unless-stopped php: image: php:8.2-fpm container_name: web_php volumes: - ./www:/var/www/html restart: unless-stopped db: image: mariadb:10.11 container_name: web_db environment: MYSQL_ROOT_PASSWORD: example_root_pwd MYSQL_DATABASE: myweb MYSQL_USER: myweb_user MYSQL_PASSWORD: myweb_pwd volumes: - db_data:/var/lib/mysql restart: unless-stopped volumes: db_data:这套组合的逻辑是Nginx 对外监听 80/443转发 PHP 请求给php容器php容器和nginx容器共享同一个./www目录保证网页文件两边都能读到数据库单独使用独立数据卷保证删除容器后数据不丢。用docker compose up -d就能一次性启动所有服务。如果你要部署一个新版本修改配置后执行docker compose up -d --builddepends_on保证了 Nginx 会等 PHP 容器先启动数据库也有独立的健康检查机制避免应用启动阶段连不上数据库。5.3 数据持久化的量和备份思路网页服务器最宝贵的是数据尤其是数据库和网站文件。在 Docker 里容器删除或重建都不会保留容器内写入的数据所以必须使用数据卷或绑定挂载。我一般把数据分成三类网站源码用绑定挂载直接映射到宿主机目录比如./www:/var/www/html改文件即时生效。数据库文件用命名卷比如db_data:/var/lib/mysql避免宿主机目录权限导致数据库无法启动。配置文件用绑定挂载把宿主机nginx/conf.d挂到容器内方便用宿主机编辑器修改后执行docker compose restart nginx。备份也很简单。数据库用容器里的mysqldump或者直接用docker compose exec进入容器导出。网站源码直接压缩宿主机目录tar czf web_backup.tar.gz ./www ./nginx ./ssl这种备份方式粒度清晰比整卡镜像备份省太多时间。整卡备份动不动几个 GB而容器配置加网站文件可能几十 MB 就搞定且恢复时只要在新环境里重新 up 一遍。5.4 日常运维命令Compose 的日常运维命令很固定常用的有这么几个# 启动服务 docker compose up -d # 查看服务状态 docker compose ps # 查看日志跟随输出 docker compose logs -f # 停止并删除容器不删除数据卷 docker compose down # 重建容器代码或镜像变更后 docker compose up -d --build注意docker compose down默认不会删除 named volume。如果你想彻底清掉数据需要加-v。这个参数我建议只有在确定数据不要时才用否则手一滑整个数据库就没了。6. 树莓派上用 Docker 跑网页服务器的几条普通文档不会写的经验6.1 日志膨胀会提前消耗 SD 卡寿命树莓派最怕的其实是 SD 卡频繁写入。很多容器默认把日志写到 Docker 的 json-file 文件里时间一长日志文件可能膨胀到几个 GB既占空间又加剧 SD 卡磨损。我在 Compose 里会统一给服务加上日志轮转限制logging: driver: json-file options: max-size: 10m max-file: 3这段配置让每个容器日志单文件最大 10MB最多保留 3 份。别小看这一行它能让 SD 卡的寿命明显延长。6.2 镜像体积不是越小越好但要学会看很多人一看到 Alpine 版本镜像体积小就无脑选但 Alpine 默认用 musl libc跟 Debian 系镜像编译出来的二进制有时不兼容。如果你的项目依赖pdo_mysql、gd这类扩展在 Alpine 里安装可能要多花时间折腾编译依赖。我的经验是先用官方推荐镜像跑通再看需要不需要瘦身。树莓派的 SD 卡容量虽然紧张但也不至于差几百 MB 就装不下。用docker system df可以查看当前镜像、容器和卷占用的空间定期清理无用镜像比一味追求小镜像更重要。6.3 network_mode: host 与端口映射的取舍Docker 默认使用 bridge 网络通过端口映射访问容器。好处是多个容器可以同时监听不同宿主端口互不冲突。缺点是多一层 NAT性能有一点损耗但对树莓派上的网页服务器来说几乎无感。有些人为了减少网络开销喜欢给容器设置network_mode: host让容器直接占用宿主机网络。这种模式性能更好但多个容器都要监听 80 时必然冲突而且端口不再隔离管理起来很容易乱。我的建议是多服务部署默认用 bridge 端口映射别图省事开 host。如果真有性能要求优先检查代码本身和数据库慢查询而不是纠结 Docker 网络转发那一点点开销。6.4 有些场景还是别急着上 DockerDocker 解决的是“环境交付”和“依赖隔离”问题但它不是所有树莓派应用的万能答案。如果你的场景是驱动 GPIO、读取摄像头、使用特定内核模块或者要跑实时性要求极高的 PWN 波形输出容器化反而会带来不必要的复杂度。Docker 容器共享宿主机内核对底层设备的控制权限和宿主机程序有差异操作时要加很多权限参数远不如直接在系统里跑得顺手。所以回到标题里的问题——“为什么我们需要 Docker”不是因为它流行而是当你在一个系统镜像上把网页服务器从 1 个加到 5 个、从纯静态发展到动态应用加数据库时只有把每个服务连同环境一起装进容器才能重新获得“干净”和“可控”。至少对我而言从第一只 Nginx 容器跑通的那一刻开始树莓派上的网页服务器终于不再是“重装系统的循环”了。后面我会在这个系列里继续拆解怎样用 Dockerfile 把网页项目本身封装成镜像以及怎样让容器内的 PHP 和数据库更高效。