【云计算】DevOps

DevOps涉及快速、灵活的开发和供应业务流程。它有效地集成了开发、交付和操作，从而促进了这些传统的分离筒仓的精益、流动连接。在本期软件技术中，Gorka Gallardo、Josune Hernantes、Nicolas Serrano和我简要介绍了最新的DevOps技术，如交付工具和微服务，并讨论了它们对行业项目的意义。我期待读者和专栏作者的来信。 —Christof Ebert
短周期的高质量交付需要高度自动化。
DevOps使用自动化的开发、部署和基础设施监控，将开发和运营的两个领域集成在一起。这是一种组织上的转变，在这种转变中，跨职能团队工作于连续的运营特性交付，而不是分散的、各自为政的团队分别执行功能。这种方法有助于更快、持续地交付价值，减少由于团队成员之间的错误沟通和加速问题造成的问题决议1。
DevOps意味着开发、质量保证和运营之间的文化转向协作。图1显示了通用流程，该流程旨在用适当的技术更好地集成开发、生产和运营业务流程。组织不是停留在永远不会到达的高度特殊的过程概念上，而是通过小的升级来建立持续的交付。亚马逊（Amazon）和谷歌（Google）等公司引领了这一做法，实现了几分钟的周期。显然，可实现的周期时间取决于环境约束和部署模型；单个云服务比实际产品的软件交付更容易实现。
DevOps可以应用于非常不同的交付模型，但必须根据环境和产品架构进行定制。并不是所有的产品都有利于持续交付，例如在安全关键系统中。尽管如此，即使在这种受限的环境中，升级也可以快速、可靠地规划和交付，正如最近发布的汽车软件的发展所显示的那样。除了高度安全的基于云的交付之外，这种交付模型还需要专门的架构和硬件更改。一个例子是一个热插拔控制器，其中一半是可操作的，另一半构建下一个更新，这些更新在深入的安全和验证过程之后切换到活动模式。嵌入式系统的DevOps比云和IT服务更具挑战性，因为它试图将遗留代码和架构与持续交付结合起来。

DevOps工具

在自动化DevOps中，工具是必需的。短周期的高质量交付需要高度自动化。因此，为您的环境或项目选择正确的工具在您迁移到DevOps时非常重要。表1列出了我们在本文中讨论的自动化工具。

构建

在这个DevOps阶段，工具必须支持快速工作流。这里我们讨论两种工具。构建工具有助于实现快速迭代，减少手动耗时的任务。持续集成（Continuous-integration，CI）工具将来自所有开发人员的代码合并，并检查是否有损坏的代码，从而提高软件质量。
构建工具：无论大小，构建自动化对于DevOps环境都是至关重要的。随着敏捷和流畅的开发，构建工具也成为管理软件开发和服务生命周期的工具，其中包括编译代码、管理依赖关系、生成文档、运行测试或将应用程序部署到不同的环境中。
Apache Ant已经成为构建应用程序的标准工具，特别是在需要从源代码构建应用程序时。用于定义要执行的任务的简单语法反映了Ant的主要优点和缺点。它很容易理解，但即使对于简单的任务也是冗长的，因为它使用的是XML，而XML不是一种过程性编程语言。
Maven的目标是解决Ant的一些问题。它还使用XML来定义构建过程。在本例中，语句定义了项目的性质，而不是构建项目的任务。Maven使用项目对象模型（POM），该模型定义了构建系统的统一方法。这具有在项目开始时定义标准的优点，但有时在必须定义自定义操作时会导致不存在。管理依赖项也有助于自动化构建过程，但有时会由于外部自动依赖项而产生问题。
Rake和Gradle试图通过提供基于编程语言的工具来构建应用程序来解决Ant和Maven的问题。使用Rake，代码行是用Ruby编写的；使用Gradle，配置使用基于Groovy的领域特定语言（DSL）。
持续集成工具：CI是一个关键的敏捷概念。CI工具尽可能早和经常地集成开发人员的工作。这样，系统就不断地被测试。拥抱CI并不总是那么简单和直接。例如，在嵌入式系统开发中，测试具有挑战性，因为在目标硬件上构建和测试并不总是可能的，因此必须进行模拟。此外，硬件限制会影响测试速度，从而影响循环时间。
Jenkins是一个开源的、基于Java的系统，也是实现最多的工具之一，因此插件选项很多。由于它的流行，从它庞大的用户群中寻找支持是很容易的。然而，它的用户界面已经过时了，并且不如其他工具的用户界面吸引人。
由ITBrains开发的TeamCity是基于Java的，因此有很好的Java支持，比如Jenkins。与Jenkins不同，它还提供了良好的.NET支持。虽然它是授权的，但它有一个小项目的免费版本。
Bamboo是来自Attlasian的，与其他Attlasian工具结合得很好。所以，如果你已经在使用Attlasian工具的话，它提供了优势。

部署

在这个阶段，最重要的转变是将基础设施视为代码。使用这种方法，可以共享、测试和版本控制基础结构。开发和生产共享一个同质的基础设施，减少了由于基础设施配置不同而产生的问题和bug。
DevOps将自动化从应用程序推进到基础设施。与手动基础设施配置相比，配置管理工具可以减少生产配置和配置维护的复杂性，同时允许在开发机器上重新创建生产系统。这些工具是一个主要的DevOps使能工具，特别是当体系结构从软件的整体块转移到微服务方法时。
为了实现嵌入式系统的连续交付，必须连接设备，因此机器到机器通信和物联网架构是必要的。持续交付将提高上市时间，并允许敏捷实践与快速消费者反馈。然而，对于不能选择故障的关键应用，例如医疗或航空应用，更保守的方法是可取的。以下工具将改进应用程序的生命周期。
Puppet提供基础设施的方法是描述系统所需的最终状态。基于Puppet的基础设施通常由一个主服务器和每个客户机上的代理组成。Puppet基于Ruby，但使用类似于JSON（JavaScript对象表示法）的DSL来表示机器配置。
Chef的方法更多的是在一个纯粹基于Ruby的DSL上编写一个菜谱，详细说明了配置系统所需的步骤。您可以将Chef用作客户机服务器工具，也可以在“Chef solo”模式下单独安装。
Ansible最容易实现，因为它不需要在客户端机器上安装代理，因为它使用SSH（Secure Shell）来推送配置。它是一个基于Python的开源工具，但是配置是用YAML（YAML不是标记语言）文件编码的，减少了学习曲线。
最后，在选择编排技术时，您需要考虑您的生产基础设施是基于虚拟化，还是希望转移到容器化技术（如Docker）。

容器还是虚拟化？

由于开发机器和生产机器之间的差异，为了实现一致性，开发人员使用虚拟化技术在开发机器上重新创建生产环境。但是虚拟化技术关注的是安全性和多租户，而在应用程序开发中，环境一致性是主要目标。
在这个场景中，容器化可以是虚拟化的轻量级替代方案。此外，虚拟化在不同的提供者之间缺乏兼容性，而容器化增强了云提供者之间的迁移。因此，传统的hypervisor供应商，如VMware和Project Bonneville，以及微软和Windows Server 2016，正在他们的平台上集成容器化支持。

运营

尽管研究人员已经非常关注构建和部署，但DevOps也会影响基础设施的运营。因此，您需要工具来维护基础架构的稳定性和性能。
日志工具。日志记录有时被认为是调试的替代品，程序员被建议调试而不是日志记录，这样他们就不会在应用程序中留下痕迹。但从DevOps的观点来看，跟踪对于管理应用程序是必要的。规则是记录所有内容并确定日志的级别（例如，fatal、error、warn、info、trace或debug）。对于不太复杂的应用程序，可以使用标准工具（在Java中，这是Java.util.logging包）。对于更复杂的项目，您可以使用不同语言的框架，如Log4j或Log4j工具系列，尽管这些任务最著名的工具是日志管理系统。
Loggly工具提供基于云的服务，使用HTTP或syslog等开放标准实时从应用程序、平台和服务器收集日志数据。安装很简单，创建自定义性能和DevOps仪表板也很容易。Loggly还提供了强大的搜索功能。与New Relic相结合，有效识别、隔离问题，寻找解决方案。
Graylog2是一个开源日志分析器，允许存储和搜索日志错误。在其易于使用的Web界面中，您可以构建特别的仪表板和强大的警报功能。它处理大量数据格式，并且可以使用大量插件进行定制。
监控工具。监控工具使组织能够在IT基础架构问题影响关键业务流程之前识别并解决这些问题。这些工具监视系统方面，如CPU负载、RAM分配、网络流量统计、内存消耗和可用磁盘空间。他们持续跟踪系统的运行状况，并在管理员发现问题时向他们发出警报，以便管理员能够采取纠正措施。
Nagios是一个著名的开源工具，用于监控IT基础设施，如终端用户站、IT服务和活动网络组件。它提供了一个易于导航的Web界面，带有一个交互式仪表板，其中包括主机、服务和网络设备的高级概述。它提供趋势图和容量规划图，让组织规划基础设施升级。这些插件解决了该工具的一些限制，例如缺少自动设备发现和配置该工具的困难。
基于软件即服务的New Relic为Web应用程序提供了强大的界面，并为iOS和Android监控本地移动应用程序。您可以监视在混合、云或内部部署环境中运行的应用程序。可自定义的仪表板允许您集成其他监视功能。您可以生成自定义报告并设置阈值警报以触发特定事件的通知。
Cacti是一个基于网络的系统，具有直观、易用的界面。它基于模板的配置支持高级别的定制。您可以构建图形，除了标准的列表视图和预览模式外，还可以在树状视图模式下显示图形。

现实世界中的DevOps

软件和IT产业关乎速度和效率。DevOps已经成为一种将创新产品和功能更快推向市场的范例。最近出现了许多技术来平滑开发和运营之间的过渡。他们有共同的流体输送实践，从而管理复杂性。用于快速应用程序交付的技术，例如用于搜索或销售平台的技术，不适用于嵌入式软件。但我们当然可以从这些方法中学习，并将它们映射到其他领域。正如我们前面提到的，用于快速汽车软件更新的无线技术的出现表明，这些原则是可转让的，同时考虑到持续功能安全和保障的严格需求。
云和Web开发是DevOps实践的早期采用者，可以作为其他领域的指南。例如，Amazon Web服务（AWS）提供了几种实现连续交付的工具。其中一个工具是AWS Elastic Beanstalk，它支持使用简单的方法进行连续部署，因此，学习曲线较浅，但可配置性较低。
AWS OpsWorks提供了一种中间方法，您可以在其中编写基础设施的代码；它提供了与Chef的集成。您还可以创建一个以JSON格式编写的AWS CloudFormation模板，以可重复的方式提供基础设施，并控制所有云基础设施组件。您可以使用AWS codeploy服务跨多个虚拟机（弹性计算云实例）部署应用程序，而停机时间最少。
或者，可以使用AWS代码管道。该服务于2015推出，集成了构建、测试和实现。
作为补充，您可以使用其他AWS组件来支持连续交付。AWS代码提交是托管私有存储库的托管源代码管理服务。AWS CloudWatch提供了一个监视和警报基础设施，可以帮助整个团队处理部署的应用程序的可靠性和性能。
图2显示了使用AWS工具的DevOps架构。

超越DevOps:Microservices

研究人员一直在讨论微服务，以便更好地管理复杂的遗留体系结构。微服务软件将系统和应用程序分解为更细粒度、模块化的层次。这种软件大约在10年前作为面向服务架构的后续出现。这种方法是对复杂的应用程序进行分段并按需提供服务，从而提高性能。
DevOps为开发、部署和管理微服务容器生态系统提供了框架。DevOps从重构架构中受益，但并不需要它。它的主要优势是通过集成开发和操作来快速交付周期。
DevOps和microservices应该尽可能地基于云，特别是如果重点是高效的服务交付。与集中管理的云解决方案不同，微服务天生就是分布式的。每次交付都有依赖性影响，必须对这些影响进行分析、验证和包装考虑。当微服务跨网络运行时，交付将导致显著的性能损失，必须通过额外的架构调整来适应，例如缓存层。具有可用性和安全约束的更复杂和关键的应用程序不应该完全由易失性云交付模型来解决。
因为微服务需要DevOps，我们建议从定制的DevOps策略开始。它将具有即时的价值，因为更好地集成整个生命周期，并可以逐步演变为微服务交付模式，如果这是适当的。

DevOps文化变迁

Vector Consulting Services通过DevOps和持续交付帮助多家公司提高了效率。（例如，请参阅侧边栏“DevOps案例研究”。）所有这些公司的一个重要教训是，不要低估文化的转变。所有DevOps项目都面临四大相关挑战：

• 将复杂的体系结构和功能集分解成可以独立生成和部署的小块；
• 维护一个配置和构建环境，该环境提供对所部署的内容、使用的版本和依赖关系；
• 引入从遗留应用程序生命周期管理或产品生命周期管理环境派生的专门构建的开发和生产环境；
• 架起传统上孤立的开发文化（人们认为运营是繁琐和昂贵的，因为它是彻底的）和运营（开发人员认为是快速和肮脏的）之间的桥梁。

对于IT和嵌入式领域的遗留软件来说，向DevOps过渡显然更具挑战性。大多数案例研究都涉及到应用程序开发和Web环境，这些环境很容易迁移到DevOps，因为只有一个源代码，因此协调回滚是可行的。实际部署的软件不是这样的。
在接受DevOps文化时，开发人员必须采用全堆栈开发方法，在这种方法中，他们负责测试和发布环境。他们必须掌握超出代码知识范围的扩展技能，包括数据库管理和测试。此外，由于功能竖井的边界模糊，需要与其他团队成员进行更紧密的协作。
当开发人员接受DevOps时，测试是开发的关键部分，开发团队执行测试驱动的开发和CI。在这个场景中，测试人员可以与开发人员配对，两者都可以获得技术知识。质量保证团队必须确保所有测试用例的自动化和完整的代码覆盖率。
从操作的角度来看，DevOps极大地影响了文化和纪律。运营团队必须在不失去控制的情况下持续与其他职能部门保持联系。因此，IT运营和开发团队必须紧密协作，以实现由DevOps团队推动的持续过程。此外，基础设施监控和应用程序性能管理更为重要，团队成员之间的通信必须是流畅的。

DevOps案例研究

关键基础设施解决方案的全球供应商面临着过长的周期和交付升级的高返工。从开发到实地部署的整个交付过程，新产品需要18个月，升级最多需要3个月。这太长了，即使在这个领域。
Vector Consulting Services引入了一个针对这些环境约束的DevOps模型。图A显示了映射到V形生命周期抽象的八个焦点区域。关键的变化是增强的需求工程和交付模型（图中的数字1和2）。
通过对自动构建管理的每一项检查运行自动化测试、静态和运行时分析，我们的客户机可以在开发早期发现缺陷。在特性开发过程中更少的更改和由于质量问题而更少的返工直接提高了投资回报。软件发布变得更加一致，也不那么痛苦，因为测试运行得很早而且经常。由于质量更好，改动更少，产品的整体端到端周期缩短了近12个月，小规模升级缩短了几天。

DevOps正在影响整个软件和IT行业。在精益和敏捷实践的基础上，DevOps意味着软件开发和交付的端到端自动化。几乎没有人能够用菜谱式的方法来实现它，但是大多数开发人员将从更好地连接开发和运营中获益。通常，从需求到维护、服务和产品开发的相互理解可以将周期时间提高10%到30%，并将成本降低20%。主要的驱动因素是更少的需求变更、集中的测试和质量保证，以及更快速的特性驱动团队交付周期。然而，由于产品和生命周期过程各不相同，每个公司都需要自己的方法来实现DevOps，从架构到工具再到文化。

参考