Förbereda tekniska tillgångar för Azure-container för en Kubernetes-app
Den här artikeln innehåller tekniska resurser och rekommendationer som hjälper dig att skapa ett containererbjudande på Azure Marketplace för ett Kubernetes-program.
Ett omfattande exempel på de tekniska tillgångar som krävs för ett Kubernetes-appbaserat containererbjudande finns i Azure Marketplace Container-erbjudandeexempel för Kubernetes.
Grundläggande teknisk kunskap
Det tar tid att utforma, skapa och testa dessa tillgångar och kräver teknisk kunskap om både Azure-plattformen och de tekniker som används för att skapa erbjudandet.
Utöver din lösningsdomän bör ditt ingenjörsteam ha kunskap om följande Microsoft-tekniker:
- Grundläggande förståelse för Azure Services
- Designa och arkitektera Azure-applikationer
- Arbetskunskaper om Azure Resource Manager
- Arbetskunskaper om JSON
- Praktisk kunskap om Helm
- Arbetskunskaper om createUiDefinition
- Arbetskunskaper om ARM-mallar (Azure Resource Manager)
Förutsättningar
Programmet måste vara Helm-diagrambaserat.
Helm-diagrammet bör inte innehålla
.tgzarkivfiler. Alla filer bör packas upp.Om du har flera diagram kan du inkludera andra Helm-charts som subcharts förutom huvud-Helm-chartet.
Alla bildreferenser och sammanfattad information måste ingå i diagrammet. Inga andra diagram eller bilder kan laddas ned under exekvering.
Du måste ha en aktiv publiceringsklient eller åtkomst till en publiceringsklient och ett Partnercenter-konto.
Du måste ha skapat ett Azure Container Registry (ACR) som tillhör den ovan nämnda aktiva publicerande klientorganisationen. Du laddar upp Cloud Native Application Bundle (CNAB) till det. Mer information finns i Skapa ett Azure Container Registry.
Installera den senaste versionen av Azure CLI.
Programmet måste kunna distribueras till Linux-miljön.
Bilderna måste vara fria från sårbarheter. Information om hur du anger krav för sårbarhetsgenomsökning finns i Felsöka containercertifiering. Mer information om hur du söker efter sårbarheter finns i Sårbarhetsbedömningar för Azure med Microsoft Defender – hantering av säkerhetsrisker.
Om du kör paketeringsverktyget manuellt måste Docker installeras på en lokal dator. Mer information finns i avsnittet WSL 2-serverdel i Docker-dokumentationen för Windows eller Linux. Detta stöds endast på Linux/Windows AMD64-datorer.
Begränsningar
- Container Marketplace stöder endast Linux-plattformsbaserade AMD64-avbildningar.
- Container Marketplace-erbjudandet stöder distribution till Managed AKS och Arc-Enabled Kubernetes . Ett enda erbjudande kan bara rikta sig mot en klustertyp, antingen Hanterad AKS eller Arc-aktiverad Kubernetes.
- Erbjudanden för Arc-aktiverade Kubernetes-kluster stöder endast fördefinierade faktureringsmodeller. Mer information om faktureringsmodeller finns i Planera ett Azure Container-erbjudande.
- Enskilda containrar stöds inte.
- Länkade Azure Resource Manager-mallar stöds inte.
Publiceringsöversikt
Det första steget för att publicera ditt Kubernetes-appbaserade containererbjudande på Azure Marketplace är att paketera ditt program som ett molnbaserat programpaket (CNAB). CNAB, som består av programmets artefakter, publiceras först till ditt privata Azure Container Registry (ACR) och skickas senare till en Offentlig ACR som ägs av Microsoft och används som den enda artefakt som du refererar till i Partnercenter.
Därifrån utförs sårbarhetsgenomsökning för att säkerställa att bilderna är säkra. Slutligen registreras Kubernetes-programmet som en tilläggstyp för ett AKS-kluster (Azure Kubernetes Service).
När ditt erbjudande har publicerats använder programmet klustertilläggen för AKS-funktionen för att hantera programmets livscykel i ett AKS-kluster.
Bevilja åtkomst till ditt Azure Container Registry
Som en del av publiceringsprocessen kopierar Microsoft din CNAB från din ACR till en ACR som ägs av Microsoft och är specifik för Azure Marketplace. Avbildningarna laddas upp till ett offentligt register som är tillgängligt för alla. Det här steget kräver att du ger Microsoft åtkomst till registret. ACR måste finnas i samma Microsoft Entra-klientorganisation som är länkad till ditt Partnercenter-konto.
Microsoft har en förstapartsapplikation som ansvarar för att hantera den här processen med en id av 32597670-3e15-4def-8851-614ff48c1efa. Börja med att skapa ett huvudnamn för tjänsten baserat på programmet:
Kommentar
Om ditt konto inte har behörighet att skapa ett tjänstehuvudnamn, returnerar az ad sp create ett felmeddelande som innehåller "Otillräckliga behörigheter för att slutföra åtgärden". Kontakta Microsoft Entra-administratören för att skapa ett tjänstehuvudkonto.
az login
Kontrollera om det redan finns ett tjänsthuvudkonto för programmet:
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
Om föregående kommando inte returnerar några resultat skapar du ett nytt huvudnamn för tjänsten:
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
Anteckna tjänstens principal-ID att använda i de följande stegen.
Hämta sedan registrets fullständiga ID:
az acr show --name <registry-name> --query "id" --output tsv
Dina utdata bör se ut ungefär så här:
...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
Skapa sedan en rolltilldelning för att ge tjänstprincipalen möjlighet att läsa från ditt register med hjälp av de värden som du fick tidigare:
För att tilldela Azure-roller måste du ha:
-
Microsoft.Authorization/roleAssignments/writebehörigheter, till exempel administratör för användaråtkomst eller ägare
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Registrera slutligen resursprovidern Microsoft.PartnerCenterIngestion för samma prenumeration som används för att skapa Azure Container Registry:
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Övervaka registreringen och bekräfta att den har slutförts innan du fortsätter:
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Samla in artefakter för att uppfylla kraven för paketformat
Varje CNAB består av följande artefakter:
- Helm-diagram
- CreateUiDefinition
- ARM-mall
- Manifestfil
Uppdatera Helm-diagrammet
Kontrollera att Helm-diagrammet följer följande regler:
Alla bildnamn och referenser parametriseras och representeras i
values.yamlsom global.azure.images-referenser. Uppdatera mallfilendeployment.yamlför Helm-diagrammet så att de pekar på dessa bilder. Detta säkerställer att avbildningsblocket kan uppdateras för att referera till ACR-avbildningar i Azure Marketplace.
Om du har flera diagram kan du inkludera andra helm charts som underdiagram utöver huvuddiagrammet. Alla associerade helm-diagrammens bildreferenser behöver uppdateras och bör peka på de bilder som ingår i huvuddiagrammets
values.yaml.När du refererar till bilder kan du använda taggar eller sammanfattningar. Det är dock viktigt att observera att bilderna är internt omtaggade för att peka på Microsoft-ägda Azure Container Registry (ACR). När du uppdaterar en tagg måste en ny version av CNAB skickas till Azure Marketplace. Detta gör att ändringarna kan återspeglas i kunddistributioner.
Tillgängliga faktureringsmodeller
Alla tillgängliga faktureringsmodeller finns i licensieringsalternativen för Azure Kubernetes-program.
Göra uppdateringar baserat på din faktureringsmodell
När du har granskat de tillgängliga faktureringsmodellerna väljer du en lämplig för ditt användningsfall och slutför följande steg:
Slutför följande steg för att lägga till identifierare i faktureringsmodellerna Per kärna, Per podd och Per nod :
Lägg till en etikett som faktureringsidentifierare
azure-extensions-usage-release-identifieri Pod-specifikationen i dina workload-yaml-filer.Om arbetsbelastningen specificeras som "Deployments" (distributioner), "Replicasets" (replikeringar), "Statefulsets" (tillståndsfulla set) eller "Daemonsets"-specifikationer, lägger du till denna etikett under .spec.template.metadata.labels.
Om arbetsbelastningen anges direkt som poddspecifikationer lägger du till den här etiketten under .metadata.labels.
För perCore-faktureringsmodell anger du CPU-begäran genom att
resources:requestsinkludera fältet i containerresursmanifestet. Det här steget krävs endast för fakturering per kärna-modell.
Vid distributionen ersätter funktionen för klustertillägg faktureringsidentifierarvärdet med tilläggets instansnamn.
Exempel som konfigurerats för att distribuera Azure Voting-appen finns i följande:
För faktureringsmodell för anpassade mätare lägger du till fälten nedan i helm-mallens values.yaml-fil
- clientId ska läggas till under global.azure.identity
- planId-nyckeln ska läggas till under global.azure.marketplace. planId
- resourceId bör läggas till under global.azure.extension.resrouceId
Vid distributionen ersätter funktionen klustertillägg dessa fält med lämpliga värden. Exempel finns i Azure Vote Custom Meters-baserade appen.
Verifiera Helm-diagrammet
Kontrollera att Helm-diagrammet är giltigt genom att testa att det kan installeras i ett lokalt kluster. Du kan också använda helm install --generate-name --dry-run --debug för att identifiera vissa fel vid generering av mallar.
Skapa och testa createUiDefinition
En createUiDefinition är en JSON-fil som definierar användargränssnittselementen för Azure Portal när programmet distribueras. Mer information finns i:
eller se ett exempel på en användargränssnittsdefinition som ber om indata för ett nytt eller befintligt klusterval och skickar parametrar till ditt program.
När du har skapat createUiDefinition.json-filen för ditt program måste du testa användarupplevelsen. För att förenkla testningen kopierar du filinnehållet till sandbox-miljön. Sandbox-miljön presenterar ditt användargränssnitt i den aktuella fullskärmsportalens upplevelse. Sandbox-miljön är det rekommenderade sättet att förhandsgranska användargränssnittet.
Skapa mallen Azure Resource Manager (ARM)
En ARM-mall definierar de Azure-resurser som ska distribueras. Som standard distribuerar du en klustertilläggsresurs för Azure Marketplace-programmet. Du kan också välja att distribuera ett AKS-kluster.
För närvarande tillåter vi endast följande resurstyper:
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Se till exempel den här ARM-exempelmallen som utformats för att ta resultat från exempeldefinitionen för användargränssnittet som länkats tidigare och skicka parametrar till ditt program.
Användarparameterflöde
Det är viktigt att förstå hur användarparametrar flödar genom artefakterna som du skapar och paketerar. I exemplet med Azure Voting App definieras parametrar ursprungligen när användargränssnittet skapas via en createUiDefinition.json-fil:
Parametrar exporteras via avsnittet outputs :
Därifrån skickas värdena till Azure Resource Manager-mallen och sprids till Helm-diagrammet under distributionen:
Slutligen skickas värdena till Helm-diagrammet genom values.yaml som det visas.
Kommentar
I det här exemplet extensionResourceName parametriseras och skickas även till klustertilläggsresursen. På samma sätt kan andra tilläggsegenskaper parametriseras, till exempel aktivera automatisk uppgradering för mindre versioner. Mer information om egenskaper för klustertillägg finns i valfria parametrar.
Skapa manifestfilen
Paketmanifestet är en yaml-fil som beskriver paketet och dess innehåll och talar om för paketeringsverktyget var de beroende artefakterna ska hittas.
Fälten som används i manifestet är följande:
| Name | Datatyp | beskrivning |
|---|---|---|
| programnamn | Sträng | Programnamn |
| förläggare | Sträng | Utgivarens namn |
| beskrivning | Sträng | Kort beskrivning av paketet |
| version | Sträng i #.#.#-format |
Versionssträng som beskriver programpaketversionen kanske eller kanske inte matchar versionen av binärfilerna inuti. |
| helmChart | Sträng | Lokal katalog där Helm-diagrammet finns i förhållande till detta manifest.yaml |
| clusterARMTemplate | Sträng | Lokal sökväg där en ARM-mall som beskriver ett AKS-kluster som uppfyller kraven i begränsningsfältet finns |
| uiDefinition | Sträng | Lokal sökväg där en JSON-fil som beskriver en Azure Portal Skapa-upplevelse finns |
| registryServer | Sträng | ACR där det slutliga CNAB-paketet ska push-överföras |
| tilläggsregistreringsparametrar | Samling | Specifikation för parametrarna för tilläggsregistrering. Inkludera minst defaultScope och som en parameter. |
| standardområde | Sträng | Standardomfånget för tilläggsinstallationen. Godkända värden är cluster eller namespace. Om cluster omfång anges tillåts endast en tilläggsinstans per kluster. Om namespace omfång har valts tillåts endast en instans per namnområde. Eftersom ett Kubernetes-kluster kan ha flera namnområden kan det finnas flera instanser av tillägget. |
| namnområde | Sträng | (Valfritt) Ange det namnområde som tillägget installeras i. Den här egenskapen krävs när defaultScope är inställd på cluster. Namnområdesnamnbegränsningar finns i Namnområden och DNS. |
| stödda klustertyper | Samling | (Valfritt) Ange vilka klustertyper som stöds av programmet. Tillåtna typer är – „managedClusters”, „connectedClusters”. "managedClusters" refererar till AKS-kluster (Azure Kubernetes Service). "connectedClusters" refererar till Azure Arc-aktiverade Kubernetes-kluster. Om supportedClusterTypes inte tillhandahålls stöds alla distributioner av "managedClusters" som standard. Om supportedClusterTypes tillhandahålls och en viss klustertyp på den högsta nivån inte tillhandahålls, behandlas alla distributioner och Kubernetes-versioner för den klustertypen som inte stöds. För varje klustertyp anger du en lista över en eller flera distributioner med följande egenskaper: -fördelning – distributionSupported – ej stöddaVersioner |
| fördelning | Lista | En matris med distributioner som motsvarar klustertypen. Ange namnet på specifika distributioner. Ange värdet till ["Alla"] för att ange att alla distributioner stöds. |
| distributionsstöd | Booleskt | Ett booleskt värde som representerar om de angivna distributionerna stöds. Om det är falskt orsakar det ett fel när du anger Ej stöddaVersioner. |
| ej stödda versioner | Lista | En lista över versioner för de angivna distributioner som inte stöds. Operatorer som stöds: - "=" Angiven version stöds inte. Till exempel "=1.2.12" – ">" Alla versioner som är större än den angivna versionen stöds inte. Till exempel ">1.1.13" – "<" Alla versioner som är mindre än den angivna versionen stöds inte. Till exempel "<1.3.14" - "..." Alla versioner i intervallet stöds inte. Till exempel "1.1.2...1.1.15" (inkluderar det högra värdet och exkluderar värdet på vänster sida) |
Ett exempel som konfigurerats för röstningsappen finns i följande exempel på manifestfil.
Strukturera ditt program
Placera filen createUiDefinition, ARM-mallen och manifestet bredvid programmets Helm-diagram.
Ett exempel på en korrekt strukturerad katalog finns i Azure Vote-exempel.
Ett exempel på röstningsprogrammet som stöder Azure Arc-aktiverade Kubernetes-kluster finns i Exempel endast för ConnectedCluster.
Mer information om hur du konfigurerar ett Azure Arc-aktiverat Kubernetes-kluster för validering av programmet finns i Snabbstart: Ansluta ett befintligt Kubernetes-kluster till Azure Arc.
Använda containerpaketeringsverktyget
När du har lagt till alla nödvändiga artefakter kör du paketeringsverktyget container-package-app för att verifiera artefakterna, skapa paketet och ladda upp paketet till Azure Container Registry.
Eftersom CNAB är ett nytt format och har en inlärningskurva har vi skapat en Docker-avbildning för container-package-app med bootstrapping-miljö och verktyg som krävs för att kunna köra paketeringsverktyget.
Du har två alternativ för att använda förpackningsverktyget. Du kan använda den manuellt eller integrera den i en distributionspipeline.
Kör förpackningsverktyget manuellt
Den senaste bilden av förpackningsverktyget kan hämtas från mcr.microsoft.com/container-package-app:latest.
Följande Docker-kommando hämtar den senaste paketeringsverktygsbilden och monterar även en katalog.
Förutsatt att ~\<path-to-content> är en katalog som innehåller innehållet som ska paketeras så monterar följande Docker-kommando ~/<path-to-content> till /data i containern. Se till att ersätta ~/<path-to-content> med din egen apps plats.
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
Kör följande kommandon i container-package-app containergränssnittet. Ersätt <registry-name> med namnet på din ACR:
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Det finns två alternativ för att autentisera ACR. Ett alternativ är genom att använda az login som tidigare, och det andra alternativet är via docker genom att köra docker login 'yourACRname'.azurecr.io. Ange ditt användarnamn och lösenord (användarnamnet ska vara ditt ACR-namn och lösenordet är den genererade nyckeln som anges i Azure Portal) och kör.
docker login <yourACRname.azurecr.io>
Kör sedan cpa verify för att iterera genom artefakterna och verifiera dem en i taget och åtgärda eventuella fel. Kör cpa buildbundle när du är redo att paketera och ladda upp CNAB till Azure Container Registry. Kommandot cpa buildbundle kör verifieringsprocessen, skapar paketet och laddar upp paketet till Azure Container Registry.
cpa verify
cpa buildbundle
Kommentar
Använd cpa buildbundle --force endast om du vill skriva över en befintlig tagg. Om du redan har bifogat detta CNAB till ett Azure Marketplace-erbjudande ökar du i stället versionen i manifestfilen.
Integrera i en Azure Pipeline
Ett exempel på hur du integrerar container-package-app i en Azure Pipeline finns i Azure Pipeline-exemplet
Ett exempel på hur du integrerar CNAB i Github Actions finns i Github-åtgärdsexemplet