Esecuzione di JanusGraph su GKE con Cloud Bigtable

I database di grafici possono aiutarti a scoprire gli insight modellando le entità dei dati e le relazioni tra questi ultimi. JanusGraph è un database di grafici che supporta l'utilizzo di grandi quantità di dati. Questo tutorial mostra come eseguire JanusGraph su Google Cloud con Google Kubernetes Engine come piattaforma di orchestrazione e Bigtable come backend di archiviazione. Il tutorial è rivolto ad architetti di sistema, amministratori di database e professionisti DevOps interessati a eseguire il database dei grafici JanusGraph su Google Cloud utilizzando un database gestito come backend di archiviazione. Si presume che tu abbia familiarità con Google Kubernetes Engine (GKE), pod di Kubernetes, grafici Helm, Bigtable ed Elasticsearch. Non è necessario conoscere il framework di computing dei grafici Apache TinkerPop e il linguaggio e la macchina di attraversamento dei grafici Gremlin, ma questa conoscenza è necessaria per utilizzare Janusgraph oltre gli esempi riportati in questo tutorial.

Panoramica

Nella terminologia dei grafici, le entità sono note come nodi o vertici, mentre le relazioni sono note come bordi. In JanusGraph, sia i vertici che i bordi possono avere altri dati associati resi disponibili tramite le proprietà.

Esempio di grafico di una proprietà.

L'illustrazione precedente è un esempio di grafico di una proprietà.

I database di grafici consentono di modellare una varietà di domini e attività:

  • Social network
  • Transazioni finanziarie (per l'analisi delle frodi)
  • Reti di sistemi fisici o virtuali

Quando crei database con grafici, a volte crei milioni o addirittura miliardi di vertici e bordi. Se utilizzi JanusGraph con Bigtable come livello di archiviazione sottostante, puoi eseguire query rapide (note come trasversamenti del grafico) e scalare il livello di archiviazione in modo indipendente in base alle dimensioni e alla velocità effettiva di cui hai bisogno. JanusGraph utilizza anche un backend di indicizzazione plug-in per fornire l'indicizzazione di testo completo per le proprietà vertice e Edge. In questo tutorial, eseguirai il deployment di un'infrastruttura JanusGraph scalabile su GKE. Utilizzi Elasticsearch come backend di indicizzazione in esecuzione nei pod in uno StatefulSet e utilizzi Bigtable come backend di archiviazione. Al termine, puoi attraversare le relazioni esistenti nei dati del grafico. Il seguente diagramma mostra in che modo questi elementi si integrano perfettamente.

Deployment di JanusGraph con Bigtable su GKE.

Il diagramma illustrando il deployment JanusGraph su GKE con Elasticsearch eBigtable.

Dati di JanusGraph in Bigtable

I dati dei grafici vengono archiviati da JanusGraph come elenco di aggressività. Ogni riga rappresenta un vertice, eventuali vertici (bordi) e metadati della proprietà adiacenti relativi ai vertici e ai bordi. La chiave riga è l'identificatore univoco del vertice. Ogni relazione tra il vertice e un altro vertice e qualsiasi proprietà che definisce ulteriormente la relazione viene archiviata come una colonna di proprietà o perimetrale. I dati del qualificatore di colonna e dell'archivio valori di colonna che definiscono il bordo, in conformità con le best practice per Bigtable, Ogni proprietà di vertice viene archiviata come colonna separata, utilizzando di nuovo sia il qualificatore di colonna che il valore della colonna per definire la proprietà.

Il seguente diagramma mostra questa struttura di archiviazione.

Struttura di archiviazione dell'elenco di cadenza JanusGraph.

Il diagramma mostra la struttura logica di archiviazione per un piccolo frammento del grafico con i dettagli logici per due righe vertice. Nel diagramma, le due righe di esempio rappresentano due vertici. Il primo vertice contiene un'unica proprietà ed è correlato ad altri due vertici con due bordi separati. Il secondo vertice contiene colonne che contengono due proprietà e un bordo.

L'illustrazione seguente del modello logico dei dati del bordo del vertice fornisce alcuni dettagli sui qualificatori di colonna e sui valori per una colonna di bordo o di una proprietà del bordo.

Colonna Limite di JanusGraph e proprietà del bordo.

Per ogni vertice adiacente, una colonna archivia i metadati relativi a tale bordo. Il qualificatore di colonna contiene i metadati relativi alla relazione del bordo e alla direzione del bordo e un puntatore al vertice adiacente. Il valore della colonna contiene l'etichetta del bordo e le eventuali proprietà aggiuntive del bordo. Poiché gli attraversamenti possono essere seguiti in entrambe le direzioni, i bordi vengono archiviati due volte, una per ciascuna estremità della relazione perimetrale. L'archiviazione bidirezionale perimetrale aumenta notevolmente le prestazioni di attraversamento, ma prevede alcuni compromessi a causa della ridondanza di spazio di archiviazione aggiuntivo e di mutazioni dei bordi non atomici.

Il seguente diagramma è il modello di dati logici di una colonna di proprietà vertice.

Valori della colonna JanusGraph per una colonna di proprietà.

L'illustrazione precedente fornisce dettagli sui qualificatori e sui valori di una colonna perimetrale.

Ogni proprietà del vertice viene memorizzata come colonna separata. Il qualificatore colonna è un identificatore univoco della chiave della proprietà. Il valore della colonna contiene sia un identificatore per la proprietà sia il valore della proprietà.

JanusGraph si affida anche all'ordinamento lessicografico di Bigtable per le righe e i qualificatori di colonna al fine di migliorare il rendimento delle query.

Obiettivi

  • Crea un'istanza Bigtable.
  • Crea un cluster GKE.
  • Installa Helm.
  • Usa un grafico Helm per il deployment di JanusGraph e di Elasticsearch.
  • Utilizza la console di Gremlin e connettiti a JanusGraph.
  • Carica ed esegui query sui dati di esempio.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono beneficiare di una prova gratuita.

Al termine di questo tutorial, puoi evitare una fatturazione continua eliminando le risorse che hai creato. Per scoprire di più, vedi Pulizia.

Prima di iniziare

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
  2. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  4. Abilita le API Bigtable, Compute Engine e GKE .

    Abilita le API

  5. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  6. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  7. Abilita le API Bigtable, Compute Engine e GKE .

    Abilita le API

prepara l'ambiente

In questo tutorial, utilizzerai Cloud Shell per inserire i comandi. Cloud Shell ti dà accesso alla riga di comando nella console e include l'interfaccia a riga di comando di Google Cloud e altri strumenti che devi sviluppare in Google Cloud. Cloud Shell viene visualizzato come una finestra nella parte inferiore della console. L'inizializzazione può richiedere diversi minuti, ma viene visualizzata immediatamente la finestra.

  1. Nella console, attiva Cloud Shell.

    Attiva Cloud Shell

  2. In Cloud Shell, imposta le variabili di ambiente per la zona di Compute Engine in cui creerai il cluster Bigtable e il cluster GKE e il nome, il tipo di nodo e la versione del tuo cluster GKE:

    export PROJECT_ID=PROJECT_ID
    export GCP_ZONE=REGION
    export GKE_CLUSTER_NAME=GKE_CLUSTER_NAME
    export GKE_NODE_TYPE=n1-standard-4
    export GKE_VERSION=1.20
    

    Sostituisci quanto segue:

    • PROJECT_ID con l'identificatore del progetto.
    • REGION con la zona in cui verranno creati il cluster Bigtable e il cluster GKE.
    • GKE_CLUSTER_NAME con il nome del tuo cluster GKE.

    Il comando dovrebbe essere simile all'esempio seguente:

    export PROJECT_ID=bt-janusgraph-project-id
    export GCP_ZONE=us-central1-f
    export GKE_CLUSTER_NAME=janusgraph-gke
    export GKE_NODE_TYPE=n1-standard-4
    export GKE_VERSION=1.20
    
  3. Crea un cluster GKE in cui verrà eseguito il deployment di JanusGraph:

    gcloud container clusters create ${GKE_CLUSTER_NAME} \
        --zone=${GCP_ZONE} \
        --cluster-version=${GKE_VERSION} \
        --machine-type ${GKE_NODE_TYPE} \
        --scopes "https://www.googleapis.com/auth/cloud-platform"
    

Creazione di un'istanza Bigtable

Per questo backend di JanusGraph, questo tutorial utilizza Bigtable, che può scalare rapidamente per soddisfare le tue esigenze. Questo tutorial utilizza un cluster a nodo singolo, economico e sufficiente per il tutorial. Puoi iniziare i tuoi progetti con un cluster più piccolo e poi passare a un cluster più grande quando è tutto pronto per lavorare con i dati di produzione. La documentazione di Bigtable include una discussione dettagliata sulle prestazioni e la scalabilità per aiutarti a scegliere le dimensioni del cluster per il tuo lavoro.

  1. In Cloud Shell, imposta la variabile di ambiente per l'identificatore di istanza Bigtable:

    export BIGTABLE_INSTANCE_ID=BIGTABLE_INSTANCE_ID
    

    Sostituisci BIGTABLE_INSTANCE_ID con l'identificatore dell'istanza Bigtable.

  2. Crea l'istanza Bigtable:

    gcloud bigtable instances create ${BIGTABLE_INSTANCE_ID} \
        --cluster-config=id=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE},zone=${GCP_ZONE},nodes=1 \
        --display-name=${BIGTABLE_INSTANCE_ID}-${GCP_ZONE}
    

Installare e configurare Helm

Usi Helm per eseguire il deployment di applicazioni nel cluster Kubernetes. In questo tutorial utilizzi Helm per eseguire il deployment dei servizi JanusGraph ed Elasticsearch sul tuo cluster GKE.

  1. In Cloud Shell, installa Helm:

    curl -fsSL -o get_helm.sh \
        https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
    chmod 700 get_helm.sh
    DESIRED_VERSION=v3.5.0 ./get_helm.sh
    
  2. Aggiungi il repository del grafico elastic, in modo che la dipendenza del grafico Elasticsearch possa essere trovata durante il deployment del grafico JanusGraph:

    helm repo add elastic https://helm.elastic.co
    

    Questo repository di grafici è ospitato da Elastic, i creatori di Elasticsearch.

Usa Helm per installare JanusGraph ed Elasticsearch

In questa sezione utilizzerai un grafico Helm per eseguire il deployment di JanusGraph ed Elasticsearch nel tuo cluster Kubernetes.

Il grafico Helm viene estratto da GitHub. Il deployment incluso nel repository dei grafici Helm esegue il deployment di un set di tre pod JanusGraph dietro un servizio che avvierà un bilanciatore del carico HTTP(S) interno. Quando i pod sono in esecuzione, i probe di avvio e di attività eseguono richieste HTTP per eseguire i controlli di integrità sul server JanusGraph su ogni pod. Inoltre, il grafico include un grafico delle dipendenze fornito da Elastic che esegue il deployment di tre pod Elasticsearch in uno StatefulSet.

  1. In Cloud Shell, imposta le variabili di ambiente per i nomi Helm e JanusGraph:

    export HELM_REPO=bigtable-janusgraph-helm
    export JANUSGRAPH_VERSION=0.5.3
    export HELM_CHART_RELEASE_VERSION=1
    export HELM_CHART_RELEASE_TAG=${JANUSGRAPH_VERSION}-${HELM_CHART_RELEASE_VERSION}
    export HELM_CHART_RELEASE_TAG_HASH=f8b271a4854d4a553dd5e9ba014d077fb098d9ab
    export HELM_CHART_NAME=janusgraph-bigtable
    
  2. Trascina il grafico Helm da GitHub:

    git clone https://github.com/GoogleCloudPlatform/${HELM_REPO} \
       --branch ${HELM_CHART_RELEASE_TAG}
    
  3. Vai alla directory del grafico Helm:

    cd ${HELM_REPO}
    
  4. Per motivi di sicurezza, esegui la verifica utilizzando l'hash di commit:

    HEAD_COMMIT_HASH=$(git rev-parse --verify HEAD)
    if [ _${HEAD_COMMIT_HASH} == _${HELM_CHART_RELEASE_TAG_HASH} ]
    then
        echo "Commit hash verified"
    fi
    

    Se l'output non sembra simile al seguente, non procedere poiché l'integrità del tag clonato non è stata verificata.

    Commit hash verified
    
  5. Aggiorna le dipendenze del grafico:

    helm dep update
    
  6. Vai alla directory principale:

    cd ..
    
  7. Imposta le variabili di ambiente per i nomi delle entità Helm e JanusGraph:

    export HELM_RELEASE_NAME=janusgraph-bigtable-elastic
    export ELASTICSEARCH_CLUSTER_NAME=${HELM_RELEASE_NAME}-elasticsearch
    export BIGTABLE_JANUSGRAPH_TABLE=janusgraph-table
    
  8. Crea un file values.yaml, che fornisce a Helm le proprietà di configurazione da utilizzare durante il deployment del grafico JanusGraph:

    cat > values.yaml << EOF
    
    image:
      repository: docker.io/janusgraph/janusgraph
      tag: 0.5.3
      pullPolicy: IfNotPresent
    
    replicaCount: 3
    
    service:
      type: LoadBalancer
      port: 8182
      serviceAnnotations:
        networking.gke.io/load-balancer-type: "Internal"
    
    elasticsearch:
      deploy: true
      clusterName: ${ELASTICSEARCH_CLUSTER_NAME}
    
    properties:
      storage.backend: hbase
      storage.directory: null
      storage.hbase.ext.google.bigtable.instance.id: ${BIGTABLE_INSTANCE_ID}
      storage.hbase.ext.google.bigtable.project.id: ${PROJECT_ID}
      storage.hbase.ext.hbase.client.connection.impl: com.google.cloud.bigtable.hbase2_x.BigtableConnection
      storage.hbase.short-cf-names: true
      storage.hbase.table: ${BIGTABLE_JANUSGRAPH_TABLE}
      index.search.backend: elasticsearch
      index.search.hostname: ${ELASTICSEARCH_CLUSTER_NAME}-master
      index.search.directory: null
      index.search.elasticsearch.health-request-timeout: 90s
      cache.db-cache: true
      cache.db-cache-clean-wait: 20
      cache.db-cache-time: 180000
      cache.db-cache-size: 0.5
      cluster.max-partitions: 1024
      graph.replace-instance-if-exists: true
    
    persistence:
      enabled: false
    
    debugLevel: INFO
    EOF
    
  9. Esegui il deployment del grafico JanusGraph Helm utilizzando il file values.yaml che hai creato:

    helm upgrade --install \
                 --wait \
                  --timeout 600s \
                  ${HELM_RELEASE_NAME} \
                  ./${HELM_REPO} \
                  -f values.yaml
    

    Il processo di installazione attende che tutte le risorse siano pronte prima del suo completamento. Questa procedura potrebbe richiedere diversi minuti.

Verifica il tuo deployment JanusGraph

Al termine dell'installazione di Helm, viene visualizzata una sezione NOTES che descrive un'esperienza introduttiva. Puoi seguire i passaggi descritti nella sezione NOTES per verificare che il tuo ambiente JanusGraph funzioni.

  1. In Cloud Shell, verifica che i componenti del grafico Helm di cui è stato eseguito il deployment in GKE:

    1. Controlla il deployment JanusGraph:

      kubectl get deployments
      

      Se il deployment ha esito positivo, l'output è il seguente:

      NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
      janusgraph-bigtable-elastic   3/3     3            3           3m28s
      
    2. Controlla l'Elasticsearch StatefulSet:

      kubectl get statefulsets
      

      Se tutto funziona correttamente, l'output è il seguente:

      NAME                                               READY   AGE
      janusgraph-bigtable-elastic-elasticsearch-master   3/3     4m13s
      
  2. Imposta una variabile di ambiente sul nome di un pod Kubernetes che esegue il server JanusGraph Gremlin. L'etichetta app per il pod su cui è in esecuzione il server Gremlin viene ricavata dal nome del grafico Helm definito nel file Chart.yaml.

    export APP_LABEL_FROM_CHART_NAME=${HELM_CHART_NAME}
    export POD_NAME=$(kubectl get pods \
                         --namespace default \
                         -l "app=${APP_LABEL_FROM_CHART_NAME}, \
                             release=${HELM_RELEASE_NAME}" \
                         -o jsonpath="{.items[0].metadata.name}")
    
  3. Connettiti al pod ed esegui la console Gremlin, una shell di lettura evale di lettura (REPL). Il nome del container viene derivato anche dal nome del grafico Helm in Chart.yaml.

    export GREMLIN_CONTAINER=${HELM_CHART_NAME}
    kubectl exec \
            -c ${GREMLIN_CONTAINER} \
            -it $POD_NAME \
            -- /opt/janusgraph/bin/gremlin.sh
    
  4. Nella console di Gremlin, connettiti al server Apache TinkerPop:

    1. Avvia la sessione:

      :remote connect tinkerpop.server conf/remote.yaml session
      

      L'output ha il seguente aspetto:

      ==>Configured localhost/127.0.0.1:8182-[b08972f2-a2aa-4312-8018-bcd11bc9812c]
      
    2. Connettiti al server:

      :remote console
      

      L'output ha il seguente aspetto:

      ==>All scripts will now be sent to Gremlin Server - [localhost/127.0.0.1:8182]-[b08972f2-a2aa-4312-8018-bcd11bc9812c] - type ':remote console' to return to local mode>
      
  5. Nella console di Gremlin, verifica che il server di Gremlin funzioni correttamente controllando la variabile graph che rappresenta l'istanza del grafico:

    graph
    

    L'output indica che il server JanusGraph è in esecuzione con un database compatibile con HBase, in questo caso Bigtable, come backend di archiviazione.

    ==>standardjanusgraph[hbase:[127.0.0.1]]
    
  6. In Gremlin, crea due vertici

    v1 = graph.addVertex(label, 'hello')
    v2 = graph.addVertex(label, 'world')
    

    Se l'output della console è simile al seguente, significa che sono stati aggiunti i due vertici:

    ==>v[4344]
    ==>v[4152]
    
  7. Crea un bordo che colleghi i due vertici:

    v1.addEdge('followedBy', v2)
    

    Se l'output della console è simile al seguente, significa che è stato aggiunto il bordo tra i due vertici:

    ==>e[17j-3co-4fmd-oe054][4344-followedBy->4152]
    
  8. Esegui il commit della transazione:

    graph.tx().commit()
    

    Se l'output della console è null, significa che le operazioni sono state eseguite:

    ==>null
    

    Il seguente diagramma illustra il grafico creato dai comandi.

    Vertici e bordi di esempio di JanusGraph.

    Il vertice con etichetta hello è collegato da un bordo diretto con l'etichetta followedBy al vertice con etichetta world.

  9. Esegui una query Gremlin per vedere qual è l'etichetta del vertice che segue un bordo etichettato followedBy dal vertice con etichetta hello:

    g.V().has(label, 'hello').out('followedBy').label()
    

    La sintassi delle query è spiegata nella sezione successiva. Per ora, vedi la parola world come output della query:

    ==>world
    

Carica ed esegui query su un set di dati di esempio

Ora che hai eseguito il deployment di JanusGraph e puoi connetterti utilizzando Gremlin, puoi iniziare a caricare e a eseguire query sui tuoi dati. Per vedere come funziona questo processo, carica il set di dati di esempio fornito con JanusGraph, il grafico degli dei, che illustra le divinità mitologiche del pantheon romano e le sue proprietà di posizione.

  1. In Gremlin, carica il grafico che hai creato in precedenza:

    GraphOfTheGodsFactory.load(graph)
    

    L'output è il seguente:

    ==>null
    
  2. Invia una query di attraversamento grafico che trova tutti i fratelli di Giove:

    g.V().has('name', 'jupiter').out('brother').values('name')
    

    La seguente tabella spiega i passaggi attraversati dalla query.

    Passaggio trasversale Spiegazione
    g.V() Inizia con la raccolta di vertici.
    has('name', 'jupiter') Trova uno che abbia la proprietà name con il valore jupiter.
    out('brother') Da qui, segui gli eventuali bordi etichettati come brother.
    values('name') Per i vertici in cui si trovano questi bordi, recupera la proprietà name.
    L'output è il seguente:

    ==>neptune
    ==>pluto
    

    Per acquisire familiarità con le query di attraversamento possibili su questo grafico del set di dati Gods, prova altre query di esempio dai JanusGraph doc.

Verificare che i dati siano archiviati in Bigtable

Ora che hai creato alcuni dati di esempio nel cluster JanusGraph, puoi verificare che Bigtable sia stato utilizzato come backend di archiviazione.

  1. Chiudi la console di Gremlin:

    :q
    
  2. In Cloud Shell, verifica che i dati siano stati resi persistenti nella tabella janusgraph in Bigtable:

    cbt -project=${PROJECT_ID} \
        -instance=${BIGTABLE_INSTANCE_ID} \
         count ${BIGTABLE_JANUSGRAPH_TABLE}
    

    L'output è simile al seguente.

    2021/03/02 02:32:19 -creds flag unset, will use gcloud credential
    101
    

    Il valore 101 nell'output rappresenta il numero di righe in janusgraph table e potrebbe essere diverso per te.

Verificare la creazione dell'indice di ricerca in Elasticsearch

  1. In Cloud Shell, imposta le variabili per l'indice e il nome del pod Elasticsearch:

    export ELASTICSEARCH_POD_ORDINAL=0
    export ELASTICSEARCH_POD_NAME_ROOT=${ELASTICSEARCH_CLUSTER_NAME}-master
    export ELASTICSEARCH_POD=${ELASTICSEARCH_POD_NAME_ROOT}-0
    

    I nomi dei pod Elasticsearch sono definiti dalle dipendenze Elasticsearch Helm. I nomi dei pod sono composti dal nome del cluster fornito nel file values.yaml che hai creato, dalla parola master e da un numero ordinale con indice zero, tutti separati da trattini. Per questo passaggio, scegli il primo pod, rappresentato da zero (0).

  2. Usa l'API REST Elasticsearch Aliases per esaminare gli indici:

    kubectl exec \
            -c elasticsearch \
            -it ${ELASTICSEARCH_POD} \
            --  \
            curl -XGET "127.0.0.1:9200/_aliases?pretty=true";
    

    L'output mostra due indici, janusgraph_vertices e janusgraph_edges, creati da JanusGraph per fornire ricerche efficienti utilizzando i vertici e le proprietà periferiche:

    {
      "janusgraph_vertices" : {
        "aliases" : {
          "janusgraph" : { }
        }
      },
      "janusgraph_edges" : {
        "aliases" : {
          "janusgraph" : { }
        }
      }
    }
    
  3. Esegui una query sui valori di uno degli indici utilizzando l'API REST di Elasticsearch:

    kubectl exec \
           -c elasticsearch \
           -it ${ELASTICSEARCH_POD} \
           --  \
           curl -XGET "127.0.0.1:9200/janusgraph_edges/_search?pretty=true&q=*";
    

    I risultati di ricerca mostrano che sono presenti voci negli indici creati da JanusGraph. L'output visualizzato è simile ai seguenti risultati troncati, che mostrano la presenza di voci nell'indice janusgraph_edges.

    {
     "took" : 94,
     "timed_out" : false,
     "_shards" : {
       "total" : 1,
       "successful" : 1,
       "skipped" : 0,
       "failed" : 0
     },
     "hits" : {
       "total" : {
         "value" : 6,
         "relation" : "eq"
       },
       "max_score" : 1.0,
       "hits" : [
         {
           "_index" : "janusgraph_edges",
           "_type" : "_doc",
           "_id" : "6bvp-5ovc-b2t-2yko",
           "_score" : 1.0,
           "_source" : {
             "reason" : "loves waves"
           }
         },
         {
    …
    

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. Nella console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto da eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi