Preparare gli asset tecnici di Azure Container per un'app Kubernetes

Questo articolo fornisce risorse tecniche e consigli per creare un'offerta di contenitori 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 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:

Prerequisiti

  • L'applicazione deve essere basata sul grafico Helm.

  • Tutti i riferimenti all'immagine e i dettagli del digest devono essere inclusi nel grafico. Non è possibile scaricare grafici o immagini aggiuntivi 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) a cui caricare il bundle di applicazioni native cloud e concedere l'autorizzazione all'ID dell'app di prima parte Microsoft per accedere al Registro Azure Container.You must have have create an Registro Azure Container (ACR) to you's upload the Cloud Native Application Bundle (CNAB) and give permission to Microsoft's first party app ID to access your ACR. 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 distribuita nell'ambiente Linux.

  • Se si esegue manualmente lo strumento di creazione pacchetti CNAB, è necessario installare docker nel computer locale.

Limitazioni

  • 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 collegati Resource Manager non sono supportati.

Importante

L'esperienza dell'offerta basata su applicazioni Kubernetes è disponibile in anteprima. Le funzionalità di anteprima sono disponibili su base self-service, opt-in. Le anteprime vengono fornite "come è" e "come disponibili", e vengono escluse dai contratti a livello di servizio e dalla garanzia limitata. Le anteprime sono parzialmente coperte dal supporto clienti su base ottimale. Di conseguenza, queste funzionalità non sono destinate all'uso di produzione.

Panoramica della pubblicazione

Il primo passaggio per pubblicare l'offerta contenitore basata su app Kubernetes nel Azure Marketplace consiste nel creare un pacchetto dell'applicazione come bundle di applicazioni native cloud (CNAB). Questo CNAB, costituito dagli artefatti dell'applicazione, verrà prima pubblicato nel Registro Azure Container privato (ACR) e successivamente eseguito il push in un Registro Azure Container di proprietà Di Microsoft e verrà usato come singolo artefatto a cui si fa riferimento nel Centro per i partner.

Da qui viene eseguita l'analisi della vulnerabilità per garantire che le immagini siano sicure. Infine, l'applicazione Kubernetes viene registrata come tipo di estensione per un cluster servizio Azure Kubernetes (AKS).

Una volta pubblicata l'offerta, l'applicazione sfrutta le estensioni del cluster per la funzionalità del servizio Azure Kubernetes per gestire il ciclo di vita dell'applicazione all'interno di un cluster del servizio Azure Kubernetes.

Diagramma che mostra le tre fasi dell'elaborazione dei bundle, passando da

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 Container di proprietà di Microsoft, Azure Marketplace registro di certificazione specifico. Questo passaggio richiede di concedere l'accesso a Microsoft al Registro di sistema.

Microsoft ha creato un'applicazione di prima parte responsabile della gestione di questo processo con un id oggetto .32597670-3e15-4def-8851-614ff48c1efa Per iniziare, creare un'entità servizio basata sull'applicazione:

Nota

Se l'account in uso non è autorizzato a creare un'entità servizio, az ad sp create restituisce un messaggio di errore contenente "I privilegi non sono sufficienti per completare l'operazione". Per creare un'entità servizio, contattare l'amministratore di Azure Active Directory.

az login
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:

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 la 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 elementi per soddisfare i requisiti di formato del pacchetto

Ogni CNAB sarà composto dagli artefatti seguenti:

  • Grafico Helm

  • CreateUiDefinition

  • Modello ARM

  • File manifesto

Aggiornare il grafico Helm

Assicurarsi che il grafico Helm sia conforme alle regole seguenti:

  • Tutti i nomi di immagine e i riferimenti sono parametrizzati e rappresentati in values.yaml come riferimenti global.azure.images. Aggiornare deployment.yaml per puntare queste immagini. Ciò garantisce che il blocco di immagini possa essere aggiornato e a cui fa riferimento Azure Marketplace del Registro Azure Container.

    Viene visualizzata una schermata di un file deployment.yaml formattato correttamente. I riferimenti all'immagine con parametri vengono visualizzati, in modo simile al contenuto nel file deployment.yaml di esempio collegato in questo articolo.

  • Se sono presenti sottochart, estrarre il contenuto nei grafici e aggiornare ognuno dei riferimenti all'immagine values.yamldipendente per puntare alle immagini incluse nel grafico principale.

  • Le immagini devono usare i digest anziché i tag. Ciò garantisce che la compilazione CNAB sia deterministica.

    Viene visualizzata una schermata di un file con formattazione corretta.yaml. Le immagini usano i digest. Il contenuto è simile al file sample values.yaml collegato in questo articolo.

Modelli di fatturazione disponibili

Opzione gestione licenze Processo di transazione
Gratuito Elencare l'offerta ai clienti gratuitamente.
Portare le proprie licenze (BYOL) L'opzione Bring Your Own Licensing consente ai clienti di trasferire licenze software esistenti in Azure.*
Per ogni core nel cluster Elencare l'offerta di Azure Container con prezzi addebitati in base al numero totale di core CPU nel cluster (segnalato in frequenza oraria). Si fornisce il prezzo per un core CPU e si incrementeranno i prezzi in base al numero totale di core CPU nel cluster.
Per core Elencare l'offerta di Azure Container con i prezzi addebitati per ogni core usata dall'istanza di estensione dell'applicazione Kubernetes (segnalata in frequenza oraria). Si fornisce il prezzo per un core CPU e si incrementeranno i prezzi in base ai core usati dall'istanza dell'applicazione Kubernetes nel cluster.
Per cluster Elencare l'offerta di Azure Container con i prezzi addebitati per ogni istanza dell'estensione dell'applicazione Kubernetes nel cluster (segnalata in frequenza oraria). Viene fornito il prezzo per un'istanza dell'applicazione Kubernetes e verranno incrementati i prezzi in base al numero di istanze dell'applicazione Kubernetes nel cluster.
Per ogni nodo nel cluster Elencare l'offerta di Azure Container con prezzi addebitati in base al numero totale di nodi nel cluster (segnalato in frequenza oraria). Si specifica il prezzo per un nodo nel cluster e si incrementeranno i prezzi in base alle dimensioni dell'hardware nel cluster.
Per nodo Elencare l'offerta di Azure Container con i prezzi addebitati per ogni nodo in cui viene eseguita l'istanza dell'applicazione Kubernetes (segnalata in frequenza oraria). Viene fornito il prezzo per un nodo nel cluster e verranno incrementati i prezzi in base al numero di nodi in cui viene eseguita l'istanza dell'applicazione Kubernetes nel cluster.
Per pod Elencare l'offerta di Azure Container con i prezzi addebitati per ogni pod in cui viene eseguita l'istanza dell'applicazione Kubernetes (segnalata in frequenza oraria). Viene fornito il prezzo per un nodo nel cluster e verranno incrementati i prezzi in base al numero di pod usati in cui viene eseguita l'istanza dell'applicazione Kubernetes nel cluster.
  • Come editore, si supportano tutti gli aspetti della transazione di licenza software, incluso (ma non limitato a) ordine, evasione, misurazione, fatturazione, fatturazione, pagamento e raccolta.

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 la procedura seguente:

Completare i passaggi seguenti per aggiungere l'identificatore nel modello di fatturazione Per core :

  • Aggiungere un'etichetta di identificatore di fatturazione e le richieste di core cpu al deployment.yaml file.

    Screenshot di un'etichetta di identificatore di fatturazione formattata correttamente in un file deployment.yaml. Il contenuto è simile al file depoyment.yaml di esempio collegato in questo articolo

    Screenshot delle richieste di risorse CPU in un file deployment.yaml. Il contenuto è simile al file depoyment.yaml di esempio collegato in questo articolo.

  • Aggiungere un valore di identificatore di fatturazione per global.azure.billingidentifier in values.yaml.

    Screenshot di un file value.yaml formattato correttamente, che mostra il > campo global Azure > billingIdentifier.

Completare la procedura seguente per aggiungere un'etichetta di identificatore di fatturazione nel modello di fatturazione Per pod e Per nodo :

  • Aggiungere un'etichetta azure-extensions-usage-release-identifier di identificatore di fatturazione al deployment.yaml file (inEtichette>metadati>modello>).

Si noti che in fase di distribuzione, la funzionalità estensioni del cluster sostituirà il valore dell'identificatore di fatturazione con il nome del tipo di estensione specificato durante la configurazione dei dettagli del piano.

Per esempi configurati per distribuire l'app di voto di Azure, vedere quanto segue:

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 di modelli.

Creare e testare createUiDefinition

Un createUiDefinition è un file JSON che definisce gli elementi dell'interfaccia utente per il portale di Azure durante la distribuzione dell'applicazione. Per altre informazioni, vedere CreateUiDefinition.json per Azure o vedere un esempio di definizione dell'interfaccia utente che chiede dati di input per una scelta di cluster nuova o esistente e passa i parametri all'applicazione.

Dopo aver creato il file createUiDefinition.json per l'applicazione, è necessario testare l'esperienza utente. Per semplificare il test, usare un ambiente sandbox che carica il file nel portale. 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. Verrà distribuita 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 arm di esempio progettato per ottenere risultati dalla definizione dell'interfaccia utente di esempio collegata in precedenza e passare i parametri nell'applicazione.

Creare il file manifesto

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 string Breve descrizione del pacchetto
version Stringa in #.#.# formato Stringa di versione che descrive la versione del pacchetto dell'applicazione, può o non corrispondere alla versione dei file binari all'interno. Mappato al campo della versione di Porter
helmChart string Directory locale in cui è possibile trovare il grafico Helm rispetto a questo manifest.yaml
clusterARMTemplate string Percorso locale in cui è possibile trovare 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 di portale di Azure
registryServer string Registro Azure Container in cui deve essere eseguito il push del 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 solo un'istanza di estensione per cluster. Se namespace l'ambito è selezionato, è consentita una sola istanza per spazio dei nomi. Poiché un cluster Kubernetes può avere più spazi dei nomi, è possibile che esistano più istanze di estensione.
namespace string (Facoltativo) Specificare lo spazio dei nomi in cui verrà installata l'estensione. Questa proprietà è necessaria quando defaultScope è impostata su cluster. Per le restrizioni di denominazione dello spazio dei nomi, vedere Spazi dei nomi e DNS.

Per un esempio configurato per l'app di voto, vedere l'esempio di file manifesto seguente.

Flusso di parametri utente

È importante comprendere il flusso dei parametri utente in tutti gli artefatti creati e di creazione e creazione di pacchetti. I parametri vengono inizialmente definiti durante la creazione dell'interfaccia utente tramite un file createUiDefinition.json :

Screenshot dell'esempio createUiDefinition collegato in questo articolo. Vengono visualizzate le definizioni per 'value1' e 'value2'.

Nota

In questo esempio viene extensionResourceName anche parametrizzato e passato alla risorsa di estensione del cluster. Analogamente, altre proprietà di estensione possono essere parametrizzate, ad esempio l'abilitazione dell'aggiornamento automatico per le versioni secondarie. Per altre informazioni sulle proprietà dell'estensione del cluster, vedere parametri facoltativi.

e vengono esportati tramite la outputs sezione:

Screenshot dell'esempio createUiDefinition collegato in questo articolo. Vengono visualizzate le righe di output per il titolo dell'applicazione, 'value1' e 'value2'.

Da qui, i valori vengono passati al modello di Resource Manager di Azure e verranno propagati al grafico Helm durante la distribuzione:

Screenshot dell'esempio di modello di Azure Resource Manager collegato in questo articolo. In 'configurationSettings', vengono visualizzati i parametri per il titolo dell'applicazione, 'value1' e 'value2'.

Infine, i valori vengono utilizzati dal grafico Helm:

Screenshot dell'esempio di grafico Helm collegato in questo articolo. I valori per il titolo dell'applicazione, 'value1' e 'value2' vengono visualizzati.

Strutturare l'applicazione

Posizionare il file createUiDefinition, arm template e manifesto accanto al grafico Helm dell'applicazione.

Per un esempio di directory strutturata correttamente, vedere il repository di esempio.

Usare lo strumento di creazione pacchetti di contenitori

Dopo aver aggiunto tutti gli artefatti necessari, eseguire lo strumento container-package-appdi creazione pacchetti .

Poiché I CNABS sono in genere nuovi formati e hanno una curva di apprendimento, è stata creata un'immagine Docker per container-package-app l'ambiente di avvio 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 pacchetti e monta anche una directory.

Supponendo ~\<path-to-content> che sia una directory contenente il contenuto da creare in pacchetto, il comando docker seguente verrà montato ~/<path-to-content> nel /data contenitore. Assicurarsi di sostituire ~/<path-to-content> con la posizione dell'app personalizzata.

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>

cpa verify Eseguire quindi per scorrere gli artefatti e convalidarli uno per uno. Risolvere eventuali errori ed eseguire cpa buildbundle quando si è pronti per il pacchetto e caricare il CNAB nel Registro Azure Container. Il cpa buildbundle comando eseguirà anche il processo di verifica prima della compilazione.

cpa verify

cpa buildbundle 

Nota

Usare cpa buildbundle --force solo se si vuole sovrascrivere un tag esistente. Se è già stato collegato questo CNAB a un'offerta Azure Marketplace, aumentare invece la versione nel file manifesto.

Integrare in una pipeline di Azure

Per un esempio di come integrare container-package-app in azure Pipeline, vedere l'esempio di Azure Pipeline.

Passaggi successivi