Actions d'initialisation

Lorsque vous créez un cluster Managed Service pour Apache Spark, vous pouvez spécifier des actions d'initialisation dans des exécutables ou des scripts que Managed Service pour Apache Spark exécutera sur tous les nœuds de votre cluster Managed Service pour Apache Spark 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 ne prend pas en charge ces exemples.

Consignes et remarques importantes

  • Ne créez pas de clusters de production qui font référence à des actions d'initialisation situées dans les buckets publics gs://goog-dataproc-initialization-actions-REGION. Ces scripts sont fournis en tant qu'implémentations de référence. Ils sont synchronisés avec les modifications apportées en continu au dépôt GitHub, et les mises à jour de ces scripts peuvent compromettre la création de votre cluster. Copiez plutôt l'action d'initialisation du 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
    Ensuite, créez le cluster en référençant la copie dans 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...

  • 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é lors du scaling ou de l'autoscaling des clusters.

  • Lorsque vous mettez à jour des actions d'initialisation (par exemple, lorsque vous synchronisez vos actions d'initialisation Cloud Storage avec les modifications apportées aux actions d'initialisation d'un bucket public ou d'un dépôt GitHub), créez un dossier (de préférence nommé d'après la version) pour recevoir les actions d'initialisation mises à jour. Si, au lieu de cela, vous mettez à jour l'action d'initialisation en place, les nouveaux nœuds, tels que ceux ajoutés par l'autoscaler, exécuteront l'action d'initialisation mise à jour en place, et non l'action d'initialisation de la version précédente qui s'est exécutée sur les nœuds existants. De telles différences d'actions d'initialisation peuvent entraîner des incohérences ou des dysfonctionnements au niveau des nœuds du cluster.

  • Les actions d'initialisation sont exécutées en tant qu'utilisateur root. Vous n'avez pas besoin d'utiliser sudo.

  • Utilisez des chemins absolus dans les actions d'initialisation.

  • Utilisez une ligne shebang dans les actions d'initialisation pour indiquer comment le script doit être interprété (par exemple, #!/bin/bash ou #!/usr/bin/python).

  • Utilisez des fins de ligne de style Unix (LF) dans les actions d'initialisation. Si vous créez des actions d'initialisation sous Windows, elles peuvent contenir des fins de ligne de style Windows (CRLF), ce qui peut entraîner des échecs d'exécution du script.

  • 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". Pour déboguer l'action d'initialisation, utilisez SSH pour vous connecter aux instances de VM du cluster, puis examinez les journaux. 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 Managed Service pour Apache Spark avec des adresses IP internes uniquement, les tentatives d'accès à github.com via Internet dans une action d'initialisation échoueront, sauf si vous avez configuré des routes pour diriger le trafic via Cloud NAT ou un Cloud VPN. Sans accès à Internet, vous pouvez activer l'accès privé à Google et placer les dépendances de job dans Cloud Storage. Les nœuds de cluster peuvent télécharger les dépendances depuis Cloud Storage à partir d'adresses IP internes.

  • Vous pouvez utiliser des images personnalisées Managed Service pour Apache Spark au lieu d'actions d'initialisation pour configurer les dépendances des jobs.

  • Traitement de l'initialisation :

    • Clusters d'images antérieurs à la version 2.0 :
      • Nœud maître : pour permettre aux actions d'initialisation exécutées sur les nœuds maîtres d'écrire des fichiers dans HDFS, les actions d'initialisation des nœuds maîtres ne démarrent pas tant que HDFS n'est pas accessible en écriture (tant que HDFS n'a pas quitté le mode sans échec et qu'au moins deux nœuds de données HDFS n'ont pas été joints).
      • Nœud de calcul : si vous définissez la propriété de cluster dataproc:dataproc.worker.custom.init.actions.mode sur RUN_BEFORE_SERVICES, chaque nœud de calcul exécute ses actions d'initialisation avant de démarrer ses daemons de nœud de données HDFS et de gestionnaire de nœuds YARN. Étant donné que Managed Service pour Apache Spark n'exécute pas les actions d'initialisation du maître tant que HDFS n'est pas accessible en écriture, ce qui nécessite l'exécution de deux démons de nœud de données HDFS, la définition de 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 sur RUN_AFTER_SERVICES. Remarque : Étant donné que ce paramètre de propriété peut augmenter le temps de création du cluster (voir l'explication du délai de création du cluster pour les nœuds de calcul de cluster d'images antérieurs à la version 2.0), ne l'utilisez que lorsque cela est nécessaire (en règle générale, fiez-vous au paramètre RUN_BEFORE_SERVICES par défaut pour cette propriété).
      • Nœud de calcul : la propriété de cluster dataproc:dataproc.worker.custom.init.actions.mode est définie sur RUN_BEFORE_SERVICES et ne peut pas être transmise au cluster lors de sa création (vous ne pouvez pas modifier le paramètre de propriété). Chaque nœud de calcul exécute ses actions d'initialisation avant de démarrer ses daemons de nœud de données HDFS et de gestionnaire de nœuds YARN. Étant donné que Managed Service pour Apache Spark n'attend pas que HDFS soit accessible en écriture avant d'exécuter les actions d'initialisation du maître, les actions d'initialisation du maître et des nœuds de calcul s'exécutent en parallèle.

    • 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 nouvelles tentatives lorsque vous téléchargez depuis Internet pour stabiliser l'action d'initialisation.

Utiliser des 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 :

ConsoleGoogle Cloud

  • Ouvrez la page Créer un cluster.
  • Cliquez sur Configuration supplémentaire pour développer cette section.
  • Modifiez les paramètres Personnalisation et autres.
  • Dans le panneau qui s'ouvre, cliquez sur Ajouter des actions d'initialisation, puis saisissez ou parcourez l'emplacement Cloud Storage d'une action d'initialisation.

    • gcloud CLI

    Lorsque vous créez un cluster à l'aide de la commande gcloud dataproc clusters create, spécifiez un ou plusieurs emplacements Cloud Storage (URI) séparés par une virgule pour les exécutables ou les scripts d'initialisation avec l'option --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écutez 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 l'exécutable ou le script d'initialisation n'est pas terminé à la fin du délai avant expiration, Managed Service pour Apache Spark 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"
      }
    ]
  }
}

    Transmettre des arguments aux actions d'initialisation

    Managed Service pour Apache Spark définit des valeurs de métadonnées spéciales pour les instances qui s'exécutent 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, de pilote ou de calcul, vous pouvez ajouter une logique de sélection de nœuds à votre exécutable ou à votre 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

    Préparer les binaires

    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 emplacement de bucket 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

    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

    Managed Service pour Apache Spark exécutera ce script sur tous les nœuds et, en raison de la logique de sélection des nœuds du script, téléchargera 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

    Les scripts d'actions d'initialisation fréquemment utilisés et d'autres exemples de scripts sont situés dans gs://goog-dataproc-initialization-actions-<REGION>, un bucket Cloud Storage public 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.

    Étapes suivantes

    Découvrez les actions d'initialisation GitHub.