GitLab CI中MySQL服务未读取variables配置导致连接失败

问题分析 #

你遇到的核心问题是MySQL服务容器未正确接收MYSQL_ALLOW_EMPTY_PASSWORD变量，导致初始化时提示缺少必填的密码配置项。尽管在多个位置设置了变量，但Helm部署的GitLab Runner（Kubernetes执行器）可能存在变量传递限制，或重复设置引发变量覆盖/未正确传递到服务容器的情况。

解决方案 #

1. 简化配置，确保变量正确传递 #

移除不必要的重复变量设置，仅在服务的variables块中配置MySQL所需环境变量，避免全局/作业变量的干扰：

mysql-test:
  stage: test
  needs: []
  # 使用mysql镜像提供客户端工具
  image: mysql:8.0.28
  services:
    - name: mysql:8.0.28
      alias: mysql
      variables:
        MYSQL_DATABASE: mysql_test
        # 改用空字符串的MYSQL_ROOT_PASSWORD，绕过部分镜像的变量检查逻辑
        MYSQL_ROOT_PASSWORD: ""
  script:
    # 等待MySQL服务完全初始化，避免直接执行命令时连接拒绝
    - until mysqladmin ping -h mysql -u root --password='' --silent; do sleep 2; done
    - echo SELECT 'OK' | mysql mysql_test --host='mysql' --user=root --password=''

2. 检查GitLab Runner的Kubernetes配置 #

若使用Helm部署的Kubernetes Runner，需确保以下配置：

• 查看runner的config.toml文件，确认[runners.kubernetes]下未禁用环境变量传递
• 确保runner的privileged选项设为true（MySQL容器初始化可能需要相关权限）

3. 调试变量传递（可选） #

若问题仍存在，可在作业脚本中添加调试命令，确认服务容器是否接收变量：

script:
  # 仅用于调试，需runner具备kubectl权限
  - kubectl exec -it $(kubectl get pods -l app=mysql -o name) -- env | grep MYSQL_

关键说明 #

• 部分MySQL 8.0镜像的entrypoint脚本对MYSQL_ALLOW_EMPTY_PASSWORD的处理存在兼容性问题，改用MYSQL_ROOT_PASSWORD: ""能更可靠地启用空密码登录
• MySQL服务启动后需要几秒完成初始化，直接执行客户端命令会触发连接拒绝，添加等待逻辑可解决该问题

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