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

DevOps 的部署注意事项Deployment considerations for DevOps

在设置和更新 Azure 资源、应用程序代码和配置设置时,可重复且可预测的过程将帮助你避免错误和停机时间。As you provision and update Azure resources, application code, and configuration settings, a repeatable and predictable process will help you avoid errors and downtime. 建议自动执行的部署过程可以按需运行,并在出现故障时重新运行。We recommend automated processes for deployment that you can run on demand and rerun if something fails. 在您的部署过程顺利运行后,处理文档就可以使它们保持正常运行。After your deployment processes are running smoothly, process documentation can keep them that way.

自动化Automation

若要按需激活资源,请快速部署解决方案,最小化人为错误,并生成一致且可重复的结果,确保自动执行部署和更新。To activate resources on demand, deploy solutions rapidly, minimize human error, and produce consistent and repeatable results, be sure to automate deployments and updates.

自动执行尽可能多的进程Automate as many processes as possible

最可靠的部署过程是自动进行的 ,并且 — 是可重复的,以生成相同的结果。The most reliable deployment processes are automated and idempotent — that is, repeatable to produce the same results.

作为一种最佳做法,请创建一个用于快速访问的分类自动化脚本的存储库,其中包含参数说明和脚本使用示例。As a best practice, create a repository of categorized automation scripts for quick access, documented with explanations of parameters and examples of script use. 使此文档与 Azure 部署保持同步,并指定主要人员来管理存储库。Keep this documentation in sync with your Azure deployments, and designate a primary person to manage the repository.

自动化脚本还可以根据需要激活资源,以实现灾难恢复。Automation scripts can also activate resources on demand for disaster recovery.

自动化和测试部署与维护任务Automate and test deployment and maintenance tasks

分布式应用程序由多个必须共同工作的部件组成。Distributed applications consist of multiple parts that must work together. 部署应利用经过验证的机制(如脚本)来更新和验证配置并自动化部署过程。Deployment should take advantage of proven mechanisms, such as scripts, that can update and validate configuration and automate the deployment process. 完全测试所有过程,以确保错误不会导致额外的停机时间。Test all processes fully to ensure that errors don't cause additional downtime.

实现部署安全措施Implement deployment security measures

所有部署工具都必须包含安全限制,以保护部署的应用程序。All deployment tools must incorporate security restrictions to protect the deployed application. 仔细定义并强制实施部署策略,并最大程度地减少人工干预需求。Define and enforce deployment policies carefully, and minimize the need for human intervention.

发布过程Release process

自动部署的难题之一是,将软件从测试的最后阶段到实时生产。One of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. 通常需要快速执行此操作,以最大程度地减少停机时间。You usually need to do this quickly in order to minimize downtime. 蓝绿色部署方法通过确保两个生产环境尽可能相同来实现此功能。The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible.

文档发布过程Document release process

如果没有详细的发布过程文档,操作员可能会部署错误的更新,或者可能无法正确配置应用程序的设置。Without detailed release process documentation, an operator might deploy a bad update or might improperly configure settings for your application. 明确定义和阐述发布过程,并确保将其提供给整个运营团队。Clearly define and document your release process, and ensure that it's available to the entire operations team.

暂存工作负荷Stage your workloads

在继续下一步之前,部署到各个阶段并在每个阶段运行测试/验证,以确保无摩擦的生产部署。Deployment to various stages and running tests/validations at each stage before moving on to the next ensures friction free production deployment.

通过充分利用过渡和生产环境,你可以以高度控制的方式将更新推送到生产环境,并最大限度地减少意外部署问题的中断。With good use of staging and production environments, you can push updates to the production environment in a highly controlled way and minimize disruption from unanticipated deployment issues.

  • 蓝绿色部署 涉及到将更新部署到独立于实时应用程序的生产环境中。Blue-green deployment involves deploying an update into a production environment that's separate from the live application. 验证部署后,可将流量改为路由到更新的版本。After you validate the deployment, switch the traffic routing to the updated version. 实现此目的的一种方法是使用 Azure App Service 中提供的 过渡槽 来暂存部署,然后再将其移动到生产环境。One way to do this is to use the staging slots available in Azure App Service to stage a deployment before moving it to production.
  • 不限,其 版本类似于蓝绿色部署。Canary releases are similar to blue-green deployments. 不是将所有流量切换到已更新的应用程序,而只是将一小部分流量路由到新的部署。Instead of switching all traffic to the updated application, you route only a small portion of the traffic to the new deployment. 如果出现问题,请还原为旧的部署。If there's a problem, revert to the old deployment. 否则,将更多的流量路由到新版本。If not, gradually route more traffic to the new version. 如果使用 Azure App Service,则可以使用 "生产中的测试" 功能来管理不限的版本。If you're using Azure App Service, you can use the Testing in production feature to manage a canary release.

测试环境Test environments

如果开发和测试环境与生产环境不相符,则很难测试和诊断问题。If development and test environments don't match the production environment, it is hard to test and diagnose problems. 因此,应该让开发和测试环境尽量接近生产环境。Therefore, keep development and test environments as close to the production environment as possible. 确保测试数据与生产环境中使用的数据一致,即使测试数据是示例数据而不是实际生产数据(出于隐私或符合性原因)。Make sure that test data is consistent with the data used in production, even if it's sample data and not real production data (for privacy or compliance reasons). 计划生成并匿名化示例测试数据。Plan to generate and anonymize sample test data.

日志记录和审核Logging and auditing

若要尽可能多地捕获版本特定的信息,请实现可靠的日志记录策略。To capture as much version-specific information as possible, implement a robust logging strategy. 如果使用分阶段部署技术,将在生产环境中运行多个版本的应用程序。If you use staged deployment techniques, more than one version of your application will be running in production. 如果出现问题,请确定哪个版本导致了问题。If a problem occurs, determine which version is causing it.

高可用性注意事项High availability considerations

依赖于单个服务实例的应用程序将创建单点故障。An application that depends on a single instance of a service creates a single point of failure. 为了改善复原能力和可伸缩性,预配了多个实例。To improve resiliency and scalability, provision multiple instances.

考虑跨多个区域部署Consider deploying across multiple regions

建议跨多个区域部署所有但最不重要的应用程序和应用程序服务。We recommend deploying all but the least critical applications and application services across multiple regions. 如果你的应用程序部署到单个区域,则在整个区域变得不可用的罕见情况下,该应用程序也会不可用。If your application is deployed to a single region, in the rare event that the entire region becomes unavailable, the application will also be unavailable. 如果选择部署到单个区域,请考虑准备重新部署到次要区域,作为对意外故障的响应。If you choose to deploy to a single region, consider preparing to redeploy to a secondary region as a response to an unexpected failure.

重新部署到次要区域Redeploy to a secondary region

如果在不包含复制的单个主区域中运行应用程序和数据库,则恢复策略可能是重新部署到另一个区域。If you run applications and databases in a single, primary region with no replication, your recovery strategy might be to redeploy to another region. 此解决方案价格合理,但最适用于可以容忍更长的恢复时间的非关键应用程序。This solution is affordable but most appropriate for non-critical applications that can tolerate longer recovery times. 如果选择此策略,会尽可能自动执行重新部署过程,并在灾难响应测试中包括重新部署方案。If you choose this strategy, automate the redeployment process as much as possible and include redeployment scenarios in your disaster response testing.

若要自动执行重新部署过程,请考虑使用 Azure Site RecoveryTo automate your redeployment process, consider using Azure Site Recovery.

后续步骤Next steps