问题标签 [azure-deployment-slots]

Short: How do I create a publish profile in Visual Studio that deploys a deployment slot vs production slot?

Long: That moment when you get a Sev1 call saying that Production is busted and you know that minutes before you just fired off a deployment to your integration deployment slot. Yup that's what just happened to me and for the life of me I can't explain it.

So we have one deployment slot for our Azure Function app named "Int". When creating the publishing profiles, I simply used the "Create new profile" wizard in Visual Studio and chose "Select Existing" Azure App Service, and then drilled in on the "Int" Deployment Slot. Seemed pretty straight forward. Well doing so causes both Int AND Production to be deployed. This was certainly unexpected and obviously catastrophic.

After some digging in the Portal I found in the "Overview" section of our Azure Function app there's a "Download publish profile" button. Clicking it for Production as well as for INT yields two separate files with different users, destinationAppUrls, etc. The only thing that was the same between the two was the FTP publishUrl but I assume that the server would route to the appropriate root based on the credentials passed in.

As it stands in spite of the fact that I have two unique publish profiles, one for prod and one for int, deploying either of them updates both production and our deployment slot.

Here's a list of the things I've tried to fix this myself to no avail:

1. Deleted both publishing profiles from Visual Studio and recreated them via the Wizard.
2. Deleted both publishing profiles from Visual Studio and recreated them via the downloaded profiles from the portal.
3. Deleted the INT publishing profile, created a new FTP user in the portal for our INT deployment slot, updated the downloaded profile for INT, then imported it into Visual Studio. <== Honestly I think this was dumb because I don't think VS is using FTP to deploy. I could be wrong though.
4. Ensured AutoSwap is turned off.
5. Used an FTP client to manually login with the publish credentials. Turns out even though Production and Int have different "FTP Deployment Users" logging in as either points at the same location. (This ultimately seems to be the problem)
6. Clicked "Reset publish profile" on the deployment slot and re-downloaded profile.

Other than losing the autoswap feature which I'm not even losing, I suppose one way to work around this would be to create an entirely separate app thus forcing it to work properly. I really want to avoid that if possible though.

Thanks in advance for help here.

我的应用设置需要与 Azure Function 的部署槽保持一致。

我按照下面发布的示例进行操作。

如何在 Azure Arm 模板中使用粘性暂存槽

但是，当通过 VSTS 将资源部署到资源上时，由于“冲突”（https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-common-deployment ）而不断失败-错误）。

我目前有“Microsoft.Web/Sites”和“Microsoft.Web/Sites/Config”的单独资源模板

应用程序设置在“Microsoft.Web/Sites”模板的“siteConfig”属性下指定。

如果“appSettingNames”是一种配置，我可以在 siteConfig 下为“Microsoft.Web/Sites”列出它，如下所示？

其中参数“appSettingNames”是一个数组参数，如下所示：[“setting1”，“setting2”，“setting3”]。

如果有任何指定此配置的示例。这真的很有帮助

谢谢

我有一个在 2017 年 11 月创建的 Azure 应用服务。应用服务称为 ManifestAPI。

我为应用服务创建了一个名为 ManifestAPI-QA 的 QA 部署槽，并且从那时起我一直很高兴地将我的 API 代码更新部署到 QA 槽。我正在使用 Kudu zipdeploy API 从我的 Bamboo 部署服务器部署到 Azure QA 部署槽。没有错误，并且所有端点都工作正常。

现在，我们正准备将产品转移到生产环境，并且我正在尝试部署到基础应用服务 ManifestAPI。所以我在 Bamboo 中创建了一个部署，使用与部署到 QA 插槽完全相同的发布代码，并将其部署到 ManifestAPI URL。但是，当我尝试在基础应用服务中运行 API 时，我收到 502.5 错误。

我尝试使用相同的代码库和来自基本 ManifestAPI 应用服务的发布配置文件从 VisualStudio 2017 中直接发布，认为 Bamboo 部署存在问题。但我得到了同样的 502.5 错误。

查看 eventlog.xml 文件中 LogFiles 文件夹中的 Kudu 站点，我看到以下内容；

检查 Google 上的错误似乎暗示安装在 IIS 本身上的 .Net Core DLL 存在问题。

另外，由于 API 在 QA 部署槽 IIS 实例中运行良好，我相信这意味着我的代码很好。所以，我认为微软提供的 IIS 实例和 .NET Core 文件一定存在一些问题。

我比较了 ManifestApi 和 ManifestAPI-QA 实例的扩展，它们在两个实例上都是相同的。

我尝试从工作 QA 插槽交换到生产（基本应用服务）插槽并得到相同的 502.5 错误。

我创建了一个名为 ManifestAPI-Prod 的新部署槽，通过克隆 ManifestAPI-qa 实例，将我的部署包部署到该槽，并设置连接字符串和应用程序设置以完全匹配我在基本应用程序服务应用程序设置部分中的内容。ManifestAPI-Prod 部署槽工作得很好。

因此，我在 Azure 中与 Microsoft 建立了一个支持案例，到目前为止，我已经花了 2 多天的时间与技术人员来回交流，试图解决这个问题。他们一直说这一定是我的代码中的一个问题，但这对我来说没有任何意义，因为完全相同的部署包在 QA 插槽和现在的 Prod 插槽中工作。一位技术人员甚至说我没有正确部署。但是，我在 VS2017 中使用 dotnet publish，然后压缩生成的文件目录并通过 zipdeploy API 推送到 Kudu。这对部署插槽非常有效，我无法理解我是如何错误地部署它的。

在这一点上，我不知道如何将 API 部署到生产（基本）插槽。

我在这里想念什么？

2018 年 6 月 27 日更新 通过卸载 Azure 生产槽实例中的所有扩展解决了这个问题。然后重新安装 Microsoft Core 扩展。Extensions 刀片仍然显示 ASP.NET Core Extensions 2.1.0-preview2-final 但是当我转到该实例的 Azure 控制台并键入 dotnet --info 时，它列出了以下内容；

值得注意的是 2.1.0-preview2-final 的列表不再出现在 dotnet --info 显示的文件列表中

有没有办法仅在应用程序完全初始化后交换插槽？我在 Azure 上有一个 Web 应用程序，并且交换槽的过程非常快，但在那之后，应用程序必须进行初始化，这在我的应用程序中需要几分钟，因为有一些繁重的任务。

因此，此时为我交换插槽是不值得的。

我想使用交换槽来减少停机时间，我们有一个经常更新的时间表，因为我的客户每天 24 小时工作，即使在周末也是如此。

我可能会优化这个初始化过程，但不是现在......所以我需要一种在初始化之后进行交换的方法，这将减少我的停机时间，以减少交换插槽所花费的时间，这需要几秒钟来重定向所有当前请求。

我正在考虑在初始化后开始工作并提示 Azure 进行交换，但我找不到这样做的方法。这很糟糕吗？有更好的方法吗？

谢谢。

我有一个有 2 个插槽的应用程序。我已将连接字符串存储在密钥保管库中。我在应用程序和 2 个插槽上启用了 MSI。此外，在保管库的访问策略中，我添加了应用程序（生产槽）。但是我无法将插槽添加到访问策略中。例如，我的应用程序名称是 XYZ20180706，插槽是 XYZ20180706/dev 和 XYZ20180706/test。但是当我在服务主体中输入 XYZ20180706/dev 或 XYZ20180706-dev 时，却找不到。

如何为部署槽创建访问策略？

仅在主插槽上启用它是不够的。如果我将应用程序部署到开发槽并运行它，我目前会被拒绝访问（保险库）。

谢谢。

我正在尝试在 Azure 中为 Web 应用程序（登台和生产）创建 2 个不同的插槽。我正在使用“本地 Git 存储库”将我已经构建的应用程序推送到 Azure（所以，没有 VSTS）。

从我的测试中，我注意到插槽之间的交换也会影响 git 存储库。我期待实际上是固定的。

有没有办法避免交换存储库？我猜不是？我不明白为什么 Azure 也决定交换 git 存储库.. 有人能解释一下吗？

目前我只能找到这个似乎以某种方式工作的流程：

我将本地存储库连接到暂存槽，我只推到那里（生产已断开）。当暂存版本合格时，将执行切换到生产。

*注：生产未断流时断流！

大家能不能推荐一个更好的方法。我看错了吗？

非常感谢！

我想遵循 Azure 最佳实践并利用部署槽来测试我的聊天机器人。我已经部署了 2 个我的机器人实例。

我有一个 DirectLine 应用程序可以成功连接到我的生产机器人，但不知道如何将它连接到暂存实例。

关于这个主题的最新 StackOverflow 问题已经过时了。此处接受的答案声称您需要 2 个物理机器人而不是使用部署槽：为 Azure 机器人服务设置槽或多个环境

2018年还是这样吗？如何将 DirectLine 连接到暂存槽？

在我的应用程序中，我有styles.css。现在，我正在为我们拥有开发、测试和生产槽的团队设置槽。

我怎样才能有一个不同的 style.css 用于开发，另一个用于测试？我想要做的是简单地在顶部导航中使用另一种颜色进行开发和测试，表明这不是生产（你在错误的地方 - 不要着色）。

我查看了应用程序设置，但我不知道如何在 .css 文件中强制执行设置。也许答案是一个虚拟目录，将styles.css的路径“覆盖”到dev slot中的styles-dev.css？虚拟目录在交换时是否保留在插槽中？

还有其他方法可以做到这一点吗？

我有一个要部署到 Azure 应用服务的 ASP.NET Core 2.1 API。我使用 Azure SQL Server 作为我的后备数据库。

下面是应用服务（基本）应用程序设置刀片的屏幕截图。这显示 .Net Framework 版本设置为 4.7。

我设置了带有部署槽的应用服务。

对于每个部署槽，我在“应用程序设置”刀片中都有连接字符串，其中包含特定于该槽数据库的值（每个槽有 3 个不同的数据库，并且有 3 个槽）。

QA 和 DEV 插槽几个月来一直运行良好，但是，我们现在正在使用生产插槽（应用服务基础）将 API 推出到 beta 站点，并且似乎应用服务的生产插槽中的连接字符串没有被可靠阅读。具体来说，似乎没有可靠地读取第二个和第三个连接字符串。

这是显示连接字符串的应用服务 --> 应用程序设置刀片的屏幕截图；

如您所见，我为每个检查了插槽设置。HangfireDbConnectioinString 总是无法读取，并且 UspsReferenceDbConnectionString 似乎不稳定，但这可能是因为 Hangfire 数据库未设置并引发异常。

我对 QA 和 DEV 插槽使用相同的设置，它们工作正常。此问题仅发生在生产槽（基本应用服务）设置中。

如果我在我的 API 的 AppSettings.json 文件中包含实际连接字符串并将其重新部署到生产槽，则 API 能够正确访问数据库。当然，这不是一个理想的解决方案，因为它将我的连接字符串置于源代码控制中。

如果它很重要，这里是基本应用服务扩展刀片的屏幕截图。

下面是我的 Startup.cs 中设置数据库的代码部分。

如您所见，我正在使用 Configuration.GetConnectionString("HangfireDbConnectionString") 从 Configuration 中检索连接字符串。

有任何想法吗？

在 Visual Studio 中添加额外的发布配置文件之前，一切正常。当我右键单击相关项目并选择“发布”时，我能够将单个 VS 项目部署到我的 Azure 应用程序服务。
添加部署到附加应用服务暂存槽的 2nd Publish 配置文件后，右键单击相关项目将使用任一配置文件部署解决方案中的所有 VS 项目。

我找到了这个帖子，但不确定在哪里/如何进行这些更改，或者它是否是正确的做法。