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 cluster Dataproc subito dopo la configurazione del cluster. Le azioni di inizializzazione spesso configurano dipendenze dei job, ad esempio l'installazione di pacchetti Python, in modo che i job possano essere inviati al cluster senza dover installare dipendenze quando vengono eseguiti i job.

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

• Repository GitHub
• Cloud Storage: nei bucket pubblici gs://goog-dataproc-initialization-actions-REGION a livello di regione

Considerazioni e linee guida importanti

• Non creare cluster di produzione che fanno riferimento alle azioni di inizializzazione situate nei bucket pubblici gs://goog-dataproc-initialization-actions-REGION. Questi script vengono forniti come implementazioni di riferimento. Vengono sincronizzati con le modifiche in corso al repository GitHub e gli aggiornamenti a questi script possono interrompere la creazione del cluster. Copia invece l'azione di inizializzazione dal bucket pubblico in una cartella del bucket Cloud Storage sottoposto al controllo delle versioni, 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 in serie durante la creazione del cluster. Vengono eseguite anche su ciascun 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 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 atto, i nuovi nodi, come quelli aggiunti dal gestore della 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 cluster incoerenti o non funzionanti.

• 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à lo 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 ricreare il cluster.

• Se crei un cluster Dataproc con solo indirizzi IP interni, i tentativi di accedere a github.com su internet durante un'azione di inizializzazione non riusciranno, a meno che tu non abbia configurato route per indirizzare il traffico tramite Cloud NAT o Cloud VPN. Senza l'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 da IP interni.

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

• Elaborazione di inizializzazione:

  • Cluster di immagini precedenti alla versione 2.0:
    • Master: 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 finché HDFS non è scrivibile (fino a quando HDFS non è uscito da modalità provvisoria e almeno due DataNode HDFS non sono stati uniti).
    • Worker: se imposti la dataproc:dataproc.worker.custom.init.actions.mode proprietà cluster su RUN_BEFORE_SERVICES, ogni worker esegue le azioni di inizializzazione prima di avviare i relativi daemon datanode HDFS e YARN nodemanager. Poiché Dataproc non esegue azioni di inizializzazione master finché HDFS non è scrivibile, il che richiede l'esecuzione di due daemon datanode HDFS, l'impostazione di questa proprietà potrebbe aumentare i tempi di creazione del cluster.

  • Cluster di immagini 2.0+:

    • Master: le azioni di inizializzazione del nodo master possono essere eseguite prima che sia scrivibile HDFS. Se esegui azioni di inizializzazione che eseguono lo stage in HDFS o dipendono dalla disponibilità dei servizi dipendenti da HDFS, come Ranger, imposta la proprietà cluster dataproc.master.custom.init.actions.mode su RUN_AFTER_SERVICES. Nota: poiché questa impostazione della proprietà può aumentare i tempi di creazione del cluster (consulta la spiegazione del ritardo di creazione del cluster per i worker di cluster immagini precedenti alla versione 2.0), utilizzala solo se necessario (come prassi generale, affidati all'impostazione RUN_BEFORE_SERVICES predefinita per questa proprietà).
    • Worker: la proprietà cluster dataproc:dataproc.worker.custom.init.actions.mode è impostata su RUN_BEFORE_SERVICES e non può essere trasmessa al cluster al momento della sua creazione (non puoi modificare l'impostazione della proprietà). Ogni worker esegue le azioni di inizializzazione prima di avviare i daemon datanode HDFS e Nodemanager YARN. Poiché Dataproc non attende che HDFS sia scrivibile prima di eseguire le azioni di inizializzazione master, le azioni di inizializzazione master e 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 un fork di una copia di un'azione di inizializzazione in un bucket Cloud Storage per una maggiore stabilità (consulta Come vengono utilizzate le azioni di inizializzazione).
    • Aggiungi nuovi tentativi 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 da come crei un cluster:

• Mediante la console Google Cloud
• Utilizzo di gcloud CLI
• A livello di programmazione con l'API clusters.create Dataproc (vedi NodeInitializationAction)

Comando gcloud

Quando crei un cluster con il comando gcloud dataproc clusters create, specifica una o più località Cloud Storage (URI) separate da virgole degli eseguibili o degli script di inizializzazione con il flag --initialization-actions. Nota: non sono supportate più "/" consecutive 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 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 di timeout predefinito è 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 proprietà cluster dataproc:dataproc.worker.custom.init.actions.mode per eseguire l'azione di inizializzazione sui worker principali prima dell'avvio del gestore dei nodi e dei daemon dei nodi dati.

Consenti alla console Google Cloud di costruire la richiesta di creazione del cluster. Puoi fare clic sui link REST equivalente o riga di comando nella parte inferiore del riquadro sinistro della pagina Crea un cluster di Dataproc per fare in modo che la console Google Cloud crei una richiesta REST dell'API o il comando dello strumento gcloud equivalente. Nota: la console Google Cloud non include il campo dell'API REST executionTimeout o il flag --initialization-action-timeout di Google Cloud CLI.

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"
      }
    ]
  }
}

Consenti alla console Google Cloud di creare la tua richiesta di creazione del cluster.: Puoi fare clic sui link API REST o riga di comando equivalente nella parte inferiore del riquadro sinistro della pagina Crea un cluster di Dataproc per fare in modo che la console Google Cloud crei una richiesta REST API o il comando dello strumento gcloud equivalente. Nota: la console Google Cloud non include il campo REST executionTimeout o il flag --initialization-action-timeout di Google Cloud CLI.

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 Browser Cloud Storage della console Google Cloud e selezionare uno script o un file eseguibile. Fai clic su Aggiungi azione di inizializzazione per aggiungere ciascun file.

Passaggio di argomenti alle azioni di inizializzazione

Dataproc imposta valori speciali dei metadati per le istanze in esecuzione nei cluster. Puoi impostare i tuoi metadati personalizzati come modo 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 del nodo

Se vuoi limitare le azioni di inizializzazione ai nodi master, driver o worker, puoi aggiungere una 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

Gestione temporanea dei programmi binari

Uno scenario comune di inizializzazione del cluster è la gestione temporanea dei programmi binari dei job su 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, 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 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à lo script su tutti i nodi e, come conseguenza della logica di selezione dei nodi dello script, scaricherà il jar nel nodo master. I job inviati possono quindi utilizzare il jar nella fase preliminare:

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 di esempio si trovano in gs://goog-dataproc-initialization-actions-<REGION>, in un bucket Cloud Storage pubblico a livello di regione e in un repository GitHub. Per contribuire a uno script, esamina il documento di CONTRIBUTING.md e 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 azioni di inizializzazione successivo. Ad esempio, se il cluster ha due azioni di inizializzazione, gli output verranno registrati su /var/log/dataproc-initialization-script-0.log e /var/log/dataproc-initialization-script-1.log.

Passaggi successivi

Esplora le azioni di inizializzazione di GitHub.