Technische assets van Azure-containers voorbereiden voor een Kubernetes-app
Dit artikel bevat technische resources en aanbevelingen om u te helpen bij het maken van een containeraanbieding in Azure Marketplace voor een Kubernetes-toepassing.
Voor een uitgebreid voorbeeld van de technische assets die vereist zijn voor een Container-aanbieding op basis van een Kubernetes-app, raadpleegt u Voorbeelden van Azure Marketplace-containeraanbieding voor Kubernetes.
Fundamentele technische kennis
Het ontwerpen, bouwen en testen van deze assets kost tijd en vereist technische kennis van zowel het Azure-platform als de technologieën die worden gebruikt om de aanbieding te bouwen.
Naast uw oplossingsdomein moet uw technische team kennis hebben over de volgende Microsoft-technologieën:
- Basiskennis van Azure-services
- Azure-toepassingen ontwerpen en ontwerpen
- Werkende kennis van Azure Resource Manager
- Werkende kennis van JSON
- Werkkennis van Helm
- Werkende kennis van createUiDefinition
- Werkende kennis van ARM-sjablonen (Azure Resource Manager)
Vereisten
Uw toepassing moet op Helm-grafieken zijn gebaseerd.
De Helm-grafiek mag geen archiefbestanden bevatten
.tgz
. Alle bestanden moeten worden uitgepakt.Als u meerdere grafieken hebt, kunt u andere Helm-grafieken opnemen als subgrafieken naast de hoofd-Helm-grafiek.
Alle afbeeldingsverwijzingen en samenvattingsdetails moeten worden opgenomen in de grafiek. Er kunnen tijdens runtime geen andere grafieken of afbeeldingen worden gedownload.
U moet een actieve publicatietenant hebben of toegang hebben tot een publicerende tenant en een Partnercentrum-account.
U moet een Azure Container Registry (ACR) hebben gemaakt die deel uitmaakt van de actieve publicatietenant hierboven. U uploadt de Cloud Native Application Bundle (CNAB) daar naar. Zie Een Azure Container Registry maken voor meer informatie.
De nieuwste versie van de Azure CLI installeren
De toepassing moet kunnen worden geïmplementeerd in de Linux-omgeving.
De installatiekopieën moeten vrij zijn van beveiligingsproblemen. Zie Problemen met containercertificering oplossen voor hulp bij het opgeven van vereisten voor scannen op beveiligingsproblemen. Zie Evaluaties van beveiligingsproblemen voor Azure met Microsoft Defender Vulnerability Management voor meer informatie over het scannen op beveiligingsproblemen.
Als het pakketprogramma handmatig wordt uitgevoerd, moet Docker een lokale machine worden geïnstalleerd. Zie de sectie WSL 2-back-end in docker-documentatie voor Windows of Linux voor meer informatie. Dit wordt alleen ondersteund in Linux-/Windows AMD64-machines.
Beperkingen
- Container Marketplace ondersteunt alleen AMD64-installatiekopieën op basis van het Linux-platform.
- Container Marketplace biedt ondersteuning voor implementatie naar Beheerde AKS en Kubernetes met Arc. Eén aanbieding kan zich slechts richten op één clustertype: Beheerde AKS of Kubernetes met Arc.
- Aanbiedingen voor Kubernetes-clusters met Arc ondersteunen alleen vooraf gedefinieerde factureringsmodellen. Zie Een Azure Container-aanbieding plannen voor meer informatie over factureringsmodellen.
- Afzonderlijke containers worden niet ondersteund.
- Gekoppelde Azure Resource Manager-sjablonen worden niet ondersteund.
Publicatieoverzicht
De eerste stap voor het publiceren van uw Kubernetes-containeraanbieding op de Azure Marketplace is het verpakken van uw toepassing als een Cloud Native Application Bundle (CNAB). De CNAB, bestaande uit de artefacten van uw toepassing, wordt eerst gepubliceerd naar uw persoonlijke Azure Container Registry (ACR) en later gepusht naar een openbare ACR van Microsoft en wordt gebruikt als het enige artefact waarnaar u verwijst in partnercentrum.
Van daaruit wordt scannen op beveiligingsproblemen uitgevoerd om ervoor te zorgen dat afbeeldingen veilig zijn. Ten slotte wordt de Kubernetes-toepassing geregistreerd als een extensietype voor een AKS-cluster (Azure Kubernetes Service).
Zodra uw aanbieding is gepubliceerd, maakt uw toepassing gebruik van de clusterextensies voor de AKS-functie om de levenscyclus van uw toepassing binnen een AKS-cluster te beheren.
Toegang verlenen tot uw Azure Container Registry
Als onderdeel van het publicatieproces kopieert Microsoft uw CNAB van uw ACR naar een azure Marketplace-specifieke ACR die eigendom is van Microsoft. De installatiekopieën worden geüpload naar een openbaar register dat toegankelijk is voor iedereen. Voor deze stap moet u Microsoft toegang verlenen tot uw register. De ACR moet zich in dezelfde Microsoft Entra-tenant bevinden die is gekoppeld aan uw Partnercentrum-account.
Microsoft heeft een eigen toepassing die verantwoordelijk is voor het afhandelen van dit proces met een id
van 32597670-3e15-4def-8851-614ff48c1efa
. Maak eerst een service-principal op basis van de toepassing:
Notitie
Als uw account niet gemachtigd is om een service-principal te maken, az ad sp create
wordt een foutbericht geretourneerd met onvoldoende bevoegdheden om de bewerking te voltooien. Neem contact op met uw Microsoft Entra-beheerder om een service-principal te maken.
az login
Controleer of er al een service-principal bestaat voor de toepassing:
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
Als de vorige opdracht geen resultaten retourneert, maakt u een nieuwe service-principal:
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
Noteer de id van de service-principal die u in de volgende stappen wilt gebruiken.
Haal vervolgens de volledige id van uw register op:
az acr show --name <registry-name> --query "id" --output tsv
Uw uitvoer moet er ongeveer als volgt uitzien:
...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
Maak vervolgens een roltoewijzing om de service-principal de mogelijkheid te geven om uit het register te halen met behulp van de waarden die u eerder hebt verkregen:
Als u Azure-rollen wilt toewijzen, hebt u het volgende nodig:
Microsoft.Authorization/roleAssignments/write
machtigingen, zoals beheerder van gebruikerstoegang of eigenaar
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Registreer ten slotte de Microsoft.PartnerCenterIngestion
resourceprovider voor hetzelfde abonnement dat is gebruikt voor het maken van Azure Container Registry:
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Controleer de registratie en bevestig dat deze is voltooid voordat u doorgaat:
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Artefacten verzamelen om te voldoen aan de vereisten voor pakketindeling
Elke CNAB bestaat uit de volgende artefacten:
- Helm-grafiek
- CreateUiDefinition
- ARM-sjabloon
- Manifestbestand
De Helm-grafiek bijwerken
Zorg ervoor dat de Helm-grafiek voldoet aan de volgende regels:
Alle afbeeldingsnamen en verwijzingen worden geparameteriseerd en weergegeven als
values.yaml
global.azure.images-verwijzingen. Werk uw Helm-grafieksjabloonbestanddeployment.yaml
bij om deze afbeeldingen te laten verwijzen. Dit zorgt ervoor dat het afbeeldingsblok kan worden bijgewerkt om te verwijzen naar de ACR-installatiekopieën van Azure Marketplace.Als u meerdere grafieken hebt, kunt u andere Helm-grafieken opnemen als subgrafieken naast de hoofd-Helm-grafiek. Alle afhankelijke helm-grafieken moeten worden bijgewerkt en moeten verwijzen naar de afbeeldingen die zijn opgenomen in de hoofdgrafiek
values.yaml
.Wanneer u naar afbeeldingen verwijst, kunt u tags of samenvattingen gebruiken. Het is echter belangrijk om te weten dat de installatiekopieën intern opnieuw worden gemarkeerd om te verwijzen naar het Azure Container Registry (ACR) dat eigendom is van Microsoft. Wanneer u een tag bijwerkt, moet een nieuwe versie van cnab worden verzonden naar Azure Marketplace. Dit is zodat de wijzigingen kunnen worden doorgevoerd in klantimplementaties.
Beschikbare factureringsmodellen
Raadpleeg de licentieopties voor Azure Kubernetes-toepassingen voor alle beschikbare factureringsmodellen.
Updates uitvoeren op basis van uw factureringsmodel
Nadat u de beschikbare factureringsmodellen hebt bekeken, selecteert u er een die geschikt is voor uw use-case en voert u de volgende stappen uit:
Voer de volgende stappen uit om de id toe te voegen in de factureringsmodellen per per kern, per pod, factureringsmodellen per knooppunt :
Voeg een label
azure-extensions-usage-release-identifier
voor de facturerings-id toe aan de podspecificatie in uw yaml-bestanden van uw workload .Als de workload is opgegeven als Implementaties of Replicasets of Statefulsets of Daemonsets specificaties, voegt u dit label toe onder .spec.template.metadata.labels.
Als de workload rechtstreeks als podspecificaties is opgegeven, voegt u dit label toe onder .metadata.labels.
Geef voor het factureringsmodel perCore CPU-aanvraag op door het
resources:requests
veld in het containerresourcemanifest op te geven. Deze stap is alleen vereist voor het perCore-factureringsmodel .
Tijdens de implementatie vervangt de functie clusterextensies de waarde van de facturerings-id door de naam van het extensie-exemplaar.
Voor voorbeelden die zijn geconfigureerd om de Azure Voting-app te implementeren, raadpleegt u het volgende:
- Voorbeeld van implementatiebestand.
- Voorbeeld van het waardenbestand.
Voor het factureringsmodel voor aangepaste meters voegt u de onderstaande velden toe in het bestand values.yaml van uw Helm-sjabloon
- clientId moet worden toegevoegd onder global.azure.identity
- planId-sleutel moet worden toegevoegd onder global.azure.marketplace. planId
- resourceId moet worden toegevoegd onder global.azure.extension.resrouceId
Tijdens de implementatie vervangt de functie clusterextensies deze velden door de juiste waarden. Zie de azure Vote Custom Meters-app voor voorbeelden.
De Helm-grafiek valideren
Om ervoor te zorgen dat de Helm-grafiek geldig is, test u of deze kan worden geïnstalleerd op een lokaal cluster. U kunt ook helm install --generate-name --dry-run --debug
bepaalde fouten bij het genereren van sjablonen detecteren.
Create and test the createUiDefinition
Een createUiDefinition is een JSON-bestand dat de elementen van de gebruikersinterface voor Azure Portal definieert bij het implementeren van de toepassing. Zie voor meer informatie:
of bekijk een voorbeeld van een UI-definitie die vraagt om invoergegevens voor een nieuwe of bestaande clusterkeuze en parameters doorgeeft aan uw toepassing.
Nadat u het createUiDefinition.json-bestand voor uw toepassing hebt gemaakt, moet u de gebruikerservaring testen. Kopieer de bestandsinhoud naar de sandbox-omgeving om het testen te vereenvoudigen. De sandbox presenteert uw gebruikersinterface in de huidige portal-ervaring op volledig scherm. De sandbox is de aanbevolen manier om een voorbeeld van de gebruikersinterface te bekijken.
De ARM-sjabloon (Azure Resource Manager) maken
Een ARM-sjabloon definieert de Azure-resources die moeten worden geïmplementeerd. Standaard implementeert u een clusterextensieresource voor de Azure Marketplace-toepassing. U kunt er desgewenst voor kiezen om een AKS-cluster te implementeren.
Momenteel zijn alleen de volgende resourcetypen toegestaan:
Microsoft.ContainerService/managedClusters
Microsoft.KubernetesConfiguration/extensions
Zie bijvoorbeeld deze ARM-voorbeeldsjabloon die is ontworpen om resultaten te nemen van de eerder gekoppelde voorbeeld-UI-definitie en parameters door te geven aan uw toepassing.
Gebruikersparameterstroom
Het is belangrijk om te begrijpen hoe gebruikersparameters stromen in de artefacten die u maakt en verpakt. In het voorbeeld van de Azure Voting-app worden parameters in eerste instantie gedefinieerd bij het maken van de gebruikersinterface via een createUiDefinition.json-bestand:
Parameters worden geëxporteerd via de outputs
sectie:
Van daaruit worden de waarden doorgegeven aan de Azure Resource Manager-sjabloon en tijdens de implementatie doorgegeven aan de Helm-grafiek:
Ten slotte worden de waarden doorgegeven aan de Helm-grafiek values.yaml
, zoals wordt weergegeven.
Notitie
In dit voorbeeld extensionResourceName
wordt ook geparameteriseerd en doorgegeven aan de clusterextensieresource. Op dezelfde manier kunnen andere extensie-eigenschappen worden geparameteriseerd, zoals het inschakelen van automatische upgrade voor secundaire versies. Zie optionele parameters voor meer informatie over eigenschappen van clusteruitbreidingen.
Het manifestbestand maken
Het pakketmanifest is een yaml-bestand dat het pakket en de inhoud ervan beschrijft en het pakketprogramma vertelt waar de afhankelijke artefacten moeten worden gevonden.
De velden die in het manifest worden gebruikt, zijn als volgt:
Naam | Gegevenstype | Beschrijving |
---|---|---|
applicationName | String | Naam van de toepassing |
uitgever | String | Naam van de uitgever |
beschrijving | String | Korte beschrijving van het pakket |
version | Tekenreeks in #.#.# notatie |
Versietekenreeks die de versie van het toepassingspakket beschrijft, komt mogelijk wel of niet overeen met de versie van de binaire bestanden in. |
helmChart | String | Lokale map waar de Helm-grafiek kan worden gevonden ten opzichte van dit manifest.yaml |
clusterARMTemplate | String | Lokaal pad waar een ARM-sjabloon die een AKS-cluster beschrijft dat voldoet aan de vereisten in het veld Beperkingen, kan worden gevonden |
uiDefinition | String | Lokaal pad waar een JSON-bestand dat een Azure Portal-ervaring maken beschrijft, kan worden gevonden |
registryServer | String | De ACR waar de uiteindelijke CNAB-bundel moet worden gepusht |
extensionRegistrationParameters | Verzameling | Specificatie voor de extensieregistratieparameters. Neem ten minste defaultScope en als parameter op. |
defaultScope | String | Het standaardbereik voor de installatie van de extensie. Geaccepteerde waarden zijn cluster of namespace . Als cluster het bereik is ingesteld, is slechts één extensie-exemplaar per cluster toegestaan. Als namespace het bereik is geselecteerd, is slechts één exemplaar per naamruimte toegestaan. Omdat een Kubernetes-cluster meerdere naamruimten kan hebben, kunnen er meerdere extensie-exemplaren bestaan. |
naamruimte | String | (Optioneel) Geef de naamruimte op waarin de extensie wordt geïnstalleerd. Deze eigenschap is vereist wanneer defaultScope deze is ingesteld op cluster . Zie Naamruimten en DNS voor naamruimten voor naamruimten. |
supportedClusterTypes | Verzameling | (Optioneel) Geef de clustertypen op die door de toepassing worden ondersteund. Toegestane typen zijn: 'managedClusters', 'connectedClusters'. ManagedClusters verwijst naar AKS-clusters (Azure Kubernetes Service). ConnectedClusters verwijst naar Kubernetes-clusters met Azure Arc. Als supportedClusterTypes niet is opgegeven, worden alle distributies van 'managedClusters' standaard ondersteund. Als supportedClusterTypes wordt opgegeven en er geen clustertype op het hoogste niveau wordt opgegeven, worden alle distributies en Kubernetes-versies voor dat clustertype behandeld als niet-ondersteund. Geef voor elk clustertype een lijst op met een of meer distributies met de volgende eigenschappen: -distributie - distributionSupported - niet-ondersteundeVersions |
distributie | List | Een matrix met distributies die overeenkomen met het clustertype. Geef de naam van specifieke distributies op. Stel de waarde in op ["Alle"] om aan te geven dat alle distributies worden ondersteund. |
distributionSupported | Booleaanse waarde | Een Booleaanse waarde die aangeeft of de opgegeven distributies worden ondersteund. Als dit onwaar is, veroorzaakt het opgegeven UnsupportedVersions een fout. |
niet-ondersteundeVersions | List | Een lijst met versies voor de opgegeven distributies die niet worden ondersteund. Ondersteunde operators: - "=" De opgegeven versie wordt niet ondersteund. Bijvoorbeeld "=1.2.12" - Alle> versies die groter zijn dan de opgegeven versie, worden niet ondersteund. Bijvoorbeeld '>1.1.13' - Alle< versies die kleiner zijn dan de opgegeven versie, worden niet ondersteund. Bijvoorbeeld '<1.3.14' - "..." Alle versies in het bereik worden niet ondersteund. Bijvoorbeeld '1.1.2...1.1.15' (inclusief de waarde aan de rechterkant en sluit de waarde aan de linkerkant uit) |
Zie het volgende manifestbestandsvoorbeeld voor een voorbeeld dat is geconfigureerd voor de stem-app.
Uw toepassing structuren
Plaats het bestand createUiDefinition, ARM-sjabloon en manifestbestand naast de Helm-grafiek van uw toepassing.
Zie het Voorbeeld van Azure Vote voor een voorbeeld van een correct gestructureerde map.
Voor een voorbeeld van de stemtoepassing die Kubernetes-clusters met Azure Arc ondersteunt, raadpleegt u het voorbeeld Alleen-verbonden clusters.
Het hulpprogramma voor containerverpakkingen gebruiken
Nadat u alle vereiste artefacten hebt toegevoegd, voert u het pakketprogramma container-package-app
uit om de artefacten te valideren, het pakket te bouwen en het pakket te uploaden naar Azure Container Registry.
Omdat CNABs een nieuwe indeling hebben en een leercurve hebben, hebben we een Docker-installatiekopie gemaakt voor container-package-app
de bootstrapping-omgeving en hulpprogramma's die nodig zijn om het verpakkingshulpprogramma uit te voeren.
U hebt twee opties om het verpakkingshulpmiddel te gebruiken. U kunt deze handmatig gebruiken of integreren in een implementatiepijplijn.
Voer het verpakkingshulpprogramma handmatig uit
De nieuwste afbeelding van het verpakkingshulpmiddel kan worden opgehaald.mcr.microsoft.com/container-package-app:latest
Met de volgende Docker-opdracht wordt de meest recente installatiekopie van het verpakkingshulpprogramma opgehaald en wordt ook een map gekoppeld.
Ervan uitgaande dat ~\<path-to-content>
het een map is met de inhoud die moet worden verpakt, wordt ~/<path-to-content>
de volgende Docker-opdracht gekoppeld aan /data
de container. Zorg ervoor dat u de locatie van uw eigen app vervangt ~/<path-to-content>
.
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
Voer de volgende opdrachten uit in de container-package-app
containershell. Zorg ervoor dat u vervangt door <registry-name>
de naam van uw ACR:
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Er zijn twee opties om de ACR te verifiëren. Een optie is met behulp van az login
zoals eerder weergegeven, en de tweede optie is via docker door uit te voeren docker login 'yourACRname'.azurecr.io
. Voer uw gebruikersnaam en wachtwoord in (gebruikersnaam moet uw ACR-naam zijn en het wachtwoord is de gegenereerde sleutel die is opgegeven in Azure Portal) en voer deze uit.
docker login <yourACRname.azurecr.io>
Voer vervolgens uit cpa verify
om de artefacten te herhalen en deze één voor één te valideren en eventuele fouten op te pakken. Voer cpa buildbundle
uit wanneer u klaar bent om de CNAB te verpakken en te uploaden naar uw Azure Container Registry. De cpa buildbundle
opdracht voert het verificatieproces uit, bouwt het pakket en uploadt het pakket naar uw Azure Container Registry.
cpa verify
cpa buildbundle
Notitie
Gebruik cpa buildbundle --force
alleen als u een bestaande tag wilt overschrijven. Als u deze CNAB al hebt gekoppeld aan een Azure Marketplace-aanbieding, moet u in plaats daarvan de versie in het manifestbestand verhogen.
Integreren in een Azure-pijplijn
Probleemoplossing
- Help voor het oplossen van problemen met pakketten
- Help voor het oplossen van problemen met publiceren