Requisiti per la pacchettizzazione dell'app

In questa pagina vengono descritti i requisiti per creare un pacchetto con l'app Kubernetes e le linee guida per soddisfarli.

Il pacchetto dell'app è un pacchetto di immagini container e file di configurazione che vengono implementati nei cluster Kubernetes. Per supportare il deployment della tua applicazione in Google Kubernetes Engine da Google Cloud Console, il pacchetto deve includere un container di deployment. Il container di deployment esegue il push dei file di configurazione e visualizza i metadati all'API Kubernetes.

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

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

Oltre a supportare il deployment tramite console, il pacchetto deve includere i passaggi per consentire agli utenti di eseguire il deployment della tua app tramite un'interfaccia a riga di comando (CLI), mediante strumenti come kubectl o Helm.

Per esempi di pacchetti di app, consulta il repository di GitHub per le soluzioni Google Click to Deploy. Il repository contiene pacchetti per le app open source più utilizzate, come WordPress ed Elasticsearch.

Prima di iniziare

  • Assicurati di aver configurato il tuo ambiente Google Cloud.
  • Crea un repository Git pubblico per i file di configurazione, la guida dell'utente e altre risorse per eseguire l'app. Puoi ospitare il repository con un provider 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 la licenza open source per il repository.

  • Il tuo repository Git deve contenere un file di configurazione che esegue il deployment della tua app. Il file di configurazione può essere un manifest YAML Kubernetes o un grafico Helm.

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

    Consulta Requisiti per la configurazione.

  • Facoltativamente, se vuoi che la tua app sia compatibile con i cluster Anthos su VMware, modifica le immagini dell'app per assicurare la compatibilità.

    Vedi Requisiti per supportare i cluster Anthos su VMware.

    Per informazioni sui cluster Anthos su VMware, visita la panoramica di Anthos su VMware.

  • Se vuoi che la tua app sia compatibile con Istio, consulta le limitazioni per i cluster che eseguono Istio.

  • Se la tua app è commerciale (non BYOL), deve segnalare il suo utilizzo a Google, in modo che i clienti vengano fatturati in modo accurato. Ti consigliamo di integrare la tua app con l'agente di fatturazione basato sull'utilizzo, che invia i rapporti di utilizzo a Google.

    Consulta i requisiti per l'integrazione dell'agente di fatturazione.

  • Tutte le immagini container dell'app devono essere caricate nel tuo registro in Container Registry. Il Registro di sistema deve includere anche un'immagine deployer, che esegue il push della configurazione dell'app all'API Kubernetes quando gli utenti eseguono il deployment dell'app dalla console.

    Consulta i requisiti per la creazione di immagini di app.

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

    Consulta i requisiti per la procedura di verifica.

  • Devi includere una guida per l'utente, con i passaggi per eseguire il deployment dell'app dalla riga di comando, configurare l'app e utilizzarla.

    Consulta i requisiti per la guida dell'utente.

Requisiti per la configurazione

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

La configurazione deve soddisfare i seguenti requisiti:

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

  • La configurazione deve eseguire il deployment di una risorsa personalizzata dell'applicazione. La risorsa applicazione contiene le informazioni che gli utenti visualizzano quando eseguono il deployment della loro applicazione tramite l'interfaccia utente di Google Cloud Marketplace.

    La risorsa applicazione è una risorsa personalizzata, che aggrega i componenti Kubernetes associati alla tua app e consente agli utenti di gestire queste risorse come gruppo.

    Per informazioni sulla creazione di una risorsa dell'applicazione e per esempi, consulta la pagina relativa al repository GitHub dell'applicazione.

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

    È possibile sostituire i seguenti parametri:

    • Spazio dei nomi: tutte le risorse di configurazione devono appartenere a un singolo spazio dei nomi. Gli utenti di Google Cloud Marketplace configurano questo spazio dei nomi quando eseguono il deployment della tua app. Evita spazi dei nomi hardcoded nei manifest, in modo che le risorse specificate vengano create nello spazio dei nomi selezionato dagli utenti. A volte gli spazi dei nomi vengono visualizzati anche all'interno delle definizioni delle risorse, ad esempio quando fanno riferimento a un elemento ServiceAccount in un elemento RoleBinding. Eventuali riferimenti di questo tipo devono essere parametrizzati.

    • Nome app: il nome istanza della risorsa dell'applicazione. Questa stringa deve essere inclusa nel nome di ogni risorsa dell'app, per evitare conflitti di nome se viene eseguito il deployment di più istanze dell'app in un unico spazio dei nomi.

    • Immagini container: ogni riferimento immagine, ad esempio in un elemento PodSpec, deve essere sostituibile, in modo che Google Cloud Marketplace possa ignorarlo in modo che rimandi alle immagini pubblicate nel nostro Container Registry. Inoltre, consente ai clienti di sostituire facilmente le immagini modificate.

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

      Ulteriori informazioni sui parametri di configurazione in GitHub.

  • Deve essere possibile eseguire il deployment della tua app utilizzando strumenti lato client. Ad esempio, se utilizzi Helm, il deployment deve funzionare con il flag della riga di comando --client-only.

Requisiti per supportare i cluster Anthos su VMware

I cluster Anthos sui cluster VMware potrebbero essere configurati in modo diverso dai cluster GKE standard. Questa potenziale variabilità significa che, se vuoi che la tua app venga eseguita su cluster Anthos su VMware, i tuoi clienti devono configurare manualmente le seguenti risorse:

  • Classi di archiviazione

    Google Cloud Marketplace non può prevedere quali classi di archiviazione esistono nei cluster Anthos su un cluster VMware di un cliente, quindi ti consigliamo di apportare le seguenti modifiche alla tua app:

    • Se stai creando richieste di volumi permanenti, è necessario eseguire il provisioning della richiesta senza fare riferimento esplicitamente a una classe di archiviazione.

    • Se la tua app utilizza la proprietà x-google-marketplace STORAGE_CLASS, i clienti devono scegliere una classe di archiviazione quando eseguono il deployment dell'app dalla console. Ti consigliamo di aggiungere documentazione che consenta agli utenti di scegliere una classe di archiviazione appropriata.

  • Servizi e Ingress

    Google Cloud Marketplace non può prevedere la topologia di rete e i controller di networking nei cluster Anthos di un cliente su un cluster VMware, quindi i clienti devono impostare un networking compatibile con la loro configurazione specifica.

    Il deployer non deve creare risorse Ingress se la topologia di rete sottostante non la supporta. A seconda del client utilizzato dalla tua app per il deployment, devi modificarla nei seguenti modi:

    • Se utilizzi kubectl e variabili di ambiente per la configurazione dell'app, ti consigliamo di rimuovere tutte le risorse Ingress dai manifest, poiché l'espansione dei manifest non può essere modificata per diversi ambienti di deployment.

    • Se utilizzi Helm per la tua configurazione, usa la proprietà x-google-marketplace INGRESS_AVAILABLE nello schema per l'immagine del deployment. Se questa proprietà è false, il tuo deployer non deve creare risorse Ingress. Tieni presente che solo il deployment dell'interfaccia utente configura questo valore; il valore predefinito verrà utilizzato per il deployment dell'interfaccia a riga di comando.

      Consulta il modello nginx click-to-deploy per un esempio di ramo in base a un valore della proprietà INGRESS_AVAILABLE.

    Per informazioni di alto livello sul container di deployment, consulta i requisiti per il container del deployment. Per la procedura dettagliata sulla creazione di un container di deployment, incluse le informazioni sullo schema del deployer, consulta il repository GitHub degli strumenti di Google Cloud Marketplace.

    Nella sezione post-deployment della documentazione, aggiungi i passaggi per consentire ai clienti di configurare il networking dopo aver eseguito il deployment dell'app.

  • Account di servizio Kubernetes

    Per garantire che i clienti Anthos sui cluster VMware possano accedere alle immagini dell'app nel repository di Container Registry, l'app deve utilizzare account di servizio Kubernetes dichiarati esplicitamente. Gli account di servizio devono essere definiti nello schema dell'immagine del deployer, utilizzando la proprietà x-google-marketplace SERVICE_ACCOUNT.

    L'app non deve fare affidamento sull'account di servizio predefinito dello spazio dei nomi o creare nuovi account di servizio. Per rimuovere la dipendenza dall'account di servizio predefinito dello spazio dei nomi, definisci in modo esplicito l'account di servizio da utilizzare per tutti i carichi di lavoro, ad esempio impostando la proprietà serviceAccountName per tutte le specifiche dei pod.

    Per un'app che utilizza un account di servizio esplicito, consulta i seguenti esempi dall'app Prometheus nel repository GitHub di Google Click to Deploy:

    Per informazioni sulla configurazione degli account di servizio, consulta la documentazione di Kubernetes per gli account di servizio.

Limitazioni sui 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, vedi la sezione 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 le comunicazioni di rete nei seguenti casi:

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

  • Se la tua app utilizza una comunicazione pod-to-pod o IP, il passaggio della formazione del cluster potrebbe non riuscire.

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

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

Se utilizzi Helm per la tua configurazione, usa la proprietà x-google-marketplace ISTIO_ENABLED nello schema per l'immagine del deployment. Se questa proprietà è true, il tuo deployment deve modificare il deployment, ad esempio in attesa del completamento della sidecar Istio.

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

Requisiti per l'integrazione dell'agente di fatturazione

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

L'agente gestisce l'autenticazione e la segnalazione all'endpoint di reporting sull'utilizzo di Google: Service Control. Dopo che hai inviato il tuo modello di prezzi, il team di Google Cloud Marketplace crea un servizio per la tua app in base al quale generare report e le metriche di fatturazione per misurare l'utilizzo.

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

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

I clienti acquistano l'app in Google Cloud Marketplace per acquisire una licenza, che è allegata all'app al momento del deployment.

Durante l'integrazione con l'agente di fatturazione, valuta il comportamento dell'app quando i report sull'utilizzo non riescono, il che potrebbe indicare che:

  • Il cliente ha annullato l'abbonamento.

  • Il cliente potrebbe aver disattivato accidentalmente il canale di segnalazione. Ad esempio, i clienti potrebbero rimuovere inavvertitamente 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 gestire i casi in cui Google non riceve dati di utilizzo e i clienti non ricevono addebiti.

Integrazione dell'agente di fatturazione

Puoi integrare l'agente come container collaterale, che viene eseguito nello stesso pod dell'app o utilizzando l'SDK.

Nell'approccio sidecar, l'agente viene eseguito nel proprio container, nello stesso pod Kubernetes del container di app. L'app comunica con l'interfaccia REST locale dell'agente.

Nell'approccio basato sull'SDK, l'agente deve essere compilato o collegato al programma binario dell'app. L'SDK viene implementato in modo nativo per Go, con le associazioni di Python.

In generale, l'approccio collaterale richiede meno sforzi di integrazione, mentre l'SDK è più potente contro la disattivazione accidentale.

Per la procedura di integrazione dettagliata, consulta il documento README nel repository GitHub in base all'utilizzo basato sull'utilizzo. Per un'implementazione di esempio, vedi i repository di esempio app e strumenti.

Credenziali per segnalare l'utilizzo

L'agente di fatturazione richiede credenziali che gli consentano di inviare rapporti sull'utilizzo a Google. Google Cloud Marketplace genera queste credenziali quando gli utenti eseguono il deployment dell'app da Google Cloud Marketplace e garantisce che esistano come Secret nello spazio dei nomi Kubernetes di destinazione prima del deployment dell'app. Il nome di questo Secret viene passato alla tua app come proprietà dello schema REPORTING_SECRET.

Per un manifest di esempio che utilizza il Secret di reporting, consulta l'esempio di app WordPress in GitHub.

Il Secret contiene i seguenti campi:

entitlement-id

Un identificatore che rappresenta il contratto del cliente all'acquisto e all'utilizzo del software.

consumer-id

Identificatore associato al diritto passato a Google Service Control, insieme ai rapporti sull'utilizzo.

reporting-key

La chiave JSON dell'account di servizio Google Cloud utilizzata per l'autenticazione in Google Service 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à degli ID diritti, utilizzando il servizio Approvvigionamento di Google Cloud Marketplace. Per ottenere l'accesso al servizio di approvvigionamento, contatta il tuo Partner Engineer.

Per informazioni su altri parametri trasmessi all'app, consulta la sezione Parametri trasmessi all'app più avanti in questa sezione.

Requisiti per la creazione delle immagini container

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

Le immagini container vengono in genere create utilizzando un Dockerfile e lo strumento a riga di comando docker build. Ti consigliamo di pubblicare le istruzioni per la creazione del Dockerfile e del container nel repository pubblico della tua app. La loro pubblicazione consente ai clienti di modificare o ricreare le immagini, cosa che a volte è necessaria per certificare le immagini per gli ambienti di produzione aziendali.

Se l'immagine della tua app dipende da un'immagine di base, come Debian, o un'immagine di runtime del linguaggio, come Python o OpenJDK, ti consigliamo vivamente di utilizzare una delle immagini container certificate di Google Cloud Marketplace. Questo garantisce aggiornamenti tempestivi sulla tua immagine di base, in particolare per le patch di sicurezza.

Dopo aver creato le immagini dell'app, esegui il push al Registro di sistema temporaneo che hai creato in Container Registry durante la configurazione dell'ambiente.

Il tuo repository Container Registry deve avere la seguente struttura:

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

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

  • Se l'app utilizza immagini container aggiuntive, ogni immagine aggiuntiva deve essere nella relativa cartella sotto l'immagine principale. Ad esempio, se l'app richiede un'immagine proxy, aggiungila a gcr.io/exampleproject/exampleapp/proxy.

  • Tutte le immagini della tua app devono essere contrassegnate con il percorso di rilascio e la versione corrente. Ad esempio, se stai pubblicando la versione 2.0.5 sul percorso di rilascio di 2.0, tutte le immagini devono essere contrassegnate con 2.0 e 2.0.5. Scopri come organizzare le release.

Ad esempio, la seguente immagine mostra il repository di Container Registry per l'applicazione Kubernetes Grafana Cluster. Il percorso di rilascio è 5.3, mentre l'app contiene l'immagine principale dell'app, l'immagine del deployer nella propria cartella e l'immagine Debian 9 in debian9. Tutte le immagini nel repository sono etichettate con lo stesso percorso, 5.3 e la stessa versione del percorso, 5.3.4. Deve corrispondere ancheal campo "Version" della definizione di risorsa personalizzata (CRD) per la risorsa dell'applicazione come dichiarato nel deployer.

Esempio di struttura del repository Grafana Container Registry

Il repository è a gcr.io/cloud-marketplace/google/grafana.

Utilizza gli ID immagine container che hai selezionato in precedenza durante la scelta degli ID prodotto.

Per caricare le tue immagini in Container Registry, assegnagli il nome del Registro di sistema, quindi esegui il push dell'immagine utilizzando gcloud. Ad esempio, utilizza i comandi seguenti 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 il tagging e il push delle immagini al tuo registro, consulta la documentazione di Container Registry.

Requisiti per il container del deployment

Il container di deployment, o deployer, viene utilizzato quando i clienti eseguono il deployment del tuo prodotto da Google Cloud Marketplace. L'immagine del deployer pacchettizza la configurazione Kubernetes della tua app e gli strumenti client, come kubectl o Helm, che eseguono il push della configurazione all'API Kubernetes. Il deployer dovrebbe in genere utilizzare lo stesso set di comandi a riga di comando che un utente eseguirebbe per eseguire il deployment dell'app.

Per creare il tuo deployer, utilizza una delle immagini di base per i container di deployment dalla directory dei marketplace del repository degli strumenti:

Le immagini di base hanno utilità integrate per attività quali l'assegnazione di riferimenti ai proprietari, la generazione di password e la pulizia post-deployment.

Per i passaggi per creare l'immagine del deployer, consulta Creazione del deployer di applicazioni.

Parametri trasmessi alla tua app

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

Per configurare questi parametri, l'immagine del container di deployment deve includere uno schema JSON, in formato YAML, in questo percorso: /data/schema.yaml.

Per informazioni su come creare uno schema.yaml, vedi Schema di deployment.

Richieste di cluster GPU

Se la tua app ha esigenze GPU specifiche o è ad alta intensità di GPU, puoi specificare il tipo e il numero di GPU nel cluster utilizzando lo schema del deployer. Se specifichi le esigenze della tua GPU, la creazione del cluster assistito è disabilitata.

La tua app potrebbe richiedere una GPU Nvidia generica o una specifica piattaforma Nvidia.

Requisiti per la procedura di verifica

Le app vengono eseguite nel nostro sistema di verifica per garantire che:

  • Installazione riuscita: tutte le risorse vengono applicate e sono in attesa di uno stato integro.
  • Test di funzionalità superati: il deployer avvia il pod tester e ne controlla lo stato di uscita. Zero significa successo, non zero significa errore.
  • Disinstallazione riuscita: l'app e tutte le relative risorse vengono rimosse correttamente dal cluster.

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

Per maggiori dettagli su come pacchettizzare, eseguire e verificare questi test di funzionalità, segui la documentazione sull'integrazione di Verification.

Requisiti per la guida dell'utente

La tua guida dell'utente deve includere le seguenti informazioni:

Panoramica

  • Una panoramica generale delle app che illustra le funzioni e le opzioni di configurazione di base. Questa sezione deve anche rimandare al prodotto pubblicato su Google Cloud Marketplace.

Configurazione una tantum

  • Configurazione di strumenti client come kubectl o Helm, a seconda dei casi.
  • Installare Application CustomResourceDefinition (CRD) per consentire al cluster di gestire la risorsa dell'applicazione.
  • Se vendi un'app commerciale, passaggi per acquisire e sottoporre a deployment un Secret di licenza da Google Cloud Marketplace.

Installazione

  • Comandi per il deployment dell'app.
  • Parametri di passaggio disponibili nella configurazione dell'interfaccia utente.
  • Blocco dei riferimenti alle immagini per digest immutabili.
  • Se aggiungi campi di immissione personalizzati allo schema del deployer, aggiungi informazioni sui valori previsti, se applicabili.

    Scopri come aggiungere campi di input al deployer

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).
  • Modifica di nomi utente e password.
  • Abilitazione del traffico in entrata e installazione dei certificati TLS (se applicabili).

Backup e ripristino

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

Aggiornamenti di immagini

  • Aggiornamento delle immagini dell'app per patch o aggiornamenti di minore entità.

Ridimensiona

  • Scalabilità dell'app (se applicabile).

Eliminazione

  • Eliminazione dell'app in corso...
  • Pulizia di risorse che potrebbero essere orfane intenzionalmente, come PersistentVolumeClaim.