Azure Spring Apps 中的藍綠部署策略

本文適用於：✅ 基本/標準 ✅ 企業

本文說明 Azure Spring Apps 中的藍綠部署支援。

Azure Spring Apps（標準方案和更高版本）允許每個應用程式的兩個部署，其中只有一個會接收生產流量。 此模式通常稱為藍綠部署。 Azure Spring Apps 對藍綠部署的支援，以及 持續傳遞 （CD） 管線和嚴格的自動化測試，可讓敏捷式應用程式部署充滿信心。

替代部署

使用 Azure Spring Apps 實作藍綠部署的最簡單方式是建立兩個固定部署，並一律部署到未接收生產流量的部署。 使用適用於 Azure Pipelines 的 Azure Spring Apps 工作，您可以將旗標設定UseStagingDeployment為 true，以這種方式部署。

以下是替代部署方法在實務上的運作方式：

假設您的應用程式有兩個部署： deployment1 和 deployment2。 目前， deployment1 會設定為生產部署，且正在執行應用程式的版本 v3 。

這會建立 deployment2 預備部署。 因此，當持續傳遞 （CD） 管線準備好執行時，它會將下一個版本的應用程式版本版本 v4部署到預備部署 deployment2。

啟動deployment2之後v4，您可以透過私人測試端點執行自動化和手動測試，以確保v4符合所有期望。

當您有信心 v4時，您可以將 設定 deployment2 為生產環境部署，以便接收所有生產流量。 v3 如果您發現需要復原的嚴重問題，將會繼續執行 deployment1 。

現在， deployment1 是預備部署。 因此，部署管線的下一次執行會 deployment1部署到 。

您現在可以在的私人測試端點上deployment1進行測試V5。

最後，在您符合所有期望之後 v5 ，您會再次設定 deployment1 為生產部署，以便 v5 接收所有生產流量。

替代部署方法的取捨

替代部署方法是簡單且快速，因為它不需要建立新的部署。 不過，它確實存在數個缺點，如下列各節所述。

持續性預備部署

預備部署一律會繼續執行，因此會耗用 Azure Spring Apps 實例的資源。 這可有效地將 Azure Spring Apps 上每個應用程式的資源需求加倍。

核准競爭條件

假設在上述應用程式中，發行管線需要手動核准，然後每個新版本的應用程式才能接收生產流量。 這會建立風險，當一個版本 （v6） 等候預備部署的手動核准時，部署管線會再次執行，並以較新版本覆寫它。v7 然後，授與核准 v6 時，部署 v6 的管線會將預備部署設定為生產環境。 但現在會是未核准 v7的 ，而不是已核准 v6的 ，該部署上部署並接收流量。

您可以確定一個版本的部署流程無法開始，直到所有舊版的部署流程完成或中止，才能防止競爭狀況。 另一個防止核准競爭條件的方法，是使用下面所述的具名部署方法。

具名部署

在具名部署方法中，會為每個要部署的應用程式新版本建立新的部署。 在應用程式在其定製部署上測試之後，該部署會設定為生產部署。 包含舊版的部署可以保留足夠長的時間，以確保不需要復原。

在下圖中，版本 v5 正在部署 deployment-v5上執行。 部署名稱現在包含版本，因為已特別針對此版本建立部署。 一開始就沒有其他部署。 現在，若要部署版本 v6，部署管線會建立新的部署 deployment-v6 ，並在該處部署應用程式版本 v6 。

沒有平行部署另一個版本的風險。 首先，Azure Spring Apps 不允許在兩個部署已經存在時建立第三個部署。 其次，即使可能有多個部署，每個部署都是由它所包含的應用程式版本來識別。 因此，協調部署的 v6 管線只會嘗試設定 deployment-v6 為生產部署。

為新版本建立的部署收到生產流量之後，您必須移除包含舊版的部署，以騰出空間供未來部署使用。 您可能會想要延遲一些分鐘或小時，以便在新版本中發現重大問題時，回復至舊版。

具名部署方法的取捨

具名部署方法具有下列優點：

• 它可防止核准競爭條件。
• 它可藉由刪除不在使用中的預備部署來減少資源耗用量。

不過，也有缺點，如下一節所述。

部署管線失敗

在部署開始和刪除預備部署的時間之間，執行部署管線的任何其他嘗試都會失敗。 管線會嘗試建立新的部署，這會導致錯誤，因為 Azure Spring Apps 中每個應用程式只允許兩個部署。

因此，部署協調流程必須有方法，才能在稍後重試失敗的部署程式，或確保每個版本的部署流程會維持排入佇列，直到所有舊版的流程完成為止。

下一步

• 將應用程式部署自動化至 Azure Spring Apps