JobPreparationTask クラス
特定のコンピューティング ノード上のジョブのタスクの前に実行するジョブ準備タスク。
ジョブの準備を使用して、ジョブのタスクを実行するノードを準備できます。 ジョブの準備で一般的に実行されるアクティビティには、ジョブ内のすべてのタスクで使用される一般的なリソース ファイルのダウンロードが含まれます。 ジョブ準備タスクでは、これらの共通リソース ファイルをノード上の共有場所にダウンロードできます。 (AZ_BATCH_NODE_ROOT_DIRshared)、またはノードでローカル サービスを開始して、そのジョブのすべてのタスクが通信できるようにします。 ジョブ準備タスクが失敗した場合 (つまり、終了コード 0 で終了する前に再試行回数を使い果たす)、Batch はノードでこのジョブのタスクを実行しません。 コンピューティング ノードは、再イメージ化されるまで、このジョブのタスクを実行できません。 コンピューティング ノードはアクティブなままであり、他のジョブに使用できます。 ジョブ準備タスクは、同じノードで複数回実行できます。 そのため、再実行を処理するジョブ準備タスクを記述する必要があります。 ノードが再起動されると、ジョブの他のタスクをスケジュールする前に、再実行OnNodeRebootAfterSuccess が true の場合、またはジョブ準備タスクが以前に完了しなかった場合は、コンピューティング ノードでジョブ準備タスクが再度実行されます。 ノードを再イメージ化すると、ジョブのタスクをスケジュールする前に、ジョブ準備タスクが再度実行されます。 ノードで回復操作がトリガーされると、バッチによってタスクが再試行されます。 復旧操作の例としては、異常なノードが再起動されたときや、ホストの障害によってコンピューティング ノードが消失した場合 (ただし、これらに限定されません) があります。 回復操作による再試行は に依存せず、maxTaskRetryCount に対してカウントされません。 maxTaskRetryCount が 0 の場合でも、回復操作による内部再試行が発生する可能性があります。 このため、すべてのタスクはべき等である必要があります。 つまり、タスクは、破損や重複するデータを引き起こさずに中断および再起動されることを許容する必要があります。 実行時間の長いタスクのベスト プラクティスは、何らかの形式のチェックポイント処理を使用することです。
Azure に送信するには、必要なすべてのパラメーターを設定する必要があります。
- 継承
-
JobPreparationTask
コンストラクター
JobPreparationTask(*, command_line: str, id: str = None, container_settings=None, resource_files=None, environment_settings=None, constraints=None, wait_for_success: bool = None, user_identity=None, rerun_on_node_reboot_after_success: bool = None, **kwargs)パラメーター
- id
- str
ID には、ハイフンやアンダースコアを含む英数字を任意に組み合わせて使用でき、64 文字を超えることはできません。 このプロパティを指定しない場合、Batch サービスは既定値の 'jobpreparation' を割り当てます。 ジョブ内の他のタスクは、ジョブ準備タスクと同じ ID を持つ必要はありません。 同じ ID のタスクを送信しようとすると、Batch サービスはエラー コード TaskIdSameAsJobPreparationTask を使用して要求を拒否します。REST API を直接呼び出す場合、HTTP 状態コードは 409 (競合) です。
- command_line
- str
必須。 コマンド ラインはシェルでは実行されないため、環境変数の拡張などのシェル機能を利用することはできません。 このような機能を利用する場合は、コマンド ラインでシェルを呼び出す必要があります。たとえば、Windows では "cmd /c MyCommand" を使用し、Linux では "/bin/sh -c MyCommand" を使用します。 コマンド ラインがファイル パスを参照している場合は、相対パス (Task 作業ディレクトリに対する相対パス) を使用するか、Batch 指定の環境変数 (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables) を使用する必要があります。
- container_settings
- TaskContainerSettings
ジョブ準備タスクを実行するコンテナーの設定。 これを指定すると、AZ_BATCH_NODE_ROOT_DIRの下にあるすべてのディレクトリ (ノード上のAzure Batchディレクトリのルート) がコンテナーに再帰的にマップされ、すべての Task 環境変数がコンテナーにマップされ、Task コマンド ラインがコンテナーで実行されます。 AZ_BATCH_NODE_ROOT_DIR外のコンテナーで生成されたファイルはホスト ディスクに反映されない可能性があります。つまり、Batch ファイル API はそれらのファイルにアクセスできません。
- resource_files
- list[ResourceFile]
この要素の下に一覧表示されるファイルは、タスクの作業ディレクトリにあります。 リソース ファイルの一覧には最大サイズがあります。 最大サイズを超えると、要求は失敗し、応答エラー コードは RequestEntityTooLarge になります。 この場合、ResourceFiles のコレクションのサイズを小さくする必要があります。 これは、.zip ファイル、アプリケーション パッケージ、または Docker コンテナーを使用して実現できます。
- environment_settings
- list[EnvironmentSetting]
- wait_for_success
- bool
Batch サービスがジョブ準備タスクが正常に完了するまで待機してから、コンピューティング ノード上のジョブの他のタスクをスケジュールする必要があるかどうか。 ジョブ準備タスクが終了コード 0 で終了すると、正常に完了しました。 true で、ノードでジョブ準備タスクが失敗した場合、Batch サービスはジョブ準備タスクを最大再試行回数 (constraints 要素で指定) まで再試行します。 すべての再試行の後もタスクが正常に完了していない場合、Batch サービスはジョブのタスクをノードにスケジュールしません。 ノードはアクティブなままで、他のジョブのタスクを実行する資格があります。 false の場合、Batch サービスはジョブ準備タスクの完了を待機しません。 この場合、ジョブ準備タスクがまだ実行中に、ジョブの他のタスクがコンピューティング ノードで実行を開始できます。ジョブ準備タスクが失敗した場合でも、新しいタスクはコンピューティング ノードで引き続きスケジュールされます。 既定値は、true です。
- user_identity
- UserIdentity
ジョブ準備タスクを実行するユーザー ID。 省略すると、タスクは、Windows コンピューティング ノード上のタスクに固有の管理以外のユーザー、または Linux コンピューティング ノード上のプールに固有の管理ユーザーとして実行されます。
- rerun_on_node_reboot_after_success
- bool
コンピューティング ノードの再起動後に Batch サービスでジョブ準備タスクを再実行する必要があるかどうか。 コンピューティング ノードが再イメージ化された場合、またはジョブ準備タスクが完了しなかった場合 (タスクの実行中に再起動が発生したためなど)、ジョブ準備タスクは常に再実行されます。 そのため、ジョブ準備タスクは常にべき等であり、複数回実行すると正しく動作するように記述する必要があります。 既定値は、true です。
メソッド
| as_dict |
json.dump を使用して JSONify できる dict を返します。 高度な使用法では、必要に応じてコールバックをパラメーターとして使用できます。 キーは、Python で使用される属性名です。 Attr_descはメタデータのディクテーションです。 現在、msrest 型の 'type' と RestAPI でエンコードされたキーを持つ 'key' が含まれています。 値は、このオブジェクトの現在の値です。 返される文字列は、キーのシリアル化に使用されます。 戻り値の型がリストの場合、これは階層的な結果 dict と見なされます。 このファイルの 3 つの例を参照してください。
XML シリアル化が必要な場合は、kwargs is_xml=True を渡すことができます。 |
| deserialize |
RestAPI 構文を使用して str を解析し、モデルを返します。 |
| enable_additional_properties_sending | |
| from_dict |
指定されたキー抽出器を使用してディクテーションを解析し、モデルを返します。 既定では、キー抽出器 (rest_key_case_insensitive_extractor、attribute_key_case_insensitive_extractor、last_rest_key_case_insensitive_extractor) を検討してください |
| is_xml_model | |
| serialize |
このモデルから Azure に送信される JSON を返します。 これは、 as_dict(full_restapi_key_transformer、keep_readonly=False) のエイリアスです。 XML シリアル化が必要な場合は、kwargs is_xml=True を渡すことができます。 |
| validate |
このモデルを再帰的に検証し、ValidationError の一覧を返します。 |
as_dict
json.dump を使用して JSONify できる dict を返します。
高度な使用法では、必要に応じてコールバックをパラメーターとして使用できます。
キーは、Python で使用される属性名です。 Attr_descはメタデータのディクテーションです。 現在、msrest 型の 'type' と RestAPI でエンコードされたキーを持つ 'key' が含まれています。 値は、このオブジェクトの現在の値です。
返される文字列は、キーのシリアル化に使用されます。 戻り値の型がリストの場合、これは階層的な結果 dict と見なされます。
このファイルの 3 つの例を参照してください。
attribute_transformer
full_restapi_key_transformer
last_restapi_key_transformer
XML シリアル化が必要な場合は、kwargs is_xml=True を渡すことができます。
as_dict(keep_readonly=True, key_transformer=<function attribute_transformer>, **kwargs)パラメーター
- key_transformer
- <xref:function>
キー トランスフォーマー関数。
- keep_readonly
戻り値
dict JSON 互換オブジェクト
の戻り値の型 :
deserialize
RestAPI 構文を使用して str を解析し、モデルを返します。
deserialize(data, content_type=None)パラメーター
戻り値
このモデルのインスタンス
例外
enable_additional_properties_sending
enable_additional_properties_sending()from_dict
指定されたキー抽出器を使用してディクテーションを解析し、モデルを返します。
既定では、キー抽出器 (rest_key_case_insensitive_extractor、attribute_key_case_insensitive_extractor、last_rest_key_case_insensitive_extractor) を検討してください
from_dict(data, key_extractors=None, content_type=None)パラメーター
- key_extractors
戻り値
このモデルのインスタンス
例外
is_xml_model
is_xml_model()serialize
このモデルから Azure に送信される JSON を返します。
これは、 as_dict(full_restapi_key_transformer、keep_readonly=False) のエイリアスです。
XML シリアル化が必要な場合は、kwargs is_xml=True を渡すことができます。
serialize(keep_readonly=False, **kwargs)パラメーター
戻り値
dict JSON 互換オブジェクト
の戻り値の型 :
validate
Azure SDK for Python
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示