使用 Azure 插槽来回收应用程序并最大限度地减少停机时间，而不是出于部署原因

Question

是否有人使用过并注意到使用此技术来回收应用程序以最大程度地减少对客户的影响。

需要回收和蔚蓝，并需要尽量减少对客户的影响。

为什么不在 2 个不同的插槽中拥有完全相同的代码库？ 交换插槽，然后应用程序被有效回收。 当交换槽发生时，可以停止/启动该槽。

那么

• [来自插槽 a]
• [至插槽 b]
• 两个插槽具有相同版本的代码
• 恐慌？该应用程序需要回收
• 做一个

  az webapp deployment slot swap

  ...

az webapp deployment slot swap  -g $rg -n $app --slot $a --target-slot $b

• 槽 $a 中的代码被放入 $b 中，
• 并且槽 $b 中的代码被放入槽 $a 中 他们被交换了...

但是，他们没有停止或开始......

但是，他们现在流量完全通过一个或另一个插槽，可以独立停止/启动。

• 因此，在交换之前，用 a 停止 $a 插槽

az webapp stop --resource-group rg --name app --slot <$a>

有人用过这个吗？有人这样做吗？

目标：回收和应用，并最大限度地减少停机时间

Answer 1

是的，

插槽交换是一种常见且高效的 Web 应用程序回收过程方法，用于最大限度地减少部署期间的停机时间，如给定的 MS 文档中所述。

好的方法是停止正在换出的槽中的应用程序服务，以防止在交换期间主动处理请求。

上述过程的PowerShell脚本：

$rg = "xxx"
$a = "newslot"
$b = "slotswap"
$app = "jahapps"
az webapp stop --resource-group $rg --name $app --slot $a
az webapp deployment slot swap -g $rg -n $app --slot $a --target-slot $b

交换完成后，再次重新启动之前停止的应用程序槽。

az webapp start --resource-group $rg --name $app --slot $a

输出：

交换已成功完成，并且也显示在

app service >> deployment slots

下的插槽日志中。