Cuando crees un clúster de Dataproc, puedes especificar acciones de inicialización en archivos ejecutables o secuencias de comandos que Dataproc ejecutará en todos los nodos de tu clúster de Dataproc inmediatamente después de configurar el clúster. Las acciones de inicialización suelen configurar dependencias de tareas, como instalar paquetes de Python, para que las tareas se puedan enviar al clúster sin tener que instalar dependencias cuando se ejecuten.
Puedes encontrar secuencias de comandos de ejemplo de acciones de inicialización en las siguientes ubicaciones: Nota: Google no ofrece asistencia para estos ejemplos.
- Repositorio de GitHub
- Cloud Storage: en los segmentos públicos regionales
gs://goog-dataproc-initialization-actions-REGION
Consideraciones y directrices importantes
No cree clústeres de producción que hagan referencia a acciones de inicialización ubicadas en los
gs://goog-dataproc-initialization-actions-REGION
contenedores públicos. Estas secuencias de comandos se proporcionan como implementaciones de referencia. Se sincronizan con los cambios que se producen en los repositorios de GitHub y, si se actualizan, pueden interrumpir la creación del clúster. En su lugar, copia la acción de inicialización del segmento público en una carpeta de un segmento de Cloud Storage versionado, como se muestra en el siguiente ejemplo: A continuación, crea el clúster haciendo referencia a la copia de Cloud Storage: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. También se ejecutan en cada nodo añadido cuando se amplían los clústeres escalado o autoescalado.
Cuando actualices las acciones de inicialización (por ejemplo, cuando sincronices tus acciones de inicialización de Cloud Storage con los cambios realizados en las acciones de inicialización de un repositorio de GitHub o de un bucket público), crea una carpeta nueva (preferiblemente con el nombre de la versión) para recibir las acciones de inicialización actualizadas. Si, por el contrario, actualiza la acción de inicialización, los nodos nuevos, como los que añade el escalador automático, ejecutarán la acción de inicialización actualizada, no la acción de inicialización de la versión anterior que se ejecutó en los nodos existentes. Estas diferencias en la acción de inicialización pueden provocar que los nodos del clúster sean incoherentes o estén dañados.
Las acciones de inicialización se ejecutan como usuario
root
. No es necesario que usessudo
.Usa rutas absolutas en las acciones de inicialización.
Usa una línea shebang en las acciones de inicialización para indicar cómo se debe interpretar la secuencia de comandos (por ejemplo,
#!/bin/bash
o#!/usr/bin/python
).Si una acción de inicialización finaliza con un código de salida distinto de cero, la operación de creación del clúster mostrará el estado "ERROR". Para depurar la acción de inicialización, usa SSH para conectarte a las instancias de VM del clúster y, a continuación, examina los registros. Después de solucionar el problema de la acción de inicialización, puedes eliminar el clúster y volver a crearlo.
Si creas un clúster de Dataproc con solo direcciones IP internas, los intentos de 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 a través de Cloud NAT o una Cloud VPN. Si no tienes acceso a Internet, puedes habilitar el acceso privado de Google y colocar las dependencias de los trabajos en Cloud Storage. Los nodos del clúster pueden descargar las dependencias de Cloud Storage desde IPs internas.Puedes usar imágenes personalizadas de Dataproc en lugar de acciones de inicialización para configurar las dependencias de los trabajos.
Procesamiento de la inicialización:
- Clústeres de imágenes anteriores a la versión 2.0:
- Principal: para permitir que las acciones de inicialización se ejecuten en los principales para escribir archivos en HDFS, las acciones de inicialización de los nodos principales no se inician hasta que HDFS se puede escribir (hasta que HDFS haya salido del modo seguro y se hayan unido al menos dos DataNodes de HDFS).
- Trabajador: si asigna el valor
RUN_BEFORE_SERVICES
a la propiedad de clústerdataproc:dataproc.worker.custom.init.actions.mode
, cada trabajador ejecuta sus acciones de inicialización antes de iniciar sus daemons HDFS DataNode y YARN NodeManager. Como Dataproc no ejecuta acciones de inicialización del nodo maestro hasta que HDFS se puede escribir, lo que requiere que se ejecuten dos daemons de nodo de datos de HDFS, al definir esta propiedad se puede aumentar el tiempo de creación del clúster.
Clústeres de imágenes 2.0 o versiones posteriores:
- 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 almacenan archivos en HDFS o dependen de la disponibilidad de servicios que dependen de HDFS, como Ranger, define la
dataproc.master.custom.init.actions.mode
propiedad del clúster enRUN_AFTER_SERVICES
. Nota: Como este ajuste de propiedad puede aumentar el tiempo de creación del clúster (consulta la explicación del retraso en la creación de clústeres para trabajadores de clústeres con imágenes anteriores a la versión 2.0), úsalo solo cuando sea necesario (por lo general, utiliza el ajuste predeterminadoRUN_BEFORE_SERVICES
de esta propiedad). - Trabajador: la
dataproc:dataproc.worker.custom.init.actions.mode
propiedad de clúster tiene el valorRUN_BEFORE_SERVICES
y no se puede transferir al clúster cuando se crea (no se puede cambiar el valor de la propiedad). Cada trabajador ejecuta sus acciones de inicialización antes de iniciar sus daemons de nodo de datos de HDFS y de gestor de nodos de YARN. Como Dataproc no espera a que HDFS se pueda escribir antes de ejecutar las acciones de inicialización del maestro, las acciones de inicialización del maestro y del trabajador se ejecutan en paralelo.
- 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 almacenan archivos en HDFS o dependen de la disponibilidad de servicios que dependen de HDFS, como Ranger, define la
Recomendaciones:
- Usa los metadatos para determinar el rol de un nodo y ejecutar condicionalmente una acción de inicialización en los nodos (consulta Usar metadatos de clúster).
- Crea una bifurcación de una acción de inicialización en un segmento de Cloud Storage para mejorar la estabilidad (consulta Cómo se usan las acciones de inicialización).
- Añade reintentos al descargar contenido de Internet para estabilizar la acción de inicialización.
- Clústeres de imágenes anteriores a la versión 2.0:
Usar acciones de inicialización
Las acciones de inicialización de clústeres se pueden especificar independientemente de cómo se cree un clúster:
- A través de la consola de Google Cloud
- Usar la CLI de gcloud
- De forma automatizada con la API clusters.create de Dataproc (consulta NodeInitializationAction)
Comando de gcloud
Al crear un clúster con el comando gcloud dataproc clusters create, especifica una o varias ubicaciones de Cloud Storage (URIs) separadas por comas de los ejecutables o las secuencias de comandos de inicialización con la marca --initialization-actions
. Nota: No se admiten varias barras consecutivas ("/") en un URI de ubicación de Cloud Storage después de la "gs://" inicial, como "gs://bucket/my//object//name". Ejecuta
gcloud dataproc clusters create --help
para obtener información sobre los comandos.
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 ...
- Usa la marca
--initialization-action-timeout
para especificar un periodo de tiempo de espera para la acción de inicialización. El valor de tiempo de espera predeterminado es de 10 minutos. Si el ejecutable o el script de inicialización no se han completado al final del periodo de tiempo de espera, Dataproc cancela la acción de inicialización. -
Usa la
dataproc:dataproc.worker.custom.init.actions.mode
propiedad de clúster para ejecutar la acción de inicialización en los trabajadores principales antes de que se inicien los daemons del gestor de nodos y del nodo de datos.
API REST
Especifica uno o varios scripts o ejecutables en un array ClusterConfig.initializationActions como parte de una solicitud de 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" } ] } }
Consola
Transferir argumentos a acciones de inicialización
Dataproc define valores de metadatos especiales para las instancias que se ejecutan en tus clústeres. Puede definir sus propios metadatos personalizados para transferir 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 los metadatos se pueden leer en 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 los nodos maestros, de controlador o de trabajador, puedes añadir una lógica de selección de nodos sencilla a tu ejecutable o 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
Binarios de fase
Un escenario habitual de inicialización de clústeres es el almacenamiento provisional de los archivos binarios de las tareas en un clúster para no tener que almacenar provisionalmente los archivos binarios cada vez que se envía una tarea. Por ejemplo, supongamos que el siguiente script de inicialización se almacena en gs://my-bucket/download-job-jar.sh
, una ubicación de segmento de Cloud Storage:
#!/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 se puede transferir 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 archivo JAR en el nodo maestro. Las tareas enviadas pueden usar el archivo JAR preconfigurado:
gcloud dataproc jobs submit hadoop \ --cluster=my-dataproc-cluster \ --region=${REGION} \ --jar=file:///home/username/sessionalize-logs-1.0.jar
Ejemplos de acciones de inicialización
Los scripts de acciones de inicialización de uso frecuente y otros de ejemplo se encuentran en gs://goog-dataproc-initialization-actions-<REGION>
, un segmento público regional de Cloud Storage, y en un repositorio de GitHub.
Para contribuir con una secuencia de comandos, consulta el documento CONTRIBUTING.md
y, a continuación, presenta una solicitud de extracción.
Almacenamiento de registros
El resultado de la ejecución de cada acción de inicialización se registra en cada instancia de /var/log/dataproc-initialization-script-X.log
, donde X
es el índice de base 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, las salidas se registrarán en /var/log/dataproc-initialization-script-0.log
y /var/log/dataproc-initialization-script-1.log
.
Siguientes pasos
Consulta las acciones de inicialización de GitHub.