Job mit Speicher-Volumes erstellen und ausführen

In diesem Dokument wird erläutert, wie Sie einen Batchjob erstellen, der ein oder mehrere externe Speicher-Volumes verwendet. Zu den Speicheroptionen gehören neue oder vorhandene nichtflüchtige Speicher, neue lokale SSDs, vorhandene Cloud Storage-Buckets und ein vorhandenes Netzwerkdateisystem (NFS) wie eine Filestore-Dateifreigabe.

Hinweis

Job erstellen, der Speicher-Volumes verwendet

Standardmäßig hat jede Compute Engine-VM für einen Job einen einzelnen nichtflüchtigen Bootspeicher, der das Betriebssystem enthält. Optional können Sie einen Job erstellen, der zusätzliche Speicher-Volumes verwendet. Genauer gesagt können die VMs eines Jobs einen oder mehrere der folgenden Speicher-Volumes verwenden. Weitere Informationen zu den verschiedenen Speichertypen und den jeweiligen Unterschieden und Einschränkungen finden Sie in der Dokumentation zu Compute Engine-VM-Speicheroptionen.

Sie können einem Job erlauben, jedes Speicher-Volume zu verwenden, indem Sie ihn in die Definition des Jobs aufnehmen und den Bereitstellungspfad (mountPath) in den ausführbaren Dateien angeben. Informationen zum Erstellen eines Jobs, der Speicher-Volumes verwendet, finden Sie in einem oder mehreren der folgenden Abschnitte:

Nichtflüchtigen Speicher verwenden

Bei einem Job, der nichtflüchtige Speicher verwendet, gelten folgende Einschränkungen:

  • Alle nichtflüchtigen Speicher: Lesen Sie die Einschränkungen für alle nichtflüchtigen Speicher.

  • Neue und vorhandene nichtflüchtige Speicher: Jeder nichtflüchtige Speicher in einem Job kann entweder neu (mit dem Job definiert und erstellt) oder vorhanden (bereits in Ihrem Projekt erstellt und im Job angegeben) sein. Um einen nichtflüchtigen Speicher zu verwenden, muss er auf den VMs des Jobs formatiert und bereitgestellt werden. Dies muss sich am selben Standort wie der nichtflüchtige Speicher befinden. In einem Batch werden alle nichtflüchtigen Speicher bereitgestellt, die Sie in einem Job angeben, und alle neuen nichtflüchtigen Speicher formatiert. Sie müssen jedoch alle vorhandenen nichtflüchtigen Speicher, die ein Job verwenden soll, formatieren und trennen.

    Die unterstützten Standortoptionen, Formatoptionen und Bereitstellungsoptionen variieren zwischen neuen und vorhandenen nichtflüchtigen Speichern wie in der folgenden Tabelle beschrieben:

    Neuer nichtflüchtiger Speicher Vorhandene nichtflüchtige Speicher
    Formatoptionen

    Der nichtflüchtige Speicher wird automatisch mit einem ext4-Dateisystem formatiert.

    Sie müssen den nichtflüchtigen Speicher formatieren, um ein ext4-Dateisystem zu verwenden, bevor Sie es für einen Job verwenden.

    Bereitstellungsoptionen

    Alle Optionen werden unterstützt.

    Alle Optionen außer Schreiben werden unterstützt. Der Grund dafür sind die Einschränkungen im Modus für mehrere Autoren.

    Sie müssen den nichtflüchtigen Speicher von allen VMs trennen, mit denen er verknüpft ist, bevor Sie ihn für einen Job verwenden.
    Speicherortoptionen

    Sie können nur zonale nichtflüchtige Speicher erstellen.

    Sie können für Ihren Job einen beliebigen Standort auswählen. Die nichtflüchtigen Speicher werden in der Zone erstellt, in der Ihr Projekt ausgeführt wird.

    Sie können zonale und regionale nichtflüchtige Speicher auswählen.


    Der Standort des Jobs (oder, sofern angegeben, nur die zulässigen Standorte des Jobs) müssen auf nur Standorte festgelegt sein, die alle nichtflüchtigen Speicher des Jobs enthalten. Bei einem zonalen nichtflüchtigen Speicher muss der Speicherort des Jobs beispielsweise die Zone des Laufwerks sein. Bei einem regionalen nichtflüchtigen Speicher muss der Speicherort des Jobs entweder die Region des Laufwerks oder, wenn Sie Zonen angeben, eine oder beide der Zonen sein, in denen sich der regionale nichtflüchtige Speicher befindet.

  • Instanzvorlagen: Wenn Sie beim Erstellen dieses Jobs eine VM-Instanzvorlage verwenden möchten, müssen Sie alle nichtflüchtigen Speicher für diesen Job in der Instanzvorlage anhängen. Wenn Sie keine Instanzvorlage verwenden möchten, müssen Sie alle nichtflüchtigen Speicher direkt in der Jobdefinition anhängen.

Sie können einen Job erstellen, der einen nichtflüchtigen Speicher mit der Google Cloud Console, der gcloud CLI oder der Batch API verwendet.

Console

Im folgenden Beispiel wird mithilfe der Google Cloud Console ein Job erstellt, der ein Skript zum Lesen einer Datei aus einem vorhandenen zonalen nichtflüchtigen Speicher in der Zone us-central1-a ausführt. Im Beispielskript wird davon ausgegangen, dass der Job einen vorhandenen zonalen nichtflüchtigen Speicher hat, der eine Textdatei mit dem Namen example.txt im Stammverzeichnis enthält.

Optional: Wenn Sie einen zonalen nichtflüchtigen Speicher erstellen möchten, den Sie zum Ausführen des Beispielskripts verwenden können, gehen Sie vor dem Erstellen des Jobs so vor:

  1. Hängen Sie einen neuen, leeren nichtflüchtigen Speicher mit dem Namen example-disk an eine Linux-VM in der Zone us-central1-a an und führen Sie dann Befehle auf der VM aus, um das Laufwerk zu formatieren und bereitzustellen. Eine Anleitung finden Sie unter Nichtflüchtigen Speicher zu Ihrer VM hinzufügen.

    Trennen Sie die Verbindung zur VM noch nicht.

  2. Führen Sie die folgenden Befehle auf der VM aus, um example.txt auf dem nichtflüchtigen Speicher zu erstellen:

    1. Geben Sie den folgenden Befehl ein, um das aktuelle Arbeitsverzeichnis in das Stammverzeichnis des nichtflüchtigen Speichers zu ändern:

      cd VM_MOUNT_PATH

      Ersetzen Sie VM_MOUNT_PATH durch den Pfad zum Verzeichnis, in dem der nichtflüchtige Speicher im vorherigen Schritt auf dieser VM bereitgestellt wurde, z. B. /mnt/disks/example-disk.

    2. Drücken Sie Enter.

    3. Geben Sie den folgenden Befehl ein, um eine Datei mit dem Namen example.txt zu erstellen und zu definieren:

      cat > example.txt

    4. Drücken Sie Enter.

    5. Geben Sie den Inhalt der Datei ein. Geben Sie beispielsweise Hello world! ein.

    6. Drücken Sie zum Speichern der Datei Ctrl+D (oder Command+D unter macOS).

    Wenn Sie fertig sind, können Sie die Verbindung zur VM trennen.

  3. Nichtflüchtigen Speicher von der VM trennen.

    • Wenn Sie die VM nicht mehr benötigen, können Sie die VM löschen, wodurch der nichtflüchtige Speicher automatisch getrennt wird.

    • Trennen Sie andernfalls den nichtflüchtigen Speicher. Eine Anleitung finden Sie unter Bootlaufwerke trennen und neu anhängen und anstelle des Bootlaufwerks der VM den nichtflüchtigen Speicher example-disk trennen

So erstellen Sie einen Job, der vorhandene zonale nichtflüchtige Speicher mit der Google Cloud Console verwendet:

  1. Rufen Sie in der Google Cloud Console die Seite Jobliste auf.

    Zur Jobliste

  2. Klicken Sie auf Erstellen. Die Seite Batchjob erstellen wird geöffnet.

  3. Geben Sie im Feld Jobname einen Namen für den Job ein.

    Geben Sie beispielsweise example-disk-job ein.

  4. Wählen Sie im Feld Region den Standort für diesen Job aus.

    Wählen Sie beispielsweise us-central1 (Iowa) (Standardeinstellung) aus.

  5. Wählen Sie im Feld Zone die Zone aus, die die vorhandenen zonalen nichtflüchtigen Speicher enthält, die Sie für diesen Job verwenden möchten.

    Wählen Sie beispielsweise us-central1-a (Iowa) aus.

  6. Fügen Sie im Bereich Neue Ausführung mindestens ein Skript oder einen Container hinzu, der ausgeführt werden soll.

    So führen Sie beispielsweise ein Skript aus, das den Inhalt einer Datei mit dem Namen example.txt ausgibt und sich im Stammverzeichnis des nichtflüchtigen Speichers befindet, den dieser Job verwendet:

    1. Klicken Sie das Kästchen Skript an. Ein Textfeld wird angezeigt.

    2. Geben Sie das folgende Skript in das Textfeld ein:

      echo "Here is the content of the example.txt file in the persistent disk."
cat MOUNT_PATH/example.txt

      Ersetzen Sie MOUNT_PATH durch den Pfad zu dem Speicherort, an dem Sie den nichtflüchtigen Speicher für diesen Job auf den VMs bereitstellen möchten, z. B. /mnt/disks/example-disk.

    3. Klicken Sie auf Fertig.

  7. Geben Sie im Feld Aufgabenanzahl die Anzahl der Aufgaben für diesen Job ein.

    Geben Sie beispielsweise 1 ein.

  8. Geben Sie im Feld Parallelität die Anzahl der Aufgaben ein, die gleichzeitig ausgeführt werden sollen.

    Geben Sie beispielsweise 1 (Standard) ein.

  9. Führen Sie für jeden vorhandenen zonalen nichtflüchtigen Speicher, den Sie für diesen Job bereitstellen möchten, die folgenden Schritte aus:

    1. Klicken Sie auf Neues Volume hinzufügen. Der Bereich Neues Volume wird angezeigt.

    2. Führen Sie im Bereich Neues Volume die folgenden Schritte aus:

    3. Wählen Sie im Abschnitt Volume-Typ die Option Nichtflüchtiger Speicher aus.

    4. Wählen Sie im Menü Laufwerk einen vorhandenen zonalen nichtflüchtigen Speicher aus, den Sie für diesen Job bereitstellen möchten. Das Laufwerk muss sich in derselben Zone wie dieser Job befinden.

      Wählen Sie beispielsweise den vorhandenen zonalen nichtflüchtigen Speicher aus, den Sie vorbereitet haben. Dieser befindet sich in der Zone us-central1-a und enthält die Datei example.txt.

    5. Optional: Wenn Sie diesen zonalen nichtflüchtigen Speicher umbenennen möchten, gehen Sie so vor:

      1. Wählen Sie Gerätenamen anpassen aus.

      2. Geben Sie im Feld Gerätename den neuen Namen für das Laufwerk ein.

    6. Geben Sie im Feld Bereitstellungspfad den Bereitstellungspfad (MOUNT_PATH) für diesen nichtflüchtigen Speicher ein:

      Geben Sie beispielsweise Folgendes ein:

      /mnt/disks/EXISTING_PERSISTENT_DISK_NAME

      Ersetzen Sie EXISTING_PERSISTENT_DISK_NAME durch den Namen des Laufwerks. Wenn Sie den zonalen nichtflüchtigen Speicher umbenannt haben, verwenden Sie den neuen Namen.

      Ersetzen Sie beispielsweise EXISTING_PERSISTENT_DISK_NAME durch example-disk.

    7. Klicken Sie auf Fertig.

  10. Optional: Weitere Felder für diesen Job konfigurieren.

    Verwenden Sie beispielsweise für alle anderen Felder die Standardwerte.

  11. Klicken Sie auf Erstellen.

    Auf der Seite Jobliste wird der von Ihnen erstellte Job angezeigt.

gcloud

Mit der gcloud CLI wird im folgenden Beispiel ein Job erstellt, mit dem ein vorhandener nichtflüchtiger Speicher und ein neuer nichtflüchtiger Speicher bereitgestellt und bereitgestellt werden. Der Job hat 3 Aufgaben, mit denen jeweils ein Skript zum Erstellen einer Datei im neuen nichtflüchtigen Speicher output_task_TASK_INDEX.txt ausgeführt wird, wobei TASK_INDEX der Index jeder Aufgabe ist: 0, 1 und 2.

Verwenden Sie den Befehl gcloud batch jobs submit, um einen Job zu erstellen, der nichtflüchtige Speicher mit der gcloud CLI verwendet. Geben Sie in der JSON-Konfigurationsdatei des Jobs den nichtflüchtigen Speicher im Feld instances an und stellen Sie den nichtflüchtigen Speicher im Feld volumes bereit.

  1. Erstellen Sie eine JSON-Datei.

    • Wenn Sie für diesen Job keine Instanzvorlage verwenden, erstellen Sie eine JSON-Datei mit folgendem Inhalt:

      {
    "allocationPolicy": {
        "instances": [
            {
                "policy": {
                    "disks": [
                        {
                            "deviceName": "EXISTING_PERSISTENT_DISK_NAME",
                            "existingDisk": "projects/PROJECT_ID/EXISTING_PERSISTENT_DISK_LOCATION/disks/EXISTING_PERSISTENT_DISK_NAME"
                        },
                        {
                            "newDisk": {
                                "sizeGb": NEW_PERSISTENT_DISK_SIZE,
                                "type": "NEW_PERSISTENT_DISK_TYPE"
                            },
                            "deviceName": "NEW_PERSISTENT_DISK_NAME"
                        }
                    ]
                }
            }
        ],
        "location": {
            "allowedLocations": [
                "EXISTING_PERSISTENT_DISK_LOCATION"
            ]
        }
    },
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/disks/NEW_PERSISTENT_DISK_NAME/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "deviceName": "NEW_PERSISTENT_DISK_NAME",
                        "mountPath": "/mnt/disks/NEW_PERSISTENT_DISK_NAME",
                        "mountOptions": "rw,async"
                    },
                    {

                        "deviceName": "EXISTING_PERSISTENT_DISK_NAME",
                        "mountPath": "/mnt/disks/EXISTING_PERSISTENT_DISK_NAME"
                    }
                ]
            },
            "taskCount":3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

      Dabei gilt:

      • PROJECT_ID: Die Projekt-ID Ihres Projekts.
      • EXISTING_PERSISTENT_DISK_NAME ist der Name eines vorhandenen nichtflüchtigen Speichers.
      • EXISTING_PERSISTENT_DISK_LOCATION ist der Speicherort eines vorhandenen nichtflüchtigen Speichers. Der Jobstandort muss bei jedem vorhandenen zonalen nichtflüchtigen Speicher die Zone des Laufwerks angeben. Für jeden vorhandenen regionalen nichtflüchtigen Speicher muss der Speicherort des Jobs entweder die Region des Laufwerks oder, wenn Sie Zonen angeben, eine oder beide der Zonen sein, in denen sich der regionale nichtflüchtige Speicher befindet. Wenn Sie keine vorhandenen nichtflüchtigen Speicher angeben, können Sie einen beliebigen Standort auswählen. Weitere Informationen zum Feld allowedLocations.
      • NEW_PERSISTENT_DISK_SIZE: die Größe des neuen nichtflüchtigen Speichers in GB. Die zulässigen Größen hängen vom Typ des nichtflüchtigen Speichers ab, sind jedoch häufig mindestens 10 GB (10) und maximal 64 TB (64000).
      • NEW_PERSISTENT_DISK_TYPE ist der Laufwerkstyp des neuen nichtflüchtigen Speichers, entweder pd-standard, pd-balanced, pd-ssd oder pd-extreme.
      • NEW_PERSISTENT_DISK_NAME ist der Name des neuen nichtflüchtigen Speichers.

    • Wenn Sie eine VM-Instanzvorlage für diesen Job verwenden, erstellen Sie wie zuvor eine JSON-Datei, ersetzen Sie dabei das Feld instances durch Folgendes:

      "instances": [
    {
        "instanceTemplate": "INSTANCE_TEMPLATE_NAME"
    }
],

      Dabei ist INSTANCE_TEMPLATE_NAME der Name der Instanzvorlage für diesen Job. Bei einem Job, der nichtflüchtige Speicher verwendet, muss mit dieser Instanzvorlage die nichtflüchtigen Speicher definiert und angehängt werden, die der Job verwenden soll. In diesem Beispiel muss in der Vorlage ein neuer nichtflüchtiger Speicher mit dem Namen NEW_PERSISTENT_DISK_NAME definiert und angehängt und ein vorhandener nichtflüchtiger Speicher mit dem Namen EXISTING_PERSISTENT_DISK_NAME angehängt werden.

  2. Führen Sie dazu diesen Befehl aus:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Dabei gilt:

    • JOB_NAME: der Name des Jobs.

    • LOCATION: Der Standort des Jobs.

    • JSON_CONFIGURATION_FILE: Der Pfad für eine JSON-Datei mit den Konfigurationsdetails des Jobs.

API

Im folgenden Beispiel wird ein Job erstellt, der mit der Batch API einen vorhandenen nichtflüchtigen Speicher und einen neuen nichtflüchtigen Speicher anhängt und bereitstellt. Der Job hat 3 Aufgaben, mit denen jeweils ein Skript zum Erstellen einer Datei im neuen nichtflüchtigen Speicher output_task_TASK_INDEX.txt erstellt wird, wobei TASK_INDEX der Index jeder Aufgabe ist: 0, 1 und 2.

Verwenden Sie die Methode jobs.create, um einen Job zu erstellen, der nichtflüchtige Speicher mit der Batch API verwendet. Geben Sie in der Anfrage den nichtflüchtigen Speicher im Feld instances an und stellen Sie den nichtflüchtigen Speicher im Feld volumes bereit.

  • Wenn Sie keine Instanzvorlage für diesen Job verwenden, stellen Sie die folgende Anfrage:

    POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

{
    "allocationPolicy": {
        "instances": [
            {
                "policy": {
                    "disks": [
                        {
                            "deviceName": "EXISTING_PERSISTENT_DISK_NAME",
                            "existingDisk": "projects/PROJECT_ID/EXISTING_PERSISTENT_DISK_LOCATION/disks/EXISTING_PERSISTENT_DISK_NAME"
                        },
                        {
                            "newDisk": {
                                "sizeGb": NEW_PERSISTENT_DISK_SIZE,
                                "type": "NEW_PERSISTENT_DISK_TYPE"
                            },
                            "deviceName": "NEW_PERSISTENT_DISK_NAME"
                        }
                    ]
                }
            }
        ],
        "location": {
            "allowedLocations": [
                "EXISTING_PERSISTENT_DISK_LOCATION"
            ]
        }
    },
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/disks/NEW_PERSISTENT_DISK_NAME/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "deviceName": "NEW_PERSISTENT_DISK_NAME",
                        "mountPath": "/mnt/disks/NEW_PERSISTENT_DISK_NAME",
                        "mountOptions": "rw,async"
                    },
                    {

                        "deviceName": "EXISTING_PERSISTENT_DISK_NAME",
                        "mountPath": "/mnt/disks/EXISTING_PERSISTENT_DISK_NAME"
                    }
                ]
            },
            "taskCount":3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

    Dabei gilt:

    • PROJECT_ID: Die Projekt-ID Ihres Projekts.
    • LOCATION: Der Standort des Jobs.
    • JOB_NAME: der Name des Jobs.
    • EXISTING_PERSISTENT_DISK_NAME ist der Name eines vorhandenen nichtflüchtigen Speichers.
    • EXISTING_PERSISTENT_DISK_LOCATION ist der Speicherort eines vorhandenen nichtflüchtigen Speichers. Bei jedem vorhandenen zonalen nichtflüchtigen Speicher muss der Speicherort des Jobs die Zone des Laufwerks sein. Bei jedem vorhandenen regionalen nichtflüchtigen Speicher muss der Speicherort des Jobs entweder die Region des Laufwerks oder, wenn Sie Zonen angeben, eine oder beide der Zonen sein, in denen sich der regionale nichtflüchtige Speicher befindet. Wenn Sie keine vorhandenen nichtflüchtigen Speicher angeben, können Sie einen beliebigen Standort auswählen. Weitere Informationen zum Feld allowedLocations.
    • NEW_PERSISTENT_DISK_SIZE: die Größe des neuen nichtflüchtigen Speichers in GB. Die zulässigen Größen hängen vom Typ des nichtflüchtigen Speichers ab, sind jedoch häufig mindestens 10 GB (10) und maximal 64 TB (64000).
    • NEW_PERSISTENT_DISK_TYPE ist der Laufwerkstyp des neuen nichtflüchtigen Speichers, entweder pd-standard, pd-balanced, pd-ssd oder pd-extreme.
    • NEW_PERSISTENT_DISK_NAME ist der Name des neuen nichtflüchtigen Speichers.

  • Wenn Sie eine VM-Instanzvorlage für diesen Job verwenden, erstellen Sie wie zuvor eine JSON-Datei, ersetzen Sie dabei das Feld instances durch Folgendes:

    "instances": [
    {
        "instanceTemplate": "INSTANCE_TEMPLATE_NAME"
    }
],
...

    Dabei ist INSTANCE_TEMPLATE_NAME der Name der Instanzvorlage für diesen Job. Bei einem Job, der nichtflüchtige Speicher verwendet, muss mit dieser Instanzvorlage die nichtflüchtigen Speicher definiert und angehängt werden, die der Job verwenden soll. In diesem Beispiel muss in der Vorlage ein neuer nichtflüchtiger Speicher mit dem Namen NEW_PERSISTENT_DISK_NAME definiert und angehängt und ein vorhandener nichtflüchtiger Speicher mit dem Namen EXISTING_PERSISTENT_DISK_NAME angehängt werden.

Lokale SSD verwenden

Bei einem Job, der lokale SSDs verwendet, gelten folgende Einschränkungen:

Sie können einen Job erstellen, der eine lokale SSD mit der gcloud CLI oder der Batch API verwendet. Im folgenden Beispiel wird beschrieben, wie Sie einen Job erstellen, mit dem eine lokale SSD erstellt, angehängt und bereitgestellt wird. Der Job hat außerdem 3 Aufgaben, mit denen jeweils ein Skript zum Erstellen einer Datei mit dem Namen output_task_TASK_INDEX.txt auf der lokalen SSD ausgeführt wird, wobei TASK_INDEX der Index jeder Aufgabe ist: 0, 1 und 2.

gcloud

Verwenden Sie den Befehl gcloud batch jobs submit, um einen Job zu erstellen, der lokale SSDs mit der gcloud CLI verwendet. Erstellen und hängen Sie in der JSON-Konfigurationsdatei des Jobs das Feld instances an und hängen Sie die lokalen SSDs im Feld volumes an.

  1. Erstellen Sie eine JSON-Datei.

    • Wenn Sie für diesen Job keine Instanzvorlage verwenden, erstellen Sie eine JSON-Datei mit folgendem Inhalt:

      {
    "allocationPolicy": {
        "instances": [
            {
                "policy": {
                    "machineType": MACHINE_TYPE,
                    "disks": [
                        {
                            "newDisk": {
                                "sizeGb": LOCAL_SSD_SIZE,
                                "type": "local-ssd"
                            },
                            "deviceName": "LOCAL_SSD_NAME"
                        }
                    ]
                }
            }
        ]
    },
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/disks/LOCAL_SSD_NAME/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "deviceName": "LOCAL_SSD_NAME",
                        "mountPath": "/mnt/disks/LOCAL_SSD_NAME",
                        "mountOptions": "rw,async"
                    }
                ]
            },
            "taskCount":3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

      Dabei gilt:

      • MACHINE_TYPE: der Maschinentyp der VMs des Jobs vordefiniert oder benutzerdefiniert. Die zulässige Anzahl lokaler SSDs hängt vom Maschinentyp für die VMs Ihres Jobs ab.
      • LOCAL_SSD_NAME ist der Name einer lokalen SSD, die für diesen Job erstellt wurde.
      • LOCAL_SSD_SIZE: die Größe aller lokalen SSDs in GB. Jede lokale SSD ist 375 GB groß. Dieser Wert muss also ein Vielfaches von 375 GB sein. Setzen Sie diesen Wert beispielsweise für 2 lokale SSDs auf 750 GB.

    • Wenn Sie eine VM-Instanzvorlage für diesen Job verwenden, erstellen Sie wie zuvor eine JSON-Datei, ersetzen Sie dabei das Feld instances durch Folgendes:

      "instances": [
    {
        "instanceTemplate": "INSTANCE_TEMPLATE_NAME"
    }
],

      Dabei ist INSTANCE_TEMPLATE_NAME der Name der Instanzvorlage für diesen Job. Bei einem Job, der lokale SSDs verwendet, muss diese Instanzvorlage die lokalen SSDs definieren und anhängen, die der Job verwenden soll. In diesem Beispiel muss in der Vorlage eine lokale SSD namens LOCAL_SSD_NAME definiert und angehängt werden.

  2. Führen Sie dazu diesen Befehl aus:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Dabei gilt:

    • JOB_NAME: der Name des Jobs.
    • LOCATION: Der Standort des Jobs.
    • JSON_CONFIGURATION_FILE: Der Pfad für eine JSON-Datei mit den Konfigurationsdetails des Jobs.

API

Verwenden Sie die Methode jobs.create, um einen Job zu erstellen, der lokale SSDs mit der Batch API verwendet. Erstellen Sie in der Anfrage die lokalen SSDs im Feld instances und hängen Sie sie an. Stellen Sie die lokalen SSDs im Feld volumes bereit.

  • Wenn Sie keine Instanzvorlage für diesen Job verwenden, stellen Sie die folgende Anfrage:

    POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

{
    "allocationPolicy": {
        "instances": [
            {
                "policy": {
                    "machineType": MACHINE_TYPE,
                    "disks": [
                        {
                            "newDisk": {
                                "sizeGb": LOCAL_SSD_SIZE,
                                "type": "local-ssd"
                            },
                            "deviceName": "LOCAL_SSD_NAME"
                        }
                    ]
                }
            }
        ]
    },
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/disks/LOCAL_SSD_NAME/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "deviceName": "LOCAL_SSD_NAME",
                        "mountPath": "/mnt/disks/LOCAL_SSD_NAME",
                        "mountOptions": "rw,async"
                    }
                ]
            },
            "taskCount":3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

    Dabei gilt:

    • PROJECT_ID: Die Projekt-ID Ihres Projekts.
    • LOCATION: Der Standort des Jobs.
    • JOB_NAME: der Name des Jobs.
    • MACHINE_TYPE: der Maschinentyp der VMs des Jobs vordefiniert oder benutzerdefiniert. Die zulässige Anzahl lokaler SSDs hängt vom Maschinentyp für die VMs Ihres Jobs ab.
    • LOCAL_SSD_NAME ist der Name einer lokalen SSD, die für diesen Job erstellt wurde.
    • LOCAL_SSD_SIZE: die Größe aller lokalen SSDs in GB. Jede lokale SSD ist 375 GB groß. Dieser Wert muss also ein Vielfaches von 375 GB sein. Setzen Sie diesen Wert beispielsweise für 2 lokale SSDs auf 750 GB.

  • Wenn Sie eine VM-Instanzvorlage für diesen Job verwenden, erstellen Sie wie zuvor eine JSON-Datei, ersetzen Sie dabei das Feld instances durch Folgendes:

    "instances": [
    {
        "instanceTemplate": "INSTANCE_TEMPLATE_NAME"
    }
],
...

    Dabei ist INSTANCE_TEMPLATE_NAME der Name der Instanzvorlage für diesen Job. Bei einem Job, der lokale SSDs verwendet, muss diese Instanzvorlage die lokalen SSDs definieren und anhängen, die der Job verwenden soll. In diesem Beispiel muss in der Vorlage eine lokale SSD namens LOCAL_SSD_NAME definiert und angehängt werden.

Cloud Storage-Bucket verwenden

Wählen Sie eine der folgenden Methoden aus, um einen Job zu erstellen, der einen vorhandenen Cloud Storage-Bucket verwendet:

  • Empfohlen: Stellen Sie einen Bucket direkt auf den VMs Ihres Jobs bereit. Geben Sie dazu den Bucket in der Definition des Jobs an, wie in diesem Abschnitt gezeigt. Wenn der Job ausgeführt wird, wird der Bucket automatisch mit Cloud Storage FUSE auf den VMs für Ihren Job bereitgestellt.
  • einen Job mit Aufgaben erstellen, die direkt mit dem gsutil-Befehlszeilentool oder Clientbibliotheken für die Cloud Storage API auf einen Cloud Storage-Bucket zugreifen Informationen dazu, wie Sie direkt von einer VM aus auf einen Cloud Storage-Bucket zugreifen, finden Sie in der Compute Engine-Dokumentation unter Daten aus Cloud Storage-Buckets schreiben und lesen.

Bevor Sie einen Job erstellen, für den ein Bucket verwendet wird, müssen Sie einen Bucket erstellen oder einen vorhandenen Bucket identifizieren. Weitere Informationen finden Sie unter Buckets erstellen und Buckets auflisten.

Sie können einen Job erstellen, der einen Cloud Storage-Bucket mit der Google Cloud Console, der gcloud CLI, Batch API, GO, Java, Node.js oder Python verwendet.

Im folgenden Beispiel wird beschrieben, wie Sie einen Job erstellen, der einen Cloud Storage-Bucket bereitstellt. Der Job hat außerdem 3 Aufgaben, mit denen jeweils ein Skript zum Erstellen einer Datei mit dem Namen output_task_TASK_INDEX.txt ausgeführt wird und wobei TASK_INDEX der Index jeder Aufgabe ist: 0, 1 und 2.

Console

So erstellen Sie einen Job, der einen Cloud Storage-Bucket mit der Google Cloud Console verwendet:

  1. Rufen Sie in der Google Cloud Console die Seite Jobliste auf.

    Zur Jobliste

  2. Klicken Sie auf Erstellen. Die Seite Batchjob erstellen wird geöffnet.

  3. Geben Sie im Feld Jobname den Wert example-bucket-job ein.

  4. Wählen Sie im Feld Region den Standort für diesen Job aus.

    Wählen Sie beispielsweise us-central1 (Iowa) (Standardeinstellung) aus.

  5. Wählen Sie im Feld Zone die Option any (Standard) aus.

  6. Wählen Sie im Abschnitt VM-Bereitstellungsmodell die Option Standard aus (Standardeinstellung).

  7. Klicken Sie auf Allgemein.

  8. Wählen Sie im Feld Reihe die Option E2 (Standardeinstellung) aus.

  9. Wählen Sie im Feld Maschinentyp die Option e2-medium (2 vCPUs, 4 GB Arbeitsspeicher) (Standardeinstellung) aus.

  10. Führen Sie im Bereich Neue ausführbare Option die folgenden Schritte aus:

    1. Klicken Sie das Kästchen Skript an. Ein Textfeld wird angezeigt.

    2. Geben Sie das folgende Skript in das Textfeld ein:

      echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt

      Dabei ist MOUNT_PATH der Bereitstellungspfad, mit dem die ausführbaren Jobs dieses Jobs verwendet werden, um auf einen vorhandenen Cloud Storage-Bucket zuzugreifen. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen Bucket beispielsweise mit einem Verzeichnis namens my-bucket darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-bucket fest.

    3. Klicken Sie auf Fertig.

  11. Geben Sie im Feld Anzahl der Aufgaben den Wert 3 ein.

  12. Geben Sie im Feld Parallelismus den Standardwert 1 ein.

  13. Geben Sie im Abschnitt Aufgabenressourcen die für jede Aufgabe erforderliche Anzahl von VM-Ressourcen an. Gehen Sie dazu so vor:

    1. Geben Sie im Feld Kerne 1 (Standard) ein.

    2. Geben Sie im Feld Arbeitsspeicher den Wert 0.5 (Standard) ein.

  14. Klicken Sie auf Neues Volume hinzufügen. Der Bereich Neues Volume wird angezeigt.

  15. Führen Sie im Bereich Neues Volume die folgenden Schritte aus:

    1. Wählen Sie im Abschnitt Volume-Typ die Option Cloud Storage-Bucket aus.

    2. Geben Sie im Feld Name des Storage-Buckets den Namen eines vorhandenen Buckets ein.

      Geben Sie beispielsweise den Bucket ein, den Sie in der Ausführung dieses Jobs ausgeführt haben.

    3. Geben Sie im Feld Bereitstellungspfad den Bereitstellungspfad des Buckets (MOUNT_PATH) ein, den Sie im vorherigen Schritt angegeben haben.

    4. Klicken Sie auf Fertig.

  16. Klicken Sie auf Erstellen.

Auf der Seite Jobliste wird der von Ihnen erstellte Job angezeigt.

gcloud

Verwenden Sie den Befehl gcloud batch jobs submit, um einen Job zu erstellen, der einen Cloud Storage-Bucket mit der gcloud CLI verwendet. Stellen Sie in der JSON-Konfigurationsdatei des Jobs den Bucket im Feld volumes bereit.

So erstellen Sie beispielsweise einen Job, der Dateien in Cloud Storage ausgibt:

  1. Erstellen Sie eine package.json-Datei mit folgendem Inhalt:

    {
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "gcs": {
                            "remotePath": "BUCKET_PATH"
                        },
                        "mountPath": "MOUNT_PATH"
                    }
                ]
            },
            "taskCount": 3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

    Dabei gilt:

    • BUCKET_PATH: der Pfad des Bucket-Verzeichnisses, auf das dieser Job zugreifen soll. Er muss mit dem Namen des Buckets beginnen. Bei einem Bucket mit dem Namen BUCKET_NAME stellt der Pfad BUCKET_NAME beispielsweise das Stammverzeichnis des Buckets dar. Der Pfad BUCKET_NAME/subdirectory stellt das Unterverzeichnis subdirectory dar.
    • MOUNT_PATH: Der Bereitstellungspfad, den die ausführbaren Jobs des Jobs verwenden, um auf diesen Bucket zuzugreifen. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen Bucket beispielsweise mit einem Verzeichnis namens my-bucket darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-bucket fest.

  2. Führen Sie dazu diesen Befehl aus:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Dabei gilt:

    • JOB_NAME: der Name des Jobs.
    • LOCATION: Der Standort des Jobs.
    • JSON_CONFIGURATION_FILE: Der Pfad für eine JSON-Datei mit den Konfigurationsdetails des Jobs.

API

Wenn Sie einen Job erstellen möchten, der einen Cloud Storage-Bucket mit der Batch API verwendet, verwenden Sie die Methode jobs.create und stellen Sie den Bucket im Feld volumes bereit.

POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

{
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "gcs": {
                            "remotePath": "BUCKET_PATH"
                        },
                        "mountPath": "MOUNT_PATH"
                    }
                ]
            },
            "taskCount": 3
        }
    ],
    "logsPolicy": {
            "destination": "CLOUD_LOGGING"
    }
}

Dabei gilt:

  • PROJECT_ID: Die Projekt-ID Ihres Projekts.
  • LOCATION: Der Standort des Jobs.
  • JOB_NAME: der Name des Jobs.
  • BUCKET_PATH: der Pfad des Bucket-Verzeichnisses, auf das dieser Job zugreifen soll. Er muss mit dem Namen des Buckets beginnen. Bei einem Bucket mit dem Namen BUCKET_NAME stellt der Pfad BUCKET_NAME beispielsweise das Stammverzeichnis des Buckets dar. Der Pfad BUCKET_NAME/subdirectory stellt das Unterverzeichnis subdirectory dar.
  • MOUNT_PATH: Der Bereitstellungspfad, den die ausführbaren Jobs des Jobs verwenden, um auf diesen Bucket zuzugreifen. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen Bucket beispielsweise mit einem Verzeichnis namens my-bucket darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-bucket fest.

Einfach loslegen (Go)

Go

Weitere Informationen finden Sie in der Referenzdokumentation zur Batch Go API. 

import (
	"context"
	"fmt"
	"io"

	batch "cloud.google.com/go/batch/apiv1"
	batchpb "google.golang.org/genproto/googleapis/cloud/batch/v1"
	durationpb "google.golang.org/protobuf/types/known/durationpb"
)

// Creates and runs a job that executes the specified script
func createScriptJobWithBucket(w io.Writer, projectID, region, jobName, bucketName string) error {
	// projectID := "your_project_id"
	// region := "us-central1"
	// jobName := "some-job"
	// jobName := "some-bucket"

	ctx := context.Background()
	batchClient, err := batch.NewClient(ctx)
	if err != nil {
		return fmt.Errorf("NewClient: %v", err)
	}
	defer batchClient.Close()

	// Define what will be done as part of the job.
	command := &batchpb.Runnable_Script_Text{
		Text: "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/share/output_task_${BATCH_TASK_INDEX}.txt",
	}

	// Specify the Google Cloud Storage bucket to mount
	volume := &batchpb.Volume{
		Source: &batchpb.Volume_Gcs{
			Gcs: &batchpb.GCS{
				RemotePath: bucketName,
			},
		},
		MountPath:    "/mnt/share",
		MountOptions: []string{},
	}

	// We can specify what resources are requested by each task.
	resources := &batchpb.ComputeResource{
		// CpuMilli is milliseconds per cpu-second. This means the task requires 50% of a single CPUs.
		CpuMilli:  500,
		MemoryMib: 16,
	}

	taskSpec := &batchpb.TaskSpec{
		Runnables: []*batchpb.Runnable{{
			Executable: &batchpb.Runnable_Script_{
				Script: &batchpb.Runnable_Script{Command: command},
			},
		}},
		ComputeResource: resources,
		MaxRunDuration: &durationpb.Duration{
			Seconds: 3600,
		},
		MaxRetryCount: 2,
		Volumes:       []*batchpb.Volume{volume},
	}

	// Tasks are grouped inside a job using TaskGroups.
	taskGroups := []*batchpb.TaskGroup{
		{
			TaskCount: 4,
			TaskSpec:  taskSpec,
		},
	}

	// Policies are used to define on what kind of virtual machines the tasks will run on.
	// In this case, we tell the system to use "e2-standard-4" machine type.
	// Read more about machine types here: https://cloud.google.com/compute/docs/machine-types
	allocationPolicy := &batchpb.AllocationPolicy{
		Instances: []*batchpb.AllocationPolicy_InstancePolicyOrTemplate{{
			PolicyTemplate: &batchpb.AllocationPolicy_InstancePolicyOrTemplate_Policy{
				Policy: &batchpb.AllocationPolicy_InstancePolicy{
					MachineType: "e2-standard-4",
				},
			},
		}},
	}

	// We use Cloud Logging as it's an out of the box available option
	logsPolicy := &batchpb.LogsPolicy{
		Destination: batchpb.LogsPolicy_CLOUD_LOGGING,
	}

	jobLabels := map[string]string{"env": "testing", "type": "script"}

	// The job's parent is the region in which the job will run
	parent := fmt.Sprintf("projects/%s/locations/%s", projectID, region)

	job := batchpb.Job{
		TaskGroups:       taskGroups,
		AllocationPolicy: allocationPolicy,
		Labels:           jobLabels,
		LogsPolicy:       logsPolicy,
	}

	req := &batchpb.CreateJobRequest{
		Parent: parent,
		JobId:  jobName,
		Job:    &job,
	}

	created_job, err := batchClient.CreateJob(ctx, req)
	if err != nil {
		return fmt.Errorf("unable to create job: %v", err)
	}

	fmt.Fprintf(w, "Job created: %v\n", created_job)

	return nil
}

Java

Java

Weitere Informationen finden Sie in der Referenzdokumentation zur Batch Java API. 


import com.google.cloud.batch.v1.AllocationPolicy;
import com.google.cloud.batch.v1.AllocationPolicy.InstancePolicy;
import com.google.cloud.batch.v1.AllocationPolicy.InstancePolicyOrTemplate;
import com.google.cloud.batch.v1.BatchServiceClient;
import com.google.cloud.batch.v1.ComputeResource;
import com.google.cloud.batch.v1.CreateJobRequest;
import com.google.cloud.batch.v1.GCS;
import com.google.cloud.batch.v1.Job;
import com.google.cloud.batch.v1.LogsPolicy;
import com.google.cloud.batch.v1.LogsPolicy.Destination;
import com.google.cloud.batch.v1.Runnable;
import com.google.cloud.batch.v1.Runnable.Script;
import com.google.cloud.batch.v1.TaskGroup;
import com.google.cloud.batch.v1.TaskSpec;
import com.google.cloud.batch.v1.Volume;
import com.google.protobuf.Duration;
import java.io.IOException;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class CreateWithMountedBucket {

  public static void main(String[] args)
      throws IOException, ExecutionException, InterruptedException, TimeoutException {
    // TODO(developer): Replace these variables before running the sample.
    // Project ID or project number of the Cloud project you want to use.
    String projectId = "YOUR_PROJECT_ID";

    // Name of the region you want to use to run the job. Regions that are
    // available for Batch are listed on: https://cloud.google.com/batch/docs/get-started#locations
    String region = "europe-central2";

    // The name of the job that will be created.
    // It needs to be unique for each project and region pair.
    String jobName = "JOB_NAME";

    // Name of the bucket to be mounted for your Job.
    String bucketName = "BUCKET_NAME";

    createScriptJobWithBucket(projectId, region, jobName, bucketName);
  }

  // This method shows how to create a sample Batch Job that will run
  // a simple command on Cloud Compute instances.
  public static void createScriptJobWithBucket(String projectId, String region, String jobName,
      String bucketName)
      throws IOException, ExecutionException, InterruptedException, TimeoutException {
    // Initialize client that will be used to send requests. This client only needs to be created
    // once, and can be reused for multiple requests. After completing all of your requests, call
    // the `batchServiceClient.close()` method on the client to safely
    // clean up any remaining background resources.
    try (BatchServiceClient batchServiceClient = BatchServiceClient.create()) {

      // Define what will be done as part of the job.
      Runnable runnable =
          Runnable.newBuilder()
              .setScript(
                  Script.newBuilder()
                      .setText(
                          "echo Hello world from task ${BATCH_TASK_INDEX}. >> "
                              + "/mnt/share/output_task_${BATCH_TASK_INDEX}.txt")
                      // You can also run a script from a file. Just remember, that needs to be a
                      // script that's already on the VM that will be running the job.
                      // Using setText() and setPath() is mutually exclusive.
                      // .setPath("/tmp/test.sh")
                      .build())
              .build();

      Volume volume = Volume.newBuilder()
          .setGcs(GCS.newBuilder()
              .setRemotePath(bucketName)
              .build())
          .setMountPath("/mnt/share")
          .build();

      // We can specify what resources are requested by each task.
      ComputeResource computeResource =
          ComputeResource.newBuilder()
              // In milliseconds per cpu-second. This means the task requires 50% of a single CPUs.
              .setCpuMilli(500)
              // In MiB.
              .setMemoryMib(16)
              .build();

      TaskSpec task =
          TaskSpec.newBuilder()
              // Jobs can be divided into tasks. In this case, we have only one task.
              .addRunnables(runnable)
              .addVolumes(volume)
              .setComputeResource(computeResource)
              .setMaxRetryCount(2)
              .setMaxRunDuration(Duration.newBuilder().setSeconds(3600).build())
              .build();

      // Tasks are grouped inside a job using TaskGroups.
      // Currently, it's possible to have only one task group.
      TaskGroup taskGroup = TaskGroup.newBuilder().setTaskCount(4).setTaskSpec(task).build();

      // Policies are used to define on what kind of virtual machines the tasks will run on.
      // In this case, we tell the system to use "e2-standard-4" machine type.
      // Read more about machine types here: https://cloud.google.com/compute/docs/machine-types
      InstancePolicy instancePolicy =
          InstancePolicy.newBuilder().setMachineType("e2-standard-4").build();

      AllocationPolicy allocationPolicy =
          AllocationPolicy.newBuilder()
              .addInstances(InstancePolicyOrTemplate.newBuilder().setPolicy(instancePolicy).build())
              .build();

      Job job =
          Job.newBuilder()
              .addTaskGroups(taskGroup)
              .setAllocationPolicy(allocationPolicy)
              .putLabels("env", "testing")
              .putLabels("type", "script")
              .putLabels("mount", "bucket")
              // We use Cloud Logging as it's an out of the box available option.
              .setLogsPolicy(
                  LogsPolicy.newBuilder().setDestination(Destination.CLOUD_LOGGING).build())
              .build();

      CreateJobRequest createJobRequest =
          CreateJobRequest.newBuilder()
              // The job's parent is the region in which the job will run.
              .setParent(String.format("projects/%s/locations/%s", projectId, region))
              .setJob(job)
              .setJobId(jobName)
              .build();

      Job result =
          batchServiceClient
              .createJobCallable()
              .futureCall(createJobRequest)
              .get(5, TimeUnit.MINUTES);

      System.out.printf("Successfully created the job: %s", result.getName());
    }
  }
}

Node.js

Node.js

Weitere Informationen finden Sie in der Referenzdokumentation zur Batch Node.js API. 

/**
 * TODO(developer): Uncomment and replace these variables before running the sample.
 */
// const projectId = 'YOUR_PROJECT_ID';
/**
 * The region you want to the job to run in. The regions that support Batch are listed here:
 * https://cloud.google.com/batch/docs/get-started#locations
 */
// const region = 'us-central-1';
/**
 * The name of the job that will be created.
 * It needs to be unique for each project and region pair.
 */
// const jobName = 'YOUR_JOB_NAME';
/**
 * The name of the bucket to be mounted.
 */
// const bucketName = 'YOUR_BUCKET_NAME';

// Imports the Batch library
const batchLib = require('@google-cloud/batch');
const batch = batchLib.protos.google.cloud.batch.v1;

// Instantiates a client
const batchClient = new batchLib.v1.BatchServiceClient();

// Define what will be done as part of the job.
const task = new batch.TaskSpec();
const runnable = new batch.Runnable();
runnable.script = new batch.Runnable.Script();
runnable.script.text =
  'echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/share/output_task_${BATCH_TASK_INDEX}.txt';
// You can also run a script from a file. Just remember, that needs to be a script that's
// already on the VM that will be running the job. Using runnable.script.text and runnable.script.path is mutually
// exclusive.
// runnable.script.path = '/tmp/test.sh'
task.runnables = [runnable];

const gcsBucket = new batch.GCS();
gcsBucket.remotePath = bucketName;
const gcsVolume = new batch.Volume();
gcsVolume.gcs = gcsBucket;
gcsVolume.mountPath = '/mnt/share';
task.volumes = [gcsVolume];

// We can specify what resources are requested by each task.
const resources = new batch.ComputeResource();
resources.cpuMilli = 2000; // in milliseconds per cpu-second. This means the task requires 2 whole CPUs.
resources.memoryMib = 16;
task.computeResource = resources;

task.maxRetryCount = 2;
task.maxRunDuration = {seconds: 3600};

// Tasks are grouped inside a job using TaskGroups.
const group = new batch.TaskGroup();
group.taskCount = 4;
group.taskSpec = task;

// Policies are used to define on what kind of virtual machines the tasks will run on.
// In this case, we tell the system to use "e2-standard-4" machine type.
// Read more about machine types here: https://cloud.google.com/compute/docs/machine-types
const allocationPolicy = new batch.AllocationPolicy();
const policy = new batch.AllocationPolicy.InstancePolicy();
policy.machineType = 'e2-standard-4';
const instances = new batch.AllocationPolicy.InstancePolicyOrTemplate();
instances.policy = policy;
allocationPolicy.instances = [instances];

const job = new batch.Job();
job.name = jobName;
job.taskGroups = [group];
job.allocationPolicy = allocationPolicy;
job.labels = {env: 'testing', type: 'script'};
// We use Cloud Logging as it's an option available out of the box
job.logsPolicy = new batch.LogsPolicy();
job.logsPolicy.destination = batch.LogsPolicy.Destination.CLOUD_LOGGING;

// The job's parent is the project and region in which the job will run
const parent = `projects/${projectId}/locations/${region}`;

async function callCreateJob() {
  // Construct request
  const request = {
    parent,
    jobId: jobName,
    job,
  };

  // Run request
  const response = await batchClient.createJob(request);
  console.log(response);
}

callCreateJob();

Python

Python

Weitere Informationen finden Sie in der Referenzdokumentation zur Batch Python API. 

from google.cloud import batch_v1

def create_script_job_with_bucket(project_id: str, region: str, job_name: str, bucket_name: str) -> batch_v1.Job:
    """
    This method shows how to create a sample Batch Job that will run
    a simple command on Cloud Compute instances.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use to run the job. Regions that are
            available for Batch are listed on: https://cloud.google.com/batch/docs/get-started#locations
        job_name: the name of the job that will be created.
            It needs to be unique for each project and region pair.
        bucket_name: name of the bucket to be mounted for your Job.

    Returns:
        A job object representing the job created.
    """
    client = batch_v1.BatchServiceClient()

    # Define what will be done as part of the job.
    task = batch_v1.TaskSpec()
    runnable = batch_v1.Runnable()
    runnable.script = batch_v1.Runnable.Script()
    runnable.script.text = "echo Hello world from task ${BATCH_TASK_INDEX}. >> /mnt/share/output_task_${BATCH_TASK_INDEX}.txt"
    task.runnables = [runnable]

    gcs_bucket = batch_v1.GCS()
    gcs_bucket.remote_path = bucket_name
    gcs_volume = batch_v1.Volume()
    gcs_volume.gcs = gcs_bucket
    gcs_volume.mount_path = '/mnt/share'
    task.volumes = [gcs_volume]

    # We can specify what resources are requested by each task.
    resources = batch_v1.ComputeResource()
    resources.cpu_milli = 500  # in milliseconds per cpu-second. This means the task requires 50% of a single CPUs.
    resources.memory_mib = 16
    task.compute_resource = resources

    task.max_retry_count = 2
    task.max_run_duration = "3600s"

    # Tasks are grouped inside a job using TaskGroups.
    # Currently, it's possible to have only one task group.
    group = batch_v1.TaskGroup()
    group.task_count = 4
    group.task_spec = task

    # Policies are used to define on what kind of virtual machines the tasks will run on.
    # In this case, we tell the system to use "e2-standard-4" machine type.
    # Read more about machine types here: https://cloud.google.com/compute/docs/machine-types
    allocation_policy = batch_v1.AllocationPolicy()
    policy = batch_v1.AllocationPolicy.InstancePolicy()
    policy.machine_type = "e2-standard-4"
    instances = batch_v1.AllocationPolicy.InstancePolicyOrTemplate()
    instances.policy = policy
    allocation_policy.instances = [instances]

    job = batch_v1.Job()
    job.task_groups = [group]
    job.allocation_policy = allocation_policy
    job.labels = {"env": "testing", "type": "script", "mount": "bucket"}
    # We use Cloud Logging as it's an out of the box available option
    job.logs_policy = batch_v1.LogsPolicy()
    job.logs_policy.destination = batch_v1.LogsPolicy.Destination.CLOUD_LOGGING

    create_request = batch_v1.CreateJobRequest()
    create_request.job = job
    create_request.job_id = job_name
    # The job's parent is the region in which the job will run
    create_request.parent = f"projects/{project_id}/locations/{region}"

    return client.create_job(create_request)

Netzwerkdateisystem verwenden

Sie können einen Job erstellen, der ein vorhandenes Netzwerkdateisystem (Network File System, NFS) verwendet, z. B. eine Filestore-Dateifreigabe, und zwar mit der Google Cloud Console, der gcloud CLI oder der Batch API.

Bevor Sie einen Job erstellen, der einen NFS verwendet, prüfen Sie, ob die Firewall Ihres Netzwerks ordnungsgemäß konfiguriert ist, um Traffic zwischen den VMs des Jobs und dem NFS zuzulassen. Weitere Informationen finden Sie unter Firewallregeln für Filestore konfigurieren.

Im folgenden Beispiel wird beschrieben, wie Sie einen Job erstellen, der ein NFS-Element angibt und bereitstellt. Der Job hat außerdem 3 Aufgaben, mit denen jeweils ein Skript zum Erstellen einer Datei im NFS mit dem Namen output_task_TASK_INDEX.txt ausgeführt wird, wobei TASK_INDEX der Index jeder Aufgabe ist: 0, 1 und 2.

Console

So erstellen Sie einen Job, der einen Cloud Storage-Bucket mit der Google Cloud Console verwendet:

  1. Rufen Sie in der Google Cloud Console die Seite Jobliste auf.

    Zur Jobliste

  2. Klicken Sie auf Erstellen. Die Seite Batchjob erstellen wird geöffnet.

  3. Geben Sie im Feld Jobname den Wert example-nfs-job ein.

  4. Wählen Sie im Feld Region den Standort für diesen Job aus.

    Wählen Sie beispielsweise us-central1 (Iowa) (Standardeinstellung) aus.

  5. Wählen Sie im Feld Zone die Option any (Standard) aus.

  6. Wählen Sie im Abschnitt VM-Bereitstellungsmodell die Option Standard aus (Standardeinstellung).

  7. Klicken Sie auf Allgemein.

  8. Wählen Sie im Feld Reihe die Option E2 (Standardeinstellung) aus.

  9. Wählen Sie im Feld Maschinentyp die Option e2-medium (2 vCPUs, 4 GB Arbeitsspeicher) (Standardeinstellung) aus.

  10. Führen Sie im Bereich Neue ausführbare Option die folgenden Schritte aus:

    1. Klicken Sie das Kästchen Skript an. Ein Textfeld wird angezeigt.

    2. Geben Sie das folgende Skript in das Textfeld ein:

      echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt

      Dabei ist MOUNT_PATH der Bereitstellungspfad, mit dem der Job für den Zugriff auf diesen NFS ausgeführt wird. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen NFS beispielsweise mit einem Verzeichnis namens my-nfs darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-nfs fest.

    3. Klicken Sie auf Fertig.

  11. Geben Sie im Feld Anzahl der Aufgaben den Wert 3 ein.

  12. Geben Sie im Feld Parallelismus den Standardwert 1 ein.

  13. Geben Sie im Abschnitt Aufgabenressourcen die für jede Aufgabe erforderliche Anzahl von VM-Ressourcen an. Gehen Sie dazu so vor:

    1. Geben Sie im Feld Kerne 1 (Standard) ein.

    2. Geben Sie im Feld Arbeitsspeicher den Wert 0.5 (Standard) ein.

  14. Klicken Sie auf Neues Volume hinzufügen. Der Bereich Neues Volume wird angezeigt.

  15. Führen Sie im Bereich Neues Volume die folgenden Schritte aus:

    1. Wählen Sie im Abschnitt Volume-Typ die Option Netzwerkdateisystem aus.

    2. Geben Sie in das Feld Dateiserver die IP-Adresse des Servers ein, auf dem sich der in der Ausführung dieses Jobs angegebene NFS befindet.

      Wenn Ihre NFS-Datei beispielsweise eine Filestore-Dateifreigabe ist, geben Sie die IP-Adresse der VM an, die die Filestore-Dateifreigabe hostet. Diese erhalten Sie, wenn Sie die Filestore-VM beschreiben.

    3. Geben Sie im Feld Remote-Pfad einen Pfad ein, der auf das NFS zugreifen kann, das Sie im vorherigen Schritt angegeben haben.

      Der Pfad des NFS-Verzeichnisses muss mit einem / beginnen, gefolgt vom Stammverzeichnis des NFS-Verzeichnisses.

    4. Geben Sie im Feld Bereitstellungspfad den Bereitstellungspfad zum NFS (MOUNT_PATH) ein, den Sie im vorherigen Schritt angegeben haben.

    5. Klicken Sie auf Fertig.

  16. Klicken Sie auf Erstellen.

Auf der Seite Jobliste wird der von Ihnen erstellte Job angezeigt.

gcloud

Verwenden Sie den Befehl gcloud batch jobs submit, um einen Job zu erstellen, der mit der gcloud CLI ein NFS verwendet. Stellen Sie in der JSON-Konfigurationsdatei des Jobs den NFS-Wert im Feld volumes bereit.

  1. Erstellen Sie eine package.json-Datei mit folgendem Inhalt:

    {
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "nfs": {
                            "server": "NFS_IP_ADDRESS",
                            "remotePath": "NFS_PATH"
                        },
                        "mountPath": "MOUNT_PATH"
                    }
                ]
            },
            "taskCount": 3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

    Dabei gilt:

    • NFS_IP_ADDRESS ist die IP-Adresse des NFS. Wenn Ihre NFS beispielsweise eine Filestore-Dateifreigabe ist, geben Sie die IP-Adresse der VM an, die die Filestore-Dateifreigabe hostet. Diese erhalten Sie, wenn Sie die Filestore-VM beschreiben.
    • NFS_PATH: Der Pfad des NFS-Verzeichnisses, auf das dieser Job zugreifen soll. Er muss mit einem / beginnen, gefolgt vom Stammverzeichnis des NFS. Bei einer Filestore-Dateifreigabe mit dem Namen FILE_SHARE_NAME stellt beispielsweise der Pfad /FILE_SHARE_NAME das Stammverzeichnis der Dateifreigabe dar und der Pfad /FILE_SHARE_NAME/subdirectory stellt das Unterverzeichnis subdirectory dar.
    • MOUNT_PATH: Der Bereitstellungspfad, den die ausführbaren Jobs des Jobs verwenden, um auf diesen NFS zuzugreifen. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen NFS beispielsweise mit einem Verzeichnis namens my-nfs darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-nfs fest.

  2. Führen Sie dazu diesen Befehl aus:

    gcloud batch jobs submit JOB_NAME \
  --location LOCATION \
  --config JSON_CONFIGURATION_FILE

    Dabei gilt:

    • JOB_NAME: der Name des Jobs.
    • LOCATION: Der Standort des Jobs.
    • JSON_CONFIGURATION_FILE: Der Pfad für eine JSON-Datei mit den Konfigurationsdetails des Jobs.

API

Zum Erstellen eines Jobs, der einen NFS mithilfe der Batch API verwendet, verwenden Sie die Methode jobs.create und stellen den NFS im Feld volumes bereit.

POST https://batch.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/jobs?job_id=JOB_NAME

   {
    "taskGroups": [
        {
            "taskSpec": {
                "runnables": [
                    {
                        "script": {
                            "text": "echo Hello world from task ${BATCH_TASK_INDEX}. >> MOUNT_PATH/output_task_${BATCH_TASK_INDEX}.txt"
                        }
                    }
                ],
                "volumes": [
                    {
                        "nfs": {
                            "server": "NFS_IP_ADDRESS",
                            "remotePath": "NFS_PATH"
                        },
                        "mountPath": "MOUNT_PATH"
                    }
                ]
            },
            "taskCount": 3
        }
    ],
    "logsPolicy": {
        "destination": "CLOUD_LOGGING"
    }
}

Dabei gilt:

  • PROJECT_ID: Die Projekt-ID Ihres Projekts.
  • LOCATION: Der Standort des Jobs.
  • JOB_NAME: der Name des Jobs.
  • NFS_IP_ADDRESS ist die IP-Adresse des Netzwerkdateisystems. Wenn Ihre NFS beispielsweise eine Filestore-Dateifreigabe ist, geben Sie die IP-Adresse der VM an, die die Filestore-Dateifreigabe hostet. Diese erhalten Sie, wenn Sie die Filestore-VM beschreiben.
  • NFS_PATH: Der Pfad des NFS-Verzeichnisses, auf das dieser Job zugreifen soll. Er muss mit einem / beginnen, gefolgt vom Stammverzeichnis des NFS. Bei einer Filestore-Dateifreigabe mit dem Namen FILE_SHARE_NAME stellt beispielsweise der Pfad /FILE_SHARE_NAME das Stammverzeichnis der Dateifreigabe dar und der Pfad /FILE_SHARE_NAME/subdirectory ein Unterverzeichnis.
  • MOUNT_PATH: Der Bereitstellungspfad, den die ausführbaren Jobs des Jobs verwenden, um auf diesen NFS zuzugreifen. Der Pfad muss mit /mnt/disks/ beginnen, gefolgt von einem Verzeichnis oder Pfad, den Sie auswählen. Wenn Sie diesen NFS beispielsweise mit einem Verzeichnis namens my-nfs darstellen möchten, legen Sie den Bereitstellungspfad auf /mnt/disks/my-nfs fest.

Nächste Schritte