gitlab-runner 的 executors 之 docker

梦想的初衷 提交于 2020-05-09 15:59:04

gitlab-runner 的 executors 之 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 版本不符,发生一些意想不到的错误
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!