Azioni di inizializzazione

Quando crei un cluster Dataproc, puoi specificare azioni di inizializzazione negli eseguibili o negli script che verranno eseguiti su tutti i nodi del cluster Dataproc immediatamente dopo la configurazione del cluster. Le azioni di inizializzazione configurano spesso le dipendenze dei job, ad esempio l'installazione dei pacchetti Python, in modo che i job possano essere inviati al cluster senza dover installare dipendenze quando i job vengono eseguiti.

Di seguito sono riportati alcuni script di azioni di inizializzazione di esempio: Nota: Google non supporta questi esempi.

Considerazioni importanti e linee guida

  • Non creare cluster di produzione che fanno riferimento ad azioni di inizializzazione situate nei gs://goog-dataproc-initialization-actions-REGION bucket pubblici. Questi script vengono forniti come implementazioni di riferimento. Sono sincronizzati con le modifiche in corso del repository GitHub e gli aggiornamenti a questi script possono interrompere la creazione del cluster. Copia invece l'azione di inizializzazione dal bucket pubblico a una cartella del bucket Cloud Storage con versione, come mostrato nell'esempio seguente:

    REGION=COMPUTE_REGION
    gsutil cp gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
        gs://my-bucket/cloud-sql-proxy/v1.0/cloud-sql-proxy.sh
    
    Quindi, crea il cluster facendo riferimento alla copia in Cloud Storage:
    gcloud dataproc clusters create CLUSTER_NAME \
        --region=${REGION} \
        --initialization-actions=gs://my-bucket/cloud-sql-proxy/v1.0/cloud-sql-proxy.sh \
        ...other flags...
    

  • Le azioni di inizializzazione vengono eseguite su ciascun nodo durante la creazione del cluster. Vengono inoltre eseguiti su ogni nodo aggiunto durante la scalabilità o la scalabilità automatica dei cluster.

  • Quando aggiorni le azioni di inizializzazione, ad esempio quando sincronizzi le azioni di inizializzazione di Cloud Storage con le modifiche apportate al bucket pubblico o alle azioni di inizializzazione del repository GitHub, crea una nuova cartella (preferibilmente con nome della versione) per ricevere le azioni di inizializzazione aggiornate. Se invece aggiorni l'azione di inizializzazione, i nuovi nodi, come quelli aggiunti dal gestore della scalabilità automatica, eseguiranno l'azione di inizializzazione aggiornata, anziché l'azione di inizializzazione della versione precedente eseguita sui nodi esistenti. Queste differenze nell'azione di inizializzazione possono comportare nodi incoerenti o non funzionanti.

  • Le azioni di inizializzazione vengono eseguite come utenti root. Non è necessario utilizzare sudo.

  • Utilizza i percorsi assoluti nelle azioni di inizializzazione.

  • Utilizza una riga Bangs nelle azioni di inizializzazione per indicare come interpretare lo script (ad esempio #!/bin/bash o #!/usr/bin/python).

  • Se un'azione di inizializzazione termina con un codice di uscita diverso da zero, l'operazione di creazione del cluster segnalerà uno stato "ERROR". Per eseguire il debug dell'azione di inizializzazione, utilizza SSH per connetterti alle istanze VM del cluster, quindi esamina i log. Dopo aver risolto il problema relativo all'azione di inizializzazione, puoi eliminare il cluster e ricrearlo.

  • Se crei un cluster Dataproc con solo indirizzi IP interni, tenta di accedere a github.com su Internet con un'azione di inizializzazione non riuscito, a meno che tu non abbia configurato le route per indirizzare il traffico tramite Cloud NAT o Cloud VPN. Senza accesso a Internet, puoi abilitare l'accesso privato Google e posizionare le dipendenze job in Cloud Storage; i nodi cluster possono scaricare le dipendenze da Cloud Storage dagli IP interni.

  • Puoi utilizzare immagini personalizzate Dataproc anziché azioni di inizializzazione per configurare le dipendenze dei job.

  • Elaborazione dell'inizializzazione:

    • Cluster immagini precedenti alla 2.0:
      • Master: per consentire le azioni di inizializzazione eseguite sui master per scrivere file in HDFS, le azioni di inizializzazione dei nodi master non iniziano finché l'HDFS non è scrivibile (fino a quando HDFS non esce dal modalità provvisoria e non vengono uniti almeno due datano HDFS).
      • Worker: se imposti la dataproc:dataproc.worker.custom.init.actions.mode proprietà cluster su RUN_BEFORE_SERVICES, ogni worker esegue le proprie azioni di inizializzazione prima di avviare i dadoni del nodo dati HDFS e YARN dedemanager. Poiché Dataproc non esegue azioni di inizializzazione del master finché HDFS non è scrivibile, il che richiede due daemon di nodi datano HDFS in esecuzione, l'impostazione di questa proprietà può aumentare il tempo di creazione del cluster.
    • Più di 2.0 cluster di immagini:

      • Master: le azioni di inizializzazione dei nodi master possono essere eseguite prima che l'HDFS sia scrivibile. Se esegui azioni di inizializzazione che archiviano i file in HDFS o dipendono dalla disponibilità dei servizi dipendenti da HDFS, ad esempio Ranger, imposta la proprietà del cluster dataproc.master.custom.init.actions.mode su RUN_AFTER_SERVICES. Nota: poiché questa impostazione della proprietà può aumentare il tempo di creazione del cluster, consulta la spiegazione del ritardo nella creazione dei cluster per i worker cluster delle immagini precedenti alla 2.0, utilizzala solo quando necessario (come pratica generale, utilizza l'impostazione RUN_BEFORE_SERVICES predefinita per questa proprietà).
      • Worker: la dataproc:dataproc.worker.custom.init.actions.mode proprietà del cluster è impostata su RUN_BEFORE_SERVICES e non può essere passata al cluster quando viene creato il cluster (non puoi modificare l'impostazione della proprietà). Ogni worker esegue le proprie azioni di inizializzazione prima di avviare il nodo dati HDFS e i daemon NodeManager YARN. Poiché Dataproc non attende che l'HDFS sia scrivibile prima di eseguire le azioni di inizializzazione del master, quelle di inizializzazione del master e del worker vengono eseguite in parallelo.
    • Consigli:

      • Utilizza i metadati per determinare il ruolo di un nodo per eseguire in modo condizionale un'azione di inizializzazione sui nodi (vedi Utilizzo dei metadati del cluster).
      • Crea un fork di una copia di un'azione di inizializzazione in un bucket Cloud Storage per stabilire la stabilità (consulta la sezione Come vengono utilizzate le azioni di inizializzazione).
      • Aggiungi nuovi tentativi di download da Internet per stabilizzare l'azione di inizializzazione.

Utilizzo delle azioni di inizializzazione

Le azioni di inizializzazione dei cluster possono essere specificate indipendentemente da come crei un cluster:

Comando Gcloud

Quando crei un cluster con il comando gcloud dataproc clusters create, specifica una o più località (URI) Cloud Storage separate da virgole degli eseguibili o degli script di inizializzazione con il flag --initialization-actions. Nota: non sono supportati più valori "/" consecutivi in un URI della posizione Cloud Storage dopo l'iniziale "gs://", ad esempio "gs://bucket/my//object//name". Esegui gcloud dataproc clusters create --help per informazioni sul comando.

gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
    --initialization-action-timeout=timeout-value (default=10m) \
    ... other flags ...
Note:
  • Utilizza il flag --initialization-action-timeout per specificare un periodo di timeout per l'azione di inizializzazione. Il valore predefinito è 10 minuti. Se l'eseguibile o lo script di inizializzazione non sono stati completati entro la fine del periodo di timeout, Dataproc annulla l'azione di inizializzazione.
  • Utilizza la proprietà cluster dataproc:dataproc.worker.custom.init.actions.mode per eseguire l'azione di inizializzazione sui worker principali prima di avviare il gestore di nodi e i daemon di nodi dati.

API REST

Specifica uno o più script o eseguibili in un array ClusterConfig.InitializationActions come parte di una richiesta API clusters.create.

Esempio

POST /v1/projects/my-project-id/regions/us-central1/clusters/
{
  "projectId": "my-project-id",
  "clusterName": "example-cluster",
  "config": {
    "configBucket": "",
    "gceClusterConfig": {
      "subnetworkUri": "default",
      "zoneUri": "us-central1-b"
    },
    "masterConfig": {
      "numInstances": 1,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "workerConfig": {
      "numInstances": 2,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "initializationActions": [
      {
        "executableFile": "gs://cloud-example-bucket/my-init-action.sh"
      }
    ]
  }
}

Console

  • Apri la pagina Crea un cluster di Dataproc, quindi seleziona il riquadro Personalizza cluster.
  • Nella sezione Azioni di inizializzazione, inserisci la località del bucket Cloud Storage di ogni azione di inizializzazione nei campi File eseguibile. Fai clic su Sfoglia per aprire la pagina del browser di Cloud Storage della console Google Cloud e selezionare uno script o un file eseguibile. Fai clic su Aggiungi azione di inizializzazione per aggiungere ogni file.
  • Trasmettere argomenti alle azioni di inizializzazione

    Dataproc imposta valori speciali per i metadati per le istanze eseguite nei tuoi cluster. Puoi impostare metadati personalizzati come metodo per passare argomenti alle azioni di inizializzazione.

    gcloud dataproc clusters create cluster-name \
        --region=${REGION} \
        --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
        --metadata=name1=value1,name2=value2... \
        ... other flags ...
    

    I valori dei metadati possono essere letti all'interno delle azioni di inizializzazione come segue:

    var1=$(/usr/share/google/get_metadata_value attributes/name1)
    

    Selezione dei nodi

    Se vuoi limitare le azioni di inizializzazione ai nodi master o worker, puoi aggiungere una logica di selezione dei nodi semplice all'eseguibile o allo script.

    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
    if [[ "${ROLE}" == 'Master' ]]; then
      ... master specific actions ...
    else
      ... worker specific actions ...
    fi
    

    Gestione temporanea di programmi binari

    Uno scenario di inizializzazione comune del cluster è la gestione temporanea dei programmi binari di un cluster per eliminare la necessità di archiviare i programmi binari ogni volta che viene inviato un job. Ad esempio, supponiamo che il seguente script di inizializzazione sia archiviato in gs://my-bucket/download-job-jar.sh, ovvero un percorso del bucket Cloud Storage:

    #!/bin/bash
    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
    if [[ "${ROLE}" == 'Master' ]]; then
      gsutil cp gs://my-bucket/jobs/sessionalize-logs-1.0.jar home/username
    fi
    

    La posizione di questo script può essere passata al comando gcloud dataproc clusters create:

    gcloud dataproc clusters create my-dataproc-cluster \
        --region=${REGION} \
        --initialization-actions=gs://my-bucket/download-job-jar.sh
    

    Dataproc eseguirà questo script su tutti i nodi e, a seguito della logica di selezione dei nodi dello script, scaricherà il jar nel nodo master. I job inviati possono quindi utilizzare il jar pre-stage:

    gcloud dataproc jobs submit hadoop \
        --cluster=my-dataproc-cluster \
        --region=${REGION} \
        --jar=file:///home/username/sessionalize-logs-1.0.jar
    

    Esempi di azioni di inizializzazione

    Gli script delle azioni di inizializzazione usati e di altro tipo si trovano in gs://goog-dataproc-initialization-actions-<REGION>, nei bucket Cloud Storage pubblici a livello di regione e in un repository GitHub. Per contribuire con uno script, esamina il documento CONTRIBUTING.md, quindi presenta una richiesta di pull.

    Logging

    L'output dell'esecuzione di ogni azione di inizializzazione viene registrato per ogni istanza in /var/log/dataproc-initialization-script-X.log, dove X è l'indice in base zero di ogni script di azione di inizializzazione successivo. Ad esempio, se il cluster ha due azioni di inizializzazione, gli output verranno registrati in /var/log/dataproc-initialization-script-0.log e /var/log/dataproc-initialization-script-1.log.

    Passaggi successivi

    Esplora le azioni di inizializzazione di GitHub.