问题标签 [azure-configuration]

我正在将我的 .NET MVC 应用程序移动到 Microsoft Azure 云服务。我计划将配置从 web.config 移动到 azure 中的 csdef/cscfg。

我的 web.config 文件几乎没有自定义配置部分。

我在应用程序启动时使用此配置（global.asax）。我想把它转换成csdef/cscfg。通常 cscfg 具有配置设置的键/值对。

谁能建议我如何将自定义配置转换为 azure 中的服务配置？

我们为 MS Azure 编写了一个高度可扩展的云服务，它有两个角色：“WebsiteRole”和“WebsiteWorkerRole”。为了获得更好的性能，我们在多个区域（2 个美国、2 个欧洲、1 个日本）部署了这个 Cloudservice。每个区域都有不同的配置文件（EuWestProductive.azurePubxml、ServiceConfiguration.CloudEuWest.cscfg、Web.ReleaseEuWest.config）。

现在的问题：在每个区域中，我们都运行“WebsiteRole”和“WebsiteWorkerRole”。但是“WebsiteWorkerRole”只有非常小的任务，所以一个区域的一个额外的小实例就绰绰有余了。

我们尝试将角色实例计数设置为零 (ServiceConfiguration.CloudEuWest.cscfg)。但这是不允许的： Azure 反馈：允许角色实例计数为 0

部署云服务时是否有其他方法可以删除角色？

因此，我是 Azure 的新手，目前正在从事一个项目，在该项目中我将使用 azure 批处理在具有不同配置的多个实例中运行应用程序。

我想知道这样做的最佳实践是什么，参考更改配置文件、部署、如何将它们与源代码控制等链接起来有多容易。

任何想法/知识都会有所帮助，因为我似乎找不到太多基于 Azure 批处理和配置文件。

我可以让我的 OnPremise 服务器上运行的 MongoDB 实例与 azure 托管服务交互吗？我看过这个 https://azure.microsoft.com/en-in/documentation/articles/web-sites-dotnet-store-data-mongodb-vm/

但是上面的一个和大部分链接都建议创建一个在 AzureVM 上运行的 MongoDB 实例。是否真的需要或者我可以使用本地 MongoDB 实例来解决这个问题。

任何输入都受到高度赞赏。

提前致谢

我的配置代码以提供默认值的方式设置，并且配置文件可用于覆盖这些默认值。

对于 Azure Worker Roles，我使用CloudConfigurationManager从ServiceConfiguration.*.cscfg文件中读取配置以覆盖默认值。

覆盖默认值的一个常见原因是在测试期间提供不同的存储（blob、表、队列等）名称。

不幸的是，据我所知，一旦在ServiceDefinition.csdef文件中定义了设置，就必须在所有ServiceConfiguration.*.cscfg文件中提供它。

这消除了创建较少配置和减少创建该配置时出现错误的机会的优势。

有没有办法使设置成为可选？

或者是否有其他地方可以让我按照我想要的方式获得特定于部署的配置值？

您能否告诉我如何操作 Azure 连接空闲超时？

现在我正在使用 Azure VM 并在 IIS 中托管我的 Web 应用程序。我的应用程序从外部网络调用休息服务，需要 5-10 分钟才能得到响应。我已经读到如果超过 4 分钟没有响应，Azure 将关闭任何连接。我尝试从 Azure 门户公共 IP 配置中将空闲超时设置为 30 分钟，但这并不能解决问题。

在我的系统中 LockDuration = 5 分钟，AutoRenewTimeout = 20 分钟。处理某些消息需要超过 5 分钟（有时 5:15，有时超过 6:00）。对于这些消息，我有一个例外：

我在我们的日志中读到，系统开始处理一条消息（我们称之为 Process_A），它仍在进行中，5 分钟后，系统再次开始处理同一条消息（我们称之为 Process_B）。Process_A 完成并调用 Complete()。然后 Process_B 完成工作并调用 Complete()。它会导致异常，因为此消息已被编译。

我在文档中发现 LockDuration 的最大值是 5 分钟。为什么？超过 5 分钟的消息无法处理？或者可能配置错误？

我正在玩我已发布的小型ASP.NET Core 1.1应用程序。现在我正在关注有关使用appsettings*.json和环境变量的文档。所以我有以下内容：

每个appsettings*.json文件都有一个适当的"ConnectionStrings:"部分：

因此，当我开始发布到 Azure 时，我在发布设置中使用了默认连接字符串（我知道这是错误的），现在这显示在我的应用程序的 Azure 远程设置中：

上面的连接字符串是在我在此屏幕中的第一次发布时填充的（发布向导）：

现在我的生产应用程序似乎在使用上图中的此设置，而不是从我的appsettings.json连接字符串部分中获取设置。

我的appsetting.json文件存在于 Azure 应用服务中：

我知道我可以在发布向导中覆盖该数据库连接字符串以获得正确的字符串，但 Azure 不应该首先从我​​的appsettings.json文件中获取连接字符串，这与它在 Azure 上的存储位置不同。

我有一个在 Azure 上愉快地运行的应用服务，并且一切正常，但是当我查看日志流时，在应用程序日志连接后我有以下条目：

正如您在上面的日志中看到的那样，我得到

这显然是在抱怨我的 web.config 中没有的system.application 。

1. 我应该关心这个消息吗？
2. 我将如何摆脱 Azure 日志流中的这条消息？
3. 由于 system.applicationHost 包含 IIS 中的 Windows 进程激活服务使用的全局配置设置，如果我假设添加一个新部分，如system.applicationHost中的部分

上面的配置会传播到我的 azure 服务器上的所有站点吗？

我目前正在评估 OMS 和 Log Analytics，成本始终以“每个节点”的形式给出，但我不确定节点是什么。
例如，如果我有一个带有 5 个数据库的 SQL-Server，然后我进入 Azure 门户并将日志记录添加到 OMS 工作区，它的成本是一个单位还是 5 个（每个数据库）？
应用服务等也是如此。是一个节点 1 应用服务计划还是每个部署的网站？

是否有任何我错过的文件可以澄清这些问题？

PS：有必要特权的人可以创建标签“操作管理套装”或“日志分析”吗？