前两天有同事问起 DCA 到底值不值得考，我翻了翻手里那本已经翻出毛边的培训笔记，发现这话题确实值得好好写一篇。DCA 全称是 Docker Certified Associate，是容器领域里比较有代表性的认证考试。我当时考它，目标很实际：把脑子里零散的容器知识系统化，顺带给自己一个可量化的学习节点。这个认证覆盖面很广，镜像构建、容器编排、网络存储、安全边界全都有，但它考得并不浮夸，更多是考察你日常会不会用、出了问题能不能快速定位。如果你刚接触容器技术，或者已经用了半年但还在靠复制粘贴命令过日子，这篇笔记应该能帮上忙。我尽量不写让人犯困的理论，直接按培训和备考的经验记录来整理，命令、坑、排查思路都放在里面。
1. DCA认证要想清楚的三件事
1.1 认证到底考什么：考试模块与比例
DCA 考试覆盖六个方向，按我当时拿到的考点大纲来看，大致比例是这样的：
- 编排（Orchestration）约 25%，主要涉及 Swarm 集群、Service、Stack 这些概念。
- 镜像创建、管理与仓库操作约 20%，核心是 Dockerfile 的编写和镜像仓库的使用。
- 容器安装与应用生命周期管理约 20%，包含容器启停、资源限制、监控日志。
- 网络约 15%，包括默认网络、端口映射、自定义网络、跨节点通信。
- 存储约 10%，考察 Volume、Bind Mount、临时存储的使用场景。
- 安全约 10%，涉及权限收敛、只读文件系统、内核能力约束、镜像信任机制。
这个分布说明一件事：DCA 不是深挖底层内核的硬核考试，而是把工程实践中最高频的那部分知识拎出来考。它的题型以场景化选择题为主，题目会给你一个具体的使用场景，比如“生产环境某个容器频繁被系统杀掉，你第一反应查什么”，然后让你判断最合理的答案。这种考法比单纯背概念要实用得多，因为题目描述的场景你日常工作里真的会遇到。
我对这个考试的评价是：它不简单，但也绝不至于悬在云端。只要动手练过，把命令用熟、把原理讲明白，通过是水到渠成的事。最怕的就是只刷题库不实际操作，那样遇到稍微换了个说法的场景题就会懵。
1.2 备考优先级：四周复习节奏
如果把备考周期拉成一个月，我的建议是按照掌握程度分层推进。第一周先把考试大纲过一遍，同时把镜像和容器的生命周期命令跑熟，这是后面所有模块的地基。第二周的精力砸在 Dockerfile 上，因为镜像构建既是考试重点，也是以后日常工作里写项目的基础能力。第三周主攻网络、存储、安全和 Compose，这部分概念比较多，适合集中记忆再加动手实验。第四周做模拟自测，把薄弱点拎出来单独练。
优先级上我个人的排序是这样：Dockerfile 和 Compose 的优先度最高，因为它们是“主菜”；其次是容器生命周期命令，这是“基本功”；再次是网络和存储，这是“难点”；最后是 Swarm 和安全概念，可以放在通关后加强。按这个顺序复习，即使时间不够，也能保证核心得分点不掉链子。
这里有个容易忽略的细节：很多人在准备时会把大量时间花在背 Swarm 命令上，但实际考试里 Swarm 更多是考概念，比如 manager 和 worker 的区别、service 的滚动更新策略。反倒是 Compose 这种每天都要用的工具，考试里出现频繁，而且常常穿插到网络、存储、环境变量这些跨模块场景里。复习时一定要给 Compose 留够时间。
2. 考点拆解：把培训笔记压缩成可执行要点
2.1 容器与镜像生命周期
镜像和容器的关系，我用一个老掉牙但很形象的比喻：镜像是安装盘，容器是装完系统并开机运行的机器。镜像是只读模板，容器是运行实例。你对容器做任何修改，只要没有显式提交成新镜像，就不会影响镜像本身。
生命周期相关的命令是每天都要碰的，我整理了一份高频清单：
# 拉取镜像 docker image pull nginx:1.25 # 运行容器，-d 后台运行，--name 取名，-p 端口映射 docker container run -d --name web -p 8080:80 nginx:1.25 # 查看运行中容器和全部容器 docker container ps docker container ps -a # 进入容器执行命令 docker container exec -it web bash # 查看日志 docker container logs --tail 50 web # 停止、启动、强制删除 docker container stop web docker container start web docker container rm -f web有个细节很多人一开始会搞混：docker run和docker create加docker start的关系。docker create只是基于镜像创建容器，不启动；docker start启动一个已存在的容器；docker run则相当于把创建和启动合并成一步操作。考试里喜欢在这个点上做文章，给你一个场景问“哪个命令只创建不启动”。
容器退出状态码也需要留个心眼。很多排查场景里，第一步不是看日志，而是看docker ps -a里容器的退出码。0 代表正常退出，1 代表应用内部报错，137 意味着进程被强制杀掉，常见于内存超限触发系统 OOM，126/127 则是命令无法执行或找不到命令。这些码在后面的排查部分我还会细说。
2.2 Dockerfile 与镜像构建
Dockerfile 是镜像构建的蓝图，也是整个 DCA 考试里我最推荐的投入方向。它不复杂，但细节很多。一个典型的多阶段构建示例：
FROM nginx:1.25-alpine AS runtime COPY --from=build /app/dist /usr/share/nginx/html EXPOSE 80 HEALTHCHECK --interval=30s --timeout=3s \ CMD wget -qO- http://localhost/ || exit 1构建指令里，FROM指定基础镜像，RUN在构建层执行命令，COPY把本机文件复制进镜像，CMD声明容器启动时的默认命令。这里最容易被问倒的是CMD和ENTRYPOINT的区别：CMD可以被docker run后面的参数覆盖，ENTRYPOINT则定义了容器启动时的主进程入口，如果两者同时存在，CMD的内容会作为参数传给ENTRYPOINT。这个设计不少人一开始理解起来很绕，但考试一定绕不开。
镜像分层是理解构建缓存的关键。每条会产生文件系统变更的指令都会生成一个新层，Docker 构建时会检查本层内容和上层缓存是否一致，一致就复用缓存，不一致就重新执行。COPY和RUN的顺序会影响缓存命中率。把不常变化的基础依赖放在 Dockerfile 前面，把频繁变化的业务代码放在后面，构建速度会有质的提升。
构建上下文也需要重视。docker build会把当前目录打包发给守护进程，如果目录里有 node_modules、target 这类大目录，每次构建都很慢。解决方式是在项目根目录放一个.dockerignore文件，语法和.gitignore类似，把不相关的目录排除掉，这算是新手最容易忽略的性能优化点。
2.3 存储：数据该放哪里
容器本身是临时性的，一旦删除，容器内部的文件系统也跟着没了。要让数据活过容器生命周期，就得靠存储挂载。DCA 考的存储分三种：Volume、Bind Mount、tmpfs。
Volume 是 Docker 管理的持久化存储，数据存放在 Docker 数据目录下，推荐在有状态服务里使用。Bind Mount 直接把宿主机路径挂载进容器，适合开发和调试，比如把本地代码目录挂载进去做热更新，但它的缺点是权限管理完全依赖宿主机的目录权限，容器内用户很容易遇到权限问题。tmpfs 是内存里的临时文件系统，容器停止数据就消失，适合放临时缓存、锁文件这类不要求持久的内容。
下面这张表是我备考时自己整理的，基本覆盖了三种存储的核心差异：
| 存储方式 | 数据存放位置 | 生命周期 | 典型使用场景 |
|---|---|---|---|
| Volume | Docker 托管目录 | 随容器删除仍存在，手动清理才删除 | 数据库数据、应用持久化配置 |
| Bind Mount | 宿主机任意路径 | 容器删除不影响 | 开发调试、日志收集、配置文件注入 |
| tmpfs | 容器内存 | 随容器停止消失 | 临时缓存、sockets、密钥的临时存放 |
数据卷的备份和迁移也是个考点，常用的方式是用一个临时容器挂载 volume 然后打 tar 包。命令大概是docker run --rm --volumes-from 数据库容器 -v 宿主机目录:/backup alpine tar cvf /backup/backup.tar /数据目录。这种操作方式在实际项目里出现过很多次，考试描述成“在不停止业务容器的情况下备份数据”也很常见。
2.4 网络：容器之间怎么通信
默认情况下，Docker 会为每个容器分配一个虚拟 IP，所有容器通过一个叫 bridge 的默认网络互相通信。端口映射的写法是-p 宿主机端口:容器端口，比如-p 8080:80就是把宿主机的 8080 端口转发到容器的 80 端口。有个细节容易踩坑：容器内应用监听的地址必须是0.0.0.0，如果只监听127.0.0.1，端口映射是无法从外部访问的。
自定义网络是备考重点。创建一个自定义网络后，同一网络里的容器可以直接通过容器名互相访问，不用关心 IP 地址。原因是 Docker 内置了 DNS 解析，只要你把容器放到同一个自定义网络中，容器名就是一个可用主机名。这个特性在 Compose 编排多服务时尤为关键。
网络模式有几种，bridge 是默认模式，适合单机多容器互通；host 模式让容器直接复用宿主机网络栈，性能好但端口隔离弱；none 模式完全不配置网络，适合做离线计算任务。考试常问的就是“端口映射用哪种模式”“跨主机通信依赖哪个组件”，答案分别是 bridge 和覆盖网络。
实际项目里，我几乎不会依赖默认网络里的 IP 地址进行通信，因为容器重建后 IP 会变。正确做法是创建一个自定义网络，然后靠容器名互相访问。这个思路考试会换各种方式反复问，理解透了基本不会丢分。
2.5 编排：从 Compose 到集群服务
Compose 用声明式配置文件把多个容器编织成一个整体服务栈。一个最小可用的编排文件长这样：
services: web: image: nginx:1.25 ports: - "8080:80" depends_on: - api restart: always api: image: demo-api:latest environment: - DB_HOST=db networks: - app-net db: image: postgres:16 volumes: - pgdata:/var/lib/postgresql/data networks: - app-net networks: app-net: volumes: pgdata:Compose 里最有价值的概念是depends_on，它用来表达服务之间的启动依赖。但要注意，它只决定启动顺序，不保证依赖服务已经进入“可用状态”。生产环境通常需要配合健康检查或者重试机制，让应用在依赖服务真正就绪之后才对外提供流量。考试喜欢拿这一点设计迷惑选项，识别出“准备就绪状态”和“进程已启动”之间的差别就能避开坑。
Swarm 是集群层的编排工具，涉及的概念有 manager 节点、worker 节点、service 服务、stack 应用栈。核心命令是docker swarm init初始化集群，docker service create创建服务，docker service scale动态扩缩容，docker service ls查看集群服务，docker stack deploy把 Docker Compose 文件部署成集群服务。Swarm 在考试里占比不小，但考得比较表面，把每个命令的职能记清楚，再用几台实验机实际拉一遍，基本就稳了。
2.6 安全与资源限制：守住边界
DCA 的安全考点强调的不是高深原理，而是日常就能用的加固手段。核心思路是“最小权限”。在docker run时通过--user指定非 root 用户运行进程，可以避免容器内应用以最高权限执行危险操作。--read-only把根文件系统挂载为只读，程序只能往显式声明的数据卷写入，遇到恶意写文件的场景能挡住一大片。--cap-drop ALL再按需--cap-add可以精确控制 Linux capabilities，这比单纯依赖用户权限更细。
资源限制也是高频考点。默认情况下容器可以吃光宿主机所有 CPU 和内存，这对生产环境是致命威胁。运行容器时加上--memory 512m --cpus 0.5就能限制内存和 CPU 配额。运行中的容器也可以用docker update --memory 256m --cpus 0.5 容器名调整限制，不用重建容器，这个细节考试偶尔会考。
容器日志和监控属于日常运维的基本功。docker stats查看实时资源占用，docker logs查看应用输出。日志驱动默认是 json-file，会把每个容器的标准输出写入磁盘文件，遇到日志量大的服务，要配置日志轮转策略，比如限制单个日志文件大小和文件数量，否则磁盘会悄然被占满。
3. 实操记录：一套能真正跑通的训练路径
3.1 环境搭建与基础验证
备考 DCA 的第一件事不是买教材，而是把环境搭起来。开发机上安装 Docker Desktop 是最省事的方案，装完启动即可。Linux 服务器上则需要安装 Docker Engine，装完启动服务，并确认开机自启。
环境装好之后，先跑三组验证命令。第一组是docker version和docker info，确认客户端和服务端能正常通信。第二组是docker run --rm hello-world，验证能正常拉取镜像并执行容器。第三组是docker network ls，看清楚当前存在的网络列表。这三条命令跑通，说明基础链路没问题。
有一个容易忽略的小事：容器时区。默认情况下，容器使用的是 UTC 时间，而宿主机可能是其他时区。应用日志里看到的时间比实际快八小时，就是这个原因。解决方式是启动容器时通过环境变量注入时区，或者在 Compose 里配置 TZ 环境变量。这个点虽然不起眼，但实际排查中很容易纠结半天。
3.2 训练项目：从单容器到多服务组合
我的建议是不要孤立地记命令，而是搭建一个接近真实的小项目。第一步先跑一个单容器项目：用 Nginx 镜像起一个站点，挂载一个本地目录作为站点根目录，映射端口后调整页面内容，观察容器文件系统里修改文件和挂载目录里修改文件的差异。这一步能把镜像只读层、容器可写层、挂载卷这三层概念一次性讲明白。
第二步处理多容器协作。用 Compose 把数据库服务和应用服务组合起来，应用通过环境变量读取数据库地址。配置完成后执行docker compose up -d拉起来，然后尝试停掉数据库容器，观察应用日志的变化，再恢复数据库，观察服务能否自愈。这个实验会直观理解存活探针、依赖关系和重启策略的价值。
第三步切到 Swarm。用几台实验机器初始化一个 manager 节点，加入 worker，然后创建一个多副本的服务，执行docker service scale看到副本数从 3 变成 5 再从 5 缩回 2，观察任务在节点间的调度过程。这一步跑完，集群编排不再是纸上概念。
再多说一个细节：训练过程中尽量别用docker rm -f把问题容器直接干掉，而是尝试先看日志、再进容器诊断、然后才决定是否删除。这种习惯会让你在真实故障场景里保持冷静，而不是一遇到问题就消灭证据重开一个。
3.3 考前自测：一周检查清单
备考最后一周，我习惯用一张清单做自测，能不看笔记直接写出来的知识点才算是真的掌握：
- 不看文档写出一个含多阶段构建的 Dockerfile。
- 解释
docker run、docker create、docker start三者的区别。 - 说明 Volume 和 Bind Mount 的适用场景，以及数据备份的常用方式。
- 写出创建自定义网络并在其中启动两个容器的完整命令。
- 说明 CMD 和 ENTRYPOINT 的组合规则。
- 用三条命令定位一个反复重启容器的问题。
- 解释
docker compose中depends_on的局限性。 - 说明
--memory、--cpus参数的实际效果。 - 分辨常见的容器退出码如 0、1、126、127、137。
- 描述为容器设置只读根文件系统和降权用户的完整参数。
清单的每一条都对应一组考点，快速检验薄弱点。遇到写不出来的，立刻回到对应章节练三遍，而不是翻完答案就觉得会了。我之前备考时低估了“写 Dockerfile”的难度，总觉得看过就是会，结果自测时卡住了，这才静下心一条条练透。
4. 常见问题与排查技巧实录
4.1 容器启动失败怎么定位
容器启动失败是我日常收到最多的问题，也是考试的高频场景。第一步永远是用docker ps -a看容器的当前状态，特别关注 STATUS 列里的退出码，退出码会直接告诉你大概率的故障方向。第二步执行docker logs 容器名看应用输出，很多问题是配置文件路径错误或端口被占用导致的启动报错。第三步针对仍然看不懂的情况，用docker inspect 容器名查看详细配置，确认环境变量、挂载路径、网络模式是否符合预期。
常见原因和表现可以参照下表：
| 现象 | 可能原因 | 快速处理 |
|---|---|---|
| 端口映射无法访问 | 容器内应用只监听了本机回环地址 | 调整应用监听地址为 0.0.0.0 |
| 容器秒退 | 启动命令参数错误或依赖服务未就绪 | 查看退出码与日志确认原因 |
| 挂载目录为空 | Bind Mount 目标路径不对 | 核对容器内路径是否与配置一致 |
| 磁盘空间不足 | 日志文件或镜像堆积过多 | 清理旧容器与悬空镜像 |
排查过程中要养成一个习惯：先看日志再改配置，避免凭感觉重启容器。日志是容器留下的第一手线索，跳过它直接重启纯靠运气。
4.2 镜像构建的几个老坑
镜像构建慢或者构建失败，往往不是某个指令写错了，而是对缓存机制理解不到位。最典型的坑是频繁修改ENV导致后续层全部缓存失效，因为环境变量的变化会影响后面对它的引用。解决办法是把变动频繁的业务代码放在 Dockerfile 后半段，让依赖安装的过程尽量命中缓存。
还有一个坑是文件上下文过大。如果构建目录里有几十 GB 的数据目录，即使 Dockerfile 里没有 COPY 它，Docker 也会先把整个上下文打包发送给守护进程，导致构建卡住很久。这也是.dockerignore必须存在的原因。
权限问题是 Linux 环境下构建的老大难。用基础镜像的默认 root 用户构建时一切正常，但运行时切换到普通用户，应用就报“Permission denied”。原因是镜像里的文件还保留着 root 权限。处理方式的通行做法是在构建阶段用RUN chown -R 指定用户:指定用户 /app把应用目录归属到运行用户，再通过USER指令切过去。
4.3 网络联通的排查路径
容器间访问不通是另一个高频问题。排查路径基本固定：先用docker network inspect 网络名确认容器是否在同一个网络里，再确认是否使用了容器名作为访问地址。默认 bridge 网络虽然也提供互通能力，但不保证支持内置 DNS 解析功能，依赖 IP 访问会在容器重建后失效。
端口映射排查时，先确认-p参数有没有映射到正确的宿主机端口，再用curl直接访问宿主机的映射端口，确认是否有响应。如果宿主机上没响应，再进容器内部试试，因为容器内应用监听的地址决定了它能否接受来自端口映射的流量。
有一种隐蔽情况是容器内部的localhost和宿主机localhost并不是同一个东西。容器内访问localhost访问的是容器自己，不是宿主机服务，这一点排查问题很容易绕进去。遇到联不通的访问，明确目标地址写在哪个环境中，比盲目抓包有效。
4.4 退出码速查表
| 退出码 | 含义 | 常见场景 |
|---|---|---|
| 0 | 正常退出 | 进程完成工作主动结束 |
| 1 | 应用内部错误 | 配置文件错误、初始化失败 |
| 125 | Docker 守护进程自身错误 | 运行参数不合法 |
| 126 | 命令无法执行 | 缺少执行权限 |
| 127 | 命令不存在 | 镜像内没有该可执行文件 |
| 130 | 进程被 Ctrl+C 终止 | 手动中断前台容器 |
| 137 | 进程被 SIGKILL 杀死 | 内存超限触发 OOM 或手动强杀 |
退出码是排查的第一把钥匙。看到 137 先查内存限制，看到 127 先查镜像内命令路径，方向对了，后面什么都顺。
备考 DCA 这件事，真正值钱的不是那张证书本身，而是被它逼着补全的那张知识地图。我现在做项目里的容器方案设计时，很多时候脑子里残留的并不是考试题目，而是备考时动手实验的场景。如果你也在考虑考这个认证，我的建议是别抱着“考完就解脱”的心态，把目标定成“能在不查文档的情况下完整跑通一套多容器应用”，通过考试会变成一个顺带的结果。
