Technische Ressourcen zur Vorbereitung von Azure-Containern für eine Kubernetes-App
Dieser Artikel enthält technische Ressourcen und Empfehlungen, die Ihnen helfen, ein Containerangebot im Azure Marketplace für eine Kubernetes-Anwendung zu erstellen.
Ein umfassendes Beispiel der technische Ressourcen, die für ein App-basiertes Kubernetes-Containerangebot erforderlich sind, finden Sie auf der Seite mit den Beispielen für Container-Angebote für Kubernetes im Azure Marketplace.
Grundlegende technische Kenntnisse
Das Entwerfen, Erstellen und Testen dieser Ressourcen dauert lange, und es sind technische Kenntnisse in Bezug auf die Azure-Plattform und die Technologien erforderlich, die verwendet werden, um das Angebot zu erstellen.
Zusätzlich zur Vertrautheit mit Ihrer Lösungsdomäne sollte sich Ihr Engineeringteam mit den folgenden Microsoft-Technologien auskennen:
- Grundkenntnisse in Bezug auf Azure-Dienste
- Entwerfen und Erstellen der Architektur für Azure-Anwendungen
- Erweiterte Grundkenntnisse in Bezug auf Azure Resource Manager
- Fundierte Kenntnisse zu JSON
- Fundierte Kenntnisse zu Helm.
- Fundierte Kenntnisse zu createUiDefinition
- Fundierte Kenntnisse zu ARM-Vorlagen (Azure Resource Manager).
Voraussetzungen
Ihre Anwendung muss auf einem Helm-Chart basieren.
Wenn Sie über mehrere Diagramme verfügen, können Sie andere Steuerdiagramme als Unterdiagramme neben dem Haupt-Steuerdiagramm einschließen.
Das Chart muss alle Imageverweise und Digestdetails enthalten. Zur Laufzeit können keine anderen Diagramme oder Bilder heruntergeladen werden.
Sie benötigen einen aktiven Mandanten für die Veröffentlichung oder Zugriff auf einen Veröffentlichungsmandanten und ein Partner Center-Konto.
Sie müssen eine Azure Container Registry (ACR) erstellt haben, die zum aktiven Veröffentlichungsmandanten oben gehört. Sie laden das Cloud Native Application Bundle (CNAB) dazu hoch. Weitere Informationen finden Sie unter Erstellen einer Azure-Containerregistrierung.
Installieren Sie die aktuelle Version der Azure CLI.
Die Anwendung muss in einer Linux-Umgebung bereitgestellt werden können.
Die Bilder müssen frei von Sicherheitsrisiken sein. Informationen zum Überprüfen auf Sicherheitsrisiken finden Sie unter Sicherheitsrisikobewertungen für Azure mit Microsoft Defender Vulnerability Management.
Wenn Das Pakettool manuell ausgeführt wird, muss Docker auf einem lokalen Computer installiert sein. Weitere Informationen finden Sie im WSL 2-Back-End-Abschnitt in der Docker-Dokumentation für Windows oder Linux. Dies wird nur auf Linux/Windows AMD64-Computern unterstützt.
Begrenzungen
- Der Container-Marketplace unterstützt ausschließlich Linux-basierte AMD64-Images.
- Nur verwalteter AKS-Dienst.
- Einzelne Container werden nicht unterstützt.
- Verknüpfte Azure Resource Manager-Vorlagen werden nicht unterstützt.
Übersicht über die Veröffentlichung
Der erste Schritt zum Veröffentlichen Ihres App-basierten Kubernetes-Containerangebots im Azure Marketplace besteht darin, Ihre Anwendung als Cloud Native Application Bundle (CNAB) zu packen. Das CNAB, bestehend aus den Artefakten Ihrer Anwendung, wird zuerst in Ihrer privaten Azure Container Registry (ACR) veröffentlicht und später an einen öffentlichen ACR von Microsoft übertragen und wird als einzelnes Artefakt verwendet, auf das Sie im Partner Center verweisen.
Von dort aus wird eine Überprüfung auf Sicherheitsrisiken durchgeführt, um sicherzustellen, dass Images sicher sind. Schließlich wird die Kubernetes-Anwendung als Erweiterungstyp für einen Azure Kubernetes Service-Cluster (AKS) registriert.
Sobald Ihr Angebot veröffentlicht wurde, nutzt Ihre Anwendung die Clustererweiterungen für das AKS-Feature , um Ihren Anwendungslebenszyklus innerhalb eines AKS-Clusters zu verwalten.
Gewähren von Zugriff auf Ihre Azure Container Registry-Instanz
Im Rahmen des Veröffentlichungsprozesses kopiert Microsoft Ihre CNAB von Ihrem ACR in ein microsofteigenes Azure Marketplace-spezifisches ACR. Die Bilder werden in eine öffentliche Registrierung hochgeladen, die für alle zugänglich ist. Für diesen Schritt müssen Sie Microsoft Zugriff auf Ihre Registrierung erteilen. Die ACR muss sich in demselben Microsoft Entra-Mandanten befinden, der mit Ihrem Partner Center-Konto verknüpft ist.
Microsoft verfügt über eine Erstanbieteranwendung, die für die Verarbeitung dieses Prozesses mit einer id von 32597670-3e15-4def-8851-614ff48c1efa. Erstellen Sie zunächst einen Dienstprinzipal basierend auf der Anwendung:
Hinweis
Wenn Ihr Konto nicht über die Berechtigung zum Erstellen eines Dienstprinzipals verfügt, gibt az ad sp create eine Fehlermeldung mit dem Hinweis „Nicht genügend Berechtigungen zum Abschließen des Vorgangs“ zurück. Wenden Sie sich an Ihre*n Microsoft Entra-Administrator*in, um einen Dienstprinzipal zu erstellen.
az login
Überprüfen Sie, ob für die Anwendung bereits ein Dienstprinzipal vorhanden ist:
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
Wenn der vorherige Befehl keine Ergebnisse zurückgibt, erstellen Sie einen neuen Dienstprinzipal:
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
Notieren Sie sich die ID des Dienstprinzipals, die in den folgenden Schritten verwendet werden soll.
Rufen Sie als Nächstes die vollständige ID Ihrer Registrierung ab:
az acr show --name <registry-name> --query "id" --output tsv
Ihre Ausgabe sollte in etwa wie folgt aussehen:
...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
Erstellen Sie dann eine Rollenzuweisung, mit der der Dienstprinzipal mithilfe der Werte, die Sie zuvor abgerufen haben, Daten aus Ihrer Registrierung pullen kann:
Zum Zuweisen von Azure-Rollen müssen Sie über Folgendes verfügen:
Microsoft.Authorization/roleAssignments/write-Berechtigungen, z. B. Benutzerzugriffsadministrator oder Besitzer
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Registrieren Sie schließlich den Microsoft.PartnerCenterIngestion-Ressourcenanbieter im selben Abonnement, das zum Erstellen der Azure Container Registry-Instanz verwendet wurde:
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Überwachen Sie die Registrierung, und überprüfen Sie, ob sie abgeschlossen wurde, bevor Sie fortfahren:
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Sammeln von Artefakten, um die Paketformatanforderungen zu erfüllen
Jedes CNAB besteht aus den folgenden Artefakten:
- Helm-Chart
- CreateUiDefinition
- ARM-Vorlage
- Manifestdatei
Aktualisieren des Helm-Charts
Stellen Sie sicher, dass das Helm-Chart den folgenden Regeln entspricht:
Alle Imagenamen und Verweise sind parametrisiert und werden in
values.yamlals global.azure.images-Verweise dargestellt. Aktualisieren Sie ihre Helm-Diagrammvorlagendateideployment.yamlso, dass sie auf diese Bilder verweist. Dadurch wird sichergestellt, dass der Imageblock aktualisiert werden kann, um auf die ACR-Bilder von Azure Marketplace zu verweisen.
Wenn Sie über mehrere Diagramme verfügen, können Sie andere Steuerdiagramme als Unterdiagramme neben dem Haupt-Steuerdiagramm einschließen. Aktualisieren Sie dann alle abhängigen Bildverweise so, dass sie auf die Bilder verweisen, die im Hauptdiagramm
values.yamlenthalten sind.Beim Verweisen auf Bilder können Sie Tags oder Digests verwenden. Es ist jedoch wichtig zu beachten, dass die Bilder intern zurückgeschlüsselt werden, um auf die Microsoft-besitzer Azure Container Registry (ACR) zu verweisen. Wenn Sie ein Tag aktualisieren, muss eine neue Version des CNAB an den Azure Marketplace übermittelt werden. Dies ist so, dass die Änderungen in Kundenbereitstellungen widerspiegelt werden können.
Verfügbare Abrechnungsmodelle
Alle verfügbaren Abrechnungsmodelle finden Sie unter den Lizenzierungsoptionen für Azure Kubernetes-Anwendungen.
Vornehmen von Updates basierend auf Ihrem Abrechnungsmodell
Nachdem Sie die verfügbaren Abrechnungsmodelle überprüft haben, wählen Sie einen geeigneten Für Ihren Anwendungsfall aus, und führen Sie die folgenden Schritte aus:
Führen Sie die folgenden Schritte aus, um den Bezeichner in den Abrechnungsmodellen "Pro Kern", "Pro Pod", "Pro Knoten " hinzuzufügen:
Fügen Sie der Pod-Spezifikation in Ihren Workload-Yaml-Dateien eine Bezeichnung für die Abrechnungs-ID
azure-extensions-usage-release-identifierhinzu.Wenn die Workload als Bereitstellungen oder Replicasets oder Statefulsets- oder Daemonsets-Spezifikationen angegeben ist, fügen Sie diese Bezeichnung unter .spec.template.metadata.labels hinzu.
Wenn die Workload direkt als Pod-Spezifikationen angegeben wird, fügen Sie diese Bezeichnung unter ".metadata.labels" hinzu.
Geben Sie für das perCore-Abrechnungsmodell DIE CPU-Anforderung an, indem Sie das
resources:requestsFeld in das Containerressourcenmanifest einschließen. Dieser Schritt ist nur für das perCore-Abrechnungsmodell erforderlich.
Zur Bereitstellungszeit ersetzt das Clustererweiterungsfeature den Abrechnungsbezeichnerwert durch den Namen der Erweiterungsinstanz.
Beispiele, die für die Bereitstellung der Azure-Voting-App konfiguriert sind, finden Sie hier:
Fügen Sie für das Abrechnungsmodell für benutzerdefinierte Zähler die unten aufgeführten Felder in der Datei "values.yaml" Ihrer Helmvorlage hinzu.
- "clientId" sollte unter "global.azure.identity" hinzugefügt werden.
- planId-Schlüssel sollte unter "global.azure.marketplace" hinzugefügt werden. planId
- resourceId sollte unter "global.azure.extension.resrouceId" hinzugefügt werden.
Zur Bereitstellungszeit ersetzt das Clustererweiterungsfeature diese Felder durch die entsprechenden Werte. Beispiele finden Sie in der benutzerdefinierten Azure-Meter-App.
Testparameterdatei erstellen
Eine Testparameterdatei ist ein JSON-Code, der in Verbindung mit einer ARM-Vorlage zum Bereitstellen einer Ressource in Azure verwendet wird. Für Anwendungen oder Erweiterungen, die für verwaltete Cluster (AKS) bereitgestellt werden können, ist die Parameterdatei für die Bereitstellungsüberprüfung anzugeben. Die Testparameterdatei sollte Werte enthalten, die eine erfolgreiche Testbereitstellung ermöglichen würden.
Hinweis
Nicht alle Parameter müssen in die Parameterdatei eingeschlossen werden, nur Parameter, die keinen Standardwert aufweisen. Anleitungen finden Sie hier.
Hier ist eine Beispieltestparameterdatei:
Nachdem die Testparameterdatei erstellt wurde, fügen Sie sie ihrer Manifestdatei hinzu:
Hinweis
In Situationen, in denen eine Testparameterdatei nicht auf Ihre Anwendung anwendbar wäre (z. B. erfordert die Anwendung geheime Schlüssel für die Bereitstellung wie einen API-Schlüssel oder eine Anwendung, die auf verbundenen Clustern bereitgestellt wird), wird ein Flag für die Skipdeployment-Bereitstellung bereitgestellt, damit Sie die Bereitstellungstests überspringen können.
Überprüfen des Helm-Charts
Testen Sie, ob das Helm-Chart auf einem lokalen Computer installiert werden kann. So können Sie sicherstellen, dass es gültig ist. Sie können auch helm install --generate-name --dry-run --debug verwenden, um bestimmte Fehler bei der Vorlagengenerierung zu ermitteln.
Erstellen und Testen der Datei „createUiDefinition“
„createUiDefinition“ ist eine JSON-Datei zur Definition der Benutzeroberflächenelemente für das Azure-Portal bei der Bereitstellung der Anwendung. Weitere Informationen finden Sie unter:
- CreateUiDefinition.json für Azure
- oder sehen Sie sich ein Beispiel für eine UI-Definition an, die Eingabedaten für eine neue oder vorhandene Clusterauswahl anfragt und Parameter an Ihre Anwendung übergibt.
Nachdem die Datei „createUiDefinition.json“ für Ihre Anwendung erstellt wurde, muss das Benutzererlebnis getestet werden. Um das Testen zu vereinfachen, kopieren Sie Den Dateiinhalt in die Sandkastenumgebung. Der Sandkasten stellt Ihre Benutzeroberfläche in der aktuellen Vollbildportalumgebung dar. Die Sandbox ist die empfohlene Methode, um eine Vorschau der Benutzeroberfläche anzuzeigen.
Erstellen der ARM-Vorlage (Azure Resource Manager)
In einer ARM-Vorlage werden die Azure-Ressourcen definiert, die bereitgestellt werden sollen. Standardmäßig stellen Sie eine Clustererweiterungsressource für die Azure Marketplace-Anwendung bereit. Optional können Sie einen AKS-Cluster bereitstellen.
Derzeit sind nur die folgenden Ressourcentypen zulässig:
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Sehen Sie sich z. B. diese ARM-Beispielvorlage an, die Ergebnisse aus der zuvor verknüpften Beispiel-UI-Definition verwendet und Parameter an Ihre Anwendung übergeben soll.
Benutzerparameterflow
Es ist wichtig zu verstehen, wie Benutzerparameter durch die Artefakte fließen, die Sie erstellen und verpacken. Im Azure Voting App-Beispiel werden beim Erstellen der Benutzeroberfläche zunächst Parameter über eine createUiDefinition.json-Datei definiert:
Parameter werden über den outputs Abschnitt exportiert:
Von dort aus werden die Werte an die Azure Resource Manager-Vorlage übergeben und während der Bereitstellung an das Helm-Diagramm weitergegeben:
Schließlich werden die Werte wie dargestellt in das Helmdiagramm values.yaml übergeben.
Hinweis
In diesem Beispiel wird extensionResourceName auch parametrisiert und an die Clustererweiterungsressource übergeben. Auf ähnliche Weise können andere Erweiterungseigenschaften parametrisiert werden, z. B. das Aktivieren des automatischen Upgrades für Nebenversionen. Weitere Informationen zu Clustererweiterungseigenschaften finden Sie unter Optionale Parameter.
Paketlistendatei erstellen
Das Paketmanifest ist eine YAML-Datei zur Beschreibung des Pakets und seiner Inhalte. Anhand dieser Informationen weiß das Paketerstellungstool, wo sich die abhängigen Artefakte befinden.
Im Manifest werden folgende Felder verwendet:
| Name | Datentyp | Beschreibung |
|---|---|---|
| applicationName | String | Name der Anwendung |
| Herausgeber | String | Name des Herausgebers |
| Beschreibung | String | Kurze Beschreibung des Pakets |
| version | Zeichenfolge im #.#.#-Format |
Versionszeichenfolge, die die Anwendungspaketversion beschreibt, stimmt möglicherweise oder nicht mit der Version der Binärdateien überein. |
| helmChart | String | Lokales Verzeichnis, in dem sich das Helm-Chart relativ zu dieser manifest.yaml-Datei befindet |
| clusterARMTemplate | String | Lokaler Pfad zu einer ARM-Vorlage, die einen AKS-Cluster beschreibt, der die Anforderungen im Einschränkungsfeld erfüllt |
| uiDefinition | String | Lokaler Pfad zu einer JSON-Datei, die eine Erstellungsoberfläche im Azure-Portal beschreibt |
| registryServer | String | Die ACR-Instanz, in die das finale CNAB gepusht werden soll |
| extensionRegistrationParameters | Sammlung | Spezifikation für die Erweiterungsregistrierungsparameter. Schließen Sie mindestens defaultScope als Parameter ein. |
| defaultScope | String | Der Standardbereich für die Erweiterungsinstallation. Zulässige Werte sind cluster und namespace. Wenn der cluster-Bereich festgelegt ist, ist pro Cluster nur eine Erweiterungsinstanz zulässig. Wenn der namespace-Bereich ausgewählt ist, ist pro Namespace nur eine Instanz zulässig. Da ein Kubernetes-Cluster über mehrere Namespaces verfügen kann, können mehrere Erweiterungsinstanzen vorhanden sein. |
| namespace | String | (Optional) Geben Sie den Namespace an, in dem die Erweiterung installiert wird. Diese Eigenschaft ist erforderlich, wenn defaultScope auf cluster festgelegt ist. Informationen zu Einschränkungen bei der Namespacebenennung finden Sie unter Namespaces und DNS. |
| supportedClusterTypes | Sammlung | (Optional) Geben Sie die von der Anwendung unterstützten Clustertypen an. Zulässige Typen sind – "managedClusters", "connectedClusters". "managedClusters" bezieht sich auf Azure Kubernetes Service (AKS)-Cluster. "connectedClusters" bezieht sich auf Azure Arc-fähige Kubernetes-Cluster. Wenn supportedClusterTypes nicht bereitgestellt wird, werden standardmäßig alle Verteilungen von "managedClusters" unterstützt. Wenn supportedClusterTypes bereitgestellt wird und kein bestimmter Clustertyp auf oberster Ebene bereitgestellt wird, werden alle Verteilungen und Kubernetes-Versionen für diesen Clustertyp als nicht unterstützt behandelt. Geben Sie für jeden Clustertyp eine Liste mit einer oder mehreren Verteilungen mit den folgenden Eigenschaften an: -Verteilung - distributionSupported - nicht unterstützteVersions |
| distribution | Liste | Ein Array von Verteilungen, die dem Clustertyp entsprechen. Geben Sie den Namen bestimmter Verteilungen an. Legen Sie den Wert auf ["Alle"] fest, um anzugeben, dass alle Verteilungen unterstützt werden. |
| distributionSupported | Boolean | Ein boolescher Wert, der angibt, ob die angegebenen Verteilungen unterstützt werden. Wenn "False" angegeben wird, führt die Angabe von "UnsupportedVersions" zu einem Fehler. |
| unsupportedVersions | Liste | Eine Liste der Versionen für die angegebenen Verteilungen, die nicht unterstützt werden. Unterstützte Operatoren: - "=" Angegebene Version wird nicht unterstützt. Beispiel: "=1.2.12" - ">" Alle Versionen, die größer als die angegebene Version sind, werden nicht unterstützt. Beispiel: ">1.1.13" - "<" Alle Versionen, die kleiner als die angegebene Version sind, werden nicht unterstützt. Beispiel: "<1.3.14" - "..." Alle Versionen im Bereich werden nicht unterstützt. Beispiel: "1.1.2...1.1.15" (enthält den rechten Wert und schließt den linken Wert aus) |
Ein für die Voting-App konfiguriertes Beispiel finden Sie im folgenden Beispiel einer Manifestdatei.
Strukturieren Ihrer Anwendung
Platzieren Sie die createUiDefinition-Datei, die ARM-Vorlage und die Manifestdatei neben dem Helm-Chart Ihrer Anwendung.
Ein Beispiel für ein ordnungsgemäß strukturiertes Verzeichnis finden Sie im Azure-Abstimmungsbeispiel.
Ein Beispiel für die Abstimmungsanwendung, die Azure Arc-fähige Kubernetes-Cluster unterstützt, finden Sie unter ConnectedCluster-only-Beispiel .
Ein Beispiel für die Abstimmungsanwendung, die Azure Kubernetes Service (AKS)-Cluster und Azure Arc-fähige Kubernetes-Cluster unterstützt, finden Sie im Beispiel für verbundene und verwaltete Cluster.
Weitere Informationen zum Einrichten eines Azure Arc-fähigen Kubernetes-Clusters für die Überprüfung der Anwendung finden Sie in der Schnellstartanleitung: Verbinden eines vorhandenen Kubernetes-Clusters mit Azure Arc.
Verwenden des Containerpaketerstellungstools
Nachdem Sie alle erforderlichen Artefakte hinzugefügt haben, führen Sie das Paketerstellungstool container-package-app aus.
Da CNABs ein neues Format sind und eine Lernkurve aufweisen, haben wir ein Docker-Image für container-package-app die Bootstrapping-Umgebung und Tools erstellt, die zum erfolgreichen Ausführen des Pakettools erforderlich sind.
Bei der Verwendung des Paketerstellungstools haben Sie zwei Möglichkeiten. Sie können das Tool manuell verwenden oder in eine Bereitstellungspipeline integrieren.
Manuelles Ausführen des Paketerstellungstools
Das aktuelle Image des Paketerstellungstools kann aus mcr.microsoft.com/container-package-app:latest gepullt werden.
Der folgende Docker-Befehl pullt das aktuelle Image des Paketerstellungstools und bindet zudem ein Verzeichnis ein.
Wenn es sich um ~\<path-to-content> ein Verzeichnis handelt, das den zu packenden Inhalt enthält, wird der folgende Docker-Befehl im Container bereitgestellt ~/<path-to-content>/data . Ersetzen Sie ~/<path-to-content> dabei durch den Speicherort Ihrer eigenen Anwendung.
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
Führen Sie die folgenden Befehle in der container-package-app-Containershell aus. Ersetzen Sie <registry-name> durch den Namen Ihrer ACR-Instanz:
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Zum Authentifizieren des ACR gibt es zwei Optionen. Eine Option besteht darin, wie zuvor dargestellt, zu verwenden az login , und die zweite Option wird über Docker ausgeführt docker login 'yourACRname'.azurecr.io. Geben Sie Ihren Benutzernamen und Ihr Kennwort ein (Benutzername sollte Ihr ACR-Name sein, und das Kennwort ist der generierte Schlüssel, der in Azure-Portal angegeben ist) und führen Sie aus.
docker login <yourACRname.azurecr.io>
Führen Sie dann cpa verify aus, um die Artefakte zu durchlaufen und einzeln zu überprüfen. Behandeln Sie gegebenenfalls aufgetretene Fehler, und führen Sie cpa buildbundle aus, wenn das CNAB-Paket erstellt und in Ihre Azure Container Registry-Instanz hochgeladen werden soll. Der cpa buildbundle Befehl führt auch den Überprüfungsprozess vor dem Erstellen aus.
cpa verify
cpa buildbundle
Hinweis
Verwenden Sie cpa buildbundle --force nur, wenn Sie ein vorhandenes Tag überschreiben möchten. Wenn Sie dieses CNAB bereits an ein Azure Marketplace-Angebot anfügen, erhöhen Sie stattdessen die Version in der Manifestdatei.
Integration in eine Azure-Pipeline
Ein Beispiel für die Integration container-package-app in eine Azure-Pipeline finden Sie im Azure Pipeline-Beispiel
Problembehandlung
Nächste Schritte
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für