1. 这不是教科书是我在生产环境里踩过坑后写的Docker名词手册你打开 Docker Desktop看到“Containers”“Images”“Volumes”“Networks”这些词是不是像看天书点开一个容器日志满屏Exited (137)、OOM killed、port already in use却不知道哪个词对应哪类问题我刚接触 Docker 时也这样——背了一堆定义一上线就懵为什么镜像拉不下来为什么容器启动后立刻退出为什么宿主机能连 Redis但另一个容器连不上后来我才明白Docker 不是学出来的是用错十次、查二十遍文档、重启三十次服务之后才真正理解每个词背后的真实重量。这第2招不讲安装、不跑 hello-world就干一件事把 Docker 里那些被反复提起、却没人说透的专有名词掰开揉碎还原成你在真实项目里每天打交道的“活物”。比如“镜像”不是静态文件而是分层缓存元数据执行上下文的组合体“容器”不是进程封装而是 Linux Namespace Cgroups Rootfs 的一次精准快照“Registry”不是网盘而是带鉴权、带策略、带 GC 机制的镜像仓库系统。我们还会直击三个高频痛点场景为什么你本地docker build成功CI/CD 流水线却报failed to solve with frontend dockerfile.v0为什么docker-compose up启动了 MySQL 和 PHP但 PHP 总提示Connection refused为什么用--network host能通换回bridge就断而加了--add-host又莫名其妙失效这些都不是配置写错了而是你对network mode、DNS resolution order、container networking scope这些概念的理解还停留在字面意思。本招会用真实命令输出、实际错误日志、线上拓扑截图文字还原和我亲手画的内存/磁盘/网络三维度资源流向图带你建立一套可验证、可调试、可迁移的 Docker 认知框架。适合所有已经装好 Docker Desktop、能跑起第一个容器但一进复杂项目就卡壳的开发者、运维、测试和 DevOps 工程师。2. Docker 专有名词不是术语表是故障排查地图Docker 的专有名词体系本质是一张“资源生命周期地图”。它不按字母排序而按你排障时的实际路径组织从你敲下docker run开始到容器崩溃结束每一步都对应一个核心名词。我把它们分成三组构建态名词Build-time、运行态名词Run-time、协同态名词Orchestration-time。这不是教科书分类而是我过去三年在金融、电商、AI 推理平台三个领域累计处理 472 起 Docker 相关故障后总结出的最贴近实战的归因逻辑。2.1 构建态名词镜像不是“打包”是“分层快照链”很多人以为docker build就是把代码依赖打成一个压缩包。错。镜像是由Layer层 Manifest清单 Config配置 Image ID摘要四部分构成的不可变实体。关键在于Layer 是只读的、可复用的、按顺序叠加的文件系统快照。举个真实例子你写了一个DockerfileFROM python:3.9-slim COPY requirements.txt . RUN pip install -r requirements.txt # ← 这行生成一个 layer COPY . . CMD [python, app.py]执行docker build -t myapp .后Docker 实际做了什么先拉取python:3.9-slim镜像它本身包含 5 层OS 基础、Python 运行时等COPY requirements.txt .创建第 6 层仅含该文件RUN pip install创建第 7 层所有 Python 包约 200MBCOPY . .创建第 8 层你的源码假设 5MB最终myapp镜像 ID 是这 8 层 SHA256 摘要拼接后的哈希值。提示docker history myapp命令会清晰列出每一层的大小、创建命令和时间戳。你会发现pip install那层最大且修改requirements.txt后重建只有第 6、7 层会变前 5 层完全复用——这就是 Docker 缓存加速的本质不是“跳过”而是“命中缓存层”。为什么这重要因为线上 CI/CD 报错failed to solve with frontend dockerfile.v090% 是 Layer 缓存失效或 Registry 权限导致某一层拉取失败。比如你用了私有 Registry但没配docker loginFROM private-registry.com/base:latest这一行就会卡住后续所有 Layer 都无法构建。解决方案不是重写 Dockerfile而是先docker pull private-registry.com/base:latest验证权限再docker build --no-cache强制重建——这是我在某银行 AI 模型部署平台踩过的坑当时花了 3 小时才定位到是内网 Registry 的 TLS 证书过期。另一个高频陷阱“镜像体积太大推送超时”。新手常COPY . .把.git、__pycache__、node_modules全塞进去。正确做法是用.dockerignore文件不是.gitignore内容必须显式声明.git __pycache__ *.pyc node_modules .env实测某 NLP 服务镜像从 1.2GB 降到 320MB推送时间从 18 分钟缩短到 2 分钟。.dockerignore是构建态的第一道防火墙它决定哪些文件永远不进入 Layer比RUN rm -rf更彻底——后者只是在新 Layer 里删旧 Layer 还在镜像里。2.2 运行态名词容器不是“进程”是“隔离环境实例”docker run启动的不是一个进程而是一个Namespace 隔离空间 Cgroups 资源限制 Rootfs 文件系统 Init 进程PID 1的组合体。四个要素缺一不可任何一个出问题容器就“假死”或“真崩”。Namespace提供视图隔离。pidnamespace 让容器内只看到自己的进程netnamespace 给容器独立的网络栈IP、端口、路由表mntnamespace 控制挂载点可见性。典型问题docker run --network host下容器直接使用宿主机网络netnamespace 被绕过所以localhost指向宿主机而非容器自身——这就是为什么用 host 网络时PHP 连localhost:3306是连宿主机 MySQL而不是同 compose 网络里的 MySQL 容器。Cgroups提供资源硬限。--memory512m不是“建议用 512MB”而是“超过就 OOM kill”。--cpus1.5表示最多占用 1.5 个 CPU 核心的计算时间片。某次线上事故AI 推理服务容器设了--memory2g但模型加载峰值内存达 2.3GB容器被 kernel OOM killer 杀掉日志只显示Exited (137)。查dmesg -T | grep -i killed process才看到 OOM 记录。解决方案不是调大内存而是用--memory-reservation1.5g设软限让容器在内存紧张时主动降级而非突然死亡。Rootfs容器的根文件系统。它由镜像 Layer 叠加而成但运行时是Copy-on-WriteCoW机制——容器启动后所有写操作都在最上层可写层Container Layer进行底层只读 Layer 不变。这也是docker commit能生成新镜像的原理把可写层打包成新 Layer。但副作用是频繁写日志、临时文件会导致可写层膨胀。某电商订单服务每天生成 5GB 日志一周后容器体积涨到 15GBdocker ps -s显示SIZE列暴增。解决方法用docker run -v /app/logs:/logs挂载宿主机目录让日志写到 Volume避开 CoW 层。Init 进程PID 1容器内 PID 为 1 的进程负责信号转发和僵尸进程回收。如果CMD [python, app.py]启动的 Python 不是前台进程比如后台 daemon 模式PID 1 就会退出整个容器立即终止。正确做法用CMD [python, -u, app.py]加-u参数强制 stdout/stderr 无缓冲或用tini作为 initENTRYPOINT [tini, --]。我在青龙面板部署时就栽在这儿npm start启动的 Node.js 默认后台运行容器秒退加了tini后稳定运行 6 个月。2.3 协同态名词网络与卷不是配置项是服务契约当多个容器协同工作如 MySQL PHP Nginxdocker network和docker volume就成了服务间约定的“契约”。它们定义了“谁可以访问谁”和“数据存在哪儿”一旦契约破坏整个系统就失联。NetworkDocker 默认bridge网络是私有子网如172.17.0.0/16每个容器分配一个 IP通过docker0网桥通信。但关键细节是容器间通信必须用容器名DNS 名或 IP不能用localhost。因为localhost在容器内指向自己不是其他容器。docker-compose.yml中services: db: image: mysql:8.0 networks: - app-net web: image: php:8.1-apache networks: - app-net depends_on: - db这里web容器里连 MySQL必须写mysql://db:3306db是服务名Docker 内置 DNS 自动解析写mysql://localhost:3306必然失败。某次交付客户坚持用localhost我花 2 小时说服他改配置——不是技术不行是契约意识没建立。Volume是 Docker 管理的持久化存储与 Bind Mount宿主机目录映射有本质区别。Volume 由 Docker 创建在/var/lib/docker/volumes/下有独立生命周期docker volume rm才删除支持跨容器共享。Bind Mount 是直接映射宿主机路径权限、路径存在性全靠人工保证。生产环境必须用 Volumedocker run -v mydata:/data nginx而不是docker run -v /host/data:/data nginx。后者一旦宿主机/host/data权限不对如 root 写nginx 用户读Nginx 就启动失败报错open() /data/index.html failed (13: Permission denied)。用 VolumeDocker 自动处理权限且升级镜像时数据不丢失。Registry不只是“镜像仓库”而是带策略的分发中心。公有 RegistryDocker Hub有速率限制未登录用户 100 次/6 小时私有 RegistryHarbor支持项目级权限、漏洞扫描、GC 策略。某次凌晨发布CI 流水线批量拉取基础镜像触发 Docker Hub 限流所有构建失败。紧急方案在 Harbor 部署mirror代理把docker.io请求转到 Harbor再由 Harbor 缓存并分发——这才是 Registry 的真实角色流量调度器安全守门员。3. Docker 核心架构不是抽象图是资源调度流水线Docker 的架构常被画成 Client-Server-Daemon 三层图但这掩盖了真正的复杂性。实际生产中Docker 是一条“用户指令 → 客户端解析 → Daemon 调度 → Runtime 执行 → Kernel 支撑”的五级流水线。每一级都有单点故障可能而故障现象往往指向错误层级。下面用docker run -d --name nginx-test nginx:alpine这条命令逐级拆解真实执行路径。3.1 第一级CLI 客户端 —— 指令翻译器docker命令行工具不是简单发 HTTP 请求它先做三件事参数校验检查--name是否重复docker ps -a | grep nginx-test检查镜像名格式nginx:alpine符合repo:tag规则上下文准备若命令含.如docker build .自动打包当前目录为 tar 流API 版本协商向 Daemon 发送/version请求确定双方支持的 API 版本如v1.41避免版本不兼容。常见问题docker: buildx is not a docker command.原因buildx是插件需docker buildx install。但更深层是 CLI 无法加载插件二进制。解决方案下载docker-buildx二进制到~/.docker/cli-plugins/并chmod x。这不是 Docker 本身问题是客户端生态管理缺失。3.2 第二级Docker Daemon —— 资源总调度台Daemondockerd进程是核心大脑它监听/var/run/docker.sockUnix socket接收 CLI 请求并协调所有后端组件。它的关键职责是镜像管理从 Registry 拉取镜像解压 Layer存入/var/lib/docker/image/容器编排调用 containerd 创建容器传递 OCI SpecJSON 格式运行时配置网络配置调用docker0网桥驱动为容器分配 IP设置 iptables 规则卷管理调用 local volume driver创建目录设置权限。致命故障Virtualization support not detected. Docker Desktop failed to start because V.这不是 Docker 错误而是 Daemon 启动前的硬件检查失败。Docker Desktop for Windows/macOS 依赖 WSL2 或 HyperKit 虚拟化层。报错意味着WindowsBIOS 中 Intel VT-x/AMD-V 未开启或 Hyper-V/WSL2 功能未启用macOSApple Silicon 芯片需 Rosetta 2 运行 x86 镜像但 Rosetta 2 未安装。解决方案不是重装 Docker Desktop而是Windows 运行wsl --installmacOS 运行softwareupdate --install-rosetta。Daemon 启动失败90% 是前置依赖未就绪。3.3 第三级containerd —— 容器生命周期管家Docker Daemon 不直接操作容器而是通过 gRPC 调用 containerd一个符合 OCI 标准的容器运行时。containerd 负责镜像解包将镜像 Layer 解压到/var/lib/containerd/io.containerd.content.v1.content/容器创建生成config.jsonOCI 运行时规范调用 runc 执行进程监控监听容器进程状态上报给 Daemon。典型问题containerd: failed to load plugin io.containerd.grpc.v1.cri这是 containerd 的 CRIContainer Runtime Interface插件加载失败常见于 Kubernetes 环境。但 Docker Desktop 也集成 CRI用于支持docker buildx构建多平台镜像。修复方法sudo systemctl restart containerdLinux或重启 Docker DesktopMac/Win。记住containerd 是 Daemon 和 runc 之间的“翻译官”它挂了所有容器操作都会卡在“Creating”状态。3.4 第四级runc —— Linux 内核调用封装器runc 是 OCI 标准的参考实现它把config.json中的 Namespace、Cgroups、Rootfs 配置翻译成具体的 Linux 系统调用clone()创建新进程传入CLONE_NEWPID|CLONE_NEWNET等 flagmount()挂载 Rootfs 到容器根目录setrlimit()设置资源限制execve()启动用户指定的 CMD 进程。runc本身不处理网络或存储它只管“让进程在隔离环境中跑起来”。因此runc报错几乎全是内核级问题runc create: unable to start container process: exec: sh: executable file not found in $PATH镜像里没有sh但docker run默认用sh -c执行命令runc run: exit status 1: OCI runtime error: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting /proc to rootfs at /proc caused: operation not permitted宿主机 SELinux 或 AppArmor 策略阻止挂载/proc。解决方案前者用docker run --entrypoint /bin/bash nginx:alpine指定入口后者临时禁用 SELinuxsetenforce 0或配置策略模块。3.5 第五级Linux Kernel —— 隔离能力提供者最终一切归于内核四大支柱Namespacespid,net,mnt,uts,ipc,user六种隔离Cgroups v1/v2内存、CPU、IO、PID 数量限制Capabilities细粒度权限控制如CAP_NET_BIND_SERVICE允许绑定 1024 以下端口Seccomp系统调用过滤默认白名单禁用reboot、kill等危险调用。docker run --cap-addNET_ADMIN nginx是给容器添加网络管理能力允许它运行ip route命令。但生产环境严禁滥用--privileged它等于关闭所有隔离容器可直接访问宿主机设备。某次安全审计发现测试环境大量用--privileged跑 Selenium被判定为高危漏洞——因为浏览器渲染引擎漏洞可能逃逸到宿主机。4. Docker 使用场景不是罗列是决策树Docker 的使用场景本质是“在什么约束条件下选择 Docker 解决什么问题”。我把常见场景归纳为一张“四维决策树”横轴是环境复杂度Dev/Test/Prod纵轴是应用形态单体/微服务/AI 模型深度是数据敏感性公开/内部/金融级高度是团队能力脚本化/标准化/自动化。每个节点对应一个真实场景和一套推荐实践。4.1 场景一本地开发环境统一 —— 解决“在我机器上能跑”的诅咒典型症状后端说“数据库连不上”前端说“API 返回 500”运维说“配置文件没错”。根源是环境不一致Mac 上 MySQL 8.0CentOS 上 MySQL 5.7Windows 上 MySQL 容器端口被占。Docker 方案用docker-compose.yml定义完整开发栈。version: 3.8 services: db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: devpass MYSQL_DATABASE: myapp ports: - 3306:3306 volumes: - db-data:/var/lib/mysql redis: image: redis:7-alpine ports: - 6379:6379 api: build: ./backend environment: DB_HOST: db REDIS_HOST: redis ports: - 8000:8000 depends_on: - db - redis volumes: db-data:关键实践所有服务用depends_on声明启动顺序但depends_on不等待服务就绪MySQL 启动要 10 秒所以 API 代码里必须加重试逻辑如while ! nc -z db 3306; do sleep 1; done数据库密码用environment明文写在 Compose 文件里仅限本地开发生产环境必须用docker secret或外部 Vaultports暴露宿主机端口方便浏览器访问http://localhost:8000但禁止在生产环境用ports改用ingress网络或反向代理。我团队的标准流程新人入职git clone项目后只需docker-compose up -d5 分钟内获得完整可运行环境。比手动装 Python、Node.js、MySQL、Redis 快 10 倍且 100% 一致。4.2 场景二CI/CD 流水线标准化 —— 解决“测试通过上线就崩”的魔咒典型症状GitLab CI 跑单元测试通过但部署到测试环境后import pandas报错ModuleNotFoundError。原因是 CI runner 用的是python:3.9镜像而本地开发用python:3.9-slim后者缺少gcc编译器pandas的 C 扩展无法编译。Docker 方案CI 流水线全程使用与生产一致的镜像。# .gitlab-ci.yml stages: - build - test - deploy build-image: stage: build image: docker:stable services: - docker:dind script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG test: stage: test image: $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG # ← 关键用刚构建的镜像跑测试 script: - pytest tests/关键实践image: docker:stable是 CI runner 镜像它自带 Docker CLI通过docker:dindDocker-in-Docker服务获得构建能力test作业的image直接引用build-image构建的镜像确保测试环境 100% 复现生产环境避免在test作业里pip install -r requirements.txt因为这会引入与镜像不一致的依赖版本。某金融科技项目我们用此方案将线上故障率从 32% 降至 1.7%。根本原因是以前测试用pip install线上用docker run现在两者用同一镜像差异归零。4.3 场景三AI 模型推理服务化 —— 解决“模型跑不通”的黑洞典型症状PyTorch 训练好的模型在服务器上torch.load()报错OSError: [Errno 2] No such file or directory。原因是训练环境 CUDA 11.3服务器 CUDA 11.8torch版本不兼容。Docker 方案为每个模型定制 GPU 镜像固化 CUDA cuDNN PyTorch 版本。# FROM nvidia/cuda:11.3.1-devel-ubuntu20.04 FROM nvidia/cuda:11.3.1-devel-ubuntu20.04 RUN apt-get update apt-get install -y python3-pip rm -rf /var/lib/apt/lists/* RUN pip3 install torch1.10.0cu113 torchvision0.11.1cu113 -f https://download.pytorch.org/whl/torch_stable.html COPY model.pth /app/ COPY inference.py /app/ CMD [python3, /app/inference.py]关键实践基础镜像必须用nvidia/cuda:xx.x-devel非runtime因为devel包含编译工具链runtime只含运行时库torch安装必须指定cu113后缀匹配 CUDA 版本否则import torch会段错误模型文件model.pth用COPY而非VOLUME因为模型是只读的挂载卷反而增加 I/O 开销。我们部署 Qwen2-VL 多模态模型时用此方案在 4 台 A10 显卡服务器上支撑 200 QPS 图文理解请求平均延迟 86ms。关键在于镜像固化了transformers4.35.0、torch2.1.0cu118、cuda-toolkit11.8三者的精确版本组合杜绝了版本漂移。4.4 场景四遗留系统容器化迁移 —— 解决“不敢动”的困局典型症状Java Web 应用跑在 Tomcat 7 JDK 7 上客户要求迁移到云平台但源码丢失无法重构。Docker 方案用docker commit将物理机环境“快照”为镜像。在旧服务器上安装 Dockerdocker run -it --name legacy-tomcat centos:7 /bin/bash手动复制 Tomcat 目录、JDK、应用 WAR 包到容器内docker commit legacy-tomcat mycorp/legacy-app:1.0docker run -d -p 8080:8080 mycorp/legacy-app:1.0。关键实践docker commit是最后手段仅用于无法获取源码的黑盒系统必须在commit前docker export容器文件系统生成 tar 包备份防止镜像损坏启动时加--ulimit nofile65536:65536因为老应用常开大量文件句柄监控用docker stats查 CPU/内存而非top因为top在容器内看到的是宿主机全局视图。某政务系统迁移我们用此法将 12 年历史的 Java 应用容器化上线后 0 故障运行 18 个月。虽然不优雅但它是业务连续性的最优解。5. 常见问题与排查技巧实录不是问答是故障时间线Docker 问题排查不是查文档而是按时间线回溯从你敲下命令开始到结果出现每一步的日志、状态、返回值都是线索。我把高频问题整理成“五步定位法”1. CLI 输出 → 2. Daemon 日志 → 3. containerd 日志 → 4. runc 日志 → 5. Kernel 日志。下面用三个真实案例演示。5.1 案例一docker run启动后立即退出日志为空现象docker run -d --name test nginx:alpinedocker ps看不到容器docker ps -a显示Exited (0)。五步定位CLI 输出docker run返回容器 ID说明 Daemon 接收成功Daemon 日志sudo journalctl -u docker.service | tail -20无错误containerd 日志sudo journalctl -u containerd | tail -20发现msgCreateContainer within timeoutrunc 日志sudo journalctl | grep runc空Kernel 日志dmesg -T | tail -10看到Out of memory: Kill process 12345 (nginx) score 123 or sacrifice child。根因宿主机内存不足OOM killer 杀掉了 nginx 进程。Exited (0)是 nginx 主进程正常退出但被 kernel 强制终止。解决方案docker run --memory512m nginx:alpine限制内存或free -h查宿主机内存释放空间。注意docker ps -a的STATUS列中(0)表示进程 exit code 0成功(137)表示被 signal 9kill终止(139)表示 segmentation fault。记住这三个码比查日志更快。5.2 案例二docker-compose up启动 MySQLPHP 容器连不上现象docker-compose up -d后docker exec -it web curl -v http://db:3306返回Empty reply from server。五步定位CLI 输出Creating network myapp_default with the default driver网络创建成功Daemon 日志无异常containerd 日志msgStartContainer idabc123MySQL 容器启动runc 日志msgexecuting setuid/setgid to root:rootMySQL 进程启动Kernel 日志无 OOM。深入排查docker exec -it db netstat -tlnp | grep :3306发现 MySQL 监听127.0.0.1:3306而非*:3306查 MySQL 配置docker exec -it db cat /etc/mysql/my.cnfbind-address 127.0.0.1。根因MySQL 默认只监听 localhost容器内127.0.0.1是自身不是宿主机。解决方案在docker-compose.yml中覆盖配置db: image: mysql:8.0 command: --bind-address0.0.0.0或挂载自定义配置文件volumes: - ./my.cnf:/etc/mysql/conf.d/bind.cnf。实操心得容器内服务的监听地址必须是0.0.0.0所有接口或::IPv6 所有接口绝不能是127.0.0.1。这是网络通信的黄金法则。5.3 案例三Docker Desktop 启动失败报virtualization support not detected现象Windows 10 上双击 Docker Desktop弹窗报错日志显示Failed to start WSL2 backend。五步定位CLI 输出无GUI 启动失败Daemon 日志journalctl -u docker-desktopError: WSL2 distro not foundcontainerd 日志未启动runc 日志未启动Kernel 日志dmesg无相关。深入排查wsl -l -v返回No distributions installed.wsl --install提示Windows Subsystem for Linux has been installed.wsl -l -v显示Ubuntu-20.04 Running重启 Docker Desktop成功。根因WSL2 未安装或未启用。Docker Desktop for Windows 依赖 WSL2 作为 Linux 内核层不是可选组件。解决方案管理员权限 PowerShell 运行wsl --install若已安装但未启用运行wsl --updateBIOS 中确认 Intel VT-x/AMD-V 开启。注意不要卸载重装 Docker Desktop99% 的启动失败是 WSL2 或 Hyper-V 问题。先查wsl -l -v再查bcdedit /enum | findstr hypervisor。6. 我的 Docker 认知进化史从“能跑”到“敢用”的三次顿悟第一次顿悟是在 2020 年我用docker run -p 80:80 nginx部署静态网站觉得 Docker 就是“高级 zip”。直到客户问“怎么让两个 nginx 共享同一个 SSL 证书”我才意识到volume不是目录映射而是跨容器的数据契约——我把证书放到nginx-certvolume两个 nginx 容器都挂载它问题解决。那一刻我明白了Docker 的价值不在封装而在定义服务间的边界。第二次顿悟是在 2022 年CI 流水线频繁失败日志显示pull access denied。我查 Registry 权限发现是 Docker Hub 的匿名拉取限额。我部署了 Harbor配置了镜像代理和自动 GC还写了脚本定期清理未使用的镜像。
； 这个s1称为什么，存储在什么位置？)
