Informazioni sulle immagini dell'applicazione
Un'immagine in contenitori è una parte essenziale di qualsiasi applicazione distribuita che usa servizio Azure Kubernetes (servizio Azure Kubernetes). È possibile usare i tag per:
- Creare immagini del contenitore diverse necessarie.
- Archiviare le immagini in un registro contenitori.
- Distribuire una particolare immagine con tag.
In questa unità viene illustrato come la pipeline CI/CD usa le immagini dell'applicazione con tag.
Immagini del contenitore
Un'immagine del contenitore è un bundle software eseguibile che incapsula un'applicazione e tutte le relative dipendenze software. Questo modulo usa un'immagine del contenitore Docker per compilare l'applicazione del sito Web Contoso.
L'immagine Docker contiene il codice dell'applicazione ed eventuali dipendenze necessarie per creare un'immagine completamente eseguibile dell'applicazione. L'immagine del contenitore è configurata da un Dockerfile con un set di istruzioni per il runtime del contenitore.
Se si esamina il Dockerfile nella radice del fork, si noterà che l'immagine inizia usando un'altra immagine nginx come base. Invece di iniziare da zero, è comune iniziare con altre immagini che hanno i file necessari.
Si compila un'immagine da un Dockerfile usando il docker build comando .
Importante
Il docker build comando non funziona all'interno dell'ambiente Cloud Shell, perché l'uso di Docker all'interno di un contenitore in esecuzione non è consentito. Se si vuole testare il docker build . comando, clonare il repository in locale ed eseguire il comando usando la propria installazione docker.
Tag di immagine
I tag sono un aspetto importante dell'uso delle immagini dei contenitori. I tag possono indicare il tipo di immagine e distinguere tra più immagini con lo stesso nome.
Ad esempio, se si vuole che l'immagine Node.js in un repository inizi dal nodo 12, è possibile includere il tag FROM node:12 nel Dockerfile. Se si vuole iniziare dalla versione stabile più recente, è possibile usare il tag FROM node:current. I tag indicano il tipo di immagine e le operazioni previste.
La compilazione di un'immagine del contenitore usa la stessa tecnica della creazione di un repository GitHub e il percorso del contenitore Docker è in genere simile a repository/nome-immagine. Tuttavia, è possibile compilare più versioni della stessa immagine che usano tag per distinguerle.
In questo modulo si usano tag per etichettare le versioni di rilascio. Creare un tag per ogni versione di produzione usando v*.*.* regole di controllo delle versioni semantiche, ad esempio v1.0.0 per la versione 1.0.0. Ogni push con tag nel ramo principale genera un nuovo tag immagine con lo stesso nome del tag in tale push. I push senza tag generano solo il latest tag .
Tutti i push, contrassegnati e senza tag, aggiornano l'immagine latest con il codice più recente e la distribuiscono nella gestione temporanea. Anche le immagini contrassegnate con v* vengono distribuite nell'ambiente di produzione. Solo le immagini con tag ufficiali vengono distribuite nell'ambiente di produzione, mentre gli ambienti di staging e di produzione hanno sempre l'immagine latest di staging.
Registri contenitori
Un aspetto importante dell'uso di un'immagine è la posizione in cui è archiviata. Un registro contenitori è una posizione in cui archiviare i file di immagine in contenitori. Ad esempio, GitHub è un registro contenitori che archivia anche le modifiche e le versioni del codice. È possibile eseguire il push di nuove immagini dell'applicazione nei registri contenitori usando il docker push comando .
In questo modulo vengono archiviati i file di immagine dell'applicazione nell'istanza di Registro Azure Container creata nell'unità precedente. Dopo aver creato un token di accesso personale (PAT) ed emettere un certificato federato per l'autenticazione con GitHub e Azure, la pipeline automatizza essenzialmente i docker build comandi e docker push .
Dopo aver compreso le pipeline CI/CD e le immagini del contenitore con tag, passare all'unità successiva per iniziare a compilare la pipeline CI/CD di GitHub Actions.