您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

部署最佳实践Deployment Best Practices

每个开发团队都有独特的要求,这使得在任何云服务上都难以实现有效的部署管道。Every development team has unique requirements that can make implementing an efficient deployment pipeline difficult on any cloud service. 本文介绍了部署到应用服务的三个主要组件:部署源、生成管道和部署机制。This article introduces the three main components of deploying to App Service: deployment sources, build pipelines, and deployment mechanisms. 本文还介绍了特定语言堆栈的一些最佳实践和提示。This article also covers some best practices and tips for specific language stacks.

部署组件Deployment Components

部署源Deployment Source

部署源是应用程序代码的位置。A deployment source is the location of your application code. 对于生产应用,部署源通常是由版本控制软件(例如GitHub、BitBucket 或 Azure Repos)托管的存储库。For production apps, the deployment source is usually a repository hosted by version control software such as GitHub, BitBucket, or Azure Repos. 对于开发和测试方案,部署源可以是本地计算机上的项目For development and test scenarios, the deployment source may be a project on your local machine. 应用服务还支持OneDrive 和 Dropbox 文件夹作为部署源。App Service also supports OneDrive and Dropbox folders as deployment sources. 尽管云文件夹可以轻松地开始使用应用服务,但通常不建议将此源用于企业级的生产应用程序。While cloud folders can make it easy to get started with App Service, it is not typically recommended to use this source for enterprise-level production applications.

生成管道Build Pipeline

确定部署源后,下一步是选择生成管道。Once you decide on a deployment source, your next step is to choose a build pipeline. 生成管道从部署源读取源代码,并执行一系列步骤 (如编译代码、缩小 HTML 和 JavaScript、运行测试以及打包组件) 以使应用程序处于可运行状态。A build pipeline reads your source code from the deployment source and executes a series of steps (such as compiling code, minifying HTML and JavaScript, running tests, and packaging components) to get the application in a runnable state. 生成管道执行的特定命令取决于你的语言堆栈。The specific commands executed by the build pipeline depend on your language stack. 这些操作可在 Azure Pipelines 的生成服务器上执行,或在本地执行。These operations can be executed on a build server such as Azure Pipelines, or executed locally.

部署机制Deployment Mechanism

部署机制是用于将生成的应用程序放入 web 应用程序的 /home/site/wwwroot 中目录的操作。The deployment mechanism is the action used to put your built application into the /home/site/wwwroot directory of your web app. /Wwwroot目录是由 web 应用的所有实例共享的已装载存储位置。The /wwwroot directory is a mounted storage location shared by all instances of your web app. 当部署机制将应用程序放在此目录中时,实例会收到同步新文件的通知。When the deployment mechanism puts your application in this directory, your instances receive a notification to sync the new files. 应用服务支持以下部署机制:App Service supports the following deployment mechanisms:

  • Kudu 终结点: Kudu是一种开源开发人员生产力工具,它作为 Windows 应用服务中的单独进程运行,并作为 Linux 应用服务中的第二个容器运行。Kudu endpoints: Kudu is the open-source developer productivity tool that runs as a separate process in Windows App Service, and as a second container in Linux App Service. Kudu 处理连续部署并提供用于部署的 HTTP 终结点,如 zipdeploy。Kudu handles continuous deployments and provides HTTP endpoints for deployment, such as zipdeploy.
  • FTP 和 WebDeploy:使用您的站点或用户凭据,可以通过 FTP或 WebDeploy 上传文件。FTP and WebDeploy: Using your site or user credentials, you can upload files via FTP or WebDeploy. 这些机制不会经过 Kudu。These mechanisms do not go through Kudu.

部署工具(例如 Azure Pipelines、Jenkins 和编辑器插件)使用这些部署机制之一。Deployment tools such as Azure Pipelines, Jenkins, and editor plugins use one of these deployment mechanisms.

使用部署槽位Use deployment slots

请尽可能在部署新的生产版本时使用部署槽位Whenever possible, use deployment slots when deploying a new production build. 使用标准应用服务计划层或更好的应用程序层时,可将应用部署到过渡环境,验证更改,以及执行冒烟测试。When using a Standard App Service Plan tier or better, you can deploy your app to a staging environment, validate your changes, and do smoke tests. 准备就绪后,可以交换过渡和生产槽。When you are ready, you can swap your staging and production slots. 交换操作得到预热必要的辅助角色实例,以匹配生产规模,从而消除停机。The swap operation warms up the necessary worker instances to match your production scale, thus eliminating downtime.

连续部署代码Continuously deploy code

如果你的项目已指定用于测试、QA 和过渡的分支,则每个分支都应持续部署到过渡槽。If your project has designated branches for testing, QA, and staging, then each of those branches should be continuously deployed to a staging slot. (这称为Gitflow 设计。 ) 这使您的利益干系人可以轻松地评估和测试已部署的分支。(This is known as the Gitflow design.) This allows your stakeholders to easily assess and test the deployed the branch.

永远不应为生产槽启用持续部署。Continuous deployment should never be enabled for your production slot. 相反,生产分支 (经常) 应部署到非生产槽上。Instead, your production branch (often master) should be deployed onto a non-production slot. 准备好释放基本分支后,将其交换到生产槽中。When you are ready to release the base branch, swap it into the production slot. 交换到生产中(而不是部署到生产环境)可防止停机,并使你能够通过再次交换回滚更改。Swapping into production—instead of deploying to production—prevents downtime and allows you to roll back the changes by swapping again.

槽使用情况视觉对象

连续部署容器Continuously deploy containers

对于 Docker 或其他容器注册表中的自定义容器,请将映像部署到过渡槽并交换到生产中,以防止停机。For custom containers from Docker or other container registries, deploy the image into a staging slot and swap into production to prevent downtime. 自动化比代码部署更复杂,因为必须将映像推送到容器注册表,并更新 webapp 上的图像标记。The automation is more complex than code deployment because you must push the image to a container registry and update the image tag on the webapp.

对于想要部署到槽的每个分支,设置自动化,在每次提交到分支时执行以下操作。For each branch you want to deploy to a slot, set up automation to do the following on each commit to the branch.

  1. 生成并标记映像Build and tag the image. 作为生成管道的一部分,用 git 提交 ID、时间戳或其他可识别信息标记映像。As part of the build pipeline, tag the image with the git commit ID, timestamp, or other identifiable information. 最好不要使用默认的 "最新" 标记。It’s best not to use the default “latest” tag. 否则,很难跟踪当前部署的代码,这使得调试变得更加困难。Otherwise, it’s difficult to trace back what code is currently deployed, which makes debugging far more difficult.
  2. 推送标记的映像Push the tagged image. 生成并标记映像后,管道会将映像推送到容器注册表。Once the image is built and tagged, the pipeline pushes the image to our container registry. 在下一步中,部署槽位将从容器注册表拉取标记的映像。In the next step, the deployment slot will pull the tagged image from the container registry.
  3. 用新的图像标记更新部署槽位Update the deployment slot with the new image tag. 此属性更新时,站点将自动重新启动并请求新的容器映像。When this property is updated, the site will automatically restart and pull the new container image.

槽使用情况视觉对象

下面是适用于常见自动化框架的示例。There are examples below for common automation frameworks.

使用 Azure DevOpsUse Azure DevOps

应用服务通过部署中心为容器提供内置持续交付App Service has built-in continuous delivery for containers through the Deployment Center. 导航到Azure 门户中的应用,然后在 "部署" 下选择 "部署中心"。Navigate to your app in the Azure portal and select Deployment Center under Deployment. 按照说明选择存储库和分支。Follow the instructions to select your repository and branch. 这会配置 DevOps 生成和发布管道,以便在将新提交推送到所选分支时自动生成、标记和部署容器。This will configure a DevOps build and release pipeline to automatically build, tag, and deploy your container when new commits are pushed to your selected branch.

使用 GitHub 操作Use GitHub Actions

还可以通过 GitHub 操作自动化容器部署。You can also automate your container deployment with GitHub Actions. 以下工作流文件将使用提交 ID 构建并标记容器,并将其推送到容器注册表,并使用新的映像标记更新指定的站点槽。The workflow file below will build and tag the container with the commit ID, push it to a container registry, and update the specified site slot with the new image tag.

name: Build and deploy a container image to Azure Web Apps

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

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@master

    -name: Authenticate using a Service Principal
      uses: azure/actions/login@v1
      with:
        creds: ${{ secrets.AZURE_SP }}

    - uses: azure/container-actions/docker-login@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Build and push the image tagged with the git commit hash
      run: |
        docker build . -t contoso/demo:${{ github.sha }}
        docker push contoso/demo:${{ github.sha }}

    - name: Update image tag on the Azure Web App
      uses: azure/webapps-container-deploy@v1
      with:
        app-name: '<your-webapp-name>'
        slot-name: '<your-slot-name>'
        images: 'contoso/demo:${{ github.sha }}'

使用其他自动化提供程序Use other automation providers

前面列出的步骤适用于其他自动化实用程序,例如 CircleCI 或 Travis CI。The steps listed earlier apply to other automation utilities such as CircleCI or Travis CI. 但是,您需要使用 Azure CLI 在最后一个步骤中使用新的图像标记来更新部署槽位。However, you need to use the Azure CLI to update the deployment slots with new image tags in the final step. 若要在自动化脚本中使用 Azure CLI,请使用以下命令生成服务主体。To use the Azure CLI in your automation script, generate a Service Principal using the following command.

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

在脚本中,使用登录 az login --service-principal ,提供主体的信息。In your script, log in using az login --service-principal, providing the principal’s information. 然后,可以使用 az webapp config container set 设置容器名称、标记、注册表 URL 和注册表密码。You can then use az webapp config container set to set the container name, tag, registry URL, and registry password. 下面是一些有用的链接,可用于构造容器 CI 过程。Below are some helpful links for you to construct your container CI process.

特定于语言的注意事项Language-Specific Considerations

JavaJava

使用 Kudu zipdeploy/ API 部署 JAR 应用程序,并使用WARDEPLOY/ for WAR 应用。Use the Kudu zipdeploy/ API for deploying JAR applications, and wardeploy/ for WAR apps. 如果你使用的是 Jenkins,则可以在部署阶段直接使用这些 Api。If you are using Jenkins, you can use those APIs directly in your deployment phase. 有关详细信息,请参阅此文章For more information, see this article.

节点Node

默认情况下,Kudu 执行节点应用程序 () 的生成步骤 npm installBy default, Kudu executes the build steps for your Node application (npm install). 如果使用的是生成服务(例如 Azure DevOps),则不需要 Kudu 内部版本。If you are using a build service such as Azure DevOps, then the Kudu build is unnecessary. 若要禁用 Kudu 生成,请创建一个应用设置, SCM_DO_BUILD_DURING_DEPLOYMENT 并将值设置为 falseTo disable the Kudu build, create an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, with a value of false.

.NET.NET

默认情况下,Kudu 执行 .NET 应用程序 () 的生成步骤 dotnet buildBy default, Kudu executes the build steps for your .NET application (dotnet build). 如果使用的是生成服务(例如 Azure DevOps),则不需要 Kudu 内部版本。If you are using a build service such as Azure DevOps, then the Kudu build is unnecessary. 若要禁用 Kudu 生成,请创建一个应用设置, SCM_DO_BUILD_DURING_DEPLOYMENT 并将值设置为 falseTo disable the Kudu build, create an app setting, SCM_DO_BUILD_DURING_DEPLOYMENT, with a value of false.

其他部署注意事项Other Deployment Considerations

本地缓存Local Cache

Azure 应用服务内容存储在 Azure 存储中,作为内容共享持续提供。Azure App Service content is stored on Azure Storage and is surfaced up in a durable manner as a content share. 但是,某些应用程序只需要高性能的只读内容存储,其可在高可用性下运行。However, some apps just need a high-performance, read-only content store that they can run with high availability. 这些应用程序可以受益于使用本地缓存These apps can benefit from using local cache. 对于内容管理站点(例如 WordPress),不建议使用本地缓存。Local cache is not recommended for content management sites such as WordPress.

始终将本地缓存与部署槽位一起使用,以防止停机。Always use local cache in conjunction with deployment slots to prevent downtime. 有关将这些功能一起使用的信息,请参阅此部分See this section for information on using these features together.

高 CPU 或内存High CPU or Memory

如果你的应用服务计划使用超过90% 的可用 CPU 或内存,则基础虚拟机在处理你的部署时可能会遇到问题。If your App Service Plan is using over 90% of available CPU or memory, the underlying virtual machine may have trouble processing your deployment. 发生这种情况时,请暂时向上缩放实例计数以执行部署。When this happens, temporarily scale up your instance count to perform the deployment. 完成部署后,可以将实例计数返回到它以前的值。Once the deployment has finished, you can return the instance count to its previous value.

有关最佳实践的详细信息,请访问应用服务诊断,以了解特定于资源的可操作最佳方案。For more information on best practices, visit App Service Diagnostics to find out actionable best practices specific to your resource.

  • Azure 门户中导航到 Web 应用。Navigate to your Web App in the Azure portal.
  • 在左侧导航栏中单击 "诊断和解决问题",这将打开应用服务诊断。Click on Diagnose and solve problems in the left navigation, which opens App Service Diagnostics.
  • 选择最佳方案主页磁贴。Choose Best Practices homepage tile.
  • 若要查看应用的当前状态,请单击 "可用性最佳实践 & 性能" 或 "最佳实践" 以查看应用的当前状态。Click Best Practices for Availability & Performance or Best Practices for Optimal Configuration to view the current state of your app in regards to these best practices.

你还可以使用此链接为你的资源直接打开应用服务诊断: https://ms.portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshootYou can also use this link to directly open App Service Diagnostics for your resource: https://ms.portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.