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. Das Anwendungspaket muss einen Bereitstellungscontainer enthalten, damit die Anwendung über die Google Cloud Console in Google Kubernetes Engine bereitgestellt werden kann. Der Deployment-Container überträgt die Konfigurationsdateien und zeigt Metadaten für die Kubernetes API an.

Mit Ihrem Anwendungspaket können Google Cloud-Nutzer:

  • Anwendung im Cloud Marketplace-Katalog finden
  • Anwendung über die Google Cloud Console im GKE- oder GKE Enterprise-Cluster bereitstellen
  • Über die Google Cloud Console mit der ausgeführten Anwendung interagieren

Zusätzlich zur Unterstützung der Bereitstellung über die Google Cloud Console muss Ihr Paket auch Schritte für Nutzer enthalten, mit denen Nutzer die Anwendung über eine Befehlszeile 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.

Hinweise

  • 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.

Überblick

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

  • Ihre Anwendung muss auf Knoten mit einem x86-Prozessor ausgeführt werden.

  • 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 (nicht-BYOL) 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. Die Registry muss auch ein deployer enthalten, das die Konfiguration der Anwendung an die Kubernetes API überträgt, wenn Nutzer die Anwendung über die Google 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.

  • Eine benutzerdefinierte Anwendungsressource ist bereitgestellt. Die Anwendungsressource enthält die Informationen, die Nutzer sehen, wenn sie ihre Anwendung über die 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. Cloud Marketplace-Nutzer konfigurieren diesen Namespace, wenn sie Ihre Anwendung bereitstellen. Vermeiden Sie in Ihren Manifesten, Namespaces hartzucodieren, damit die von Ihnen angegebenen Ressourcen in dem Namespace erstellt werden, den die Nutzer auswählen. Gelegentlich kommen Namespaces auch in Ressourcendefinitionen vor, z. B. wenn auf ein ServiceAccount in einer RoleBinding verwiesen wird. 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, etwa in einem PodSpec, muss ersetzbar sein, damit sie von Cloud Marketplace so überschrieben werden kann, dass sie auf Images verweisen, die in unserer Container Registry veröffentlicht sind. 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.

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 gesendet haben, erstellt das Cloud Marketplace-Team einen Dienst, anhand dessen Ihre Anwendung Berichte erstellen kann, sowie die Abrechnungsmesswerte, um die Nutzung zu messen.

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 kaufen die Anwendung in Cloud Marketplace, um eine Lizenz zu erwerben, die der Anwendung bei der Bereitstellung zugeordnet 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.

Befolgen Sie die Best Practices, um die Nutzung zu melden und Fälle zu bearbeiten, in denen Google keine Nutzungsdaten erhält und Kunden nichts in Rechnung gestellt wird.

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. Cloud Marketplace generiert diese Anmeldedaten, wenn Nutzer die Anwendung aus Cloud Marketplace bereitstellen, und sorgt dafür, dass sie vor der Bereitstellung der Anwendung als Secret im Ziel-Kubernetes-Namespace vorhanden sind. 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 Ihr Produkt zusätzlich zur Anwendung eine SaaS-Komponente bereitstellt, können Sie diese optional veranlassen, die Gültigkeit der Berechtigungs-IDs regelmäßig mit dem Beschaffungsdienst von Cloud Marketplace zu prüfen. 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 Bereitstellungscontainer enthalten, der verwendet wird, wenn Kunden die Anwendung über die Cloud Marketplace-UI bereitstellen.

Container-Images werden normalerweise mit einem Dockerfile und dem docker build-Befehlszeilentool erstellt. Wir empfehlen, die Anleitungen für den 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 Basis-Image wie Debian oder einem Laufzeit-Image für Sprachen wie Python oder OpenJDK abhängt, empfehlen wir dringend, eines der zertifizierten Container-Images von Cloud Marketplace zu verwenden. Damit werden pünktliche Aktualisierungen Ihres Basisimages sichergestellt, insbesondere für Sicherheitspatches.

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 Bereitstellungscontainer

Der Bereitstellungscontainer oder deployer wird verwendet, wenn Kunden Ihr Produkt über 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 einer schema.yaml-Datei finden Sie unter Deployer-Schema.

GPU-Clusteranfragen

Wenn Ihre Anwendung bestimmte GPU-Anforderungen hat oder GPU-intensiv ist, können Sie den Typ und die Anzahl der GPUs im Cluster mit Ihrem Deployer-Schema angeben. Wenn Sie Ihre GPU-Anforderungen angeben, ist die unterstützte Clustererstellung deaktiviert.

Ihre Anwendung kann eine generische Nvidia-GPU oder eine bestimmte Nvidia-Plattform anfordern.

Anforderungen für den Bestätigungsvorgang

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 Deployer startet den Tester-Pod und beobachtet seinen Exit-Status. Null bedeutet Erfolg. Ist der Wert nicht Null, liegt ein Fehler vor.
  • 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 Ausführen, Prüfen und Verpacken dieser Funktionalitätstests finden Sie in der Dokumentation unter Integration prüfen.

Anforderungen an das Nutzerhandbuch

Ihr Nutzerhandbuch muss die folgenden Informationen enthalten:

Übersicht

  • Eine allgemeine Übersicht über die Anwendung mit ihren grundlegenden Funktionen und Konfigurationsoptionen. Dieser Abschnitt muss auch auf das veröffentlichte Produkt im Cloud Marketplace verweisen.

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 anbieten, Schritte zum Kaufen und Bereitstellen eines Lizenz-Secret von 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 Deployer 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
Zurück
Preismodell auswählen
Weiter
Anwendung an Google Cloud Marketplace senden