Docker与CI/CD是当前技术面试中出现频率很高的两个主题，尤其是在DevOps、后端开发、运维开发等岗位的考察里。面试官通常不满足于候选人只会运行简单的docker命令，而是会追问镜像分层机制、Dockerfile优化、多阶段构建、流水线缓存设计以及容器化后的部署策略。准备这类面试时，建议把知识拆成三个层次来复习：基础概念是否能讲清楚原理，构建环节是否有过实际优化经验，以及能否结合CI/CD设计一套可用的交付流程。下面分别展开这些高频考点。
Docker 核心概念与网络存储考点
容器和镜像的区别是几乎每一场Docker面试都会问的问题。镜像是一个只读的模板，由多个只读层叠加而成，每一层对应Dockerfile里的一条指令；容器则是在镜像层之上增加了一个可写层，也就是容器层。当容器被删除后，可写层里的数据会丢失，除非使用了数据卷或者挂载主机目录。这个写时复制的特性可以这样解释：多个容器可以共享同一个基础镜像层，只有发生修改时才复制到自己的可写层，这样既节省了磁盘空间又加快了启动速度。
存储和网络是另外两个高频方向。数据卷分为匿名卷和命名卷，面试官常问如何持久化容器数据。一个典型的回答是使用docker run -v mydata:/data创建命名卷，这样即使容器被删除，数据仍然保留在卷里。网络方面需要清楚bridge、host、none和overlay这几种模式的区别。bridge是默认的NAT网络，容器之间可以通过IP通信，但不同宿主机上的容器需要overlay或者外部服务发现来解决。很多面试题会问容器为什么无法直接通过localhost访问宿主机服务，答案就在于默认的bridge网络做了网络隔离。
命令行操作也是必考项。比如如何查看容器日志、如何进入一个正在运行的容器、如何清理无用的镜像和容器。常见的命令有docker logs -f 容器名、docker exec -it 容器名 /bin/sh、docker system prune。除了记住命令，理解容器生命周期状态也很重要：created、running、paused、restarting、exited、dead。面试时如果能把状态机和命令对应起来，会显得基础非常扎实。
镜像构建优化与 Dockerfile 实战
Dockerfile是构建镜像的脚本，面试中经常让候选人现场写一个多阶段构建。多阶段构建的核心思路是把编译环境和运行环境分开，用第一个阶段安装编译器、下载依赖、执行构建，第二个阶段只复制编译产物和运行时依赖。这样做可以显著减小最终镜像的体积。下面是一个Go语言项目的多阶段构建示例：
FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o main . FROM alpine:3.18 WORKDIR /app COPY --from=builder /app/main . CMD ["./main"]
上面这个例子最终镜像只包含一个静态二进制文件和基础运行环境，体积可能从几百MB降到几十MB。除了多阶段构建，减小镜像体积的方法还包括选择更小的基础镜像，比如用alpine、distroless替代ubuntu或centos；使用.dockerignore文件排除不必要的构建上下文；合并多个RUN指令减少层数；以及在安装依赖后清理包管理器缓存。面试时如果能把这些技巧串起来讲，会给人留下实际做过优化的印象。
构建缓存是另一个高频问题。Docker会按照Dockerfile指令顺序构建缓存，如果某一层之前的指令没有变化，就会直接使用缓存层。因此把变化最频繁的步骤放在后面，把稳定的依赖安装放在前面，可以最大化缓存命中率。例如先COPY go.mod和go.sum并下载依赖，再COPY源代码，这样代码修改后依赖层仍然可以被复用。面试官可能会问为什么构建上下文很大，原因往往是没有使用.dockerignore，导致把整个项目目录包括node_modules、.git、日志文件都传给了Docker守护进程。
CMD和ENTRYPOINT的区别也是经典题。简单来说，CMD提供默认的执行命令或参数，运行时可以被覆盖；ENTRYPOINT定义容器启动时必须执行的主进程，运行时传入的参数会追加到ENTRYPOINT后面。实际项目中常把ENTRYPOINT设为固定命令，用CMD提供默认参数，比如ENTRYPOINT ["nginx"]配合CMD ["-g", "daemon off;"]。这样用户运行docker run 镜像 -t时，-t会追加到nginx后面，而不会覆盖启动命令。
CI/CD 流水线设计与容器化集成
持续集成和持续部署的核心是把代码提交后的构建、测试、打包、部署自动化。在容器化环境中，CI流水线通常会在代码合并后触发，拉取代码、运行测试、构建镜像并推送到镜像仓库。CD阶段则从仓库拉取镜像，更新到测试或生产环境。下面是一个简单的Jenkins pipeline示例，展示如何在流水线中构建并推送Docker镜像：
pipeline {
agent any
environment {
IMAGE_NAME = 'myapp'
REGISTRY = 'registry.ipipp.com'
}
stages {
stage('Checkout') {
steps {
git url: 'https://github.com/example/myapp.git', branch: 'main'
}
}
stage('Build and Push') {
steps {
sh 'docker build -t $IMAGE_NAME:$BUILD_NUMBER .'
sh 'docker tag $IMAGE_NAME:$BUILD_NUMBER $REGISTRY/$IMAGE_NAME:$BUILD_NUMBER'
sh 'docker push $REGISTRY/$IMAGE_NAME:$BUILD_NUMBER'
}
}
}
}
实际面试中不会要求背出完整脚本，但会考察对流水线设计原则的理解。比如为什么要用镜像标签而不是latest，答案是为了可追溯性和回滚能力。每次构建生成唯一的标签，比如使用Git提交哈希或者构建号，这样出问题时可以快速定位并回退到上一个稳定版本。缓存复用也是流水线加速的关键，在Docker构建时可以使用BuildKit的缓存挂载，或者使用远程缓存，避免每次都重新下载依赖。
容器化部署还涉及零停机策略。常见的方式有滚动更新、蓝绿部署和金丝雀发布。滚动更新是逐个替换旧实例，蓝绿部署是同时运行两套环境切换流量，金丝雀是先让少量用户使用新版本。在Kubernetes中这些策略可以通过Deployment的rolling update参数或者服务网格来实现。面试官可能会问如何实现回滚，一个标准答案是保存历史镜像版本和部署配置，一旦新版本健康检查失败就自动切换回旧版本。
Docker in Docker是流水线里常见的坑。直接在容器里运行Docker守护进程会带来权限和安全问题，也会破坏构建缓存。更推荐的做法是使用挂载宿主机的Docker socket，或者使用Kaniko、Buildah这类无需守护进程的构建工具。如果必须使用Docker in Docker，需要了解privileged模式的风险。面试时能主动提到这些权衡，通常会成为加分项。
综合场景题与排查思路
场景题经常这样问：某次上线后发现容器反复重启，你会怎么排查？第一步是查看容器状态和日志，使用docker ps -a和docker logs。如果日志显示端口被占用，检查宿主机端口映射；如果是内存不足导致OOM，可以使用docker stats查看资源使用情况。健康检查配置也是常见原因，Dockerfile里通过HEALTHCHECK指令或者Kubernetes的liveness、readiness探针来定义。如果readiness探针一直失败，容器不会被标记为就绪，流量也就不会转发过去。
另一个高频场景是构建慢。构建慢的原因可能是基础镜像太大、依赖下载没有缓存、构建上下文过大、或者流水线串行执行太多任务。优化方向包括使用多阶段构建减小体积、利用Docker层缓存、并行执行测试和构建、将依赖安装提前到独立层。在代码层面，引入增量编译或者使用构建工具自带的缓存也能起到明显效果。面试时把这些点按优先级排列出来，会显得思路清晰。
最后是关于安全的问题。容器安全涉及镜像扫描、运行用户非root、只读根文件系统、限制资源、使用seccomp和AppArmor等。面试官可能问如何避免敏感信息泄露，答案是通过环境变量或者Secret管理工具注入，而不是把密码写进Dockerfile。在CI/CD流水线中，要使用密钥管理服务或流水线自身的加密变量，并且定期扫描镜像漏洞。这些内容不仅能应对面试，也直接关系到生产环境的稳定性。