Jump to section

Cos'è un registro dei container?

Copia URL

Un registro dei container è un repository, o una raccolta di repository, utilizzato per archiviare e accedere alle immagini container. I registri dei container possono supportare lo sviluppo di applicazioni basate su container, spesso nell'ambito dei processi DevOps. I registri dei container possono connettersi direttamente a piattaforme di orchestrazione dei container come Docker e Kubernetes

I registri dei container consentono agli sviluppatori di risparmiare tempo prezioso nella creazione e nella distribuzione di applicazioni cloud native, agendo da intermediario per la condivisione delle immagini container tra i sistemi.

Un'immagine container include i file e i componenti che compongono un'applicazione. A differenza delle macchine virtuali (VM), i container sono pacchetti software leggeri che vengono eseguiti sul sistema operativo Linux®. Le immagini container possono essere moltiplicate per adattarsi alle variazioni dei carichi di lavoro. Sono in genere associate allo sviluppo agile, alla metodologia DevOps e all'integrazione e alla distribuzione continue (CI/CD). 

Le immagini container includono librerie di sistema, strumenti di sistema e altre impostazioni della piattaforma necessarie per l'esecuzione delle applicazioni, e offrono agli sviluppatori i vantaggi della portabilità e dell'agilità indispensabili per creare nuove applicazioni o espanderle rapidamente.

Uno strumento open source come Buildah consente di creare immagini compatibili con OCI e Docker, con o senza Dockerfiles o un punto di partenza di un'immagine container esistente, semplificando notevolmente il processo. 

Quando si sviluppano immagini container, è necessaria una posizione in cui salvarli, condividerli e accedervi durante la loro creazione. Il registro dei container svolge questi compiti,

agendo, sostanzialmente, come posizione in cui gli sviluppatori possono archiviare e condividere le immagini container tramite processi di uploading (pushing) nel registro e downloading (pulling) in un altro sistema, come un cluster di Kubernetes

Una volta estratta l'immagine, l'applicazione al suo interno può essere eseguita su quel sistema.

Oltre alle immagini container, i registri conservano anche i percorsi e i parametri per il controllo degli accessi alle interfacce di programmazione delle applicazioni (API) per la comunicazione da container a container. Le API aiutano a eliminare gli accoppiamenti non previsti, che limitano il cambiamento e costituiscono una fonte comune di interruzioni, soprattutto negli ambienti di cloud ibrido in cui le applicazioni non risiedono più nello stesso datacenter.

Le immagini container possono comunicare anche tramite una service mesh, un livello di infrastruttura tra i servizi containerizzati che migliora la scalabilità. Per le applicazioni cloud native integrate in un'architettura di microservizi, una service mesh consente di includere un numero elevato di servizi "piccoli" in un'applicazione funzionale.

Secondo la Cloud Native Computing Foundation, container (comprese le immagini container e i registri) e microservizi rappresentano le basi dello sviluppo applicativo cloud native. Il fatto che container e microservizi sono del tutto autonomi, li rende un potente strumento per la creazione di applicazioni cloud native portabili. 

I container isolano i processi applicativi, i file di runtime e le dipendenze del sistema operativo dal resto del sistema. Promettono una maggiore portabilità tra gli ambienti di cloud ibrido e possono essere distribuiti per periodi di tempo molto più brevi rispetto alle macchine virtuali (VM). In questo modo gli sviluppatori possono eseguire più facilmente il pushing e il pulling di ciò di cui hanno bisogno da un registro dei container, concentrandosi quindi sulla creazione di un ottimo prodotto, senza distrazioni causate dall'infrastruttura sottostante o dai dettagli di esecuzione.

In un ambiente DevOps, l'uso dei container, e delle immagini/registri dei container, consente agli sviluppatori di distribuire ciascun servizio applicativo in modo indipendente, eliminando la necessità di unire le modifiche al codice, migliorare i test e aiutare con gli errori di isolamento sia in fase di test che di produzione.

Sono disponibili due tipi di registri per container: pubblico e privato.

I registri pubblici sono in genere utilizzati da singoli o piccoli team che desiderano utilizzare il proprio registro il più rapidamente possibile. Tuttavia, la crescita delle organizzazioni può portare a problemi di sicurezza più complessi, come l'applicazione di patch, la privacy e il controllo degli accessi. 

I registri privati consentono di integrare sicurezza e privacy nello storage delle immagini container dell'enterprise, che sia ospitato in remoto o che sia on premise. In genere, a questi registri privati sono associati funzionalità di sicurezza e supporto tecnico.

La maggior parte dei provider di servizi cloud offre servizi privati per il registro delle immagini:Google offre Google Container Registry, AWS offre Amazon Elastic Container Registry (ECR) e Microsoft offre Azure Container Registry.

Un registro privato interno offre le maggiori potenzialità in termini di sicurezza e configurazione, ma richiede una gestione attenta e la garanzia che l'infrastruttura del registro e i controlli di accesso rimangano all'interno dell'organizzazione.

Nel processo di scelta di un servizio di registro dei container privato per l'azienda, è utile verificare la presenza dei seguenti aspetti:

  • Supporto per più sistemi di autenticazione

  • Gestione del controllo degli accessi basato sui ruoli (RBAC) per le immagini locali

  • Funzionalità di scansione delle vulnerabilità per migliorare la sicurezza e la configurazione

  • Capacità di registrare l'utilizzo in log verificabili che consentano di tracciare l'attività di ogni singolo utente

  • Ottimizzato per l'automazione

Le funzionalità enterprise-ready di un registro privato consentono alle organizzazioni di accedere internamente alle immagini container in modo sicuro ed efficiente. Diversi sistemi di autenticazione adottano misure per verificare l'immagine container archiviata al suo interno.

Ad esempio, l'immagine deve essere firmata digitalmente dalla persona che l'ha caricata prima di poterla inviare al registro, per consentire il tracciamento delle attività e prevenire i caricamenti da parte di utenti non autorizzati.

RBAC gestisce le azioni dell'utente consentite in base al ruolo dell'individuo. A uno sviluppatore serve l'accesso per poter eseguire l'upload e il download dal registro, mentre a un membro del team o a un tester è sufficiente accedere per il download. Le organizzazioni dotate di un sistema di gestione degli utenti, come Active Directory (AD) o Lightweight Directory Access Protocol (LDAP), possono collegarlo direttamente al registro dei container e utilizzarlo per il controllo RBAC.

Un'azienda può scegliere di creare e distribuire il proprio registro dei container, o scegliere un apposito servizio privato commerciale.

Red Hat® OpenShift® è una piattaforma Kubernetes per container enterprise-ready che garantisce coerenza a qualsiasi infrastruttura cloud, attraverso la gestione dei deployment di cloud ibrido, multicloud ed edge. Red Hat OpenShift consente di eseguire il provisioning di un ambiente per un nuovo microservizio o una nuova applicazione in pochi minuti. Oltre ad altri servizi cloud come middleware, linguaggi, framework e database, include già un registro privato che fornisce le funzionalità di base per la gestione delle immagini container. 

Il deployment dei registri privati può fare parte di un servizio gestito da Red Hat OpenShift su un provider cloud dall'ecosistema di partner di Red Hat, per un'esperienza lineare su Azure, Amazon Web Services (AWS), IBM Cloudo Google Cloud. Red Hat OpenShift supporta l'integrazione con gli altri registri privati eventualmente in uso, come JFrog Artifactory e Sonatype Nexus.

Red Hat offre inoltre servizi autogestiti che si basano sul cloud ibrido, con funzionalità di sicurezza avanzate ed elementi software aggiuntivi che è possibile utilizzare nel data center. Se hai bisogno di funzionalità di supporto tecnico e sicurezza più avanzate,Red Hat Quay è disponibile come opzione standalone e scalabile nel registro di livello enterprise.

Keep reading

ARTICOLO

Stateful e stateless

La condizione di stateful o stateless di un elemento dipende dalla durata della registrazione dell'interazione con l'elemento stesso e dalle modalità di memorizzazione di questa informazione.

ARTICOLO

Cos'è Quarkus?

Quarkus è uno stack Java Kubernetes native realizzato per le macchine virtuali Java (JVM) e per la compilazione nativa, che ottimizza Java specificamente per i container.

ARTICOLO

Cos'è il serverless computing?

Il serverless computing è un modello di sviluppo cloud native che consente agli sviluppatori di creare ed eseguire applicazioni senza gestire i server.

Scopri di più sulle applicazioni cloud native

Prodotti

Una piattaforma applicativa aziendale che offre servizi verificati per consentire la distribuzione delle app sulle infrastrutture preferite.

Risorse

White paper

Panoramica di Red Hat sullo sviluppo cloud native

Ebook

Il percorso verso le applicazioni cloud native

EBOOK

Cloud native e cloud ibrido: come definire la tua strategia.

Formazione

Formazione gratuita

Developing Cloud-Native Applications with Microservices Architectures