【发布时间】：2019-10-22 06:08:45
【问题描述】：
这是应用程序的架构：
- 用 ASP.NET Core 编写的 Web API。
- Dockerfile 使用
microsoft/dotnet:2.1-sdk构建Web 应用程序并使用microsoft/dotnet:aspnetcore-rumtime执行API。该应用程序已编译并放入/app。 - 启动API执行的命令是：
ENTRYPOINT ["dotnet", "/app/WebAPI.dll"] - 此 API 部署到 Azure 容器注册表（Docker 注册表）。
- Azure 应用服务用于托管 API。应用服务配置为从 ACR 中提取给定容器。
- API 完全按预期运行。
问题是我们需要接受大于 IIS 和 Kestrel 规定的 28.6MB 限制的帖子正文大小。我们已经尝试了这个 URL 的方法，但没有成功：https://www.talkingdotnet.com/how-to-increase-file-upload-size-asp-net-core/
- 将 Web.config 文件添加到项目中没有帮助，因为容器中运行的 ASP.NET Core 运行时不会拾取它。 （在容器内只有 Kestrel 正在运行）
- 添加
[RequestSizeLimit]属性并不能解决问题，因为我相信实际限制发生在 Azure 级别。- 如果我理解正确的话，在容器内的 Kestrel 上运行的 Dockerized ASP.NET Core 应用程序是从 Azure IIS 服务器反向代理的。因此 IIS 服务器可能存在 28.6MB 的限制。
- 在
UesKestrel中设置大小限制也无效。 - 当我们尝试实现“中间件”解决方案时，我们发现
Features不是页面代码中给出的context对象的属性。
我们需要知道如何增加最大帖子大小。如果这是在整个应用服务计划级别，则可以。由于我们正在运行容器，我们不知道可以将具有适当设置的 Web.config 文件放在哪里。
【问题讨论】：
-
问题解决了吗？
-
不幸的是，没有。我们迁移到运行 Docker Swarm 的 Azure Linux VM。老实说，成本并没有太大的不同，并且使我们可以完全控制堆栈。我们失去了一些不错的 Azure 脚本功能，但我们用 Docker Compose 和 CI 工具弥补了它。我猜这要么是设计上的限制，要么是微软的“计划”功能。
标签： azure asp.net-core azure-web-app-service kestrel