直接说结论Docker 不是又一个让人望而却步的运维工具它是现阶段解决“环境不一致”“部署流程混乱”最经济实用的方案。这篇文章适合刚接触 Docker、准备把它用到自己项目里的开发者也适合那些被“在我机器上能跑”折磨过的测试和运维朋友。我会从零开始把镜像、容器、仓库这三件套讲明白再带你把一个实际项目跑起来最后把最容易踩的坑全部摊开说清楚。1. Docker 到底解决了什么问题1.1 从一次“环境地狱”说起先讲个场景。某个周五下午A 同学在本地开发环境把功能调通了代码提交上去还特意在交付群里说“测试通过了”。隔了两天测试反馈说完全跑不起来报错是缺少某个依赖库。A 同学打开自己的终端敲了几条命令怎么都复现不出对方的报错。最后折腾了半天才发现测试机器上装的是另一个版本的基础运行库某些接口行为不一样应用就挂了一部分功能。这不是个例。传统部署流程中代码只是一个部分真正影响运行结果的还有操作系统版本、底层依赖库、运行时环境、配置文件、环境变量。这些东西在每台机器上都不完全相同差一个版本号都可能引发连锁反应。Docker 解决的就是这个核心问题把应用连同它需要的完整运行环境打包在一起像一个集装箱一样搬到哪里都能原样运行。1.2 镜像、容器、仓库三个词先混个脸熟刚接触 Docker 的时候有三个词绕不开镜像Image、容器Container、仓库Registry。镜像可以理解成一个“模板”或“快照”里面包含了运行某个应用所需的全部文件系统、依赖、配置、启动命令。它本身是静态的就像电脑里的一份压缩包。容器则是由镜像启动后的运行实例是真正跑起来的那一层。同一个镜像可以启动多个容器彼此相互隔离。好比同一份安装镜像装出多台虚拟机一样。仓库用来集中存储和分发镜像。Docker 官方有一个默认的镜像仓库服务称为 Docker Hub里面放着大量现成的公共镜像比如数据库、缓存、Web 服务器等。日常使用中我们大多数时候是先“拉取”别人做好的镜像再启动容器很少需要从头构建。提示初学者最大的误区是把“镜像”和“容器”当成一回事。简单记成镜像负责“定义”容器负责“运行”。后续所有操作都围绕这条主线展开。1.3 Docker 和虚拟机的关键差异很多人会有疑问这不就跟虚拟机一样吗为什么不用 VMware 或者 VirtualBox虚拟机是完整的硬件虚拟化里面跑一套完整的操作系统内核对资源的开销比较大启动也要几十秒到几分钟。Docker 容器则共享宿主机的操作系统内核只做运行环境的隔离。所以 Docker 容器的启动通常以毫秒级到秒级计算一个低配开发机跑十几个容器也轻轻松松。好处不仅在于省资源。因为共享内核容器和宿主机之间的文件交换、端口映射、网络通信都比虚拟机更直接。这为后面做微服务的本地联调、自动化测试、持续集成流水线铺平了道路。注意共享内核也意味着 Linux 容器必须跑在 Linux 环境下如果是在 Windows 或 macOS 上使用Docker Desktop 会内置一个轻量级虚拟机中转一层体验上没什么差别。2. 安装 Docker 并用 5 分钟跑起第一个容器2.1 安装与版本检查我假设你用的是 Linux 服务器或本地开发电脑。安装方式根据系统不同有差异这里只强调几个关键点。Linux 下尽量不要直接用包管理器装一个过旧版本。建议先卸载掉系统自带的旧包然后在官方源里装最新版本。装完以后记着执行这两条命令sudo systemctl enable docker sudo systemctl start docker这两条命令的作用是让 Docker 服务开机自启并启动。很多新手装完以后直接敲docker命令发现提示无法连接守护进程多半是服务没有启动。验证是否装好执行docker version正常会输出 Client 和 Server 两段信息。如果 Server 那一段报错说明 Docker 守护进程没跑起来先回去检查服务状态。macOS 和 Windows 用户直接安装 Docker Desktop 就行安装完成后在终端执行同样的docker version验证。我个人建议把一个普通用户加入 docker 用户组避免每条命令都要加sudosudo usermod -aG docker $USER改完以后重新登录会话生效。这一步做不做不影响功能但对命令行操作体验天差地别。2.2 第一个容器hello-world装好以后跑一条最基本的命令docker run hello-world这个过程会发生四件事本地找不到hello-world镜像、自动从远程仓库拉取、启动容器、容器输出一串提示后退出。等看到那段 “Hello from Docker!” 的提示说明整个链路已经通了一半。我更推荐用 Nginx 演示一次真正的容器服务样例因为hello-world只是输出文本看不到网络效果docker run -d -p 8080:80 nginx参数的意思-d表示后台运行-p 8080:80表示把宿主机端口 8080 映射到容器内部的 80 端口。跑完以后浏览器访问http://localhost:8080看到 Nginx 的欢迎页你就完成了第一个真正对外提供服务的容器。注意第二个示例要求宿主机网络上 8080 端口未被占用。如果端口被占用了换成任意一个空闲端口即可比如-p 8090:80。2.3 停下来思考为什么一条命令就把服务跑起来了第一次成功的时候不妨多想一步Nginx 并没有被安装到你电脑上也没有修改系统的任何配置为什么它就能跑起来因为nginx镜像里面已经包含了 Nginx 程序本体、它依赖的系统库、默认的配置文件、日志目录约定。Docker 启动容器时把这一整套文件系统完整地装入一个隔离空间里然后执行镜像里预设的启动命令。它不需要也不关心宿主机的软件环境所有运行需要的东西都在镜像里备齐了。这也是新人最容易产生疑惑的地方。“为什么我在容器里装的软件不会把宿主机弄乱”“为什么卸载 Dcoker 对系统毫无影响”答案都在这个设计里容器看到的是一个由镜像提供的完整文件系统它做的所有改动只会写在自己那层可写层里不会碰宿主机文件。3. 镜像、容器、仓库三件套的命令实战3.1 最常用的镜像命令挑几个出现频率最高的写一下。docker images列出本地已有的镜像。这个命令能看到镜像名、标签Tag、镜像 ID、创建时间和大小。注意一点同一个镜像名下面可以有多个标签比如ubuntu:20.04和ubuntu:22.04是两套不同的镜像。docker pull ubuntu:22.04从仓库拉取镜像到本地。新手以为只有docker run才会下载镜像其实可以先pull再run分两步更容易理解。docker rmi 镜像ID或镜像名删除本地镜像。如果镜像还有容器在使用删除会报错需要先清理容器。镜像的大小值得留意。一个ubuntu:22.04基础镜像通常只有几十兆但一个包含完整工具链的开发环境镜像可能到几个吉比特。这决定了后面构建镜像时的优化策略也解释了为什么 Docker 镜像分层复用的设计极其关键。3.2 容器的生命周期管理容器的操作是日常频率最高的环节先把生命周期串一遍。启动一个容器docker run -d --name my-nginx -p 8080:80 nginx--name给容器起一个名字后续所有管理操作都可以用这个名字代替容器 ID。查看运行中的容器docker ps加上-a参数可以看到所有容器包括已经停止的。停止和删除容器docker stop my-nginx docker rm my-nginx注意stop只是暂停容器进程容器还在磁盘上rm才是真正删除。停止的容器可以用docker start my-nginx再次启动。我见过不少同事为了省事直接删除重跑其实容器内产生的数据也一并丢了。这也引出了后续要专门讲的数据持久化问题。容器日志查看docker logs -f my-nginx-f参数表示持续跟随日志输出调试服务时很有用。进入容器内部调试docker exec -it my-nginx bash这条命令会打开一个容器的交互式终端你可以像在一台独立 Linux 机器上一样敲命令。但这要建立在镜像里装了 bash 的前提下有些精简镜像只有 sh把bash改成sh即可。3.3 端口映射和数据卷端口映射的原理值得稍微展开。容器运行在一个隔离的网络空间里宿主机并不能直接访问容器内部的网络地址。-p 8080:80相当于在宿主机 8080 端口和容器 80 端口之间建立了一条通道所有访问宿主机 8080 端口的流量都会转发到容器的 80 端口。生产环境常见的内网服务常使用-p将端口只绑定到内网网络接口而不是0.0.0.0。比如docker run -d -p 127.0.0.1:8080:80 nginx这样写只允许本机访问外网不可达做调试更安全。容器内部的文件改了什么容器一删就全部消失这时需要数据卷Volume来解决。最简单的挂载方式docker run -d -p 8080:80 -v /home/myuser/nginx-html:/usr/share/nginx/html nginx-v 宿主机目录:容器目录把宿主机目录原样挂到容器目录里容器读写这个目录的操作直接映射到宿主机磁盘上。修改宿主机文件容器内立刻能看到变化删除容器重新创建数据依然在。提示宿主机目录最好用绝对路径否则容易踩到目录解析的坑。4. 用 Dockerfile 构建自己的镜像4.1 为什么需要自己构建镜像常用软件可以从仓库拉现成的但自己的业务代码必须做成镜像才能享受 Docker 带来的部署便利。Dockerfile 就是一份描述“如何构建镜像”的配方文件把依赖安装、代码拷贝、启动命令一步一步写清楚。Docker 会按照步骤逐层构建每一层形成一次文件系统的变更记录。4.2 一个最小可用的 Node.js 示例假设项目是一个简单的 Node.js HTTP 服务源码目录里只有app.js和package.json。创建一个名为Dockerfile的文件FROM node:20-alpine WORKDIR /app COPY package.json ./ RUN npm install COPY . . EXPOSE 3000 CMD [node, app.js]逐行解释一下FROM node:20-alpine以 Node.js 20 的 Alpine 精简版镜像为基础。Alpine 镜像体积小适合作为构建基础。WORKDIR /app设定容器内的工作目录后续命令都在这个目录下执行。COPY package.json ./RUN npm install两步分开写有讲究。Docker 构建时会缓存每一层的结果只要package.json没变npm install的结果会直接命中缓存不会每次重建依赖构建速度快很多。COPY . .把项目源码拷贝进镜像。EXPOSE 3000声明容器内使用的端口注意这只是一个声明不会自动映射端口真正映射还得靠docker run -p。CMD [node, app.js]设置容器启动后的默认执行命令。然后在项目目录下执行docker build -t my-node-app .-t指定镜像名和标签这里仅指定了镜像名默认标签是latest。构建完成后运行docker run -d -p 3000:3000 my-node-app浏览器访问http://localhost:3000一个属于自己的应用容器就上线了。4.3 .dockerignore 和镜像体积的优化很多新手从 Git 仓库拷贝项目时顺带把node_modules、.git目录也打包进了镜像构建体积立刻膨胀到几百兆甚至上吉比特。解决办法是在项目根目录添加.dockerignore文件node_modules .git *.log .DS_Store这是构建镜像是常被忽略但实际作用非常大的配置文件。少了它COPY . .会盲目地把整个项目目录塞进镜像构建速度慢、镜像体积失控甚至可能把宿主机上的敏感配置也带进去。还有一层优化思路是构建阶段和使用阶段分离。比如前面示例中npm install产生的依赖文件运行时根本不需要完整保留源码构建工具。业界常见做法是用多阶段构建先把编译产物做一个精简的运行时镜像。这个技巧进阶时再细说但了解这个概念会让后来的学习顺畅很多。5. 用 Docker Compose 编排多容器应用5.1 为什么要引入 Compose实际项目很少只有一个容器。一个简单的 Web 应用可能同时依赖 MySQL、Redis加上应用本身至少三个容器。如果全用docker run逐个启动不仅要记一堆参数容器之间的网络、启动顺序、配置关联手工处理起来非常痛苦。Docker Compose 允许写一个docker-compose.yml文件把多个服务、网络、数据卷一次性定义好然后一条命令启动全部。5.2 一份最常见的 Web Redis 组合示例假设项目是 Node.js Web 服务需要连接一个 Redis 缓存。在项目目录创建docker-compose.ymlservices: web: build: . ports: - 3000:3000 depends_on: - redis environment: - REDIS_HOSTredis redis: image: redis:7-alpine ports: - 6379:6379这里有几个细节值得单独解释。ports的作用和docker run -p完全一致只是写成了结构化的格式。environment里设置的REDIS_HOSTredis是容器之间通信的精髓。在 Compose 创建的内部网络中每个服务名本身就是可用的域名。应用代码连 Redis 时只需把主机名设成redisCompose 会自动解析到这个服务容器的内部网络地址无需关心容器的具体 IP。depends_on保证 Redis 容器会在web容器之前启动。但注意它只保证“启动顺序”不保证“服务已就绪”。数据库容器启动了未必代表端口已能接受连接严格的健康检查还需要额外的配置这点后续碰到了再深入。启动命令docker compose up -d查看所有服务状态docker compose ps停止并清理docker compose down一切正常运行后把项目分享给同事会非常顺滑。对方只需要安装 Docker 和 Compose然后在项目目录敲一条docker compose up -d就能得到一个完全一致的环境。5.3 数据卷在 Compose 里的配置容器重启后数据库数据不能丢需要把数据写到宿主机磁盘。Compose 里推荐用命名卷来做services: redis: image: redis:7-alpine volumes: - redis-data:/data volumes: redis-data:redis-data是 Docker 自动管理的一个数据卷不需要手动指定宿主机目录。它迁移性好生产环境备份也方便。6. 常见问题与排查技巧实录6.1 高频问题速查表整理了几个入门阶段高频出现的问题直接对照排查。现象可能原因处理办法拉取镜像超时网络不稳定或仓库连接不通配置镜像加速地址或检查网络策略端口映射不起作用指定的宿主机端口被占用更换宿主机端口用docker ps查看真实映射容器启动立刻退出启动命令执行后进程主动退出docker logs查看日志确认启动命令是否阻塞容器内连接不到宿主机服务使用了localhost而不是宿主机地址容器里的localhost是容器自己要用宿主机局域网 IP数据不持久化没挂载数据卷或匿名卷被清理使用-v显式挂载宿主机目录或命名卷镜像构建体积过大多余文件被打包添加.dockerignore优化 Dockerfile 层级权限报错permission denied当前用户不在 docker 用户组sudo usermod -aG docker $USER后重新登录6.2 排查动作的推荐顺序新遇到一个容器问题不要急着反复删除重建。先按这个顺序操作第一步docker ps -a看容器的状态。是Exited还是Up状态信息本身就能缩小问题范围。第二步docker logs 容器名看日志。多数应用启动失败都会在日志里打印明确的报错信息。有的应用日志默认打到文件里标准输出没有内容这时需要进容器查日志文件。第三步docker inspect 容器名看容器的详细配置。这个命令输出内容很长建议结合grep或jq查关键字段。比如确认环境变量是否生效、端口映射是否正确、挂载目录是否合法。第四步如果确认是启动命令或镜像内容的问题再用docker exec -it 容器名 sh进容器内手动执行命令。容器里的文件和目录结构一目了然很容易定位是“文件没打进去”还是“权限不对”。6.3 几条实践之后的避坑心得我用 Docker 折腾了不少项目有几条经验是挨过打总结出来的。容器内的时间问题。容器默认使用 UTC 时区如果你的应用日志或定时任务依赖本地时区需要在启动时挂载时区文件或者通过环境变量设置时区。否则凌晨排查问题时会发现时间差了八个小时非常迷惑。不要随意用latest标签。latest是个会变动的引用同一台机器今天跑和下周跑可能拉到的镜像内容不一致。正式项目建议把标签固定到具体版本号比如redis:7.2.4避免“没改代码但行为变了”的离奇问题。容器里尽量不要自己装东西调试。容器是临时环境任何改动在容器重建后都会消失。需要临时修改时不如先确认改动点再把改动写进 Dockerfile 或环境变量里保证“重启不丢”。.dockerignore不要嫌麻烦。即使项目很小也比把一整个开发目录送进镜像强得多。我之前见过一个镜像打出来 2GB 多查了半天发现是.git目录被带了进去加上几十个压缩包全被塞进了镜像。6.4 磁盘空间被容器日志吃满的处理开发环境用久了docker logs输出会积攒大量日志文件如果不限制大小磁盘会被慢慢吃光。推荐在启动容器时就给日志加上轮转限制docker run -d --log-opt max-size10m --log-opt max-file3 nginxCompose 里对应的写法services: web: image: nginx logging: driver: json-file options: max-size: 10m max-file: 3忘了加限制的可以定期用docker system prune清理悬空镜像和停止的容器。不过它会连带清理所有没有在用的资源执行前确认下这台机器上有没有要留着的容器数据。写在最后的体会我在最初上手 Docker 时也曾把不少时间耗在“看命令、跑通、再忘掉”的循环里。后来真正让我产生质变的不是记住了多少命令而是把镜像和容器的关系理清楚了理解了每一层是怎么回事端口是转发数据卷是映射容器只是进程镜像只是归档。所有操作都围绕这几个概念展开命令再多也能归类。再有一个实际心得是入门阶段不要只玩 hello-world拿一个自己熟悉的小项目构建一遍镜像再用 Compose 跑起来比读十篇教程都管用。出错的时候认真看日志遇到问题多按docker inspect查细节几轮下来你会发现自己已经能靠“推测加验证”解决绝大多数问题。如果后续想继续深入建议顺着几个方向摸索多阶段构建的进阶写法容器间的网络安全策略以及把构建流程接入自动化流水线。这些内容一块一块啃下来Docker 从熟悉到用得顺手只是时间问题。