Hello,
We've been trying to install an instance of this solution, based on the MTGCorp.HttpApi.Host solution, version . We're trying to create a docker image using the following versions:
"versions": { "LeptonX": "4.1.0", "AbpFramework": "9.1.0", "AbpCommercial": "9.1.0", "AbpStudio": "0.9.25", "TargetDotnetFramework": "net9.0" },
We've managed to create an image locally, but when trying to deploy this same docker image into an Azure App Service we're running into problems, the Azure App Service expects an internal port 80 and the standard solution uses only https ports.
Because of this, we understand that the azure app service refuses to consider the docker as running correctly and does not provide connectivity to it.
We have tried to change the app to use http, but we end up in a situation where, when accessing the address https://apiaddress/.well-known/openid-configuration, this gives us the error that we cannot use http and we must use https. Without this link working our app does not work.
We would like to run the app as a docker inside an app service, is that possible without major refactoring?
We're happy to provide config files as necessary.
We've tried to follow different guides regarding set up of certificates and we have a wildcart certificate for the https, but still it doesn't work. The guides referencing app services expect to deploy code, and we do not want that since it's more costly and unstable in general, we'd like to use dockers only.
Do you have some solution/guide for this? Should we move away from app services and try a kubernetes cluster instead?
We'll wait for your input.
1 Answer(s)
-
0
To run your ABP application as a Docker container inside Azure App Service, you need to ensure that your container listens on port 80 (the only port Azure App Service routes traffic to by default). By default, ABP's Docker templates are configured to use port 80 for HTTP, but .NET 8+ changes the default to 8080, and HTTPS-only configurations can cause issues if not handled properly.
Here’s how you can resolve your issue:
- Ensure the Container Listens on Port 80
- In your Dockerfile or container startup, set the environment variable so ASP.NET Core listens on port 80:
ENV ASPNETCORE_URLS=http://+:80
- If you are using .NET 8 or later, explicitly set this, as the default is now 8080.
- Disable HTTPS Redirection (if needed)
- If your container is behind Azure’s SSL termination (App Service provides HTTPS at the front), you should disable HTTPS redirection inside your app. In
appsettings.Production.json
or via environment variable:
- If your container is behind Azure’s SSL termination (App Service provides HTTPS at the front), you should disable HTTPS redirection inside your app. In
"Kestrel": { "Endpoints": { "Http": { "Url": "http://*:80" } } }, "App": { "SelfUrl": "https://<your-app-service-url>" }
- Or, set the environment variable:
ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
- Configure OpenIddict/IdentityServer Authority
- Set the
Authority
to your public HTTPS URL (the App Service URL), but allow the app to run on HTTP internally:
- Set the
"AuthServer": { "Authority": "https://<your-app-service-url>", "RequireHttpsMetadata": "false" }
- This allows the discovery endpoint to work, even if the internal traffic is HTTP.
Certificates
- If you need to use a custom certificate for OpenIddict, ensure it is available in the container and referenced correctly. For most App Service scenarios, SSL is terminated at the Azure front end, so you do not need to bind HTTPS inside the container.
App Service Configuration
- In the Azure Portal, under your App Service > Configuration > Application settings, add:
ASPNETCORE_URLS
=http://+:80
AbpLicenseCode
(if needed)
- Remove any HTTPS endpoint bindings from your Dockerfile or appsettings.
- In the Azure Portal, under your App Service > Configuration > Application settings, add:
Testing
- After deployment, access
https://<your-app-service-url>/.well-known/openid-configuration
and it should be reachable.
- After deployment, access
No major refactoring is required—just ensure your container listens on port 80 and does not enforce HTTPS redirection internally. If you need end-to-end HTTPS (including inside the container), you must handle certificate mounting and Kestrel configuration, but for most App Service scenarios, this is not necessary.
Kubernetes is not required unless you have more advanced orchestration needs.
Sources:
- https://abp.io/community/articles/r93u9c6d
- https://abp.io/community/articles/brjzgim6
- https://abp.io/docs/latest/solution-templates/layered-web-application/deployment/deployment-docker-compose
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.
- Ensure the Container Listens on Port 80