基于Google Cloud Kubernetes的Jenkins中docker-compose CI测试方案求助

我之前在GCP Kubernetes上搭建Jenkins CI时，也碰到过docker-in-docker（dind）各种不靠谱的问题，尤其是要集成本地用docker-compose跑的测试场景。这里给你几个亲测有效的方案，你可以根据自己的集群环境和测试需求选：

方案1：挂载宿主机Docker Socket（快速适配现有测试） #

这是最直接的方案，跳过dind，让Jenkins Agent直接调用宿主机的Docker daemon，自然就能正常运行docker-compose命令。

• 具体配置：在Jenkins的Kubernetes Agent Pod模板里，添加Docker Socket的挂载：

  spec:
    volumes:
      - name: docker-socket
        hostPath:
          path: /var/run/docker.sock
    containers:
      - name: jenkins-agent
        image: your-jenkins-agent-image:latest
        volumeMounts:
          - mountPath: /var/run/docker.sock
            name: docker-socket
  

• 注意事项：
  • 要确保Agent使用的ServiceAccount有足够权限访问宿主机资源
  • 这种方式存在一定安全风险（容器能直接控制宿主机Docker），适合私有可控的集群环境，公共集群建议谨慎使用

方案2：用Kaniko替代Docker构建，配合DooD跑测试 #

如果你的测试流程包含镜像构建，Kaniko是Google推出的无daemon镜像构建工具，不需要特权模式，更适合K8s环境。

• 流程拆分：
  1. 先用Kaniko构建测试所需的镜像，推送到GCR（Google Container Registry）
  2. 再用挂载Socket的方式（方案1）运行docker-compose启动测试服务
• Jenkins Pipeline示例：

  pipeline {
    agent { kubernetes { yaml 'your-agent-pod.yaml' } }
    stages {
      stage('Build Test Images') {
        steps {
          container('kaniko') {
            sh '''
              # 生成GCR认证配置
              cat > kaniko-config.json << EOF
              {"auths":{"gcr.io":{"username":"_json_key","password":"$(cat /var/run/secrets/google-cloud/service-account.json)"}}}
              EOF
              # 构建并推送镜像
              kaniko --context=./ --dockerfile=Dockerfile.test --destination=gcr.io/your-project/test-image:latest --docker-config=./kaniko-config.json
            '''
          }
        }
      }
      stage('Run Tests with Docker Compose') {
        steps {
          sh 'docker-compose -f docker-compose.test.yml up --abort-on-container-exit'
        }
      }
    }
  }
  

方案3：用Kind搭建迷你K8s集群跑测试（更贴近生产环境） #

如果你的测试依赖多容器协作，也可以放弃docker-compose，用Kind（Kubernetes in Docker）在Agent里启动一个迷你K8s集群，把测试服务部署进去。这种方式完全不需要dind，更符合K8s原生环境。

• 步骤示例：
  1. 在Jenkins Agent镜像中预装Kind和kubectl
  2. 在Pipeline中启动Kind集群：kind create cluster
  3. 部署测试服务的K8s Manifest：kubectl apply -f test-service-manifests/
  4. 执行测试命令：kubectl exec test-pod -- ./run-tests.sh
  5. 测试完成后清理集群：kind delete cluster
• 优势：测试环境和生产K8s环境一致，避免docker-compose和K8s之间的环境差异问题

方案4：用Jenkins Docker Pipeline Plugin的DooD模式 #

Jenkins官方的Docker插件支持Docker outside Docker（DooD）模式，帮你封装了Socket挂载的配置，用起来更便捷。

• Pipeline示例：

  pipeline {
    agent {
      kubernetes {
        yaml '''
          apiVersion: v1
          kind: Pod
          spec:
            containers:
              - name: docker
                image: docker:24.0.6-alpine
                command: ["sleep", "99d"]
                volumeMounts:
                  - mountPath: /var/run/docker.sock
                    name: docker-socket
            volumes:
              - name: docker-socket
                hostPath:
                  path: /var/run/docker.sock
        '''
      }
    }
    stages {
      stage('Run Compose Tests') {
        steps {
          container('docker') {
            # 安装docker-compose（alpine镜像默认没有）
            sh 'apk add --no-cache docker-compose'
            # 启动测试并跟随测试容器的退出码
            sh 'docker-compose -f docker-compose.test.yml up --exit-code-from test-container'
          }
        }
      }
    }
  }
  

你可以先试试方案1或4，这两个能最快适配你现有的docker-compose测试流程；如果想长期往K8s原生方向优化，方案3会更合适。

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