Anforderungen an das Erstellen von Anwendungspaketen

Diese Seite beschreibt die Anforderungen zum Erstellen Ihrer Kubernetes-Anwendungen als Paket und die Richtlinien zum Erfüllen dieser Anforderungen.

Ihr Anwendungspaket besteht aus Container-Images und Konfigurationsdateien, die in den Kubernetes-Clustern der Nutzer bereitgestellt werden. Um das Deployment Ihrer Anwendung in Google Kubernetes Engine von der Google Cloud Console zu unterstützen, muss das Anwendungspaket einen Deployment-Container enthalten. Der Deployment-Container überträgt die Konfigurationsdateien und zeigt Metadaten für die Kubernetes API an.

Mit Ihrem Anwendungspaket können Google Cloud-Nutzer:

  • Ihre Anwendung im Google Cloud Marketplace-Katalog entdecken
  • Die Anwendung mithilfe der Cloud Console in ihrem GKE- oder Anthos-Cluster bereitstellen
  • Mit der laufenden Anwendung über die Cloud Console interagieren

Zusätzlich zur Unterstützung des Deployment über die Cloud Console muss Ihr Paket Schritte enthalten, mit denen Nutzer Ihre Anwendung über eine Befehlszeilenschnittstelle (CLI) mithilfe von Tools wie kubectl oder Helm bereitstellen können.

Beispiele für Anwendungspakete finden Sie im GitHub-Repository für Google Click-to-Deploy-Lösungen. Das Repository enthält Pakete für beliebte Open Source-Anwendungen wie WordPress und Elasticsearch.

Vorbereitung

  • Richten Sie Ihre Google Cloud-Umgebung ein.
  • Erstellen Sie ein öffentliches Git-Repository für die Konfigurationsdateien, das Nutzerhandbuch und andere Ressourcen, um Ihre Anwendung auszuführen. Sie können das Repository bei einem Anbieter wie GitHub, Cloud Source Repositories oder auf Ihrem eigenen Server hosten. Wir empfehlen für jedes von Ihnen vertriebene Produkt ein eigenes Repository.

Übersicht

Die Anwendung muss folgende Anforderungen erfüllen:

  • Ihr Git-Repository muss eine LICENSE-Datei mit der Open-Source-Lizenz für das Repository enthalten.

  • Ihr Git-Repository muss eine Konfigurationsdatei enthalten, die Ihre Anwendung bereitstellt. Die Konfigurationsdatei kann ein Kubernetes YAML-Manifest oder ein Helm-Diagramm sein.

    Die Konfiguration muss eine benutzerdefinierte Anwendungsressource enthalten, die die Anwendung beschreibt.

    Siehe Anforderungen an die Konfiguration

  • Wenn Sie möchten, dass Ihre Anwendung mit GKE On-Prem kompatibel ist, ändern Sie die Anwendungsbilder für die Kompatibilität.

    Siehe Anforderungen zur Unterstützung von GKE On-Prem.

    Informationen zu GKE On-Prem finden Sie in der GKE On-Prem-Übersicht.

  • Wenn Ihre Anwendung mit Istio kompatibel sein soll, prüfen Sie optional die -Beschränkungen für die Cluster, auf denen Istio ausgeführt wird.

  • Wenn Ihre Anwendung kommerziell ist, muss sie ihre Nutzung an Google melden, damit die Abrechnungen für Ihre Kunden korrekt erstellt werden können. Wir empfehlen, Ihre Anwendung in den nutzungsbasierten Billing Agent einzubinden, der Nutzungsberichte an Google sendet.

    Siehe Anforderungen an die Einbindung des Billing Agent

  • Alle Container-Images Ihrer Anwendung müssen in Ihre Registry in der Container Registry hochgeladen werden. Ihre Registry muss außerdem ein Deployer-Image enthalten, mit dem die Konfiguration der Anwendung an die Google Kubernetes Engine API übertragen wird, wenn Nutzer die Anwendung über die Cloud Console bereitstellen.

    Siehe Anforderungen an die Erstellung von Anwendungs-Images.

  • Die Anwendung muss Integrationstests enthalten.

    Siehe Anforderungen an den Verifizierungsvorgang.

  • Sie müssen ein Nutzerhandbuch mit Schritten zum Bereitstellen der Anwendung über die Befehlszeile, zum Konfigurieren der Anwendung und zum Verwenden der Anwendung hinzufügen.

    Siehe Anforderungen an das Nutzerhandbuch

Anforderungen an die Konfiguration

Sie können Ihre Konfiguration entweder als Kubernetes-Manifest oder als Helm-Diagramm bereitstellen.

Ihre Konfiguration muss die folgenden Voraussetzungen erfüllen:

  • Es werden nur Betaressourcen oder allgemein verfügbare Kubernetes-Ressourcen verwendet, um Nutzer vor instabilen APIs zu schützen.

  • Ihre Konfiguration muss eine benutzerdefinierte Anwendungsressource bereitstellen. Die Anwendungsressource enthält die Informationen, die den Nutzern angezeigt werden, wenn sie ihre Anwendung über die Google Cloud Marketplace-UI bereitstellen.

    Die Anwendungsressource ist eine benutzerdefinierte Ressource. In ihr sind die Ihrer Anwendung zugeordneten Kubernetes-Komponenten zusammengefasst, sodass Nutzer diese als Gruppe verwalten können.

    Informationen zur Erstellung einer Anwendungsressource und entsprechende Beispiele finden Sie im Application GitHub-Repository.

  • Die in Ihrer Konfiguration verwendeten Parameter müssen entweder mit envsubst oder als Flags ersetzbar sein.

    Die folgenden Parameter müssen ersetzt werden können:

    • Namespace: Alle Ressourcen Ihrer Konfiguration müssen einem einzigen Namespace angehören. Nutzer von Google Cloud Marketplace konfigurieren diesen Namespace bei der Bereitstellung der Anwendung. Sie sollten in Ihren Manifesten keine hartcodierten Namespaces verwenden, damit die von Ihnen angegebenen Ressourcen im Namespace erstellt werden, den Nutzer auswählen. Gelegentlich kommen Namespaces auch in Ressourcendefinitionen vor, z. B. wenn sich auf einen ServiceAccount in einer RoleBinding, um die Option zu aktivieren. Verweise solcher Art müssen parametrisiert werden.

    • Anwendungsname: Der Instanzname der Anwendungsressource. Diese Zeichenfolge muss im Namen jeder Ressource der Anwendung enthalten sein, um Namenskollisionen zu vermeiden, wenn mehrere Instanzen der Anwendung in einem einzigen Namespace bereitgestellt werden.

    • Container-Images: Jede Image-Referenz, z. B. in einem PodSpec, muss austauschbar sein, damit Google Cloud Marketplace sie überschreiben kann, um auf Images zu verweisen, die in unserer Container Registry veröffentlicht wurden. Außerdem können Kunden modifizierte Images auf einfache Weise ersetzen.

    • Lizenz-Secret: Wenn Ihre Anwendung eine kommerzielle Messung durchführt, muss sie den Namen einer Secret-Ressource als Parameter akzeptieren. Das Secret enthält die Anmeldedaten für die Nutzungsberichte, die Ihre Anwendung verwendet, um Nutzungsdaten an Google zu senden.

      Weitere Informationen zu Konfigurationsparametern finden Sie auf GitHub.

  • Es muss möglich sein, Ihre Anwendung mit clientseitigen Tools bereitzustellen. Wenn Sie beispielsweise Helm verwenden, muss das Deployment mit dem Befehlszeilenflag --client-only funktionieren.

Anforderungen zur Unterstützung von GKE On-Prem

Die GKE On-Prem-Cluster der Kunden sind möglicherweise anders konfiguriert als die Standard-GKE-Cluster. Diese potenzielle Variabilität bedeutet, dass Ihre Kunden die folgenden Ressourcen manuell konfigurieren müssen, wenn Ihre Anwendung auf GKE On-Prem ausgeführt werden soll:

  • Speicherklassen

    Google Cloud Marketplace kann nicht vorhersagen, welche Speicherklassen im lokalen GKE-Cluster eines Kunden vorhanden sind. Daher empfehlen wir die folgenden Änderungen an Ihrer Anwendung:

    • Wenn Sie Persistent Volume Claims (PVCs) erstellen, muss die Anforderung bereitgestellt werden, ohne explizit auf eine Speicherklasse zu verweisen.

    • Wenn Ihre Anwendung das Attribut x-google-marketplace STORAGE_CLASS verwendet, müssen Kunden eine Speicherklasse auswählen, wenn sie Ihre Anwendung über die Cloud Console bereitstellen. Es wird empfohlen, eine Dokumentation hinzuzufügen, die den Nutzer bei der Auswahl einer geeigneten Speicherklasse unterstützt.

  • Dienste und Ingress

    Google Cloud Marketplace kann die Netzwerktopologie und die Netzwerkcontroller im GKE On-Prem-Cluster eines Kunden nicht vorhersagen. Daher müssen Kunden ein Netzwerk einrichten, das mit ihrer spezifischen Konfiguration funktioniert.

    Der Bereitsteller darf keine Ingress-Ressourcen erstellen, wenn die zugrunde liegende Netzwerktopologie dies nicht unterstützt. Je nachdem, welchen Client Ihre Anwendung für das Deployment verwendet, müssen Sie Ihre Anwendung so ändern:

    • Wenn Sie kubectl und Umgebungsvariablen für die Konfiguration Ihrer Anwendung verwenden, empfehlen wir, alle Ingress-Ressourcen aus Ihren Manifesten zu entfernen, da die Manifesterweiterung nicht für verschiedene Deployment-Umgebungen geändert werden kann.

    • Wenn Sie Helm für Ihre Konfiguration verwenden, verwenden Sie das Attribut x-google-marketplace INGRESS_AVAILABLE im Schema für Ihr Deployment-Image. Wenn dieses Attribut false ist, darf Ihr Deployer keine Ingress-Ressourcen erstellen. Beachten Sie, dass nur das UI-Deployment diesen Wert konfiguriert. Der Standardwert wird für das Befehlszeilen-Deployment verwendet.

      In der Click-to-Deployment-Nginx-Vorlage finden Sie ein Beispiel für die Verzweigung basierend auf dem Attributwert von INGRESS_AVAILABLE.

    Sie finden die wichtigsten Informationen zum Deployment-Container in den Anforderungen an den Deployment-Container. Ausführliche Schritte zum Erstellen eines Deployment-Containers, einschließlich Informationen zum Deployment-Schema, finden Sie im GitHub-Repository der Google Cloud Marketplace-Tools.

    Im Abschnitt nach dem Deployment Ihrer Dokumentation fügen Sie Schritte hinzu, mit denen Ihre Kunden das Netzwerk einrichten können, nachdem sie die Anwendung bereitgestellt haben.

  • Kubernetes-Dienstkonten

    Damit die GKE On-Prem-Cluster der Kunden auf die Anwendungs-Images in Ihrem Container Registry-Repository zugreifen können, muss Ihre Anwendung explizit deklarierte Kubernetes-Dienstkonten verwenden. Die Dienstkonten müssen im Schema Ihres Deployer-Images mithilfe des Attributs x-google-marketplace SERVICE_ACCOUNT definiert werden.

    Ihre Anwendung darf sich nicht auf das Standarddienstkonto des Namespace verlassen oder neue Dienstkonten erstellen. Um die Abhängigkeit vom Standarddienstkonto des Namespace zu entfernen, definieren Sie explizit das Dienstkonto, das für alle Arbeitslasten verwendet werden soll, z. B. indem Sie das Attribut serviceAccountName für alle Pod-Spezifikationen festlegen.

    Informationen zu einer Anwendung, die ein explizites Dienstkonto verwendet, finden Sie in den folgenden Beispielen aus der Prometheus-Anwendung im Google Click-to-Deploy GitHub-Repository:

    Informationen zum Konfigurieren von Dienstkonten finden Sie in der Kubernetes-Dokumentation zu Dienstkonten.

Einschränkungen bei Clustern mit Istio

Wenn Sie möchten, dass Ihre Anwendung mit Istio kompatibel ist, lesen Sie die in diesem Abschnitt beschriebenen Einschränkungen. Einen Überblick über Istio finden Sie unter Was ist Istio?.

Wenn Ihre Kunden Istio in ihren Clustern ausführen, steuert Istio standardmäßig den Netzwerkverkehr zwischen den Pods Ihrer Anwendung. Dies kann in den folgenden Szenarien die Netzwerkkommunikation blockieren:

  • Wenn Ihre Pods kubectl-Befehle ausführen, die die IP-Adresse des Clusters verwenden, schlagen die Befehle möglicherweise fehl.

  • Wenn Ihre Anwendung Pod-zu-Pod- oder IP-basierte Kommunikation verwendet, schlägt der Schritt zur Clusterbildung möglicherweise fehl.

  • Externe Verbindungen zu Drittanbieterdiensten, wie Repositories für Betriebssystempakete, werden möglicherweise blockiert. Kunden müssen den aus Istio ausgehenden Traffic konfigurieren, um den Zugriff auf externe Dienste zu ermöglichen.

Es empfiehlt sich, die eingehenden Verbindungen mithilfe des Istio-Gateways anstelle von Load Balancer- oder Ingress-Ressourcen zu konfigurieren.

Wenn Sie Helm für Ihre Konfiguration verwenden, verwenden Sie das Attribut x-google-marketplace ISTIO_ENABLED im Schema für Ihr Deployment-Image. Wenn dieses Attribut true ist, muss Ihr Deployer das Deployment ändern, indem er beispielsweise darauf wartet, dass der Istio-Sidecar bereit ist.

Um Ihren Kunden beim Einrichten der Kommunikation zwischen Anwendungs-Pods zu helfen, empfehlen wir, den Abschnitten nach dem Deployment in Ihrer Dokumentation Schritte hinzuzufügen.

Anforderungen an die Einbindung des Billing Agent

Wenn Sie eine kommerzielle Anwendung verkaufen, empfehlen wir, Ihre Anwendung in den nutzungsbasierten Billing Agent einzubinden.

Der Agent wickelt die Authentifizierung ab und sendet Nutzungsberichte an Service Control, den entsprechenden Endpunkt von Google. Wenn Sie Ihr Preismodell übertragen haben, erstellt das Google Cloud Marketplace-Team einen Dienst für Ihre Anwendung zur Berichterstattung und zum Verwenden der Abrechnungsmesswerte, um die Nutzung zu ermitteln.

Der Agent verwaltet auch lokale Zusammenfassungen, Wiederherstellungen nach Absturz und Wiederholungsversuche. Für den Messwert "Nutzung pro Stunde" kann der Agent so konfiguriert werden, dass Heartbeats automatisch gemeldet werden.

Der Agent macht auch den Berichtsstatus verfügbar, sodass Ihre Anwendung erkennen kann, ob der Agent Nutzungsdaten erfolgreich meldet.

Kunden erwerben die Anwendung in Google Cloud Marketplace, um eine Lizenz zu erwerben, die zum Zeitpunkt des Deployments an die Anwendung angehängt wird.

Beachten Sie bei der Einbindung in den Abrechnungsagenten, wie sich Ihre Anwendung verhält, wenn Nutzungsberichte fehlschlagen. Dies kann auf Folgendes hinweisen:

  • Der Kunde hat sein Abo gekündigt.

  • Der Kunde hat den Berichtskanal versehentlich deaktiviert. Es kann zum Beispiel passieren, dass Kunden den Agent versehentlich entfernen oder falsch konfigurieren, oder das Netzwerk den Zugriff des Agents auf den Berichtsendpunkt von Google verhindert.

In diesen Fällen erhält Google keine Nutzungsdaten und den Kunden werden keine Kosten in Rechnung gestellt.

In diesen Szenarien kann Ihre Anwendung die Funktionalität selbst beenden oder deaktivieren. Wenn Nutzungsberichte beim Start der Anwendung fehlschlagen, empfehlen wir, dass Ihre Anwendung sich selbst beendet, damit Ihre Kunden sofortiges Feedback erhalten und das Problem beheben können.

Billing Agent einbinden

Sie können den Agenten als Sidecar-Container integrieren, der im selben Pod wie Ihre Anwendung ausgeführt wird, oder mithilfe des SDK.

Beim Sidecar-Ansatz wird der Agent in einem eigenen Container im selben Kubernetes Pod wie der Anwendung-Container ausgeführt. Ihre Anwendung kommuniziert mit der lokalen REST-Schnittstelle des Agenten.

Beim SDK-Ansatz muss der Agent kompiliert oder mit der Binärdatei Ihrer Anwendung verknüpft werden. Das SDK ist nativ für Go implementiert und enthält Bindungen für Python.

Der Sidecar-Ansatz ist im Allgemeinen weniger integrationsaufwendig, das SDK ist dagegen robuster und lässt sich weniger leicht versehentlich deaktivieren.

Detaillierte Integrationsschritte finden Sie in der README-Datei im GitHub-Repository zum nutzungsbasierten Billing Agent. Eine Beispielimplementierung finden Sie in den Beispiel-Repositories app und tools.

Anmeldedaten für Nutzungsberichte

Für die Übermittlung von Nutzungsberichten an Google benötigt der Billing Agent Anmeldedaten. Google Cloud Marketplace generiert diese Anmeldeinformationen, wenn Nutzer die Anwendung über Google Cloud Marketplace bereitstellen, und stellt sicher, dass sie im Ziel-Kubernetes-Namespace als Secret vorhanden sind, bevor Ihre Anwendung bereitgestellt wird. Der Name dieses Secrets wird als REPORTING_SECRET-Schemaattribut an Ihre Anwendung übertragen.

Ein Beispielmanifest, das das Übertragungs-Secret verwendet, finden Sie im WordPress-Anwendungsbeispiel auf GitHub.

Das Secret enthält die folgenden Felder:

entitlement-id

Eine Kennzeichnung, die die Zustimmung des Kunden zu Erwerb und Nutzung der Software wiedergibt

consumer-id

Eine der Berechtigung zugeordnete Kennzeichnung, die zusammen mit den Nutzungsberichten an Google Service Control übergeben wird

reporting-key

Der JSON-Schlüssel des Google Cloud-Dienstkontos, der zur Authentifizierung bei Google Service Control verwendet wird

Wenn Ihre Lösung zusätzlich zur Anwendung eine SaaS-Komponente bereitstellt, können Sie diese SaaS-Komponente optional mithilfe des Google Cloud Marketplace-Beschaffungsdienstes regelmäßig die Gültigkeit von Berechtigungs-IDs prüfen lassen. Wenden Sie sich an Ihren Partnerentwickler, um Zugriff auf den Beschaffungsdienst zu erhalten.

Informationen zu anderen Parametern, die an die Anwendung übergeben werden, finden Sie unter An Ihre Anwendung übergebene Parameter weiter unten in diesem Abschnitt.

Anforderungen an die Erstellung von Container-Images

Ihre Anwendung besteht aus einem oder mehreren Anwendungscontainer-Images. Darüber hinaus muss Ihr Repository einen Deployment-Container enthalten, der verwendet wird, wenn Kunden die Anwendung über die Benutzeroberfläche des Google Cloud Marketplace bereitstellen.

Container-Images werden normalerweise mit einem Dockerfile und dem docker build-Befehlszeilentool erstellt. Wir empfehlen, die Anleitungen für Dockerfile und Container-Build im öffentlichen Repository Ihrer Anwendung zu veröffentlichen. Dadurch können Kunden die Images ändern oder neu erstellen. Dies ist manchmal erforderlich, um Images für Produktionsumgebungen in Unternehmen zu zertifizieren.

Wenn Ihr Anwendungs-Image von einem Basisimage wie Debian oder einem Laufzeitimage für Sprachen wie Python oder OpenJDK abhängt, empfehlen wir dringend die Verwendung eines der zertifizierten Container-Images von Google Cloud Marketplace. Damit werden pünktliche Aktualisierungen Ihres Basisimages sichergestellt, insbesondere für Sicherheitspatches. Dieser Ansatz vereinfacht auch die Überprüfung der Open-Source-Lizenzen, da Sie keine Pakete aus dem Basisimage berücksichtigen müssen.

Verschieben Sie Ihre Anwendungs-Images nach dem Erstellen in die Staging-Registry, die Sie bei der Einrichtung Ihrer Umgebung in der Container Registery erstellt haben.

Ihr Container Registry-Repository muss die folgende Struktur haben:

  • Das Haupt-Image Ihrer Anwendung muss sich im Stammverzeichnis des Repositorys befinden. Wenn Ihr Container Registry-Repository beispielsweise gcr.io/exampleproject/exampleapp ist, sollte sich das Image der Anwendung in gcr.io/exampleproject/exampleapp befinden.

  • Das Image für Ihren Deployment-Container muss sich in einem Ordner mit dem Namen deployer befinden. Im obigen Beispiel muss sich das Deployment-Image in gcr.io/exampleproject/exampleapp/deployer befinden.

  • Wenn Ihre Anwendung zusätzliche Container-Images verwendet, muss sich jedes zusätzliche Image in einem eigenen Ordner unter den Haupt-Images befinden. Wenn Ihre Anwendung beispielsweise ein proxy-Image benötigt, fügen Sie das Image zu gcr.io/exampleproject/exampleapp/proxy hinzu.

  • Alle Images Ihrer Anwendung müssen mit dem Release-Track und der aktuellen Version versehen sein. Wenn Sie beispielsweise die Version 2.0.5 auf dem Release-Track 2.0 veröffentlichen, müssen alle Images mit 2.0 und 2.0.5 gekennzeichnet sein. Erfahren Sie mehr über das Verwalten Ihrer Releases.

Die folgende Abbildung zeigt beispielsweise das Repository der Container Registry für die Kubernetes-Anwendung Grafana Cluster. Der Release-Track ist 5.3. Die Anwendung enthält das Image der Hauptanwendung, das Deployer-Image in einem eigenen Ordner und das Debian 9-Image in debian9. Alle Images im Repository werden mit demselben Track, 5.3, und derselben Version in diesem Track, 5.3.4, getaggt. Außerdem muss dies mit dem Feld "Version" der benutzerdefinierten Ressourcendefinition für die Anwendungsressource übereinstimmen, wie im Deployer angegeben.

Repository-Beispielstruktur für ein Grafana Container Registry

Das Repository befindet sich unter gcr.io/cloud-marketplace/google/grafana.

Verwenden Sie die zuvor ausgewählten Container-Image-Kennzeichnungen, wenn Sie Ihre Produkt-IDs auswählen.

Um Ihre Images in die Container Registry hochzuladen, kennzeichnen Sie sie mit dem Registrierungsnamen und übertragen Sie das Image mit gcloud. Verwenden Sie beispielsweise die folgenden Befehle, um die Images für example-pro zu verschieben:

docker build -t gcr.io/my-project/example-pro:4.0   # release track 4.0
docker tag gcr.io/my-project/example-pro:4.0 gcr.io/my-project/example-pro:4.0.3  # release version 4.0.3
docker push gcr.io/my-project/example-pro:4.0
docker push gcr.io/my-project/example-pro:4.0.3

Detaillierte Anweisungen zum Taggen und Übertragen von Images in die Registry finden Sie in der Dokumentation zu Container Registry.

Anforderungen an den Deployment-Container

Der Deployment-Container oder Deployer wird verwendet, wenn Kunden Ihre Lösung über den Google Cloud Marketplace bereitstellen. Das Deployer-Image erstellt die Kubernetes-Konfiguration Ihrer Anwendung und die Client-Tools wie kubectl oder Helm als Paket, das die Konfiguration an die Kubernetes API überträgt. Der Deployer sollte in der Regel dieselben Befehlszeilenbefehle verwenden, die ein Nutzer zum Bereitstellen Ihrer Anwendung ausführt.

Zum Erstellen Ihres Deployers verwenden Sie eines der Basis-Images der Deployment-Container aus dem Marktplatzverzeichnis des Tools-Repositorys:

Die Basis-Images verfügen über integrierte Dienstprogramme für Aufgaben wie das Zuweisen von Eigentümerreferenzen, das Generieren von Passwörtern und die Bereinigung nach dem Deployment.

Eine schrittweise Anleitung zum Erstellen eines Deployer-Images finden Sie unter Anwendungs-Deployer erstellen.

An Ihre Anwendung übergebene Parameter

Ihr Deployment-Container muss Parameter deklarieren, die von Kunden bei der Auswahl Ihrer Anwendung erfasst werden müssen. Diese Parameter werden dann an den Deployment-Container übergeben, wenn Nutzer die Anwendung bereitstellen.

Damit diese Parameter konfiguriert werden können, muss das Image des Deployment-Containers ein JSON-Schema im YAML-Format enthalten. Der Pfad lautet /data/schema.yaml.

Informationen zum Erstellen eines schema.yaml finden Sie unter Deployer-Schema.

Anforderungen an den Verifizierungsvorgang

Anwendungen werden in unserem Verifizierungssystem ausgeführt, um Folgendes sicherzustellen:

  • Die Installation ist erfolgreich: Alle Ressourcen werden angewendet, und es wird darauf gewartet, dass sie fehlerfrei sind.
  • Funktionstests bestanden: Der Bereitsteller startet den Tester-Pod und beobachtet seinen Exit-Status. Null bedeutet Erfolg, keine Null bedeutet einen Fehler.
  • Die Deinstallation ist erfolgreich: Die Anwendung und alle ihre Ressourcen wurden erfolgreich aus dem Cluster entfernt.

Erfolgreiche Ergebnisse sind erforderlich, bevor eine Anwendung auf dem Google Cloud Marketplace veröffentlicht werden kann.

Ausführliche Informationen zum Paketerstellen, Ausführen und Prüfen dieser Funktionalitätstests finden Sie in den Anweisungen unter verification-integration.md.

Anforderungen an das Nutzerhandbuch

Ihr Nutzerhandbuch muss die folgenden Informationen enthalten:

Übersicht

  • Eine allgemeine Übersicht über die Anwendung mit ihren grundlegenden Funktionen und Konfigurationsoptionen. Der Abschnitt muss auch einen Link zur bei Google Cloud Marketplace veröffentlichten Lösung enthalten.

Einmalige Einrichtung

  • Clienttools wie kubectl oder Helm je nach Bedarf konfigurieren.
  • CustomResourceDefinition (CRD) der Anwendung installieren, sodass Ihr Cluster die Anwendungsressource verwalten kann
  • Wenn Sie eine kommerzielle Anwendung verkaufen, Schritte zum Erwerb und zum Deployment eines Lizenz-Secrets von Google Cloud Marketplace.

Installation

  • .Befehle zum Bereitstellen der Anwendung-
  • In der UI-Konfiguration verfügbare Parameter übergeben.
  • Image-Referenzen an unveränderliche Digests anheften.
  • Wenn Sie Ihrem Deployer-Schema benutzerdefinierte Eingabefelder hinzufügen, fügen Sie gegebenenfalls Informationen zu den erwarteten Werten hinzu.

    Eingabefelder zu Ihrem Bereitsteller hinzufügen

Grundlegende Nutzung

  • Verbindung zu einer Admin-Konsole (falls zutreffend) herstellen
  • Verbindung zu einem Clienttool herstellen und gegebenenfalls Beispielbefehl ausführen
  • Nutzernamen und Passwörter ändern
  • Eingehenden Traffic aktivieren und gegebenenfalls TLS-Zertifikate installieren.

Sichern und Wiederherstellen

  • Anwendungsstatus sichern.
  • Wiederherstellen des Anwendungsstatus aus einer Sicherung.

Images aktualisieren

  • Aktualisieren der Anwendungs-Images für Patches oder kleinere Updates.

Skalieren

  • Skalieren der Anwendung (falls zutreffend).

Löschen

  • Anwendung löschen.
  • Ressourcen bereinigen, die möglicherweise gewollt verwaist sind, z. B. PersistentVolumeClaims.