DevOps on Azure with ASP.NET Core

引言和背景

DevOps，DevOps，DevOps。我个人认为DevOps是大多数软件开发项目中必不可少的一部分。然而，真正理解DevOps能提供什么，或者DevOps本身是什么的人却很少。至于DevOps是什么，我留到以后再写一篇帖子来阐述，但在这篇帖子中，我将试着概述DevOps能提供什么，以及如何在Microsoft Azure上启动你的DevOps流水线。在这篇帖子中，我们将介绍Microsoft和Azure平台提供的一些平台级服务，并了解如何构建一个完整的工具链——或者更确切地说，Microsoft Azure如何帮助我们在这些服务上构建DevOps流水线。我们的服务将包括但不限于：

• Visual Studio Team Services
• Azure App Service
• Azure Application Insights

然后，我们将继续演示如何启动任何框架或运行时的应用程序，以及如何配置DevOps流水线——包括但不限于持续集成、交付和部署。本文的实践部分将介绍Azure为团队实施DevOps提供的服务，理论部分将涵盖DevOps是什么，以及它为何如此重要！

我很想知道你是否了解DevOps，DevOps对你意味着什么，以及你的团队是否需要DevOps。

什么是DevOps？

DevOps，让我们抛开过于典型的DevOps定义，即DevOps是融合了软件工程师的工具和思维方式的一种理念和概念。问题在于，运维在哪里？或者更确切地说，软件工程师在运维方面可以进行到什么程度的干预？让我们重新定义这个概念，但首先，DevOps成为现代软件工程重要支柱的主要概念和特征是：

• 减少组织孤岛。
• 接受——如果不是拥抱——失败。
• 实施渐进式变革。
• 利用工具和自动化。
• 衡量一切。

我从Google的Cloud Platform博客上摘录了以上列表，因为我想从一个了解DevOps及其大规模实现方法的人那里获取信息。在维基百科、微软等地方也能找到类似的内容。关键在于，这些是任何DevOps实践的关键要素。Google有内部职位，即站点可靠性工程师（SRE）。大多数人认为DevOps的工作，就是这些SRE在做。

还有一点，与其以图形化的方式展示DevOps，不如我们换个方法，将DevOps呈现为它实际的样子；毕竟，我们谈论的是软件工程师和开发人员，对吧！？

// Apologies for C# style
interface DevOps
{
    /// <summary>
    ///  Give ownership to the person(s) managing it. 
    ///  Let them take the wheel for a while.
    /// </summary>
    void GrantOwnership();

    /// <summary>
    /// Understand that an error has to be encountered, 
    /// employ post-mortem reports, check and understand
    /// what went wrong, what could have been improved. 
    /// Keep a limitation, figure out what defines
    /// your service as reliable (thus, the name Site Reliability Engineering).
    /// 
    /// See https://en.wikipedia.org/wiki/Reliability_engineering.
    /// </summary>
    /// <param name="threshold">Threshold is the criteria to measure reliability; 
    /// (1 - Probability of Failure).</param>
    void BearFailure(int threshold);

    /// <summary>
    /// SREs or DevOps also requires that you ship changes as you make them, 
    /// minor patches are easier
    /// to be determined for bugs or crashes, than huge quarterly updates. 
    /// 
    /// Consider giving the control to the teams, 
    /// but define a specific sprint when to publish
    /// the changes in production; A/B testing for instance. 
    /// </summary>
    /// <param name="sprintNumber">Define when to push the changes in the stream.
    /// </param>
    void ReleaseProdution(int sprintNumber);

    /// <summary>
    /// DevOps does container CI/CD. Configure those pipelines 
    /// to automatically do the things
    /// an operations guy would have to jump in for. 
    /// </summary>
    void ConfigurePipelines();

    /// <summary>
    /// Monitoring is the way for your teams to check and 
    /// visualize how site is being used, what 
    /// areas of app are lagging, which countries are facing latency issues and so on.
    /// </summary>
    void Watch();
}

这些对你来说有意义吗？所以现在，我们设想DevOps就像一个合同，一个你的流程在消耗它之前必须实现的接口。没有简单的方法可以做到这一点，正如你所见，大多数步骤都是为流程准备的；构建、部署、测试，而其中大多数都是文化变革；包括但不限于赋予所有权，接受失败而不是沮丧。

现在我们回到主题，讨论Azure如何为我们提供设置DevOps环境所需的工具和服务。

Azure DevOps Project

微软曾为开发人员提供开发应用程序的工具和服务，为运维团队提供部署和管理应用程序的平台。对开发人员而言，TFS、VSTS等工具能带来无与伦比的生产力；而对运维团队而言，Azure App Service和Azure Application Insights等服务和平台则能提供更丰富的体验，按需深度、可控地部署和扩展应用。

Azure DevOps Project是这两个平台（App Service和VSTS）的延续。由于该服务尚处于预览阶段，我们无法确定其他服务是否会加入（最值得注意的是Azure Container Service），但目前这些服务的结合构成了Azure DevOps Project。以前，在Azure和VSTS上创建和启动简单的DevOps CI/CD流水线需要：

• 配置了Azure服务终结点的VSTS账户。
• 已设置了适当的部署选项的Azure App Service。

然后，为了获得更多控制，您可能还需要创建一个单独的监控包，例如Application Insights。尽管Azure支持资源组，即使那样也需要您自己进行配置。

然后，最后，在所有这一切完成后，您仍然没有仪表板！仪表板是可视化产品/项目/应用程序所有信息的统一场所。您可以查看应用程序的当前状态、部署状态、应用程序的当前使用情况、失败与成功率等等。现在，让我们深入了解本篇文章的实践部分，部署一个新的DevOps流水线，并实际理解Azure在云端设置DevOps流水线方面能为我们带来哪些好处。

请务必查看Azure DevOps Project文档和Azure上的产品详情。

创建项目

与所有其他服务一样，Azure DevOps Project也必须在云端部署，您可以轻松创建新资源。只需前往Azure门户，搜索“devops”，您就会找到DevOps Project资源。这就是我们目前感兴趣的资源。该页面将向您展示流水线的完整周期，此资源创建中一个有趣的地方是，Azure会根据您的选择显示相关的页面和字段。我们将创建一个基本的ASP.NET Core应用程序，并在Windows App Service上运行它，但工作流将为您提供所有主要的运行时、框架、不同的部署模型和要使用的服务，如Kubernetes、虚拟机、Windows或Linux App Service等等。

如果您已经开始了资源创建过程，您会在第一页找到以下页面；而不是资源创建表单。

正如您所见，这个项目将能够为您配置各种运行时和框架。选择其中一个将引导您进入后续的支持选项。这将生成一个包含项目所有设置的资源模板，我们路径中的其他选项将是：

在这里还要注意的一点是，这是为您创建基本模板项目的地方。因此，Azure还会询问您是否要添加新的数据库连接。数据库连接可用于账户和其他存储。我们选择ASP.NET Core，因为ASP.NET Core暴露了更多的部署应用程序平台。

Azure是一个巨大的选择平台。既然我们已经选择了ASP.NET Core，我们可以看到这个平台可以部署在大量的服务上。

• Kubernetes容器编排，您的应用程序将被打包并作为镜像发布到Azure，由Azure负责编排——我们将在后面的模块中介绍这一点。
• Service Fabric应用程序也得到编排和管理。
• Windows和Linux上的Web应用是两种选择，您的应用程序结构将相同，但平台不同。
• Web App for Containers是一个基于Linux的平台选项，用于在无服务器容器平台中运行您的镜像。您可以阅读我其他的文章，了解如何将镜像部署到Web App for Containers。
• 虚拟机提供IaaS选项，用于在Azure上部署您的应用程序。

在此示例中，我们将讨论如何将应用程序发布到Web App并使用Windows作为选项——请记住，基于Linux的App Service具有更好的性能和低延迟！我选择它只是为了简单起见。

这是显示配置的页面。如您所见，我们需要一个Visual Studio Team Services账户（或者我们可以在这里创建一个新的），然后最后要做的就是创建我们可以在其中托管应用程序的平台托管服务。这样，我们就构建并设置了一个使用Visual Studio Team Services和Azure App Service的开发到生产链。输入这些设置，就完成了。

DevOps流水线

典型的DevOps流水线将包含以下步骤：

• 构建（集成）
• 测试和打包（交付）
• 部署（部署）

大多数时候，构建和测试是同时完成的，导致交付步骤变得模糊。然而，这些是DevOps流水线中执行单个操作所采取的步骤。在这些步骤的边界之外，是以下步骤：

• 设计和规划冲刺
• 编码功能和用户故事
• 部署后监控应用程序

一切都被整合到一个周期中，这个周期从应用程序的诞生开始，一直到应用程序的生命周期结束，直到产品退役或下一阶段的启动。

功能	Visual Studio Team Services	Azure App Service	Azure Application Insights
减少孤岛	VSTS提供IAM和管理功能，允许其他成员贡献和协作仓库。看板、Scrum待办事项列表等所有内容都对所有者、成员和利益相关者可见。	Azure AD可以配置允许来自域的用户在Azure平台上协作和参与服务的部署和管理。	Azure Application Insights可以生成可以从任何地方访问的报告，甚至是Power BI仪表板或自定义解决方案。
接受失败	我们失败的测试虽然构成严重威胁，但我们可以检查构建失败的程度以及我们需要如何处理。		我们可以轻松地可视化应用程序的报告，并查看它们在特定时间段内的表现。
实施渐进式变革	您可以以一种方式定义功能和史诗，以便在一个版本中，能够衡量改进或错误的改变。	建议将更改提交到部署槽，或对其进行A/B测试，以便您知道是否保留或忽略该更改。	在特定版本发布后，Insights可以帮助您衡量整体的改进或错误。
自动化	VSTS允许您在每个步骤中使用触发器自动启动并保持流水线运行。
监控		App Services通过Application Insights支持基本洞察。	Application Insights提供了完整的应用程序监控和事后分析解决方案。

这个表格几乎总结了您可以用来优化DevOps周期运行的功能。所有这三项服务都在一个仪表板中创建和提供，供我们管理和可视化正在发生的事情。

现在，这展示了Azure上的DevOps意味着什么。这个仪表板让我们能够访问所有信息，包括当前版本控制、当前运行的版本发布以及访问应用程序的终结点。

触发CI/CD

现在开发人员需要知道的唯一信息是仓库路径，原因是，我们不需要配置构建或发布定义；*因为它们是在我们创建项目时由Azure创建的*。该定义包含ASP.NET Core构建和打包的配置，并最终完成所有已构建工件的复制。

这将自动触发，并将应用程序部署到平台，从那里我们可以在仪表板中轻松捕获当前构建或发布的信息。

我们可以继续使用在线Visual Studio编辑功能，触发对网站的更改，只需更改网站的标题和主页元素，以展示其工作原理。此更改将自动触发提交，进而触发DevOps流水线。让我们来看看。

提交更改将触发CI。

现在后端正在运行集成，并将构建项目。

这将触发部署，并将应用程序部署到Microsoft Azure的App Service。这仍然不是一个好的做法，因为我们将应用程序直接部署到了生产槽。您应该考虑将其推送到部署槽并进行测试，然后再向更广泛的受众公开。阅读我在Microsoft MVP团队博客上关于如何在Azure App Service中部署应用程序的文章，了解如何做到这一点。最后，网站将被部署，仪表板将开始显示流量；可以进行详细查看。

查看更新后的仪表板，它显示了产品中正在发生的情况。

这就是DevOps项目运行、管理和衡量的过程。

监控

最后，应用程序的监控发生在Application Insights中，它本身就是一个完整的平台。因此，我将向您展示我个人网站的仪表板，该网站托管在Azure上，并提供了一些洞察。

仪表板显示了从使用情况、活动用户、请求、延迟到错误和资源消耗的一切信息。看看仪表板。

通过这些，我们的运维团队可以轻松地了解正在发生什么。例如，延迟何时增加，以及何时抛出异常。洞察仪表板还有更多功能，包括会话管理、用户花费的时间、用户正在与哪些部分进行交互以及地理信息；这些在此未显示，并且超出了本文的范围。

本文到此结束。我希望您从中有所收获。还有很多东西我们没有讲，因为它们会增加文章的总体篇幅，并可能使我们偏离主题——**Azure上的DevOps**。我将撰写另一篇关于使用Kubernetes进行编排的综合性文章。

历史

• 2018年7月1日：初稿