1. 镜像到底是个什么东西
很多测试同学第一次接触 Docker 的时候，最容易卡住的就是“镜像”和“容器”这两个词。官方文档翻来覆去讲 UnionFS、讲只读层、讲写时复制，看完还是会懵。我换个说法：镜像就是一个打包好的、带操作系统的、随时能跑起来的文件包。容器就是把这个文件包解压运行之后产生的“活体”。你拉下来的镜像像一个光盘，容器是光盘插进光驱之后正在运行的系统。
这个类比能解决大多数困惑。光盘本身是只读的，你怎么折腾都不会改变光盘上的内容；而容器运行时会有一层可写的临时区域，你在容器里改了文件、装了包、写了日志，都落在这层临时区域里。容器删掉之后，这些改动全部消失，镜像还是原来那个镜像。这也就是为什么很多人第一次在容器里改了配置、重启容器之后发现改动没了——因为改的是容器层，不是镜像层。
镜像还有一个测试人员必须理解的结构特点：分层。docker pull的时候你能看到一层一层下载，这就是镜像分层的直观体现。每一层对应 Dockerfile 里的一条指令，基础镜像自带若干层，你每加一条 RUN、COPY 就多出一层。分层的好处有两个：一是拉取和推送可以复用已有的层，多个镜像共用同一个基础层时只需要下载一次；二是构建时只要某一层没变，后面继承它的层可以直接走缓存，构建速度会明显变快。
这里有个容易踩的坑：层数并不是越多越好。每多一层，镜像的体积和构建时间都会有额外开销，而且层与层之间如果变化频繁，缓存的命中率也会下降。所以 Dockerfile 里最常见的优化手段之一，就是把连续几条RUN习惯通过&&合并成一条，把依赖装完再清理缓存，尽量控制在单个 RUN 里完成。后面专门讲制作镜像的时候我再展开。
镜像和容器的关系，另一个需要强调的点是：镜像不是虚拟机镜像。虚拟机的镜像是完整的操作系统镜像，包含内核；Docker 镜像只包含文件系统内容和元数据，它共享宿主机的内核。这也是为什么 Linux 的 Docker 镜像不能直接跑在 Windows 宿主机上，除非开了虚拟机内核。测试团队如果统一用公司内部的 Linux 构建机拉镜像，就不会碰到这类平台兼容问题。
对测试人员来说，理解镜像的本质还有一个实际收益：排查环境问题的时候，你能判断哪个环节出了问题。比如容器里报“缺少某个动态库”，你第一反应不是去装库，而是先想想这个镜像是谁做的、基于什么做的、缺的这个库是不是本来就不在基础镜像里。有了这个意识，后面所有操作都顺了。
1.1 镜像和容器在测试场景里的分工
测试人员使用 Docker 最常见的几个场景：搭一套 MySQL/Redis 当测试依赖、跑一份自动化测试环境、复现线上问题的环境、给开发提供一个临时的联调环境。这些场景里，镜像负责“定义环境”，容器负责“提供环境”。
比如我经常会写一套自动化接口测试，本地开发环境跑得好好的，一到新同事电脑上就各种缺依赖。后来我把运行环境和依赖全部做成镜像，任何人拉下来直接docker run就能执行同一套测试，环境差异的问题几乎消失。这就是镜像在测试领域的核心价值：把环境本身变成可交付、可版本管理的产物。
镜像也天然适合做“环境快照”。测试过程中发现某个问题依赖一组特定的中间件版本、特定的系统配置，就可以把当时的环境做成镜像保留下来。以后随时用这个镜像启动一个容器，就能回到当时的状态。这种用法比“我保存了一个虚拟机备份”要轻量得多，也比在文档里写“请安装 XX 版本、修改 XX 配置”要可靠得多。
1.2 镜像层的存在对测试有什么实际影响
前面说了分层机制，这里补两个测试中会直接遇到的现象。
现象一：docker build的时候出现CACHED。很多测试同学自己写 Dockerfile 构建镜像，发现改了某一行代码，重新构建时镜像层却显示缓存。这是因为 Docker 在构建每一层时会对比该层对应的指令上下文，如果指令字符串没变、涉及的上下文文件也没变，就直接复用缓存。如果你改的是 Dockerfile 后面的层，前面的层没变，前面所有层都会走缓存。这个特性本身是好事，但如果你希望强行走全量构建，需要加--no-cache。
现象二：镜像大小并不等于你写的文件大小的总和。基础镜像可能就有几百 MB，你往里面塞一个 1MB 的二进制文件，镜像不会只增加 1MB，因为新层本身还有文件系统的元数据和格式开销。反过来，你在一层里往镜像里写了一个 1GB 的文件，在下一层又把它删掉，镜像体积不会减少——因为那个 1GB 的文件仍然存在于底层里，只是上层把它遮住了。这个机制对测试镜像的体积控制影响很大，后面讲镜像瘦身的时候会再次提到。
2. 测试人员怎么挑选和获取镜像
镜像从哪里来，是测试人员接触 Docker 之后的第一个实际问题。大多数人的习惯是直接去公共镜像仓库搜一个名字，然后docker pull完事。这么做本身没错，但不是所有镜像都值得直接拿来用。
公共镜像仓库里的镜像质量参差不齐。有些镜像长期没人维护，基础系统里带着一堆已知漏洞；有些镜像为了“体积小”把常用的调试工具全砍了，你docker exec进去发现自己连vi都没有；还有的镜像作者直接在 README 里声明“仅供学习，不要用于生产”。测试环境虽然不如生产环境敏感，但你拿一个有安全漏洞的镜像当测试基线，测出来的结果本身就不可信。
所以我的建议是，优先选择官方镜像或团队内部维护的镜像。官方镜像的更新频率、安全维护、文档完整度都有基本保障。测试环境里你追求的不是“最新”，而是“稳定、可复现、可追溯”。这句话展开就是：记录你当时用的镜像名和标签，确保三个月后还能拉回来同一个版本；确保团队里任何人拉下来得到的结果都一致；确保出了问题你知道这个镜像是谁基于什么制作的。
2.1 公共镜像仓库的筛选标准
如果你确实需要从公共镜像仓库拉第三方镜像，我一般会按这几条标准去筛：
第一，看更新时间。超过半年没更新的镜像，大概率没人维护了。除非你明确知道这个版本是业务锁定的版本，否则不建议选。
第二，看 pull 次数和 stars 数。这个指标不完全可靠，但能反映一定程度的社区认可度。一个几万 pull 的镜像是经过大量人验证过的，踩坑概率相对小。
第三，看镜像描述和 Dockerfile 是否公开。描述里写清楚了这个镜像基于什么系统、包含什么软件、如何使用，通常比较靠谱；Dockerfile 公开也有助于你追查镜像里面到底装了什么。
第四，看体积。同一个功能的镜像，体积差好几倍的情况很常见。体积大的不一定差，可能是包含调试工具；体积小的也不一定好，可能把运行需要的工具链也裁掉了。体积只是参考，不能作为唯一标准。
还有一个细节：下载之后自己验证一下。拉下来先docker run跑一下，确认能启动、能访问，再分发到团队公共仓库或者写进测试文档。不要只看到 pull 成功就觉得万事大吉，pull 下来但跑不起来的镜像我遇到过不少。
2.2 镜像标签的版本陷阱
镜像标签是测试配置里最容易埋坑的地方，这里必须单独列出来说。
latest标签，看起来方便，实际上是最不可控的。latest并不是一个版本，只是一个随时可能变化的指针。作者每发一个新版本，都会把新版本也打上latest标签。你今天 pull 的和下周 pull 的latest可能完全是两个不同的镜像。测试环境一旦用了latest，就等于放弃了“可复现性”，某天环境突然跟昨天不一样了，你连排查方向都找不到。
因此我在项目里定过一个规矩：所有测试环境、测试脚本里涉及镜像的地方，必须写具体的版本标签，谁都不许用latest。比如 Redis 就写redis:7.0.12，Nginx 就写nginx:1.24.0，哪怕只是本地玩一玩也最好别偷懒，否则后面“环境对不上”的问题会把你折腾死。
另外要注意标签的“引用关系”：有些镜像的标签虽然指向同一个镜像 ID，但是不同标签对应构建时的默认配置可能不同。比如有些镜像同时提供-alpine、-slim、-bullseye、-bookworm等变体标签，它们底层系统、体积、包含的组件都不一样。就算版本号相同，也不能想当然认为它们等价。写测试基线文档的时候，最好把完整的镜像名和标签写全。
3. 手把手做一个测试用镜像
会拉镜像、会跑容器，只能算入门；测试人员真正拉开差距的是会不会自己做镜像。做镜像的第一种方式是在容器里手动改环境、装依赖，然后docker commit保存成一个新镜像。这种方式适合临时验证，但不适合长期维护。我强烈建议学习第二种方式：写 Dockerfile。
用docker commit做的镜像有个致命问题：不可审计、不可复现。你无法从镜像本身看到它是什么步骤生成的；过了两个月你自己都可能想不起当时往容器里装了什么。而 Dockerfile 是文本文件，天然适合放进代码仓库做版本管理，任何人照着构建都能得到一样的镜像。
下面我用一个实际例子，带着大家从头写一个测试用镜像，目标是做一个带调试工具和接口测试脚本的 Python 运行环境。整个过程中会穿插很多实操细节。
3.1 准备好的应用和目录结构
假设我们要把一套接口回归测试脚本打包进镜像，目录结构是这样的：
demo-api-tests/ ├── Dockerfile ├── requirements.txt ├── run_tests.sh ├── tests/ │ ├── __init__.py │ ├── test_login.py │ └── test_order.py └── config/ └── env.yaml脚本本身不复杂，就是用requests发请求、断言返回结果，最后输出测试报告。run_tests.sh是执行入口，里面调用 pytest。我们做镜像的目标是：任何人拿到这个镜像，一条docker run命令就能跑完整套回归。
这里有个测试人员的习惯可以先培养起来：脚本内部不要硬编码环境地址，通过环境变量传参。这样同一个镜像，通过-e ENV=dev可以在测试环境跑，-e ENV=stage可以在预发布环境跑，不需要为不同环境构建不同的镜像。镜像承担的是“运行能力”，环境地址属于“配置”，两者分开管理，灵活度会高很多。
3.2 Dockerfile 编写的关键细节
先给出这个场景下的一份初始 Dockerfile：
FROM python:3.11-slim WORKDIR /app RUN apt-get update \ && apt-get install -y --no-install-recommends curl vim procps \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY tests/ tests/ COPY config/ config/ COPY run_tests.sh . RUN chmod +x run_tests.sh ENV PYTHONUNBUFFERED=1 ENV TZ=Asia/Shanghai CMD ["sh", "run_tests.sh"]每一行背后都有讲究。
基础镜像选python:3.11-slim，而不是python:3.11。完整版 python 镜像体积在 1GB 左右，slim 版本在 150MB 左右，对我们这个场景来说足够用了。选 slim 而不是 alpine，是因为 alpine 的底层不是常见的 glibc，有些 Python 的 C 扩展包在 alpine 里需要额外编译或根本没预编译包，容易让测试脚本跑不起来。测试环境的稳定性优先，所以我倾向用最贴近主流运行环境、踩坑最少的镜像。
apt-get那条命令里我装了三个工具：curl用于接口连通性排查，vim用于进容器看日志和改配置，procps提供ps命令，方便查看容器内进程。这几个工具都是最基础的调试工具，缺了它们，容器跑起来出了问题你什么都干不了。注意--no-install-recommends这个参数，它会阻止 apt 安装推荐的额外软件包，能省下不少体积。装完还要清理/var/lib/apt/lists/*，这是 apt 的缓存索引，不清理会白白增加镜像体积。
COPY requirements.txt .之后再执行pip install，这看起来是小事，实际是为了利用 Docker 分层缓存。如果先COPY整个项目目录再安依赖，那么只要任何一个脚本文件改了，依赖安装那层缓存就会失效，每次都要重新装一遍。把依赖清单单独 COPY 进去，只要requirements.txt没变，无论脚本怎么改，依赖层都能复用缓存，构建速度快很多。
ENV PYTHONUNBUFFERED=1是为了让 Python 日志直接输出到终端，不经过缓冲区。测试脚本如果是通过docker logs看输出，不加这个可能会因为缓冲导致日志延迟甚至丢失，排查问题的时候会误以为脚本卡住了。
ENV TZ=Asia/Shanghai是时区设置。基础镜像默认是 UTC 时区，日志里打印的时间会跟本地差 8 小时，测试报告里如果有时间戳，对不上会让你很痛苦。再加一步也可以：在 RUN 里ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime，有些基础系统还需要这一步才能真正生效。
CMD是容器启动时默认执行的命令。这里写成["sh", "run_tests.sh"]，这样直接docker run 镜像名就能跑测试。如果希望进入容器做手工验证，可以在运行时覆盖 CMD，比如docker run --rm -it 镜像名 /bin/bash，后面的/bin/bash会覆盖 CMD 里的命令。
3.3 构建命令与验证循环
写好 Dockerfile 后，在项目目录下执行构建：
docker build -t demo-api-tests:1.0.0 .-t指定镜像名称和标签，demo-api-tests是镜像名，1.0.0是标签。点号表示构建上下文是当前目录。注意这个点号不是随便写的，它决定了 Docker 能获取哪些文件：构建时 Docker 会把整个上下文目录打包发给 Docker 守护进程，Dockerfile 里COPY的相对路径都是相对于这个上下文的。如果上下文目录太大，比如里面有个node_modules或者.git目录，构建会变得很慢，这时候应该添加.dockerignore文件把无关内容排除掉，写法和.gitignore一样：
.git node_modules __pycache__ *.pyc *.log .env构建完成后先用docker images确认镜像存在并查看体积。然后跑一次验证：
docker run --rm -e ENV=dev demo-api-tests:1.0.0--rm表示容器退出后自动删除，临时跑测试很合适，不会留下堆积的容器。-e ENV=dev传入环境变量。跑通之后再进容器手工验证环境完整性：
docker run --rm -it --entrypoint /bin/bash demo-api-tests:1.0.0 curl --version python -c "import requests; print(requests.__version__)" ps aux | head这里用了--entrypoint /bin/bash来覆盖默认入口。为什么不用直接追加命令？因为镜像里设置了CMD，而CMD是可以在运行时被替换的，追加命令就能替换掉。但有些镜像用的是ENTRYPOINT，这种情况下直接追加命令不会执行你想要的，必须用--entrypoint强行替换。测试同事之间交流时我经常说：先搞清楚镜像是用 CMD 还是 ENTRYPOINT 定义的入口，这两个的区别是理解容器启动行为的关键。
构建和验证循环基本就是：改代码、重新构建、跑容器、看结果。构建速度因为分层缓存会越来越快，测试迭代的体验相对舒服。
3.4 建立在 Dockerfile 里的多阶段构建
前面例子比较简单，不需要多阶段构建。但如果你是给测试团队做一个包含编译型组件的镜像，比如要同时装 Java 环境、编译一个 Spring Boot 应用，然后还要保留运行环境和调试工具，多阶段构建就是必须掌握的技巧。
多阶段构建的核心思路：一个 Dockerfile 里写多个FROM，前面的阶段是“构建期”，负责编译应用；最后一个阶段是“运行期”，只把编译好的产物复制过来，不会带着整套编译工具链。这样最终镜像只包含运行所需的最小集，体积小、漏洞面也小。
举一个很粗糙的例子：
FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline COPY src/ src/ RUN mvn package -DskipTests FROM eclipse-temurin:17-jre-jammy WORKDIR /app COPY --from=builder /build/target/demo-api.jar . CMD ["java", "-jar", "demo-api.jar"]第一个阶段有完整的 JDK 和 Maven，能执行编译；第二个阶段只放 JRE，体积和层级都干净得多。测试人员自己写这种 Dockerfile 的场景不多，但你要能看懂开发交付的镜像，能判断镜像是怎么做的，也能在需要自己搭建测试依赖服务时使用同样的思路。
4. 测试环境里镜像的高频使用姿势
镜像做出来是拿来用的。测试人员日常跟镜像打交道，主要就这几种姿势：拉起依赖中间件、搭建整套测试环境、复现 bug 和验证缺陷修复。
4.1 秒级拉起依赖服务
测试环境里最常见的需求：我要一套 MySQL、一套 Redis、一套 Kafka，本地不用安装，直接用 Docker 拉起来。这个场景我用得最多的是一行命令加一个挂载参数：
docker run -d --name test-redis \ -p 6379:6379 \ -v redis_data:/data \ redis:7.0.12-d表示后台运行，--name给容器命名方便后续管理，-p把容器端口映射到宿主机端口，-v把数据挂载到命名卷，这样删除容器后数据还能保留。
其中-p 6379:6379这个参数值得多说一句。容器里的 Redis 默认监听 6379 端口，但外部访问不在宿主机端口上，必须通过这个参数做端口映射。左边是宿主机端口，右边是容器内端口。如果宿主机端口已被占用，把左边改成一个空闲端口就行，比如-p 16379:6379。测试脚本里连接地址就改成localhost:16379。
挂载卷是个好东西，但测试场景里有时候反而会造成麻烦。比如你反复用同一个卷，数据越攒越乱；或者你跑的是临时验证，根本不关心数据持久化，那就不加-v，容器删掉数据也随之删除，省心。挂载目录还能直接覆盖容器内的配置文件，这在调试配置问题时非常方便：宿主机改配置，容器内立即生效。
另一个有用的参数是--network。多个容器需要互相通信时，可以创建一个自定义网络，让容器之间通过容器名访问，而不用依赖宿主机端口：
docker network create test-net docker run -d --name mysql --network test-net -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0.34 docker run -d --name myapp --network test-net -p 8080:8080 myapp:latest这样myapp容器里访问 MySQL，直接用mysql:3306这个地址就行，比通过宿主机 IP 访问要稳定得多，也不受宿主机端口冲突影响。测试环境这招很实用。
4.2 复现 bug 的标准流程
测 bug 的时候最怕的是“这个 bug 我没法复现”“环境我搭不起来”。有了镜像之后，复现方式可以统一成一套流程。
第一步，确认环境基线。从 bug 报告里提取测试环境的关键信息：应用版本、中间件版本、操作系统、相关配置。正常情况下这些信息在测试记录或者配置管理里都有，如果不太确定，就先用最接近的版本跑一次。
第二步，拉取或构建对应版本的镜像。中间件版本直接指定标签；应用版本看团队有没有按版本打标签的镜像，如果没有，向开发要对应分支的 Dockerfile 或构建产物。
第三步，启动容器，带上和现场一致的配置。比如 bug 里说“在并发 50 的情况下接口偶现超时”，那就用 Docker 把同样的服务、同样的数据库连起来，再用压测工具跑同样的并发。
这套流程最大的好处是“可重发”。测试发现一个问题后，可以把复现环境的完整命令写进 bug 描述里，开发照着命令启动同一个镜像，复现成本会明显降低。我在团队里推广过这种方式，效果很不错，大家从“环境调不通”变成“直接贴命令”。
4.3 用临时容器验证镜像内容
除了跑业务，我经常需要检查一个镜像里面到底装了什么，这时候会启动一个临时容器进去看，看完就删：
docker run --rm -it image-name /bin/sh为什么用/bin/sh而不是/bin/bash？因为很多精简镜像里只有sh，没有bash，你指定/bin/bash会直接报错。这也从侧面说明，进入容器之前你先确认一下这个镜像是基于什么系统、默认 shell 是什么，再决定用哪个命令。
进去之后我一般会看几个地方：
/etc/os-release，确认底层系统版本- 环境变量，确认运行时参数怎么传的
- 软件的版本号，比如
java -version、python --version - 工作目录下有没有源码或配置文件
这些信息记一遍，基本就能对一个镜像形成完整判断。如果镜像里没有你需要的调试工具，也可以临时进容器装一个，但注意这个改动不会保留，容器删除就没了。想要永久加工具，回到 Dockerfile 修改重新构建才是正路。
5. 常见问题与排查实录
用镜像和容器做测试，时间久了会遇到一些典型的坑。我按频率和影响程度整理一下，基本覆盖日常工作的主要痛点。
5.1 镜像占磁盘空间越来越大
docker images一看，本地占了几十 GB，这是最常见的抱怨。原因通常有三个：
一是镜像本身有多个变体，latest加具体版本标签，拉一次就是一个独立镜像，虽然底层层可复用，但 Docker 不会自动清理不被引用的层。
二是旧版本镜像一直保留着。测试过程中拉了很多中间版本，每个版本都占空间。镜像跟代码一样，也会有版本堆积的问题。
三是构建缓存和悬空镜像。改 Dockerfile 之后重新构建，旧层没被引用就成了悬空镜像，这类镜像名和标签都显示<none>。构建频繁的机器上，悬空镜像体积会快速膨胀。
清理方式分两种。只清理悬空镜像：
docker image prune清理所有未使用镜像、容器、网络、构建缓存：
docker system prune -a-a会把所有没在使用的镜像都删掉，执行前先确认一下是否都好删除，免得需要的时候又要重新拉。我给自己定的习惯：测试任务结束后，顺手删掉这次拉的一堆临时镜像，只保留团队公共仓库里已有的版本。自己的机器上脏数据少了，排障也会清爽很多。
5.2 容器里时区不对、中文显示乱码
镜像拉的官方版本默认是 UTC 时区。测试脚本里datetime.now()打印出来的时间比本地时间早 8 小时。如果你只看日志内容，很难第一时间意识到是时区问题，会把时间误差当成业务 bug。排查方法是执行date -R查看时区，再加环境变量TZ=Asia/Shanghai或调整 Dockerfile。
中文乱码的问题主要出现在需要渲染文字或者打印中文日志的场景。原因是基础镜像的系统语言环境没有配置C.UTF-8或zh_CN.UTF-8。在 Dockerfile 里加一句：
ENV LANG=C.UTF-8 ENV LC_ALL=C.UTF-8大部分场景就能解决。如果系统里没有生成中文字符集环境，某些精简镜像还需要额外安装locales包。在测试镜像里保留中文环境支持，比每次进容器后再去处理要省事。
5.3 容器一启动就退出
“我这个容器怎么跑不起来，一启动就退了。”这个问题在测试同事那被问过无数次。最常见的直接原因：容器内的主进程结束了。Docker 容器不是虚拟机，它的生命周期跟主进程一致，主进程退出，容器就退出；如果主进程是后台守护进程，没有前台进程霸占着，也会秒退。
比如你执行：
docker run image-name nginx -t这是测试 nginx 配置的命令，执行完就退出了，容器自然也就停了。你需要的是nginx -g "daemon off;"，让主进程前台运行。很多基础镜像默认的 CMD 已经处理了前台问题，但你自己写镜像时很容易踩坑。
解决办法是查看容器退出码和日志：
docker ps -a docker logs container-id确认主进程是什么、日志报了什么错。如果只是为了临时验证，还可以用docker run --entrypoint /bin/bash进去手工操作，排查是不是启动脚本、依赖文件的问题。记住一句话：容器启动失败，先看日志，再看退出码，最后才猜原因。
5.4 镜像构建成功但运行时缺依赖
构建 Dockerfile 的过程中一切正常，docker run时才报错，比如“No such file or directory”或者找不到某个动态库。这个现象有几种常见原因：
第一种，运行期间依赖的文件没有复制进镜像。比如你的脚本运行时需要读取某个配置文件，而 Dockerfile 里只 COPY 了代码，没 COPY 配置。
第二种，动态链接库缺失。镜像在构建和运行的环境可能不一致：构建时依赖的某些库在运行阶段不存在。合理做法是确保 Dockerfile 里把运行期需要的所有系统依赖都用apt-get install明确安装。
第三种，入口脚本换行符或者权限问题。Linux 下执行 shell 脚本如果是从 Windows 拷过去的，\r\n会导致执行报错；脚本没有执行权限也会报 Permission denied。我处理过一次：脚本内容没问题，就是run_tests.sh没有chmod +x，导致镜像里执行脚本失败。Dockerfile 里加一行RUN chmod +x run_tests.sh，问题解决。
5.5docker exec进不了容器
docker exec是测试过程中进入运行中容器排查问题的常用命令。如果执行时报错，先看容器是否在运行（docker ps），再看你指定的 shell 在镜像里是否存在。
一个真实案例：某个基础镜像没有bash，只有sh，我直接docker exec -it container /bin/bash，结果报错。换成/bin/sh就好了。还有一次，容器里连sh都被限制，只能使用镜像指定入口启动主进程，这种时候要考虑在 Dockerfile 里主动加入bash和常用调试工具，确保后续排查能顺利进行。
6. 镜像的日常维护和团队协作建议
最后聊一点镜像在团队里怎么管理，这个问题很多测试团队没有花精力重视，等规模大了才发现很痛苦。
6.1 镜像命名规范
镜像名如果随意起，时间一长就分不清谁是谁。我建议团队内部统一一套命名规则，比如：项目名-组件名:版本号，或者加上用途前缀test-、base-、runtime-。
标签尽量用语义化版本号，不要只用latest。版本号格式可以和应用的版本一致，比如api-test:1.2.3。如果对应某次测试固件版本，还可以加后缀，比如api-test:1.2.3-regression-20240610。
6.2 镜像仓库的搭建
测试团队使用 Docker，不一定要搭一个完整的私有仓库，但至少要有一个团队共享的镜像存放地。最开始团队可能只有一个人自己做镜像，相互之间通过docker save和docker load传递镜像文件，这种方式在小团队里能用，但版本一旦多起来非常混乱。
更合适的做法是搭一个简单的私有仓库，比如用 Docker 官方提供的registry镜像：
docker run -d -p 5000:5000 --name registry registry:2然后把本地镜像推上去：
docker tag demo-api-tests:1.0.0 registry-host:5000/demo-api-tests:1.0.0 docker push registry-host:5000/demo-api-tests:1.0.0其他机器拉取：
docker pull registry-host:5000/demo-api-tests:1.0.0这就是一个可用的最小私有仓库。后续还能加上基于目录和身份验证的管理功能，不过对测试团队来说，先把统一存储做好已经很受益了。我见过不少测试团队所有镜像都存本机、没有统一存放地，最后每个人拉的镜像都不一样，环境永远对不上。私有仓库这一招几乎是一劳永逸地解决了这个问题。
6.3 Dockerfile 纳入代码仓库管理
Dockerfile 本质上是配置文件，应该跟着项目代码一起维护，放进代码仓库而不是散落在个人机器上。这样有几个好处：改动有记录、版本可回溯、任何成员拉下来都能看明白镜像是怎么构建的。配合 CI 的自动构建，测试团队还能在每次提交代码后自动打出测试镜像，省去手工维护的功夫。
我自己在团队里比较推荐的流程是：代码仓库里每个需要构建镜像的项目放一个docker/目录，Dockerfile 和.dockerignore放一起，README.md里写清楚镜像用途、基础镜像版本来源、常用运行参数、注意事项。这样即使有人几个月没碰这个项目，也能照文档还原一套环境。
6.4 镜像安全与审计意识
很多测试人员觉得“测试环境无所谓”，于是随便拉镜像、随便跑容器。实际不是这样的。镜像里可能包含的是基础系统、第三方库和业务代码，任何一个环节出了安全问题，影响的都不只是当前容器。测试数据、数据库密码、接口凭据如果通过环境变量或文件传进容器，而这些信息又是明文写在镜像里的，那就等于泄露给所有能拉取这个镜像的人。
我的建议是：镜像里不要写死任何密码、Token、密钥；需要用到敏感信息时通过运行时环境变量、挂载文件或者配置中心传入。测试团队还应该定期检查镜像里的依赖有没有已知漏洞，这个不用搞得太复杂，基础镜像更新到新版、第三方库升级到安全版本就够了。
最后分享一点经验
从我开始在测试团队里推广 Docker 到现在，最大的体会是：镜像解决了“环境不一致”这一测试行业的老大难问题，但它本身也需要像代码一样被规范管理。不要贪快，不要只停留在docker pull、docker run的层面。花半天时间把所有用到的测试中间件镜像统一规格，写一份简单的镜像使用手册，建立一个共享仓库，以后每次排障节省的时间都远超当初的投入。
还有一个小技巧收个尾：如果你发现某个容器跑起来之后操作系统占用奇高或者日志刷个不停，先别急着重启，用docker stats看一下资源占用，用docker logs看看主进程输出了什么。镜像和容器再好，排查问题也还是离不开日志和基础命令。先看日志，再看配置，最后才怀疑镜像本身，这个顺序能帮你少走很多弯路。
