部署最佳做法

發行項
06/01/2024

注意

從 2024 年 6 月 1 日起，所有新建立的 App Service 應用程式都可以選擇使用命名慣例來產生唯一的預設主機名稱 <app-name>-<random-hash>.<region>.azurewebsites.net。現有的應用程式名稱將保持不變。

範例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

如需詳細資料，請參閱 App Service 資源的唯一預設主機名稱。

每個開發小組都有獨特需求，可能會讓在任何雲端服務上實作有效率部署管線變得困難。本文介紹部署至 App Service 的三個主要元件：部署來源、組建管線和部署機制。本文也涵蓋特定語言堆疊的一些最佳做法和秘訣。

部署元件

部署來源

部署來源是應用程式碼的位置。針對生產應用程式，部署來源通常是由版本控制軟體所裝載的存放庫，例如 GitHub、BitBucket 或 Azure Repos。針對開發和測試案例，部署來源可能是本機電腦上的專案。

組建管線

一旦您決定了部署來源，下一個步驟就是選擇組建管線。組建管線會從部署來源讀取您的原始程式碼，並執行一系列步驟 (例如編譯程式碼、縮小 HTML 和 JavaScript、執行測試和封裝元件) 讓應用程式處於可執行狀態。組建管線執行的特定命令取決於您的語言堆疊。這些作業可以在組建伺服器 (例如 Azure Pipelines) 上執行，或在本機執行。

部署機制

部署機制是一種動作，用來將您建置的應用程式放入 Web 應用程式的 /home/site/wwwroot 目錄。 /wwwroot 目錄是 Web 應用程式所有執行個體共用的掛接儲存位置。當部署機制將您的應用程式放在此目錄中時，您的執行個體會收到同步新檔案的通知。 App Service 支援下列部署機制：

Kudu 端點：Kudu 是開放原始碼開發人員生產力工具，可在 Windows App Service 中以個別處理序執行，並在 Linux App Service 中作為第二個容器執行。 Kudu 會處理持續部署，並提供 HTTP 端點以進行部署，例如 zipdeploy/。
FTP 和 WebDeploy：使用您的網站或使用者認證，您可以透過 FTP 或 WebDeploy 上傳檔案。這些機制不會通過 Kudu。

Azure Pipelines、Jenkins 和編輯器外掛程式等部署工具會使用這些部署機制的其中一個。

使用部署位置

盡可能在部署新生產環境組建時，使用部署位置。使用標準 App Service 方案層或更佳的層級時，您可以將應用程式部署到預備環境、驗證您的變更，以及進行煙霧測試。當您準備就緒時，就可以交換預備和生產位置。交換作業會準備必要的背景工作角色執行個體，以符合您的生產規模，進而消除停機時間。

連續部署程式碼

如果您的專案已指定用於測試、QA 和預備的分支，則其中每個分支都應該持續部署到預備位置。 (這稱為 Gitflow 設計。)這可讓專案關係人輕鬆地評估並測試已部署的分支。

永遠不應該針對您的生產位置啟用持續部署。相反地，生產分支 (通常為主要分支) 應該部署到非生產位置。當您準備好釋放基礎分支時，請將其交換至生產位置。交換至生產環境，而不是部署到生產環境，可防止停機並可讓您藉由再次交換來復原變更。

圖表顯示開發、預備和主要分支與其部署至位置之間的流程。

持續部署容器

針對來自 Docker 或其他容器登錄的自訂容器，將映像部署到預備位置，並交換至生產環境以避免停機。自動化比程式碼部署更為複雜，因為您必須將映像推送至容器登錄，並在 Web 應用程式上更新映像標籤。

針對您想要部署至位置的每個分支，設定自動化以在每次認可至分支時執行下列動作。

建置和標記映像。作為組建管線的一部分，使用 git 認可識別碼、時間戳記或其他可識別資訊標記映像。最好不要使用預設的「最新」標籤。否則，很難回溯目前部署的程式碼，這會使偵錯更為困難。
推送已標記的映像。一旦建置並標記了映像，管線就會將該映像推送至我們的容器登錄。在下一個步驟中，部署位置會從容器登錄提取已標記的映像。
使用新的映像標籤更新部署位置。更新此屬性時，網站會自動重新啟動並提取新的容器映像。

位置使用方式視覺效果

以下有常見自動化架構的範例。

使用 Azure DevOps

App Service 具有供容器通過部署中心的內建持續傳遞。瀏覽至 Azure 入口網站中的應用程式，然後選取 [部署] 下的 [部署中心]。請遵循指示來選取您的存放庫和分支。這會設定 DevOps 組建和發行管線，以在新的認可推送至您選取的分支時自動建置、標記和部署您的容器。

使用 GitHub Actions

您也可以使用 GitHub Actions 將容器部署自動化。下列工作流程檔案會使用認可識別碼建置並標記容器、將其推送至容器登錄，並使用新的映像標籤更新指定的 Web 應用程式。

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

使用其他自動化提供者

先前列出的步驟適用於其他自動化公用程式，例如 CircleCI 或 Travis CI。不過，您必須使用 Azure CLI，才能在最後一個步驟中使用新的映像標籤來更新部署位置。若要在自動化指令碼中使用 Azure CLI，請使用下列命令產生服務主體。

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

在指令碼中，使用 az login --service-principal 登入，並提供主體的資訊。然後，您可以使用 az webapp config container set 來設定容器名稱、標籤、登錄 URL 和登錄密碼。以下是一些實用的連結，可讓您建構容器 CI 流程。

如何登入 Circle CI 上的 Azure CLI

語言特定考量

Java

使用 Kudu zipdeploy/ API 來部署 JAR 應用程式，而對於 WAR 應用程式，則使用 wardeploy/。如果您使用 Jenkins，則可以直接在部署階段使用那些 API。如需詳細資訊，請參閱這篇文章。

節點

根據預設，Kudu 會針對您的節點應用程式執行建置步驟 (npm install)。如果您使用 Azure DevOps 之類的組建服務，則不需要 Kudu 組建。若要停用 Kudu 組建，請建立值為 false 的應用程式設定 SCM_DO_BUILD_DURING_DEPLOYMENT。

.NET

根據預設，Kudu 會針對您的 .NET 應用程式執行建置步驟 (dotnet build)。如果您使用 Azure DevOps 之類的組建服務，則不需要 Kudu 組建。若要停用 Kudu 組建，請建立值為 false 的應用程式設定 SCM_DO_BUILD_DURING_DEPLOYMENT。

其他部署考量

本機快取

Azure App Service 的內容儲存在 Azure 儲存體中，並且會持久顯示為內容共用。不過，某些應用程式只需要高效能、唯讀內容存放區，可在其中執行執行並具有高可用性。這些應用程式可從使用本機快取獲益。不建議針對 WordPress 之類的內容管理網站使用本機快取。

一律搭配部署位置使用本機快取以避免停機。如需一起使用這些功能的相關資訊，請參閱本節。

高 CPU 或記憶體

如果您的 App Service 方案使用超過 90% 的可用 CPU 或記憶體，基礎虛擬機器可能無法處理您的部署。發生這種情況時，請暫時擴大您的執行個體計數以執行部署。一旦部署完成，您就可以將執行個體計數回復到其先前的值。

如需最佳做法的詳細資訊，請瀏覽 App Service 診斷，找出對資源具體可行的最佳做法。

在 Azure 入口網站中，巡覽至您的 Web 應用程式。
選取左側導覽中的 [診斷並解決問題]，以開啟 App Service 診斷。
選擇 [最佳做法] 首頁圖格。
選取 [可用性和效能的最佳做法] 或 [最佳設定的最佳做法]，從這些最佳做法上，檢視應用程式的目前狀態。

您也可以使用此連結，直接為資源開啟 App Service 診斷：https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot。

共用方式為