tag stages run dind compose docker gitlab gitlab-ci gitlab-ci-runner

docker - stages - ¿Cómo puedo dejar que la imagen DinD del gitlab-ci-runner guarde imágenes intermedias?



gitlab docker registry (3)

Tengo un Dockerfile que comienza con la instalación del paquete texlive-full, que es enorme y lleva mucho tiempo. Si no docker build localmente, la imagen interna creada después de la instalación se almacena en caché y las compilaciones posteriores son rápidas.

Sin embargo, si presiono mi propia instalación de GitLab y se inicia el compilador GitLab-CI build, esto siempre parece comenzar desde cero, volver a descargar la imagen FROM y volver a instalar apt-get. Esto me parece una gran pérdida, así que estoy tratando de encontrar la forma de obtener la imagen DinD de GitLab para almacenar en caché las imágenes intermedias entre compilaciones, sin suerte hasta el momento.

He intentado usar el --cache-dir y --docker-cache-dir para el gitlab-runner register , en vano.

¿Es esto incluso algo que se supone que puede hacer la imagen DinD de gitlab-runner?

Mi .gitlab-ci.yml :

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

My Dockerfile :

FROM php:5.6-fpm MAINTAINER Roel Harbers <[email protected]> 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.

Uso GitLab CE 8.4.0 y gitlab / gitlab-runner: último como corredor, iniciado como

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 / ; /

El corredor se registra usando:

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/ / ; /

Esto crea el siguiente 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/"

(He experimentado con diferentes valores para cache_dir , docker_cache_dir y disable_cache , todos con el mismo resultado: sin almacenamiento en caché en absoluto)


Actualmente no puede almacenar capas intermedias en GitLab Docker-in-Docker. A pesar de que hay planes para agregar eso (que se mencionan en el siguiente enlace). Lo que puedes hacer hoy para acelerar tu compilación DinD es usar el sistema de archivos superpuesto. Para hacer esto, debe ejecutar un kernel liunx> = 3.18 y asegúrese de cargar el módulo de kernel de superposición. Luego configuras esta variable en tu gitlab-ci.yml:

variables: DOCKER_DRIVER: overlay

Para obtener más información, consulte este tema y, en particular, este comentario sobre "El estado de optimización de Docker Builds!", Consulte la sección "Uso de docker executor with dind".

https://gitlab.com/gitlab-org/gitlab-ce/issues/17861#note_12991518


Para las dependencias de compilación que no cambian con tanta frecuencia, puede hacer un poco de caché manual con el registro de imágenes de gitlab. En el script de CI no llama explícitamente a la docker build sino que la envuelve en un script de shell

# cat build_dependencies.sh registry=registry.example.com project=group/project imagebase=$registry/$project/linux docker pull $imagebase/devbase:1.0 if [ $? -ne 0 ]; then docker build -f devbase.dockerfile -t $imagebase/devbase:1.0 . docker push $imagebase/devbase:1.0 fi ...

y llame a ese script en su CI

... script: - ./build_dependencies.sh

La desventaja de esto es que cuando se actualiza su devbase.dockerfile esto devbase.dockerfile desapercibido para CI, por lo que debe forzar la creación y el empuje de una nueva imagen. Por lo tanto, para cambiar dinámicamente las imágenes, esto no funciona bien, pero para su caso de uso, esto parece una manera posible de hacerlo.


Supongo que no hay una respuesta simple a tu pregunta. Antes de agregar algunos detalles, sugiero leer este artículo del blog del desarrollador de DinD, que originalmente se llamaba "Docker Docker Docker for CI".

Lo que podría intentar es declarar /var/lib/docker como un volumen para su corredor GitLab. Pero ten en cuenta que, dependiendo de los controladores del sistema de archivos, puedes usar AUFS en el contenedor de un sistema de archivos AUFS en tu host, lo que es muy probable que cause problemas.

Lo que le sugiero es crear una Docker-VM separada , solo para los corredores, y atar-montar docker.sock desde la VM en su contenedor-corredor. Estamos utilizando esta configuración con GitLab con gran éxito (> 27.000 versiones en aproximadamente 12 meses).

Puede echarle un vistazo a nuestro corredor con el soporte docker-compose que en realidad se basa en el ejecutor de shell del corredor de GitLab.