如果你刚从“在本机怎么都跑不起来在同事电脑上却一切正常”的噩梦中醒来如果你刚入职一家公司光搭开发环境就花掉整整两天或者你正被“明明测试环境没问题一上生产就崩”这种经典剧情反复折磨那么这篇文章是为你准备的。先说判断Docker 并不是什么新潮的“容器技术”名词它是当前软件开发流程中解决“环境一致性”和“项目交付”最直接的工程手段。很多人把它学成了命令大全背了一堆 docker run 参数到了真正要“把一个项目打包好交给别人运行”的时候依然无从下手。这是因为没有抓住 Docker 最核心的两层抽象镜像images和容器container。这篇文章不会停留在概念罗列我会从实际开发者的视角把 Docker 的安装、镜像管理、容器生命周期、Dockerfile 编写、数据卷挂载以及“把一个完整项目环境打包给别人用”这条主线完整走一遍。你可以跟着操作也可以在遇到具体问题时回来查对应章节。读完你至少能解决三个问题第一搞清镜像和容器到底是什么关系第二能独立完成镜像的拉取、构建和容器运行第三能把自己写的项目连同运行环境一起打包分发给同事或部署到服务器。1. Docker 真正解决的问题是什么在接触 Docker 之前很多团队是这样部署项目的新同事入职按文档一步步装 JDK、装 MySQL、装 Redis、配环境变量、调配置文件。开发完成后把 jar 包或 war 包发给运维运维在服务器上再走一遍“装环境”流程。某个依赖库升级了测试环境升了生产环境没升结果行为不一致。一台服务器上想同时跑两个不同版本的 MySQL装上就冲突。这些问题的根源不是某个人的操作失误而是软件运行环境和代码本身没有打包在一起。代码是代码环境是环境中间靠“人工部署”这条脆弱链条连接。Docker 解决这个问题的思路很朴素把代码和运行环境一起打包成一个可以分发和运行的“包裹”这个包裹就是镜像。别人拿到这个镜像不需要再关心环境怎么配直接运行起来就是一致的。同一个镜像无论跑在开发笔记本、测试服务器还是生产机器上内部看到的操作系统依赖、库文件、环境变量完全一致。从工程角度看Docker 真正改变的是协作边界。以前开发说“我这边是好的”运维说“我这边起不来”两边互相拉扯。现在开发负责把镜像构建好运维负责把镜像跑起来双方基于同一个镜像进行协作扯皮空间被大幅压缩。就算出了问题问题也出在镜像构建或运行配置上能够准确定位和回溯而不是“环境玄学”。需要说明的是Docker 不等于虚拟机。虚拟机是把整个操作系统虚拟化重量级、启动慢、资源占用高容器则是共享宿主机内核只隔离进程、文件系统、网络等资源启动速度和资源占用都轻量得多。这也是很多人第一次用 Docker 时感到“快得离谱”的原因。对个人开发者来说Docker 更像一台“万能环境恢复机”。你不需要在电脑上安装各种版本冲突的软件需要 MySQL 就拉一个 MySQL 镜像用完删掉也不污染系统。需要测试某个开源项目跑一个容器就行不用担心卸载不干净。2. Docker 镜像与容器的核心概念要真正理解 Docker 的使用必须先建立两个核心概念。2.1 镜像Image是模板容器Container是运行实例镜像是一个只读的模板文件里面包含了运行某个应用所需要的完整操作系统文件系统、代码、依赖库、环境变量、默认命令等。你可以把它理解成一个“装箱清单 完整快照”它本身不运行只负责定义容器应该长什么样。容器是镜像运行起来后产生的进程实例。同一个镜像可以同时启动多个容器每个容器之间相互隔离运行状态彼此独立。容器可以被启动、停止、删除也可以在里面执行命令、写入文件。容器的写入层是临时的一旦容器被删除容器内产生的数据默认也会丢失这个特性后面操作数据卷时会重点讲。理解二者的关系最常用的一个类比是镜像 类Class容器 对象Instance镜像 安装光盘容器 安装完成后运行起来的系统镜像 菜谱容器 按这个菜谱做出的菜其中“菜谱”这个类比很贴切。菜谱是静态的文本你可以反复用同一份菜谱做很多盘菜每盘菜都是独立的吃完或者倒掉不影响菜谱本身。如果菜谱里某一步写错了你只能修改菜谱后重新做菜已经做好的菜不会自动变好。对应到 Docker 里就是容器运行后如果在里面安装了额外软件或修改了文件这些修改默认只停留在容器层不会写回镜像要永久修改必须通过 Dockerfile 重新构建镜像。2.2 镜像分层结构与联合文件系统镜像还有一个不能忽略的特性分层存储。Docker 镜像由多个只读层组成每一层代表 Dockerfile 中的一条指令。构建镜像时如果基础镜像层没有变化Docker 会直接复用缓存这也是为什么很多项目构建第二次时速度会快很多。层的好处是节约磁盘空间和网络带宽。你拉取一个新镜像时如果它的某些层本地已经存在Docker 只需下载不在本地的那部分层。多个镜像可以共享相同的底层基础镜像层这对本地磁盘占用和私有镜像仓库的带宽优化非常有意义。但要提醒新手的是分层结构也带来一个常见坑每一层都会固化当时的文件状态。如果有人把包含密码的文件写进镜像的某一层即使后面的层把它删了它仍然存在于更底层的镜像历史中通过 docker history 可以翻出来。所以管理和制作镜像时不要把密钥、密码、token 写进去这是一个必须从第一天就养成的安全意识。2.3 镜像仓库Registry镜像建好后需要分发的载体叫镜像仓库。Docker Hub 是官方公共仓库里面放着大量官方维护的镜像比如 mysql、nginx、redis、ubuntu、python 等绝大多数情况下不用自己从零搭建环境直接基于官方镜像稍作修改即可。实际公司内部也经常会搭建私有镜像仓库用于存放内部应用镜像避免直接依赖外网拉取。后面写实战时会演示如何把一个自建镜像打上标签并推送。3. Docker 安装与环境准备不同操作系统安装 Docker 的方式不同这里不写死某个版本的安装包因为 Docker 迭代较快安装方式也会更新。关键在于理解你装的到底是哪一类 Docker 环境。3.1 Linux 环境在 Linux 服务器上Docker 以守护进程方式运行安装后通过 systemctl 管理。绝大多数云服务器和公司测试机都是这种方式。安装步骤一般是# 1. 安装依赖 sudo apt-get update sudo apt-get install -y ca-certificates curl # 2. 添加 Docker 官方 GPG 密钥和仓库以 Debian/Ubuntu 系为例 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg # 3. 写入软件源 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 4. 安装 Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 5. 验证 sudo docker run hello-world安装成功后可以使用 docker version 查看客户端和服务端版本信息。如果显示服务端和客户端都有版本号说明 Docker 守护进程已经在运行。如果只显示客户端而服务端报错多半是守护进程没启动先检查 systemctl status docker 再启动它。sudo systemctl start docker sudo systemctl enable docker这里有一个实际开发中常见的操作建议尽量不要让普通用户直接执行 docker 命令时需要 sudo 或者在“是否把用户加入 docker 用户组”之间反复纠结。把用户加入 docker 组确实可以免 sudo 执行 docker 命令但 Docker 的权限边界很特殊凡是能执行 docker 命令的用户本质上就等同于有了宿主机的 root 权限。不要为了图方便在共用服务器上给所有人开放 docker 权限安全边界比便利更重要。个人开发机可以正常操作生产服务器请务必做好用户和权限规划。3.2 Windows 与 macOS 环境Windows 上过去常被提及的 Docker Toolbox 和基于 Hyper-V 的方案已经逐渐淡出目前主流是安装 Docker Desktop。Docker Desktop 在 Windows 上依赖 WSL 2 或 Hyper-V在 macOS 上依赖 HyperKit 或 Apple Virtualization Framework。安装 Docker Desktop 后它会提供一个图形化界面你可以在上面直接管理容器、查看日志、打开终端、查看镜像。Docker Desktop 内置了 docker CLI安装完成后在 PowerShell 或终端中直接敲 docker 即可。需要特别提醒的是Windows 下要检查 Docker Desktop 是否正常运行右下角托盘里的鲸鱼图标是否常亮。刚启动时 Docker Desktop 需要一个启动时间如果立即执行 docker ps 会报“Cannot connect to the Docker daemon”这是正常的等图标稳定后再操作。WSL 2 模式下你还可以在 Windows 和 Linux 发行版之间共用 Docker 命令具体取决于你终端所在的上下文。从我个人经验来看新手不要一上来就在 Windows 上折腾原生安装先装好 Docker Desktop能让你把精力集中在理解镜像和容器本身而不是跟 Docker 的环境依赖搏斗。3.3 验证安装无论哪个平台安装完成后跑一次 hello-world 是最稳的验证方式docker run hello-world如果能正常输出一段 Hello from Docker! 的提示说明整个链路已经通了。这个命令背后发生的事情是Docker 发现在本地没有 hello-world 镜像于是自动从 Docker Hub 拉取镜像然后创建并运行容器容器打印信息后退出了。4. Docker 镜像的基础操作安装完成只是第一步。接下来我们把命令分成两个层次先掌握镜像操作再掌握容器操作最后串起来做项目打包。很多人学 Docker 的失败经验就是镜像命令和容器命令混在一起记最后完全不知道当前在操作哪个对象。4.1 搜索镜像在不确认镜像是否存在以及有哪些版本时可以直接在远程仓库搜索docker search nginx搜索结果会列出镜像名称、描述、星数、是否官方。星数是参考项但不是绝对权威有些第三方镜像虽然星数很高维护情况和安全性并不一定可靠。生产环境尽量选择官方镜像或可信组织维护的镜像。更准确的做法是直接到 Docker Hub 网站上查看镜像的 tag版本标签。因为 docker search 不会列出具体版本号只有知道具体 tag 才能精准拉取。4.2 拉取镜像拉取镜像的基本命令docker pull nginx:latest其中nginx是镜像名latest是标签。如果不写 tag默认拉取 latest。这里从工程角度给一个建议尽量不要依赖 latest 标签。latest 指向的版本会随时间变化今天拉的是一个版本三个月后再拉可能就是另一个大版本这会给环境复现带来不确定性。更稳妥的做法是指定明确版本例如固定使用某个常用稳定版本后面需要升级再明确调整。如果你不清楚镜像有哪些版本可以在 Docker Hub 的 Tags 页面查看也可以通过docker image inspect查看已拉取镜像的详细信息。关于国内网络环境下镜像拉取慢的问题需要说明一点不同网络环境下的镜像加速方案差异很大具体加速地址和配置方式时效性也很强这里不写死任何加速地址。如果你在拉取镜像时很慢一个更通用的建议是先确认基础镜像尽量选择体积小的变体或者在公司里配置私有镜像仓库作为中转或者考虑使用更大带宽的网络环境拉取后通过镜像导出再内网导入。不要盲目相信网上流传的加速地址很多已经失效。4.3 查看本地镜像docker images输出包含 REPOSITORY、TAG、IMAGE ID、CREATED、SIZE 几列。IMAGE ID 是镜像的唯一标识操作镜像时可以直接用 IMAGE ID 的前几位作为简写。SIZE 列反映的是镜像的软件包体积不代表实际解压后的磁盘占用。如果想看某个镜像更完整的信息包括环境变量、端口暴露、挂载点、架构等可以使用docker inspect nginx输出是 JSON 格式内容很详细。新手可能不适应这种大段 JSON但排查问题时 inspect 是很有用的工具比如你想知道镜像默认暴露了哪些端口、入口命令是什么都可以在这里找到。4.4 删除镜像docker rmi nginx:latest如果镜像已经被某个容器使用需要先删除相关容器再删除镜像否则会报错。这里的逻辑和操作系统中“文件正被占用无法删除”类似。强制删除可以用 -f 参数但生产环境不建议默认使用先理清关联关系再操作更安全。4.5 镜像导入导出在没有私有镜像仓库又需要把镜像从一台机器搬到另一台机器时可以用导出导入# 导出镜像为 tar 文件 docker save -o nginx.tar nginx:latest # 导入镜像 docker load -i nginx.tar还有一种 dump 容器文件系统的方式是docker export它导出的内容和docker save不一样。save 保存的是镜像的分层结构可以重新加载为镜像export 导出的是容器的文件系统快照导入后不再是完整镜像通常没有镜像的元数据、分层和历史信息。实际项目打包时优先用 save 和 load。4.6 镜像操作小结到这里镜像这条线的操作闭环已经通了搜索、拉取、查看、删除、导出、导入。你可能已经发现这些操作和包管理工具的思路很像比如 Python 里的 pip、Node 里的 npm只是镜像管理的粒度更重携带的是完整运行环境。5. Docker 容器的生命周期操作镜像只是“原材料”真正运行起来产生项目效果的是容器。这一节我们完整走一遍容器的创建、启动、停止、进入、删除。5.1 从镜像创建并运行容器先看最常见的命令docker run -d --name my-nginx -p 8080:80 nginx:latest把这个命令拆开解释docker run从镜像创建并运行一个新容器。-d后台运行容器终端不阻塞不写这个参数时容器会在前台运行直接霸占当前终端。--name my-nginx给容器命名。不命名的话 Docker 会随机生成一个名字不便于管理。-p 8080:80端口映射。左边是宿主机端口右边是容器内端口。这里把宿主机 8080 端口映射到容器内 nginx 的 80 端口。nginx:latest指定镜像。运行后在浏览器访问http://localhost:8080能看到 nginx 的欢迎页面。这里需要理解一个关键概念容器是一个隔离的沙箱容器内的端口默认不会被宿主机直接访问到必须通过 -p 映射出来才能从外部访问。很多人刚学 Docker 时疑惑“为什么我运行了 MySQL 容器但程序连不上 MySQL”多半就是没有做端口映射或者映射错方向了。5.2 查看容器列表# 查看运行中的容器 docker ps # 查看所有容器包括已经停止的 docker ps -a容器状态里通常会有 Up、Exited、Restarting 等状态。Up 表示正在运行Exited 表示容器已退出。如果容器启动不到两秒就退出多半是容器内的主进程退出了这个问题后面排查时还要提到。5.3 启动、停止、重启、删除容器# 停止容器 docker stop my-nginx # 启动已停止的容器 docker start my-nginx # 重启容器 docker restart my-nginx # 强制停止 docker kill my-nginx # 删除容器只能删除已停止的容器 docker rm my-nginx # 强制删除正在运行的容器 docker rm -f my-nginx这里的重点在于理解 start 和 run 的区别。docker run每次都会创建一个新容器docker start是启动一个已经存在的、处于停止状态的容器。如果你反复用 docker run 同一个镜像会产生多个容器实例名字冲突时会报错。实际项目操作中经常有新手用 docker run -d 启动容器发现端口冲突于是又改端口重新 run 一次结果机器上残留了一堆容器。正确做法是先 docker ps -a 看看到底有哪些容器再决定 stop、rm 还是重新 run。5.4 进入容器内部执行命令排查问题或查看容器内部文件时经常需要进入容器# 在运行中的容器内执行一条命令 docker exec my-nginx ls /etc/nginx # 以交互模式进入容器并打开 bash 终端 docker exec -it my-nginx bash-i表示保持标准输入打开-t表示分配一个伪终端。两者配合才能得到一个可以交互操作的 bash 终端。如果容器内部没有 bash极简镜像可能只有 sh可以尝试docker exec -it my-nginx sh进入容器后可以查看日志文件、检查进程、验证配置等。要注意的是你在容器内做的修改只对当前容器有效不会影响镜像也不会影响由同一镜像创建的其他容器。如果你希望修改后重新生成一个新容器也能保留效果正确的做法是改 Dockerfile 重新构建镜像或者用数据卷挂载外部文件。5.5 查看容器日志项目部署后第一件事往往就是看日志# 查看全部日志 docker logs my-nginx # 实时跟踪日志输出类似 tail -f docker logs -f my-nginx # 查看最后 100 行 docker logs --tail 100 my-nginx如果容器启动后立即退出docker logs 是最有效的排查手段。比如你发现自己写的一个应用容器运行后立刻 Exited运行 docker logs 容器名看到的具体报错信息就是下一步排查的依据。5.6 容器文件拷贝需要从容器里拷贝文件到宿主机或者往容器里拷文件时# 从容器拷贝文件到宿主机 docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf # 从宿主机拷贝文件到容器 docker cp ./nginx.conf my-nginx:/etc/nginx/nginx.confdocker cp 适合临时操作不适合作为常规配置管理手段。因为容器一旦被删除重建之前往容器里拷贝的内容会全部消失。6. 项目环境打包实战从 Dockerfile 到可分发镜像前面几节你可以理解为准备工作这一节进入主线目标把手里的项目连同一个完整运行环境打包成镜像让别人一条命令就能跑起来。这里以最常见的 Java Spring Boot 项目为例也可以换成一个 Node 项目或 Python 项目核心思路是一样的先选择一个合适的基础镜像再把项目文件放进去最后声明启动命令。6.1 编写 DockerfileDockerfile 是描述镜像构建过程的文本文件Docker 会按文件里的指令逐行构建镜像。下面是一个 Spring Boot 项目的 Dockerfile 示例# 文件路径项目根目录/Dockerfile # 第一阶段使用 Maven 镜像构建项目 FROM maven:3.8-openjdk-11 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests # 第二阶段使用精简 JRE 镜像运行项目 FROM openjdk:11-jre-slim WORKDIR /app COPY --frombuilder /app/target/demo-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]这里使用了多阶段构建作用是第一阶段用大而全的 Maven 镜像编译项目第二阶段只把编译好的 jar 包放进精简运行镜像。这样做的好处是最终镜像体积小很多不包含编译工具链攻击面也更小。如果不使用多阶段构建直接把源码、Maven 和运行时都塞进一个镜像镜像体积会非常庞大。从实际经验看一个精简的多阶段 Spring Boot 镜像可能只有一两百兆而带完整 Maven JDK 的镜像可能达到几百兆甚至更大。对部署带宽和存储成本都有影响。Dockerfile 里几个关键指令的含义FROM指定基础镜像。所有镜像都必须有基础镜像可以是官方镜像也可以是自建镜像。WORKDIR设置工作目录。后续命令默认在这个目录下执行。COPY把文件从宿主机复制到镜像内。RUN在构建阶段执行命令常用于安装依赖、编译项目等。EXPOSE声明容器运行时监听的端口。它更像文档说明真正暴露端口仍要靠运行容器时的 -p 参数。ENTRYPOINT定义容器启动时执行的命令。如果是一个 Python Flask 项目Dockerfile 类似这样FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD [python, app.py]如果是 Node.js 项目FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD [npm, start]无论哪种技术栈背后的逻辑都是装依赖、放代码、写启动命令。6.2 构建镜像在 Dockerfile 所在目录执行docker build -t my-demo:1.0 .-t my-demo:1.0给镜像命名并打标签。镜像名通常是小写字母建议包含项目含义标签按版本号管理。最后的.构建上下文路径。Docker 会把当前目录下的文件作为构建上下文发送给 Docker 守护进程Dockerfile 里的 COPY 指令会从这个上下文中找文件。有一点很重要.dockerignore文件。它和 .gitignore 类似声明哪些文件不要发送给 Docker 构建上下文比如本地 target 目录、node_modules、.git 等。不写 .dockerignore 的话构建上下文会变得非常大构建速度也会明显变慢。示例 .dockerignoretarget/ node_modules/ .git/ .idea/ *.log6.3 运行自建镜像docker run -d --name my-demo-app -p 8080:8080 my-demo:1.0运行后访问http://localhost:8080检查项目是否启动成功。6.4 分发镜像的常用方式自建镜像要在团队内部分发通常有三种做法推送到镜像仓库这是最正规的方式。先给镜像打上仓库地址和命名空间docker tag my-demo:1.0 registry.example.com/team01/my-demo:1.0 docker push registry.example.com/team01/my-demo:1.0其他同事在自己的机器上执行 docker pull registry.example.com/team01/my-demo:1.0 即可获取镜像。公司内部一般会搭建私有镜像仓库避免依赖外网且方便权限控制。如果你使用云服务商提供的镜像仓库操作流程也是类似先登录再推送。导出镜像文件在没有仓库的情况下用前面讲过的 docker save 导出成 tar 文件拷贝给目标机器再 docker load 导入。这种方式适合小范围交付但文件较大时不方便传输而且缺少集中管理能力。通过 Docker Compose 编排多容器项目如果项目不止一个容器比如一个应用要同时依赖 MySQL 和 Redis用 docker run 两条三条命令去启动会非常零散。这时可以使用 docker-compose.yml 定义整个环境的服务列表、网络、依赖关系、数据卷然后一条命令启动全部服务。这是实际项目中最接近“项目环境打包”的完整形态因为环境不只是一个镜像而是多个组件协同运行。一个示例 docker-compose.ymlversion: 3.8 services: app: build: . ports: - 8080:8080 environment: SPRING_DATASOURCE_URL: jdbc:mysql://db:3306/demo?useUnicodetruecharacterEncodingutf8 SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: root123 depends_on: - db db: image: mysql:8.0 restart: always environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: demo ports: - 3306:3306 volumes: - db_data:/var/lib/mysql volumes: db_data:这里要强调一个安全规范这是为了演示服务间连通性而展示的配置实际项目中绝对不要把数据库密码硬编码在 docker-compose.yml 文件里尤其是不能提交到代码仓库。生产环境推荐使用环境变量注入、Docker 密钥管理或者配置中心等专门机制管理敏感信息。在这个编排文件中app 服务的数据库地址写成 db而不是 localhost是因为 Compose 会为服务创建一个默认网络服务之间通过服务名互相解析。当 app 容器访问 db 这个主机名时实际上访问的是 db 服务对应的容器。如果你写成 localhost应用会尝试连接 app 容器自己的 3306 端口而那里并没有 MySQL这个报错是新手最容易遇到的问题之一。在 docker-compose.yml 所在目录执行# 构建并启动 docker-compose up -d # 查看服务状态 docker-compose ps # 查看日志 docker-compose logs -f app # 停止并移除容器保留数据卷 docker-compose down # 停止并移除容器、网络、数据卷慎用会删数据 docker-compose down -v如果你使用的是新版 Docker 插件版 Compose命令可能是docker compose中间没有横线执行方式基本一致。7. 数据卷让容器里的数据“活”起来前面反复提到一个让人不安的问题容器删了就什么都没了。对无状态应用来说这不是问题但数据库、上传文件、日志等场景必须把数据持久化保存。Docker 的解决方案是数据卷Volume。# 创建一个数据卷 docker volume create mydata # 挂载数据卷运行容器 docker run -d --name mysql-demo \ -v mydata:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDroot123 \ mysql:8.0-v mydata:/var/lib/mysql表示把名为 mydata 的数据卷挂载到容器内的 /var/lib/mysql 目录。这样 MySQL 写入的数据实际上保存在宿主机的数据卷中即使删除容器数据卷还在重新用同一数据卷启动新容器数据就回来了。除了命名数据卷还可以直接挂载宿主机目录这在开发调试时很常用# 把宿主机当前目录下的 nginx.conf 挂载到容器内 docker run -d --name my-nginx -p 8080:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro nginx:latest:ro表示只读挂载避免容器内修改宿主机文件。开发场景下可以直接把本地代码目录挂载进容器改代码后服务自动加载不用重新构建镜像这也是很多前端 Node 容器开发方案的核心思路。关于数据卷需要掌握两个判断什么时候该用数据卷有状态服务数据库、消息队列一定要用应用产生需要保留的文件上传文件、日志一定要用其他无状态服务可以不挂载。数据卷会不会泄露数据卷里的数据独立于容器生命周期。用 docker-compose down -v 或 docker volume rm 会删掉数据执行前必须确认备份。还要补充一个容器文件系统写入层和挂载卷的区别容器内未挂载卷的路径修改都发生在可写容器层容器删除即丢失挂载卷的路径直接对应宿主机路径删除容器不丢数据。判断一个容器是否有数据丢失风险第一看它是否有状态第二看状态写在哪个路径。8. 常见问题与排查思路以下问题是我在实际使用和帮助同事排查时遇到比较多的场景按出现频率排列。问题现象可能原因排查方式解决方案执行 docker 命令报 Cannot connect to the Docker daemonDocker 守护进程未启动systemctl status docker 或查看 Docker Desktop 图标状态启动守护进程或 Docker Desktop拉取镜像超时或非常慢网络环境限制、镜像源问题查看拉取时的错误信息配置镜像加速、使用公司镜像仓库、换网络环境容器启动后立即退出Exited容器内主进程启动失败或直接结束docker logs 容器名根据日志修复应用配置、依赖、启动命令端口无法访问端口映射错误或容器未运行docker ps 看端口映射宿主机制试防火墙检查 -p 参数方向开放宿主机防火墙端口容器之间无法互通未加入同一网络或主机名写错docker inspect 查看网络配置使用 docker network 创建网络服务名访问端口被占用宿主机的端口已被其他进程或容器占用docker ps 或 lsof -i:端口停掉冲突进程或修改 -p 映射端口删除镜像报错 image is being used by container镜像仍被容器引用docker ps -a 找到对应容器删除或停止对应容器后再删除镜像重点讲两个最容易卡住新手的场景。第一个是容器秒退。很多新手用 docker run 启动一个自己写的应用镜像发现 docker ps 看不到容器以为没启动成功。实际上容器启动后如果容器内主进程正常执行并退出容器状态就变成 Exited。这种情况要区分“异常退出”和“任务完成”——比如跑一个打印日志就结束的脚本容器自然退出是正常的但启动一个 web 服务却秒退就需要用 docker logs 查看日志找启动失败原因。判断方法如果你的应用应该常驻运行但容器秒退大概率是应用启动异常。第二个是容器之间访问 localhost 的误区。在 docker-compose 里app 容器内访问数据库不能用 localhost因为 localhost 指向的是 app 容器自己。必须用服务名 db。如果不用 Compose只用 docker run 启动多个容器它们默认不在同一网络需要通过 docker network create 自定义网络并让容器加入这个网络才能用容器名互相访问。任何时候遇到“容器内连不上另一个容器”第一反应应该是检查网络连接和主机名而不是怀疑数据库配置错了。9. 最佳实践与工程建议到这里Docker 的主线操作已经全部走通。下面是一些在实际项目和团队协作中验证过有效的经验建议收藏后在真实项目中逐步实践。第一镜像构建要追求“可重复”。Dockerfile 里的基础镜像标签不要用 latest写明确版本依赖锁定文件要提交到仓库比如 Java 项目 lock 住 pom.xml 或 gradle 版本Node 项目锁定 package-lock.jsonCold 构建缓存虽然能提速但要保证不依赖缓存时也能完整构建出同一结果。第二运行容器要遵循最小权限。不要默认用 root 用户跑应用容器。Dockerfile 中可以通过创建专用用户来降低逃逸风险FROM openjdk:11-jre-slim RUN groupadd -r app useradd -r -g app app WORKDIR /app COPY --frombuilder /app/target/demo-0.0.1-SNAPSHOT.jar app.jar USER app EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]容器内以普通用户运行的好处是即使容器被攻破攻击者获得的权限也受限于容器内普通用户而不是 root。这个方法在基线安全和生产环境部署要求中非常常见。第三配置和密钥不进镜像。镜像会被分发到不同环境甚至不同团队一旦包含密钥就相当于把密码公开。正确做法是通过环境变量、配置文件挂载、密钥管理服务等方式在运行时注入。判断一个值该不该写进镜像的标准是如果这个值在不同环境开发、测试、生产中不一样就不该写在镜像里。第四日志要输出到标准输出。Docker 容器里不要用文件方式写日志而是输出到 stdout/stderr由 Docker 日志机制统一收集。这样可以使用 docker logs 查看接入日志采集系统也会方便很多。如果应用框架默认写文件需要配置成输出到控制台。第五容器是无状态的。尽量把应用做成无状态需要保存的数据放到数据卷或外部存储。这样容器可以随时删除重建可以水平扩容。如果某个容器还需要小心翼翼地保存它的“现场”说明架构上可能还有优化空间。第六镜像体积需要控制。基础镜像优先选择 slim、alpine 等变体多阶段构建只保留运行产物及时清理构建缓存的中间镜像和不再使用的悬空镜像。镜像越小拉取越快部署越快暴露的攻击面也越小。第七给镜像和容器一个清晰的命名规范。镜像名建议格式为 项目名:版本号 或 仓库地址/项目名:版本号容器名用简短且包含项目含义的单词不要用 docker run 后随机生成的怪异名字用于正式环境。规范命名能避免团队协作时和运维确认问题说不清楚操作对象。第八生产环境不要使用 docker-compose 作为唯一交付方案。Compose 非常适合开发环境和测试环境以及单机多容器的简单场景。但到生产环境需要有更完善的容器编排方案比如 Kubernetes 一类平台来管理容器数量、健康检查、滚动升级、配置管理、存储、服务发现等能力。Docker 是底座生产落地还需要往前再走一步。10. 写在最后回到最初的问题为什么项目环境打包这个事值得每个人认真掌握 Docker因为环境一致性不是靠口头约定保证的而是靠把运行环境固化进镜像保证的。镜像一旦构建完成它在任何一台装有 Docker 的机器上表现都一致。这种“一次构建到处运行”的确定性是 Docker 对开发、测试、运维协作最大的价值。如果你是从零开始的新手建议你按下面这个顺序做一次完整练习安装 Docker跑通 hello-world。拉取一个官方 nginx 镜像用 -p 做端口映射浏览器访问成功。修改宿主机上的一个静态页面用数据卷挂载进容器让 nginx 提供新页面的内容。选一个你正在写的小项目编写 Dockerfile 构建镜像。用 docker-compose 把一个应用和一个数据库组合起来实现全栈启动。把镜像打标签、导出、在另一台机器上导入运行感受一下“环境打包分发”带来的交付体验。这个练习覆盖了镜像、容器、数据卷、构建、编排、分发是你后续学习 K8s、CI/CD、云原生概念的基础。Docker 的命令在熟练后会形成肌肉记忆但真正有价值的不是记住命令而是理解镜像和容器的边界、数据如何持久化、服务如何网络互通以及如何构建出可分发、可复现、安全可控的项目环境交付物。如果你的项目里还没有引入 Docker现在就可以从最小场景开始把你本地的数据库换成容器来跑感受一下“用完即走、不污染系统”的干净再把一个项目用 Dockerfile 构建成镜像发给同事试运行。这条路走通之后你会回来收藏这篇文章的。以上是本次实战的完整内容。如果你在打包项目时遇到了具体报错建议先把 docker logs 和 docker inspect 的输出贴出来按上面的排查表逐项对照大多数问题都能定位到原因。建议收藏备用也欢迎在评论区留下你遇到的奇葩环境问题。