Azioni di inizializzazione

Quando crei un cluster Dataproc, puoi specificare le azioni di inizializzazione negli eseguibili o negli script che Dataproc eseguirà su tutti i nodi del tuo cluster Dataproc immediatamente dopo la configurazione del cluster. Le azioni di inizializzazione spesso configurano come l'installazione di pacchetti Python, in modo che i job possano essere inviati al cluster senza dover installare dipendenze durante l'esecuzione dei job.

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 alle azioni di inizializzazione situate nei bucket pubblicigs://goog-dataproc-initialization-actions-REGION. Questi script vengono forniti come implementazioni di riferimento. I script vengono 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 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 in serie su ciascun nodo durante la creazione del cluster. Vengono inoltre eseguiti su ogni nodo aggiunto quando si esegue lo scale up o la scalabilità automatica dei cluster.

  • Quando aggiorni le azioni di inizializzazione, ad esempio quando sincronizzi le tue Azioni di inizializzazione di Cloud Storage alle modifiche apportate al bucket pubblico di inizializzazione del repository GitHub, crea una nuova con nome versione) per ricevere le azioni di inizializzazione aggiornate. Se, invece, aggiorni l'azione di inizializzazione attiva, nuovi nodi, quelli aggiunti dal gestore della scalabilità automatica, eseguiranno l'inizializzazione aggiornata dell'applicazione, non l'azione di inizializzazione della versione precedente eseguita su applicazioni nodi. Queste differenze nelle azioni di inizializzazione possono comportare nodi del cluster incoerenti o inaccessibili.

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

  • Utilizza percorsi assoluti nelle azioni di inizializzazione.

  • Utilizza un shebang line 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 registrerà uno stato "ERROR". Per eseguire il debug dell'inizializzazione usa SSH per connetterti alle istanze VM del cluster, quindi esamina log. Dopo aver risolto il problema relativo all'azione di inizializzazione, puoi eliminare e ricreare il cluster.

  • Se crei un cluster Dataproc con solo indirizzi IP interni, tenta di accedere a github.com su internet in un'azione di inizializzazione avrà esito negativo se non sono state configurate route per indirizzare il traffico Cloud NAT o Cloud VPN. Senza accesso a internet, puoi attivare l'accesso privato Google e inserire le dipendenze dei job in Cloud Storage. I nodi del cluster possono scaricare le dipendenze da Cloud Storage da IP interni.

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

  • Elaborazione dell'inizializzazione:

    • Cluster di immagini precedenti alla versione 2.0:
      • Principale: per consentire l'esecuzione delle azioni di inizializzazione sui master. per scrivere file su HDFS, le azioni di inizializzazione del nodo master non vengono avviate HDFS è scrivibile (fino all'uscita di HDFS in modalità provvisoria e ad almeno due HDFS DataNodes si è unito).
      • Worker: se imposti la proprietà del cluster dataproc:dataproc.worker.custom.init.actions.mode su RUN_BEFORE_SERVICES, ogni worker esegue le sue azioni di inizializzazione prima di avviare i demoni del datanode HDFS e del nodemanager YARN. Dato che Dataproc non esegue il master di inizializzazione finché HDFS non è scrivibile, che richiede l'esecuzione di 2 daemon datanode HDFS, impostando questa proprietà potrebbe aumentare i tempi di creazione del cluster.

    • Cluster di immagini 2.0 e versioni successive:

      • Master: le azioni di inizializzazione del nodo master possono essere eseguite prima HDFS è scrivibile. Se esegui azioni di inizializzazione che eseguono il 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à 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 se necessario (come regola generale, utilizza l'impostazione predefinita RUN_BEFORE_SERVICES per questa proprietà).
      • Worker: dataproc:dataproc.worker.custom.init.actions.mode proprietà cluster è impostato su RUN_BEFORE_SERVICES e non può essere passato al cluster quando questo viene creato (non puoi modificare l'impostazione della proprietà). Ogni worker esegue le proprie azioni di inizializzazione prima di avviare i demoni DataNode HDFS e NodeManager YARN. Dataproc non attende che HDFS sia scrivibile prima di eseguire azioni di inizializzazione master, le azioni di inizializzazione vengono eseguite in parallelo.

    • Consigli:

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

Utilizzo delle azioni di inizializzazione

Le azioni di inizializzazione del cluster possono essere specificate indipendentemente dal modo in cui viene creato un cluster:

Comando gcloud

Quando crei un cluster gcloud dataproc clusters create , specifica una o più località Cloud Storage (URI) separate da virgole degli eseguibili o degli script di inizializzazione con Flag --initialization-actions. Nota: non sono supportati più "/" consecutivi in un URI della posizione di Cloud Storage dopo "gs://" iniziale, ad esempio "gs://bucket/my//object//name". Corsa gcloud dataproc clusters create --help per le 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
  • Usa --initialization-action-timeout per specificare un periodo di timeout per l'inizializzazione un'azione. Il valore predefinito di timeout è 10 minuti. Se lo script o l'eseguibile 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à cluster per eseguire l'azione di inizializzazione sui worker principali prima dell'avvio dei demoni node manager e datanode.

API REST

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

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 Dataproc Crea un cluster e seleziona il riquadro Personalizza cluster.
  • Nella sezione Azioni di inizializzazione, inserisci la posizione del bucket Cloud Storage di ogni azione di inizializzazione nei campi File eseguibile. Fai clic su Sfoglia per aprire il browser di Cloud Storage della console Google Cloud. per selezionare uno script o un file eseguibile. Fai clic su Aggiungi azione di inizializzazione per aggiungere ogni file.

    • Passaggio di argomenti alle azioni di inizializzazione

    Dataproc imposta metadati speciali per le istanze in esecuzione nei cluster. Puoi impostare metadati personalizzati 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, driver o worker, puoi aggiungere semplice 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

    Programmi binari nella gestione temporanea

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

    #!/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 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, in base alla logica di selezione dei nodi dello script, scaricherà il file JAR sul nodo master. I job inviati possono quindi utilizzare il jar con fasi iniziali:

    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 utilizzati di frequente e altri esempi di azioni di inizializzazione si trovano in gs://goog-dataproc-initialization-actions-<REGION>, un cloud pubblico a livello di regione nei bucket Cloud Storage, Repository GitHub. Per contribuire con uno script, esamina il documento CONTRIBUTING.md e poi invia una pull request.

    Logging

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

    Passaggi successivi

    Scopri le azioni di inizializzazione di GitHub.