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:
- Conoscenza di base di Servizi di Azure
- Capacità di progettare applicazioni di Azure per architetture diverse
- Conoscenza pratica di Azure Resource Manager
- Conoscenza del funzionamento di JSON
- Conoscenza del lavoro di Helm
- Conoscenza del funzionamento di createUiDefinition
- Conoscenza del funzionamento dei modelli di Azure Resource Manager (ARM)
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.
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:
Microsoft.Authorization/roleAssignments/writeautorizzazioni, ad esempio Amministratore accesso utente 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 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.yamlcome riferimenti global.azure.images. Aggiornaredeployment.yamlper puntare queste immagini. Ciò garantisce che il blocco di immagini possa essere aggiornato e a cui fa riferimento Azure Marketplace del Registro Azure Container.
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.
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.yamlfile.
Aggiungere un valore di identificatore di fatturazione per
global.azure.billingidentifierinvalues.yaml.
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-identifierdi identificatore di fatturazione aldeployment.yamlfile (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/managedClustersMicrosoft.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 :
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:
Da qui, i valori vengono passati al modello di Resource Manager di Azure e verranno propagati al grafico Helm durante la distribuzione:
Infine, i valori vengono utilizzati dal grafico Helm:
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.