前两天有同事问起 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 意味着进程被强制杀掉常见于内存超限触发系统 OOM126/127 则是命令无法执行或找不到命令。这些码在后面的排查部分我还会细说。2.2 Dockerfile 与镜像构建Dockerfile 是镜像构建的蓝图也是整个 DCA 考试里我最推荐的投入方向。它不复杂但细节很多。一个典型的多阶段构建示例FROM nginx:1.25-alpine AS runtime COPY --frombuild /app/dist /usr/share/nginx/html EXPOSE 80 HEALTHCHECK --interval30s --timeout3s \ 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 是内存里的临时文件系统容器停止数据就消失适合放临时缓存、锁文件这类不要求持久的内容。下面这张表是我备考时自己整理的基本覆盖了三种存储的核心差异存储方式数据存放位置生命周期典型使用场景VolumeDocker 托管目录随容器删除仍存在手动清理才删除数据库数据、应用持久化配置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_HOSTdb 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应用内部错误配置文件错误、初始化失败125Docker 守护进程自身错误运行参数不合法126命令无法执行缺少执行权限127命令不存在镜像内没有该可执行文件130进程被 CtrlC 终止手动中断前台容器137进程被 SIGKILL 杀死内存超限触发 OOM 或手动强杀退出码是排查的第一把钥匙。看到 137 先查内存限制看到 127 先查镜像内命令路径方向对了后面什么都顺。备考 DCA 这件事真正值钱的不是那张证书本身而是被它逼着补全的那张知识地图。我现在做项目里的容器方案设计时很多时候脑子里残留的并不是考试题目而是备考时动手实验的场景。如果你也在考虑考这个认证我的建议是别抱着“考完就解脱”的心态把目标定成“能在不查文档的情况下完整跑通一套多容器应用”通过考试会变成一个顺带的结果。