问题标签 [azure-deployment-slots]

为 Azure WebApp 创建新 Slot 时，如何成功更改一个或多个 AppSettings？

的文档New-AzureRmWebAppSlot建议有一个名为 的参数-AppSettingsOverrides，但这不起作用。

但是应该注意的是，链接的文档似乎错误地引用了New-AzureRmWebAppCmdlet，所以我不能确定该参数是否真的有效（尽管它似乎被接受而没有错误）。

这是我正在运行的代码。

有没有其他人经历过这种看似不正确的行为，如果有，你是如何解决的？

我的 Azure 版本是 3.5.0。

我在 Azure 中创建了一个现有的应用服务，它有一个链接到数据库的连接字符串，配置了“简易表”，以及通过“应用服务编辑器”完成的一大堆自定义 API 方法和表定义。

我正处于开发阶段，我需要使用部署槽，以便为开发、测试和最终运行提供单独的环境。

在创建部署槽时，我可以选择“配置源” - 我可以在其中克隆现有应用程序。当我选择此选项时，我选择了我现有的应用程序，但是我的 Easy Tables 或 API 配置并未随它一起使用，并且似乎我需要重新设置它们？

考虑到我已经在App Service 中设置了所有内容，如何将 Easy Tables 和 API 方法转移到新的部署槽，而无需一一重新创建每个文件。

我试图实现的最终目标是我当前的 Web 应用程序的精确复制——指向一个单独的数据库，拥有自己的 API 调用集合和简单的表——所有这些都使用现有的应用程序作为起点，使用不同的 URL到现有的应用程序。

我们正在尝试将 Azures 部署槽用于我们构建的 Umbraco 站点。

默认情况下，Umbraco 使用在 web.config 的connectionStrings部分中定义的 DSN，我们希望它使用它所在的部署槽的连接字符串。

我们尝试过的

Azure 部署槽将所有已定义的应用程序设置（和连接字符串）放入环境变量中并访问它们，我们可以使用Environment.GetEnvironmentVariable()哪个有效，但似乎没有办法告诉 Umbraco 这样做。

因此，在 OnApplicationInitialized()（在 /App_Code/Core/UmbracoAppStart.cs 中）中，我们从 web.config 加载了连接字符串部分，从 env vars 中获取了 connstr，将 DSN 添加到连接字符串部分并保存。正确的连接字符串被抓取并存储，但这似乎回收了应用程序（由于 web.config 更改），因此我们只是得到超时。（或者 Umbraco XML 缓存错误，或者加载页面需要 20 分钟）。

我知道您可以将 appsettings 和 connectionstrings 部分存储在单独的文件中。但是文件属性（如果引用的文件被更改，不会导致回收）在 connectionStrings 部分不起作用 - 只有configSource属性并且如果更改会回收。

（来自：ASP.NET web.config：configSource 与文件属性）

帮助

有没有人找到解决这个问题的方法？ 我们只需要让 Umbraco 使用部署槽连接字符串——而不是 webconfig 中的那个。

我什至愿意在不了解它是如何工作的情况下盲目地复制和粘贴——我讨厌这样做:)。但这就是当人们同意客户想要在圣诞节前上线时发生的情况......

我在 azure 中有几个插槽，一个用于 qa，一个用于分期，一个用于“直播”。我同时发布到 QA 和 staging，一旦 QA 获得批准，我就想将 staging 与 live 交换（这样 staging 现在变为 live）。

我的问题是，由于 staging 本身就是一个单独的 Web 应用程序，它在 web.config 文件中有自己的设置（数据库连接、客户端 ID、客户端密码等）如果我交换，web.config 是否交换为出色地 ？因此，如果设置不同，我的“实时”应用程序不再具有正确的设置（它采用暂存 web.config 设置）

这个对吗 ？交换部署槽时如何保留实时设置？另外，这对网络作业有何影响？我在 web 应用程序下有几个，具有相应的 app.config 设置

嗨，我部署了一个 API 并在生产中使用，并且我一直在阅读一些有关部署槽的信息。问题是生产中的 API 有自己的自定义 URL。

我想知道的是，如果我部署 API 的更新版本，并在 Azure 中交换它......它是否仍会获得与旧版本相同的 URL？

那就是它也会交换 URL，从而使用它，这样我就不必在其他连接的系统中更改 URL？

我正在尝试编写一个本地控制台应用程序，它将使用Azure REST API交换一个 Azure Web App 插槽。使用以下代码，我得到 401（未经授权）响应：

我知道我需要输入某种凭据，但我发现的似乎适用于使用 Azure AD 进行身份验证的应用程序。这将是一个具有匿名身份验证的可公开访问的 Web 应用程序。

过去，我能够在我的应用服务的部署槽上部署我的 NodeJS Web 应用。portal.azure.com通过配置 git 存储库和分支等，在部署选项刀片中完成了部署。

最近（自上周 1-15-2018 以来的最后几天），所有部署都失败了，包括那些具有最新生产的分支。失败似乎是由于 Azurenpm install基于 package.json 文件中的内容运行所致。

在 Kudu 门户中，确认部署以错误结束，因为该node_modules文件夹包含 0 个项目。

正如我所提到的，我什至创建了一个临时部署槽，通过指向代表当前生产的 git 分支来配置其部署选项，因此没有新代码，没有新包，没有新任何东西。这与当前正在运行的生产完全相同。

它似乎与 Azure 有关。有没有人经历过类似的事情或知道解决方案？Azure 最近有什么变化吗？

这是捕获的活动日志：

我们想稍微改变我们在不同插槽中的 web.config 文件。例如，我们想重定向和代理到不同插槽中的不同 url。我正在考虑使用可以作为环境变量读取的应用程序设置，但我找不到在 XML 中使用它们的方法。我想象这样的事情：

{ENV_EXTERNAL_HOST} 部分当然是错误的。是否可以从 web.config XML 文件的内容中使用这些设置？

在我的 Web 应用程序中，当用户登录到应用程序时，他们的浏览器会向服务器打开一个 Websocket，以便可以将更新推送到浏览器。

它是在 Azure 应用服务中运行的 ASP.NET Core Web 应用（自托管）。我想使用 Azure 的部署槽交换功能将代码更新推送到生产环境，实现零停机部署。

在我所做的有限测试中，看起来在插槽交换之后，Websocket 连接对浏览器连接到的原始插槽保持打开状态。（因此，如果浏览器的 Websocket 连接到插槽 A，并且我们交换了插槽 A 和 B，以便新连接进入插槽 B，那么 Websocket 仍然对运行在插槽 A 上的应用程序开放。）

在某些时候，旧插槽将脱机，这将强制关闭任何打开的 Websocket。我希望在插槽交换后尽快将 Websocket 重新打开到新插槽，这样如果我更新与 Websocket 相关的代码，所有客户端都将尽快运行新代码。

这可能如何工作的草图：

1. 插槽交换发生
2. 向旧插槽上运行的代码发送通知
3. 在旧插槽上运行的代码推送 Websocket 消息以重新连接
4. 收到消息后，浏览器会打开一个新的 Websocket 连接（将转到新插槽）
5. 连接成功后，浏览器关闭旧的 Websocket

有更好的方法吗？

在旧插槽上运行的代码如何知道它何时被交换？

优雅地处理这个甚至可能吗？或者总是会有一堆竞争条件？

我有一个 Azure 生产应用程序槽和一个暂存应用程序槽。我已在生产和登台中将应用程序特定项目设置为“粘性”（连接字符串、键等）

当我在生产和登台之间切换时，我的网络作业设置正在采用登台槽设置，这是灾难性的（我在现场网站中发现了艰难的方式！）

连接字符串名称和键在 Web 应用程序和所有 Web 作业（web.config 和 app.config）中都具有相同的名称，那么为什么会发生这种情况？

我现在必须从我的开发环境手动发布，这并不理想。我注意到的一件事是，以前当我选择我的实时应用程序并进行交换时，该名称保留为我的实时应用程序名称，但现在它始终默认为我没有的“生产”。似乎 Azure 会将其用于主应用程序服务。这之前没有发生过，当我交换插槽时它工作得很好。还有什么我需要注意的吗？插槽交换过程是否发生了某种变化？