Question

我正在尝试为我们的一个项目建立新的构建管道。第一步，我将构建一个新的docker映像以进行后续测试。此步骤工作正常。但是，在执行测试作业时，将拉出映像，但是命令在主机而不是容器上运行。

这是我的gitlab-ci.yml的内容：

stages:
  - build
  - analytics

variables:  
  TEST_IMAGE_NAME: 'registry.server.de/testimage'

build_testing_container:
  stage: build

  image: docker:stable
  services:
  - dind

  script:
    - docker build --target=testing -t $TEST_IMAGE_NAME .
    - docker push $TEST_IMAGE_NAME

mess_detection:
  stage: analytics
  image: $TEST_IMAGE_NAME

  script:
    - vendor/bin/phpmd app html tests/md.xml --reportfile mess_detection.html --suffixes php

  artifacts:
    name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
    paths:
      - mess_detection.html
    expire_in: 1 week
    when: always

  except:
    - production

  allow_failure: true

要使gitlab运行程序在成功提取的容器内执行script命令，我需要更改什么？

更新：

它变得越来越有趣：我只是将脚本更改为休眠一会儿，以便可以附加到容器。当我从ci脚本运行密码时，它显示为/builds/namespace/project。但是，使用完全相同的容器在pwd上在服务器上运行docker exec时，它会返回/app。

UPDATE2：

经过更多研究，我了解到gitlab为每个构建步骤执行四个子步骤：

经过更多研究，我发现gitlab为每个构建步骤运行4个子步骤：

准备：创建并启动服务。
预构建：从上一阶段克隆，还原缓存并下载工件。这是在特殊的Docker映像上运行的。
内部版本：用户内部版本。这是在用户提供的Docker映像上运行的。
构建后：创建缓存，将工件上传到GitLab。这是在特殊的Docker映像上运行的。

在我看来，第3步未正确执行，并且该命令仍在gitlabRunner docker映像内运行。

UPDATE3 同时，我测试了使用命令mess_detection在另一台机器上执行gitlab-runner exec docker mess_detection步骤。行为是完全相同的。因此，它不是特定于gitlab的，而必须是部署脚本或运行器配置中的某些配置选项。

Answer 1

这是通常的行为image关键字是Docker执行程序将运行以执行CI任务的Docker映像的名称。您可以使用services关键字定义仅在您的工作期间运行的另一个Docker映像，该映像链接到image关键字定义的Docker映像。这样，您就可以在构建期间访问服务映像。可以通过脚本或入口点进行访问，例如：在要构建的映像的docker文件中，添加要执行的脚本，如下所示：

ADD exemple.sh /

RUN chmod +x exemple.sh

然后您可以在gitlab-ci中将图像添加为服务，脚本将变为：

docker exec <container_name> /exemple.sh

这将在容器内运行脚本或指定docker映像的入口点，然后脚本将是：

docker exec <container> /bin/sh -c "cmd1;cmd2;...;cmdn"

这里是参考：

https://docs.gitlab.com/ee/ci/docker/using_docker_images.html

Gitlab CI docker-in-docker部署未在容器内运行命令

1 个答案: