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.

• Il grafico Helm non deve includere .tgz file di archivio. Tutti i file devono essere decompressi.

• 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 indicazioni su come specificare i requisiti di analisi delle vulnerabilità, vedere Risolvere i problemi di certificazione dei contenitori. 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.
• L'offerta Marketplace per contenitori supporta la distribuzione nel servizio Azure Kubernetes gestito e in Kubernetes abilitato per Arc. Una singola offerta può scegliere come destinazione un solo tipo di cluster, ovvero il servizio Azure Kubernetes gestito o Kubernetes abilitato per Arc.
• Le offerte per i cluster Kubernetes abilitati per Arc supportano solo modelli di fatturazione predefiniti. Per altre informazioni sui modelli di fatturazione, vedere Pianificare un'offerta di Azure Container.
• 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:

az login

az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa 

az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa

az acr show --name <registry-name> --query "id" --output tsv

...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull

az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait

az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>

Connect-AzAccount

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App" 

New-AzADServicePrincipal -ApplicationId 32597670-3e15-4def-8851-614ff48c1efa

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App"

Select-AzSubscription -SubscriptionId <subscriptionId>
Get-AzContainerRegistry -ResourceGroupName <resource-group> -Name <registry-name>

...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

New-AzRoleAssignment -ObjectId <sp-id> -Role acrpull -Scope <registry-id>

Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscription-id>
Register-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

Get-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

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.yaml come riferimenti global.azure.images. Aggiornare il file deployment.yaml modello 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. Tutti i riferimenti alle immagini dei grafici Helm dipendenti avranno bisogno di aggiornamenti e devono puntare alle immagini incluse nel grafico values.yamlprincipale.

• 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-identifier di 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:requests campo 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:

• Esempio di file di distribuzione.
• Esempio di file di valori.

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.

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/managedClusters
• Microsoft.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.

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:

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 Esempio di solo ConnectedCluster.

Per altre informazioni su come configurare un cluster Kubernetes abilitato per Azure Arc per la convalida dell'applicazione, vedere Avvio rapido: Connettere un cluster Kubernetes esistente ad Azure Arc.

Usare lo strumento di creazione di pacchetti dei contenitori

Dopo aver aggiunto tutti gli artefatti necessari, eseguire lo strumento container-package-app di creazione pacchetti per convalidare gli artefatti, compilare il pacchetto e caricare il pacchetto nella Registro Azure Container.

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.

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 

export REGISTRY_NAME=<registry-name>

az login 

az acr login -n $REGISTRY_NAME 

cd /data/<path-to-content>

docker login <yourACRname.azurecr.io>

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v d:/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

cpa verify Eseguire quindi per scorrere gli artefatti e convalidarli uno per uno e risolvere eventuali errori. Eseguire cpa buildbundle quando si è pronti per creare un pacchetto e caricare cnab nel Registro Azure Container. Il cpa buildbundle comando esegue il processo di verifica, compila il pacchetto e carica il pacchetto nel Registro Azure Container.

cpa verify

cpa buildbundle 

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

Contenuto correlato

• Creare l'offerta Kubernetes