Se osserviamo da vicino i prodotti LEGO®, possiamo vedere che sono tutti realizzati con gli stessi elementi costitutivi. Tuttavia, la composizione di questi blocchi è il fattore chiave di differenziazione se stiamo costruendo un castello o un'astronave. È praticamente lo stesso per Podman e i suoi progetti fratelli Buildah, Skopeo e CRI-O. Tuttavia, invece della plastica riciclata, gli elementi costitutivi dei nostri strumenti per contenitori sono costituiti da codice open source. La condivisione di questi elementi costitutivi ci consente di fornire strumenti container solidi come una roccia di livello aziendale. Le funzionalità vengono spedite più velocemente, i bug vengono risolti più rapidamente e il codice è testato in battaglia. E, beh, invece di portare gioia nelle sale giochi, gli strumenti container portano gioia nei data center e nelle workstation.
L'elemento fondamentale per i nostri strumenti contenitore è la libreria contenitori/archiviazione, che archivia e gestisce localmente contenitori e immagini di contenitori. Salendo di un livello più in alto, troviamo i contenitori/libreria di immagini. Come suggerisce il nome, questa libreria si occupa di immagini di contenitori ed è incredibilmente potente. Ci consente di estrarre e spingere le immagini, manipolare le immagini (ad esempio, cambiare la compressione dei livelli), ispezionare le immagini insieme alla loro configurazione e ai livelli e copiare le immagini tra i cosiddetti trasporti di immagini. Un trasporto può fare riferimento a un archivio container locale, un registro container, un archivio tar e molto altro. Dan Walsh ha scritto un ottimo post sul blog sui vari trasporti che consiglio vivamente di leggere.
La libreria di immagini supporta anche diversi file di configurazione dove, senza dubbio, il registries.conf è il più importante per la stragrande maggioranza degli utenti. Voglio dedicare questo post del blog a registries.conf file di configurazione, spiega le sue varie opzioni e manopole e come possiamo usarle in produzione.
Gestione dei registri dei contenitori con registries.conf
Il registries.conf la configurazione è in gioco ogni volta che spingiamo o estraiamo un'immagine. O, più in generale, ogni volta che contattiamo un registro di container. Questa è una semplice regola pratica. La posizione a livello di sistema è /etc/containers/registries.conf , ma se vuoi cambiarlo per un singolo utente, puoi creare un nuovo file in $HOME/.config/containers/registries.conf .
Quindi tuffiamoci dentro. Nelle sezioni seguenti, analizzeremo alcuni esempi che spiegano le varie opzioni di configurazione in registries.conf . Gli esempi sono scenari del mondo reale e possono essere una fonte di ispirazione per affrontare il tuo caso d'uso individuale.
Tirare con nomi brevi
Gli esseri umani sono pigri e io non faccio eccezione. È molto più comodo eseguire un podman pull ubi8 anziché podman pull registry.access.redhat.com/ubi8:latest . Continuo a dimenticare quale immagine risiede su quale registro e ci sono molte immagini e molti registri là fuori. Ci sono Docker Hub e Quay.io, oltre ai registri per Amazon, Microsoft, Google, Red Hat e molte altre distribuzioni Linux.
Docker ha affrontato la nostra pigrizia risolvendo sempre il Docker Hub. Un docker pull alpine si risolverà in docker.io/library/alpine:latest e docker pull repo/image:tag si risolverà in docker.io/repo/image:tag (notare il repository specificato). Podman e i suoi progetti fratelli non volevano bloccare gli utenti nell'uso di un solo registro, quindi i nomi brevi possono risolversi in più di docker.io e, come puoi aspettarti, possiamo configurarlo in registries.conf come segue:
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
Lo snippet sopra è preso direttamente da registries.conf in Fedora 33. È un elenco di registri che vengono contattati nell'ordine specificato quando si estrae un'immagine di nome breve. Se non è possibile trovare l'immagine nel primo registro, Podman tenterà di eseguire il pull dal secondo registro e così via. Buildah e CRI-O seguono la stessa logica, ma nota che Skopeo si normalizza sempre su docker.io.
[ Potrebbe piacerti anche: Qual è il prossimo carico di lavoro Linux che prevedi di containerizzare? ]
Ricerca di immagini
Analogamente alla sezione precedente sull'estrazione, le immagini vengono comunemente ricercate per nome. Quando si esegue una podman search , di solito non so o semplicemente ho dimenticato su quale registro risiede l'immagine data. Quando si utilizza Docker, è possibile eseguire ricerche solo su Docker Hub. Podman offre più libertà agli utenti e consente di cercare immagini su qualsiasi registro. E non sorprende che registries.conf ha una soluzione.
Simile al pull, i unqualified-search-registries vengono utilizzati anche quando si utilizza un nome breve con podman search . Un podman search foo cercherà immagini denominate pippo in tutti i registri di ricerca non qualificata.
Le grandi aziende di solito hanno registri di container locali. Integrare tali registri nel flusso di lavoro è semplice come aggiungerli all'elenco dei registri di ricerca non qualificati.
Alias abbreviati
Le versioni più recenti di Podman, Buildah e CRI-O vengono fornite con un nuovo modo di risolvere i nomi brevi, principalmente utilizzando alias. Gli alias sono una semplice tabella TOML [aliases] nella forma "name" = "value" , simile a come funzionano gli alias Bash. Manteniamo un elenco centrale di alias insieme alla community a monte su github.com/containers/shortnames . Se possiedi un'immagine e desideri avere un alias, sentiti libero di aprire una richiesta pull o di contattarci.
Alcune distribuzioni, come RHEL8, prevedono di spedire i propri elenchi di nomi brevi per aiutare gli utenti e impedire loro di estrarre accidentalmente immagini dal registro sbagliato.
Spiegare in dettaglio come funzionano gli alias di nomi abbreviati amplierebbe notevolmente questo post del blog, quindi se sei interessato, fai riferimento a un precedente post del blog sugli alias di nomi abbreviati.
Configurazione di un registro container locale
L'esecuzione di un registro container locale è abbastanza comune. Ne ho uno sempre in esecuzione, quindi posso memorizzare nella cache le immagini e sviluppare e testare nuove funzionalità come gli aggiornamenti automatici in Podman. La larghezza di banda nel mio ufficio a casa è limitata, quindi apprezzo le spinte e le tirate veloci. Poiché tutto è in esecuzione localmente, non devo preoccuparmi di configurare TLS per il registro. Ciò implica la connessione al registro tramite HTTP anziché tramite HTTPS. Podman ti consente di farlo specificando --tls-verify=false sulla riga di comando, che salterà la verifica TLS e consentirà connessioni non sicure.
Un approccio alternativo per saltare la verifica TLS tramite la riga di comando consiste nell'usare registries.conf . Questo potrebbe essere più conveniente, specialmente per gli script automatizzati in cui non vogliamo aggiungere manualmente i flag della riga di comando. Diamo un'occhiata allo snippet di configurazione di seguito.
[[registry]]
location="localhost:5000"
insecure=true
Il formato di registries.conf è TOML. Le doppie parentesi di [[registry]] indicare che possiamo specificare un elenco (o tabella) di [registry] oggetti. In questo esempio, esiste un solo registro in cui la posizione (ovvero il suo indirizzo) è impostata su localhost:5000 . È qui che viene comunemente eseguito un registro locale. Ogni volta che i containers/image libreria si connette a un registro contenitori con quella posizione, cercherà la sua configurazione e agirà di conseguenza. In questo caso, il registro è configurato per non essere sicuro e la verifica TLS verrà ignorata. Podman e gli altri strumenti contenitore possono ora comunicare con il registro locale senza che le connessioni vengano rifiutate.
Blocco di un registro, uno spazio dei nomi o un'immagine
Nel caso in cui desideri impedire a utenti o strumenti di eseguire il pull da un registro specifico, puoi procedere come segue.
[[registry]]
location="registry.example.org"
blocked=true
Il blocked=true impedisce le connessioni a questo registro, o almeno blocca l'estrazione di dati da esso.
Tuttavia, è sorprendentemente comune tra gli utenti bloccare solo spazi dei nomi specifici o singole immagini ma non l'intero registro. Supponiamo di voler impedire agli utenti di estrarre immagini dallo spazio dei nomi registry.example.org/namespace . Il registries.conf ora apparirà così:
[[registry]]]
location="registry.example.org"
prefix="registry.example.org/example"
blocked=true
Ho appena introdotto una nuova manopola di configurazione:prefix . Un prefisso indica solo di selezionare la configurazione specificata quando si tenta di estrarre un'immagine che corrisponde al prefisso specifico. Ad esempio, se eseguissimo un podman pull registry.example.org/example/image:latest , il prefisso specificato corrisponderebbe e a Podman verrebbe impedito di estrarre l'immagine. Se desideri bloccare un'immagine specifica, puoi impostarla utilizzando quanto segue:
prefix="registry.example.org/namespace/image"
L'uso di un prefisso è uno strumento molto potente per soddisfare tutti i tipi di casi d'uso. Può essere combinato con tutte le manopole di un [registry] . Si noti che l'utilizzo di un prefisso è facoltativo. Se non ne viene specificato nessuno, il prefisso verrà impostato automaticamente sulla posizione (obbligatoria).
Registri di mirroring
Supponiamo di eseguire il nostro carico di lavoro in un ambiente con gap d'aria. Tutti i nostri server sono disconnessi da Internet. Ci sono molte ragioni per questo. Potremmo essere in esecuzione al limite o in un ambiente altamente sensibile alla sicurezza che ci impedisce di connetterci a Internet. In questo caso, non possiamo connetterci al registro originale ma dobbiamo eseguire un registro che rispecchi i contenuti della rete locale.
Un mirror del registro è un registro che verrà contattato prima di tentare di eseguire il pull da quello originale. È un caso d'uso comune e una delle richieste di funzionalità più vecchie nell'ecosistema dei container.
[[registry]]
location="registry.access.redhat.com"
[[registry.mirror]]
location="internal.registry.mirror"
Con questa configurazione, quando si estrae l'immagine di base universale tramite podman pull ubi8 , l'immagine verrebbe estratta dal mirror anziché dal registro dei contenitori di Red Hat.
Si noti che possiamo specificare più mirror che verranno contattati nell'ordine specificato. Diamo una rapida occhiata a cosa significa:
[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"
[[registry.mirror]]
location="mirror-3.com"
Supponiamo che stiamo tentando di estrarre l'immagine registry.example.com/myimage:latest . I mirror vengono contattati nell'ordine specificato (cioè dall'alto verso il basso), il che significa che Podman proverebbe prima a estrarre l'immagine da mirror-1.com . Se l'immagine non è presente o il pull non riesce per altri motivi, Podman contatterà mirror-2.com e così via. Se tutti i mirror pull falliscono, Podman contatterà il registry.example.com principale .
Nota che i mirror supportano anche insecure pomello. Se vuoi saltare la verifica TLS per un mirror specifico, aggiungi semplicemente insecure=true .
Rimappatura dei riferimenti
Come abbiamo visto sopra, un prefix viene utilizzato per selezionare un [registry] specifico nel registries.conf . Sebbene i prefissi siano un mezzo potente per impedire l'estrazione di spazi dei nomi specifici o di determinate immagini, possono anche essere utilizzati per rimappare intere immagini. Simile ai mirror, possiamo usare un prefisso per eseguire il pull da un registro diverso e uno spazio dei nomi diverso.
Per illustrare cosa intendo per rimappare , consideriamo che corriamo in un ambiente a vuoto d'aria. Non possiamo accedere ai registri dei container poiché siamo disconnessi da Internet. Il nostro carico di lavoro utilizza immagini da Quay.io, Docker Hub e dal registro dei container di Red Hat. Mentre potremmo avere un mirror locale di rete per registro, potremmo anche usarne uno con la seguente configurazione.
[[registry]]
prefix="quay.io"
location="internal.registry.mirror/quay"
[[registry]]
prefix="docker.io"
location="internal.registry.mirror/docker"
[[registry]]
prefix="registry.access.redhat.com"
location="internal.registry.mirror/redhat"
Un podman pull quay.io/buildah/stable:latest ora tirerà invece internal.registry.mirror/quay/buildah/stable:latest . Tuttavia, l'immagine estratta rimarrà quay.io/buildah/stable:latest poiché la rimappatura e il mirroring avvengono in modo trasparente a Podman e agli altri strumenti contenitore.
Come possiamo vedere nello snippet sopra, internal.registry.mirror è il nostro mirror locale di rete che stiamo utilizzando per estrarre le immagini per conto di Quay.io, Docker Hub e il registro dei container di Red Hat. Le immagini di ciascun registro risiedono su spazi dei nomi separati nel registro (ad esempio, "quay", "docker", "redhat"):un trucco semplice ma potente per rimappare le immagini durante il pull. Potresti chiederti come possiamo precompilare il mirror interno con le immagini dei tre registri. Non consiglio di farlo manualmente ma di usare skopeo sync invece. Con skopeo sync , un amministratore di sistema può caricare facilmente tutte le immagini su un'unità USB, portarla in un cluster con air gap e precaricare il mirror.
Esistono innumerevoli casi d'uso in cui tale rimappatura può essere d'aiuto. Ad esempio, quando si utilizza un altro registro durante i test, può essere utile estrarre in modo trasparente da un altro registro (di test o di staging) rispetto a quello in produzione. Non sono necessarie modifiche al codice.
Tom Sweeney e Ed Santiago hanno utilizzato la rimappatura per sviluppare una soluzione creativa per affrontare i limiti di velocità di Docker Hub. Alla fine di novembre 2020, Docker Hub ha iniziato a limitare il numero di pull per utente in un determinato periodo di tempo. All'inizio eravamo preoccupati perché gran parte dei nostri sistemi di test e l'integrazione continua utilizzavano immagini Docker Hub. Ma con una semplice modifica a registries.conf sui nostri sistemi, Tom ed Ed hanno trovato un'ottima soluzione. Questo ci ha risparmiato il compito manuale e noioso di modificare tutte le immagini che fanno riferimento a docker.io nei nostri test.
Gestione avanzata della configurazione tramite file di configurazione drop-on
La gestione delle configurazioni è impegnativa. I nostri sistemi vengono aggiornati continuamente e con gli aggiornamenti potrebbero verificarsi modifiche alla configurazione. Potremmo voler aggiungere nuovi registri, configurare nuovi mirror, correggere le impostazioni precedenti o estendere la configurazione predefinita di Fedora. Ci sono molte motivazioni, e per certi registries.conf lo supporta tramite i cosiddetti file di configurazione drop-in.
Durante il caricamento della configurazione, il containers/image la libreria caricherà prima il file di configurazione principale in /etc/containers/registries.conf e poi tutti i file in /etc/containers/registries.conf.d directory in ordine alfanumerico.
Usando tale drop-in registries.conf i file sono diretti. Basta inserire un .conf file nella directory e Podman otterrà la configurazione aggiornata. Nota che le tabelle nella configurazione vengono unite mentre le semplici manopole vengono sovrascritte. Ciò significa, in pratica, che il [[registry]] la tabella può essere facilmente estesa con nuovi registri. Se esiste già un registro con lo stesso prefisso, l'impostazione del registro verrà sovrascritta. Lo stesso vale per [aliases] tavolo. Semplici manopole di configurazione come i registri di ricerca non qualificati vengono sempre sovrascritte.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Conclusione
Il registries.conf è un elemento fondamentale dei nostri strumenti container. Consente di configurare tutti i tipi di proprietà quando si parla con un registro contenitori. Se sei interessato a studiare la configurazione in modo più dettagliato, puoi eseguire un man containers-registries.conf per leggere la pagina man sulla tua macchina Linux o visitare la documentazione a monte.