我怎样才能让gitlab-ci-runner的DinD图像缓存中间图像？

Question

我有一个Dockerfile,从安装texlive-full软件包开始,这是一个巨大的,需要很长时间.如果我docker build在本地,安装后创建的中间图像被缓存,后续构建很快.

但是,如果我推送到我自己的GitLab安装并启动GitLab-CI构建运行器,这似乎总是从头开始,重新下载FROM映像,再次执行apt-get安装.这对我来说似乎是一个巨大的浪费,所以我试图弄清楚如何让GitLab DinD图像在构建之间缓存中间图像,到目前为止没有运气.

我已经使用了尝试--cache-dir,并--docker-cache-dir为gitlab-runner register命令,都无济于事.

这甚至是gitlab-runner DinD图像应该能够做到的吗？

我的.gitlab-ci.yml:

build_job:
    script:
    - docker build --tag=example/foo .

我的Dockerfile:

FROM php:5.6-fpm
MAINTAINER Roel Harbers <roel.harbers@example.com>
RUN apt-get update && apt-get install -qq -y --fix-missing --no-install-recommends texlive-full
RUN echo Do other stuff that has to be done every build.

我使用GitLab CE 8.4.0和gitlab/gitlab-runner:latest作为跑步者

docker run -d --name gitlab-runner --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /usr/local/gitlab-ci-runner/config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest \
; \

跑步者使用以下方式注册:

docker exec -it gitlab-runner gitlab-runner register \
    --name foo.example.com \
    --url https://gitlab.example.com/ci \
    --cache-dir /cache/build/ \
    --executor docker \
    --docker-image gitlab/dind:latest \
    --docker-privileged \
    --docker-disable-cache false \
    --docker-cache-dir /cache/docker/ \
; \

这会创建以下内容config.toml:

concurrent = 1
[[runners]]
    name = "foo.example.com"
    url = "https://gitlab.example.com/ci"
    token = "foobarsldkflkdsjfkldsj"
    tls-ca-file = ""
    executor = "docker"
    cache_dir = "/cache/build/"
    [runners.docker]
        image = "gitlab/dind:latest"
        privileged = true
        disable_cache = false
        volumes = ["/cache"]
        cache_dir = "/cache/docker/"

(我已经尝试了不同的值cache_dir,docker_cache_dir并且disable_cache都有相同的结果:没有任何缓存)

Answer 1

我想你的问题没有简单的答案.在添加一些细节之前,我强烈建议您阅读DinD维护者的这篇博客文章,该文章最初名为"不要在Docker中使用Docker for CI".

您可能会尝试/var/lib/docker将GitLab跑步者声称为音量.但要注意,根据您的文件系统驱动程序,您可以在主机上的AUFS文件系统上的容器中使用AUFS,这很可能会导致问题.

我建议你创建一个单独的 Docker-VM,仅用于跑步者,并docker.sock从VM 绑定到你的跑步者容器.我们正在使用GitLab的这种设置取得了巨大成功(大约12个月内大于27.000次构建).

你可以看看我们的跑步者的docker-compose支持,这实际上是基于GitLab跑步者的shell执行者.