Azure Container Apps のジョブ

Azure Container Apps のジョブを使うと、有限の期間実行して終了するコンテナー化されたタスクを実行できます。 ジョブを使って、データ処理、機械学習、オンデマンド処理が必要なシナリオなどのタスクを実行できます。

コンテナー アプリとジョブは同じ環境で実行されるので、ネットワークやログなどの機能を共有できます。

コンテナー アプリとジョブを比較する

Azure Container Apps には、アプリとジョブという 2 種類のコンピューティング リソースがあります。

アプリは継続的に実行されるサービスです。 アプリ内のコンテナーは、失敗すると自動的に再起動します。 アプリの例としては、HTTP API、Web アプリ、入力を継続的に処理するバックグラウンド サービスなどがあります。

ジョブとは、開始され、一定時間実行され、完了すると終了されるタスクです。 1 つのジョブを実行するたびに、通常、1 つの作業単位が実行されます。 ジョブの実行は、手動、スケジュール、またはイベントに応答して開始されます。 ジョブの例としては、オンデマンドで実行されるバッチ プロセスやスケジュール タスクなどがあります。

シナリオ例

次の表は、アプリとジョブの一般的なシナリオを比較したものです。

コンテナー コンピューティング リソース メモ
Web コンテンツと API 要求を処理する HTTP サーバー アプリ HTTP スケール ルール を構成します。
財務レポートを夜間に生成するプロセス ジョブ スケジュール ジョブの種類 を使用し、cron 式を構成します。
Azure Service Bus キューからのメッセージを処理する継続的に実行されるサービス アプリ カスタム スケール ルール を構成します。
1 つのメッセージまたは Azure キューからのメッセージの小さなバッチを処理して終了するジョブ ジョブ ジョブの種類 "イベント" を使用し、キュー内にメッセージがあるときに、ジョブ実行をトリガーするようにカスタム スケール ルールを構成します。
オンデマンドでトリガーされ、完了すると終了するバックグラウンド タスク ジョブ ジョブの種類 [手動] を使用し、API を使用して手動またはプログラムで 実行を開始 します 。
セルフホステッド GitHub Actions ランナーまたは Azure Pipelines エージェント ジョブ ジョブの種類 [イベント] を使用し、 GitHub Actions または Azure Pipelines のスケール ルールを 構成します。
Azure Functions アプリ アプリ Azure Functions を Container Apps へデプロイします
Azure WebJobs SDK を使用したイベント ドリブン アプリ アプリ イベント ソースごとに スケール ルールを構成します

概念

Container Apps 環境は、1 つ以上のコンテナー アプリおよびジョブを囲むセキュリティ保護された境界です。 ジョブには、重要な概念がいくつかあります。

  • ジョブ: ジョブ実行のたびに使用される既定の構成を定義します。 その構成には、使用するコンテナー イメージ、割り当てるリソース、実行するコマンドが含まれます。
  • ジョブ実行: ジョブの 1 回の実行のことで、手動で、スケジュールに従って、またはイベントへの応答としてトリガーされます。
  • ジョブ レプリカ: 一般的なジョブ実行では、ジョブの構成によって定義されたレプリカが 1 つ実行されます。 高度なシナリオのジョブ実行では、複数のレプリカを実行できます。

Azure Container Apps のジョブの概要。

アクセス許可

コンテナー アプリ ジョブを開始するには、適切なアクセス許可が必要です。 ユーザー アカウントまたはサービス プリンシパルに次のロールが割り当てられていることを確認します。

  • Azure Container Apps 共同作成者: コンテナー アプリとジョブを作成および管理するためのアクセスが許可されます。
  • Azure Monitor 閲覧者 (省略可能): ジョブの監視データを表示できます。
  • カスタム ロール: よりきめ細かいアクセス許可を適用する場合は、次のアクションを使用してカスタム ロールを作成できます。
  • Microsoft.App/containerApps/jobs/start/action
  • Microsoft.App/containerApps/jobs/read
  • Microsoft.App/containerApps/jobs/executions/read

ロールとアクセス許可の割り当ての詳細については、「Azure ロールベースのアクセス制御」を参照してください。

ジョブのトリガーの種類

ジョブのトリガーの種類によって、ジョブの開始方法が決まります。 次のトリガーの種類を使用できます。

  • 手動: 手動ジョブは、オンデマンドでトリガーされます。
  • スケジュール: スケジュール ジョブは特定の時間にトリガーされ、繰り返し実行できます。
  • イベント: メッセージがキューに到着するなどのイベントによって、イベントドリブン ジョブがトリガーされます。

手動ジョブ

手動ジョブは、Azure CLI、Azure portal、または Azure Resource Manager API への要求を使ってオンデマンドでトリガーされます。

手動ジョブの例としては、次のようなものがあります。

  • 1 回限りの処理タスク。たとえば、あるシステムから別のシステムへデータを移行する場合。
  • コンテナー アプリとして動作する eコマース サイトは、受注したときに在庫を処理するジョブの実行を開始します。

手動ジョブを作成するには、ジョブの種類 Manual を使います。

Azure CLI を使って手動ジョブを作成するには、az containerapp job create コマンドを使います。 次の例では、my-resource-group というリソース グループと my-environment という Container Apps 環境内に my-job という手動ジョブを作成します。

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Manual" \
    --replica-timeout 1800 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi"

mcr.microsoft.com/k8se/quickstart-jobs:latest イメージは、数秒間待機し、コンソールにメッセージを出力してから終了するジョブを実行するパブリック サンプル コンテナー イメージです。 プライベート コンテナー イメージを認証して使用するには、「コンテナー」を参照してください。

上のコマンドを実行すると、単にジョブが作成されます。 ジョブの実行を開始するには、オンデマンドでジョブの実行を開始する方法に関する記事を参照してください。

スケジュールされたジョブ

スケジュール ジョブを作成するには、ジョブの種類 Schedule を使います。

Container Apps ジョブでは、cron 式を使用してスケジュールを定義します。 標準の cron 式形式がサポートされており、分、時、日、月、曜日の 5 つのフィールドがあります。 cron 式の例を次に示します。

説明
*/5 * * * * 5 分ごとに実行します。
0 */2 * * * 2 時間に 1 回実行します。
0 0 * * * 毎日午前 0 時に実行します。
0 0 * * 0 毎週日曜日の午前 0 時に実行します。
0 0 1 * * 毎月 1 日の午前 0 時に実行します。

スケジュール ジョブの Cron 式は協定世界時 (UTC) で評価されます。

Azure CLI を使ってスケジュール ジョブを作成するには、az containerapp job create コマンドを使います。 次の例では、my-resource-group というリソース グループと my-environment という Container Apps 環境内に my-job というスケジュール ジョブを作成します。

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 \
    --image "mcr.microsoft.com/k8se/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --cron-expression "*/1 * * * *"

mcr.microsoft.com/k8se/quickstart-jobs:latest イメージは、数秒間待機し、コンソールにメッセージを出力してから終了するジョブを実行するパブリック サンプル コンテナー イメージです。 プライベート コンテナー イメージを認証して使用するには、「コンテナー」を参照してください。

cron 式 */1 * * * * は、1 分ごとにジョブを実行します。

イベントドリブン ジョブ

イベントドリブン ジョブは、サポートされるカスタム スケーラーからのイベントによってトリガーされます。 イベントドリブン ジョブの例としては、次のようなものがあります。

  • Azure Service Bus、Kafka、RabbitMQ などのキューに新しいメッセージが追加されたときに実行されるジョブ。
  • ワークフローまたはパイプラインのキューに新しいジョブが格納されたときに実行されるセルフホステッド GitHub Actions ランナー または Azure DevOps エージェント

コンテナー アプリとイベントドリブン ジョブは KEDA スケーラーを使います。 どちらもポーリング間隔でスケーリング ルールを評価してイベント ソースのイベント量を測定しますが、結果の使用方法は異なります。

アプリ内では、各レプリカでイベントを継続的に処理します。また、需要を満たすように、スケーリング ルールによって実行するレプリカ数が決まります。 イベントドリブン ジョブの場合、通常、ジョブ実行ごとに 1 つのイベントが処理され、実行するジョブ実行数は、スケーリング ルールによって決まります。

ジョブを使うのは、各イベントに専用リソースを持つコンテナーの新しいインスタンスが必要な場合や、長時間の実行が必要な場合です。 イベントドリブン ジョブは、概念的には KEDA スケーリング ジョブと似ています。

イベントドリブン ジョブを作成するには、ジョブの種類 Event を使います。

Azure CLI を使ってイベントドリブン ジョブを作成するには、az containerapp job create コマンドを使います。 次の例では、my-resource-group というリソース グループと my-environment という Container Apps 環境内に my-job というイベントドリブン ジョブを作成します。

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Event" \
    --replica-timeout 1800 \
    --image "docker.io/myuser/my-event-driven-job:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --min-executions "0" \
    --max-executions "10" \
    --scale-rule-name "queue" \
    --scale-rule-type "azure-queue" \
    --scale-rule-metadata "accountName=mystorage" "queueName=myqueue" "queueLength=1" \
    --scale-rule-auth "connection=connection-string-secret" \
    --secrets "connection-string-secret=<QUEUE_CONNECTION_STRING>"

この例では、Azure Storage キュー スケール ルールを構成します。

詳細なチュートリアルについては、イベントドリブン ジョブのデプロイに関する記事を参照してください。

オンデマンドでジョブの実行を開始する

どの種類のジョブでも、オンデマンドでジョブの実行を開始できます。

Azure CLI を使ってジョブの実行を開始するには、az containerapp job start コマンドを使います。 次の例では、my-resource-group というリソース グループの my-job というジョブの実行を開始します。

az containerapp job start --name "my-job" --resource-group "my-resource-group"

ジョブの実行を開始するときに、ジョブの構成をオーバーライドすることを選択できます。 たとえば、環境変数または起動コマンドをオーバーライドして、異なる入力で同じジョブを実行することができます。 オーバーライドされた構成は、現在の実行にのみ使用され、ジョブの構成は変更されません。

重要

構成をオーバーライドすると、ジョブのテンプレート構成全体が新しい構成に置き換えられます。 新しい構成に、必要な設定がすべて含まれていることを確認してください。

実行の開始時にジョブの構成をオーバーライドするには、 az containerapp job start コマンドを使用し、実行に使用するテンプレートを含む YAML ファイルを渡します。 次の例では、my-resource-group というリソース グループの my-job というジョブの実行を開始します。

az containerapp job show コマンドを使用して現在のジョブの構成を取得し、テンプレートを my-job-template.yaml という名前のファイルに保存します。

az containerapp job show --name "my-job" --resource-group "my-resource-group" --query "properties.template" --output yaml > my-job-template.yaml

--query "properties.template" オプションによって、ジョブのテンプレート構成のみが返されます。

my-job-template.yaml ファイルを編集して、ジョブの構成をオーバーライドします。 たとえば、環境変数をオーバーライドするには、 env セクションを変更します。

containers:
- name: print-hello
  image: ubuntu
  resources:
    cpu: 1
    memory: 2Gi
  env:
  - name: MY_NAME
    value: Azure Container Apps jobs
  args:
  - /bin/bash
  - -c
  - echo "Hello, $MY_NAME!"

次のテンプレートを使用してジョブを開始します。

az containerapp job start --name "my-job" --resource-group "my-resource-group" \
    --yaml my-job-template.yaml

ジョブの実行履歴を取得する

各 Container Apps ジョブは、最近のジョブの実行履歴を保持します。

Azure CLI を使ってジョブの実行状態を取得するには、az containerapp job execution list コマンドを使います。 次の例は、my-resource-group というリソース グループ内の my-job というジョブの直近の実行状態を返します。

az containerapp job execution list --name "my-job" --resource-group "my-resource-group"

スケジュールされたジョブとイベント ベースのジョブの実行履歴は、成功したジョブと失敗したジョブの直近の 100 個に制限されます。

ジョブのすべての実行を一覧表示する場合、またはジョブから詳細な出力を取得する場合は、Container Apps 環境の構成されたログ プロバイダーにクエリを実行します。

高度なジョブ構成

Container Apps ジョブは、コンテナー設定、再試行、タイムアウト、並列処理などの高度な構成オプションをサポートしています。

コンテナーの設定

コンテナーの設定では、ジョブの実行の各レプリカで実行するコンテナーを定義します。 環境変数、シークレット、リソース制限などが含まれます。 詳細については、コンテナーに関する記事を参照してください。 1 つのジョブで複数のコンテナーを実行することは、高度なシナリオです。 ほとんどのジョブは 1 つのコンテナーを実行します。

ジョブの設定

次の表は、構成できるジョブの設定をまとめたものです。

設定 Azure リソース マネージャーのプロパティ CLI パラメーター 説明
職務タイプ triggerType --trigger-type ジョブの種類。 (ManualSchedule、または Event)
レプリカのタイムアウト replicaTimeout --replica-timeout レプリカが完了するまで待機する最長時間 (秒)。
[ポーリング間隔] pollingInterval --polling-interval イベントのポーリング間の待機時間 (秒)。 既定値は 30 秒です。
レプリカの再試行回数の上限 replicaRetryLimit --replica-retry-limit 失敗したレプリカを再試行する最大回数。 レプリカを失敗して再試行しない場合は、値を 0 に設定します。
Parallelism parallelism --parallelism 1 回の実行で実行するレプリカ数。 ほとんどのジョブでは、値を 1 に設定します。
レプリカの完了数 replicaCompletionCount --replica-completion-count このレプリカ数が正常に完了すると、実行を成功と見なします。 ほとんどの場合、並列処理の値以下になります。 ほとんどのジョブでは、値を 1 に設定します。

次の例では、高度な構成オプションを指定したジョブを作成します。

az containerapp job create \
    --name "my-job" --resource-group "my-resource-group"  --environment "my-environment" \
    --trigger-type "Schedule" \
    --replica-timeout 1800 --replica-retry-limit 3 --replica-completion-count 5 --parallelism 5 \
    --image "myregistry.azurecr.io/quickstart-jobs:latest" \
    --cpu "0.25" --memory "0.5Gi" \
    --command "/startup.sh" \
    --env-vars "MY_ENV_VAR=my-value" \
    --cron-expression "0 0 * * *"  \
    --registry-server "myregistry.azurecr.io" \
    --registry-username "myregistry" \
    --registry-password "myregistrypassword"

ジョブの制限

次の機能はサポートされていません:

  • Dapr
  • イングレスとカスタム ドメインや SSL 証明書などの関連機能

次のステップ