Versioning immagini Docker per integrazione continua/distribuzione continua

Question

Stiamo implementando i nostri processi di integrazione continua e consegna continua con l'uso di due concetti ben noti: pacchetti binari Linux e immagini Docker.

La maggior parte del lavoro è già fatto: prendiamo il codice GitLab pronti contro termine, compilarlo e mettere in deb pacchetti archiviati in Aptly, allora creiamo Docker immagini per il ogni servizio che abbiamo e spingere le immagini in il server privato Docker Registry. Successivamente queste immagini vengono rotolate nell'ambiente di test. Finalmente iniziamo i servizi ed eseguiamo i test di accettazione. Questo è un processo continuo e inizia ogni volta che qualcuno preme commit a origin/master.

Ciò che non è ancora chiaro è come distinguere le immagini stabili memorizzate nel Registro di Docker?

Dobbiamo monitorare lo stato di ogni immagine perché è necessario eseguire gli aggiornamenti periodici di sever stabile. Ovviamente alcune versioni (cioè versioni di immagini) non superano i test di accettazione e devono essere contrassegnate come inutilizzabili e filtrate ad ogni successiva iterazione di Consegna continua.

sembra che ci sia alcuna implementazione predefinita di questa funzione:

1. immagine predefinito repo/tag è una stringa semplice banale che non può contenere sia il numero di versione, costruire punti Data e QA.
2. Labels (introdotto in 1.6) potrebbe essere un buon punto di partenza per una soluzione alternativa, ma non siamo stati in grado di trovare l'opportunità di rietichettare le immagini esistenti (si noti che è necessario aggiornare l'immagine "metadati" tenendo conto dei risultati di QA). Non esiste un metodo utilizzabile per interrogare l'immagine in base ai valori dell'etichetta, ma probabilmente è possibile racchiudere l'API Docker.

Quindi qual è il modo corretto di assegnare le versioni alle immagini di Docker? Come possono essere archiviate le informazioni relative al QA? Come possiamo "evidenziare" le build stabili dell'immagine? Quali caratteristiche di Jenkins CI potrebbero essere utilizzate per raggiungere questi scopi? Per favore condividi la tua esperienza.

UPD: dopo un po 'ho dovuto avviare il discussion nel tracker di errore Docker. Probabilmente qualcuno lo troverà anche utile.

Answer 1

Sembra che la tua domanda abbia già una risposta in quel link di discussione, tuttavia, vorrei solo notare che in Bleacher Report non abbiamo mai trasferito le immagini su un hub di docker (privato o ospitato) che non ha passato prima l'IC.

• Codice spinto
• CircleCI crea un accumulo etichettato
• test eseguiti all'interno taggati contenitore
• Se i test passati CircleCI spinge etichettato contenitore ad un hub

Detailed explanation