Cuando creas un clúster de Dataproc, puedes especificar acciones de inicialización en ejecutables o secuencias de comandos que Dataproc ejecutará en todos los nodos en tu clúster de Dataproc inmediatamente después de configurar el clúster. A menudo, las acciones de inicialización configuran dependencias de trabajo, como la instalación de paquetes de Python, para que los trabajos puedan enviarse al clúster sin tener que instalar dependencias cuando se ejecutan los trabajos.
Puedes encontrar secuencias de comandos de acciones de inicialización de ejemplo en las siguientes ubicaciones: Nota: Google no admite estos ejemplos.
- Repositorio de GitHub
- Cloud Storage: en el entorno regional
gs://goog-dataproc-initialization-actions-REGION
buckets públicos
Consideraciones y lineamientos importantes
No crees clústeres de producción que hagan referencia acciones de inicialización y configuración ubicadas en el
gs://goog-dataproc-initialization-actions-REGION
buckets públicos. Estas secuencias de comandos se proporcionan como implementaciones de referencia. Ellas se sincronizan con cambios en curso en el repositorio de GitHub y las actualizaciones las secuencias de comandos pueden afectar la creación del clúster. En cambio, copia la acción de inicialización de el bucket público en una carpeta de bucket de Cloud Storage con versión, como se muestra en el siguiente ejemplo: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...
Las acciones de inicialización se ejecutan en cada nodo en serie durante la creación del clúster. Ellas también se ejecutan en cada nodo agregado cuando escalamiento o ajuste de escala automático se agrupan en clústeres.
Cuando actualizas acciones de inicialización, por ejemplo, cuando sincronizas tus Acciones de inicialización de Cloud Storage para los cambios realizados en el bucket público o de inicialización del repositorio de GitHub, crea un archivo con nombre de la versión) para recibir las acciones de inicialización actualizadas. En cambio, si actualizas la acción de inicialización en el lugar, los nodos nuevos, como los agregados por el escalador automático, ejecutarán la inicialización no la acción de inicialización de la versión anterior que se ejecutaba nodos. Estas diferencias en las acciones de inicialización pueden generar nodos del clúster rotos.
Las acciones de inicialización se ejecutan como el usuario
root
. No es necesario que usessudo
.Usa rutas de acceso absolutas en las acciones de inicialización.
Usa un línea shebang en las acciones de inicialización para indicar cómo debe interpretarse el script (por ejemplo,
#!/bin/bash
o#!/usr/bin/python
).Si una acción de inicialización termina con un código de salida que no es cero, la operación de creación del clúster presentará un estado de "ERROR". Cómo depurar la inicialización acción, usar SSH para conectarse a las instancias de VM del clúster y, luego, examinar el registros. Luego de solucionar el problema de la acción de inicialización, puedes borrar y, luego, volver a crear el clúster.
Si creas un clúster de Dataproc con solo direcciones IP internas intenta acceder a
github.com
a través de Internet en una acción de inicialización fallarán a menos que hayas configurado rutas para dirigir el tráfico Cloud NAT o Cloud VPN. Sin acceso a Internet, puedes habilitar Acceso privado a Google y colocar las dependencias de trabajos en Cloud Storage. los nodos del clúster pueden descargar las dependencias de Cloud Storage IP internas.Puedes usar imágenes personalizadas de Dataproc en vez de acciones de inicialización para configurar dependencias de trabajos.
Procesamiento de inicialización:
- Clústeres de imágenes anteriores a la versión 2.0:
- Principal: Permite que las acciones de inicialización se ejecuten en instancias principales. para escribir archivos en HDFS, las acciones de inicialización del nodo principal no comienzan hasta HDFS se puede escribir (hasta que HDFS haya salido del modo seguro y al menos dos HDFS DataNodes).
- Worker: Si configuras la opción
dataproc:dataproc.worker.custom.init.actions.mode
propiedad del clúster aRUN_BEFORE_SERVICES
, cada trabajador ejecuta su acciones de inicialización antes de que inicien su datanode HDFS y YARN daemons de nodemanager. Dataproc no ejecuta acciones de inicialización de la instancia principal hasta que HDFS admite operaciones de escritura, lo que requiere que se ejecuten 2 daemons de datanode de HDFS, configurar esta propiedad puede aumentar el tiempo de creación del clúster.
Clústeres de imágenes posteriores a la versión 2.0:
- Instancia principal: Las acciones de inicialización del nodo principal pueden ejecutarse antes de que se pueda escribir en HDFS. Si ejecutas acciones de inicialización que habilitan por etapas archivos en HDFS o que dependen de la disponibilidad de los servicios dependientes de HDFS, como Ranger, configura la propiedad del clúster
dataproc.master.custom.init.actions.mode
enRUN_AFTER_SERVICES
. Nota: Como este de la propiedad puede aumentar el tiempo de creación del clúster. Consulta el explicación del retraso en la creación de clústeres Trabajadores de clústeres de imágenes anteriores a la versión 2.0: úsala solo cuando sea necesario (como práctica general, confía en la configuración la configuraciónRUN_BEFORE_SERVICES
de esta propiedad). - Trabajador: el
dataproc:dataproc.worker.custom.init.actions.mode
propiedad del clúster se establece enRUN_BEFORE_SERVICES
y no se puede pasar al clúster cuando se crea (no puedes cambiar la configuración de la propiedad). Cada trabajador ejecuta sus acciones de inicialización antes de iniciar su datanode HDFS y daemons de nodemanager de YARN. Debido a que Dataproc no espera a que HDFS se pueda escribir antes de ejecutar las acciones de inicialización de la instancia principal, las acciones de inicialización de la instancia principal y del trabajador se ejecutan en paralelo.
- Instancia principal: Las acciones de inicialización del nodo principal pueden ejecutarse antes de que se pueda escribir en HDFS. Si ejecutas acciones de inicialización que habilitan por etapas archivos en HDFS o que dependen de la disponibilidad de los servicios dependientes de HDFS, como Ranger, configura la propiedad del clúster
Recomendaciones:
- Usa metadatos para determinar la función de un nodo a fin de ejecutar forma condicional una acción de inicialización en ellos (consulta Usa metadatos del clúster).
- Bifurca una copia de una acción de inicialización en un bucket de Cloud Storage a fin de lograr estabilidad (consulta Cómo se usan las acciones de inicialización).
- Agrega reintentos cuando descargues de Internet para ayudar a estabilizar la acción de inicialización.
- Clústeres de imágenes anteriores a la versión 2.0:
Usa acciones de inicialización
Las acciones de inicialización del clúster se pueden especificar independientemente de cómo creas el clúster:
- A través de la consola de Google Cloud
- Con la CLI de gcloud
- De manera programática con la API clusters.create de Dataproc (consulta NodeInitializationAction)
Comando de gcloud
Cuando creas un clúster con el
gcloud dataproc clusters create
especifica una o más ubicaciones de Cloud Storage (URI) separadas por comas
de los ejecutables o secuencias de comandos de inicialización con el
--initialization-actions
. Nota: Varios "/" consecutivos en un URI de ubicación de Cloud Storage después del "gs://" inicial, como "gs://bucket/my//object//name", no son compatibles. Ejecutar
gcloud dataproc clusters create --help
para la información del 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 ...Notas:
- Usa la marca
--initialization-action-timeout
a fin de especificar un tiempo de espera para la acción de inicialización. El tiempo de espera predeterminado es de 10 minutos. Si el ejecutable o la secuencia de comandos de inicialización no se completó al final del tiempo de espera, Dataproc cancela la acción de inicialización. - Usa la propiedad de clúster
dataproc:dataproc.worker.custom.init.actions.mode
para ejecutar la acción de inicialización en los trabajadores principales antes de que se inicien el administrador de nodos y los daemons de datanode.
API de REST
Especifica uno o más ejecutables o secuencias de comandos en un array ClusterConfig.initializationActions como parte de una solicitud a la API clusters.create.
Ejemplo
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
Aplica argumentos a las acciones de inicialización
Dataproc establece valores especiales de metadatos para las instancias que se ejecutan en tus clústeres. Puedes configurar tus propios metadatos personalizados como una forma de aplicar argumentos a las acciones de inicialización.
gcloud dataproc clusters create cluster-name \ --region=${REGION} \ --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \ --metadata=name1=value1,name2=value2... \ ... other flags ...
Los valores de metadatos se pueden leer dentro de las acciones de inicialización de la siguiente manera:
var1=$(/usr/share/google/get_metadata_value attributes/name1)
Selección de nodos
Si quieres limitar las acciones de inicialización a nodos principales, controladores o trabajadores, puedes agregar de selección de nodos simple a tu ejecutable o secuencia de comandos.
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
Staging de binarios
Una situación de inicialización del clúster común es la etapa de pruebas de los binarios de trabajo en un clúster para eliminar la necesidad de habilitar a etapa los binarios cada vez que se envía un trabajo. Por ejemplo, supongamos que la siguiente secuencia de comandos de inicialización se almacena en
gs://my-bucket/download-job-jar.sh
, un bucket de Cloud Storage
ubicación:
#!/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 ubicación de esta secuencia de comandos puede pasarse 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 ejecutará esta secuencia de comandos en todos los nodos y, como consecuencia de la lógica de selección de nodos de la secuencia de comandos, descargará el jar al nodo principal. Por lo tanto, los trabajos enviados pueden usar el jar previo a la etapa de pruebas:
gcloud dataproc jobs submit hadoop \ --cluster=my-dataproc-cluster \ --region=${REGION} \ --jar=file:///home/username/sessionalize-logs-1.0.jar
Muestras de acciones de inicialización
Las secuencias de comandos de acciones de inicialización de uso frecuente y otros ejemplos se ubican en gs://goog-dataproc-initialization-actions-<REGION>
, un depósito público regional de Cloud Storage, y en un repositorio de GitHub.
Para contribuir a una secuencia de comandos, revisa el documento CONTRIBUTING.md
y, a continuación, presenta una solicitud de extracción.
Logging
El resultado de la ejecución de cada acción de inicialización se registra para cada instancia en /var/log/dataproc-initialization-script-X.log
; X
es el índice basado en cero de cada secuencia de comandos de acción de inicialización sucesiva. Por ejemplo, si tu clúster tiene dos acciones de inicialización, los resultados se registrarán en /var/log/dataproc-initialization-script-0.log
y /var/log/dataproc-initialization-script-1.log
.
¿Qué sigue?
Explora las acciones de inicialización de GitHub.