2016-02-22 16 views
27

Ho un Dockerfile che inizia con l'installazione del pacchetto texlive-full, che è enorme e richiede molto tempo. Se I docker build localmente, l'immagine intermedia creata dopo l'installazione viene memorizzata nella cache e le build successive sono veloci.Come posso lasciare che le immagini intermedie della cache di immagini DinD di gitlab-ci-runner?

Tuttavia, se si esegue il push della mia installazione di GitLab e viene avviato il builder GitLab-CI, questo sembra sempre iniziare da zero, scaricare di nuovo l'immagine FROM e eseguire di nuovo apt-get install. Questo mi sembra un enorme spreco, quindi sto cercando di capire come ottenere l'immagine GDD di GitLab per memorizzare le immagini intermedie tra le build, senza fortuna fino ad ora.

Ho provato a utilizzare il --cache-dir e --docker-cache-dir per il comando gitlab-runner register, senza alcun risultato.

E 'forse questo qualcosa che l'immagine DinD di gitlab-runner dovrebbe essere in grado di fare?

mio .gitlab-ci.yml:

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

mio 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. 

Io uso GitLab CE 8.4.0 e gitlab/gitlab-runner: ultima come corridore, iniziato come

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

Il corridore è registrato utilizzando:

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

questo crea il seguente 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/" 

(Ho sperimentato con valori diversi per cache_dir, docker_cache_dir e disable_cache, tutte con lo stesso risultato: no cache di alcun tipo)

+0

Sto assumendo "Dind" sta per Docker-in-Docker? – BrokenBinary

+0

Sì, DinD è la terminologia di Gitlab per l'esecuzione della finestra mobile all'interno di un contenitore e forniscono un'immagine predefinita per questo scopo: https://hub.docker.com/r/gitlab/dind/ –

+0

Ciao, stai accettando i cambiamenti di il DinD all'immagine docker? L'immagine DinD si sta riavviando del tutto se ciò causa la perdita della cache poiché non si sta effettuando il commit della cache su una nuova immagine di finestra mobile. – Deckerz

risposta

12

Suppongo che non c'è semplice risposta alla tua domanda. Prima di aggiungere alcuni dettagli, consiglio vivamente di leggere this blog article dal manutentore di DinD, che in origine era chiamato "non utilizzare Docker in Docker per CI".

Quello che potresti provare è dichiarare /var/lib/docker come volume per il tuo runner GitLab. Ma attenzione, a seconda dei driver del tuo sistema di file puoi usare AUFS nel contenitore su un filesystem AUFS sul tuo host, che molto probabilmente causerà problemi.

Quello che io suggerirei a voi sta creando una separata Docker-VM, solo per il corridore (s), e legare-Mount docker.sock dalla VM nel vostro runner-contenitore. Stiamo usando questa installazione con GitLab con grande successo (> 27.000 build in circa 12 mesi).

Potete dare un'occhiata al nostro runner with docker-compose support che è in realtà basato sul shell-executor del corridore di GitLab.

+0

Se due build vengono eseguite contemporaneamente ed entrambe creano ad esempio un'immagine denominata "temp", non si otterrebbe un conflitto? Non è esattamente questo il motivo per cui le persone usano DinD? – AndreKR

+1

Stiamo impostando 'COMPOSE_PROJECT_NAME' su buildpipeline' CI_BUILD_PIPELINE', vedere https://github.com/dmstr/phd5-app/blob/b6921e3c27dafb00217bdc899923bc91bbbb443a/.gitlab-ci.yml#L13-L14 - che si traduce in un perfetto isolamento delle pile. – schmunk

+0

Un'altra opzione è creare immagini taggate con docker-compose (sintassi v2), ad esempio: 'image: mynamespace/myimage: $ {APP_VERSION}' – schmunk

3

Attualmente non è possibile memorizzare nella cache i livelli intermedi in GitLab Docker-in-Docker. Anche se ci sono piani per aggiungere che (che sono menzionati nel link sottostante). Quello che puoi fare oggi per accelerare la tua build DinD è usare il filesystem di overlay. Per fare ciò è necessario avere un kernel liunx> = 3.18 e assicurarsi di caricare il modulo del kernel overlay. Quindi imposti questa variabile nel tuo gitlab-ci.yml:

variables: 
    DOCKER_DRIVER: overlay 

Per ulteriori informazioni vedere questo problema e, in particolare, questo commento su, vedere la "Uso finestra mobile esecutore con Dind" sezione "Lo stato di ottimizzare Docker Builds!".

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

Problemi correlati