这两年不管是后端、运维还是做前端自建个人项目大家聊到“怎么把服务稳定跑起来”基本绕不开 Docker。Docker 是什么一句话讲清楚它是一种容器化技术把应用和它运行所需的依赖、配置、环境一起打包成标准化的镜像再在任意装了 Docker 的机器上变成容器运行。这意味着你本地跑起来的东西在测试环境、生产环境里也能用同样的方式跑起来不再出现“在我电脑上是好的”这种尴尬。这篇文章我从项目设计思路、核心概念、完整实操到生产环境常见坑做一次系统复盘适合刚接触容器化、或者已经会docker run但总觉得理解不深的读者。1. 项目画像Docker 到底在解决什么问题1.1 从环境不一致说起先回想一下以前部署服务时最常见的场景代码在本地跑通了一放到服务器上就崩溃。原因可能只是服务器上的 Python 版本高了 0.1或者 MySQL 的编码集不一样又或者是某个系统依赖库没装。你花一天时间排错最后发现是环境差异这种时间损失真的很亏。Docker 的处理思路是把代码、运行时、依赖库、环境变量、端口配置全部打进一个镜像里。镜像相当于一个打包好的“完整运行环境”容器则是这个环境在机器上的运行实例。换个比喻来说传统方式像搬家时只搬家具到了新房子还得重新接水电、量尺寸Docker 则是把整个房间连同装修一起封装搬到哪都能直接住。这个设计之所以能成立靠的是底层两个机制命名空间容器里的进程、文件系统、网络、用户等资源被隔离在自己的命名空间里彼此看不见像多个独立的小隔间。控制组限制每个容器能使用的 CPU、内存、磁盘 IO防止一个容器把整台机器资源吃光。这也是容器和虚拟机最大的不同。虚拟机需要模拟一个完整的操作系统通常要占几个 GB 的磁盘、开起来要分钟级容器直接共享宿主机的内核镜像可能只有几百 MB启动速度是秒级。这也是我后来在项目里优先选择 Docker 的重要原因。1.2 它适合什么不适合什么不是所有场景都需要 Docker但它确实覆盖了绝大多数常见的工程痛点:适合用 Docker 的场景开发环境统一新同事入职拉代码后一条命令起数据库和中间件不用再折腾安装包。微服务拆分不同服务用不同语言、不同依赖版本容器天然隔离互不干扰。CI/CD 交付产物构建好的镜像可以推送到仓库部署时拉取即可回滚也简单。快速搭建中间件比如 Redis、MySQL、Nginx以前要下载编译安装现在一条docker run就能跑起来。不太适合用 Docker 的场景带 GUI 的桌面应用容器对图形界面支持比较麻烦。对极致性能敏感的高性能计算虚拟化层多少会有损耗。需要直接操作宿主硬件设备、内核模块的场景容器隔离反而成了障碍。所以我的原则是先用容器解决环境一致性和交付标准化不要把 Docker 神化。2. 核心概念拆解把这几个东西彻底弄明白2.1 镜像只读模板与分层缓存镜像是容器的模板它由一层层只读文件系统组成。每一层对应 Dockerfile 里的一条指令比如FROM拉取基础镜像RUN安装依赖COPY拷贝文件。这些层级会形成缓存构建时如果某一层没变就直接复用缓存构建速度会快很多。举个例子一个 Python 项目的镜像可能由这些层组成基础镜像比如python:3.12-slim安装 pip 依赖层拷贝项目代码层如果只改动代码依赖层没变重新构建时只需要重新拷贝代码而不用重新下载依赖。这个特性是我在设计 Dockerfile 时最关注的点。镜像常用操作也很简单# 查看本地镜像 docker images # 拉取远程镜像 docker pull nginx:1.27-alpine # 删除本地镜像 docker rmi nginx:1.27-alpine有一点值得专门提醒不要用docker commit来制作镜像。虽然它可以把一个容器的当前状态保存成镜像但会丢失 Dockerfile 的可追溯性镜像体积也容易膨胀里面的历史操作都无法复现。团队协作或者生产发布规范做法永远是用 Dockerfile 构建。2.2 容器可写层的运行实例有了镜像这个只读模板docker run会基于它创建一个容器并在最上层加一个可写层。你对容器内部文件系统的修改都写在这个可写层里容器删除后可写层也跟着消失。容器本质上是宿主机上的一个进程只不过被隔离在了自己的命名空间里。它和虚拟机的差异前面已经说过。这里用一个类比镜像是一张写满内容的光盘容器则是在某台机器上读取这张光盘并在上面做笔记。光盘本身不变笔记跟着你读完放下就没了。常用操作# 启动一个交互式容器 docker run -it ubuntu:22.04 bash # 查看运行中的容器 docker ps # 查看所有容器包括已退出 docker ps -a # 进入运行中的容器 docker exec -it my-container sh # 停止和删除容器 docker stop my-container docker rm my-container有个常见误解是“容器就是一台小虚拟机想怎么改就怎么改”。实际生产中我建议把容器当作一次性进程要改配置就改 Dockerfile重新构建、重新启动而不是进入容器去改文件。原因很简单容器一旦重建所有手动修改全都消失。规范化的交付流程应该保证任何环境都从同一个镜像得到同样的结果。2.3 数据卷把状态从容器里剥离出来前面说了容器的可写层生命周期很短容器删除后数据会丢。所以凡是需要持久化的数据比如数据库文件、上传的图片、日志文件都必须放到数据卷里。Docker 提供两种常见挂载方式命名卷由 Docker 管理的目录docker volume ls可以看到适合数据库数据这类不需要直接关心的内容。绑定挂载直接把宿主机的某个目录映射到容器里的路径适合看日志、改配置或者开发时热更新代码。用法示例# 使用命名卷挂载 MySQL 数据目录 docker run -d \ --name mysql-demo \ -v mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDroot \ mysql:8.0 # 使用绑定挂载把当前目录映射到容器工作目录 docker run -d \ --name app-demo \ -v $(pwd):/app \ my-app-image-v 卷名:容器内路径和-v /宿主机绝对路径:容器内路径的区别在于第一个冒号左边是卷名第二个是宿主机路径。很多新手踩坑都是把这两者混着用结果数据被写到了意想不到的位置。权限问题要特别注意宿主机目录如果权限不对容器里的进程可能没法读写。最常见的表现是 MySQL 容器启动时报数据目录权限错误。这种情况要么调整宿主机目录的属主和权限要么在挂载时指定正确的用户 ID。我后面在问题排查章节会专门展开。2.4 网络模型容器之间如何通信默认情况下每个容器有自己独立的网络栈外部访问它需要做端口映射。比如把宿主机的 8080 端口映射到容器的 3000 端口docker run -d -p 8080:3000 demo-app容器与容器之间通信最推荐的方式是创建一个自定义网络然后把多个容器放进去。自定义网络里Docker 内置 DNS 解析容器可以直接用服务名互相访问不需要关心 IP 地址变化。# 创建网络 docker network create app-net # 启动两个容器并加入同一网络 docker run -d --name app --network app-net demo-app docker run -d --name redis --network app-net redis:7-alpine在app容器里访问redis服务时直接连接redis:6379即可不需要写 IP。这一套机制在docker-compose里体现得更加明显后面的实操章节会直接用到。3. 实操复盘从零部署一个带数据库的 Web 服务3.1 先写一个需要连接外部服务的程序空谈概念没有意义我带着你从零到一跑一个完整项目。这次选一个小型 Web 服务用 Node.js 写对外提供两个接口依赖 Redis 和 MySQL。技术栈大家都很熟重点是容器化的思路。项目结构先搭出来demo-app ├── .dockerignore ├── Dockerfile ├── docker-compose.yml ├── package.json └── server.jspackage.json如下只引入最少依赖{ name: demo-app, version: 1.0.0, dependencies: { express: ^4.19.2, mysql2: ^3.9.7, redis: ^4.6.14 }, scripts: { start: node server.js } }server.js实现一个健康检查接口同时验证 Redis 和 MySQL 是否连通const express require(express); const redis require(redis); const mysql require(mysql2/promise); const app express(); const port 3000; const redisClient redis.createClient({ url: process.env.REDIS_URL || redis://localhost:6379, }); redisClient.connect(); const db mysql.createPool({ host: process.env.MYSQL_HOST || localhost, user: process.env.MYSQL_USER || root, password: process.env.MYSQL_PASSWORD || root, database: process.env.MYSQL_DATABASE || appdb, }); app.get(/, (req, res) { res.json({ message: demo app is running }); }); app.get(/health, async (req, res) { try { await redisClient.ping(); await db.query(SELECT 1); res.json({ status: ok }); } catch (err) { res.status(500).json({ status: error, detail: err.message }); } }); app.listen(port, () { console.log(demo app listening on ${port}); });这些环境变量都从外面传进来。这样做的好处是同一份代码在不同的环境里可以通过环境变量切换数据库地址镜像本身不需要重新构建。3.2 编写 Dockerfile 的注意点Dockerfile 是构建镜像的配方文件。下面是这个项目的 DockerfileFROM node:20-alpine WORKDIR /app COPY package.json package-lock.json* ./ RUN npm install --registryhttps://registry.npmjs.org COPY . . EXPOSE 3000 CMD [node, server.js]逐行说一下为什么这么写FROM node:20-alpine选择 Alpine 版基础镜像。Alpine 体积小比标准镜像小不少对部署和传输都很友好。WORKDIR /app设置容器里的工作目录。后续命令都在这个目录下执行避免文件乱放。COPY package.json package-lock.json* ./先只拷贝依赖清单文件。这是 Docker 分层缓存的核心技巧后续改代码时依赖安装层不会变化构建会直接复用缓存。RUN npm install在镜像构建时安装依赖。如果你用 npm 私服也可以把 registry 地址替换成私服地址。COPY . .把项目代码拷贝进去。注意前面必须配置.dockerignore否则本地的node_modules也会被拷贝进去污染镜像。EXPOSE 3000声明容器对外提供 3000 端口。这只是一种元信息真正发布端口还是要靠docker run -p。CMD [node, server.js]容器启动时执行的命令。需要注意它和RUN的区别RUN是构建阶段执行的CMD是运行阶段执行的。.dockerignore文件不能省node_modules npm-debug.log .git .gitignore Dockerfile docker-compose.yml这个文件的作用是让构建上下文里不包含无关文件。我在实际项目里见过不少人把整个项目目录塞进构建上下文镜像变得巨大构建也慢就是因为没写.dockerignore。3.3 用 docker-compose 编排整套服务前面只用单个容器现在要把应用、Redis、MySQL 三个服务一起跑起来。如果每条都用docker run去启动不仅命令长还得手动管理网络和依赖顺序非常容易出错。这时候用docker compose来做编排最合适。创建docker-compose.ymlservices: app: build: . ports: - 8080:3000 environment: REDIS_URL: redis://redis:6379 MYSQL_HOST: mysql MYSQL_USER: root MYSQL_PASSWORD: root MYSQL_DATABASE: appdb depends_on: redis: condition: service_healthy mysql: condition: service_healthy restart: unless-stopped redis: image: redis:7-alpine volumes: - redis-data:/data healthcheck: test: [CMD, redis-cli, ping] interval: 5s timeout: 3s retries: 5 mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: appdb volumes: - mysql-data:/var/lib/mysql healthcheck: test: [CMD-SHELL, mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD] interval: 5s timeout: 3s retries: 5 volumes: redis-data: mysql-data:这个编排文件里值得关注的几个点app服务没有指定image而是使用build: .表示用当前目录的 Dockerfile 构建。ports把宿主机的 8080 映射到容器内的 3000。environment注入环境变量应用代码里从process.env读取这一步就把前面代码里的坑补上了。depends_on配合condition: service_healthy确保 Redis 和 MySQL 真正就绪后应用才开始启动。不然应用启动时数据库还没准备好会出现一堆连接错误。两个数据库服务都挂了命名卷容器删掉重建数据还在。restart: unless-stopped让服务在意外退出时自动重启这是生产环境比较稳妥的策略。启动命令非常干净docker compose up -d查看运行状态docker compose ps查看日志docker compose logs -f app停止和清理docker compose down注意docker compose down默认不会删除命名卷。如果想把数据一起清理掉需要加-v参数但请一定慎重加了之后数据库里的数据会被清空没有后悔药。3.4 验证部署结果与日常操作整套服务起来之后可以直接验证# 查看所有服务状态 docker compose ps # 访问应用根路径 curl http://localhost:8080/ # 访问健康检查接口 curl http://localhost:8080/health如果一切正常/health接口会返回{status:ok}在开发调试过程中我常会用到的操作还有这些# 进入应用容器内部排查 docker compose exec app sh # 查看某个容器的资源占用 docker stats # 在宿主机直接访问容器内 Redis docker compose exec redis redis-cli ping这套组合命令基本覆盖了日常开发和线上排查百分之八九十的场景。4. 常见问题排查实录从报错到恢复4.1 端口映射不生效或访问被拒绝现象宿主机上访问http://localhost:8080报错但容器日志显示服务已经正常启动了。排查顺序先看容器有没有在运行docker ps。查看端口是否正确映射docker port app。查看容器日志docker compose logs app。在宿主机上监听端口状态ss -lntp | grep 8080。一个常见原因是端口冲突。8080 已经被另一个进程占用Docker 会映射失败但不同版本的 Docker 行为不一样有的会直接启动失败有的会报端口占用错误。解决办法是换一个宿主机端口比如改成8081:3000。还有一种情况是容器监听了127.0.0.1导致外部访问不通。如果程序里监听的地址是localhost或127.0.0.1容器外部就访问不到。记得把监听地址设为0.0.0.0。4.2 容器一重启数据就没了现象重启容器后数据库的数据或者上传的文件全部消失退回初始状态。原因数据写在了容器的可写层没有挂载数据卷。容器重建后可写层被丢弃数据自然就没了。解决办法按前面 3.3 节的写法给所有需要持久化的路径挂载命名卷或绑定挂载。MySQL 挂/var/lib/mysqlRedis 挂/data这是各自镜像文档约定好的数据目录不能随意挂。注意不要只依赖docker commit来“保存数据”这是一种很不优雅的备份方式维护成本极高。4.3 构建镜像非常慢或者缓存总是失效现象每次改一行代码重新构建时都要重新安装依赖耗时很久。原因Dockerfile 里的COPY顺序不合理。如果把COPY . .写在RUN npm install之前那么任何代码改动都会让“拷贝代码”这一层缓存失效后面的依赖安装层也只能重新执行。正确顺序先拷贝依赖清单文件再安装依赖最后拷贝源码。这样源码变动不会影响依赖缓存。COPY package.json package-lock.json* ./ RUN npm install COPY . .另外启用 BuildKit 后缓存策略会有更多选项比如RUN --mounttypecache可以缓存包管理器下载的临时文件让镜像内层缓存更高效。4.4 容器内权限不足或数据目录无法写入现象启动 MySQL 或者其他服务时日志里出现Permission denied或者挂载目录里文件自动变成 root 所有程序运行报错。原因镜像内的服务进程以特定用户运行而宿主机挂载进来的目录权限和该用户不匹配。Docker 的-v挂载不会自动调整权限特别是绑定挂载时最容易遇到。解决办法指定容器以宿主机当前用户运行docker run --user $(id -u):$(id -g) ...。调整宿主机目录属主chown -R 1000:1000 ./data。在镜像里预创建目录并调整权限。RUN mkdir -p /data chown -R node:node /data USER node4.5 应用日志无限增长磁盘被打满现象运行一段时间后系统磁盘空间告警定位发现是容器日志文件占用大量空间。原因容器内的标准输出默认会被 Docker 记录到本地的 json 文件里如果应用日志比较多且没有设置轮转策略文件会一直膨胀。解决办法在 Docker 守护进程配置里统一设置日志轮转或者在 compose 文件里设置services: app: logging: driver: json-file options: max-size: 10m max-file: 5这样单个日志文件超过 10MB 后会自动切割最多保留 5 份不会再无限占盘。常见问题可以先记成这样一张速查表问题可能原因快速排查推荐处理端口访问失败端口冲突、程序绑定地址不对docker ps、docker port换端口、绑定0.0.0.0数据丢失未挂载数据卷docker inspect看 Mounts挂载命名卷构建慢依赖层缓存失效观察构建日志每层耗时调整 COPY 顺序权限不足挂载目录属主不匹配ls -l查看宿主机目录属性--user参数或调整目录权限磁盘暴涨日志无轮转策略du -h /var/lib/docker/containers/*/*.log配置 log rotation5. 除了踩坑日常使用中值得坚持的一些习惯5.1 基础镜像选择要克制选基础镜像时优先考虑 Alpine 版本或官方提供的 slim 版本体积小、攻击面小。但也要注意Alpine 使用 musl 而不是 glibc有些二进制依赖可能不兼容。如果遇到诡异的运行时错误可以先怀疑基础镜像换回debian:stable-slim试试。固定镜像标签也很重要。FROM node:20这个写法虽然方便但node:20标签会随着时间更新今天构建和三个月后构建可能拿到不同内容。对于生产发布建议把标签精确到小版本比如node:20.14.0-alpine或者使用镜像摘要digest保证完全一致。5.2 给容器加上健康检查健康检查不是锦上添花而是多服务协作时的必要条件。前面 3.3 节的 compose 文件里已经写了healthcheck它的意义在于让编排工具知道容器是否真正可用而不是只看进程还在不在。比如 Redis 容器启动了但可能还在加载持久化数据此时访问会失败。有了健康检查依赖它的应用容器就不会过早启动。在没有 compose 的单容器场景下也可以直接在docker run参数里加docker run -d \ --name redis \ --health-cmdredis-cli ping \ --health-interval5s \ --health-retries5 \ redis:7-alpine5.3 限制容器资源避免“一个容器吃整台机器”生产环境一定要给容器设置资源上限。不加限制的话一个出现内存泄漏的容器可能把宿主机内存耗尽导致同机器上的其他服务全部受影响。docker run -d --name app \ --memory512m \ --cpus0.5 \ my-app-image在 compose 里对应的写法是services: app: deploy: resources: limits: cpus: 0.5 memory: 512M对于 Java 这类有堆内存配置的程序还要注意把 JVM 的堆参数设置好避免容器限制和 JVM 感知的内存不一致。5.4 把镜像当普通包来管理不要依赖容器内部修改我在项目组里一再强调一切对容器的修改都应该通过重新构建镜像来解决。进入容器里apt-get install、手动改配置文件、手工复制二进制文件这些操作虽然在当下能解决问题但容器一重建就会全部丢失。更关键的是如果这台容器承载线上流量手工改动会让机器漂移出标准状态以后排查问题都无从下手。如果有临时调试需求比如在容器里看网络连通性、查端口可以使用docker exec进入容器但不要在里面做持久性修改。调试完直接退出需要什么能力就在 Dockerfile 里加。5.5 镜像体积压缩与安全扫描构建体积太大的时候除了换小基础镜像还可以用多阶段构建。以前端项目为例第一阶段用完整 Node 镜像安装依赖并构建静态文件第二阶段用 Nginx 镜像只拷贝构建产物最终镜像里不包含任何源代码和构建工具既小又安全。镜像构建完成后有条件的话可以引入安全扫描比如用开源的扫描工具检查依赖漏洞。我们平时的习惯是把构建和扫描一起接入 CI 流程镜像有问题时直接阻断发布而不是上线后再补救。这套流程跑顺之后你会发现部署一个新环境的时间从小时级降到分钟级交付的东西也变成标准的、可复现的镜像。如果让我只留一个建议那就是从今天开始每个项目都坚持写一份合适的 Dckerfile 和 compose 编排别图省事去手工折腾环境。这个动作节省的时间会远超你最初学习容器化的成本。