ACR_NAME=""
RESOURCE_GROUP=""
LOCATION=""
APP_NAME=""
ENV=""
az group create --name $RESOURCE_GROUP --location $LOCATION
az acr create --name $ACR_NAME --resource-group $RESOURCE_GROUP --sku Basic --location $LOCATION
Use Docker Buildx to build a Linux AMD64 compatible image:
# Create and use buildx builder
docker buildx create --use
# Build for linux/amd64 and push directly to ACR
docker buildx build --platform linux/amd64 -t $ACR_NAME.azurecr.io/product-service:latest --push .
✅ This ensures your container is compatible with Azure Container Apps (linux/amd64 architecture).
az acr login --name $ACR_NAME
az containerapp env create \
--name $ENV \
--resource-group $RESOURCE_GROUP \
--location $LOCATION
az containerapp create \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--environment $ENV \
--image $ACR_NAME.azurecr.io/product-service:latest \
--target-port 8080 \
--ingress external \
--registry-server $ACR_NAME.azurecr.io \
--registry-username "<your-acr-username>" \
--registry-password "<your-acr-password>"
✅ Get your ACR username and password via:
az acr credential show --name $ACR_NAME
Use the username
and password
values from the output.
az containerapp show \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--query properties.configuration.ingress.fqdn \
--output tsv
✅ Your public URL will look like:
https://demoappchmaps2025.centralus.azurecontainerapps.io
https://your-app-url/health
→ Health checkhttps://your-app-url/api/products
→ Product APIshttps://your-app-url/swagger/index.html
→ Swagger UI
- Always build using
linux/amd64
if you're using Mac M1/M2 to avoid OS/Architecture mismatch. - Azure Container Apps auto-scales based on HTTP traffic.
- ACA will scale to zero if no traffic = saves cost automatically.
Azure Container Apps is a serverless platform built on Kubernetes for running microservices and APIs, without managing Kubernetes clusters.
✅ Built on Kubernetes and KEDA (Kubernetes Event-Driven Autoscaling)
✅ Automatic scale-out and scale-in based on traffic or events
✅ Supports HTTP-based APIs, event-driven architectures, and background workers
✅ Integrated ingress, scaling, and Dapr (for microservices communication)
✅ Supports private container registries (like ACR) out of the box
✅ Ideal for microservices, APIs, background jobs, and event processors
Now that your basic app is deployed, you can explore advanced Azure Container Apps capabilities:
Feature | Description |
---|---|
🔥 Scale to Zero | Automatically scale down your app to 0 instances when no traffic to save cost. |
🌍 Traffic Splitting | Roll out new app versions with canary deployments (e.g., 80% v1, 20% v2 traffic). |
🧹 Revisions Management | Deploy new revisions without downtime. |
⚡ Autoscaling (KEDA) | Scale apps based on queue length, events, CPU usage, etc. |
🔒 Secure Networking | Integrate with Azure Virtual Network (VNet) for private endpoints. |
📈 Monitoring | Use Container Apps metrics, Azure Monitor, and distributed tracing. |
Suppose you deploy a new revision and want:
- 90% traffic to v1 (stable version)
- 10% traffic to v2 (new version)
You can configure traffic splitting like this:
az containerapp revision set-mode --name $APP_NAME --resource-group $RESOURCE_GROUP --mode multiple
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--type revision \
--revision-weight latest=10 stable=90
✅ This allows safe gradual rollout of new app versions!
✅ No downtime during upgrades.
- 📘 Azure Container Apps Documentation Overview
- 📘 Code to Cloud Options with Azure Container Apps
- 📘 Deploying Revisions and Traffic Splitting
- 📘 Build and Push Containers with Docker Buildx
- 📘 Scale Rules with KEDA
✅ Deployed a fully containerized GoLang Product Service API on Azure Container Apps
✅ Container built for linux/amd64 using Docker Buildx (important for M1/M2 Macs)
✅ Image securely stored in Azure Container Registry (ACR)
✅ App publicly accessible with HTTPS
✅ Ready for future enhancements like autoscaling, private networking, canary deployments, and observability.