Comprendere Azure Container Registry

Quando si arriva alla fine di una pipeline di compilazione devops, rimane una serie di artefatti: binari, file di configurazione, pagine Web, persino macchine virtuali e contenitori. Sono i componenti che vanno insieme per costruire un'applicazione moderna. Avvolgere il maggior numero possibile di questi componenti in un contenitore ha molto senso, offrendoti un modello di distribuzione più semplice. Ma questo lascia una nuova serie di domande: come gestisci questi container e come li distribuisci su un'applicazione cloud su scala globale?

Servizi come GitHub offrono registri pubblici e privati ​​per i tuoi artefatti di build, utilizzando standard aperti e codice open source. Azure ha fatto lo stesso, utilizzando il Docker Registry 2.0 open source come base per il proprio registro contenitori, compatibile con Open Container Initiative. Non è inteso solo per i contenitori; data la crescente importanza delle applicazioni cloud native basate su Kubernetes, è pensato per essere un repository one-stop per tutti i tuoi artefatti di build conformi a OCI. Ciò include ora i grafici Helm, quindi puoi usare ACR (Container Registry) di Azure come hub di distribuzione per le tue applicazioni, usando Helm 3.0 per il recapito alle istanze Kubernetes.

Iniziare con ACR

Strumenti come Azure Container Registry sono meglio pensati come registri privati. Solo tu, il tuo team e i servizi avete accesso al registro, automatizzando il recapito ai servizi di Azure che usano i contenitori. Strumenti familiari come Azure DevOps e Jenkins possono essere configurati per usare il Registro di sistema come endpoint di compilazione, in modo da poter passare direttamente dall'unione di una richiesta pull a un contenitore su Azure, pronto per la distribuzione.

Microsoft offre attualmente tre versioni di ACR: Basic, Standard e Premium, a tre diverse fasce di prezzo. Funzionano tutti con Web hook, usano Azure Active Directory per l'autenticazione e hanno la capacità di eliminare immagini. Basic ha la capacità più bassa; Premium include il supporto per la replica tra le regioni e aggiunge il supporto per la firma delle immagini. È molto probabile che utilizzi Standard, che ti offre 100 GB di spazio di archiviazione, 60 MBps di larghezza di banda per il download e supporta fino a 10 Web hook. Il prezzo si intende per registro al giorno, con costi di rete aggiuntivi e un addebito separato per l'utilizzo della CPU durante la creazione di nuove immagini del contenitore.

La creazione di un nuovo registro contenitori è relativamente semplice, utilizzando l'interfaccia della riga di comando di Azure o il portale. Le istanze ACR sono legate ai gruppi di risorse, quindi puoi avere un registro separato per ogni applicazione eseguita in Azure. Dopo aver creato un registro, ti viene fornito l'URL di un server di accesso. Questo è il punto finale per l'integrazione con gli strumenti devops o le istanze Docker desktop dei tuoi sviluppatori.

Interagire con un registro ACR

Il acrcomando dell'interfaccia della riga di comando di Azure è probabilmente il modo più utile per interagire con un registro. Accedi e puoi iniziare a inviare le immagini del contenitore ad esso. È una buona idea iniziare dal desktop per avere un'idea di come funziona, contrassegnare un'immagine Docker locale con il nome del server di accesso ACR e quindi utilizzare il docker pushcomando per inviare l'immagine al registro ACR, creando automaticamente il repository appropriato in azzurro. Una volta che un'immagine è in un repository ACR, utilizza gli strumenti della riga di comando per elencare i file, rimuoverli e persino utilizzare i comandi Docker per eseguirli.

L'automazione di ACR può ridurre notevolmente il carico di lavoro, utilizzando le attività di ACR. Le attività raggruppano quello che sarebbe stato un set di script dell'interfaccia della riga di comando di Azure in semplici flussi di lavoro che gestiscono le operazioni comuni. Ad esempio, offrono una serie di trigger che automatizzano la creazione di nuove immagini quando si verificano modifiche nella pipeline di build o nel sistema di integrazione continua / distribuzione continua (CI / CD).

Un'opzione, l'attività rapida, racchiude in un unico comando tutte le fasi utilizzate per creare un insieme di file in un contenitore. Tutto ciò di cui hai bisogno è una directory di lavoro con i tuoi file e un registro ACR esistente e un Dockerfile. Un singolo comando prende quei file e utilizza il Dockerfile per creare un'immagine, archiviandola automaticamente in un repository ACR. Un'altra operazione rapida esegue l'immagine sull'host scelto.

Mettili insieme e avrai un set di base di strumenti per testare le immagini del contenitore. Distribuzioni più complesse richiederanno script più complessi, ad esempio la distribuzione di un contenitore in un'istanza Kubernetes gestita utilizzando AKS. In alternativa, puoi automatizzare l'intero processo, creando un'attività che monitora un repository GitHub per le modifiche in un ramo di distribuzione, creando una nuova immagine quando unisci una richiesta pull nel ramo o effettui un commit.

Protezione dei container in ACR

Ci sono vantaggi in termini di sicurezza nel lavorare con ACR. Uno dei grandi problemi che deve affrontare chiunque crei applicazioni moderne è comprendere e gestire l'albero delle dipendenze. Come fai a sapere se una nuova versione di una libreria di chiavi o di un componente offuscato è sicuro da usare? Devi essere in grado di fidarti dei tuoi contenitori e ACR offre due modi per assicurarti di distribuire sempre codice affidabile.

In primo luogo, fornisce immagini del contenitore firmate, in modo che il tuo cluster Kubernetes possa verificare che il codice in esecuzione sia il codice che hai inviato al registro dal tuo sistema di compilazione. Le immagini firmate garantiscono che nessuno abbia manomesso il contenuto di un contenitore durante la distribuzione. In secondo luogo, ACR può integrarsi con il Centro sicurezza di Azure. Ciò consente di scansionare le immagini così come sono archiviate nel registro, controllando non solo le vulnerabilità nel codice e nell'immagine di base, ma anche in tutte le dipendenze incluse o a cui fa riferimento il file immagine. Utilizzando lo scanner di Qualys, i report del Centro sicurezza ti aiuteranno a identificare le vulnerabilità con consigli per le correzioni.

Le cose si fanno interessanti quando inizi a utilizzare le tue istanze ACR per più di contenitori. OCI ha iniziato ad aprire lo standard del registro agli artefatti, con Helm, lo strumento de facto per la distribuzione delle applicazioni Kubernetes, utilizzandolo nell'ultima versione. Il settore ha visto una proliferazione di registri e repository e ha senso standardizzarne uno per tutti i componenti dell'applicazione, soprattutto quando fanno tutti parte della stessa applicazione cloud-native.

ACR ora supporta OCI Registry As Storage (ORAS). Utilizzando uno strumento ORAS puoi eseguire il push e il pull di tutti i tuoi artefatti dallo stesso repository ACR. Installa ORAS sui tuoi computer sviluppatori o aggiungi supporto alla pipeline di build. Dopo aver effettuato l'accesso al registro con un'entità servizio di Azure Active Directory che dispone dei diritti di push, usa lo strumento della riga di comando ORAS per inviare nuovi elementi al registro.

L'utilizzo di uno strumento da riga di comando nell'interfaccia della riga di comando di Azure ti offre la flessibilità di creare il push ORAS nella tua scelta di strumenti di compilazione, come uno script che può essere chiamato come e quando necessario. Lo stesso strumento della riga di comando può estrarre gli artefatti e puoi incorporarli negli script di distribuzione in modo che tutti i componenti che compongono le tue applicazioni possano distribuirsi automaticamente quando una nuova build viene inviata ai tuoi repository ACR.

Il codice privato necessita di repository privati ​​e mantenere i contenitori e altri elementi di build in Azure li colloca dove sono necessari. Un processo di compilazione devops completo dovrebbe passare dal commit del codice all'esecuzione dell'applicazione senza alcun intervento umano, rendendo strumenti come Azure Container Registry e i componenti essenziali dell'automazione delle attività associate in qualsiasi pipeline destinata ad Azure. Non solo il codice viene archiviato e distribuito automaticamente su scala globale, ma viene sottoposto a scansione per i rischi per la sicurezza ogni volta che viene apportata una modifica.