Durante la creazione di un cluster Dataproc, puoi specificare le azioni di inizializzazione negli eseguibili o negli script che Dataproc essere eseguiti immediatamente su tutti i nodi nel tuo cluster Dataproc 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 esempi di script di azioni di inizializzazione nelle seguenti posizioni: Nota: Google non supporta questi esempi.
- Repository GitHub
- Cloud Storage: nella regione
gs://goog-dataproc-initialization-actions-REGION
bucket pubblici
Considerazioni e linee guida importanti
Non creare cluster di produzione che fanno riferimento di inizializzazione che si trovano
gs://goog-dataproc-initialization-actions-REGION
dei bucket pubblici. Questi script vengono forniti come implementazioni di riferimento. Loro vengono sincronizzati con le modifiche in corso al repository GitHub e gli aggiornamenti 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
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. Loro vengono eseguite anche su ciascun nodo aggiunto scalabilità o scalabilità automatica di cluster in esecuzione.
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. Tali differenze nelle azioni di inizializzazione possono generare nodi cluster danneggiati.
Le azioni di inizializzazione vengono eseguite come utente
root
. Non è necessario utilizzaresudo
.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, il cluster l'operazione di creazione segnalerà un "ERRORE" . Per eseguire il debug dell'inizializzazione usa SSH per connetterti alle istanze VM del cluster, quindi esamina log. Dopo aver risolto il problema dell'azione di inizializzazione, puoi eliminare e ricreare nel 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 l'accesso a internet, puoi attivare Accesso privato Google e collocare le dipendenze del job in Cloud Storage; di nodi cluster possono scaricare le dipendenze da Cloud Storage e IP interni.Puoi utilizzare la modalità Immagini personalizzate Dataproc anziché azioni di inizializzazione per configurare le dipendenze del 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 il valore
dataproc:dataproc.worker.custom.init.actions.mode
proprietà cluster aRUN_BEFORE_SERVICES
, ogni worker esegue di inizializzazione prima di avviare il datanode HDFS e YARN daemon nodemanager. 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 o versioni successive:
- Master: le azioni di inizializzazione del nodo master possono essere eseguite prima
HDFS è scrivibile. Se esegui azioni di inizializzazione che fasi
o dipendono dalla disponibilità di servizi che dipendono da HDFS,
come Ranger, imposta
dataproc.master.custom.init.actions.mode
proprietà cluster aRUN_AFTER_SERVICES
. Nota: poiché dell'impostazione della proprietà può aumentare i tempi di creazione del cluster: spiegazione del ritardo nella creazione del cluster Worker cluster di immagini precedenti alla versione 2.0: utilizzali solo se necessario (come prassi generale, fare affidamento sulleRUN_BEFORE_SERVICES
per questa proprietà). - Worker:
dataproc:dataproc.worker.custom.init.actions.mode
proprietà cluster è impostato suRUN_BEFORE_SERVICES
e non può essere passato al cluster quando questo viene creato (non puoi modificare l'impostazione della proprietà). Ogni worker esegue la sua inizializzazione prima di avviare i daemon 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.
- Master: le azioni di inizializzazione del nodo master possono essere eseguite prima
HDFS è scrivibile. Se esegui azioni di inizializzazione che fasi
o dipendono dalla disponibilità di servizi che dipendono da HDFS,
come Ranger, imposta
Consigli:
- Usa i metadati per determinare il ruolo di un nodo ed eseguire in modo condizionale 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 della stabilità (vedi Come eseguire le azioni di inizializzazione vengono utilizzati).
- Aggiungi nuovi tentativi durante il download da internet per contribuire alla stabilizzazione l'azione di inizializzazione.
- Cluster di immagini precedenti alla versione 2.0:
Utilizzo delle azioni di inizializzazione
Le azioni di inizializzazione del cluster possono essere specificate indipendentemente da come crei un cluster:
- Tramite la console Google Cloud
- Utilizzo di gcloud CLI
- In modo programmatico con l'API Dataproc clusters.create (vedi NodeInitializationAction)
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: più video consecutivi
"/" nell'URI di una posizione di Cloud Storage dopo "gs://", ad esempio
"gs://bucket/my//object//name" non sono supportati. 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 il file eseguibile di inizializzazione lo script non sia stato completato entro la fine del periodo di timeout, Dataproc annulla l'azione di inizializzazione. -
Usa
dataproc:dataproc.worker.custom.init.actions.mode
proprietà cluster per eseguire l'azione di inizializzazione sui worker principali prima dell'avvio del gestore nodi e dei daemon 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
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 durante le azioni di inizializzazione, come descritto di seguito:
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 cluster comune è la gestione temporanea dei file binari dei job su un
per eliminare la necessità di posizionare i file binari ogni volta che viene eseguito
inviate. 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
Il percorso di questo script può essere passato
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, come conseguenza del logica di selezione dei nodi dello script scaricherà il jar nel nodo master. I job inviati possono quindi utilizzare il jar con preparazione 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 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, consulta l'articolo
CONTRIBUTING.md
documento di identità, quindi invia una richiesta di pull.
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.