Preparare gli asset tecnici del contenitore di Azure per un'app Kubernetes
Questo articolo offre risorse tecniche e consigli utili per creare un'offerta di contenitore in Azure Marketplace per un'applicazione Kubernetes.
Per un esempio completo degli asset tecnici necessari per un'offerta contenitore basata su app Kubernetes, vedere Esempi di offerte di contenitori di Azure Marketplace per Kubernetes.
Conoscenze tecniche fondamentali
La progettazione, la compilazione e il test di queste risorse richiedono tempo e conoscenze tecniche sia della piattaforma di Azure che delle tecnologie usate per creare l'offerta.
Oltre alle conoscenze relative al dominio della soluzione, il team tecnico deve conoscere le seguenti tecnologie Microsoft:
- Conoscenza di base di Servizi di Azure
- Capacità di progettare applicazioni di Azure per architetture diverse
- Conoscenza pratica di Azure Resource Manager
- Conoscenza pratica di JSON
- Conoscenza operativa di Helm
- Conoscenza di createUiDefinition
- Conoscenza dei modelli di Azure Resource Manager (ARM)
Prerequisiti
L'applicazione deve essere basata sul grafico Helm.
Se sono presenti più grafici, è possibile includere altri grafici helm come sottochart a parte il grafico helm principale.
Tutti i riferimenti all'immagine e i dettagli del digest devono essere inclusi nel grafico. Non è possibile scaricare altri grafici o immagini in fase di esecuzione.
È necessario disporre di un tenant di pubblicazione attivo o di accedere a un tenant di pubblicazione e a un account del Centro per i partner.
È necessario aver creato un Registro Azure Container (ACR) che appartiene al tenant di pubblicazione attivo precedente. Si caricherà il bundle di applicazioni native cloud (CNAB) in tale bundle. Per altre informazioni, vedere Creare un Registro Azure Container.
Installare la versione più recente dell'interfaccia della riga di comando di Azure.
L'applicazione deve essere distribuibile nell'ambiente Linux.
Le immagini devono essere prive di vulnerabilità. Per informazioni sull'analisi delle vulnerabilità, vedere Valutazioni delle vulnerabilità per Azure con Gestione delle vulnerabilità di Microsoft Defender.
Se si esegue manualmente lo strumento di creazione pacchetti, Docker deve essere installato un computer locale. Per altre informazioni, vedere la sezione back-end WSL 2 nella documentazione di Docker per Windows o Linux. Questa funzionalità è supportata solo nei computer Linux/Windows AMD64.
Limiti
- Container Marketplace supporta solo immagini AMD64 basate sulla piattaforma Linux.
- Solo servizio Azure Kubernetes gestito.
- I singoli contenitori non sono supportati.
- I modelli di Azure Resource Manager collegati non sono supportati.
Panoramica della pubblicazione
Il primo passaggio per pubblicare l'offerta contenitore basata su app Kubernetes in Azure Marketplace consiste nel creare un pacchetto dell'applicazione come bundle di applicazioni native cloud (CNAB). Il CNAB, costituito dagli artefatti dell'applicazione, viene prima pubblicato nell'Registro Azure Container privato (ACR) e successivamente inserito in un Registro Azure Container pubblico di proprietà microsoft e viene usato come singolo artefatto a cui si fa riferimento nel Centro per i partner.
Da qui viene eseguita l'analisi delle vulnerabilità per garantire la sicurezza delle immagini. Infine, l'applicazione Kubernetes viene registrata come tipo di estensione per un cluster servizio Azure Kubernetes (servizio Azure Kubernetes).
Dopo la pubblicazione dell'offerta, l'applicazione sfrutta le estensioni del cluster per la funzionalità servizio Azure Kubernetes per gestire il ciclo di vita dell'applicazione all'interno di un cluster del servizio Azure Kubernetes.
Concedere l'accesso al Registro Azure Container
Nell'ambito del processo di pubblicazione, Microsoft copia in modo approfondito il cnab dal Registro Azure Container a un registro azure di proprietà di Microsoft, specifico di Azure Marketplace. Le immagini vengono caricate in un registro pubblico accessibile a tutti. Questo passaggio richiede di concedere a Microsoft l'accesso al Registro di sistema. Il Registro Azure Container deve trovarsi nello stesso tenant di Microsoft Entra collegato all'account del Centro per i partner.
Microsoft ha un'applicazione proprietaria responsabile della gestione di questo processo con un id di 32597670-3e15-4def-8851-614ff48c1efa. Per iniziare, creare un'entità servizio basata sull'applicazione:
Nota
Se l'account non dispone dell'autorizzazione per creare un'entità servizio, az ad sp create restituisce un messaggio di errore contenente "Privilegi insufficienti per completare l'operazione". Contattare l'amministratore di Microsoft Entra per creare un'entità servizio.
az login
Verificare se per l'applicazione esiste già un'entità servizio:
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
Se il comando precedente non restituisce risultati, creare una nuova entità servizio:
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
Prendere nota dell'ID dell'entità servizio da usare nei passaggi seguenti.
Ottenere quindi l'ID completo del Registro di sistema:
az acr show --name <registry-name> --query "id" --output tsv
L'output dovrebbe essere simile al seguente:
...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
Creare quindi un'assegnazione di ruolo per concedere all'entità servizio la possibilità di eseguire il pull dal Registro di sistema usando i valori ottenuti in precedenza:
Per assegnare ruoli di Azure, è necessario disporre di:
Microsoft.Authorization/roleAssignments/writeautorizzazioni, ad esempio accesso utente Amministrazione istrator o proprietario
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Registrare infine il Microsoft.PartnerCenterIngestion provider di risorse nella stessa sottoscrizione usata per creare il Registro Azure Container:
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Monitorare la registrazione e verificare che sia stata completata prima di procedere:
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Raccogliere gli artefatti per soddisfare i requisiti di formato del pacchetto
Ogni CNAB è costituito dagli artefatti seguenti:
- Grafico Helm
- CreateUiDefinition
- Modello ARM
- File manifesto
Aggiornare il grafico Helm
Verificare che il grafico Helm sia conforme alle regole seguenti:
Tutti i nomi e i riferimenti delle immagini vengono parametrizzati e rappresentati in
values.yamlcome riferimenti global.azure.images. Aggiornare il filedeployment.yamlmodello di grafico Helm in modo che punti a queste immagini. In questo modo il blocco di immagini può essere aggiornato per fare riferimento alle immagini del Registro Azure Marketplace.
Se sono presenti più grafici, è possibile includere altri grafici helm come sottochart a parte il grafico helm principale. Aggiornare quindi ogni riferimento all'immagine
values.yamldipendente in modo che punti alle immagini incluse nel grafico principale.Quando si fa riferimento alle immagini, è possibile usare tag o digest. Tuttavia, è importante notare che le immagini vengono internamente contrassegnate per puntare al Registro Azure Container di proprietà di Microsoft. Quando si aggiorna un tag, è necessario inviare una nuova versione di CNAB ad Azure Marketplace. Ciò significa che le modifiche possono essere riflesse nelle distribuzioni dei clienti.
Modelli di fatturazione disponibili
Per tutti i modelli di fatturazione disponibili, vedere le opzioni di licenza per le applicazioni Azure Kubernetes.
Apportare aggiornamenti in base al modello di fatturazione
Dopo aver esaminato i modelli di fatturazione disponibili, selezionare uno appropriato per il caso d'uso e completare i passaggi seguenti:
Completare i passaggi seguenti per aggiungere l'identificatore nei modelli di fatturazione Per core, Per pod, Per nodo :
Aggiungere un'etichetta
azure-extensions-usage-release-identifierdi identificatore di fatturazione alla specifica Pod nei file yaml del carico di lavoro .Se il carico di lavoro viene specificato come distribuzioni o set di repliche o specifiche statefulset o Daemonsets, aggiungere questa etichetta in .spec.template.metadata.labels.
Se il carico di lavoro viene specificato direttamente come specifiche pod, aggiungere questa etichetta in .metadata.labels.
Per il modello di fatturazione perCore , specificare la richiesta cpu includendo il
resources:requestscampo nel manifesto della risorsa contenitore. Questo passaggio è obbligatorio solo per il modello di fatturazione perCore.
In fase di distribuzione, la funzionalità estensioni del cluster sostituisce il valore dell'identificatore di fatturazione con il nome dell'istanza dell'estensione.
Per esempi configurati per distribuire l'app Azure Voting, vedere quanto segue:
Per il modello di fatturazione dei contatori personalizzati, aggiungere i campi elencati di seguito nel file values.yaml del modello Helm
- clientId deve essere aggiunto in global.azure.identity
- la chiave planId deve essere aggiunta in global.azure.marketplace. planId
- resourceId deve essere aggiunto in global.azure.extension.resrouceId
In fase di distribuzione, la funzionalità estensioni cluster sostituisce questi campi con i valori appropriati. Per esempi, vedere l'app basata sui contatori personalizzati di Azure Vote.
Creare il file dei parametri di test
Un file di parametri di test è un file JSON usato insieme a un modello di Resource Manager per distribuire una risorsa in Azure. Per le applicazioni o le estensioni che possono essere distribuite nei cluster gestiti , è necessario specificare il file di parametri per la convalida della distribuzione. Il file dei parametri di test deve includere valori che consentano la corretta distribuzione dei test.
Nota
Non tutti i parametri devono essere inclusi nel file di parametri, ma solo i parametri che non hanno un valore predefinito. Per indicazioni, vedere qui.
Ecco un file di parametri di test di esempio:
Dopo aver creato il file dei parametri di test, aggiungerlo al file manifesto:
Nota
Per le situazioni in cui un file di parametri di test non sarebbe applicabile all'applicazione (ad esempio: l'applicazione richiede segreti per la distribuzione come una chiave API o un'applicazione distribuita nei cluster connessi), viene fornito un flag skipdeployment per consentire di ignorare i test di distribuzione.
Convalidare il grafico Helm
Per assicurarsi che il grafico Helm sia valido, verificare che sia installabile in un cluster locale. È anche possibile usare helm install --generate-name --dry-run --debug per rilevare determinati errori di generazione del modello.
Creare e testare createUiDefinition
CreateUiDefinition è un file JSON che definisce gli elementi dell'interfaccia utente per il portale di Azure durante la distribuzione dell'applicazione. Per altre informazioni, vedi:
- CreateUiDefinition.json per Azure
- oppure vedere un esempio di definizione dell'interfaccia utente che richiede dati di input per una scelta di cluster nuova o esistente e passa i parametri nell'applicazione.
Dopo aver creato il file createUiDefinition.json per l'applicazione, è necessario testare l'esperienza utente. Per semplificare il test, copiare il contenuto del file nell'ambiente sandbox. La sandbox presenta l'interfaccia utente nell'esperienza corrente del portale a schermo intero. La sandbox è il modo consigliato per visualizzare in anteprima l'interfaccia utente.
Creare il modello di Azure Resource Manager (ARM)
Un modello di Resource Manager definisce le risorse di Azure da distribuire. Per impostazione predefinita, si distribuirà una risorsa di estensione del cluster per l'applicazione Azure Marketplace. Facoltativamente, è possibile scegliere di distribuire un cluster del servizio Azure Kubernetes.
Attualmente sono consentiti solo i tipi di risorse seguenti:
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Ad esempio, vedere questo modello di Azure Resource Manager di esempio progettato per ottenere i risultati dalla definizione dell'interfaccia utente di esempio collegata in precedenza e passare i parametri all'applicazione.
Flusso di parametri utente
È importante comprendere il flusso dei parametri utente in tutti gli artefatti che si stanno creando e creando e creando pacchetti. Nell'esempio di app Azure Voting i parametri vengono inizialmente definiti durante la creazione dell'interfaccia utente tramite un file di createUiDefinition.json:
I parametri vengono esportati tramite la outputs sezione :
Da qui, i valori vengono passati al modello di Azure Resource Manager e vengono propagati al grafico Helm durante la distribuzione:
Infine, i valori vengono passati al grafico Helm attraverso values.yaml come illustrato.
Nota
In questo esempio viene extensionResourceName anche parametrizzato e passato alla risorsa dell'estensione del cluster. Analogamente, è possibile parametrizzare altre proprietà di estensione, ad esempio l'abilitazione dell'aggiornamento automatico per le versioni secondarie. Per altre informazioni sulle proprietà dell'estensione del cluster, vedere parametri facoltativi.
Creare il file manifest
Il manifesto del pacchetto è un file yaml che descrive il pacchetto e il relativo contenuto e indica allo strumento di creazione pacchetti dove individuare gli artefatti dipendenti.
I campi usati nel manifesto sono i seguenti:
| Nome | Tipo di dati | Descrizione |
|---|---|---|
| applicationName | String | Nome dell'applicazione |
| publisher | String | Nome del server di pubblicazione |
| description | Stringa | Breve descrizione del pacchetto |
| versione | Stringa in #.#.# formato |
Stringa di versione che descrive la versione del pacchetto dell'applicazione, potrebbe o non corrispondere alla versione dei file binari all'interno. |
| helmChart | String | Directory locale in cui è possibile trovare il grafico Helm in relazione a questo manifest.yaml |
| clusterARMTemplate | String | Percorso locale in cui è disponibile un modello di Resource Manager che descrive un cluster del servizio Azure Kubernetes che soddisfa i requisiti nel campo restrizioni |
| uiDefinition | String | Percorso locale in cui è disponibile un file JSON che descrive un'esperienza di creazione portale di Azure |
| registryServer | String | Registro Azure Container in cui deve essere inserito il bundle CNAB finale |
| extensionRegistrationParameters | Raccolta | Specifica per i parametri di registrazione dell'estensione. Includere almeno defaultScope e come parametro. |
| defaultScope | String | Ambito predefinito per l'installazione dell'estensione. I valori accettati sono cluster o namespace. Se cluster l'ambito è impostato, è consentita una sola istanza di estensione per ogni cluster. Se namespace l'ambito è selezionato, è consentita una sola istanza per spazio dei nomi. Poiché un cluster Kubernetes può avere più spazi dei nomi, possono esistere più istanze di estensione. |
| namespace | String | (Facoltativo) Specificare lo spazio dei nomi in cui viene installata l'estensione. Questa proprietà è obbligatoria quando defaultScope è impostata clustersu . Per le restrizioni di denominazione degli spazi dei nomi, vedere Spazi dei nomi e DNS. |
| supportedClusterTypes | Raccolta | (Facoltativo) Specificare i tipi di cluster supportati dall'applicazione. I tipi consentiti sono: "managedClusters", "connectedClusters". "managedClusters" fa riferimento a cluster servizio Azure Kubernetes (AKS). "connectedClusters" fa riferimento ai cluster Kubernetes abilitati per Azure Arc. Se supportedClusterTypes non viene fornito, tutte le distribuzioni di 'managedClusters' sono supportate per impostazione predefinita. Se supportatoClusterTypes viene fornito e non viene fornito un determinato tipo di cluster di primo livello, tutte le distribuzioni e le versioni di Kubernetes per tale tipo di cluster vengono considerate non supportate. Per ogni tipo di cluster, specificare un elenco di una o più distribuzioni con le proprietà seguenti: -Distribuzione - distributionSupported - unsupportedVersions |
| distribution | List | Matrice di distribuzioni corrispondenti al tipo di cluster. Specificare il nome di distribuzioni specifiche. Impostare il valore su ["All"] per indicare che tutte le distribuzioni sono supportate. |
| distributionSupported | Booleano | Valore booleano che indica se le distribuzioni specificate sono supportate. Se false, specificando UnsupportedVersions si verifica un errore. |
| unsupportedVersions | List | Elenco di versioni per le distribuzioni specificate non supportate. Operatori supportati: - La versione specificata "=" non è supportata. Ad esempio, "=1.2.12" - ">" Tutte le versioni successive alla versione specificata non sono supportate. Ad esempio, ">1.1.13" - "<" Tutte le versioni minori della versione specificata non sono supportate. Ad esempio, "<1.3.14" - "..." Tutte le versioni dell'intervallo non sono supportate. Ad esempio, "1.1.2...1.1.15" (include il valore a destra ed esclude il valore a sinistra) |
Per un esempio configurato per l'app di voto, vedere l'esempio di file manifesto seguente.
Strutturare l'applicazione
Posizionare il file createUiDefinition, arm template e manifest accanto al grafico Helm dell'applicazione.
Per un esempio di directory strutturata correttamente, vedere Esempio di voto di Azure.
Per un esempio dell'applicazione di voto che supporta i cluster Kubernetes abilitati per Azure Arc, vedere Connessione edCluster-only sample .For a sample of voting application that supports Azure Arc-enabled Kubernetes clusters, see Connessione edCluster-only sample .
Per un esempio dell'applicazione di voto che supporta cluster kubernetes servizio Azure Kubernetes (AKS) e cluster Kubernetes abilitati per Azure Arc, vedere Connessione ed e Managed Cluster sample (Esempio di cluster gestito e Connessione).
Per altre informazioni su come configurare un cluster Kubernetes abilitato per Azure Arc per la convalida dell'applicazione, vedere Avvio rapido: Connessione un cluster Kubernetes esistente in Azure Arc.
Usare lo strumento di creazione di pacchetti dei contenitori
Dopo aver aggiunto tutti gli artefatti necessari, eseguire lo strumento container-package-appdi creazione pacchetti .
Poiché i CNAB sono un nuovo formato e hanno una curva di apprendimento, è stata creata un'immagine Docker per container-package-app con l'ambiente di bootstrap e gli strumenti necessari per eseguire correttamente lo strumento di creazione pacchetti.
Sono disponibili due opzioni per usare lo strumento di creazione pacchetti. È possibile usarlo manualmente o integrarlo in una pipeline di distribuzione.
Eseguire manualmente lo strumento di creazione pacchetti
L'immagine più recente dello strumento di creazione pacchetti può essere estratta da mcr.microsoft.com/container-package-app:latest.
Il comando Docker seguente esegue il pull dell'immagine più recente dello strumento di creazione di pacchetti e monta anche una directory.
Supponendo ~\<path-to-content> che sia una directory contenente il contenuto da inserire nel pacchetto, il comando docker seguente viene montato /data~/<path-to-content> in nel contenitore. Assicurarsi di sostituire ~/<path-to-content> con la posizione dell'app.
docker pull mcr.microsoft.com/container-package-app:latest
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest
Eseguire i comandi seguenti nella shell del container-package-app contenitore. Assicurarsi di sostituire <registry-name> con il nome del Registro Azure Container:
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Per autenticare il Registro Azure Container, sono disponibili due opzioni. Un'opzione consiste nell'usare az login come illustrato in precedenza e la seconda opzione è tramite Docker eseguendo docker login 'yourACRname'.azurecr.io. Immettere il nome utente e la password (il nome utente deve essere il nome del Registro Azure Container e la password è la chiave generata in portale di Azure) ed eseguire.
docker login <yourACRname.azurecr.io>
cpa verify Eseguire quindi per scorrere gli artefatti e convalidarli uno alla sola. Risolvere eventuali errori ed eseguire cpa buildbundle quando si è pronti per creare un pacchetto e caricare cnab nel Registro Azure Container. Il cpa buildbundle comando esegue anche il processo di verifica prima della compilazione
cpa verify
cpa buildbundle
Nota
Usare cpa buildbundle --force solo se si desidera sovrascrivere un tag esistente. Se il cnab è già associato a un'offerta di Azure Marketplace, incrementare invece la versione nel file manifesto.
Eseguire l'integrazione in una pipeline di Azure
Per un esempio di come eseguire l'integrazione container-package-app in una pipeline di Azure, vedere l'esempio di Azure Pipeline
Risoluzione dei problemi
- Guida alla risoluzione dei problemi relativi alla creazione di pacchetti
- Guida alla risoluzione dei problemi di pubblicazione
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per