Concourse CI: consente di sfruttare la cache dell'image

Capisco totalmente che il Concourse è destinato ad essere apolide, ma comunque c'è qualche modo per riutilizzare le immagini già esistenti del docker? Nel mio caso, costruisco ~ 10 immagini docker che hanno la stessa image base, ma each volta che viene generata la build Concourse tira l'image base 10 volte.

È ansible tirare questa image una volta e riutilizzarla più tardi (alless in ambito della stessa struttura) utilizzando la risorsa di docker standard?

Sì, dovrebbe essere ansible farlo usando l'image personalizzata e codificarlo nello script sh, ma non sono affezionato alle biciclette invitanti.

Se la risorsa di docker standard non lo consente, è ansible estenderlo in qualche modo per abilitare tale comportmento?

--cache-from non è utile, poiché CI trascorre la maggior parte del tempo a tirare l'image, senza build nuovi livelli.

Teoria

In primo luogo, una certa teoria di Concourse (alless come da v3.3.1):

La gente spesso parla di Concourse con una "cache", ma erroneamente spiega cosa significa. Ogni operatore concourse dispone di un insieme di volumi sul disco che vengono lasciati in giro, formando una cache di volume. Questa cache di volume contiene volumi che sono stati popolati da risorse di get e put e outputs attività.

Anche le persone spesso sbagliano a capire come la docker-image-resource docker utilizza Docker. Non esiste un server globale docker in esecuzione con l'installazione di Concourse, infatti i contenitori di Concourse non sono contenitori Docker, sono contenitori runC. Ogni process di docker-image-resource check ( check , get , put ) viene eseguito all'interno del proprio contenitore runC, all'interno di cui esiste un server docker locale. Ciò significa che non esiste un server docker globale che sta tirando le immagini docker e memorizzando gli strati per ulteriori usi.

Ciò significa che quando si parla di memorizzazione nella cache con la risorsa image-docker, significa caricare o prelevare immagini nel server docker locale.


Pratica

Ora alle opzioni per ottimizzare i tempi di costruzione:

load_base

background

Il parametro load_base nella tua docker-image-resource load_base docker-image-resource put indica la risorsa che prima di docker load un'image (recuperata tramite un get ) nel suo server docker locale, prima di build l'image specificata tramite i tuoi parametri di messaggistica.

Ciò è utile quando occorre pre-popolare un'image nella tua "cache docker". Nel vostro caso, si desidera eseguire la precaricamento dell'image utilizzata nella direttiva FROM . Questo è più efficiente perché utilizza la memorizzazione del volume di Concourse proprio per sollevare la "base" una volta, rendendola disponibile al server docker durante l'esecuzione del command FROM .

uso

È ansible utilizzare load_base come segue:

Supponiamo che tu voglia build un'image python personalizzata e tu hai un repository git con un file ci/Dockerfile come segue:

 FROM ubuntu RUN apt-get update RUN apt-get install -y python python-pip 

Se voleste automatizzare la costruzione / spingere di questa image, approfittando del caching del volume di Concourse e della cache del livello di image Docker :

 resources: - name: ubuntu type: docker-image source: repository: ubuntu - name: python-image type: docker-image source: repository: mydocker/python - name: repo type: git source: uri: ... jobs: - name: build-image-from-base plan: - get: repo - get: ubuntu - put: python-image params: load_base: ubuntu dockerfile: repo/ci/Dockerfile 

cache & cache_tag

background

Le cache e la cache_tag parametri nella tua docker-image-resource cache_tag indicano che la risorsa prima di estrarre una particolare image + tag dalla tua origine remota, prima di build l'image specificata tramite i tuoi parametri di messaggistica.

Ciò è utile quando è più facile abbassare l'image di quanto non lo sia da build da zero, per esempio si dispone di un process di costruzione molto lungo , ad esempio costose compilazioni

Questo non utilizza la cache del volume di Concourse e utilizza la --cache-from " --cache-from di Docker (che esegue il rischio di prima necessità di eseguire un docker pull ) in each momento.

uso

È ansible utilizzare la cache e la cache_tag come segue:

Supponiamo che tu voglia build un'image ruby personalizzata, in cui compila il ruby dalla sorgente e hai un repository di git con un file ci/Dockerfile come segue:

 FROM ubuntu # Install Ruby RUN mkdir /tmp/ruby;\ cd /tmp/ruby;\ curl ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p247.tar.gz | tar xz;\ cd ruby-2.0.0-p247;\ chmod +x configure;\ ./configure --disable-install-rdoc;\ make;\ make install;\ gem install bundler --no-ri --no-rdoc RUN gem install nokogiri 

Se voleste automatizzare la costruzione / spingere di questa image, approfittando solo del caching dello strato di image Docker :

 resources: - name: compiled-ruby-image type: docker-image source: repository: mydocker/ruby tag: 2.0.0-compiled - name: repo type: git source: uri: ... jobs: - name: build-image-from-cache plan: - get: repo - put: compiled-ruby-image params: dockerfile: repo/ci/Dockerfile cache: mydocker/ruby cache_tag: 2.0.0-compiled 

Raccomandazione

Se si desidera aumentare l'efficienza delle immagini di costruzione dell'edificio, la mia convinzione personale è che load_base dovrebbe essere utilizzato nella maggior parte dei casi. Poiché utilizza una risorsa, sfrutta la memorizzazione del volume di Concourse e evita di fare ulteriori docker pull .