Deploying microservices solution to Azure Container Apps #10042

1 Answer(s)

• 

  0

  AI-Bot created 2 months ago

  Support Team ABP Agent

  1. Solution Yes—ABP applications (monolith or microservices) can be deployed to Azure Container Apps (ACA). You have two main options:

  A) Azure Container Apps (serverless containers)

  • When to choose: simpler ops than Kubernetes, fast scale-out, HTTP-based microservices, Dapr sidecars if needed.
  • How to do it for ABP:
    1. Build and push images
       • Use the Dockerfiles/scripts in your ABP solution (etc/build/build-images-locally.ps1) to build and push each service image to your registry.
    2. Create ACA Environment + Container Apps
       • Create an ACA Environment.
       • Create one Container App per ABP service (e.g., AuthServer, IdentityService, SaaSService, AdministrationService, Web/PublicWeb, Gateways, Background workers).
       • For db migration/seed, create an ACA Job that runs your DbMigrator image once, with the same environment variables/secrets as the services.
    3. Configure environment variables (per app)
       • App__SelfUrl: https://{your-app}.azurecontainerapps.io
       • ASPNETCORE_URLS: http://+:80
       • AuthServer__Authority: https://{auth-app}.azurecontainerapps.io
       • ConnectionStrings__Default: your Azure SQL connection string
       • RemoteServices__{ServiceName}__BaseUrl: point to the relevant container app URLs (or to gateway)
       • IdentityClients/Redis/RabbitMQ/ElasticSearch etc. as needed
    4. Set ingress
       • Expose only web/publicweb and gateways externally; keep internal services non-public if using internal calls.
    5. Multi-tenant domain (optional)
       • If using wildcard subdomain tenancy, configure:
         • Tenant resolver domain pattern in AuthServer and Web apps.
         • Account options for multi-domain tenants (ABP 5+).
       • In ACA, front this with Azure Front Door or Azure Application Gateway if you need custom domain + wildcard TLS for subdomains.

  Reference template (for a simple MVC app to ACA)

  • Build and push Docker images (etc/build/build-images-locally.ps1).
  • Create Container App for Web:
    • Image: yourweb:tag
    • Ingress: External, port 80
    • Env vars:
      • App__SelfUrl = https://{app-name}.{env-id}.azurecontainerapps.io
      • ASPNETCORE_URLS = http://+:80
      • AuthServer__Authority = https://{same as SelfUrl or Auth container app URL}
      • ConnectionStrings__Default = <Azure SQL connection string>
  • Create ACA Job (DbMigrator):
    • Image: yourdbmigrator:tag
    • Trigger: Manual or Scheduled once
    • Env vars: same as above (AuthServer, ConnectionStrings)
    • Run once before first release.

  B) Azure Kubernetes Service (AKS)

  • When to choose: advanced networking, full control, Helm/Ingress, production-grade traffic policies, sidecars, service mesh.
  • How to do it for ABP:
    1. Build and push images as above.
    2. Use Helm charts per service (AuthServer, Web/PublicWeb, APIs, Gateways, DbMigrator).
    3. Configure Ingress (nginx/AGIC), certificates (cert-manager/Let’s Encrypt).
    4. Provide the same ABP environment variables via values.yaml.
    5. Automate via Azure DevOps pipelines.

  ABP-specific deployment notes for distributed/microservice solutions

  • Set SelfUrl, AuthServer.Authority and each RemoteServices.BaseUrl to the public addresses that clients/services will actually call.
  • If you face issuer mismatch errors, ensure AuthServer’s issuer equals the external HTTPS authority you set (and if there’s an internal meta address, set it via configuration for internal calls).
  • For subdomain-based multi-tenancy, use ABP’s tenant resolvers and account options for multi-domain, and ensure DNS + TLS supports wildcards.

  2. Sources

  • https://abp.io/docs/latest/deployment/distributed-microservice
  • https://abp.io/community/articles/r93u9c6d

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel