gitlab-runner 的 executors 之 docker

  • GitLab Runner 实现了许多执行程序，可用于在不同的场景中运行构建。所有执行程序分别为：
  • SSH
  • Shell
  • Parallels
  • VirtualBox
  • Docker
  • Docker Machine (auto-scaling)
  • Kubernetes
  • Custom
  • 本文主要介绍 docker 执行程序：
  • 两种不同的使用方式
  • 踩过的坑
  • 一些例子与经验

两种使用方式

docker-in-docker

sudo gitlab-runner register -n \
   --url https://gitlab.com/ \
   --registration-token REGISTRATION_TOKEN \
   --executor docker \
   --description "My Docker Runner" \
   --docker-image "docker:stable" \
   --docker-privileged
  • 以上命令将注册一个使用docker:stable镜像的 Runner，它使用privileged模式启动构建和服务容器。这也是使用docker-in-docker模式必须使用的设置

注意：通过--docker-privileged启用特权模式，禁用容器的所有安全机制，并将主机暴露在权限提升中，这可能导致容器中断。更多信息查看 Docker 官方文档运行时特权和 linux 功能

  • 上面的命令得到对应配置文件如下
[[runners]]
   url = "https://gitlab.com/"
   token = TOKEN
   executor = "docker"
   [runners.docker]
     tls_verify = false
     image = "docker:stable"
     privileged = true
     disable_cache = false
     volumes = ["/cache"]
   [runners.cache]
     Insecure = false
image: docker:latest

services:
  - docker:dind

build:
  stage: build
  script:
    - docker build -t test .
  • 缺点和不足如下：
  • 使用 docker-in-docker 时，每个作业都处于干净的环境中，没有过去的历史记录。并发任务执行正常，因为每个构建都有自己的 Docker 引擎实例，因此它们不会相互冲突。但这也意味着工作可能会变慢，因为没有层缓存
  • 默认情况下，docker:dind 使用的--storage-driver vfs 是最慢的形式。要使用其他驱动程序，请参阅 使用 overlayfs 驱动程序
  • 由于 docker:dind 容器和运行器容器不共享其根文件系统，因此任务的工作目录可用作子容器的安装点。例如，如果您要与子容器共享文件，则可以在/builds/$CI_PROJECT_PATH 其下创建子目录并将其用作挂载点（有关更详细的说明，请查看问题＃41227）

使用 Docker 套接字绑定

  • 另一种方法是绑定/var/run/docker.sock到容器中，以便 Docker 在该映像的上下文中可用

注意：如果在使用 GitLab Runner 11.11 或更高版本时绑定 Docker 套接字，则无法再将其 docker:dind 用作服务，因为也会对服务进行卷绑定，从而使这些服务不兼容

  • Runner 注册命令如下
sudo gitlab-runner register -n \
   --url https://gitlab.com/ \
   --registration-token REGISTRATION_TOKEN \
   --executor docker \
   --description "My Docker Runner" \
   --docker-image "docker:stable" \
   --docker-volumes /var/run/docker.sock:/var/run/docker.sock
  • 以上命令将注册一个使用docker:stable镜像的 Runner。注意：他是用的是 Runner 本身的 Docekr 守护程序，而 docker 命令生成的任何容器都是 Runner 的兄弟，而不是 Runner 的子节点。
  • 上面的命令得到对应配置文件如下
[[runners]]
   url = "https://gitlab.com/"
   token = REGISTRATION_TOKEN
   executor = "docker"
   [runners.docker]
     tls_verify = false
     image = "docker:stable"
     privileged = false
     disable_cache = false
     volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
   [runners.cache]
     Insecure = false
  • 对应的.gitlab-ci.yml例子如下
image: docker:stable

before_script:
  - docker info

build:
  stage: build
  script:
    - docker build -t my-docker-image .
    - docker run my-docker-image /script/to/run/tests
  • 可以看到，这个模式不需要使用服务，直接通过套接字通信。此模式也是有一些需要注意的地方：
  • 由于是共享 docker 守护程序，项目的操作会真实产生影响。比如项目如果运行docker rm -f $(docker ps -a -q)，那么将会删除所有容器
  • 并发可能会有冲突，比如创建相同的名称的容器
  • 由于创建的容器是 Runnner 的兄弟，所以文件与目录的共享是在主机上下文完成，而不是构建容器上下文

总结

  • 选择两种方式都各有好坏，可根据实际情况进行选择。这里还是推荐用第二种，因为第一种真的很干净，所以很慢
  • 做好权限管理和控制，避免危险的脚本
  • 还有一点是，指定镜像版本的时候，最好指定具体的版本。比如使用第一种模式，引入服务docker:dind，最好使用docker:18.09.8-dind。避免镜像拉取策略，每次拉取最新的镜像，导致实际是docker:19.0-dind，与安装的 docker 版本不符，发生一些意想不到的错误