Docker 面试问答（测试工程师版）

 

本文档面向软件测试工程师，涵盖 Docker 基础、测试场景应用、CI/CD 集成及实战项目问答。 基于 autotest 项目实践，每个回答都有可直接使用的素材。

目录

  1. 基础概念篇
  2. Dockerfile 与镜像构建篇
  3. 容器网络与存储篇
  4. Docker Compose 编排篇
  5. Docker 在测试中的应用篇
  6. CI/CD 集成篇
  7. 故障排查与最佳实践篇
  8. 场景题与开放题
  9. 常用命令篇

一、基础概念篇

Q1：Docker 和传统虚拟机有什么区别？

关键词：共享内核 vs 独立内核、资源开销、启动速度、隔离性

对比项Docker 容器虚拟机
内核 共享宿主机内核 独立 Guest OS 内核
启动速度 秒级 分钟级
内存开销 MB 级（仅应用+依赖） GB 级（完整 OS）
镜像大小 MB ~ 几百 MB GB ~ 十几 GB
隔离性 进程级隔离（较弱） 硬件级虚拟化（强）

面试回答：

Docker 和虚拟机最核心的区别是是否共享宿主机内核。

Docker 容器直接使用宿主机内核，通过 Namespace 做资源隔离、Cgroups 做资源限制。优点是启动快（秒级）、资源开销小（一个宿主机能跑几十上百个容器）；缺点是隔离性不如虚拟机，因为共享内核意味着如果宿主机内核崩溃，所有容器都会受影响。

虚拟机有独立的 Guest OS，通过 Hypervisor 层做硬件级虚拟化，隔离性更强，但资源开销大、启动慢。

对测试来说：Docker 适合跑自动化测试、Mock Server 这类轻量服务；虚拟机更适合需要完全隔离环境的场景（如测试不同内核版本、安全测试）。

Q2：镜像（Image）和容器（Container）的区别是什么？

关键词：类 vs 实例、只读 vs 可写、静态 vs 动态

面试回答：

镜像和容器的关系，可以类比程序和进程，或者类和对象。

  • 镜像是静态的只读模板，包含运行应用所需的一切：代码、运行时、系统库、环境变量等。构建后不再变化。
  • 容器是镜像的运行实例，在镜像层之上加了一个可写层（Container Layer），容器的读写操作都在这个可写层。容器可以启动、停止、删除、暂停。

关键点：一个镜像可以启动多个容器，每个容器互不影响。容器删除后，写入的数据也就丢失了——所以需要持久化数据时要用 Volume。

Q3：Docker 的核心架构是怎样的？

关键词：C/S 架构、Docker Daemon、REST API、containerd、runc

面试回答：

Docker 使用 C/S 架构：

  1. Docker Client（docker 命令）→ 通过 REST API 发送指令
  2. Docker Daemon（dockerd）→ 守护进程，接收并处理请求
  3. containerd → 管理容器生命周期（启动/停止/暂停）
  4. runc → 符合 OCI 标准的底层容器运行时，直接与内核交互

用户执行 docker run → Client 发送 API 请求 → Daemon 收到后调用 containerd → containerd 通过 runc 创建容器。

对测试工程师来说，了解这个架构有助于排查 Docker 相关问题。比如 docker ps 没看到容器，可能是 Daemon 挂了；容器启动失败可能是 runc 层的问题。

二、Dockerfile 与镜像构建篇

Q4：Dockerfile 中 COPY 和 ADD 有什么区别？

关键词：功能范围、推荐使用

面试回答：

  • COPY：只做一件事——将文件从宿主机复制到镜像。简单明了，推荐优先使用。
  • ADD：除了复制文件，还支持两个额外功能：① 自动解压 tar 包（如 ADD app.tar.gz /app/）；② 支持 URL 下载（如 ADD http://example.com/file /app/）。

最佳实践：能用 COPY 就不用 ADD。只有需要自动解压 tar 包时才考虑 ADD。URL 下载更推荐用 RUN curl 或 RUN wget，因为可读性更好，也方便清理缓存。

Q5：CMD 和 ENTRYPOINT 有什么区别？

关键词：默认命令 vs 入口点、是否可覆盖

面试回答：

  • CMD：提供默认命令和参数，docker run 时可以被覆盖。
    • 如 CMD ["python", "app.py"]，执行 docker run image 等于跑 python app.py，但 docker run image python test.py 就会覆盖为 python test.py
  • ENTRYPOINT：容器启动的入口程序，不会被 docker run 后面的命令覆盖。
    • 如 ENTRYPOINT ["python"]，docker run image app.py 等于 python app.py

最佳实践：ENTRYPOINT + CMD 搭配使用。ENTRYPOINT 固定入口程序，CMD 提供默认参数。

ENTRYPOINT ["python"]
CMD ["app.py"]

这样 docker run image → python app.py，docker run image test.py → python test.py，很灵活。

Q6：多阶段构建（Multi-stage Build）是什么？有什么好处？

关键词：构建环境与运行环境分离、减小镜像体积

面试回答：

多阶段构建是在一个 Dockerfile 中用多个 FROM 语句，每个 FROM 是一个独立的构建阶段，后一阶段可以只从前面阶段中复制需要的产物。

核心价值：构建环境和运行环境分离，最终镜像只包含运行所需的最小文件。

举例，我的 autotest 项目的 Dockerfile：

# 第一阶段：构建环境
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 第二阶段：运行环境
FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin
COPY . .
USER app
EXPOSE 5050
CMD ["python", "platform/app.py"]

好处：

  1. 镜像体积小：不含构建工具链（gcc、编译器），只保留运行时
  2. 安全性高：攻击面小（没有编译器、调试工具）
  3. 构建缓存：不变层（装依赖）放前面，变化层（源码）放后面，利用缓存加速构建

Q7：怎么减小 Docker 镜像体积？

关键词：基础镜像、多阶段构建、层缓存、清理缓存

面试回答：

减小镜像体积有五个常用手段：

  1. 选对基础镜像：用 slim 或 alpine 版本。python:3.12 约 1GB，python:3.12-slim 约 120MB，python:3.12-alpine 约 50MB。
  2. 多阶段构建：构建阶段装编译器，运行时阶段只复制产物。
  3. 合并 RUN 命令：每个 RUN 创建一个镜像层，合并后用 && 连接，并在最后清理缓存。 
    RUN apt-get update && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*
  4. .dockerignore：排除 .git/、node_modules/、__pycache__/、.idea/ 等无关文件。
  5. 最小化依赖：只装运行时需要的包，不装测试工具、调试器。

三、容器网络与存储篇

Q8：Docker 有哪几种网络模式？各有什么用途？

关键词：bridge、host、none、overlay、自定义网络

面试回答：

Docker 有四种基础网络模式：

  1. bridge（默认）：容器通过 Docker 网桥（docker0）与宿主机通信，容器间通过 IP 通信。适合单机容器。
  2. host：容器直接使用宿主机网络栈，无网络隔离。适合对网络性能要求高的场景（如流量压测），但有端口冲突风险。
  3. none：无网络，适合需要完全隔离的场景。
  4. overlay：跨宿主机通信，用于 Docker Swarm 集群。

实际项目用法：docker compose 默认创建自定义 bridge 网络。自定义 bridge 比默认 bridge 多一个重要功能——通过容器名通信。比如我的 autotest 项目中，test-runner 容器用 http://mock-server:5050 访问 mock-server，而不是写死 IP。

Q9：容器之间如何通信？

关键词：自定义网络、DNS 解析、服务发现

面试回答：

同一自定义 bridge 网络中的容器，Docker 内置 DNS 会将容器名自动解析为 IP。所以容器间通过容器名直接通信，不需要关心 IP 变化。

实际例子（autotest 项目）：

services:
  mock-server:
    container_name: autotest-mock
    # ... 暴露 5050 端口

  test-runner:
    environment:
      - BASE_URL=http://mock-server:5050  # ← 直接通过服务名访问

关键点：

  • 必须在同一个自定义网络下
  • docker compose 会自动创建网络，服务名就是 hostname
  • 不需要 --link（已废弃）

Q10：数据卷（Volume）和绑定挂载（Bind Mount）有什么区别？测试中怎么用？

关键词：Docker 管理 vs 宿主机路径、持久化场景

面试回答：

对比项VolumeBind Mount  
管理方式 Docker 管理（docker volume） 宿主机路径直接挂载  
存储位置 /var/lib/docker/volumes/ 宿主机任意路径  
宿主机依赖 不依赖宿主机路径结构 依赖宿主机路径  
备份迁移 易（Docker 管理） 相对难  
适用场景 生产环境、数据库持久化 开发调试、本地文件修改  

在测试项目中：我通常用 bind mount。比如 autotest 项目中，把容器的测试报告目录挂载到宿主机：

volumes:
  - ./reports:/app/reports

这样容器内生成的测试报告（HTML、Allure JSON）在宿主机直接可见，方便查看和归档。

如果是数据库或需要备份的重要数据，应该用 Volume。

四、Docker Compose 编排篇

Q11：docker-compose.yml 的核心字段有哪些？healthcheck 的作用是什么？

关键词：services、depends_on、healthcheck、networks、volumes

面试回答：

docker-compose.yml 的核心字段：

字段作用示例  
services 定义所有服务容器 mock-server:、test-runner:  
build 指定 Dockerfile 构建 context: .、dockerfile: Dockerfile  
ports 端口映射 "5050:5050"  
environment 环境变量 BASE_URL=http://mock-server:5050  
depends_on 服务启动依赖 配合 condition: service_healthy  
healthcheck 健康检查，确保服务就绪 定期检查 HTTP 端点  
volumes 数据持久化 ./reports:/app/reports  
networks 容器网络 默认自动创建  

healthcheck 的作用：确保依赖服务完全就绪后再启动下游服务。没有 healthcheck 的话，depends_on 只保证启动顺序，不保证服务可用。

实际例子：

mock-server:
  healthcheck:
    test: ["CMD", "python", "-c",
           "import urllib.request; urllib.request.urlopen('http://localhost:5050/')"]
    interval: 5s       # 每 5 秒检查一次
    timeout: 3s        # 超时时间
    retries: 5         # 连续失败 5 次算不健康
    start_period: 3s   # 启动后等 3 秒再开始检查

test-runner:
  depends_on:
    mock-server:
      condition: service_healthy  # 等 mock-server 健康了才启动

这样避免了"测试跑完了 Mock 还没起来"的问题。

Q12：depends_on 和 healthcheck 的区别是什么？

关键词：启动顺序 vs 服务就绪

面试回答：

这是一个面试高频陷阱题。

  • depends_on 只保证启动顺序——先启动 A 再启动 B。但不保证 A 里的服务已经可以接受请求。
  • healthcheck 保证服务就绪——定期检查服务是否正常运行。

两者必须配合使用：depends_on + condition: service_healthy，才能真正做到"等上游服务可用后再启动下游"。

不配置 healthcheck 的话，服务启动了但端口还没监听，下游容器就可能报 Connection Refused。

五、Docker 在测试中的应用篇

Q13：你在测试项目中怎么用 Docker？（重点必问题）

关键词：项目实战、Mock Server + 自动化测试、一键运行

面试回答：

我在 autotest 项目中搭建了 Docker Compose 双服务架构：

架构：

  • mock-server 容器：运行 Flask Mock Server，模拟被测接口
  • test-runner 容器：运行 pytest 自动化测试

关键设计：

  1. healthcheck 依赖：test-runner 等 mock-server 健康检查通过后才启动，避免"服务还没起来测试就跑了"
  2. 环境变量解耦：BASE_URL=http://mock-server:5050 通过环境变量传入，不硬编码
  3. 报告持久化：测试报告通过 bind mount 挂载到宿主机 ./reports 目录，不丢失
  4. 非 root 用户：容器内创建 app 用户运行，提升安全性
  5. 多阶段构建：镜像体积控制在 250MB 以内

最终效果：

docker compose up --build
# → mock-server 启动 → healthcheck 通过 → test-runner 自动执行测试
# → 在 reports/ 下查看测试报告

给团队带来的价值：新同学加入测试，只需要安装 Docker，一条命令就能跑起完整的测试环境，不用花半天配 Python 环境和依赖。

Q14：Mock Server 用 Docker 部署有什么好处？

关键词：环境一致性、独立部署、团队共享

面试回答：

把 Mock Server 容器化的好处：

  1. 环境一致：所有人在相同的容器环境中开发测试，消除"在我机器上能跑"的问题
  2. 快速启动/重置：docker compose restart mock-server 几秒就能重置 Mock 状态
  3. 独立部署：测试环境的 Mock Server 可以用单独的容器部署，不依赖被测服务的部署状态
  4. 团队共享：Mock Server 镜像推到仓库，其他团队也可以直接用
  5. 集成到 CI/CD：Pipeline 中启动一个 clean 的 Mock 容器，测试完销毁，每次都是全新环境

Q15：测试环境用 Docker 和直接用本地 Python 环境有什么区别？

关键词：隔离性、可重复性、CI/CD 集成

面试回答：

对比项Docker 环境本地 Python 环境  
环境隔离 ✅ 完全隔离 ❌ 依赖系统 Python  
版本管理 ✅ 每个项目独立版本 ❌ 全局包可能冲突  
环境一致性 ✅ 开发/CI/生产一致 ❌ "在我机器上能跑"  
环境搭建时间 ✅ 秒级 docker compose up ❌ 几分钟 pip install  
CI/CD 集成 ✅ 原生支持 ⚠️ 需要额外配置  
调试方便性 ⚠️ 需要 docker exec ✅ 直接改直接跑  

我的选择策略：日常开发调试用本地环境，但回归测试和CI/CD必须用 Docker。这样既保证了开发效率，又保证了测试环境的可重复性。

Q16：测试报告在容器中生成后怎么取出来？

关键词：Volume 挂载、docker cp

面试回答：

两种方式：

  1. 推荐：Volume 挂载（Bind Mount） — 运行时就挂载目录，报告直接写到宿主机

    volumes:
  - ./reports:/app/reports

    测试容器里的报告生成到 /app/reports，宿主机直接在 ./reports/ 看到。

  2. 临时：docker cp — 容器运行完后复制出来

    docker cp test-runner:/app/reports ./reports

测试项目中推荐用第 1 种，因为在 CI/CD 中可以直接拿宿主机路径的报告来做后续处理（发布 HTML、发送邮件等）。

六、CI/CD 集成篇

Q17：你的 CI/CD 流水线是什么样的？（综合题）

关键词：Pipeline as Code、Docker 集成、自动化

面试回答：

我用 Jenkins Pipeline as Code 搭建了 CI/CD 流水线，Jenkinsfile 放在代码仓库中做版本管理。

流水线阶段：

Checkout → Build Image → Start Mock → Run Tests → Report → Cleanup
  1. Checkout：从 Git 拉取最新代码
  2. Build Image：docker build 构建最新镜像
  3. Start Mock：docker compose up -d mock-server 启动 Mock 服务，等待 healthcheck
  4. Run Tests：docker compose run --rm test-runner 在 Docker 中执行 pytest
  5. Report：生成 Allure 测试报告并发布到 Jenkins
  6. Cleanup：docker compose down -v 清理容器和网络

核心价值：

  • 代码提交后 10 分钟内完成全量回归测试
  • 环境一致性：CI 环境和本地开发环境完全一致
  • 质量问题左移：提交阶段就发现问题，不等到测试阶段

Q18：Jenkins 中怎么使用 Docker？（DooD 模式）

关键词：Docker outside of Docker、docker.sock 挂载

面试回答：

Jenkins 本身也是 Docker 容器启动的。要在 Jenkins 容器里使用 docker 命令，需要挂载宿主机的 Docker 套接字，即 DooD（Docker outside of Docker）模式：

docker run -d \
  --name jenkins \
  -p 8080:8080 \
  -v jenkins_home:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \  # ← 关键
  jenkins/jenkins:lts

原理：Jenkins 容器内的 docker 客户端通过挂载进来的 socket 文件，调用宿主机上的 Docker 引擎创建容器。容器和 Jenkins 是"兄弟关系"——都是宿主机上的容器。

需要安装 Docker Pipeline 插件，Pipeline 中可以这样用：

stage('Build Image') {
    steps {
        sh 'docker build -t autotest:latest .'
    }
}

stage('Run Tests') {
    steps {
        sh 'docker compose run --rm test-runner'
    }
}

七、故障排查与最佳实践篇

Q19：容器启动失败，怎么排查？

关键词：logs、exec、inspect、逐层排查

面试回答：

排查容器启动失败，按照以下步骤：

第 1 步：看容器状态

docker ps -a          # 看所有容器（包括退出了的）
docker logs <容器名>   # 看日志，这是最重要的信息

第 2 步：检查退出码

  • 退出码 0：正常退出
  • 退出码 1/2：应用级错误（代码抛异常、找不到文件等）
  • 退出码 137：被 SIGKILL 杀死（通常 OOM）
  • 退出码 139：段错误（SIGSEGV）

第 3 步：检查配置

docker inspect <容器名>        # 查看完整配置（端口映射、环境变量、挂载卷等）
docker inspect <容器名> | jq '.[0].State'  # 看状态详情

第 4 步：在容器中手动调试

docker run -it --rm <镜像名> /bin/bash   # 进入容器手动执行命令

实际案例：autotest 项目中遇到过的问题——Dockerfile 里的 EXPOSE 5000 和 app.py 实际监听的 port=5050 不一致，导致端口映射失效。通过 docker logs 看到 Flask 在 5050 上启动，但 docker-compose 映射的是 5000，一眼就发现了问题。

Q20：容器运行正常但访问不到，可能是什么原因？

关键词：端口映射、网络模式、绑定地址

面试回答：

常见原因及排查思路：

  1. 端口映射问题：docker ps 查看 PORTS 列，确认 宿主机端口:容器端口 是否正确映射。如果 host 端口被占用，Docker 不会报错但映射会失败。

  2. 容器内服务监听地址：服务必须监听 0.0.0.0 而非 127.0.0.1。Flask 默认是 127.0.0.1，在容器中要改成 0.0.0.0。

    app.run(host='0.0.0.0', port=5050)  # 正确
app.run(port=5050)                   # 错误！默认 127.0.0.1

  3. 网络模式问题：如果用 network_mode: host，容器直接使用宿主机网络，不需要（也不能用）端口映射。

  4. 防火墙：宿主机防火墙可能拦截了 Docker 映射的端口。

排查命令：

curl http://localhost:5050/           # 测试宿主机能否访问
docker exec <容器> curl http://localhost:5050/  # 测试容器内能否访问
docker logs <容器>                     # 看服务是否正常启动

Q21：Docker 容器中的日志怎么管理？

关键词：json-file、logging driver、日志轮转

面试回答：

Docker 默认收集每个容器的 stdout/stderr，存储为 JSON 文件（位置在 /var/lib/docker/containers/<id>/<id>-json.log）。

常见问题：如果容器打印大量日志，JSON 日志文件会不断增长，占满磁盘。

最佳实践：启动容器时配置日志轮转：

docker run -d \
  --log-opt max-size=10m \   # 每个日志文件最大 10MB
  --log-opt max-file=3 \     # 保留 3 个文件
  my-service

或者在 docker-compose.yml 中全局配置：

services:
  mock-server:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

在测试项目中，容器只在 CI 中短期运行，日志量不大，用默认配置就够了。但如果是长期运行的 Mock Server，一定要配置日志轮转。

Q22：本地构建的镜像能直接给其他人用吗？怎么做？

关键词：镜像仓库、docker tag、docker push/pull

面试回答：

不能直接给，需要将镜像推送到镜像仓库（Registry），其他人再从仓库拉取。

方案一：Docker Hub（公共）

docker tag autotest:latest <用户名>/autotest:latest
docker push <用户名>/autotest:latest

方案二：私有仓库（企业中常用）

# 搭建
docker run -d -p 5000:5000 --name registry registry:2

# 推送
docker tag autotest:latest localhost:5000/autotest:latest
docker push localhost:5000/autotest:latest

# 拉取
docker pull localhost:5000/autotest:latest

方案三：Harbor（企业级，带 UI + 权限管理 + 漏洞扫描）

对测试团队的价值：Mock Server 镜像推到仓库后，其他团队的测试同学可以直接 docker pull 使用，不需要自己搭建 Mock 环境。

八、场景题与开放题

Q23：你搭建 Docker 测试环境时遇到过什么坑？怎么解决的？

关键词：真实踩坑经历、问题分析能力

面试回答：

在实际搭建 autotest Docker 环境时，遇到过三个比较典型的坑：

坑 1：端口不一致

  • Dockerfile 中 EXPOSE 5000，docker-compose 映射 5000:5000，但 app.py 实际监听 port=5050
  • 结果：容器启动了，但宿主机访问 localhost:5000 报 Connection Refused
  • 解决：统一改为 5050，并把端口号改为环境变量控制

坑 2：Python 版本不兼容

  • 原 Dockerfile 用 python:3.9-slim，但 pytest==9.0.2 要求 Python >= 3.10
  • 结果：pip install 阶段报错
  • 解决：升级到 python:3.12-slim

坑 3：测试运行过快，Mock 还没准备好

  • 没有配置 healthcheck，test-runner 启动时 mock-server 端口还没监听
  • 结果：测试全部失败，报 Connection refused
  • 解决：添加 healthcheck，test-runner 的 depends_on 加上 condition: service_healthy

Q24：如果让你设计一套基于 Docker 的测试环境管理方案，你怎么做？

关键词：架构设计、多环境、资源隔离

面试回答：

我会设计三层架构：

第一层：环境定义层

  • 用 docker-compose.yml 定义每个环境的服务拓扑（Mock Server、DB、Redis 等）
  • 通过 .env 文件和环境变量区分环境（dev/test/staging）

第二层：服务管理层

  • 每个微服务对应一个 Docker 容器，独立部署、独立版本
  • 服务之间通过 Docker 网络通信，对外只暴露必要端口
  • 数据库和中间件用 Volume 做数据持久化

第三层：自动化集成层

  • 集成 Jenkins Pipeline，提交代码自动触发测试
  • 测试执行完毕自动销毁环境，释放资源

核心原则：

  1. 不可变基础设施：每次部署都是全新容器，不做原地更新
  2. 环境等价：开发/测试/CI 环境完全一致
  3. 按需创建：用完即销毁，不长期占用资源

Q25：用 Docker 跑自动化测试和直接在宿主机跑测试，测试结果会有差异吗？

关键词：环境差异、潜在问题、建议

面试回答：

理论上不应该有差异，但实际上可能会有：

可能产生差异的原因：

  1. 时区：容器默认 UTC，宿主机可能 CST。如果测试依赖时间戳，可能产生时区相关失败
  2. 文件编码：容器可能缺少中文字体/语言包
  3. 资源限制：容器默认无资源限制，但 CI 环境中通常加了 --memory 限制
  4. 网络延迟：容器间通信和宿主机直连的延迟不同

建议：

  • 在 Dockerfile 或 docker-compose 中显式设置时区： 
    environment:
  - TZ=Asia/Shanghai
  • 在 Docker 和宿主机环境中都跑一遍测试，对比结果一致性
  • 以 CI 中的 Docker 测试结果为准（因为这是质量门禁）

Q26：作为测试工程师，你觉得自己为什么要学 Docker？

关键词：职业发展、效率提升、质量保障

面试回答：

测试工程师学 Docker 的价值，我认为有四点：

  1. 环境一致性：消除"在我机器上能跑"的问题。测试环境、CI 环境、开发环境用同一套 Docker 配置，结果可复现。
  2. 独立测试环境：不需要等开发部署测试环境，自己用 Docker 一键搭建 Mock Server + 测试环境，测试不依赖别人。
  3. 快速集成到 CI/CD：Docker 是 CI/CD 的基础设施，学 Docker 才能搭建自动化测试流水线。
  4. 职业竞争力：现在测试岗位 JD 基本都写着"熟悉 Docker"，这是标配技能不是加分项了。

一句话总结：Docker 帮测试工程师从"手工测试"走向"自动化测试平台搭建"的关键一步。

九、常用命令篇

Q27：你常用的 Docker 命令有哪些？（高频必问题）

关键词：镜像管理、容器管理、日志调试、资源清理

面试回答：

按使用场景分类，我日常最常用的 Docker 命令大概有 20 多个，分五类：

第一类：镜像管理

# 构建镜像（-t 给镜像打标签，. 指当前目录作为构建上下文）
docker build -t autotest:latest .

# 列出本地镜像
docker images

# 删除镜像（加 -f 强制删除）
docker rmi autotest:latest

# 从仓库拉取/推送镜像
docker pull python:3.12-slim
docker push myrepo/autotest:latest

# 给镜像打标签
docker tag autotest:latest myrepo/autotest:latest

面试中展开说：

  • docker build 会用 --no-cache 跳过缓存做干净构建；-f 指定其他位置的 Dockerfile
  • 构建上下文（context）只包含当前目录文件，不要把整个项目构建上下文设到根目录，否则会把大量无关文件发到 e

第二类：容器生命周期

# 启动容器
docker run -d --name mock-server -p 5050:5050 autotest:latest
# -d 后台运行  --name 命名  -p 端口映射

# 列出运行中的容器（-a 包括已停止的）
docker ps
docker ps -a

# 停止/启动/重启容器
docker stop mock-server
docker start mock-server
docker restart mock-server

# 删除容器（-f 强制删除运行中的）
docker rm mock-server
docker rm -f mock-server

# 进入容器内部调试
docker exec -it mock-server /bin/bash
# -i 交互式  -t 分配终端

面试中展开说：

  • docker run 常用参数：--rm（退出自动删除）、-v（挂载卷）、--network（指定网络）、--memory（内存限制）
  • docker exec 是排查问题的第一手段——容器运行正常但服务不可用，先 exec 进去看

第三类：日志与调试

# 查看日志（-f 实时跟踪，--tail 只看最后 N 行）
docker logs mock-server
docker logs -f --tail 100 mock-server

# 查看容器详细信息
docker inspect mock-server

# 查看容器资源使用情况
docker stats
docker top mock-server

# 查看容器内进程
docker top mock-server

# 从容器复制文件到宿主机
docker cp mock-server:/app/reports ./reports/

面试中展开说：

  • docker logs 是排查容器启动失败的第一道工序——看退出码和错误堆栈
  • docker inspect 看挂载卷、网络配置、环境变量是否生效
  • docker stats 实时看 CPU/内存，排查性能问题或 OOM

第四类：网络与存储

# 网络操作
docker network ls                    # 列出网络
docker network create autotest-net   # 创建自定义网络
docker network inspect autotest-net  # 查看网络详情
docker network connect autotest-net mock-server  # 容器接入网络

# 数据卷操作
docker volume ls                    # 列出卷
docker volume create my-volume      # 创建卷
docker volume inspect my-volume     # 查看卷详情
docker volume prune                 # 清理无用卷

# 查看容器端口映射
docker port mock-server

面试中展开说：

  • 自定义 bridge 网络拥有 DNS 解析功能，容器名即 hostname，这是容器间通信的基础
  • docker volume prune 配合 docker system prune 定期清理，释放磁盘空间

第五类：资源清理

# 一键清理（慎用！）
docker system prune          # 清理停止的容器、无用网络、 dangling 镜像
docker system prune -a       # 更彻底：清理所有未使用的镜像
docker container prune       # 只清理停止的容器
docker image prune           # 只清理 dangling 镜像
docker volume prune          # 只清理未使用的卷

面试中展开说：

  • 本地开发时磁盘经常被 Docker 占满（尤其是 Mac 的 Docker 虚拟机磁盘镜像），docker system prune 是常用操作
  • 但注意 docker system prune -a 会删除所有未使用的镜像，如果后续要用需要重新拉取，CI 环境中不要用
  • 更安全的做法：docker system prune（不加 -a），只清理 dangling 镜像和停止的容器

面试回答示例（1-2 分钟版）：

我常用的 Docker 命令按场景分五类：

镜像管理：docker build 构建镜像，docker images 查看本地镜像，docker rmi 删除镜像。

容器生命周期：docker run 启动容器，docker ps -a 查看所有容器，docker stop/start/restart 管理容器状态，docker exec -it 进入容器调试。

日志调试：docker logs -f 实时查看日志，docker inspect 看容器配置详情，docker stats 看资源使用情况。

网络存储：docker network 管理网络，docker volume 管理数据卷，docker cp 在容器和宿主机之间复制文件。

资源清理：docker system prune 定期清理无用资源，避免磁盘占满。

比如排查一个容器启动失败，我的套路是：docker ps -a 看状态 → docker logs 看错误日志 → docker inspect 检查配置 → 必要时 docker exec 进去手动调试。

附：面试回答速查表

问题类型核心关键词建议回答时长
Docker vs VM 共享内核、轻量、隔离性弱 1-2 分钟
镜像 vs 容器 类与对象、只读+可写层 1 分钟
Dockerfile 指令 COPY vs ADD、CMD vs ENTRYPOINT 1-2 分钟
多阶段构建 构建运行分离、体积优化 1-2 分钟
网络模式 bridge、host、自定义网络 1-2 分钟
容器间通信 容器名、自定义网络、DNS 1 分钟
Volume vs Bind Mount 持久化、开发 vs 生产 1 分钟
docker-compose 双服务架构、healthcheck 2-3 分钟
CI/CD 实战 Pipeline as Code、DooD 模式 2-3 分钟
排查问题 logs、exec、inspect 1-2 分钟
实战踩坑 端口不一致、healthcheck 2 分钟
Docker 对测试价值 环境一致、CI/CD、竞争力 1 分钟
常用命令 镜像/容器/日志/网络/清理 1-2 分钟

建议：不要死记硬背答案。先理解每个问题的核心关键词，面试时用自己的项目经历把答案串起来。面试官更看重你怎么用 Docker 解决实际测试问题，而不是背概念。

posted on 2026-06-29 11:27  fengZQ  阅读(35)  评论(0)    收藏  举报

导航