★ FEATURED ARTICLE 想搞清楚容器化绕不开 Docker。这个工具解决的最核心问题是让应用能够带着自己的运行环境一起打包、分发、运行从在我电脑上能跑变成在任何地方都能跑。本文作为精通之路的上篇覆盖了从容器基础原理、安装配置、镜像操作、容器生命周期管理到数据持久化和网络模式最常用也最关键的环节适合刚接触容器、或者用了一阵 Docker 但总觉得基础不牢的开发者。读完这部分你应该能独立使用 Docker 完成日常开发、测试环境搭建和简单部署并且对镜像层、数据卷、网络隔离这些概念有自己的理解而不是死记命令。1. 为什么绕不开 Docker1.1 环境地狱与交付困境先从一个最真实的场景说起。你费了很大劲完成了一个 Web 应用本地跑得非常好。结果同事把代码拉过去在他的 Windows 机器上根本起不来数据库连接报错依赖版本冲突日志刷屏。你又花一天时间帮他配环境。配完之后发现测试环境环境变量少了一个Redis 版本不一致线上再炸一次。这种“环境地狱”所有开发几乎都遇到过。Docker 的思路很直接把应用代码、系统依赖、运行环境、配置文件全部塞进一个标准化的“集装箱”也就是镜像。运行时通过镜像开启的容器就是一个隔离且完整的进程环境。应用在容器里看到的环境永远和你构建镜像时保留的环境保持一致。这带来的价值不只是省去了重复配置环境的工作量。它改变的是交付方式。以前交付产物是一段代码加一份长长的部署文档现在是一个镜像。镜像构建出来之后在开发机、测试机、生产机上运行结果完全一致这才是容器化最本质的吸引力。1.2 容器不是轻量虚拟机很多人初学 Docker 时都会把它理解成“性能更好的虚拟机”这个误解关系到后面的全部理解。虚拟机通过 Hypervisor 模拟完整的硬件层再在硬件上运行完整 Guest OS重量大、启动慢、资源开销高。每个虚拟机都包含一个完整操作系统动辄好几个 GB。容器则不一样。它不是对硬件层的模拟而是共享宿主机内核通过 Linux 内核提供的隔离机制来控制进程组。容器内没有独立的内核也不需要完整的操作系统镜像里只需要包含应用本身及其依赖的库文件、配置文件等即可因此镜像体积往往只有几十兆到几百兆启动时间以秒甚至毫秒计一台物理机上可以并行跑几十上百个容器。简明的理解方式虚拟机是“模拟整台电脑”容器是“在共享操作系统里划了几个相互隔离的空间各自安装自己需要的软件”。这些空间共用同一个底层系统但看不见、管不着对方也不会随意使用对方安装的程序和数据。1.3 底层两板斧Namespace 与 Cgroups容器隔离的核心依赖 Linux 内核的两个基本能力。第一个是 Namespace用来实现资源的隔离。举一个直观例子一台服务器上跑两个容器彼此看到的网络、进程列表、文件系统完全区分开就像两个独立的小系统在同时运行。虽然它们实际上共享同一个内核和宿主机 CPU、内存资源但 Namespace 让每个容器形成了各自独立的视图。第二个是 Cgroups用来做资源限制。单独说隔离还不够如果不加限制一个容器可能把宿主机全部内存吃光影响其他容器。Cgroups 可以把容器能用的 CPU 时间片配额、内存上限、磁盘 IO 带宽统统管住让每个容器只在自己的份额里运作。Docker 相当于在这些内核能力之上封装了一层用户友好的接口用命令和配置文件把底层行为包装起来。理解了这两点后看后面的所有操作都能在脑海里建立起来一层正确的模型。容器这个词背后本来就是一套 Linux 内核控制与调度逻辑而不是什么独有技术。2. 装机、换源与 Docker 架构认知2.1 安装与守护进程启动安装 Docker 的方式在不同系统上有些差异。Linux 上通常直接用系统包管理器下载安装以 Ubuntu 系为例安装完成之后需要确认守护进程已启动sudo systemctl enable docker sudo systemctl start dockerDocker 采用典型的 C/S 架构。docker命令是客户端真正干活的是后台的dockerd守护进程。客户端通过 socket 或网络把指令发给守护进程然后由守护进程完成镜像拉取、容器创建、资源管理等工作。这意味着即使你只是在终端敲了一个docker run背后经过的链路是整个客户端与服务端协作流程。安装完成后最好跑一条验证命令确保一切正常docker info docker run --rm hello-worldhello-world是一个专门用于验证的最简镜像能顺利输出提示信息就说明整个链路已经跑通。有些时候你还会用到免 sudo 的权限配置sudo usermod -aG docker $USER newgrp docker把当前用户加入docker组后日常操作就不用每次敲sudo了。注意这个组等同于 root 权限配置时要想清楚安全性。2.2 registry-mirror 配置Docker 官方镜像仓库部署在海外国内直连下载经常面临速度很慢、超时中断这类问题。虽然当前网络环境相对以前已经好了很多但镜像加速问题依然是实际使用中的头号痛点。配置镜像加速器的方法是修改 Docker 的守护进程配置文件常见路径是/etc/docker/daemon.jsonsudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json -EOF { registry-mirrors: [https://mirror地址] } EOF sudo systemctl daemon-reload sudo systemctl restart docker镜像加速器本质是一个仓库镜像代理节点Docker 客户端拉取镜像时直接从镜像节点获取速度快很多。使用公共镜像加速器要注意隐私问题公司内部开发时更合理的方案是部署公司私有仓库然后把加速器指向内部源。2.3 更换镜像源的必要性在实际操作中很多朋友会发现配好镜像加速之后偶尔还是会遇到某个镜像层拉取超时。这和不同公共镜像所在链路稳定性差异有关。一些人会选择直接从加速器拉取另一些人则会在构建时使用带镜像前缀的基础镜像。这块的经验是基础镜像尽量选体积较小的发行版比如 alpine 系镜像能显著减少传输层数和最终占用空间。一个几百兆的镜像和一个几十兆的镜像在同样不太稳定的网络条件下成功率差别很明显。容器镜像更新频率通常不高把重心放在源的选择和分层缓存利用率上比反复重试硬拉要有效得多。3. 镜像操作与容器生命周期3.1 镜像、容器两步走镜像和容器的关系可以对照着编程里的类和实例来理解。镜像是一份只读的模板定义好了应用代码、依赖、默认配置和启动命令容器是这份模板的运行实例。同一个镜像可以启动多个容器彼此之间相互隔离这跟同一个类可以 new 出多个对象是同一个道理。镜像由多层只读文件系统叠加组成。构建镜像时每一条指令产生一个新的层。拉取镜像时如果本地已有部分层也会复用缓存这也是为什么第二次构建时能明显感受到速度提升。基于这个模型写 Dockerfile 时一定要把不变的内容放在前面、经常变化的内容放在后面反复利用缓存层能大幅缩短构建时间。3.2 常用镜像命令清单以下是在日常工作中最高频的镜像操作# 搜索镜像 docker search nginx # 拉取镜像 docker pull nginx:1.24 # 列出本地镜像 docker images # 查看镜像详情 JSON 格式 docker inspect nginx:1.24 # 删除镜像 docker rmi nginx:1.24docker pull是运行容器前最基础的一步。默认不加 tag 时拉取的是latest标签实际生产中强烈建议指定明确的版本避免因为 latest 浮动导致环境不一致。镜像 tag 可以理解为镜像版本的标签nginx:1.24和nginx:latest可能指向完全不同的镜像内容依赖 latest 在时间维度上是不可靠的。docker inspect返回的内容很庞杂包含了镜像的所有元数据层信息、环境变量、入口命令、架构等。调试时也常用它查小细节比如容器 IP 或者镜像是何时构建的都在输出里有记录。3.3 容器的完整生命旅程容器从创建到销毁大体经历这么几个状态created、running、paused、exited、dead。理解这些状态非常重要因为排查一个问题时第一步通常就是看容器到底卡在哪个状态。先看最简单的启动方式docker run -d --name web -p 8080:80 nginx:1.24拆开看每个参数的用意-d表示后台运行不占用当前终端--name web给容器起一个易记的名字后面所有操作都通过名字来引用它-p 8080:80把宿主机 8080 端口映射到容器内 80 端口。容器内的 80 端口对外部完全不可见外部访问宿主机的 8080 端口流量就会被转发进容器。启动之后你很快就需要对容器做状态管理。最常用的就这么几条# 查看正在运行的容器 docker ps # 查看所有容器含已退出 docker ps -a # 停止容器 docker stop web # 启动已存在的容器 docker start web # 重启容器 docker restart web # 删除容器 docker rm webdocker ps是每天点得最多的命令视野内能直接看到容器的端口映射、状态、镜像来源等信息。加不加-a的区别很明显不加时只看还在运行中的容器加上-a之后那些已退出的容器也在列表里方便复盘排查。3.4 进入容器的几种方式日常开发中免不了要进入容器内部看日志、调试命令或确认文件。最常用的是docker exec -it web /bin/bash-i保持标准输入流打开-t分配一个伪终端组合起来才能得到一个可交互的操作界面。很多初学者只敲docker exec web /bin/bash执行完没有任何反应就是因为缺少-it没有通道可以输入也没拿到终端回显。还有一条常用的日志查看命令docker logs -f web容器可能会把日志输出到标准输出docker logs取的就是这部分内容-f等价于tail -f用于持续跟踪输出。注意如果一个应用写日志到文件而不是标准输出docker logs抓不到任何内容这是常见困惑点。小经验生产环境里如果所有事情都必须靠docker exec进容器解决说明应用的可观测性设计还没到位。容器本身是易失的进容器调试应当是临时手段最终还是要在镜像层面去修复问题重建容器。4. 用 Dockerfile 构建定制镜像4.1 一个最小可用的 Dockerfile纯粹使用官方镜像能解决很多问题但真正把 Docker 融入工作流最终都绕不开自己构建镜像。用一个 Node 应用举例最简单的 Dockerfile 长这样FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm install COPY . . EXPOSE 3000 CMD [node, app.js]每一行都有明确职责FROM指定基础镜像。这里选用 alpine 版本体积小安全性高。WORKDIR设定容器内的工作目录之后的所有执行路径都会基于这个目录。COPY package*.json ./先把依赖清单拷进去只做依赖安装这一步。之所以单独放前面是为了利用构建缓存。RUN npm install在镜像构建阶段安装依赖。后续 COPY . .把全部源码拷进镜像覆盖在已有层之上。EXPOSE声明容器内应用的监听端口注意它只起声明作用真正映射还是要靠-p参数。CMD定义启动容器时执行的命令。构建命令docker build -t myapp:1.0 .最后的点号用来指定构建上下文路径。Docker 会把目录下所有文件打包发送给守护进程作为构建过程中 COPY 等指令可引用的材料。所以目录过于庞大时构建也会变慢通常用.dockerignore文件排除不需要的文件。4.2 多层缓存的底层逻辑说到缓存这是构建效率的关键。Dockerfile 的每一行指令生成一个层构建时如果某个基础镜像层和前面指令都没变新加进来的指令能复用之前的缓存层。后面的指令如果有任意一层发生变更之后的所有层也会随之失效。所以衡量一个 Dockerfile 写得好不好很重要的一部分是看能否充分利用缓存。按“依赖信息在前、源码在后”的顺序来写依赖装完再复制源码日常改代码触发重新构建时就能直接命中前面所有缓存层只重跑最后几层构建时间从几分钟缩短到几十秒不是夸张的说法。COPY . .这一行经常导致缓存失效因为目录里的任何文件变动都会让该层以及之后的所有层重新构建。因此把源码复制尽量往后放是值得养成的习惯。4.3 多阶段构建解决体积焦虑构建一个编译型语言的镜像是很多人头疼的事情。因为编译阶段需要完整的编译器、头文件、SDK但这些最终运行完全用不上。把它们全放进最终镜像体积会膨胀到几个 GB。多阶段构建用一句话总结就是一个 Dockerfile 里写多个 FROM。每个 FROM 开启一个独立的构建阶段前期阶段用大而全的镜像完成编译最终阶段只把编译产物复制到精简的运行镜像里。一个典型的 Go 项目例子FROM golang:1.21 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED0 go build -o /app/app . FROM alpine:3.19 WORKDIR /app COPY --frombuilder /app/app . EXPOSE 8080 CMD [./app]前面一条RUN CGO_ENABLED0 go build ...在完整 Go 镜像里编译出静态二进制后面从 builder 阶段把产物直接拷进 alpine 运行镜像。最终镜像只需要二进制文件和少量运行库体积可以降到几十兆而且只包含必要的文件安全面也小了很多。避坑提示多阶段构建里最终阶段的基础镜像不能选错静态编译的 Go 程序可以直接跑 alpine但依赖 glibc 的动态链接程序跑到 alpine 上大概率遇到 “not found”。这种问题几乎与容器本身无关是动态链接库缺失和发行版差异共同导致的。4.4 镜像瘦身的实用手段除了多阶段构建还有几个随手就能用的瘦身技巧。首先基础镜像优先选 alpine即使业务程序对发行版有限制不能直接用也值得围绕它做一些尝试。其次善于合并 RUN 指令因为每一条 RUN 都对应一层镜像把若干操作类指令合并能减少层数和中间垃圾。还有一个老生常谈的问题是用apt-get时一定要清理缓存文件RUN apt-get update apt-get install -y \ some-package \ rm -rf /var/lib/apt/lists/*不过多阶段构建推广之后这类基于 apt 的瘦身场景在实际生产比重已经小了很多。真正意义上帮助更大的还是把编译产物和运行时环境分开这一步能直接让体积瘦得彻底。5. 数据持久化的坑位与姿势5.1 为什么数据会丢很多人在学会运行容器后的第一周都会踩上同一个坑容器里跑了数据库存了一堆数据然后执行docker rm把容器删了数据全部消失。这其实完全符合容器的设计逻辑。容器是易失的删除容器本质上就是把容器的可写层一起抹掉。容器默认状态下除镜像层外还能写入数据写入的数据放在容器可写层容器一旦删除这层数据也跟着没了。就算容器不删除宿主机上的文件也藏在 Docker 管理的目录里很难直接读写不方便。这个问题的标准解是数据卷和绑定挂载。5.2 数据卷与绑定挂载的区别数据卷是 Docker 管理的持久化存储用-v指定卷名和挂载点来使用docker run -d --name mysql -v mysql-data:/var/lib/mysql mysql:8.0数据卷的数据存放在 Docker 数据目录里由 Docker 统一管理宿主机上具体路径不需要你操心迁移时通过卷操作即可干净安全。绑定挂载则是把宿主机上的具体目录直接映射到容器内docker run -d --name web -v /home/user/myapp:/app nginx:1.24宿主机/home/user/myapp里的文件会直接出现在容器/app目录双向实时同步。这种方式的直观好处是方便阅改源代码、查看日志文件容器删了宿主机文件还在。但在绑定挂载时要有意识在两侧默认持有相同权限如果目录权限和属主配置没处理好容器里的进程可能会遇到无法读写文件的权限报错。这个不像数据卷那样由 Docker 兜底需要花点时间预先调整权限。5.3 只读挂载与日志文件清理挂载目录时不建议让容器写入宿主机的每一个目录。日志场景尤其要留意容器把日志写到挂载目录日志文件持续增长。如果目录限制没做好、日志轮转也没配置磁盘满了之后会影响整台机器的运行。一个更安全的选择是让挂载只读化宿主机单向把内容提供给容器容器不能回写宿主目录docker run -d --name web -v /home/user/app:/app:ro nginx:1.24如果要将日志放在宿主机上则必须做好磁盘空间监控或者配置容器的日志轮转。容器的日志量一大默认的 json-file 日志驱动会产生大量单文件长时间不清理也可能造成磁盘告警。绕开这个问题可以从两个方向入手一是把日志写进数据卷或 stdout 做外采二是把宿主机对日志的挂载设计成单独目录并配好轮转策略。6. 网络模型与跨容器通信6.1 默认 bridge 网络的行为Docker 安装后会默认创建一个 bridge 网络单个容器启动时如果不指定网络都会连接到这个默认网络上。容器会从网桥分配的网段中获得一个 IP容器与容器之间可以通过这个 IP 相互访问。但依赖默认网桥的容器 IP有个很明显的问题容器重建后 IP 会变化。如果你的服务 A 写死服务 B 的 IP 来访问B 一重启A 就找不到了。生产环境里这种直接依赖 IP 的方式非常脆弱维护成本也高。6.2 自定义网络与容器名互联Docker 提供用户自定义的网络而且内置了基于容器名的 DNS 解析功能。在同一个自定义网络里的容器直接用容器名就能互相通信。操作方式docker network create mynetwork docker run -d --name app1 --network mynetwork myapp:1.0 docker run -d --name app2 --network mynetwork mysql:8.0app1 需要连接数据库时直接访问app2:3306即可不用关心它的 IP 是多少。Docker 内置 DNS 会解析这个名称。这种设计带来的是一套干净的服务发现机制只要应用部署在同一个自定义网络容器迁移、扩容都不需要改配置。这与 Docker Compose 的服务名互联是同一个底层能力。6.3 host 网络和 none 网络host 网络模式下容器不进行网络隔离直接共享宿主机的网络命名空间。容器里的服务就如同直接跑在宿主机上用127.0.0.1:端口就能访问。这种模式性能好适合对网络性能要求比较高、且端口不冲突的场景。but host 网络也有明显的副作用没有端口隔离意味着容器里启动一个端口就占宿主机一个端口几个容器同时都要用相同端口时会冲突。此外服务无法用容器 IP 来区分网络调试方式也会改变。none 模式是一种完全隔离的状态容器没有外部网络接口只有本地回环。这种模式常见于高安全场景或只做离线计算的临时容器平时用到概率较低。网络模式选型上默认 bridge 最安全便捷自定义网络用于多容器的服务间通信host 网络在性能和特殊网络场景下使用属于按需权衡的选项。7. 常见问题与排查技巧实录7.1 容器启动立即退出这是新手最常见的头疼问题docker run命令执行完容器立刻退回退出状态docker ps -a里看到状态是 Exited。原因通常不在 Docker 本身。容器进程没有长期存活自然就退出了。比如启动一个不提供服务的进程或者启动一个把任务跑完就结束的程序容器跟着结束是符合预期的。想保持容器存活通常要求前台进程不能退出。比较常见的办法是在本地调试时改为docker run -it --name debug image /bin/sh利用交互式 shell 保持前台。生产环境则应修正启动命令让服务进程持续监听端口不要用后台化方式启动应用。7.2 端口不通或连接拒绝服务正常启动了外部就是访问不到。排查思路按层递进先确认容器监听端口对不对docker exec 容器名 netstat -tlnp容器常在精简镜像中缺少此命令也可以使用ss或检查应用配置。检查端口映射是否生效docker port 容器名观察宿主机端口和容器端口的对应关系。再确认访问的是宿主机 IP 而不是容器 IP外部设备无法直接访问容器 IP。最后检查宿主机防火墙、云平台安全组是否放行了对应端口。大多数情况下问题出在应用监听端口与 EXPOSE 声明不一致或者防火墙阻挡。先用docker port列出真实映射再逐层排除。7.3 容器内时区与编码问题容器默认时区往往是 UTC业务日志时间与本地时间偏差 8 小时是国内环境排查问题时一个大坑。改法是在 Dockerfile 里指定时区RUN apk add --no-cache tzdata ENV TZAsia/Shanghai镜像体积允许时也可以直接基于宿主机的时区文件做挂载。编码问题同理容器语言环境如果不显式声明可能遇到中文字符乱码。在 Dockerfile 里设置ENV LANGC.UTF-8可以在很多基础镜像上解决部分乱码问题。7.4 镜像拉取慢怎么办前面说过的 registry-mirror 方案是第一优先级。第二优先级是检查网络环境和源连通性。第三优先级是考虑换用官方轻量镜像如slim或alpine减少传输体积。在公司内网环境下部署私有镜像仓库并用专门加速通道往往是最终解法。7.5 磁盘空间被镜像吃满构建多了、拉取频繁之后本地会堆积一堆悬空镜像、旧镜像和停止状态的容器。规律性清理# 清理悬空镜像、停止容器和无用网络 docker system prune # 加上 -a 会连未被容器引用的镜像一起清理 docker system prune -a # 查看占用统计 docker system dfdocker system df很像磁盘空间管理工具能清楚看到镜像、容器、数据卷各占多少。大家经常忘掉数据卷也是大头清理前务必确认数据卷里的数据是否还有价值。8. 我踩过的坑和对初学者的几条建议8.1 容器内文件权限问题的经验用绑定挂载时宿主机用户 UID 和容器内用户 UID 不一致隔离层导致的权限拒绝问题会来回折腾。后来我习惯了在镜像里直接创建与宿主一致的 UID 用户或者用user:group参数调整这个问题才稳定解决。8.2 慎用 latest 标签初学阶段图省事经常写nginx:latest。直到有一天某个镜像的最新版本基础系统底层行为变了线上一个接口突然慢了一截查了半天才发现是拉取镜像时自动更新到了新版本。“latest 永远是浮动的”现在公司里做交付底线要求是镜像 tag 必须锁定到一个明确版本。8.3 练好 docker exec 与 docker logs 双板斧调试容器大部分工作只需这两条命令。先在docker logs看应用日志再docker exec进去确认细节。按这个顺序排查能少碰很多弯路。而真正进入生产环境这一切都需要升级为更系统的日志采集和监控体系但基础中的基础依然是对 Docker 本身行为模型的熟悉。8.4 从手敲命令走向 Compose 的过渡单机多容器唯一需要手动敲命令的阶段是刚学 Docker 的那几天。当项目里出现了两个以上相互依赖的容器使用 Docker Compose 统一的 YAML 编排是更合理的做法。上篇里所有单容器命令在 Compose 里几乎都有对应的声明式配置理解清楚单容器命令后迁移到 Compose 是非常平滑的。下篇里我会继续解析 Compose 编排、私有仓库部署、容器安全加固以及 K8s 层面一些核心概念的关联。先把这篇里的镜像、容器、数据卷、网络这四大基本功练扎实后面的路会顺很多。
阅读完成 · 觉得有帮助？
