Azure Container Apps のジョブ

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 ジョブの概要を示す図。

アクセス許可

コンテナアプリのジョブを開始するには、ユーザーアカウントやサービスプリンシパルに適切な権限が必要です。以下の役割を考慮してください:

コンテナアプリジョブの貢献者: ジョブの作成および管理権限を許可します。
コンテナアプリジョブオペレーター: ジョブの読み取り、開始、停止の権限を許可します。
監視リーダー (省略可能): ジョブの監視データの表示を有効にします。

Container Apps Jobs Contributor ロールと Container Apps Jobs Operator ロールの両方に、Microsoft.App/jobs/*/action ワイルドカードアクセス許可が含まれています。このワイルドカードは Microsoft.App/jobs/listSecrets/action と一致するため、両方の役割はジョブの秘密値をプレーンテキストで読む許可を与えます。

もしどちらの役割も許可したいアクセスと一致しない場合は、必要なアクションだけを記載したカスタムロールを作成してください。例えば、以下の操作はユーザーが Microsoft.App/jobs/*/action ワイルドカードを使わずにジョブを表示、開始、停止できるようにします。このルールセットには Microsoft.App/jobs/start/actionが含まれているため、ジョブの秘密やコンテナで利用可能な管理されるアイデンティティを使用できると信頼できるアイデンティティにのみ付与してください。

Microsoft.App/jobs/read
Microsoft.App/jobs/start/action
Microsoft.App/jobs/stop/action
Microsoft.App/jobs/stop/execution/action
Microsoft.App/jobs/executions/read
Microsoft.App/jobs/execution/read
Microsoft.App/managedEnvironments/read

カスタムロール定義における Microsoft.App/jobs/*/action のようなワイルドカードパターンは避けましょう。このワイルドカードは、パターンに合致する現在および将来のすべての操作を付与し、 listSecretsも含まれます。

Warning

ジョブ開始の許可は、その役割にその listSecrets アクションが含まれていなくても、そのジョブの秘密へのアクセスを可能にします。 Jobs - Start REST APIは、メインおよびinitコンテナイメージ、コマンド、環境変数を上書きできるオプションの実行テンプレートを受け入れています。 Microsoft.App/jobs/start/actionを保持し、秘密の名前を知っているユーザーは、好きなコンテナからその秘密を参照し、コンテナ内の値を読み取ることができます。コンテナでは、そのコンテナで利用できるように構成された任意のマネージド ID を使用することもできます。ジョブの秘密情報や利用可能なマネージドIDを使えると信頼できるアイデンティティにのみジョブ開始の許可を与えてください。

詳細については、「秘密管理権限」および「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"

次の Azure Resource Manager テンプレートの部分的な例では、my-job という名前のリソースグループと my-resource-group という名前の Container Apps 環境に、my-environmentという名前の手動ジョブを作成します。

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "manualTriggerConfig": {
                "parallelism": 1,
                "replicaCompletionCount": 1
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Manual"
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

Azure portal を使用して手動ジョブを作成するには、Azure portal で コンテナーアプリジョブ を検索し、[ 作成] を選択します。トリガーの種類として[マニュアル] を指定します。

サンプルコンテナーイメージを使用するには、[ コンテナー] タブ に次の値を入力します。

設定	値
名前	メイン
イメージソース	Docker Hub またはその他のレジストリ
画像の種類	パブリック
レジストリログインサーバー	mcr.microsoft.com
イメージとタグ	k8se/quickstart-jobs:latest
CPU とメモリ	0.25 CPU コア、0.5 Gi メモリ、またはそれ以上

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 * * * *"

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "scheduleTriggerConfig": {
                "cronExpression": "*/1 * * * *",
                "parallelism": 1,
                "replicaCompletionCount": 1
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Schedule"
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

Azure portal を使用してスケジュールされたジョブを作成するには、Azure portal で コンテナーアプリジョブ を検索し、[ 作成] を選択します。トリガーの種類として [スケジュール] を指定し、毎分実行する */1 * * * * など、cron 式を使用してスケジュールを定義します。

サンプルコンテナーイメージを使用するには、[ コンテナー] タブ に次の値を入力します。

設定	値
名前	メイン
イメージソース	Docker Hub またはその他のレジストリ
画像の種類	パブリック
レジストリログインサーバー	mcr.microsoft.com
イメージとタグ	k8se/quickstart-jobs:latest
CPU とメモリ	0.25 CPU コア、0.5 Gi メモリ、またはそれ以上

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 Resource Manager テンプレートの次の部分的な例では、my-job という名前のリソースグループと my-resource-group という名前の Container Apps 環境に、my-environmentという名前のイベントドリブンジョブを作成します。

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "eventTriggerConfig": {
                "scale": {
                    "maxExecutions": 10,
                    "minExecutions": 0,
                    "pollingInterval": 15,
                    "rules": [
                        {
                            "auth": [
                                {
                                    "triggerParameter": "connection",
                                    "secretRef": "connection-string-secret"
                                }
                            ],
                            "metadata": {
                                "accountName": "mystorage",
                                "queueLength": 1,
                                "queueName": "myqueue"
                            },
                            "name": "queue",
                            "type": "azure-queue"
                        }
                    ]
                }
            },
            "replicaRetryLimit": 0,
            "replicaTimeout": 1800,
            "triggerType": "Event",
            "secrets": [
                {
                    "name": "connection-string-secret",
                    "value": "<QUEUE_CONNECTION_STRING>"
                }
            ]
        },
        "environmentId": "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "image": "docker.io/myuser/my-event-driven-job:latest",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

この例では、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"

Azure Resource Manager REST API を使用してジョブの実行を開始するには、ジョブのPOST操作にstart要求を行います。

次の例では、my-job というリソースグループの my-resource-group というジョブの実行を開始します。

POST https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/start?api-version=2023-05-01
Authorization: Bearer <TOKEN>

<SUBSCRIPTION_ID> は、サブスクリプション ID で置き換えてください。

要求を認証するには、<TOKEN> ヘッダーの Authorization を有効なベアラートークンに置き換えます。トークンを生成する際に使われるアイデンティティは、コンテナアプリのジョブリソースに対して Microsoft.App/jobs/start/action 権限を持っている必要があります。コンテナ アプリジョブオペレーター および コンテナアプリジョブコントリビューター の組み込みロールには、この権限が含まれています。詳細については、 Jobs - Start REST APIをご覧ください。

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

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

Warning

ジョブを開始できるアイデンティティは、実行テンプレートを使って名前を知っているジョブ秘密を参照し、コンテナで利用可能に設定された管理型アイデンティティを使用できます。詳細については、「アクセス許可」を参照してください。

実行を開始するときにジョブの構成をオーバーライドするには、 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

ジョブの構成をオーバーライドするには、要求本文にテンプレートを含めます。次の例では、スタートアップコマンドをオーバーライドして別のコマンドを実行します。

POST https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/start?api-version=2023-05-01
Content-Type: application/json
Authorization: Bearer <TOKEN>

{
    "containers": [
        {
            "image": "mcr.microsoft.com/k8se/quickstart-jobs:latest",
            "name": "main",
            "resources": {
                "cpu": 0.25,
                "memory": "0.5Gi"
            },
            "command": [
                "echo",
                "Hello, Azure Container Apps jobs!"
            ]
        }
    ]
}

<SUBSCRIPTION_ID> を自分のサブスクリプション ID に、<TOKEN> ヘッダーの Authorization を有効なベアラートークンに置き換えます。トークンを生成する際に使われるアイデンティティは、コンテナアプリのジョブリソースに対して Microsoft.App/jobs/start/action 権限を持っている必要があります。コンテナ アプリジョブオペレーター および コンテナアプリジョブコントリビューター の組み込みロールには、この権限が含まれています。詳細については、 Jobs - Start REST APIをご覧ください。

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

各 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"

Azure Resource Manager REST API を使用してジョブ実行の状態を取得するには、ジョブのGET操作にexecutions要求を行います。次の例は、my-job というリソースグループ内の my-resource-group というジョブの直近の実行状態を返します。

GET https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/my-resource-group/providers/Microsoft.App/jobs/my-job/executions?api-version=2023-05-01

<SUBSCRIPTION_ID> は、サブスクリプション ID で置き換えてください。

要求を認証するには、有効なベアラートークンを含む Authorization ヘッダーを追加します。詳細については、「Azure REST API リファレンス」を参照してください。

スケジュールされたジョブとイベントベースのジョブの実行履歴は、成功したジョブと失敗したジョブの直近の 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` に設定します。

長時間実行ジョブ

注

定期的なセキュリティ更新やアップグレードを含むプラットフォームのメンテナンスにより、長時間実行されるジョブレプリカが中断される可能性があります。レプリカの再試行制限を最低 1に設定し、再試行が安全に作業を完了できるように、少なくとも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"

Azure Resource Manager テンプレートの次の部分的な例では、高度な構成オプションを使用してジョブを作成します。

{
    "location": "North Central US",
    "name": "my-job",
    "properties": {
        "configuration": {
            "scheduleTriggerConfig": {
                "cronExpression": "0 0 * * *",
                "parallelism": 5,
                "replicaCompletionCount": 5
            },
            "replicaRetryLimit": 3,
            "replicaTimeout": 1800,
            "triggerType": "Schedule",
            "secrets": [
                {
                    "name": "registry-password",
                    "value": "myregistrypassword"
                }
            ]
            "registries": [
                {
                    "server": "myregistry.azurecr.io",
                    "username": "myregistry",
                    "passwordSecretRef": "registry-password"
                }
            ]
        },
        "environmentId": "/subscriptions/<subscription_id>/resourceGroups/my-resource-group/providers/Microsoft.App/managedEnvironments/my-environment",
        "template": {
            "containers": [
                {
                    "command": [
                        "/startup.sh"
                    ],
                    "cpu": 0.25,
                    "envVars": [
                        {
                            "name": "MY_ENV_VAR",
                            "value": "my-value"
                        }
                    ],
                    "image": "myregistry.azurecr.io/quickstart-jobs:latest",
                    "memory": "0.5Gi",
                    "name": "main",
                    "resources": {
                        "cpu": 0.25,
                        "memory": "0.5Gi"
                    }
                }
            ]
        }
    }
}

仕事のネットワーキングとアプリ間通信

ジョブポッドが起動すると、メインジョブコンテナーの実行が開始される前に、サイドカーコンテナー (Envoy プロキシなど) の準備が保証されます。これにより、起動時にジョブによって行われたアプリ間の呼び出しが、接続エラーなしで成功します。

注

ジョブが起動時に他のコンテナーアプリを呼び出す場合、サイドカーの最初の準備完了に対して、再試行ロジックを追加する必要はありません。プラットフォームはこれを自動的に処理します。

ジョブの制限

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

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

次のステップ

Azure Container Apps でジョブを作成する

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-16