Initialisierungsaktionen

Beim Erstellen eines Dataproc-Clusters können Sie Initialisierungsaktionen in ausführbaren Dateien oder Skripts angeben, die von Dataproc auf allen Knoten im Dataproc-Cluster ausgeführt werden, unmittelbar nachdem der Cluster eingerichtet wurde. Initialisierungsaktionen richten häufig Jobabhängigkeiten ein, beispielsweise die Installation von Python-Paketen, sodass Jobs an den Cluster gesendet werden können, ohne Abhängigkeiten bei der Ausführung der Jobs zu installieren.

Beispiele für Skripts für Initialisierungsaktionen finden Sie an folgenden Stellen:

Wichtige Hinweise und Richtlinien

  • Erstellen Sie keine Produktionscluster, die auf Initialisierungsaktionen in den öffentlichen gs://goog-dataproc-initialization-actions-REGION-Buckets verweisen. Diese Skripts dienen als Referenzimplementierungen. Sie werden mit laufenden GitHub-Repository-Änderungen synchronisiert. Eine neue Version einer Initialisierungsaktion in einem öffentlichen Bucket kann dazu führen, dass der Cluster nicht mehr erstellt werden kann. Kopieren Sie stattdessen die Initialisierungsaktion aus dem öffentlichen Bucket in Ihren Bucket: 

    REGION=region

    gsutil cp gs://goog-dataproc-initialization-actions-${REGION}/tez/tez.sh gs://my-bucket
    Erstellen Sie anschließend den Cluster, indem Sie auf die Kopie verweisen: 
    gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=gs://my-bucket/tez.sh \
    ... other flags ...
    Sie können entscheiden, wann Ihre Kopie der Initialisierungsaktion mit Änderungen an der Initialisierungsaktion synchronisiert werden soll, die im öffentlichen Bucket oder im GitHub-Repository ausgeführt werden.

  • Initialisierungsaktionen werden auf jedem Knoten während der Clustererstellung ausgeführt. Sie werden auch auf jedem neu hinzugefügten Knoten ausgeführt, wenn Cluster skaliert oder automatisch skaliert werden.

  • Initialisierungsaktionen werden als root-Nutzer ausgeführt. sudo brauchen Sie nicht.

  • Verwenden Sie absolute Pfade in Initialisierungsaktionen.

  • Verwenden Sie in Initialisierungsaktionen eine Shebang-Zeile, um anzugeben, wie das Skript interpretiert werden soll (z. B. #!/bin/bash oder #!/usr/bin/python).

  • Wenn eine Initialisierungsaktion mit einem Exit-Code ungleich null beendet wird, meldet der Vorgang der Clustererstellung den Status "ERROR" (Fehler). Wenn Sie die Initialisierungsaktion debuggen möchten, stellen Sie mit SSH eine Verbindung zu den VM-Instanzen des Clusters her und prüfen dann die Logs. Nachdem Sie das Problem mit der Initialisierungsaktion behoben haben, können Sie den Cluster löschen und anschließend neu erstellen.

  • Wenn Sie einen Dataproc-Cluster nur mit internen IP-Adressen erstellen, versuchen Sie, über eine Initialisierungsaktion über das Internet auf github.com zuzugreifen, es sei denn, Sie haben Routen zur Weiterleitung des Traffics über Cloud NAT oder ein Cloud VPN konfiguriert. Ohne Zugriff auf das Internet können Sie den privaten Google-Zugriff aktivieren und Jobabhängigkeiten in Cloud Storage platzieren. Clusterknoten können die Abhängigkeiten aus internen Speicher von internen IP-Adressen herunterladen.

  • Sie können benutzerdefinierte Dataproc-Images anstelle von Initialisierungsaktionen verwenden, um Jobabhängigkeiten einzurichten.

  • Initialisierungsverarbeitung:

    • Image-Cluster vor Version 2.0:
      • Master: Damit Initialisierungsaktionen, die auf Mastern ausgeführt werden, Dateien in HDFS schreiben können, werden Initialisierungsaktionen des Masterknotens erst gestartet, wenn HDFS geschrieben werden kann (bis der Secure Mode beendet wurde und mindestens zwei HDFS DataNodes beigetreten sind).
      • Worker: Wenn Sie das Clusterattribut dataproc:dataproc.worker.custom.init.actions.mode auf RUN_BEFORE_SERVICES festgelegt haben, führt jeder Worker seine Initialisierungsaktionen aus, bevor er seinen HDFS-Datenknoten und YARN-Dämonenon-Daemons startet. Da Dataproc Master-Initialisierungsaktionen erst ausführt, wenn HDFS beschreibbar ist, sodass zwei HDFS-Datenknoten-Daemons aktiv sein müssen, kann das Festlegen dieses Attributs die Clustererstellungszeit erhöhen.

    • Image-Cluster ab Version 2.0:

      • Master: Master-Initialisierungsaktionen können ausgeführt werden, bevor HDFS beschreibbar ist. Wenn Sie Initialisierungsaktionen ausführen, die Dateien in HDFS bereitstellen oder von der Verfügbarkeit von HDFS-abhängigen Diensten wie Ranger abhängen, können Sie Folgendes festlegen: dataproc.master.custom.init.actions.mode Clusterattribut in RUN_AFTER_SERVICES. Hinweis: Da diese Property-Einstellung die Zeit für die Clustererstellung erhöhen kann, siehe die Erläuterung der Verzögerung bei der Clustererstellung für Pre-2.0-Image-Cluster-Worker, verwenden Sie sie nur bei Bedarf. Als Standardeinstellung sollten Sie die Standardeinstellung RUN_BEFORE_SERVICES für diese Property verwenden.
      • Worker: Die Clustereigenschaft dataproc:dataproc.worker.custom.init.actions.mode wird auf RUN_BEFORE_SERVICES festgelegt und kann nicht an den Cluster übergeben werden, wenn der Cluster erstellt wird. Diese Property-Einstellung kann nicht geändert werden. Jeder Worker führt seine Initialisierungsaktionen aus, bevor er seinen HDFS-Datenknoten und die YARN-Knotenmanager-Daemons startet. Da Dataproc nicht wartet, bis HDFS beschreibbar ist, bevor Master-Initialisierungsaktionen ausgeführt werden, werden Master- und Worker-Initialisierungsaktionen parallel ausgeführt.

    • Empfehlungen

      • Ermitteln Sie über Metadaten die Rolle eines Knotens, um in Abhängigkeit Initialisierungsaktionen auf Knoten auszuführen. Weitere Informationen finden Sie unter Clustermetadaten verwenden.
      • Erstellen Sie aus Gründen der Stabilität eine Kopie einer Initialisierungsaktion in einem Cloud Storage-Bucket. Weitere Informationen zur Verwendung von Initialisierungsaktionen
      • Fügen Sie Wiederholungen hinzu, wenn Sie aus dem Internet herunterladen. Dies hilft dabei, die Initialisierungsaktion zu stabilisieren.

Initialisierungsaktionen verwenden

Cluster-Initialisierungsaktionen können unabhängig davon angegeben werden, mit welcher Methode der Cluster erstellt wird:

Befehl "gcloud"

Geben Sie beim Erstellen eines Clusters mit dem Befehl gcloud qwiklabs cluster create einen oder mehrere durch Kommas getrennte Cloud Storage-Standorte (URIs) der ausführbaren Initialisierungsdateien oder Skripts mit dem Flag --initialization-actions an. Hinweis: Mehrere aufeinanderfolgende "/"s in einem Cloud Storage-Standort-URI nach dem ersten "gs://", z. B. "gs://bucket/my//object//name", werden nicht unterstützt. Führen Sie gcloud dataproc clusters create --help für Befehlsinformationen aus.

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 ...
Hinweise:
  • Verwenden Sie das Flag --initialization-action-timeout, um ein Zeitlimit für die Initialisierungsaktion anzugeben. Das standardmäßige Zeitlimit beträgt 10 Minuten. Wenn die ausführbare Datei oder das Skript der Initialisierung bei Ablauf der Zeitüberschreitung noch nicht abgeschlossen ist, wird die Initialisierungsaktion abgebrochen.
  • Verwenden Sie das Cluster-Attribut dataproc:dataproc.worker.custom.init.actions.mode, um die Initialisierungsaktion für primäre Worker auszuführen, bevor der Knotenmanager und die Dataknoten-Daemons gestartet werden.

REST API

Geben Sie ein oder mehrere Skripts oder ausführbare Dateien in einem ClusterConfig.initializationActions-Array als Teil der API-Anfrage clusters.create an.

Beispiel

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

  • Öffnen Sie die Dataproc-Seite Cluster erstellen und wählen Sie den Bereich Cluster anpassen aus.
  • Geben Sie im Abschnitt „Initialisierungsaktionen“ den Cloud Storage-Bucket-Standort jeder Initialisierungsaktion in die Felder Executable file (Ausführbare Datei) ein. Klicken Sie auf Durchsuchen, um die Cloud Storage-Browserseite der Google Cloud Console zu öffnen und ein Skript oder eine ausführbare Datei auszuwählen. Klicken Sie auf Initialisierungsaktion, um jede Datei hinzuzufügen.

    • Argumente an Initialisierungsaktionen übergeben

    Dataproc legt spezielle Metadatenwerte für die Instanzen fest, die in Ihrem Cluster ausgeführt werden. Sie können Ihre eigenen benutzerdefinierten Metadaten festlegen, um Argumente an Initialisierungsaktionen zu übergeben.

    gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
    --metadata=name1=value1,name2=value2... \
    ... other flags ...

    Metadatenwerte können auf folgende Weise in Initialisierungsaktionen gelesen werden:

    var1=$(/usr/share/google/get_metadata_value attributes/name1)

    Knotenauswahl

    Wenn Sie die Initialisierungsaktionen auf Master- oder Worker-Knoten beschränken möchten, können Sie der ausführbaren Datei oder dem Skript eine einfache Knotenauswahllogik hinzufügen.

    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
if [[ "${ROLE}" == 'Master' ]]; then
  ... master specific actions ...
else
  ... worker specific actions ...
fi

    Staging von Binärdateien

    Ein gängiges Szenario der Cluster-Initialisierung ist das Staging von binären Jobdateien auf einem Cluster. Hierdurch wird vermieden, dass die Binärdateien bei jeder Jobausführung einem Staging-Prozess unterzogen werden. Nehmen wir zum Beispiel an, dass das folgende Initialisierungsskript in gs://my-bucket/download-job-jar.sh, einem Cloud Storage-Bucket-Speicherort, gespeichert wird:

    #!/bin/bash
ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
if [[ "${ROLE}" == 'Master' ]]; then
  gsutil cp gs://my-bucket/jobs/sessionalize-logs-1.0.jar home/username
fi

    Der Speicherort dieses Skripts kann an den Befehl gcloud dataproc clusters create übergeben werden:

    gcloud dataproc clusters create my-dataproc-cluster \
    --region=${REGION} \
    --initialization-actions=gs://my-bucket/download-job-jar.sh

    Dataproc führt dieses Skript auf allen Knoten aus. Die JAR-Datei wird entsprechend der Knotenauswahllogik des Skripts auf den Master-Knoten heruntergeladen. Gesendete Jobs können dann die JAR-Datei in der Vor-Staging-Phase verwenden:

    gcloud dataproc jobs submit hadoop \
    --cluster=my-dataproc-cluster \
    --region=${REGION} \
    --jar=file:///home/username/sessionalize-logs-1.0.jar

    Beispiele für Initialisierungsaktionen

    Häufig verwendete und sonstige Beispielinitialisierungsaktionen werden in einem regionalen öffentlichen Cloud Storage-Bucket (gs://goog-dataproc-initialization-actions-<REGION>) und in einem GitHub-Repository bereitgestellt. Wenn Sie ein Skript beitragen möchten, lesen Sie das Dokument CONTRIBUTING.md und senden Sie eine Pull-Anfrage.

    Logging

    Die Ausgabe der einzelnen Initialisierungsaktionen wird für jede Instanz im Log /var/log/dataproc-initialization-script-X.log erfasst, wobei X der nullbasierte Index jedes nachfolgenden Skripts mit Initialisierungsaktionen ist. Wenn Ihr Cluster beispielsweise zwei Initialisierungsaktionen hat, werden die Ausgaben in /var/log/dataproc-initialization-script-0.log und /var/log/dataproc-initialization-script-1.log protokolliert.

    Nächste Schritte

    GitHub-Initialisierungsaktionen entdecken.