In questo post, ti mostro come utilizzare Quay.io per ospitare immagini di container e come evitare di sovraccaricare il registro dei container limitando le richieste non necessarie di immagini. Uso Buildah, Skopeo e Quay.io, ma i suggerimenti per limitare i pull di immagini funzioneranno con qualsiasi registro di container che potresti utilizzare.
Alla fine di novembre 2020, Docker Hub ha iniziato a limitare o limitare il numero di immagini del contenitore che puoi estrarre in modo anonimo o come Hub Docker gratuito utente. Se sei un anonimo utente, puoi estrarre solo 100 immagini del contenitore in un periodo di 6 ore. Se sei un utente di Free Docker Hub, puoi estrarre 200 immagini di container in un periodo di 6 ore.
Quando eseguiamo i nostri test funzionali degli strumenti contenitore su cui lavoriamo, come Buildah e Podman, questo limite non è generalmente un problema. Ad esempio, quando crei un'immagine del contenitore utilizzando un Containerfile e quindi test il contenitore risultante per vedere come si comporta dopo aver eseguito comandi particolari su di esso, generalmente estrai l'immagine del contenitore principale specificata in DA forte> istruzione nel file Container una volta. Se in seguito ricostruisci il contenitore da zero, in genere riutilizzi l'immagine del contenitore già tirata verso il basso e quindi non colpisci il contatore. In questo scenario, il throttling non provoca alcun dolore, ma è sempre nella parte posteriore della mia mente.
Riduzione iniziale delle interazioni Docker Hub
Tuttavia, abbiamo trovato un punto in cui ci siamo imbattuti nel throttling su Docker Hub. Ed, il mio collega e uno dei lead QE del motore di container, ha creato una soluzione molto interessante per questo. Innanzitutto, un po' di sfondo. Diversi mesi fa, Ed ha ridotto il numero di volte in cui abbiamo recuperato le immagini del contenitore utilizzate dai test Buildah Continuous Integration (CI) riutilizzando la cache che Podman aveva già creato. Prima di questo, l'IC di Buildah ha abusato dei poveri alpine immagine del contenitore che risiede nell'hub Docker in docker.io/library a non finire, insieme al fedora , busybox , e alcune altre immagini contenitore assortite lì, che le richiamano moltitudini di volte. Questo schema di prelettura elaborato da Ed non solo ha accelerato i nostri test, ma ci ha anche permesso di ridurre la larghezza di banda che stavamo utilizzando su Docker Hub.
Nonostante queste modifiche, il CI di Buildah ha iniziato a fallire più volte al giorno a novembre con questo errore:Hai raggiunto il limite di pull rate . Il raggiungimento del limite di frequenza è dovuto al numero di volte in cui i nostri test CI sono stati eseguiti ogni giorno. Anche se il precaricamento aveva ridotto il numero di volte in cui il CI di Buildah aveva bisogno per estrarre le immagini, il CI era ancora in esecuzione nel throttling di Docker Hub.
[ Potresti anche leggere: Come implementare un semplice registro di immagini container Linux personale/privato per uso interno ]
Risoluzione del throttling
La soluzione fornita da Ed utilizza la flessibilità di Buildah e gli strumenti container nel repository Containers su GitHub. Innanzitutto, Ed ha creato un account gratuito su quay.io, ha copiato le immagini lì e le ha rese pubbliche. Ed ha scelto quay.io perché è lì che memorizziamo molte delle nostre immagini di container ed è conveniente per noi. Tuttavia, potrebbe essere un repository di immagini del contenitore locale o un repository di un'altra azienda.
Come bonus, quay.io non è limitato come Docker Hub.
Utilizzare Skopeo per copiare l'immagine iniziale
Supponiamo che il tuo progetto richieda l'alpine e centos:8 immagini. Inizierai creando un account gratuito su quay.io, con un nome di myquayaccountname . Su un host con Skopeo installato, dovresti quindi eseguire:
skopeo login -u myquayaccountname quay.io
skopeo copy --all docker://docker.io/library/alpine:latest docker://quay.io/myquayaccountname/alpine:latest
Quindi ripeti, sostituendo alpine:latest con centos:8 e così via per tutte le immagini necessarie.
Configura quay.io
Le immagini sono ora su quay.io, ma sono private per impostazione predefinita. Per renderli pubblici, accedi nuovamente all'interfaccia utente web di quay.io, fai clic sul nome di ciascuna immagine. Questo ti porterà a una nuova pagina che mostra i dettagli dell'immagine. Fai clic sull'icona a forma di ingranaggio nella parte inferiore della barra di navigazione a sinistra, trova il Rendi pubblico pulsante e premerlo. Dovrai confermare OK e quindi ripetere per tutte le immagini che mostrano l'icona di un lucchetto rosa.
Nel nostro caso, la prima cosa che ha fatto Ed è stata estrarre le immagini del contenitore che utilizziamo da Docker Hub e inserirle nel repository di immagini del contenitore libpod su quay.io che aveva creato.
Configura registries.conf per il mirroring
Abbiamo risolto il problema della limitazione spostando quelle immagini. Tuttavia, ora abbiamo avuto il problema di modificare le centinaia se non migliaia di riferimenti dei test a quelle immagini in modo che l'elemento della configurazione estraesse da quay.io/libpod anziché docker.io/library . Questo cambiamento necessario è stato una vetrina perfetta per la flessibilità offerta dagli strumenti del contenitore. Ed ha affrontato questo problema con un cambiamento relativamente piccolo nella configurazione, piuttosto che cambiare globalmente tutti i test.
Ecco cosa ha inventato Ed. Quando Buildah cerca un'immagine del contenitore, non è hardcoded per estrarre semplicemente da docker.io. Invece, legge /etc/containers/registries.conf e determina da quale repository di immagini del contenitore Buildah dovrebbe attingere.
Ed ha semplicemente cambiato quel file in modo tale che quay.io/libpod viene contattato ogni volta che i test sono andati alla ricerca di docker.io/library . Usando il nostro esempio sopra, aggiungeresti le seguenti righe a /etc/containers/registries.conf su tutti i sistemi in cui desideri utilizzare la tua cache:
toml
[[registry]]
prefix=" docker.io/library"
location=" quay.io/myquayaccountname"
Tutti i successivi podman pull alpine i comandi verranno recuperati dal tuo mirror. Puoi vedere la modifica apportata da Ed per Podman qui in questa Pull Request.
Per evidenziare ulteriormente le capacità di mirroring nel progetto contenitori/immagine, utilizzato da Buildah, è possibile impostare un mirror per le immagini del contenitore consentendo di eseguire il pull con il vecchio nome da un registro diverso. Il mirroring è stato originariamente aggiunto per supportare gli ambienti disconnessi. Gli ambienti senza connettività Internet che eseguono software come OpenShift spesso non possono estrarre immagini da registri non locali, quindi consentiamo agli utenti di eseguire il mirroring delle immagini nei registri interni senza dover modificare il software.
Ecco uno snippet con ulteriori informazioni da containers-registries.conf file, che fa parte del container/image progetto:
$ man containers-registries.conf
Remapping and mirroring registries
The user-specified image reference is, primarily, a "logical" image name, always
used for naming the image. By default, the image reference also directly specifies
the registry and repository to use, but the following options can be used to redi‐
rect the underlying accesses to different registry servers or locations (e.g., to
support configurations with no access to the internet without having to change
Dockerfiles, or to add redundancy). Avvertenze :questa procedura esegue una copia unica delle immagini del contenitore. La tua immagine memorizzata nella cache non rileverà magicamente le correzioni di sicurezza inviate a docker.io. (Non rileverà atti vandalici casuali come file binari rimossi o altre modifiche sostanziali, non farmi iniziare.)
Ulteriori lavori
Data l'avvertenza, la manutenzione dell'immagine spetta a te ora e potresti considerare di aggiungere i comandi Skopeo per copiare l'immagine all'inizio della procedura di test. Un'altra possibile soluzione è abilitare un mirror pubblico come Google Cloud Registry (GCR) o eventualmente perfezionare ulteriormente registries.conf file per configurare più mirror. Meglio ancora, questo è probabilmente perfetto per il comando skopeo-sync in quanto ha una bella CLI e può essere utilizzato con un file YAML che offre un'ampia gamma di opzioni di configurazione.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Esistono vari modi per risolvere il rallentamento del Docker Hub messo in atto, ma il metodo utilizzato da Ed è stato rapido, indolore e ha riportato rapidamente online il nostro CI. Ora che abbiamo un po' di respiro, possiamo lavorare su una soluzione più completa.
Con questa modifica in atto, i test Buildah non superano più il limite e colpiscono il throttling da Docker Hub, quindi il problema del throttling è risolto.