container-apps-gpu-2025
Azure Container Apps with GPU support, serverless capabilities, and Foundry Models. PROACTIVELY activate for: (1) Container Apps GPU (serverless GPU workloads), (2) Container Apps with Dapr integration, (3) scale-to-zero AI workloads, (4) Container Apps Jobs (one-shot, scheduled, event-driven), (5) Container Apps Foundry Models integration, (6) revisions and traffic splitting, (7) custom domains and managed certificates, (8) ingress and authentication, (9) Container Apps Environment configuration, (10) Workload Profiles (Consumption vs Dedicated). Provides: GPU SKU reference, scale rule examples (HTTP, KEDA), Dapr building-block recipes, traffic-split patterns, and end-to-end serverless GPU deployment.
What this skill does
# Azure Container Apps GPU Support - 2025 Features
Complete knowledge base for Azure Container Apps with GPU support, serverless capabilities, and Dapr integration (2025 GA features).
## Overview
Azure Container Apps is a serverless container platform with native GPU support, Dapr integration, and scale-to-zero capabilities for cost-efficient AI/ML workloads.
## Key 2025 Features (Build Announcements)
### 1. Serverless GPU (GA)
- **Automatic scaling**: Scale GPU workloads based on demand
- **Scale-to-zero**: Pay only when GPU is actively used
- **Per-second billing**: Granular cost control
- **Optimized cold start**: Fast initialization for AI models
- **Reduced operational overhead**: No infrastructure management
### 2. Dedicated GPU (GA)
- **Consistent performance**: Dedicated GPU resources
- **Simplified AI deployment**: Easy model hosting
- **Long-running workloads**: Ideal for training and continuous inference
- **Multiple GPU types**: NVIDIA A100, T4, and more
### 3. Dynamic Sessions with GPU (Early Access)
- **Sandboxed execution**: Run untrusted AI-generated code
- **Hyper-V isolation**: Enhanced security
- **GPU-powered Python interpreter**: Handle compute-intensive AI workloads
- **Scale at runtime**: Dynamic resource allocation
### 4. Foundry Models Integration
- **Deploy AI models directly**: During container app creation
- **Ready-to-use models**: Pre-configured inference endpoints
- **Azure AI Foundry**: Seamless integration
### 5. Workflow with Durable Task Scheduler (Preview)
- **Long-running workflows**: Reliable orchestration
- **State management**: Automatic persistence
- **Event-driven**: Trigger workflows from events
### 6. Native Azure Functions Support
- **Functions runtime**: Run Azure Functions in Container Apps
- **Consistent development**: Same code, serverless execution
- **Event triggers**: All Functions triggers supported
### 7. Dapr Integration (GA)
- **Service discovery**: Built-in DNS-based discovery
- **State management**: Distributed state stores
- **Pub/sub messaging**: Reliable messaging patterns
- **Service invocation**: Resilient service-to-service calls
- **Observability**: Integrated tracing and metrics
## Creating Container Apps with GPU
### Basic Container App with Serverless GPU
```bash
# Create Container Apps environment
az containerapp env create \
--name myenv \
--resource-group MyRG \
--location eastus \
--logs-workspace-id <workspace-id> \
--logs-workspace-key <workspace-key>
# Create Container App with GPU
az containerapp create \
--name myapp-gpu \
--resource-group MyRG \
--environment myenv \
--image myregistry.azurecr.io/ai-model:latest \
--cpu 4 \
--memory 8Gi \
--gpu-type nvidia-a100 \
--gpu-count 1 \
--min-replicas 0 \
--max-replicas 10 \
--ingress external \
--target-port 8080
```
### Production-Ready Container App with GPU
```bash
az containerapp create \
--name myapp-gpu-prod \
--resource-group MyRG \
--environment myenv \
\
# Container configuration
--image myregistry.azurecr.io/ai-model:latest \
--registry-server myregistry.azurecr.io \
--registry-identity system \
\
# Resources
--cpu 4 \
--memory 8Gi \
--gpu-type nvidia-a100 \
--gpu-count 1 \
\
# Scaling
--min-replicas 0 \
--max-replicas 20 \
--scale-rule-name http-scaling \
--scale-rule-type http \
--scale-rule-http-concurrency 10 \
\
# Networking
--ingress external \
--target-port 8080 \
--transport http2 \
--exposed-port 8080 \
\
# Security
--registry-identity system \
--env-vars "AZURE_CLIENT_ID=secretref:client-id" \
\
# Monitoring
--dapr-app-id myapp \
--dapr-app-port 8080 \
--dapr-app-protocol http \
--enable-dapr \
\
# Identity
--system-assigned
```
## Container Apps Environment Configuration
### Environment with Zone Redundancy
```bash
az containerapp env create \
--name myenv-prod \
--resource-group MyRG \
--location eastus \
--logs-workspace-id <workspace-id> \
--logs-workspace-key <workspace-key> \
--zone-redundant true \
--enable-workload-profiles true
```
### Workload Profiles (Dedicated GPU)
```bash
# Create environment with workload profiles
az containerapp env create \
--name myenv-gpu \
--resource-group MyRG \
--location eastus \
--enable-workload-profiles true
# Add GPU workload profile
az containerapp env workload-profile add \
--name myenv-gpu \
--resource-group MyRG \
--workload-profile-name gpu-profile \
--workload-profile-type GPU-A100 \
--min-nodes 0 \
--max-nodes 10
# Create container app with GPU profile
az containerapp create \
--name myapp-dedicated-gpu \
--resource-group MyRG \
--environment myenv-gpu \
--workload-profile-name gpu-profile \
--image myregistry.azurecr.io/training-job:latest \
--cpu 8 \
--memory 16Gi \
--min-replicas 1 \
--max-replicas 5
```
## GPU Scaling Rules
### Custom Prometheus Scaling
```bash
az containerapp create \
--name myapp-gpu-prometheus \
--resource-group MyRG \
--environment myenv \
--image myregistry.azurecr.io/ai-model:latest \
--cpu 4 \
--memory 8Gi \
--gpu-type nvidia-a100 \
--gpu-count 1 \
--min-replicas 0 \
--max-replicas 10 \
--scale-rule-name gpu-utilization \
--scale-rule-type custom \
--scale-rule-custom-type prometheus \
--scale-rule-metadata \
serverAddress=http://prometheus.monitoring.svc.cluster.local:9090 \
metricName=gpu_utilization \
threshold=80 \
query="avg(nvidia_gpu_utilization{app='myapp'})"
```
### Queue-Based Scaling (Azure Service Bus)
```bash
az containerapp create \
--name myapp-queue-processor \
--resource-group MyRG \
--environment myenv \
--image myregistry.azurecr.io/batch-processor:latest \
--cpu 4 \
--memory 8Gi \
--gpu-type nvidia-t4 \
--gpu-count 1 \
--min-replicas 0 \
--max-replicas 50 \
--scale-rule-name queue-scaling \
--scale-rule-type azure-servicebus \
--scale-rule-metadata \
queueName=ai-jobs \
namespace=myservicebus \
messageCount=5 \
--scale-rule-auth connection=servicebus-connection
```
## Dapr Integration
### Enable Dapr on Container App
```bash
az containerapp create \
--name myapp-dapr \
--resource-group MyRG \
--environment myenv \
--image myregistry.azurecr.io/myapp:latest \
--enable-dapr \
--dapr-app-id myapp \
--dapr-app-port 8080 \
--dapr-app-protocol http \
--dapr-http-max-request-size 4 \
--dapr-http-read-buffer-size 4 \
--dapr-log-level info \
--dapr-enable-api-logging true
```
### Dapr State Store (Azure Cosmos DB)
```yaml
# Create Dapr component for state store
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.azure.cosmosdb
version: v1
metadata:
- name: url
value: "https://mycosmosdb.documents.azure.com:443/"
- name: masterKey
secretRef: cosmosdb-key
- name: database
value: "mydb"
- name: collection
value: "state"
```
```bash
# Create the component
az containerapp env dapr-component set \
--name myenv \
--resource-group MyRG \
--dapr-component-name statestore \
--yaml component.yaml
```
### Dapr Pub/Sub (Azure Service Bus)
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: pubsub
spec:
type: pubsub.azure.servicebus.topics
version: v1
metadata:
- name: connectionString
secretRef: servicebus-connection
- name: consumerID
value: "myapp"
```
### Service-to-Service Invocation
```python
# Python example using Dapr SDK
from dapr.clients import DaprClient
with DaprClient() as client:
# Invoke another service
response = client.invoke_method(
app_id='other-service',
method_name='process',
data='{"input": "data"}'
)
# Save state
client.save_state(
store_name='statestore',
key='mykey',
value='myvalue'
)
# Publish message
client.publish_event(
pubsub_name='pubsub',
topic_name='orders',
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.