Azure Container Apps ジョブを使用すると、有限の期間実行されたコンテナー化されたタスクを実行し、停止することができます。 ジョブを使って、データ処理、機械学習、オンデマンド処理が必要なシナリオなどのタスクを実行できます。
コンテナー アプリとジョブは同じ環境で実行されるので、ネットワークやログなどの機能を共有できます。
コンテナー アプリとジョブを比較する
Azure Container Apps には、アプリとジョブという 2 種類のコンピューティング リソースがあります。
アプリは継続的に実行されるサービスです。 アプリ内のコンテナーは、失敗すると自動的に再起動します。 アプリの例としては、HTTP API、Web アプリ、入力を継続的に処理するバックグラウンド サービスなどがあります。
ジョブは、開始し、有限の期間実行し、完了すると停止するタスクです。 1 つのジョブを実行するたびに、通常、1 つの作業単位が実行されます。 ジョブの実行は、手動、スケジュール、またはイベントに応答して開始されます。 ジョブの例としては、オンデマンドで実行されるバッチ プロセスやスケジュール タスクなどがあります。
シナリオ例
次の表は、アプリとジョブの一般的なシナリオを比較したものです。
| コンテナー | コンピューティング リソース | Notes |
|---|---|---|
| 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 つ実行されます。 高度なシナリオのジョブ実行では、複数のレプリカを実行できます。
アクセス許可
コンテナー アプリ ジョブを開始するには、適切なアクセス許可が必要です。 ユーザー アカウントまたはサービス プリンシパルに次のロールが割り当てられていることを確認します。
- Container Apps 共同作成者: コンテナー アプリとジョブを作成および管理するためのアクセス許可を許可します。
- 監視リーダー (省略可能): ジョブの監視データの表示を有効にします。
- カスタム ロール: よりきめ細かいアクセス許可を適用する場合は、次のアクションを使用してカスタム ロールを作成できます。
- microsoft.app/jobs/start/action
- microsoft.app/jobs/read
- microsoft.app/jobs/execution/read
ロールとアクセス許可の割り当ての詳細については、 Azure ロールベースのアクセス制御に関するページを参照してください。
ジョブのトリガーの種類
ジョブのトリガーの種類によって、ジョブの開始方法が決まります。 次のトリガーの種類を使用できます。
- 手動: 手動ジョブはオンデマンドでトリガーされます。
- スケジュール: スケジュール ジョブは特定の時間にトリガーされ、繰り返し実行できます。
- イベント: イベント ドリブン ジョブは、キューに到着するメッセージなどのイベントによってトリガーされます。
手動ジョブ
手動ジョブは、Azure CLI、Azure portal、または Azure Resource Manager API への要求を介してオンデマンドでトリガーされます。
手動ジョブの例としては、次のようなものがあります。
- あるシステムから別のシステムにデータを移行するなどの 1 回限りの処理タスク。
- コンテナー アプリとして実行されている e コマース サイトは、注文時にインベントリを処理するジョブの実行を開始します。
手動ジョブを作成するには、ジョブの種類 Manual を使います。
Azure CLI を使用して手動ジョブを作成するには、 az containerapp job create コマンドを使用します。 次の例では、my-job というリソース グループと my-resource-group という Container Apps 環境内に my-environment という手動ジョブを作成します。
az containerapp job create \
--name "my-job" --resource-group "my-resource-group" --environment "my-environment" \
--trigger-type "Manual" \
--replica-timeout 1800 \
--replica-retry-limit 0 \
--replica-completion-count 1 \
--parallelism 1 \
--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-job というリソース グループと my-resource-group という Container Apps 環境内に my-environment というスケジュール ジョブを作成します。
az containerapp job create \
--name "my-job" --resource-group "my-resource-group" --environment "my-environment" \
--trigger-type "Schedule" \
--replica-timeout 1800 \
--replica-retry-limit 0 \
--parallelism 1 \
--replica-completion-count 1 \
--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-job というリソース グループと my-resource-group という Container Apps 環境内に my-environment というイベントドリブン ジョブを作成します。
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-job というリソース グループの my-resource-group というジョブの実行を開始します。
az containerapp job start --name "my-job" --resource-group "my-resource-group"
ジョブの実行を開始するときに、ジョブの構成をオーバーライドすることを選択できます。 たとえば、環境変数または起動コマンドをオーバーライドして、異なる入力で同じジョブを実行することができます。 オーバーライドされた構成は、現在の実行にのみ使用され、ジョブの構成は変更されません。
重要
構成をオーバーライドすると、ジョブのテンプレート構成全体が新しい構成に置き換えられます。 新しい構成に、必要な設定がすべて含まれていることを確認してください。
実行を開始するときにジョブの構成をオーバーライドするには、 az containerapp job start コマンドを使用し、実行に使用するテンプレートを含む YAML ファイルを渡します。 次の例では、my-job というリソース グループの my-resource-group というジョブの実行を開始します。
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-job というリソース グループ内の my-resource-group というジョブの直近の実行状態を返します。
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 |
ジョブの種類 (Manual、 Schedule、または Event)。 |
| レプリカのタイムアウト | replicaTimeout |
--replica-timeout |
レプリカが完了するまで待機する最長時間 (秒)。 |
| [ポーリング間隔] | pollingInterval |
--polling-interval |
イベントのポーリング間の待機時間 (秒)。 既定値は 30 秒です。 |
| レプリカの再試行回数の上限 | replicaRetryLimit |
--replica-retry-limit |
失敗したレプリカを再試行する最大回数。 レプリカを失敗して再試行しない場合は、値を 0 に設定します。
replicaTimeout設定は、すべての再試行が行われる前に期限切れになった場合に優先されます。 |
| 平行性 | 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 証明書などの関連機能