Container Apps: Scaling, Jobs and Dapr

Bookshelf adds one more moving part on top of cae-bookshelf, catalog-api and orders-api: a notifier worker that sends order-confirmation emails and push notifications. Rather than run notifier as an always-on container app polling a queue, Bookshelf runs it as an event-driven job — a com.example.bookshelf.notifier Java process, packaged the same way as catalog-api and orders-api (see Azure Container Registry for how its image reaches acrbookshelf), that Container Apps starts on demand, once per queued message, and tears down again once the message is processed. catalog-api and orders-api keep scaling on HTTP concurrency as covered in Container Apps; this page adds a Service Bus-based custom scale rule for notifier and, separately, a Dapr pub/sub component so orders-api can publish an order-placed event without knowing notifier exists.

Shell variables used throughout (matching the rest of this section):

A Container Apps job is a task that starts, runs for a finite duration, and stops — unlike an app, a failed job replica is not automatically restarted into a long-running process; it is retried up to a limit and then the execution is marked failed. Jobs and apps share the same environment (cae-bookshelf), networking and logging, but jobs do not support ingress, custom domains/SSL, or Dapr — three restrictions worth remembering before reaching for a job where an always-on app (or a Dapr-enabled one) is really what is needed.

Three trigger types cover Bookshelf’s needs:

Dapr (Distributed Application Runtime) runs as a sidecar container next to each enabled app’s own container, giving it a local HTTP/gRPC API for cross-cutting concerns — service invocation, pub/sub messaging, state management, secrets, bindings and actors — without linking a Dapr SDK into application code (though SDKs exist and are the more ergonomic choice from Java/.NET). Container Apps manages the sidecar’s lifecycle automatically once Dapr is enabled on an app; jobs cannot use Dapr at all, which is why notifier reaches Bookshelf’s messaging exclusively through its Service Bus scale rule rather than through a Dapr pub/sub subscription.

Container Apps supports the same three probe types Kubernetes does, each governing a different failure response:

There is no dedicated CLI flag surface for probes (no --liveness-probe-* family of parameters); they are set through the container app’s YAML template, either applied at creation or via an update.

Container Apps mounts three kinds of volume into a replica’s containers, none of which is meant to replace a managed database — they cover local scratch space, a shared network file share, and secret material:

By default, a Container Apps workload profiles environment (the current default environment type) still gets its own managed virtual network, but every feature in this section — bringing an existing VNet, a private endpoint, an internal-only environment, user-defined routes and NAT — requires the environment to sit in a custom VNet with a dedicated, delegated subnet. Consumption-only (legacy) environments support a custom VNet too, but not UDR, NAT gateway egress control, or private endpoints — those three are workload-profiles-only.

Container Apps bills the Consumption plan per vCPU-second and GiB-second actually used while a replica is running, plus a per-request charge above a monthly free grant, and charges nothing while an app or job execution is scaled to zero — which is the direct economic reason notifier is worth running as an event-driven job rather than an always-on worker: it only consumes compute for the seconds it is actually processing a message. A replica that is idle but still resident in memory (below the minimum replica count, or kept warm during a scale-down stabilization window) can be billed at a lower "idle charge" rate rather than the full active rate, which is worth remembering when comparing an app kept at --min-replicas 1 against one left free to scale to zero. The Dedicated workload-profile plan instead bills for reserved vCPU/memory on dedicated instances regardless of utilization, and is the plan Bookshelf would reach for only if catalog-api or orders-api needed guaranteed capacity, larger instance sizes, or the isolation of not sharing underlying nodes with other customers' workloads — Bookshelf’s Consumption-only workloads described throughout this section do not need it. Jobs bill the same per-second Consumption model as apps, scoped to each execution’s actual running replicas rather than to the job definition itself, so a scheduled job that never has work to do (a catalog-report run that finds nothing new) still bills for the seconds its replica took to start up, run its check, and exit, but nothing between runs. Dapr’s sidecar container adds its own small vCPU/memory footprint to every replica it runs alongside, which is itself billed as part of that replica’s consumption.

References: Billing in Azure Container Apps, Azure Container Apps hosting plans.

A scale rule that never seems to fire is the most common failure mode, and it is almost always one of: the app has ingress disabled, --min-replicas 0, and no custom scale rule at all (the pitfall called out under the KEDA scale loop diagram above — nothing is polling anything, so the app never wakes); the custom scale rule’s --scale-rule-identity principal lacks the data-plane role needed to read the event source (a Service Bus scaler needs at least Azure Service Bus Data Receiver to read queue depth, not just Data Owner on the namespace for unrelated reasons); or the scale rule’s metadata does not match the event source’s actual resource names (a typo’d queueName silently measures depth 0 forever rather than erroring). az containerapp revision list and the app’s own Log stream blade (or whichever log destination the environment forwards to) show KEDA’s own scaler errors, which name the exact metadata key or authentication failure.

A job execution stuck in Running past its expected duration is usually --replica-timeout set too high for the actual workload, masking a hung container that should have failed fast; a job that fails every execution with zero retries attempted is --replica-retry-limit 0, which is correct for anything that must not silently repeat side effects (an email send, for instance) but wrong for anything that should tolerate a transient dependency outage. az containerapp job execution list plus az containerapp job logs show (or the log destination) narrow this down per execution.

A Dapr-enabled app that cannot reach a component almost always traces to one of: the component’s scopes list does not include the calling app’s Dapr app ID (a component with no scopes is available to every Dapr-enabled app in the environment, which is a security smell more often than an intended default); the app was not restarted after the component was added (a component change, like a scale-rule change, only takes effect on the next revision); or, for managed-identity component authentication, the identity referenced in the component YAML lacks the target service’s data-plane role, the same class of failure as a scale rule’s --scale-rule-identity.

An internal or custom-VNet environment that an app cannot reach from outside the VNet is very often working exactly as configured — --internal-only true intentionally removes the public endpoint — so the fix is usually a VPN/ExpressRoute/peering path into the VNet, or a private endpoint from the calling network, not a setting to revert. A NAT gateway or UDR that leaves the environment unable to reach anything at all typically means the route table or NAT association was placed on the wrong subnet, or omits the return path the environment’s control-plane traffic needs; re-check against the exact subnet association the References below call out before assuming the environment itself is broken.