Docker cache immagini hub non sembra funzionare

Question

Abbiamo una pipeline di integrazione continua su circleci che fa la seguente:

1. Carichi repo/immagine: mytag1 dalla directory cache per essere in grado di usare i livelli nella cache
2. costruisce una nuova versione: finestra mobile costruire repoimage -t: mytag2
3. Salva il nuova versione nella cartella della cache con finestra mobile Salva
4. esegue test
5. spinge a finestra mobile hub: finestra mobile spinta repo/immagine: myTa g2

Il problema è con il passaggio 5. Il passaggio di spinta richiede 5 minuti ogni volta. Se ho capito bene, l'hub docker ha lo scopo di memorizzare i livelli in cache, quindi non dobbiamo re-push cose come l'immagine di base e le dipendenze se non vengono aggiornate.

Ho eseguito la build due volte di seguito e vedo un sacco di crossover nell'hash degli strati che vengono spinti. Eppure, piuttosto che "L'immagine esiste già", vedo "Immagine spinta con successo".

Here's l'uscita di costruzione 1 di finestra mobile spinta, e here's build 2

Se diff questi due file si vedrà che solo 2 strati si differenziano per ogni generazione:

< ca44fed88be6: Buffering to Disk 
< ca44fed88be6: Image successfully pushed 
< 5dbd19bfac8a: Buffering to Disk 
< 5dbd19bfac8a: Image successfully pushed 
--- 
> 9136b10cfb72: Buffering to Disk 
> 9136b10cfb72: Image successfully pushed 
> 0388311b6857: Buffering to Disk 
> 0388311b6857: Image successfully pushed 

Allora perché è che tutte le immagini devono ripetere ogni volta?

Answer 1

L'utilizzo di un tag diverso crea un'immagine diversa che, se inserita, non può fare affidamento sulla cache.

Ad esempio i due comandi:

$ docker commit -m "thing" -a "me" db65bf421f96 me/thing:v1 
$ docker commit -m "thing" -a "me" db65bf421f96 me/thing:v2 

resa distinctimages completamente anche se sono stati creati da immagini identiche (db65bf421f96). Quando spinto, dockerhub li deve trattare come immagini completamente separati come si può vedere con:

$ docker images 
REPOSITORY  TAG  IMAGE ID 
me/thing  v2  f14aa8ac6bae 
me/thing  v1  c7d72ccc1d71 

Gli ID immagine sono uniche e quindi le immagini sono unici anche soltanto se variano nei tag.

Si potrebbe dire "la finestra mobile deve riconoscerli come bit per bit identici" e quindi trattarli come in posizione di blocco. Ma non (ancora).

L'unica sorpresa per me nel tuo esempio è l'assenza di qualsiasi ID immagine duplicato.

Autorevole (se meno esplicativo) documentation can be found at docker in "Crea le tue immagini".

Answer 2

Il processo dovrebbe funzionare come descritto. In effetti stiamo costruendo tutte le nostre immagini in questo modo senza problemi. Di solito ci sono solo alcune modifiche ai livelli più in alto e solo quelle sono trasferite al registro - altrimenti l'intero concetto di livelli di immagine sarebbe inutile.

Vedere here per un esempio. Solo i due livelli più in alto sono stati modificati, vengono inviati per :latest e per :4.0.2 non c'è nessuna spinta.Stiamo taggando le immagini con tag git e per alcuni progetti abbiamo persino taggato le immagini con git describe - per ottenere la funzionalità di rollback, per ogni evenienza.

È possibile ottenere il codice sorgente del progetto anche da GitHub per provarlo.

Un paio di cose da notare circa la messa a punto: Stiamo usando un self-hosted GitLab CI con una personalizzata runner che corre docker e docker-compose su un host isolato con Docker 1.9.1, ma che non dovrebbe fare alcuna differenza.

Ci possono essere anche differenze nella versione del registro, ho avuto la sensazione (ma non sono sicuro al 100%) che alcuni vecchi repository su DockerHub siano ancora in esecuzione sul registro v1, quelli più recenti sempre su v2 - quindi si può provare creare un nuovo repository e verificare se il problema si verifica ancora.

Si noti che il comportamento per i tag descritti sopra si applica solo quando si preme lo stesso nome immagine, se si spingono gli stessi livelli di immagine con un altro nome, è sempre necessario premere tutti i livelli, nonostante il fatto che tutti i livelli dovrebbero esiste già nel registro, quindi suppongo che repo/image:mytag1 e repoimage:mytag2 vadano effettivamente a repo/image e che la barra mancante sia solo un refuso.

Un'altra causa potrebbe essere che le immagini sono costruite su diversi host su Circle CI, ma poi dovresti anche ottenere ID di layer diversi, quindi penso che questo non sia molto probabile.

Suggerisco di creare manualmente un'immagine e provare a riprodurre il problema oppure contattare Circle CI in merito a questo problema.