共用方式為

部署最佳做法

  • 發行項

注意

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

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

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

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

部署元件

本節說明部署至 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 或其他容器登錄的自訂容器，將映像部署到預備位置，並交換至生產環境以避免停機。 自動化比程式代碼部署更為複雜。 您必須將映像推送至容器登錄，並更新 Webapp 上的映射標記。

針對您想要部署至位置的每個分支，設定自動化以在每個認可分支上執行這些工作。

  1. 建置和標記映像。 作為組建管線的一部分，使用 git 認可識別碼、時間戳記或其他可識別資訊標記映像。 最好不要使用預設 的最新 標記。 否則，很難追蹤目前部署的程序代碼，這會使偵錯更加困難。
  2. 推送已標記的映像。 建置並標記映射之後，管線會將映像推送至容器登錄。 在下一個步驟中，部署位置會從容器登錄提取標記的映射。
  3. 使用新的映像標籤更新部署位置。 更新此屬性時，月臺會自動重新啟動並提取新的容器映像。

圖表顯示代表 Web 應用程式、Container Registry 和存放庫分支的位置使用視覺效果。

本文包含常見自動化架構的範例。

使用 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 和登錄密碼。 如需詳細資訊，請參閱 如何在 Circle CI 上登入 Azure CLI。

語言特定考量

請記住下列 Java、節點和 .NET 實作的考慮。

Java

使用 Kudu zipdeploy API 來部署 JAR 應用程式。 針對 WAR 應用程式使用 wardeploy 。 如果您使用 Jenkins，則可以直接在部署階段使用那些 API。 如需詳細資訊，請參閱使用 Jenkins 部署至 Azure App 服務。

節點

根據預設，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。

其他部署考慮

其他考慮包括本機快取和高 CPU 或記憶體。

本機快取

Azure App Service 的內容儲存在 Azure 儲存體中，並且會持久顯示為內容共用。 不過，某些應用程式只需要高效能、唯讀內容存放區，可在其中執行執行並具有高可用性。 這些應用程式可從使用本機快取獲益。 如需詳細資訊，請參閱 Azure App 服務 本機快取概觀。

注意

不建議針對 WordPress 之類的內容管理網站使用本機快取。

若要避免停機，請一律搭配 部署位置使用本機快取。 如需一起使用這些功能的詳細資訊，請參閱 最佳做法。

高 CPU 或記憶體

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

如需詳細資訊，請造訪 App Service 診斷 ，以找出資源專屬的可採取動作的最佳做法。

  1. 在 Azure 入口網站中，巡覽至您的 Web 應用程式。

  2. 選取 左側導覽中的 [診斷並解決問題 ]，這會開啟App Service診斷。

  3. 選擇 [可用性] 和 [效能] ，或探索其他選項，例如 [高 CPU 分析]。

    檢視這些最佳做法的應用程式目前狀態。

您也可以使用此連結，直接為資源開啟 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。

相關內容