Azioni di inizializzazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Durante la creazione di un cluster Dataproc, puoi specificare le azioni di inizializzazione in eseguibili o script che Dataproc verrà eseguito su tutti i nodi del cluster Dataproc subito dopo la configurazione del cluster. Le azioni di inizializzazione spesso consentono la configurazione delle dipendenze dei job, come l'installazione di pacchetti Python, in modo da poter inviare i job al cluster senza dover installare dipendenze quando vengono eseguiti i job.

Puoi trovare script di azioni di inizializzazione di esempio nelle seguenti posizioni:

Considerazioni importanti e linee guida

  • Non creare cluster di produzione che fanno riferimento alle azioni di inizializzazione ubicate nei bucket pubblici gs://goog-dataproc-initialization-actions-REGION. Questi script vengono forniti come implementazioni di riferimento. Vengono sincronizzate con le modifiche in corso al repository GitHub. Una nuova versione di un'azione di inizializzazione in un bucket pubblico può interrompere la creazione del cluster. Copia invece l'azione di inizializzazione dal bucket pubblico al bucket, come mostrato nell'esempio seguente:

    REGION=region
    
    gsutil cp gs://goog-dataproc-initialization-actions-${REGION}/tez/tez.sh gs://my-bucket
    
    Quindi, crea il cluster facendo riferimento alla copia:
    gcloud dataproc clusters create cluster-name \
        --region=${REGION} \
        --initialization-actions=gs://my-bucket/tez.sh \
        ... other flags ...
    
    Puoi decidere quando sincronizzare la copia dell'azione di inizializzazione con eventuali modifiche all'azione di inizializzazione che si verificano nel bucket pubblico o nel repository GitHub.

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

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

  • Utilizza i percorsi assoluti nelle azioni di inizializzazione.

  • Utilizza una linea 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 riporterà 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, un tentativo di accesso a github.com su Internet in un'azione di inizializzazione avrà esito negativo se non hai configurato route per indirizzare il traffico tramite Cloud NAT o una Cloud VPN. Senza accesso a Internet, puoi abilitare l'accesso privato Google e posizionare le dipendenze dei job in Cloud Storage; i nodi cluster possono scaricare le dipendenze da Cloud Storage da IP interni.

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

  • Elaborazione dell'inizializzazione:

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

      • Principale: le azioni di inizializzazione del nodo master possono essere eseguite prima che l'HDFS sia scrivibile. Se esegui azioni di inizializzazione che eseguono lo stage dei file in HDFS o dipendono dalla disponibilità di servizi dipendenti da HDFS, ad esempio Ranger, imposta la dataproc.master.custom.init.actions.modeproprietà cluster 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 del cluster per i worker di cluster di immagini precedenti alla versione 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 trasferita al cluster al momento della creazione del cluster (non puoi modificare l'impostazione della proprietà). Ogni worker esegue le sue azioni di inizializzazione prima di avviare i daemon dei nodi dati HDFS e di gestore nodi YARN. 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:

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

Utilizzare le azioni di inizializzazione

Le azioni di inizializzazione del 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ù posizioni URI di Cloud Storage (URI) separate degli eseguibili o degli script di inizializzazione con il flag --initialization-actions. Nota: non sono supportati più elenchi consecutivi in un URI di posizione di Cloud Storage dopo l'iniziale "gs://", ad esempio "gs://bucket/my//object//name". Esegui gcloud dataproc clusters create --help per le informazioni sui comandi.

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 è stato completato entro la fine del periodo di timeout, Dataproc annulla l'azione di inizializzazione.
  • Utilizza la proprietà del cluster dataproc:dataproc.worker.custom.init.actions.mode per eseguire l'azione di inizializzazione sui worker principali prima dell'avvio dei daemon di gestore di nodi e datanode.

API REST

Specifica uno o più script o eseguibili in un array ClusterConfig.initializationAction 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 Dataproc e 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 Cloud Storage di Google Cloud Console 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 delle istanze eseguite nei tuoi cluster. Puoi impostare metadati personalizzati come metodo per trasmettere 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 o worker, puoi aggiungere una logica di selezione dei nodi semplice al tuo eseguibile o 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 dei programmi binari

    Uno scenario di inizializzazione comune del cluster è la gestione temporanea dei programmi binari del job su un cluster per eliminare la necessità di gestire temporaneamente 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, una località 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 trasferita 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, in conseguenza della logica di selezione del nodo 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 di azione di inizializzazione e di uso frequente si trovano in gs://goog-dataproc-initialization-actions-<REGION>, un bucket Cloud Storage pubblico a livello di regione e in un repository GitHub. Per inviare uno script, rivedi il documento CONTRIBUTING.md e poi 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 a 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.