Gitlab CI-使用共享运行程序构建Docker映像(无法连接到Docker Daemon)

时间:2018-07-31 14:41:38

标签: docker gitlab

我目前正在使用Gitlab Shared Runners构建和部署我的项目(至少我也正在尝试!)。

我下面有gitlab-ci.yml:

image: java:8-jdk

stages:
  - build
  - package

before_script:
  - export GRADLE_USER_HOME=`pwd`/.gradle
  - docker info

cache:
  paths:
    - .gradle/wrapper
    - .gradle/caches
build:
  stage: build
  script:
    - ./gradlew build
  artifacts:
    paths:
      - build/libs/*.jar
    expire_in: 1 week
  only:
    - master

docker-build:
  image: docker:stable
  services:
   - docker:dind
  stage: package
  script:
    docker build -t registry.gitlab.com/my-project .
    docker push registry.gitlab.com/my-project

after_script:
  - echo "End CI"

首先,构建阶段做得很好,但是第二个阶段在我尝试构建并推送Docker映像时出现了问题。

我收到此日志:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

看来,Gitlab正在使用无法构建docker映像的共享运行器,但是我不知道如何更改它。我无法更改运行程序的配置,因为我正在使用共享运行程序。我还尝试在第二阶段添加一些标签,希望有一个更合适的跑步者来照顾我的工作,但是我仍然遇到这个错误。

谢谢您的帮助。

3 个答案:

答案 0 :(得分:5)

我相信您需要设置var conn = DDP.connect(Meteor.absoluteUrl()); DDP.loginWithPassword(conn, {username: 'admin'}, 'admin', function (error) { // .... if no error you are free to go }) 才能连接到在另一个容器中运行的DinD:

// call remote project's method
conn.call('methodName', params, callback) 

// subscribe to remote project's publication 
conn.subscribe('pubName', params) 

答案 1 :(得分:1)

如果您共享runner executor is of type docker,则可以尝试以下设置:

stages:
  - build
  - package

before_script:
  - export GRADLE_USER_HOME=`pwd`/.gradle
  - docker info

cache:
  paths:
    - .gradle/wrapper
    - .gradle/caches
build:
  image: java:8-jdk
  stage: build
  script:
    - ./gradlew build
  artifacts:
    paths:
      - build/libs/*.jar
    expire_in: 1 week
  only:
    - master

docker-build:
  stage: package
  script:
    docker build -t registry.gitlab.com/my-project .
    docker push registry.gitlab.com/my-project

after_script:
  - echo "End CI"

答案 2 :(得分:0)

即使我们在组织中也遇到过同样的问题。我们发现gitlab的docker区域中的docker长期存在问题,可以在这些问题#3612#2408#2890中进行跟踪。

我们发现,在本例中,使用docker绑定比使用docker-in-docker更适合我们的用例。因此,我们在他们的official page中使用了该解决方案。

我知道这已经得到回答,但这可能会帮助一些具有类似用例的人:)