从 Visual Studio 部署 Azure Function Slot 部署生产 [英] Deploying Azure Function Slot from Visual Studio deploys Production

查看:39
本文介绍了从 Visual Studio 部署 Azure Function Slot 部署生产的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

简短说明:如何在 Visual Studio 中创建发布配置文件来部署部署槽与生产槽?

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

长: 当您接到 Sev1 电话说生产已被破坏并且您知道在您刚刚向集成部署槽启动部署之前的几分钟的那一刻.是的,这就是刚刚发生在我身上的事情,对于我的一生,我无法解释.

因此,我们有一个名为Int"的 Azure Function 应用程序部署槽.创建发布配置文件时,我只需使用 Visual Studio 中的创建新配置文件"向导并选择选择现有"Azure 应用服务,然后深入Int"部署槽.看起来很直接.这样做会导致 Int AND 生产部署.这当然是出乎意料的,而且显然是灾难性的.

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.

在门户中进行了一些挖掘后,我在 Azure Function 应用程序的概述"部分找到了一个下载发布配置文件"按钮.单击它用于生产以及 INT 会产生两个具有不同用户、destinationAppUrls 等的单独文件.两者之间唯一相同的是 FTP publishUrl,但我假设服务器将路由到适当的根目录传入的凭据.

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.

尽管事实上我有两个独特的发布配置文件,一个用于生产,一个用于 int,但部署它们中的任何一个都会更新生产和我们的部署槽.

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. 从 Visual Studio 中删除了两个发布配置文件,然后通过向导重新创建了它们.
  2. 从 Visual Studio 中删除了两个发布配置文件,并通过从门户下载的配置文件重新创建了它们.
  3. 删除了 INT 发布配置文件,在门户中为我们的 INT 部署槽创建了一个新的 FTP 用户,更新了下载的 INT 配置文件,然后将其导入到 Visual Studio.<== 老实说,我认为这很愚蠢,因为我认为 VS 没有使用 FTP 进行部署.不过我可能是错的.
  4. 确保 AutoSwap 已关闭.
  5. 使用 FTP 客户端使用发布凭据手动登录.事实证明,即使 Production 和 Int 有不同的FTP 部署用户"登录为同一位置的任一点.(这最终似乎是问题所在)
  6. 点击部署槽上的重置发布配置文件"并重新下载配置文件.

除了失去我什至没有失去的自动交换功能之外,我想解决这个问题的一种方法是创建一个完全独立的应用程序,从而迫使它正常工作.如果可能的话,我真的想避免这种情况.

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.

在此先感谢您的帮助.

推荐答案

这不应该发生,但如果我不得不猜测,WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE 的值必须相同 在两个应用程序中定义.前者是您的应用程序内容将保存在其中的存储帐户,后者是该存储帐户中的共享名称.两者共享相同的 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 没问题,但如果您也共享相同的 WEBSITE_CONTENTSHARE,那么您最终会看到您所看到的奇怪行为.

That shouldn't happen, but if I had to guess, you must have the same values for WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined in both apps. The former is the storage account where your app content will be saved, and the latter is the share name in that storage account. It's fine for both to share the same WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, but if you also share the same WEBSITE_CONTENTSHARE, then you'll end up with the odd behavior you're seeing.

通常,当您通过工具创建函数应用程序时,它应该为每个应用程序创建一个具有随机名称的新共享.如果您使用 ARM 模板或其他一些方法进行部署并将它们设置为相同,您将遇到该行为.

Usually when you create the function app through the tooling it should create a new share with a random name for each app. If you deploy using an ARM template or some other method and set these both to be the same you'll run into that behavior.

这篇关于从 Visual Studio 部署 Azure Function Slot 部署生产的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆