英文:
Cannot redeploy to staging after swap to production using Azure App Service
问题
我在使用 Azure App Service 的部署槽时遇到了问题。我有两个槽位：一个用于暂存，一个用于生产。
问题是：似乎 GitHub 的部署密钥/连接与实际实例绑定，而不是部署槽。这意味着当我部署到暂存然后与生产交换时，我无法重新部署到暂存。
我已经尝试了一些方法来解决这个问题，包括检查部署设置和应用程序配置，但似乎没有关于将 GitHub 凭据与槽位 vs 实例绑定的内容。问题仍然存在，我仍然无法在交换后部署到暂存实例（之前的生产实例）。
我可以断开连接然后重新连接，但这只能工作一次，在交换后再次出现问题。
奇怪的是，如果我再次交换回来，它就可以正常工作。就好像 GitHub 连接随着底层实例一起交换一样。
是否有办法将部署密钥与槽位绑定，而不是与实例绑定？
是否有其他人遇到过这个问题或有解决方案？提前感谢！
英文:
I'm running into an issue with Azure App Service using deployment slots. I have two slots: one for staging and one for production.
Here's the problem: It seems like the GitHub deployment key/connection is tied to the actual instance and not the deployment slot. This means when I deploy to staging and then swap with production, I'm unable to redeploy to staging.
I've already tried a few things to remedy this, including checking the deployment settings and app configurations, but there does not seem to be anything about tying github credentials to slot vs instance. The issue persists, and I still cannot deploy to the staging instance (previous prod) after swapping.
I can disconnect and connect again, but that would work once, and break again after swapping.
The strange part? If I swap back, it works fine again. It's as though the GitHub connection is swapping along with the underlying instances.
Is there a way to tie the deployment key to the slot, and not the instance?
Anyone else encountered this or have a solution? Thanks in advance!
答案1
得分: 0
最后，我通过创建一个额外的“temp”插槽找到了一个解决方法。有趣的是，即使缺少必要的凭据，暂存插槽也总是显示与GitHub的连接。以下是我采取的逐步过程：
- 首先创建了这个“temp”插槽，并将其链接到GitHub仓库，使得该插槽可以拥有自己的GitHub部署密钥。
- 接下来，我用这个“temp”插槽替换了我的原始暂存插槽。
- 这个替换的结果是，生产和暂存插槽现在都有有效的部署密钥，但只有暂存插槽配置为从GitHub部署。
- 我删除了“temp”插槽，因为它不再需要。
这个过程导致了在我的GitHub仓库中出现两个可见的部署密钥，对应于生产和暂存插槽。虽然这种方法本质上是一个变通方法，但它成功地解决了问题，并且在交换后两个插槽保留了它们的部署密钥。另外，我不确定为什么这会成为一个问题。
英文:
At the end, I found a workaround by creating an additional 'temp' slot. Interestingly, the staging slot would always show a connection to GitHub even when it lacked the necessary credentials. Here's the step-by-step process I undertook:
- I first created this 'temp' slot and linked it to the GitHub
repository, which allowed this slot to have its own GitHub deploy
key. - Next, I swapped this 'temp' slot with my original staging slot.
- The result of this swap was that both the production and staging
slots now had valid deployment keys, but the staging slot was the
only one configured for deployment from GitHub. - I deleted the 'temp' slot as it was no longer
required.
This process resulted in two visible deploy keys in my GitHub repository, corresponding to the production and staging slots. While this approach is essentially a workaround, it successfully addressed the issue, and both slots retained their deploy keys after the swap. Also, I'm not sure why this is even an issue in the first place.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论