GitLab Docker Runner中Elasticsearch服务启动失败：容器名称冲突

我来帮你搞定这个GitLab CI里的Elasticsearch容器命名冲突问题——这个坑我之前也踩过，给你分步骤说清楚怎么解决：

问题根源 #

你遇到的报错，核心是GitLab Runner用来检测服务是否就绪的wait-for-service辅助容器没被彻底清理。哪怕这些容器已经停止运行，它们的名字还是会被Docker保留着，导致新的CI任务要创建Elasticsearch服务时，就会触发“容器名已被占用”的冲突。虽然你升级到了10.6版本，但这个版本的Runner在自动清理残留容器的逻辑上还有bug，没法彻底删掉这些废弃容器。

立即修复：先解决当前的冲突 #

1. 清理所有残留的wait-for-service容器 #

登录你的GitLab Runner服务器，执行这条命令，把所有名字里带wait-for-service的容器（不管是运行中还是已停止的）都删掉：

docker rm $(docker ps -aq --filter "name=wait-for-service")

这条命令会先筛选出所有符合条件的容器ID，再批量删除，直接解决当前的命名冲突，让下一次CI任务能正常创建Elasticsearch容器。

2. 临时规避：给ES服务加自定义别名 #

如果不想立刻清理容器，也可以先在.gitlab-ci.yml里给Elasticsearch服务加个自定义别名，这样Runner会生成不同的容器名称，避开残留的旧容器名：

services:
  - mysql:latest
  - redis:latest
  - name: elasticsearch:latest
    alias: elasticsearch-test

之后你的测试代码里，连接ES的主机名要改成elasticsearch-test哦。

长期优化：从根源避免问题 #

1. 配置Runner自动清理容器 #

修改GitLab Runner的配置文件（通常在/etc/gitlab-runner/config.toml），添加cleanup = true配置，让Runner在任务结束后自动删掉所有相关容器：

[[runners]]
  # 保留你原来的其他配置
  executor = "docker"
  [runners.docker]
    # 保留你原来的其他配置
    cleanup = true
    pull_policy = "if-not-present"
    volumes = ["/cache"]

修改完后重启Runner服务：

gitlab-runner restart

cleanup = true会让Runner在CI任务完成后，自动清理所有服务容器和wait-for-service辅助容器，从根源上避免残留容器导致的命名冲突。

2. 别用latest标签的ES镜像 #

elasticsearch:latest会自动拉取最新版本的ES，不仅可能和你的测试代码有兼容性问题，还可能因为镜像更新导致Runner创建容器时出意外。建议指定具体的ES版本，比如和你生产环境一致的版本：

services:
  - mysql:latest
  - redis:latest
  - elasticsearch:7.17.0 # 换成你实际需要的版本

3. 检查Runner的并发配置 #

如果你的Runner并发数设置得太高，多个任务同时创建容器时，命名冲突的概率会大大增加。可以适当调整config.toml里的concurrent值，或者给不同的任务分配不同的Runner标签，让任务分散执行。

验证修复 #

做完上面的步骤后，手动触发一次CI任务，看看日志里还会不会出现容器命名冲突的报错。同时可以用docker ps -a检查，确认任务结束后所有相关容器都被正确清理了。

内容的提问来源于stack exchange，提问作者pilec