你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

部署最佳做法

项目
06/03/2024

注意

从 2024 年 6 月 1 日开始，所有新创建的应用服务应用都可以选择生成唯一的默认主机名，命名约定为 <app-name>-<random-hash>.<region>.azurewebsites.net。现有应用名称将保持不变。

示例： myapp-ds27dh7271aah175.westus-01.azurewebsites.net

有关更多详细信息，请参阅应用服务资源的唯一默认主机名。

每个开发团队都有独特的要求，因此很难做到在任何云服务上都能实现高效的部署管道。本文介绍了部署到应用服务的三个主要组件：部署源、生成管道和部署机制。本文还提供了特定语言堆栈的一些最佳做法和提示。

部署组件

部署源

部署源是指应用程序代码的位置。对于生产应用，部署源通常是由版本控制软件（例如 GitHub、BitBucket 或 Azure Repos）托管的存储库。对于开发和测试方案，部署源可能是本地计算机上的一个项目。

生成管道

确定了部署源后，下一步就是选择生成管道。生成管道将读取来自部署源的源代码并执行一系列步骤（例如，编译代码、缩小 HTML 和 JavaScript、运行测试以及打包组件等），以使应用程序处于可运行状态。生成管道所执行的具体命令取决于你的语言堆栈。这些操作可以在诸如 Azure Pipelines 之类的生成服务器上执行，也可以在本地执行。

部署机制

部署机制是指将生成的应用程序放入 Web 应用程序的 /home/site/wwwroot 目录中的操作。 /wwwroot 目录是 Web 应用的所有实例一起共享的已装载存储位置。当部署机制将应用程序放入此目录时，实例会收到要同步新文件的通知。应用服务支持以下部署机制：

Kudu 终结点：Kudu 是一种开放源代码开发人员生产力工具，在 Windows 应用服务中是作为单独进程运行，在 Linux 应用服务中是作为第二个容器来运行。 Kudu 可以处理持续部署，并提供用于部署的 HTTP 终结点，例如 zipdeploy/。
FTP 和 WebDeploy：通过使用站点或用户凭据，可以通过 FTP 或 WebDeploy 上传文件。这些机制都无需经过 Kudu。

诸如 Azure Pipelines、Jenkins 和编辑器插件之类的部署工具将使用这些部署机制之一。

使用部署槽位

在部署新的生产版本时，应尽可能使用部署槽位。如果使用标准应用服务计划层或更好的层级，则可以将应用部署到过渡环境、验证更改并执行冒烟测试。准备就绪后，可以交换过渡槽和生产槽。交换操作将根据生产规模所需预热必要的辅助角色实例，从而缩短故障时间。

持续部署代码

如果项目中指定了用于测试、QA 和过渡的分支，则每个分支都应持续部署到过渡槽位。（这称为 Gitflow 设计。）这使利益干系人可以轻松地评估和测试已部署的分支。

对于生产槽位，不得启用持续部署。而是应将生产分支（通常是主分支）部署到非生产槽上。准备好发布基本分支后，请将其交换到生产槽中。交换到生产槽位（而不是部署到生产槽位）可以防止故障停机，并且允许通过再次交换来回滚更改。

此图显示了开发、过渡和主分支与它们所部署到的槽位之间的流动。

持续部署容器

对于 Docker 或其他容器注册表中的自定义容器，请将映像部署到过渡槽位后交换到生产槽位中，以避免故障停机。这一自动过程比代码部署更复杂，因为必须将映像推送到容器注册表上，并更新 Webapp 上的映像标记。

对于想要部署到槽位的每个分支，请设置自动化过程，以在每次提交到分支时执行以下操作。

生成并标记映像。作为生成管道的一部分，使用 Git 提交 ID、时间戳或其他可识别信息来标记映像。最好不要使用默认的“latest”标记。否则将很难追溯到当前部署的代码，导致调试难度加大。
推送已标记的映像。生成并标记了映像后，管道会将该映像推送到容器注册表。下一步，部署槽位将从容器注册表中拉取已标记的映像。
使用新的映像标记更新部署槽位。此属性更新时，站点将自动重启并拉取新的容器映像。

槽位使用情况的可视化效果

下面是常用的自动化框架示例。

使用 Azure DevOps

应用服务通过部署中心为容器提供内置的持续交付。导航到 Azure 门户中的应用，然后在“部署”下选择“部署中心”。按照说明选择存储库和分支。这将配置 DevOps 生成和发布管道，以便在将新提交推送到所选分支时，自动生成、标记和部署容器。

使用 GitHub Actions

还可以通过 GitHub Actions 完成自动化容器部署。以下工作流文件将生成和标记带有提交 ID 的容器，并将其推送到容器注册表，然后使用新的映像标记来更新指定的 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 应用程序，并使用 wardeploy/ 部署 WAR 应用。如果使用的是 Jenkins，则可以在部署阶段直接使用这些 API。有关详细信息，请参阅此文章。

节点

默认情况下，Kudu 会执行 Node 应用程序的生成步骤 (npm install)。如果使用的是生成服务（例如 Azure DevOps），则不需要 Kudu 生成。若要禁用 Kudu 生成，请创建一个值为 false 的应用设置 SCM_DO_BUILD_DURING_DEPLOYMENT。

.NET

默认情况下，Kudu 会执行 Node 应用程序的生成步骤 (dotnet build)。如果使用的是生成服务（例如 Azure DevOps），则不需要 Kudu 生成。若要禁用 Kudu 生成，请创建一个值为 false 的应用设置 SCM_DO_BUILD_DURING_DEPLOYMENT。

其他部署注意事项

本地缓存

Azure 应用服务内容存储在 Azure 存储中，作为内容共享持续提供。但是，某些应用只需要高性能的只读内容存储，就能以高可用性运行。这些应用受益于本地缓存的使用。对于内容管理站点（例如 WordPress），建议不要使用本地缓存。

本地缓存应始终与部署槽位一起使用，以避免故障停机。有关将这些功能一起使用的信息，请参阅此部分。

高 CPU 或内存

如果应用服务计划占用了超过 90% 的可用 CPU 或内存，则基础虚拟机在处理部署时可能会遇到问题。发生这种情况时，请暂时纵向扩展实例计数以执行部署。完成部署后，可以将实例计数返回至以前的值。

有关最佳做法的详细信息，请访问应用服务诊断，了解特定于资源的可操作最佳做法。

在 Azure 门户中导航到 Web 应用。
在左侧导航栏中选择“诊断并解决问题”，这会打开“应用服务诊断”。
选择“最佳做法”主页磁贴。
选择“关于可用性和性能的最佳做法”或“关于理想配置的最佳做法”，查看应用在这些最佳做法方面的当前状态。

还可以单击此链接，直接打开资源对应的“应用服务诊断”：https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot。

通过