Lors de la création d'un cluster Dataproc, vous pouvez spécifier des actions d'initialisation dans des exécutables ou des scripts que Dataproc exécutera sur tous les nœuds du cluster Dataproc immédiatement après la configuration du cluster. Les actions d'initialisation vous permettent souvent de configurer les dépendances de tâches, telles que l'installation de packages Python. Vous pouvez ainsi soumettre les tâches au cluster sans avoir à installer de dépendances lors de leur exécution.
Vous trouverez des exemples de scripts d'action d'initialisation aux emplacements suivants: Remarque: Google n'accepte pas ces exemples.
- Dépôt GitHub
- Cloud Storage, au niveau régional
gs://goog-dataproc-initialization-actions-REGION
buckets publics
Consignes et remarques importantes
Ne créez pas de clusters de production faisant référence d'initialisation situées dans
gs://goog-dataproc-initialization-actions-REGION
aux buckets publics. Ces scripts sont fournis à titre d'implémentation de référence. Ils sont synchronisés avec les modifications en cours du dépôt GitHub et les mises à jour de ces peuvent interrompre la création de votre cluster. Copiez plutôt l'action d'initialisation le bucket public dans un dossier de bucket Cloud Storage avec gestion des versions, comme illustré dans l'exemple suivant: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...
Les actions d'initialisation sont exécutées sur chaque nœud en série lors de la création du cluster. Ils sont également exécutés sur chaque nœud ajouté mise à l'échelle ou autoscaling de manière centralisée.
Lorsque vous mettez à jour les actions d'initialisation, par exemple lorsque vous synchronisez votre Actions d'initialisation de Cloud Storage pour les modifications apportées au bucket public ou les actions d'initialisation du dépôt GitHub, créez une requête (version nommée) pour recevoir les actions d'initialisation mises à jour. Si, au contraire, vous mettez à jour l'action d'initialisation, les nouveaux nœuds, tels que ceux ajoutés par l'autoscaler, exécutent le processus d'initialisation sur place mis à jour et non l'action d'initialisation de la version précédente exécutée sur nœuds. Ces différences d'actions d'initialisation peuvent entraîner les nœuds de cluster défaillants.
Les actions d'initialisation sont exécutées en tant qu'utilisateur
root
. Vous n'avez pas besoin d'utilisersudo
.Utilisez des chemins absolus dans les actions d'initialisation.
Utilisez un ligne Shebang dans les actions d'initialisation pour indiquer comment le script doit être interprété (par exemple,
#!/bin/bash
ou#!/usr/bin/python
).Si une action d'initialisation se termine par un code de sortie différent de zéro, l'opération de création de cluster indique un état "ERREUR". Déboguer l'initialisation utilisez SSH pour vous connecter aux instances de VM du cluster, puis examinez le logs. Après avoir résolu le problème d'action d'initialisation, vous pouvez supprimer le cluster, puis le recréer.
Si vous créez un cluster Dataproc avec adresses IP internes uniquement, tente d'accéder à
github.com
via Internet lors d'une action d'initialisation échouera si vous n'avez pas configuré les routes pour diriger le trafic via Cloud NAT ou Cloud VPN. Sans à Internet, vous pouvez activer Accès privé à Google et placer les dépendances de tâches dans Cloud Storage. les nœuds de cluster peuvent télécharger les dépendances depuis Cloud Storage à l'aide d'adresses IP internes.Vous pouvez configurer des dépendances de tâches à l'aide d'images personnalisées Dataproc plutôt qu'avec des actions d'initialisation.
Traitement de l'initialisation :
- Clusters d'images antérieurs à la version 2.0 :
- Maître: pour autoriser l'exécution des actions d'initialisation sur les instances maîtres. pour écrire des fichiers dans HDFS, les actions d'initialisation du nœud maître ne démarrent que HDFS est accessible en écriture (jusqu'à ce que HDFS ait quitté le mode sans échec et qu'au moins deux HDFS) les DataNodes ont été joints).
- Nœud de calcul: si vous définissez le
dataproc:dataproc.worker.custom.init.actions.mode
propriété du cluster àRUN_BEFORE_SERVICES
, chaque nœud de calcul exécute des actions d'initialisation avant de démarrer son nœud de données HDFS et YARN les daemons nodemanager. Étant donné que Dataproc n'exécute aucune action d'initialisation du maître tant que HDFS n'est pas accessible en écriture, ce qui nécessite l'exécution de deux daemons de nœud de données HDFS, définir cette propriété peut augmenter le temps de création du cluster.
Clusters d'images 2.0 et versions ultérieures :
- Maître : les actions d'initialisation du nœud maître peuvent s'exécuter avant que HDFS ne soit accessible en écriture. Si vous exécutez des actions d'initialisation qui organisent les fichiers dans HDFS ou dépendent de la disponibilité des services dépendants de HDFS, tels que Ranger, définissez la
propriété de cluster
dataproc.master.custom.init.actions.mode
surRUN_AFTER_SERVICES
. Remarque: puisque ce peut augmenter le délai de création du cluster. Consultez la explication du délai de création du cluster Nœuds de calcul de cluster d'images antérieures à la version 2.0 : utilisez-les uniquement lorsque cela est nécessaire (en général, comptez-vousRUN_BEFORE_SERVICES
pour cette propriété). - Nœud de calcul:
dataproc:dataproc.worker.custom.init.actions.mode
propriété du cluster est défini surRUN_BEFORE_SERVICES
et ne peut pas être transmise au cluster lors de sa création (vous ne pouvez pas modifier les paramètres de la propriété). Chaque nœud de calcul exécute son initialisation avant de démarrer ses daemons de nœud de données HDFS et de gestionnaire de nœuds YARN. Comme Dataproc n'attend pas que HDFS soit accessible en écriture avant d'exécuter les actions d'initialisation du nœud maître, le nœud maître et le nœud de calcul les actions d'initialisation s'exécutent en parallèle.
- Maître : les actions d'initialisation du nœud maître peuvent s'exécuter avant que HDFS ne soit accessible en écriture. Si vous exécutez des actions d'initialisation qui organisent les fichiers dans HDFS ou dépendent de la disponibilité des services dépendants de HDFS, tels que Ranger, définissez la
propriété de cluster
Recommandations :
- Utilisez les métadonnées pour déterminer le rôle d'un nœud pour exécuter une action d'initialisation de manière conditionnelle sur les nœuds (voir Utiliser des métadonnées de cluster).
- Dupliquer une copie d'une action d'initialisation dans un bucket Cloud Storage pour plus de stabilité (voir Utilisation des actions d'initialisation).
- Ajoutez des tentatives pour les téléchargements depuis Internet pour stabiliser l'action d'initialisation.
- Clusters d'images antérieurs à la version 2.0 :
Utiliser les actions d'initialisation
Les actions d'initialisation de cluster peuvent être spécifiées quelle que soit la manière dont vous créez un cluster :
- Via la console Google Cloud
- Utiliser la gcloud CLI
- De façon automatisée à l'aide de l'API clusters.create de Dataproc (consultez la section sur le paramètre NodeInitializationAction)
Commande gcloud
Lorsque vous créez un cluster avec
gcloud dataproc clusters create
, spécifiez un ou plusieurs emplacements Cloud Storage (URI) séparés par une virgule
des exécutables ou des scripts d'initialisation avec
--initialization-actions
. Remarque : L'utilisation de plusieurs caractères "/" consécutifs dans un URI d'emplacement Cloud Storage après le préfixe "gs://" initial, par exemple "gs://bucket/my//object//name", n'est pas acceptée. Exécuter
gcloud dataproc clusters create --help
pour obtenir des informations sur la commande.
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 ...Remarques:
- Utilisez l'option
--initialization-action-timeout
pour spécifier un délai avant expiration pour l'action d'initialisation. La valeur par défaut du délai avant expiration est de 10 minutes. Si le script ou le fichier exécutable d'initialisation n'est pas terminé à la fin du délai d'expiration, Dataproc annule l'action d'initialisation. - Utilisez la propriété de cluster
dataproc:dataproc.worker.custom.init.actions.mode
pour exécuter l'action d'initialisation sur les nœuds de calcul principaux avant le démarrage des gestionnaires de nœuds et des daemons Datanode.
API REST
Spécifiez un ou plusieurs script(s) ou exécutable(s) dans un tableau ClusterConfig.initializationActions dans le cadre d'une requête API clusters.create.
Exemple
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
Transmettre des arguments aux actions d'initialisation
Dataproc définit des valeurs de métadonnées spéciales pour les instances exécutées dans vos clusters. Vous pouvez définir vos propres métadonnées personnalisées pour transmettre des arguments aux actions d'initialisation.
gcloud dataproc clusters create cluster-name \ --region=${REGION} \ --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \ --metadata=name1=value1,name2=value2... \ ... other flags ...
Les valeurs de métadonnées peuvent être lues dans les actions d'initialisation comme suit :
var1=$(/usr/share/google/get_metadata_value attributes/name1)
Sélection de nœud
Si vous souhaitez limiter les actions d'initialisation aux nœuds maîtres, pilotes ou nœuds de calcul, vous pouvez ajouter simple de sélection de nœud à votre exécutable ou 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
Binaires de préproduction
Un scénario d'initialisation de cluster courant consiste en la préproduction de binaires de tâches sur un cluster afin d'éliminer le besoin de préparer ces binaires chaque fois qu'une tâche est soumise. Par exemple, supposons que le script d'initialisation suivant soit stocké dans
gs://my-bucket/download-job-jar.sh
, un bucket Cloud Storage
lieu:
#!/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
L'emplacement de ce script peut être transmis à la commande gcloud dataproc clusters create
:
gcloud dataproc clusters create my-dataproc-cluster \ --region=${REGION} \ --initialization-actions=gs://my-bucket/download-job-jar.sh
Dataproc exécute ce script sur tous les nœuds et, à cause de la logique de sélection de nœud dans le script, il télécharge le fichier jar sur le nœud maître. Les tâches soumises peuvent ensuite utiliser le fichier jar de préproduction :
gcloud dataproc jobs submit hadoop \ --cluster=my-dataproc-cluster \ --region=${REGION} \ --jar=file:///home/username/sessionalize-logs-1.0.jar
Exemples d'actions d'initialisation
Vous trouverez des exemples de scripts d'actions d'initialisation fréquemment utilisés et d'autres scripts dans gs://goog-dataproc-initialization-actions-<REGION>
, un bucket public Cloud Storage régional, et dans un dépôt GitHub.
Pour contribuer à un script, consultez le document CONTRIBUTING.md
, puis déposez une demande d'extraction.
Logging
Le résultat de l'exécution de chaque action d'initialisation est enregistré pour chaque instance dans /var/log/dataproc-initialization-script-X.log
, où X
correspond à l'index basé sur zéro de chaque script d'action d'initialisation successif. Par exemple, si votre cluster comporte deux actions d'initialisation, les résultats sont enregistrés dans /var/log/dataproc-initialization-script-0.log
et /var/log/dataproc-initialization-script-1.log
.
Étape suivante
Découvrez les actions d'initialisation GitHub.