写 Docker 的文章多如牛毛但大多数都停在镜像就是模板、容器就是实例、仓库就是存镜像的地方这句比喻上。比喻能帮你建立第一印象但也容易让你产生一种我懂了的错觉真到排查容器秒退、镜像构建失败、推送超时的时候照样抓瞎。这篇打算换个路子按我自己在生产环境里用 Docker 的实践经验把镜像、容器、仓库三个概念背后的运行机制、操作逻辑和踩过的坑全部讲透。标题说三分钟我尽量让你读完前面两节就能在脑海里搭出完整框架后面每一节都是针对实际场景的深入拆解时间紧可以先看第 1、2 节再回来补细节。Docker 解决的核心问题就一句话让一份带完整运行环境的应用能够在任何机器上以一致的方式跑起来。镜像负责打包把代码、运行时、系统库、配置统统固化成一个只读产物容器负责运行在这份产物上叠加一个可写层变成真正对外服务的进程仓库负责分发把镜像从构建的地方送到运行的机器也把团队的私有镜像管理起来。这三者缺一不可理解不了任何一个其他两个都会用得很别扭。1. 先给三个概念定个性镜像、容器、仓库各自的角色1.1 镜像一份只读的完整运行环境快照镜像到底是什么从使用者的角度看它就是一个包含了完整文件系统、应用代码、运行参数和环境变量的静态包。你可以用docker images看到本机所有镜像用docker pull从仓库拉取用docker run基于它创建容器。但从机制上讲镜像的真正核心是只读两个字——镜像本身永远不会被运行过程修改任何对文件的增删改都发生在容器层。很多人不理解只读到底意味着什么举个例子就清楚了。假设你基于 nginx 镜像启动了一个容器在容器里改了/usr/share/nginx/html/index.html这个修改不会写进 nginx 镜像里。你删除这个容器改动就没了你用同一个 nginx 镜像再启动一个容器看到的还是原始文件。这个特性保证了镜像的可复现性只要镜像不变无论启动多少次、在多少台机器上启动得到的初始环境完全一致。1.2 容器镜像的一个活运行实例容器则是镜像的运行时实例。镜像是静止的文件快照容器是正在运行的进程及其运行环境。用面向对象的语言来类比镜像就像类容器就像根据类实例化出来的对象一个类可以 new 出无数对象一个镜像也可以用docker run启动无数容器彼此之间互不干扰。容器和镜像的关系还体现在存储上。Docker 在镜像的只读层之上给每个容器挂载一个可写层也叫容器层。你在容器里创建文件、修改配置、安装软件都发生在这一层。这个设计让多个容器共享同一个镜像时不需要各自复制一份完整镜像磁盘占用小启动也快代价是容器层是最脆弱的容器一删这层就没了。这也是永远不要把重要数据只存在容器里这条铁律的由来。1.3 仓库存放和分发镜像的版本管理库仓库也叫镜像仓库或 Registry是集中存放镜像并支持推送、拉取的服务。你可以把仓库理解成 Maven 的中央仓库、npm 的 registry只不过里面存的对象是 Docker 镜像。Docker Hub 是官方公共仓库互联网上任何人都可以拉取里面的公开镜像企业里更常见的是自建私有仓库负责管理不在公网公开的镜像。这里有个特别容易混淆的点英文里 Registry 是整个仓库服务比如 Docker Hub 就是一个 RegistryRepository 是仓库服务里的一个具体镜像集合比如 nginx 这个 Repository。日常中文语境下大家都叫仓库但心里要清楚这层包含关系否则看官方文档时会被 Docker Hub、repository、registry 这几个词绕晕后面配置私有仓库时更容易踩坑。1.4 三个概念用一条生活链串起来如果还是觉得抽象可以换一个生活化模型镜像 一套完整的游戏安装光盘容器 你正在玩的一个游戏存档进程仓库 楼下的软件店和在线下载站。光盘内容固定拷给谁都一样这是镜像的只读特性游戏进程会实时产生进度但进度只存在你的电脑上存档没了就要重新打这是容器层的可写与易失软件店负责把光盘分发到每个人手里也允许开发者发布新版本光盘这是仓库的推送与分发。这条链后面还会继续用到。理解了这三者各自的角色下面就可以深入到每个概念内部看看它们到底是怎么运作的以及运作方式决定了哪些操作规范和坑。接下来从镜像的诞生开始讲因为它是整条链的起点。2. 镜像到底是怎么诞生的Dockerfile、分层与构建2.1 Dockerfile 是镜像的生产配方镜像不是凭空出现的绝大多数镜像都由 Dockerfile 构建而来。Dockerfile 就是一个文本配方文件逐行声明基础镜像、要执行的命令、要复制的文件、要暴露的端口和启动命令。Docker 读取这个配方后一步步把它构建成镜像。一个最简 Dockerfile 大概是这样的FROM ubuntu:22.04 RUN apt-get update apt-get install -y curl COPY app.py /app/app.py WORKDIR /app EXPOSE 8000 CMD [python3, app.py]注意 FROM 后面的 ubuntu:22.04 本身就是另一个镜像意思是我在这基础上做加工。这体现了镜像的依赖关系绝大多数镜像都派生自基础镜像基础镜像又派生自更底层的镜像最终都能追溯到 scratch一个完全空白的镜像。这种层层依赖的体系让整条链上的维护者各自只关注自己那一层底层基础镜像有安全更新时重新构建一次上层就能一并吸收修复。2.2 分层文件系统为什么这么重要Docker 镜像由多层组成每一层对应 Dockerfile 的一条指令确切说是会改变文件系统的指令。所有层都以只读方式叠加合并起来构成镜像的完整文件系统。层的存在带来两个巨大好处复用和增量传输。复用好理解多个镜像如果共享同一个基础层磁盘上只存一份。比如你机器上有十个基于 ubuntu:22.04 的应用镜像ubuntu 的层实际只会存一份。增量传输则体现在拉取时docker pull如果发现本地已经有某一层就不会重复下载。我在公司内部搭过镜像分发流程升级基础镜像后几十个应用镜像的推送时间从几分钟降到十几秒就是靠这个特性。层数的多寡也直接影响镜像体积和构建效率。RUN 指令每执行一次就会生成一层所以行业内有个习惯能用一条 RUN 写完的安装命令就写一条用连接需要清理的临时文件要在同一条 RUN 里删除。否则每多一层镜像就多一份没有清理的中间痕迹比如 apt 的下载缓存、编译产生的临时文件体积会肉眼可见地膨胀而且这些中间层对运行时毫无价值。2.3 构建镜像时最容易忽略的缓存问题构建镜像不是每次都全量执行的。Docker 会缓存每一层的结果下次构建时如果某条指令和它的上下文都没变就直接复用缓存层。缓存机制用得好开发迭代飞快用不好会出现改了代码但镜像没变的灵异事件。最常见的坑把经常变化的文件放在前面 COPY导致后续依赖安装层的缓存全部失效。正确的做法是把变化频率从低到高排列——先 COPY 依赖清单文件比如 package.json、requirements.txt执行依赖安装再 COPY 业务代码。这样只有业务代码变化时前面昂贵的依赖安装层可以直接命中缓存。这个技巧在 CI 流水线里效果最明显有的团队没注意顺序一次构建要十几分钟调整 COPY 顺序后能直接压到两分钟以内。还要提醒一个使用 COPY 时要注意.dockerignore文件。它和.gitignore类似用来排除 node_modules、dist、缓存目录等不需要进入镜像构建上下文的文件。如果漏了构建上下文里的大目录每次docker build都要把整个目录发给 Docker daemon构建慢不说还可能不小心把密钥、配置等敏感文件打进镜像安全隐患非常大。3. 容器运行的底层原理隔离与资源限制3.1 容器不是虚拟机进程级隔离的本质很多初学者把容器当成轻量虚拟机这个印象需要修正。虚拟机通过 Hypervisor 模拟出一整台计算机里面跑一个完整操作系统内核容器则直接复用宿主机内核通过内核特性把进程圈在一个受限环境里。换句话说容器里的进程就是宿主机上的普通进程只不过被隔离了视角、限制了资源。这个本质决定了容器的两个特性。第一启动极快秒级甚至毫秒级因为不需要启动内核第二隔离边界由内核特性提供不是硬件级别的所以安全性模型和虚拟机不同这也是生产环境中容器通常还需要额外安全加固的原因。理解这一点你就能明白为什么容器里的系统内核版本和宿主机一致是常见现象也明白为什么有些依赖特定内核模块的应用在容器里会碰壁。3.2 namespaces 与 cgroups 在背后做了什么容器隔离的底层是 Linux 内核的两套机制namespaces 和 cgroups。namespaces 负责隔离看得见的东西让容器内的进程只能看到分配给它的那套进程列表、网络栈、挂载点、主机名、用户等cgroups 负责限制用得着的资源对容器内的进程做 CPU、内存、磁盘 IO 的配额控制。这两套机制合在一起容器的幻觉就成立了进程在容器里以为自己独占了一台小电脑有独立的 PID 1、独立的网络接口、独立的主机名但实际上它还是跑在宿主机内核上。用大白话说namespaces 是给它一个独立的房间隔离视角cgroups 是规定这个房间最多能用多少水电限制资源。做 Docker 排查的时候如果容器 CPU 飙升你要看的是 cgroups 写的配额是否合理而不是笼统怀疑容器里某个进程本身。3.3 容器的生命周期管理容器的生命周期从docker run开始经历创建、启动、停止、删除等状态。重点记这几个命令docker run创建并启动、docker start启动已存在的容器、docker stop发送 SIGTERM 优雅停止、docker kill强制杀掉、docker rm删除容器。需要特别注意的是docker run和docker start的区别前者是基于镜像创建一个全新容器后者是把之前创建过、后来停止的容器再次启动。容器停下来不会消失除非你用rm删掉。所以在服务器上长期维护时我习惯用docker ps -a查看所有容器包括已停止的不要只看docker ps后者默认只显示运行中的。已停止的容器如果不清理会越积越多占磁盘空间的其实是它的可写层别小看这个堆积久了也能吃掉几个 GB。启动容器的参数也值得提前列一个常用清单后面实操会用到。至少包括-d后台运行、--name命名、-p端口映射、-v挂载数据卷、-e环境变量、--restart重启策略。这些参数不是随手加的每一个都对应一种部署需求第 5 节会展开演示。4. 仓库的全貌Docker Hub、标签与私有仓库4.1 仓库和镜像名的完整结构在使用层面仓库的核心是镜像的命名和寻址。一个完整镜像名通常长这样nginx:1.25或registry.example.com/team/app:2.1.0。冒号后面是标签斜杠左边是仓库地址斜杠右边是镜像名。如果省略仓库地址默认指向 Docker Hub省略标签默认是 latest。docker pull nginx实际上等于docker pull docker.io/library/nginx:latest。这个细节平时感知不到但当你配置了 registry mirror、或者推送镜像到私有仓库时就必须把完整地址写明白。比如推送到公司内网的仓库命令是docker push registry.example.com/team/app:2.1.0这里的registry.example.com就是仓库服务地址Docker 会依据这个地址决定往哪里认证、往哪里推。4.2 标签管理版本控制的关键标签是镜像的版本标识但很多人对标签的使用非常随意。最常见的问题是滥用 latest。latest 只是一个会移动的指针指向最新推送的镜像不代表任何稳定语义。团队里如果拉镜像时都用 latest线上环境很容易被一次误推送悄悄改变行为等发现时已经很难定位是哪个版本造成的。我的建议是只要不是本地临时测试一律使用明确版本标签格式可以参考语义化版本如1.2.3、2.1.0-rc.1。标签还有一个容易踩的坑删除镜像时按标签删但两个不同标签可能指向同一个镜像 ID。docker rmi某个标签只是把这个标签从镜像上摘掉如果另一个标签还指向同一镜像镜像本体仍在。处理悬空镜像dangling image没有标签的镜像时用docker image prune清理更省心它会一次性删掉所有不再被任何标签引用的镜像层。4.3 镜像加速与私有仓库部署经验公共仓库 Docker Hub 是全球访问的网络状况不好的时候拉取镜像经常卡顿。这里说一个标准做法配置 registry mirror也就是给 Docker 增加一个镜像加速地址它会作为 Docker Hub 的缓存代理帮你更稳定地拉取公共镜像。这是 Docker 官方支持的机制配置方法是在/etc/docker/daemon.json里写registry-mirrors数组改完重启 dockerd。注意配置的是拉取加速不影响推送推送仍然只能推到你登录的、有写权限的仓库这点别搞混。私有仓库方面企业场景推荐用 Harbor 这类开源项目。它本质上是带权限控制、项目管理、镜像复制和安全扫描的仓库服务底层存储还是标准 Registry。部署私有仓库的最大收益不只是镜像不出内网而是团队可以建立自己的镜像命名规范、审批流程和生命周期策略。我的做法是分环境建项目dev 项目放开发镜像prod 项目放发布镜像权限严格分离开发人员只有 dev 项目的读写权限发布镜像由 CI 流水线统一打标签和推送。5. 一次完整的镜像-容器-仓库协作实操5.1 从拉取到运行三分钟走完主流程下面用一个实际场景把三者串起来部署一个带静态页面的 Nginx 服务。先拉取镜像再启动容器修改文件验证效果最后推送到私有仓库。第一步拉取镜像docker pull nginx:1.25。观察输出你会发现它一行一行地Pull complete每一行对应一个层。如果本地已经有部分层输出会显示Already exists这就是分层复用在传输层面的体现。第二步启动容器docker run -d --name web-demo -p 8080:80 -v /opt/html:/usr/share/nginx/html:ro nginx:1.25这条命令的含义要逐段拆解-d表示后台运行--name给容器命名-p 8080:80把宿主机的 8080 端口映射到容器内的 80 端口宿主机 8080 收到请求流量会转给容器里的 Nginx-v把宿主机的/opt/html目录以只读方式挂载到容器内的站点目录这样修改宿主机上的 HTML 文件容器立刻生效不用进容器、不用重启。第三步验证curl 127.0.0.1:8080能看到页面docker ps里能看到运行状态docker logs web-demo能看到请求日志。到这里一个容器就真正跑起来了。整个过程确实三分钟能走完但建议把每一步命令的含义弄清楚后面才能灵活组合出适合自己场景的启动参数。5.2 修改容器后如何反哺镜像容器运行过程中你可能会改配置、装工具。这些改动在容器层容器删除即消失。如果希望这个改完的状态变成一个新镜像执行docker commit就能把容器的当前状态固化成镜像。但我要泼一盆冷水commit 在落地实践中很少直接用于正式镜像因为它会丢失构建历史镜像无法追溯是怎么造的后续维护非常痛苦。正确的做法是把改动写进 Dockerfile 重新构建。你会发现镜像、容器、Dockerfile 三者形成了闭环Dockerfile 构建出镜像镜像启动出容器容器里的验证结果反哺 Dockerfile 的下一步修改。所以实操时我通常用容器做验证把验证通过的变更落回 Dockerfile再构建一个新版本镜像。这个流程刚开始觉得绕习惯后会发现它比 commit 干净太多版本历史全在代码仓库里镜像可审计、可回滚。5.3 推送镜像到私有仓库的完整步骤要让其他人能从仓库拉取你的镜像推送前需要把本机镜像重新打上仓库地址的标签docker tag nginx:1.25 registry.example.com/team/nginx-web:1.0.0 docker push registry.example.com/team/nginx-web:1.0.0推送前一般需要登录docker login registry.example.com输入用户名和密码或访问令牌。推送完成后在另一台机器上执行docker pull registry.example.com/team/nginx-web:1.0.0就能拉取拉下来之后继续docker run启动即可。这里建议关注镜像的完整性校验生产环境最好使用带签名的镜像docker trust相关命令可以查看签名信息保证从构建到部署的链路里镜像内容没有被中间环节篡改。整套流程跑一遍你就理解了镜像、容器、仓库是怎么互相配合的仓库是镜像的存储和分发中心镜像从仓库出来变成容器承载业务容器验证后的修改又通过 Dockerfile 形成新镜像回到仓库等待下一轮分发。这个循环就是一个团队日常交付的缩影。6. 常见问题与排查技巧实录6.1 拉取镜像超时或失败拉取卡住是新手最常见的拦路虎输出通常是connection refused、timeout或i/o timeout。先别急着怀疑网络环境出了问题大概率是默认仓库地址访问不稳定。按第 4 节说的 registry mirror 方式配置加速然后重启 Docker 服务再试。另外一个低级但高频的原因镜像名拼错了或者标签不存在docker pull会返回manifest not found。排查时先确认镜像名和标签是否正确、是否存在。6.2 容器启动后秒退docker run之后容器立刻退出docker ps看不到docker ps -a能看到 Exited。秒退的原因通常是前台进程没有持续运行。Nginx 这类服务天然前台运行没问题但如果你跑的是一个脚本执行完就退出容器自然就停了。解决办法是让启动命令保持前台比如用tail -f /dev/null占位或者确保 CMD 启动的是真正需要长驻的服务进程。排查时最有效的动作是docker logs 容器ID看清楚退出前打印了什么。常见还有两种情况启动命令里依赖的环境变量没传程序起不来挂载目录权限不对进程没权限读文件直接退出。这两个都可以在日志里看到明确报错修复参数后重新启动即可。我把这段时间遇到的问题整理了一张速查表方便对照现象大概率原因排查手段解决方向拉取超时仓库访问不稳定看输出中的超时类型配置 registry mirrormanifest not found镜像名或标签错误核对完整镜像名用正确标签重新拉取容器秒退前台进程退出docker logs 看退出日志调整启动命令保持前台环境变量缺失启动失败运行时配置不完整查看 logs 报错项补 -e 参数或用 env 文件挂载目录权限拒绝宿主机目录权限不当检查进程报错和目录权限调整属主或挂载只读镜像体积膨胀层内残留临时文件docker history 查看每层大小合并 RUN、清理缓存、多阶段构建6.3 镜像体积失控镜像体积越来越大的时候优先查这几处有没有把构建缓存、日志、临时安装包留在镜像里依赖层有没有重复安装基础镜像是不是选了体积巨大的带桌面环境的发行版。解决办法包括在同一 RUN 里清理临时文件、使用体积更小的基础镜像比如固定版本的精简发行版或 alpine 系、用多阶段构建不要把编译工具链带进最终镜像。这些手段组合使用一个几百 MB 的镜像压到几十 MB 很常见。这里补充一个判断层体积的小工具视角docker history 镜像名会按层展示每条指令及对应大小。哪一层异常膨胀一眼就能看出来比瞎猜高效得多。多阶段构建则是更彻底的手段第一个阶段装全套编译工具把源码编成产物第二个阶段只 COPY 产物进精简运行环境编译工具链那一大坨完全留在中间镜像里不进最终产物。6.4 仓库认证与权限问题推送私有仓库时报denied: requested access to the resource is denied十有八九是没登录或者当前用户对该项目没有写权限。先docker login确认身份再检查推送的镜像名是否带全了仓库地址和项目名。还有种情况仓库服务地址配置了 TLS 证书本机用了自签证书Docker 默认不信任会报证书相关错误需要在 daemon.json 里将该仓库地址加入insecure-registries配置或者在客户端配置信任证书。生产环境我建议直接用受信任的 CA 证书别图省事开 insecure否则每次架构调整都会埋雷。除了上面这些还有个习惯想分享排查容器问题时永远先看日志再看配置最后才怀疑内核和网络。很多时候问题出在我们自己对参数的理解而不是 Docker 本身。把docker inspect输出的 JSON 翻一翻镜像的完整配置、容器的挂载和端口映射、重启次数全在里面这是排查时的第一手资料比到处搜报错更可靠。我个人这几年和 Docker 打交道的最大体会是镜像、容器、仓库这三个词表面上是三个名词实际是一条完整链路上的三个环节。谁要是能把从 Dockerfile 构建镜像、从镜像启动容器、从容器验证回推 Dockerfile、把镜像推送到仓库再拉取到新机器这组动作打通Docker 在你手里就不再是几个零散命令而是一套可以信任的交付流水线。后面再遇到复杂场景比如多容器编排、镜像安全扫描、仓库高可用都会因为这三个底子打得牢而事半功倍。