Azioni di inizializzazione

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

Puoi trovare script di azioni di inizializzazione di esempio nelle seguenti posizioni: Nota: Google non supporta questi esempi.

Considerazioni e linee guida importanti

  • Non creare cluster di produzione che fanno riferimento ad azioni di inizializzazione che si trovano 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 di questi script possono interrompere la creazione del cluster. Copia invece l'azione di inizializzazione da il bucket pubblico in una cartella del bucket Cloud Storage con controllo delle versioni, come mostrato in nell'esempio seguente: 

    REGION=COMPUTE_REGION
gcloud storage 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 ogni nodo in sequenza durante la creazione del cluster. Vengono eseguite anche su ogni nodo aggiunto quando si esegue lo scale up o lo scale up automatico dei cluster.

  • Quando aggiorni le azioni di inizializzazione, ad esempio quando sincronizzi le azioni di inizializzazione di Cloud Storage con le modifiche apportate alle azioni di inizializzazione del bucket pubblico o del repository GitHub, crea una nuova cartella (preferibilmente con il nome della versione) per ricevere le azioni di inizializzazione aggiornate. Se invece aggiorni l'azione di inizializzazione in loco, i nuovi nodi, ad esempio quelli aggiunti dallo strumento di scalabilità automatica, eseguiranno l'azione di inizializzazione aggiornata in loco, non l'azione di inizializzazione della versione precedente eseguita sui nodi esistenti. Queste differenze nelle azioni di inizializzazione possono causare nodi del cluster incoerenti o danneggiati.

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

  • Utilizza percorsi assoluti nelle azioni di inizializzazione.

  • Utilizza una riga shebang nelle azioni di inizializzazione per indicare come deve essere interpretato 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 dell'azione di inizializzazione, puoi eliminare e poi ricreare il cluster.

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

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

  • Elaborazione dell'inizializzazione:

    • Cluster di immagini precedenti alla versione 2.0:
      • Master: per consentire alle azioni di inizializzazione eseguite sui master di scrivere file in HDFS, le azioni di inizializzazione dei nodi master non vengono avviate finché HDFS non è scrivibile (finché HDFS non esce dalla modalità provvisoria e non sono stati aggiunti almeno due DataNode HDFS).
      • Worker: se imposti la dataproc:dataproc.worker.custom.init.actions.mode proprietà del cluster su RUN_BEFORE_SERVICES, ogni worker esegue le azioni di inizializzazione prima di avviare i daemon HDFS datanode e YARN nodemanager. Poiché Dataproc non esegue le azioni di inizializzazione del master finché HDFS non è scrivibile, il che richiede l'esecuzione di 2 daemon HDFS datanode, l'impostazione di questa proprietà potrebbe aumentare il tempo di creazione del cluster.

    • Cluster di immagini versione 2.0 e successive:

      • Master: le azioni di inizializzazione dei nodi master potrebbero essere eseguite prima che HDFS sia scrivibile. Se esegui azioni di inizializzazione che eseguono lo staging dei file in HDFS o dipendono dalla disponibilità di servizi dipendenti da HDFS, come Ranger, imposta la dataproc.master.custom.init.actions.mode proprietà del cluster su RUN_AFTER_SERVICES. Nota: poiché l'impostazione di questa proprietà può aumentare il tempo di creazione del cluster (vedi la spiegazione del ritardo nella creazione del cluster per i worker dei cluster di immagini precedenti alla versione 2.0), utilizzala solo quando necessario (come prassi generale, fai affidamento sull'impostazione predefinita RUN_BEFORE_SERVICES 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 durante la creazione (non puoi modificare l'impostazione della proprietà). Ogni worker esegue le azioni di inizializzazione prima di avviare i daemon HDFS datanode e YARN nodemanager. Poiché Dataproc non attende che HDFS sia scrivibile prima di eseguire le azioni di inizializzazione del master, le azioni di inizializzazione del master e del worker vengono eseguite in parallelo.

    • Consigli:

Utilizzare le azioni di inizializzazione

Le azioni di inizializzazione del cluster possono essere specificate indipendentemente dalla modalità di creazione del cluster:

Interfaccia a riga di comando gcloud

Quando crei un cluster con il comando gcloud dataproc clusters create, specifica una o più località (URI) di Cloud Storage separate da virgole degli eseguibili o degli script di inizializzazione con il --initialization-actions flag. Nota: più "/" consecutivi in un URI di località di Cloud Storage dopo "gs://", ad esempio "gs://bucket/my//object//name", non sono supportati. 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 --initialization-action-timeout flag per specificare un periodo di timeout per l'azione di inizializzazione. Il valore di timeout predefinito è di 10 minuti. Se l'eseguibile o lo script di inizializzazione non è stato completato entro la fine del periodo di timeout, Dataproc annulla l'azione di inizializzazione.
  • Utilizza la dataproc:dataproc.worker.custom.init.actions.mode proprietà del cluster per eseguire l'azione di inizializzazione sui worker principali prima dell'avvio dei daemon del gestore dei nodi e dei nodi dati.

API REST

Specifica uno o più script o eseguibili in un ClusterConfig.initializationActions 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 Google Cloud pagina del browser di Cloud Storage della console per selezionare un file di script o eseguibile. Fai clic su Aggiungi azione di inizializzazione per aggiungere ogni file.

    • Passare argomenti alle azioni di inizializzazione

    Dataproc imposta valori di metadati speciali per le istanze in esecuzione nei cluster. Puoi impostare i tuoi metadati personalizzati per passare gli 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 nel seguente modo:

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

    Selezione dei nodi

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

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

    Eseguire lo staging dei programmi binari

    Uno scenario comune di inizializzazione del cluster è lo staging dei programmi binari dei job su un cluster per eliminare la necessità di eseguire lo staging dei programmi binari ogni volta che viene inviato un job è inviato. Ad esempio, supponiamo che il seguente script di inizializzazione sia archiviato in gs://my-bucket/download-job-jar.sh, una località del bucket Cloud Storage:

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

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

    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, di conseguenza della logica di selezione dei nodi dello script , scaricherà il file JAR nel nodo master. I job inviati possono quindi utilizzare il file JAR pre-staging:

    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 di azioni di inizializzazione utilizzati di frequente e altri di esempio si trovano in gs://goog-dataproc-initialization-actions-<REGION>, un bucket Cloud Storage pubblico regionale, e in un repository GitHub. Per contribuire con uno script, esamina il CONTRIBUTING.md documento, quindi invia 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.