Requisiti per la creazione del pacchetto dell'app

Questa pagina descrive i requisiti per il packaging dell'app Kubernetes e le linee guida per soddisfarli.

Il pacchetto dell'app è un bundle di immagini e configurazione container di cui viene eseguito il deployment nell'account cluster Kubernetes. Per supportare il deployment a Google Kubernetes Engine dalla console Google Cloud, il pacchetto dell'app deve includere un container di deployment. Il container di deployment esegue il push di configurazione e visualizzare i metadati all'API Kubernetes.

Il pacchetto dell'app consente agli utenti di Google Cloud di:

• Scopri la tua app nel catalogo di Cloud Marketplace
• Eseguire il deployment dell'app nel cluster GKE o GKE Enterprise utilizzando la console Google Cloud
• Interagire con l'app in esecuzione utilizzando la console Google Cloud

Oltre a supportare il deployment tramite la console Google Cloud, il pacchetto deve includere passaggi che consentano agli utenti di implementare l'app tramite una a interfaccia a riga di comando (CLI), con strumenti come kubectl o Helm.

Per esempi di pacchetti di app, consulta il repository GitHub per le soluzioni Google Click to Deploy. Il repository contiene pacchetti per app open source di uso comune, come WordPress e Elasticsearch.

Prima di iniziare

• Assicurati di avere configurare l'ambiente Google Cloud.
• Crea un repository Git pubblico per i file di configurazione, la guida utente e altre risorse per eseguire l'app. Puoi ospitare il repository con un fornitore come GitHub, Cloud Source Repositories o sul tuo server. Consigliamo un repository dedicato per ogni prodotto che distribuisci.

Panoramica

L'app deve soddisfare i seguenti requisiti:

• Il repository Git deve contenere un file LICENSE, che contiene i file licenza di origine per il repository.

• Il repository Git deve contenere un file di configurazione in cui viene eseguito il deployment dell'app. Il file di configurazione può essere un manifest YAML Kubernetes, o un grafico Helm.

  La configurazione deve includere una risorsa personalizzata Application, che descrive l'app.

  Consulta i requisiti per la configurazione.

• L'app deve essere eseguita su nodi utilizzando un processore x86.

• Facoltativamente, se vuoi che la tua app sia compatibile con Istio, Esamina le limitazioni per i cluster che eseguono Istio.

• Se la tua app è commerciale (non BYOL), deve segnalarne l'utilizzo a Google, in modo che i tuoi clienti vengano fatturati in modo accurato. Ti consigliamo di integrare la tua app con l'agente di fatturazione in base all'utilizzo, che invia i report sull'utilizzo a Google.

  Consulta i requisiti per integrare l'agente di fatturazione.

• Tutte le immagini container dell'app devono essere caricate sul tuo in Container Registry. Il registry deve includere anche un'immagine di deployment, che spinge la configurazione dell'app all'API Kubernetes quando gli utenti eseguono il deployment dell'app dalla console Google Cloud.

  Consulta i requisiti per la creazione di immagini delle app.

• Devi includere i test di integrazione per l'app.

  Consulta i Requisiti per la procedura di verifica.

• Devi includere una guida dell'utente con i passaggi per l'implementazione l'app dalla riga di comando, configurarla e utilizzarla.

  Consulta i requisiti per la guida dell'utente.

Requisiti per la configurazione

Puoi fornire la configurazione come manifest Kubernetes o come grafico Helm.

La tua configurazione deve soddisfare i seguenti requisiti:

• Per proteggere gli utenti da API instabili, utilizza solo risorse Kubernetes beta o disponibili in generale.

• La configurazione deve eseguire il deployment di una risorsa personalizzata dell'applicazione. La risorsa Application contiene le informazioni visualizzate dagli utenti quando eseguono il deployment dell'app tramite l'interfaccia utente di Cloud Marketplace.

  La risorsa Application è risorsa personalizzata, che aggrega i componenti Kubernetes associati alla tua app, e consente agli utenti di gestire le risorse in gruppo.

  Per informazioni sulla creazione di una risorsa applicazione e per esempi, consulta il Repository GitHub dell'applicazione.

• La configurazione deve utilizzare parametri che possono essere sostituiti mediante envsubst o come flag.

  I seguenti parametri devono essere sostituibili:

  • Spazio dei nomi: tutte le risorse della configurazione devono appartenere a un singolo spazio dei nomi. Gli utenti di Cloud Marketplace configurano questo spazio dei nomi quando eseguono il deployment dell'app. Evita di codificare in modo rigido gli spazi dei nomi nei manifest, in modo che le risorse specificate vengano create nello spazio dei nomi selezionato dagli utenti. Talvolta, gli spazi dei nomi sono definizioni di risorse, ad esempio quando fai riferimento a un ServiceAccount in RoleBinding. Tali riferimenti devono essere parametrizzati.

  • Nome app: il nome dell'istanza della risorsa Application. Questa stringa deve essere inclusa nel nome di ciascuna delle risorse dell'app, per evitare collisioni di nomi se vengono implementate più istanze dell'app in un singolo spazio dei nomi.

  • Immagini container: ogni riferimento all'immagine, ad esempio in un PodSpec, deve sostituibili, in modo che Cloud Marketplace possa eseguirne l'override in modo che puntino alle immagini pubblicate nel nostro Container Registry. it consente inoltre ai clienti di sostituire facilmente le immagini modificate.

  • Segreto licenza: se la tua app è commerciale deve accettare il nome di una risorsa secret come parametro. Il segreto contiene le credenziali per i report sull'utilizzo, che la tua app utilizza per inviare i dati sull'utilizzo a Google.

    Scopri di più sui parametri di configurazione su GitHub.

• Deve essere possibile eseguire il deployment dell'app utilizzando strumenti lato client. Per Ad esempio, se utilizzi Helm, il deployment deve funzionare Flag della riga di comando --client-only.

Limitazioni dei cluster con Istio

Se vuoi che il tuo AP sia compatibile con Istio, esamina le limitazioni descritte in questa sezione. Per una panoramica di Istio, consulta Che cos'è Istio?.

Se i tuoi clienti eseguono Istio nei loro cluster, Istio controlla il traffico di rete tra i pod della tua app per impostazione predefinita. Ciò potrebbe bloccare la comunicazione di rete nei seguenti scenari:

• Se i tuoi pod eseguono comandi kubectl che utilizzano l'indirizzo IP del cluster, potrebbero non riuscire.

• Se l'app utilizza la comunicazione pod-to-pod o basata su IP, di creazione del cluster potrebbe non riuscire.

• Le connessioni esterne a servizi di terze parti, come i repository dei pacchetti del sistema operativo, potrebbero essere bloccate. I clienti devono configurare il traffico in uscita Istio per abilitare l'accesso a servizi esterni.

Ti consigliamo di configurare le connessioni in entrata utilizzando Istio Gateway anziché le risorse LoadBalancer o Ingress.

Se usi Helm per la tua configurazione, utilizza x-google-marketplace ISTIO_ENABLED proprietà nello schema della tua del deployment. Se questa proprietà è true, il deployer deve modificare il deployment, ad esempio attendere che il sidecar Istio sia pronto.

Per aiutare i clienti a configurare la comunicazione tra i pod di app, consigliamo di aggiungere passaggi alle sezioni di post-deployment della documentazione.

Requisiti per integrare l'agente di fatturazione

Se vendi un'app commerciale, ti consigliamo di integrare la tua l'app con l'agente di fatturazione basata sull'utilizzo (UBB).

L'agente gestisce l'autenticazione e i report all'endpoint per i report sull'utilizzo di Google: Controllo servizi. Dopo aver inviato il modello di determinazione dei prezzi, il team di Cloud Marketplace crea un servizio per la tua app nonché le metriche di fatturazione per misurare l'utilizzo.

L'agente gestisce anche l'aggregazione locale, il ripristino degli arresti anomali e i nuovi tentativi. Per la metrica ore di utilizzo, l'agente può essere configurato per segnalare automaticamente i heartbeat.

L'agente espone anche lo stato dei report, consentendo alla tua app di rilevare se l'agente sta registrando correttamente i dati di utilizzo.

I clienti acquistano l'app in Cloud Marketplace per acquisire un che viene collegata all'app al momento del deployment.

Quando esegui l'integrazione con l'agente di fatturazione, tieni presente il comportamento della tua app quando i report sull'utilizzo non vanno a buon fine, il che potrebbe indicare una delle seguenti situazioni:

• Il cliente ha annullato l'abbonamento.

• Il cliente potrebbe aver disattivato accidentalmente il canale di segnalazione. Per Ad esempio, i clienti potrebbero inavvertitamente rimuovere o configurare in modo errato l'agente oppure la rete potrebbe impedire all'agente di accedere all'endpoint di reporting di Google.

Segui le best practice per segnalare l'utilizzo e per gestire i casi in cui Google non ricevono dati sull'utilizzo e ai clienti non viene addebitata.

Integrazione dell'agente di fatturazione

Puoi integrare l'agente come contenitore sidecar, che viene eseguito nello stesso pod della tua app, o utilizzando l'SDK.

Nell'approccio collaterale, l'agente viene eseguito nel proprio container, nello stesso pod Kubernetes come contenitore di app. La tua app comunica con il REST locale dell'agente a riga di comando.

Nell'approccio SDK, l'agente deve essere compilato o collegato nel tuo il file binario dell'app. L'SDK è implementato in modo nativo per Go, con associazioni per come Python.

In generale, l'approccio collaterale richiede un minore sforzo di integrazione, mentre L'SDK è più efficace contro la disattivazione accidentale.

Per la procedura dettagliata di integrazione, consulta il file README nell'agente di fatturazione basato sull'utilizzo GitHub di ASL. Per visualizzare un'implementazione di esempio, vedi l'esempio app e tools.

Credenziali per segnalare l'utilizzo

L'agente di fatturazione richiede credenziali che gli consentano di inviare i report sull'utilizzo a Google. Cloud Marketplace genera queste credenziali quando gli utenti eseguono il deployment l'app da Cloud Marketplace e ne garantisce l'esistenza come Secret nello spazio dei nomi Kubernetes di destinazione prima del deployment dell'app. Il nome di questo secret viene trasmesso alla tua app come REPORTING_SECRET di schema.

Per un esempio di manifest che utilizza il secret di reporting, consulta Esempio di app WordPress in GitHub.

Il secret contiene i seguenti campi:

entitlement-id	Un identificatore che rappresenta l'accettazione da parte del cliente di acquistare e utilizzare il software.
consumer-id	Un identificatore associato al diritto che viene passato a Google Service Control insieme ai report sull'utilizzo.
reporting-key	La chiave JSON dell'account di servizio Google Cloud utilizzata per autenticarsi a Google Service Control.

Se il tuo prodotto fornisce un componente SaaS oltre all'app, puoi facoltativamente fare in modo che il componente SaaS verifichi periodicamente la validità gli ID diritto, utilizzando il servizio di approvvigionamento Cloud Marketplace. Per ottenere l'accesso al servizio di approvvigionamento, contatta il tuo Partner Engineer.

Per informazioni sugli altri parametri trasmessi all'app, consulta Parametri trasmessi all'app di seguito in questa sezione.

Requisiti per la creazione delle immagini container

La tua app è costituita da una o più immagini container di app. Inoltre, il repository deve includere un contenitore di deployment, che viene utilizzato quando i clienti eseguono il deployment dell'app dall'interfaccia utente di Cloud Marketplace.

Le immagini container vengono in genere create Dockerfile e lo strumento a riga di comando docker build. Ti consigliamo di pubblicare il Dockerfile e le istruzioni di compilazione del container nel repository pubblico della tua app. Pubblicazione consente ai clienti di modificare o ricreare le immagini, operazione che a volte è necessaria per e certificare le immagini per gli ambienti di produzione aziendali.

Se l'immagine dell'app dipende da un'immagine di base, come Debian, o da un'immagine di runtime del linguaggio, come Python o OpenJDK, ti consigliamo vivamente di utilizzare una delle immagini container certificate di Cloud Marketplace. Ciò garantisce aggiornamenti tempestivi all'immagine di base, soprattutto per la sicurezza patch.

Dopo aver creato le immagini dell'app, inviale al registro di gestione temporanea che hai creato in Container Registry, configurare l'ambiente.

Il repository Container Registry deve avere la seguente struttura:

• L'immagine principale dell'app deve trovarsi nella directory radice del repository. Per Ad esempio, se il repository di Container Registry gcr.io/exampleproject/exampleapp, l'immagine dell'app deve essere in gcr.io/exampleproject/exampleapp.

• L'immagine del container di deployment deve trovarsi in una cartella denominata deployer. Nell'esempio precedente, l'immagine del deployment deve trovarsi gcr.io/exampleproject/exampleapp/deployer.

• Se la tua app utilizza immagini contenitore aggiuntive, ogni immagine aggiuntiva deve trovarsi nella propria cartella sotto l'immagine principale. Ad esempio, se la tua app richiede un'immagine proxy, aggiungila a gcr.io/exampleproject/exampleapp/proxy.

• Tutte le immagini dell'app devono essere taggate con il canale di rilascio e la completamente gestita. Ad esempio, se stai rilasciando la versione 2.0.5 nel canale di rilascio 2.0, tutte le immagini devono essere taggate con 2.0 e 2.0.5. Scopri come organizzare le uscite.

Ad esempio, l'immagine seguente mostra il repository di Container Registry per il cluster Garfaana dell'app Kubernetes. Il canale di rilascio è 5.3 e l'app contiene l'app principale l'immagine deployer nella propria cartella e l'immagine Debian 9 nella debian9. Tutte le immagini nel repository sono taggate con la stessa traccia, 5.3 e la versione su quel canale, 5.3.4. Deve corrispondere anche la "Versione" della definizione di risorse personalizzate (CRD) per la risorsa applicazione, come dichiarato nel deployer.

Il repository si trova all'indirizzo gcr.io/cloud-marketplace/google/grafana.

Utilizza gli identificatori delle immagini del contenitore che hai selezionato in precedenza quando scegli gli identificatori dei prodotti.

Per caricare le immagini in Container Registry, contrassegnale con il nome del registro, ed esegui il push dell'immagine utilizzando gcloud. Ad esempio, utilizza i seguenti comandi per eseguire il push delle immagini per example-pro:

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

Per la procedura dettagliata per taggare ed eseguire il push delle immagini nel tuo registry, consulta la documentazione di Container Registry.

Requisiti per il contenitore di deployment

Il contenitore di deployment o deployer viene utilizzato quando i clienti eseguono il deployment del tuo prodotto da Cloud Marketplace. L'immagine del deployer impacchetta la configurazione Kubernetes della tua app e gli strumenti client, come kubectl o Helm, che trasferiscono la configurazione all'API Kubernetes. In genere il deployer deve utilizzare lo stesso insieme a riga di comando che un utente eseguirebbe per eseguire il deployment dell'app.

Per creare il deployer, utilizza una delle immagini di base di deployment di container dal repository degli strumenti directory di marketplace:

• Se utilizzi kubectl per la configurazione, usa lo Immagine di base kubectl.
• Se usi un grafico Helm per la tua configurazione, utilizza Immagine di base Helm.

Le immagini di base hanno utilità integrate per attività come l'assegnazione dei riferimenti del proprietario, la generazione di password e la pulizia post-deployment.

Per la procedura di creazione dell'immagine del deployer, consulta Creazione del deployer dell'applicazione.

Parametri passati all'app

Il container di deployment deve dichiarare i parametri devono essere raccolti dai clienti quando selezionano la tua app. Questi parametri vengono quindi fornite al container di deployment quando gli utenti eseguono il deployment dell'app.

Per configurare questi parametri, l'immagine del contenitore di deployment deve includere un JSON Schema, in formato YAML, al seguente percorso: /data/schema.yaml.

Per scoprire come creare un schema.yaml, consulta Schema del deployment.

Richieste di cluster GPU

Se la tua app ha esigenze specifiche per le GPU o utilizza molte GPU, puoi specificare il il tipo e il numero di GPU nel cluster utilizzando lo schema del deployment. Se specifichi le tue esigenze in termini di GPU, la creazione di cluster assistita viene disattivata.

L'app potrebbe richiedere una GPU Nvidia generica o una piattaforma Nvidia specifica.

Requisiti per la procedura di verifica

Le app vengono eseguite all'interno del nostro sistema di verifica per garantire che:

• L'installazione è riuscita: tutte le risorse sono state applicate e si è aspettato che diventino valide.
• I test di funzionalità superati: il deployer avvia il pod di tester e ne controlla lo stato di uscita. Zero significa successo, diverso da zero significa errore.
• Disinstallazione riuscita: l'app e tutte le relative risorse sono state eseguite correttamente rimosso dal cluster.

Per poter pubblicare un'app su Google Cloud Marketplace, sono necessari risultati positivi.

Per informazioni dettagliate su come pacchettizzare, eseguire e verificare questi test di funzionalità, consulta la documentazione sull'integrazione della verifica.

Requisiti per la guida dell'utente

La guida dell'utente deve includere le seguenti informazioni:

Panoramica

• Una panoramica generale dell'app, che copre le funzioni di base e le opzioni di configurazione. Questa sezione deve inoltre rimandare al prodotto pubblicato su Google Cloud Marketplace.

Configurazione una tantum

• Configurazione di strumenti client come kubectl o Helm, a seconda dei casi.
• Installa CustomResourceDefinition (CRD) dell'applicazione in modo che il tuo cluster possa gestire la risorsa Application.
• Se vendi un'app commerciale, segui i passaggi per acquisire ed eseguire il deployment di un secret di licenza da Cloud Marketplace.

Installazione

• Comandi per il deployment dell'app.
• Parametri di passaggio disponibili nella configurazione dell'interfaccia utente.
• Bloccare i riferimenti alle immagini in digest immutabili.

• Se aggiungi campi di immissione personalizzati allo schema di deployment, aggiungi informazioni su i valori previsti, se applicabili.

  Scopri come aggiungere campi di immissione al deployment

Utilizzo di base

• Connessione a una Console di amministrazione (se applicabile).
• Connessione di uno strumento client ed esecuzione di un comando di esempio (se applicabile).
• Modificare nomi utente e password.
• Attivare l'ingresso e installare i certificati TLS (se applicabili).

Backup e ripristino

• Backup dello stato dell'app in corso.
• Ripristino dello stato dell'app da un backup.

Aggiornamenti delle immagini

• Aggiornamento delle immagini dell'app per patch o aggiornamenti minori.

Scalabilità

• Scalabilità dell'app (se applicabile).

Eliminazione

• Eliminazione dell'app.
• Eseguire la pulizia di tutte le risorse che potrebbero essere state intenzionalmente orfane, ad esempio PersistentVolumeClaims.