共用方式為

部署最佳做法

  • 發行項

注意

從 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 應用程式上更新映像標籤。

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

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

位置使用方式視覺效果

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

使用 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 流程。

語言特定考量

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。

更多資源

環境變數與應用程式設定參考