持续交付-集成-部署与-DevOps-全-

持续交付、集成、部署与 DevOps（全）

原文：annas-archive.org/md5/acc4b98ffa585808b0946b038414cdec

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书讲解的是 DevOps，它是最广泛使用的软件工程文化和实践，旨在促进软件开发与运维。持续集成是 DevOps 的基石技术，它将开发人员的代码更新合并到共享的中央主干中。

所以，如果你想实现 DevOps 战略，你就走在了正确的道路上。

对我有什么好处？

地图对你的旅程至关重要，尤其是当你在另一个大陆度假时。对于学习而言，路线图能为你提供一条明确的前进路径，帮助你朝着目标迈进。因此，在你开始旅程之前，这里为你呈现了一张路线图。

本书经过精心设计和开发，旨在为你提供有关 DevOps 的所有正确信息和相关知识。我们为你创建了这个学习路径，包含四个课程：

第 1 课，DevOps 简介，专注于商业趋势、驱动因素、市场推动者的演变和 DevOps 的采用。介绍了大数据、云计算、数据科学和内存计算的关键技术概念。你还将了解 DevOps 的应用场景及其对组织的好处。

第 2 课，DevOps 框架，涵盖了源代码管理、构建、仓库、发布管理和测试自动化。还包括持续集成、交付和部署，以及基础设施自动化（基础设施即代码）、应用监控等内容。

第 3 课，DevOps – 持续集成与交付，描述了使用开源流行工具（如 Git、Maven、Gerrit、Nexus、Selenium 和 Jenkins）的 CI/CD 方法论。你还将学习与 Jenkins 兼容的不同工具和插件。

第 4 课，DevOps 持续部署，展示了流行的持续部署工具 Ansible 和 Chef，以及它们的高级功能，如 Habitat、Automate 和 Compliance，增强了安全性。你将了解 Chef 的核心组件、架构和术语，包括 Cookbooks、Knife、Playbooks 和 Towers。你还将学习如何通过使用持续监控工具（如 Splunk 和 Nagios）来提高代码质量。

我从这本书中能获得什么？

• 了解 DevOps 框架的生命周期模型、成熟度状态、进展和最佳实践

• 学习如何设置 Jenkins 并将其与 Git 集成

• 学习如何构建任务并使用 Jenkins 进行测试

• 使用 Chef 和 Ansible 等工具实现基础设施自动化（基础设施即代码）

• 了解使用 Splunk 和 Nagios 等工具的持续监控过程

• 学习 Splunk 如何提高代码质量

前提条件

本书面向希望学习 DevOps 核心策略的工程师、架构师和开发人员。在开始本书之前，您需要具备以下一些前提条件：

• 具有软件开发生命周期和系统的基本知识

• 具备 Linux 命令的工作知识

第一章。DevOps 简介

在传统的应用开发和维护方法中，涉及多个利益相关者、部门、团队和供应商参与整个软件开发生命周期（SDLC）。大多数人熟悉应用生命周期管理的阶段：由业务分析师收集业务需求，然后由开发团队（或可能已外包）开发，并由 QA 团队测试功能和适用性。性能和压力测试也由具有相关工具的适当团队在适用场景中执行。然后由组织的 IT 团队管理生产部署过程，附带检查表和批准，随后由维护团队进行监控和支持。我们注意到成熟周期的每个阶段，从功能开发到可用性和维护，都是由独立团队、部门、流程和工具管理的。这种方法通常由技术、框架、流程、人员和工具分割，影响最终产品的功能、成本、进度、质量、性能以及诸如供应商之间的接口和集成等管理开销。此外，在这种方法中，通常忽视了维护、支持成本和技能需求。然而，从应用生命周期和业务角度来看，维护和支持活动对于提前评估、评估和估算都至关重要。

在本课程中，我们将涵盖以下主题：

• DevOps 简介

• DevOps 的业务应用。

• 业务驱动因素/市场趋势

• DevOps 战略

• DevOps 的好处

许多技术创新已经发生，挑战几乎每个领域的传统 IT 管理方法。技术进步和变化非常深刻、快速且经常交织在一起，涵盖多个领域，如敏捷方法、DevOps、大数据、云等。综合和全面的方法无疑将为组织带来丰厚的回报，并实现最大的价值。许多机构已经踏上了这条通向未来的旅程，采纳了这些技术。

在 DevOps 之前的软件开发挑战不愿意改变系统；部署充满风险，在环境之间缺乏一致性（它在我的机器上能运行综合症），以及部门之间的信息孤岛——将问题抛到墙上，如团队导致了努力、技能集和内部斗争的重复。为了减轻上述问题并弥合这一差距，DevOps 作为一个流行选择出现。

DevOps（开发与运维）最近在软件开发生命周期（SDLC）中占据了核心地位。DevOps 提供了通过开源工具增强的流程框架，将应用生命周期的所有阶段集成起来，并确保它们作为一个有机整体进行运作。它有助于在开发、测试、部署和支持等各个阶段对流程进行对齐和自动化。它包括代码库、构建自动化、持续部署等最佳实践。

DevOps 在大数据系统和项目等系统中的应用，相较于传统的开发周期，是一种文化变革。本书的目的是提出适用于组织的概念和采用策略，涵盖 DevOps、大数据、云计算、数据科学、内存技术等技术领域。采纳并遵循 DevOps 实践将对任何组织带来回报，帮助其提高性能和效率。

对于每个 IT 功能领域，开源工具的接受度、流行度和通用性日益增长，全球范围内都在不断增加。实际上，许多新的工具变种已经进入市场，涵盖了每个领域。DevOps 的开源工具是机构在市场上成功采用 DevOps 的主要推动力，详细讨论将在接下来的部分中进行。

正如我们所看到的，各行各业的 DevOps 采用呈现逐年稳步增长的趋势：

企业中 DevOps 的渗透率呈现健康的趋势，如下图所示：

DevOps 应用 - 商业场景

DevOps 在多个场景中的应用及其带来的好处如下：

• 开发周期自动化：商业需求通过最小的人工干预得到满足，开发人员可以通过代码库选择开源工具来运行构建；QA 团队可以创建一个与生产环境相同的 QA 系统，并无缝快速地部署到生产环境。

• 单一真实版本 - 源代码管理：存在多个版本的代码，但很难确定适合特定目的的代码。我们缺少一个单一的真实版本。代码审查反馈通过电子邮件进行且未记录，导致混乱和返工。

• 一致的配置管理：我们在不同的系统上开发、测试和构建源代码。验证平台及依赖项的兼容版本是手动进行的，容易出错。确保所有系统使用相同的语言和工具、编译器等版本是非常具有挑战性的。我们的代码在构建系统上运行正常，但在生产系统上却无法运行，这导致业务交付上的尴尬和高额的反应成本。

• 产品准备就绪度：我们有一套开发代码、测试并按既定时间表构建的流程。这个流程中有许多手动检查和验证，不同组之间的整合使得我们的承诺和交付日期变得不可预测。我们希望定期了解产品的交付进度和质量，以便提前计划，而不是被动应对。

• 自动化手动过程：我们遵循的手动流程往往容易出错，期望通过在可行的地方采用自动化流程来提高效率。测试周期自动化、增量测试以及与构建周期的集成将加快产品质量、发布周期以及基础设施服务自动化，如创建、启动、停止、删除、终止和重启虚拟或裸机。

• 容器：代码的可移植性是主要挑战。代码在开发和 QA 环境中可以正常工作，但迁移到生产系统时会面临诸如由于依赖问题导致代码无法编译、构建失败等多个挑战。构建平台无关的代码是一大挑战，而维护多个开发和 QA 平台的版本也需要付出很大的代价。可移植的容器代码将缓解这些问题。

• 本地部署的挑战：我们有许多本地部署的系统。面临从容量规划到周转时间的多重挑战。资本支出和运营费用无法预测。云迁移似乎有多种选择和供应商，因此需要有一个高效的采纳方法来确保结果。

促使大数据领域采用 DevOps 的商业驱动因素

以下是大数据系统中 DevOps 广泛流行和采纳的几个因素：

数据爆炸

数据是新的货币形式——是的，你没看错，它和石油、黄金一样，都是宝贵的资产。在过去十年中，许多公司意识到数据作为无价资产对其增长和业绩的潜力。

让我们理解数据的价值。对于任何组织来说，数据可能有很多形式，例如，客户数据、产品数据、员工数据等。如果没有关于员工、客户或产品的正确数据，可能会带来灾难性后果。正确的数据是高效运营企业的关键，这已经成为常识和基本知识。今天几乎没有企业不依赖数据驱动决策；如今的 CEO 比以往任何时候都更依赖数据做出商业决策，比如哪个产品在市场上更成功，某个区域的需求有多大，哪个价格更具竞争力等等。

数据可以通过多种来源生成，包括内部、外部甚至社交媒体。内部数据是通过内部系统和操作生成的数据，例如在银行中，通过多种渠道如 ATM、在线支付、购买等，与银行进行新客户或客户交易。外部来源可以是从 RBI 获取金价和外汇汇率。如今，社交媒体数据广泛用于市场营销和产品客户反馈。充分利用并智能使用来自各个渠道的数据对于业务成功至关重要。

更进一步，一些公司甚至对数据进行货币化，例如 Healthcare IQ、Owens & Minor、State Street Global Corporation、Ad Juggler、comScore、Verisk Analytics、Nielsen 和 LexisNexis。这些组织购买原始数据，例如在线产品销售的网站分析或每个品牌的在线搜索记录，将数据重新处理为组织化格式，并出售给研究分析师或寻求竞争情报数据以重新定位其产品在市场上位置的组织。

让我们分析推动数据和业务增长的因素。市场和客户行为的根本变化对数据爆炸产生了重大影响。一些变革的关键驱动因素包括：

• 客户偏好：今天，客户有多种与企业互动的方式；例如，银行提供多种渠道，如取款机取款、网上银行、手机银行、卡支付、现场银行等。购买也是如此；可以在商店、在线、基于手机等多种方式，这些组织必须维护业务运营。因此，这些多种渠道有助于增加数据管理。

• 社交媒体：数据从 Facebook、LinkedIn 和 Twitter 等社交媒体涌入。一方面，它们是个人之间的社交互动网站；另一方面，公司也依赖社交媒体来推广其产品。以 TB / PB 为单位发布的数据也被许多组织用于数据挖掘。这也促成了巨大的数据爆炸。

• 法规：公司需要按照监管机构的要求以适当的格式保存数据一段规定时间。例如，为了打击洗钱，每个涉及金融业务的组织都需要清晰的客户记录和凭证，以在长达 10 至 15 年的时间内与监管机构共享。

• 数字世界：随着我们向无纸化数字世界迈进，我们不断增加更多的数字数据，如电子书和 ERP 应用程序来自动化许多任务并避免文件工作。这些创新也在很大程度上促成了数字数据的增长。

下一代将更加数据密集，物联网和数据科学处于前沿，推动业务和客户优先事项。

云计算

云平台作为事实上的服务线的接受，带来了采购和管理基础设施的诸多变化。在云端提供硬件及其他类型的商品化工作对于提高效率也很重要，因为将这些 IT 功能迁移到云端能提高服务效率，并让 IT 部门能够将注意力从操作系统的补丁更新上转移开。随着云采用，DevOps 成为最广泛实施的流行选择。随着云的渗透，添加基础设施/服务器只需轻松点击即可完成。结合可信的开源工具，这为 DevOps 的实现铺平了道路。

在短短的时间内，可以使用开源工具根据需求添加构建、QA 和预生产机器，作为精确的副本和配置。

大数据

大数据是用来表示数据多个维度的术语，如大规模、速度和多样性，并为业务提供价值。数据来自多个来源，如结构化、半结构化和非结构化数据。数据的速度可能是批处理模式、来自机器传感器的实时数据或在线服务器日志，以及实时流数据。数据量可能是数 TB 或 PB，通常存储在基于 Hadoop 的存储和其他开源平台上。大数据分析扩展到构建社交媒体分析，如基于来自 Twitter、LinkedIn、Facebook 等社交媒体数据的市场情绪分析；这些数据对于了解客户情绪、支持营销和客户服务活动非常有用。

数据科学与机器学习

数据科学作为一个领域具有多维度和多种应用。我们熟悉科学；我们理解特征、行为模式和有意义的洞察，这些洞察帮助我们制定可复用的、经过验证的公式。以类似的方式，数据也可以通过工程学和统计方法来研究，以了解其行为模式和有意义的洞察。因此，数据可以被视为数据+科学，或者称为数据科学。机器学习是数据提取、提取、转换、加载（ETL）或提取、加载、转换（ELT）准备过程的结合，并使用预测算法从数据中得出有意义的模式，从而生成商业价值。这些项目有一个与项目或产品开发一致的开发生命周期。与 DevOps 方法论的对接将为程序的发展带来有价值的益处。

内存计算

传统的软件架构以前是以磁盘作为主要的数据存储；然后数据从磁盘移动到主内存和 CPU，以执行业务逻辑的聚合操作。这导致了大量数据在磁盘和内存之间来回移动的 IO 开销。

内存技术基于硬件和软件创新，将完整的业务应用数据处理在主内存中，从而使计算速度非常快。为了实现内存计算，许多底层硬件和软件的进展做出了贡献。

软件进展包括以下内容：

• 数据分区

• 无汇总表

• 插入唯一的增量

• 数据压缩

• 行加列存储

硬件进展包括以下内容：

• 多核架构允许大规模并行扩展

• 多重压缩

• 主内存具有可扩展的容量

• 快速预取无限大小

规划 DevOps 策略

本书中讨论的优秀 DevOps 策略有助于用户深入理解其主题及其在多个技术和接口中的应用，为组织提供聚焦，创造一个关于当前问题的共同（公正）视角，发展未来的状态，揭示增长机会，并带来更好的业务成果。

一个全面的 DevOps 策略，最基本的层面上，必须回答以下问题：

• 我们的业务目标和目标是什么？

• 我们如何规划路线图？我们从哪里开始？

• 我们应该如何引导我们的努力？

• 我们试图达成什么目标？

• 这个计划的时间表是什么？

• 这对业务的影响是什么？

• 我们的利益相关者如何看待这些价值？

• 这样做的好处和成本是什么？

一个好的 DevOps 策略能为组织带来多重好处，集中精力解决高影响力问题，产生清晰的未来发展方向，识别增长机会，并为更好的业务成果铺平道路。

一个 DevOps 平台策略将是一个独特且全面的程序，涵盖软件生命周期的各个方面，整合多种技术、平台和工具，并带来许多需要技巧、精确度和经验应对的挑战。

一个组织可以考虑引入 DevOps 来满足特定目的，例如以下内容：

• 自动化基础设施和工作流配置管理

• 自动化代码仓库、构建、测试和工作流

• 持续集成和部署

• 虚拟化、容器化和负载均衡

• 大数据和社交媒体项目

• 机器学习项目

有各种各样的开源工具可供选择，适用于 DevOps 特定领域的采用，例如以下内容：

• Docker：Docker 容器将应用程序及其依赖项打包在一个盒子中。它作为一个独立的进程在主机操作系统上运行，与其他容器共享内核。它享有像虚拟机一样的资源隔离和分配优势，但更加便携和高效。

• Kubernetes：Kubernetes 是一个开源的 Docker 容器编排系统。它将容器分组为逻辑单元，便于管理和发现，处理节点上的调度，并主动管理工作负载，以确保它们的状态与用户声明的意图一致。

• Jenkins：Jenkins 是一款基于 Web 的工具，通过应用或如 Tomcat 等 Web 服务器使用，用于持续构建、部署和测试，并与 Ant/Maven 等构建工具和 Git 等源代码仓库集成。它还拥有主节点和从节点功能。

• Ansible：Ansible 使用无代理的 安全外壳（SSH）模式、Playbooks、Towers 和 Yum 脚本自动化软件配置、管理和应用部署。

• Chef 和 Puppet：Chef 和 Puppet 是基于代理的拉取机制，用于工作单元的部署自动化。

• GitHub：Git 是一个流行的开源版本控制系统。它是一个基于 Web 托管的 Git 仓库服务。GitHub 允许你托管远程 Git 仓库，并且拥有丰富的社区服务，使其成为开源项目的理想平台。

有多种现成的综合框架可供使用，例如 RedHat Openshift、Microsoft Azure 和 AWS 容器服务，具备预集成和配置的工具来实施。

这里列出了一些流行的开源工具：

• 源代码管理：Git、GitHub、Subversion 和 Bitbucket

• 构建管理：Maven、Ant、Make 和 MSBuild

• 测试工具：JUnit、Selenium、Cucumber 和 QUnit

• 仓库管理：Nexus、Artifactory 和 Docker hub

• 持续集成：Jenkins、Bamboo、TeamCity 和 Visual Studio

• 配置提供：Chef、Puppet、Ansible 和 Salt

• 发布管理：Visual Studio、Serena Release 和 StackStorm

• 云：AWS、Azure、OpenShift 和 Rackspace

• 部署管理：Rapid Deploy、Code Deploy 和 Elastic box

• 协作：Jira、Team Foundation 和 Slack

• BI/监控：Kibana、Elasticsearch 和 Nagios

• 日志记录：Splunk、Logentries 和 Logstash

• 容器：Linux、Docker、Kubernetes、Swam、AWS 和 Azure

DevOps 的好处

不遵循 DevOps 实践对组织将会是挑战，原因如下：

• 每个开发、QA 和生产系统的部署工作量大

• 复杂的手动安装程序繁琐且昂贵

• 缺乏全面的操作手册使得系统难以操作

• 不足的追踪或日志文件细节使得故障排除不完整

• 未评估其他应用的性能影响时，应用特定问题的影响无法预测

• 如业务应用要求，遵守 SLA 将面临挑战

• 仅监控服务器、文件系统、数据库和应用程序会存在监控空白

• 单独进行业务应用冗余以实现故障转移成本高昂

对于大数据系统，DevOps 的采用和成熟将为组织带来以下好处：

• DevOps 流程可以作为独立流程或其他流程的组合来实施。

• 自动化框架将提高业务效率。

• DevOps 框架将有助于将弹性构建到应用程序的代码中。

• DevOps 流程包括了操作需求的服务级别协议（SLA）。

• 操作手册（runbook）在开发阶段准备，以帮助操作。

• 在成熟的 DevOps 流程中，基于操作手册的开发被集成。

• 在 DevOps 流程中，特定于应用程序的监控是开发过程的一部分。

• DevOps 规划考虑了高可用性和灾难恢复技术

• 弹性被内置到与技术特性一致的应用程序代码中。

• DevOps 完全脚本化的安装实现了完全自动化部署。

• DevOps 运维团队和开发人员熟悉使用日志框架。

• 操作性、维护性和监控等非功能需求与系统开发规范一起得到了充分关注。

• 持续集成和持续交付消除了人为错误，减少了升级的计划停机时间，并促进了生产力的提高。

摘要

在本课中，我们学习了 DevOps 的概念、关键市场趋势，以及推动 DevOps 在大数据、云计算、数据科学等系统中应用的商业驱动因素。展示了大量应用 DevOps 的商业场景及实例。随着接下来的课程中对流行开源工具的详细讲解，DevOps 的采用将大幅提升组织的生产力。

在下一课中，我们将讨论 DevOps 框架的概念和最佳实践。

评估

1. 以下哪些是内存计算的软件进展？

   1. 多核架构允许大规模并行扩展

   2. 主内存具有可扩展的容量

   3. 数据分区

   4. 快速预取无限大小

2. 以下哪些是内存计算的硬件进展？

   1. 多重压缩

   2. 无汇总表

   3. 数据压缩

   4. 行加列存储

3. ______ 由将应用程序及其依赖项打包在一个盒子里组成。

   1. Jenkins

   2. Docker

   3. Ansible

   4. Kubernetes

4. 以下哪些是源代码管理工具？

   1. Splunk

   2. Elastic box

   3. Rackspace

   4. Subversion

5. 以下哪些是发布管理工具？

   1. StackStorm

   2. Nagios

   3. Logentries

   4. Chef

第二章. DevOps 框架

在本节中，我们将学习不同的 DevOps 流程、框架和最佳实践。我们将介绍 DevOps 过程成熟度框架和进展模型，并为每个阶段提供检查表模板。我们还将了解敏捷术语和方法论，并了解组织采用它后所获得的好处。本节将涵盖以下主题：

• DevOps 过程

• DevOps 进展框架

• DevOps 成熟度模型

• DevOps 最佳实践

• 敏捷与 DevOps

DevOps 过程

行业内规定并被组织采纳的 DevOps 标准流程列在此处；我们将详细讨论它们：

• 源代码管理

• 源代码审查

• 配置管理

• 构建管理

• 仓库管理

• 发布管理

• 测试自动化

• 持续集成

• 持续交付

• 持续部署

• 基础设施即代码

• 应用性能监控

• 日常自动化/持续改进

• DevOps 框架——在 DevOps 框架下，我们将研究生命周期模型、成熟度状态、进展和最佳实践框架，以及敏捷方法论：

  • DevOps 项目生命周期

  • 成熟度状态

  • 进展框架

  • DevOps 实践框架

  • 敏捷方法论

DevOps 最佳实践

采用 DevOps 最佳实践将有助于协调人员并朝着组织目标进展。DevOps 提供了在软件开发的每个阶段的多个流程框架。在组织中全面实施 DevOps 需要文化转变，整合部门、人员和软件生命周期的过程。这使得组织能够在遵从性和流程遵守方面在成熟度路线图上不断提高：

DevOps 过程

现在我们将详细讨论行业中规定的 DevOps 标准流程，这些流程已被许多组织采用。

源代码管理

源代码管理（SCM）系统已经使用了几十年，提供了许多功能和好处。然而，将它们与 DevOps 流程集成，能够提供强大的集成和自动化。源代码管理系统使多个开发人员能够同时在多个开发中心进行代码开发，这些中心分布在不同的地理区域。SCM 帮助管理代码库和文件级的版本控制，确保开发人员不会覆盖彼此的代码，并能在各自的分支上并行工作。

开发人员将其代码更改合并到主分支或子分支，合并内容可以被跟踪、审计、查询错误修复，并在需要时回滚。分支是 SCM 的一个重要功能，软件的多个分支被维护用于不同的主要和次要版本，跟踪各种版本中的特性和错误修复。SCM 能够在开发、测试和生产环境中管理过程合规性，促进从开发到支持的整个软件生命周期管理。

DevOps 流程框架强调采用 SCM 来为组织带来以下好处：

• 软件开发团队成员之间的服务协调

• 定义任何版本的单一真实来源，无论是次要版本还是主要版本

• 在实施之前审查更改

• 跟踪共同创作、协作和个人贡献

• 审计代码更改和回滚功能

• 增量备份与恢复

市场上流行的 SCM 工具如下：

• IBM ClearCase

• Perforce

• PVCS

• Team Foundation Server

• Visual Studio Team Services

• Visual SourceSafe

开源 SCM 工具如下——它们的流行也归功于 DevOps 的广泛采用：

• Subversion (SVN)

• 并发版本系统 (CVS)

• Git

• SCCS

• 版本控制系统

• Bitbucket

代码审查

代码审查是提高软件实例质量的重要过程，在将其集成到主流之前，它们有助于识别并去除常见的漏洞，例如内存泄漏、格式错误和缓冲区溢出。代码审查或检查可以是正式的也可以是非正式的。在正式的代码审查中，过程通过多种方法进行，例如正式会议和逐行检查代码的互动。非正式代码审查可以通过肩膀审查、电子邮件、对写代码的合作编程，或工具辅助的代码审查进行——这些也被称为代码走查。

代码审查过程框架为组织带来的好处如下：

• 软件开发团队成员之间的协作

• 在集成之前识别并消除代码缺陷

• 提高代码质量

• 快速的开发周期周转

用于代码审查自动化的专有工具：

• Crucible

• Collaborator

• Codacy

• Upsource

• 理解

用于代码审查自动化的开源工具：

• Review board

• Phabricator

• Gerrit

• GitLab

配置管理

配置管理（CM）是一个广泛的主题，涉及在企业级别上管理配置项，根据基础设施库（ITIL）的定义；甚至配置管理数据库（CMDB）也是 CM 策略的一部分。配置管理包括软件和硬件的配置项的识别、验证和维护，如补丁和版本。简单来说，就是管理系统的配置，并确保其适应预期的目的。配置管理工具将根据要求验证系统配置的适宜性以及系统间的互操作性。一个常见的例子是确保在开发系统上开发的代码在 QA（测试）系统和生产系统上有效运行。系统间任何配置参数的丢失都会对应用性能产生灾难性影响。

根据 DevOps，组织引入配置管理流程和工具的好处可以总结如下：

• 通过配置变更提供影响分析，帮助组织

• 允许在不同系统（如开发、QA、生产）上进行自动化配置

• 便于系统的审计、账户管理和验证

• 通过确保一致性减少冗余工作

• 有效管理同时进行的更新

• 避免“单一真实版本”相关的配置问题

• 简化开发和运维团队成员之间的协调

• 有助于跟踪缺陷并及时解决

• 有助于预测性和预防性维护

一些流行的基础设施配置管理工具如下：

• BMC 软件的 Atrium

• 惠普企业的通用配置管理数据库

一些流行的软件配置管理工具如下：

• Chef

• Puppet

• Ansible

• Salt

• Juju

构建管理

构建管理是准备构建环境的过程，用于将软件应用程序的所有组件汇集成一个完整、可用的产品，适合其预期目的。源代码、编译器、与硬件和软件组件的依赖关系等，都会被编译成一个整体单位。构建可以是手动的、按需的或自动化的。按需自动化构建通过脚本重新启动构建，在少数情况下使用。定时自动化构建是指在持续集成服务器上运行的夜间构建。触发式自动化构建是在 Git 仓库提交后立即启动的。

根据 DevOps，构建管理流程和工具对组织的好处可以总结如下：

• 确保软件可用的核心功能

• 确保软件在客户端环境中的可重用性和可靠性

• 提高软件的效率和质量

• 这也是一项监管要求

一些使用中的构建工具如下：

• Ant

• Buildr

• Maven

• Gradle

• Grunt

• MSbuild

• Visual Build

• Make (CMake/QMake)

构件仓库管理

构建构件仓库管理器是一个专门的服务器，用于托管成功构建的多个二进制组件（可执行文件）仓库。通过集中管理多种二进制类型，它简化了访问及其依赖关系的复杂性。

其好处如下：

• 管理构件生命周期

• 确保构建是可重复且可再现的

• 有序访问构建构件

• 便于跨团队和供应商共享构建

• 基于构件的保留策略以满足审计合规性

• 高可用性构件及访问控制

一些使用中的仓库工具如下：

• Sonatype Nexus

• JFrog Artifactory

• Apache Archiva

• NuGet

• Docker hub

• Pulp

• Npm

发布管理

发布管理是软件生命周期的一部分，旨在促进发布从开发、测试、部署到支持/维护的过程。它与 SDLC 中的其他 DevOps 过程领域相互关联。

发布管理已成为开发过程的一个不可或缺的部分。然而，将其纳入 DevOps 框架中，使得自动化形成了完整的循环。

发布管理是一个迭代周期，始于请求添加新特性或更改现有功能。一旦更改获批，新的版本就会设计、构建、测试、审查，经过接受后部署到生产。在支持阶段，可能会进行增强或性能改进，从而启动新的开发周期。

采用发布管理的好处如下：

• 产品生命周期整体管理，跟踪并整合每个阶段

• 协调所有阶段活动——开发、版本控制、构建、质量保证、系统配置、生产部署和支持

• 跟踪各环境中最近部署的状态

• 审计与每个发布相关的所有工作项的活动历史

• 发布管理的自动化依赖于自动化其所有阶段

• 团队可以编写发布定义，并以可重复、可靠的方式自动化部署，同时跟踪从开发到生产的进行中的发布。

• 对授权访问和更改批准进行细粒度的访问控制

一些发布管理工具包括：

• Electric Cloud

• Octopus Deploy

• Continuum

• Automic

• Quikbuild

• UrbanCode Release

• CA 服务虚拟化（LISA）

• BMC 发布流程管理

• Plutora 发布

• CA 发布自动化

• Serena 发布

• MS Visual Studio

• StackStorm

• Rally

测试自动化

手动测试每个可能的场景既繁琐又耗费人力、时间和金钱。自动化测试，或者称为自动化测试，是指在没有人工干预的情况下执行测试用例。虽然并非所有测试用例都适合自动执行，但大多数可以安排定时执行。自动化是通过使用自动化工具或调度自动化脚本来实现的。测试数据作为输入并捕获结果进行分析。自动化测试的目标是通过减少需要手动执行的测试用例数量来补充手动测试，而不是完全取代手动测试。

自动化测试适用于那些重复、单调、繁琐且耗时的测试用例，这些用例有明确的输入和边界条件。它不适用于经常变化的、临时的或首次执行的测试用例。软件自动化测试可以基于几种框架的数据类型；如关键字、模块化和混合型框架。

测试大数据系统涉及多种技术、集成、框架和测试模块，如功能测试、安全测试、可用性测试、性能测试、集成测试等。

采用自动化测试的好处如下：

• 提高软件质量和响应速度

• 用自动化替代人工工作，从而加快工作流程

• 提高整个测试生命周期的效率

• 增量和集成测试用于持续集成和交付

一些自动化测试工具如下：

• Visual Studio Test Professional

• QTP (UFT)

• SoapUI

• TestDrive

• FitNesse

• Telerik Test Studio

• Selenium

• TestComplete

• Watir

• Robotium

持续集成

持续集成是 DevOps 最佳实践之一，开发人员将其代码持续集成到一个共同的共享仓库中，按小的逻辑单元进行，并定期提交（例如，每天一次）。这种流程的优势在于代码的质量和适应目标的透明性。否则，在固定时间后进行大量代码集成可能会暴露出许多缺陷或集成挑战，解决这些问题可能会非常昂贵。

为了实现持续集成，必须先实施以下几个前提条件：

• 使用版本仓库来管理源代码

• 定期提交代码计划

• 自动化代码变更的测试

• 自动化构建

• 在预生产环境中部署构建

持续集成的好处如下：

• 我们早期并且频繁地提交代码，从而获得最新的代码

• 由于早期检查并暴露了构建问题，构建周期更快

• 构建过程的透明度意味着更好的责任归属和更少的缺陷

• 自动化部署过程能更快速地完成工作

一些可用的持续集成工具如下：

• Jenkins

• TeamCity

• Travis

• Go CD

• Buddy

• Bitbucket

• Chef

• Microsoft Teamcenter

• CruiseControl

• Bamboo

• GitLab CI

• CircleCI

• Codeship

下图表示持续集成、持续交付和持续部署的角色：

持续交付

持续交付是软件开发周期中持续集成的下一步；它使得软件的快速、可靠开发以及最少人工干预或管理开销的产品交付成为可能。在持续集成中，正如我们所看到的，代码开发时包含审查，之后是自动化构建和测试。而在持续交付中，产品以小的频繁单位被移动到预生产（暂存）环境中，进行彻底的用户验收测试。重点是理解与软件相关的功能和性能问题。这使得与业务逻辑相关的问题可以在开发周期的早期发现，确保这些问题在继续进行到部署生产环境或增加新功能等其他阶段之前得到解决。持续交付为开发者提供了更大的可靠性和可预测性，使得软件随时可以发布，最终的生产部署是基于业务决策的手动步骤。

持续交付过程的好处如下：

• 开发的代码被持续交付

• 代码不断并定期进行审查

• 高质量的软件能够快速、可靠地、反复部署

• 最大化自动化并最小化人工开销

执行持续集成的工具也能够执行持续交付的工作。

持续部署

持续部署是代码更改的完全成熟和完整的过程周期，经过软件生命周期的每个阶段，最终部署到生产环境中。

持续部署要求整个过程自动化——也称为自动化应用发布——涵盖所有阶段，如应用打包、确保依赖项集成、部署测试以及为合规性生成充分的文档。

持续部署和自动化应用发布的好处如下：

• 频繁的产品发布尽可能快地交付软件

• 与代码更改一起自动化和加速产品发布

• 从技术和质量角度来看，代码更改符合生产要求

• 产品的最新版本以可交付格式准备好

• 部署建模减少了错误，从而提升了产品质量

• 整合访问所有工具、流程和资源数据，有助于更快地排除故障并缩短上市时间

• 开发、质量保证和运维团队之间的有效协作提高了产出，并提升了客户满意度

• 由于对所有阶段活动的集中视图，有助于降低审计工作量

基础设施即代码

基础设施即代码（IaC）是通过定义配置文件来执行基础设施服务的一种方式。在 DevOps 范畴内，IaC 是通过代码自动化日常任务，通常是作为配置定义文件，例如 shell 脚本、Ansible playbook、Chef 配方或 Puppet 清单。它通常是一个服务器和客户端的设置，使用推送或拉取机制，或通过 安全外壳（SSH）无代理方式进行。许多系统上的常规任务，如创建、启动、停止、删除、终止和重启虚拟机或裸金属机器，都是通过软件执行的。在传统的本地系统中，许多系统管理任务都是手动的，且依赖于个人。然而，随着大数据和云计算的爆炸式增长，所有常规的系统活动和任务都像任何软件代码一样被管理。它们存储在代码仓库中，并且最新的构建更新会经过部署测试。

IaC 的优势如下：

• 使用定义文件和代码来更新系统配置非常快捷。

• 所有代码和更改的版本更加不易出错，并且具有可复现的结果。

• 通过 IaC 和测试系统对部署进行彻底测试。

• 较小的常规更改容易管理，而较大的基础设施更新可能包含难以检测的错误。

• 使用定义文件可以轻松进行审计跟踪和合规性检查。

• 多台服务器同时更新。

• 系统可用性高，停机时间少。

• 一些用于 IaC 的工具如下：

• Ansible tower

• CFEngine

• Chef

• Puppet

• SaltStack

日常自动化

每个组织都致力于自动化日常重复性任务；事实上，大多数公司和软件产品的生存依赖于它们自动化的程度。ERP 系统、数据可视化、领域应用、数据分析等几乎所有领域都是潜在的自动化区域。一些需要自动化的部分包括基础设施（部署、补丁、可扩展性）、应用程序（开发、集成、构建、交付和部署）、负载均衡器、反馈以及缺陷/错误管理。

关键应用性能监控/指标

性能指标是每个工具、产品和服务的一部分。因此，组织始终警惕其应用程序、产品和服务的性能指标监控。要为任何产品实现高质量输出，首先必须在流程和指标上达到较高的标准。有许多参数可用来衡量性能指标，例如，应用程序或硬件系统的可用性或正常运行时间与停机时间和响应性，工单分类、确认、解决时间等。

DevOps 关注的是衡量指标和反馈，并结合持续改进过程。

有多种工具可用于不同需求的应用监控；我们将在本课程的后续部分讨论在 DevOps 框架下最合适和适用的工具。

DevOps 框架

在 DevOps 框架下，我们将研究生命周期模型、成熟度状态、进展和最佳实践框架，以及敏捷方法论。

实现 DevOps 成熟度是一个逐步推进的过程，朝着良好结构化和计划化的方向发展，具体阶段如下：

DevOps 成熟度生命周期

DevOps 项目阶段与软件开发生命周期一致，如此处所述。我们将详细讨论每个阶段：

• 发现与需求阶段：DevOps 发现阶段是一个高度互动的项目阶段，旨在收集关于当前过程、框架和工具的输入和反馈，主要来自关键利益相关者。模板和检查清单用于捕捉这些输入。此阶段的时间表取决于关键利益相关者的可用性、相关文档的存在以及需要探索的过程的复杂性。发现阶段的交付物如下：

  • 详细说明当前过程、工具、框架状态的模板

  • 关键利益相关者对已收集细节的签署

  • 现有的最佳实践和 DevOps 方法

  • 现有挑战、约束条件（如适用）

  • 可重用的工具、过程、工件

• 设计图纸阶段：设计阶段也是架构阶段；其目的是绘制出达成目标状态的蓝图。这是一个迭代过程，涉及权衡工具和过程的替代方案，并通过关键利益相关者达成一致。时间表和成本将基准化，并根据项目进展中的新学习定期回顾和修订。此阶段的时间表取决于过程、工具和预算对关键利益相关者的可接受程度。设计阶段的交付物如下：

  • 达成一致的目标状态

  • 要采纳的 DevOps 过程基准化

  • 最具可行性的工具基准化实施

  • 基准化的时间表和成本

• 开发阶段：从蓝图阶段基准化的工件将成为开发阶段的输入，包括商定的过程变更、要实施的工具、要采用的框架等。一份详细的项目计划，涵盖交付物、进度安排、依赖关系、约束条件、资源平衡等，将非常有用。敏捷 Scrum 方法论将是实现 DevOps 的框架，具体内容将在后续讨论。开发阶段的时间表将依据最初基准化的项目计划，并随着完成的里程碑进展定期修订。开发阶段的交付物如下：

  • 初始项目计划已基准化并签署

  • 在项目完成前融入定期反馈

  • 为每个阶段分配资源

  • 包括新技能、新方法、新过程和新工具

  • 针对项目风险、限制等的解决方案

  • 按项目计划约定的交付物

• 部署阶段：DevOps 部署阶段遵循上述 DevOps 流程框架中概述的最佳实践。其取决于部署是流程、应用工具，还是基础设施。时间表将根据在开发阶段积累的经验进行评估。部署阶段的交付物如下：

  • 部署指南——生产切换计划

  • 部署检查表

  • 来自关键利益相关者的签字确认

  • 回滚计划

  • 容量规划

• 监控阶段：监控每个阶段在开发、构建、集成和部署过程中的关键绩效因素。随后跟踪缺陷、漏洞修复、用户票务和持续改进计划。监控阶段的时间表根据组织需求和绩效基准进行设定。监控阶段的交付物如下：

  • 操作手册

  • 反馈表格和检查表

  • 用户指南，支持手册

  • 流程手册

  • 绩效基准

DevOps 成熟度图

DevOps 的采纳是一个为组织增值的过程。这不是一种可以一蹴而就的成就，而是通过一段时间的逐步成熟并表现出结果的过程。像任何能力成熟度模型（CMMI）或流程成熟度模型一样，关键的成功因素必须为程序的绩效目标进行定义。主要评估参数的初始成熟度状态需由关键利益相关者达成一致。然后，项目章程中将定义该参数变量的目标成熟度等级，以及经过利益相关者批准的详细程序、里程碑、预算和约束条件。

DevOps 流程成熟度框架

DevOps 进展框架/准备模型

如前所述，DevOps 的采用是一个使组织逐步达到更高成熟度状态的过程。在下表中，列出了 DevOps 在广泛范围内的不同实践领域和成熟度等级。DevOps 的成熟度等级在不同团队之间可能有所不同，具体取决于他们的标准，类似地，即使是同一组织的一个共同部门或分部，其在相同流程中的实践也可能远比其他部门更为先进。全公司范围内提升并实现最佳 DevOps 流程工作流应是所有团队和部门的最终目标。

DevOps 成熟度检查表

如前所述的流程成熟度框架，采用检查表和讨论进行评估。针对每个关键关注领域，详细的调查结果将表明其成熟度水平。

研究结果提供了成熟度水平及其影响的一般估算：

DevOps 过程项目的敏捷框架

DevOps 项目通常基于敏捷框架，以实现开发和实施过程的高效快速周转。

基于敏捷软件开发的项目已在行业中得到广泛接受和采用。传统的瀑布模型已经过时，无法跟上敏捷方法所带来的优势。

敏捷方法论的成功归功于其核心目标，如下所示：

• 个人和互动被重视，优于流程和工具

• 工作软件被看重，优于详尽的文档

• 客户合作被看重，优于合同谈判

• 相较于遵循项目计划，变更采纳的敏捷性更为重要

敏捷开发方式

Scrum 是一种敏捷开发方法，专注于功能开发，团队成员包括如下角色：

• Scrum Master 负责团队设置、主持冲刺会议并移除开发中的障碍

• 产品负责人创建并优先排序产品待办事项列表，并负责每个冲刺迭代周期中功能的交付

• Scrum 团队负责管理和组织工作，以完成冲刺周期中的任务。

• 产品待办事项列表是要开发的功能特性和需求的清单

敏捷开发方法是一种增量和迭代的方式，用于开发用户故事、软件功能或功能模块。客户可以早期看到产品特性，并在需要时进行必要的更改。开发周期被分为两到四周的冲刺周期，以完成工作单元。其理念是，通过开发人员和测试人员组成的团队，可以快速开发和管理较小的周期。结构和文档并不重要，但代码的可工作特性被视为最有价值的。开发过程通过连续的冲刺周期进行迭代实现。发现的漏洞会在最早的冲刺中进行修复，并通过成功的测试。回归测试会在新功能或逻辑开发时执行。用户验收测试会在冲刺周期结束后进行，以便标记产品进行发布。

采纳敏捷软件开发最佳实践的好处如下：

• 工作软件能够让客户满意，因为他可以查看功能

• 客户可以在开发的任何阶段提出变更请求

• 软件的快速持续交付，通常以周为单位

• 项目围绕着充满动力的个体构建，且这些个体应当受到信任

• 冲刺团队在交付上高度熟练且高效

• 由于开发人员和测试人员共同开发，漏洞会在冲刺周期内得到解决

• 沟通模式有效，因此交付的产品质量更高

• 持续关注技术卓越带来良好的设计

• 自组织团队专注于最佳架构、需求和设计

• 团队精简且高效，因此生产力最大化

总结

在本课程中，我们了解了 DevOps 流程、框架、最佳实践、DevOps 流程成熟度框架和进展模型及其检查清单模板的应用。我们还学习了敏捷术语和方法论。

在下一个课程中，我们将学习如何实现 DevOps 核心流程。

评估

1. 以下哪项 DevOps 流程提供了强大的集成和自动化？

   1. 源代码管理

   2. 代码审查

   3. 配置管理

   4. 构建管理

2. 以下哪些是用于代码审查自动化的专有工具？

   1. Git

   2. SCCS

   3. Crucible

   4. SVN

3. 以下哪些是工件库管理的好处？

   1. 确保软件在客户环境中的可重用性和可靠性

   2. 确保构建是可重复和可再现的

   3. 跟踪各个环境中最近部署的状态

   4. 审计与每次发布相关联的所有工作项活动的历史记录

4. 以下哪项是 DevOps 成熟生命周期中发现阶段的交付成果？

   1. 要实施的最可行工具的基准

   2. 基准同意的时间线和成本

   3. 可重用的工具、流程和工件

   4. 要采纳的 DevOps 流程基准

5. _________ 负责团队设置、召开冲刺会议并消除开发障碍。

   1. Scrum Master

   2. 产品负责人

   3. 客户

   4. Scrum 团队

第三章：DevOps – 持续集成与交付

在本课程中，我们将学习实施 DevOps 核心过程，如源代码仓库、代码审查、工件仓库、持续测试、持续开发和持续集成。我们将重点介绍一些流行工具，如 Git、Jenkins、Maven、Gerrit、Nexus、Selenium 等。

• 持续集成（CI）

• 持续交付（CD）

• Jenkins 工具设置

• 配置管理—Jenkins

• 源代码管理—Git

• 构建管理—Maven

• 源代码审查—Gerrit

• 仓库管理—Nexus

• 测试自动化—Selenium

• 持续部署—流水线

• Jenkins 客户端设置

• Jenkins 安全性

• Jenkins 指标

持续集成与持续交付是确保高质量和及时交付软件的重要且有价值的流程。持续集成是一个集成软件开发过程，其中多个开发者遵循敏捷方法，并将其调整为以下最佳实践：

• 确保所有开发代码都受到版本控制系统的管理

• 纳入充分的代码审查流程

• 代码更改被快速集成、测试和构建

• 构建过程集成以运行单元测试并自动化

• 立即处理构建错误，迅速恢复

• 构建结果和仓库管理的跟踪与指标

• 透明且用户友好的构建过程

持续交付是持续集成过程的延伸。

• 软件的最新版本随时可用

• 从技术和质量角度通过测试周期的变更已准备好部署

• 自动化运输和部署过程

持续集成过程如下图所示：

持续集成过程如下所示：

• 开发者的环境：开发者在本地工作区中创建代码更改，配有集成开发环境（IDE）运行时以及安装在 PC 上或基于云的（Web IDE）构建工具。开发者进行单元测试、数据验证、代码性能检查等操作。开发者所做的代码更改会推送到源代码管理系统。

• 典型的持续集成与部署周期包括设置 CI/CD 基础设施和流程，具体如下：

  • 源代码版本与仓库管理系统

  • 用于启动编排流水线的进程调度器

  • 用于管理代码构建和定期测试的构建过程

  • 执行构建的构建节点

  • 在已识别的测试节点上进行自动化测试过程

  • 构建结果工件仓库

  • 用于存储构建结果的工件仓库

  • 测试节点上的场景和验收测试

  • 使用部署工具将应用程序安装到运行时系统

  • 部署到运行时系统上的应用程序的验收测试

质量经理将批准接受测试，以便同意部署测试系统。

交付经理将批准应用程序的生产环境部署。

CI/CD 的最佳实践

让我们来看一下 CI/CD 的最佳实践：

• 使用版本控制：在协作开发环境中，多个开发者同时进行开发时，会遇到许多挑战：

  • 源代码管理系统在将代码置于版本控制系统下后，定义了代码的单一可信来源。通过有效地采用主干开发和修复分支（如 bug 修复）的合并过程，源代码将能够可复现。Git 是一个流行的源代码管理系统，GitHub 是其云变种，提供软件即服务（SaaS）模式：

• 自动化构建：标准化的自动化构建程序将稳定构建过程，以产生可靠的结果。成熟的构建过程必须包含构建描述和执行构建所需的所有依赖项，以及标准化构建工具的安装。Jenkins 是最具通用性的构建工具，它提供方便的用户界面，并且有插件集成了大多数流行的持续集成工具。

• 构建中的测试：需要执行一些测试，以验证代码的有效性和适用性，不仅仅是语法正确性，具体包括：

  • 单元测试直接作用于构建结果

  • 在开发者提交代码之前进行静态代码检查。可以使用 Git 预提交触发器或 CI 系统来设置一个门控或非门控检查。

  • 针对新构建应用程序的场景测试，以确保其能够正确安装并启动

  • 代码的功能性能

单元测试框架在源代码技术中非常流行，例如 Java 的 JUnit。Selenium 框架提供图形用户界面和浏览器行为的自动化测试。

将这些测试尽早实施到开发者的工作站作为构建的一部分，可以节省在开发过程中发现 bug 后处理的时间和精力。

• 早期且频繁地提交代码：在一个有多个项目的分布式开发环境中，每个团队或开发者都打算将他们的代码与主干进行集成。同时，特性分支的更改也需要集成到主干中。快速且早期地集成代码是一种最佳实践。新更改与主干合并的时间延迟会增加产品不稳定的风险，增加时间成本，并且随着主干从基线演变而带来更多复杂性。因此，每个与特性分支协作的开发者每天至少应该提交一次代码。对于主分支上不活跃的项目，必须在实施前评估不断重新基准化的高成本。

• 每次更改都要构建：开发者的更改需要被纳入主干中，但这些更改可能会破坏主干的稳定性，影响依赖主干的开发者的工作。

持续集成通过对每次提交的代码变更进行持续构建来解决这个问题。任何构建失败都需要立即处理，因为构建失败会阻碍主线的演进，而且根据提交频率和问题的严重性，这会变得非常昂贵。通过强制实施分支级构建，可以将这些问题降到最低。

在 Gerrit 中发起审核或在 GitHub 中发起拉取请求是有效的机制，可以提出变更并通过在变更推送到主线之前识别问题来检查变更的质量，避免返工。

• 快速处理构建错误：为每个变更在分支级别构建的最佳实践会将修复代码构建问题的责任放在各个开发者身上，而不是将问题传播到主分支。这形成了一个持续的“变更-提交-构建-修复”循环，在各自的分支级别进行。

• 快速构建：自动化过程的快速构建、结果和测试应成为开发者工作流程的关键输入；短时间的等待将有利于持续集成过程的整体周期效率。

这是一项平衡工作，在将新变更安全地集成到主分支的同时，还要进行构建、验证和场景测试。有时，可能会存在目标冲突，因此需要通过权衡找到不同接受标准之间的妥协点，考虑到主线质量最为重要。标准包括语法正确性、单元测试和对变更进行快速运行的场景测试。

• 生产前运行：生产流水线各个阶段的多个设置和环境会导致错误。这适用于开发者环境、分支级别构建配置和中央主构建环境。因此，进行场景测试的机器应与主要生产系统相似，并具有可比的配置。

手动保持一致的配置是一项艰巨的任务；这正是 DevOps 所带来的价值和核心价值主张，且将基础设施设置和配置视为编写代码的过程。所有机器的软件和配置都定义为源文件，这使得你能够重建相同的系统；我们将在第 4 课中更详细地讲解，DevOps 持续部署。

• 构建过程是透明的：构建状态和最后一次更改的记录必须对所有人可用，以便确定构建的质量。Gerrit 是一个变更审查工具，可以有效地记录和跟踪代码变更、构建状态和相关评论。Jenkins 流程插件为构建团队和开发人员提供了完整的端到端概览，涵盖源代码管理工具、构建调度器、测试环境、工件仓库等。

• 自动化部署：以自动化方式将应用程序安装到运行时系统中称为部署，并且有多种方式可以实现这一点。

  • 自动化场景测试应该是变更提议的验收过程的一部分。这些测试可以通过构建触发，以确保产品质量。

  • 设置多个运行时系统，如 JEE 服务器，避免单实例瓶颈，能够并行运行测试查询。使用单个系统还会产生重新创建环境和每个测试用例变更开销的负担，导致性能退化。

  • 使用 Docker 或容器技术按需安装和启动运行时系统，并在定义明确的状态下运行，然后移除。

  • 自动化测试用例，由于新评论的验证频率和时间在大多数情况下是不可预测的，因此在给定时间调度每日任务是一个可以探索的选项，在此过程中构建会被部署到测试系统并在成功部署后通知。

  • 部署到生产环境是一个人工有意识的决定，满足所有质量标准并确保更改适合部署到生产环境。如果可以自信地实现自动化，这也是自动化持续部署的最高成就。

持续交付意味着每个集成的变更都经过充分验证，确保它可以部署到生产环境。这并不要求每个变更都自动部署到生产环境。

Jenkins 设置

我们将从 Jenkins 开始，因为它是持续集成过程中的核心组件。Jenkins 的处理流程如下所示：

参见 Jenkins 首页：jenkins.io/index.html，如下所示：

安装 Jenkins 的前提条件

Jenkins 的安装和配置要求应根据以下参数进行充分规划，如 Jenkins 首页所述：

• 操作系统—Linux 版本（Ubuntu/Debian、Red Hat/Fedora/CentOS、openSUSE、FreeBSD、OpenBSD、Gentoo）、Windows、macOS X

• JDK 版本

• 内存

• 磁盘空间

• Java 容器—Jenkins WAR 文件可以在任何支持 Servlet 的引擎上运行，如 Tomcat 或 Glassfish 应用服务器。

Jenkins 可以根据其用途以不同的方式安装：

• 独立运行：Jenkins 可以在其自己的进程中独立运行，使用内置的 Web 服务器（Jetty）进行实验和小项目。

• 基于 Servlet：它还可以作为一个 Servlet 框架运行，用于开发项目。

• 用于预发布或生产的多节点设置：分布式客户端-服务器设置；建议使用 Jenkins 的高级安装程序。

独立安装

如名称所示，独立安装是在单台机器上独立进行的（与为不同任务使用多个系统相对）：

1. 独立安装要求系统已安装 JDK。

2. 下载 Jenkins.war 文件。

3. 打开命令提示符，在 Jenkins.war 文件所在位置运行以下命令：

   C:>Java -jar Jenkins.war
   
   

   

在初始化过程中，将运行一些任务，并且在安装过程中会出现以下屏幕：

1. 初始屏幕页面会询问插件选项：

2. 插件将根据前述选项中的配置进行安装：

3. 安装成功后，将弹出以下管理员凭证创建页面：

4. 访问 Jenkins：安装成功后，可以通过本地机器的 Web 浏览器访问 Jenkins，如下所示：

   http://localhost:8080

5. Jenkins 仪表板将通过此链接打开：

6. 仪表板中的 管理 Jenkins 选项将提供各种配置参数的选项：

7. 仪表板中的 管理插件 选项是一个重要选项，提供了大量插件选择，用于与源代码系统、认证系统、各种开发平台等进行集成。

   在 Servlet 引擎上安装 Jenkins 需要安装 Tomcat 或 Glassfish。

   

8. 将 Jenkins.war 文件复制到 tomcat 文件夹中的 web apps 文件夹。

9. 从 Tomcat bin 目录启动 Tomcat 服务器。

10. http://localhost:8080/Jenkins --在 Tomcat 服务器上访问 Jenkins。

在 Ubuntu 上的 Linux 系统安装

1. 登录到服务器并更新：sudo apt-get -y update。

2. 安装 Java：sudo apt-get install -y default-jdk。

3. 使用 wget 命令从 Jenkins-ci.org 网站下载 Ubuntu 版本：

   wget http://pkg.jenkins-ci.org/debian-rc/binary/jenkins_2.0_all.deb.
   
   

4. 包安装 sudo dpkg - i Jenkins.zip。

5. 通过 sudo apt - get -f install 解决依赖问题。

6. 通过端口 http://localhost:8080/Jenkins 访问 Jenkins。

7. 按照前面的图示继续操作。

8. 为了在启动时初始化 Jenkins，请在 /etc/rc.local 文件中添加命令 /etc/init.d/jenkins start。

Git (SCM) 与 Jenkins 集成

Git 是最流行的源代码管理系统，提供了广泛的好处，例如：

• 版本控制使您能够维护多个版本的代码，用于不同的目的。

• 需要一个代码库来将所有与项目相关的代码集中存放。

• 用户间的协作以及调试过程中的干预。

可以从git-scm.com/downloads下载 Git：

可在桌面版和 Web 版中使用多个平台版本，如 Linux、Windows 等。

仓库可以有多种类型：

• 在 GitHub 上创建的公共仓库可以允许每个人访问读取权限，但写入或提交权限仅授予选定的个人或组。

• 私有仓库允许协作者参与，并且需要订阅 GitHub 的付费服务。

• 本地仓库是桌面版本，不需要互联网连接。

• 远程仓库是一个基于 Web 的仓库，提供了如问题管理和拉取请求等扩展功能。

GitHub 提供选项，可以从单台计算机或多台计算机之间同步代码更改。

拉取更改将同步桌面与在线仓库之间的代码更改，而克隆选项将创建仓库的新副本到本地计算机。

执行这些任务使我们能够在基于云的 SaaS 系统中维护源代码。

1. 在 GitHub 上创建一个登录账户。

2. 创建一个项目仓库来组织与你项目相关的代码。

将 GitHub 与 Jenkins 集成

若要将 GitHub 仓库与 Jenkins 集成，请按以下步骤操作：

1. 在管理插件中，在筛选器部分搜索 Git 插件并安装。

2. 如果默认已安装，我们可以在已安装标签下找到它，如下所示：

3. 在 Jenkins 重启后，创建新项目时，Jenkins 主页面会显示如下画面：

4. 选择一个工作名称，接下来的页面将显示如下 Git 选项，位于源代码管理标签下。你可以以类似的方式添加其他 SCM 工具，如 CVS、Subversion 等：

5. 在前述的仓库 URL 占位符中输入本地计算机的 Git 仓库地址或 Web 链接，以配置 Git 与 Jenkins 的集成。

Maven（构建）工具与 Jenkins 集成

让我们执行以下步骤，将 Maven（构建）工具与 Jenkins 集成：

1. 从maven.apache.org/download.cgi下载 Maven，这是最新的二进制文件版本：

2. 将下载的 Maven 文件解压到一个文件夹中。

3. 打开管理 Jenkins：

   按照如下选择 Maven 插件并安装，不要选择重启选项。

   

4. 监控插件进度如下所示：

5. 在 配置 工具下，通过提供仓库位置添加 Maven：

6. 使用 Maven 项目选项创建一个新项目：

7. 构建环境中的 Maven 选项如下：

8. 项目按以下方式创建：

使用 Jenkins 构建作业

让我们按照以下步骤使用 Jenkins 构建作业：

1. 一个简单的应用程序构建并运行程序：

2. 以下是列出的源代码仓库选项：

3. 我们可以指定需要构建的文件位置，可以选择从源 Git 代码仓库或 GitHub 的 URL 中获取：

4. 可以通过多种选项、命令模式和 Maven 等执行构建：

5. 命令行程序可以如下执行：

6. 保存后，构建选项可见，并且历史记录也可以查看：

7. 可以看到构建进度并且仓库可用，如下所示：

代码审查 – Gerrit

代码审查是软件开发框架中的一个重要功能。拥有像 Gerrit 这样的良好协作工具来进行代码审查过程非常合适且必要。Gerrit 发起一个基于拉取的工作流来启动变更请求，在该过程中，即使是源代码也会包含评论，以便通过工作流过程将变更合并到代码仓库中。Gerrit 维护一个镜像 Git 项目仓库的本地仓库和参考仓库。Gerrit 从主分支创建另一个维护分支来跟踪代码的审查；它为提交信息创建一个 change-id 标识符，以跟踪每次代码审查中的变更。

Gerrit 允许进行代码变更比较，审阅者可以给出五个评分之一：

• +2：看起来不错，已批准

• +1：看起来不错，但需要额外的审批

• 0：没有评论

• -1：建议不要提交

• -2：阻止提交

Gerrit 安装

让我们按照以下步骤安装 Gerrit：

1. 从 www.gerritcodereview.com/ 下载 Gerrit。

2. 根据平台选项按照安装说明进行操作，并通过端口 8080 访问 Gerrit，如下所示，以创建用户和项目：

3. 在 Jenkins 中的 管理插件 下配置 Gerrit：

在 Lesson 2 中列出的版本控制工具，例如 Gerrit，这是一个基于 Web 的代码审查界面，允许在线审查更改以从任何 Git 客户端推送更改，然后与主分支自动合并；它也可以配置为远程 Git 仓库。

Gerrit 的配置包括用户创建，设置 Secure Shell（SSH）以与 Gerrit 服务器交换数据。配置文件 /etc/gerrit.config 包含了需要根据配置需求设置的广泛参数。

仓库管理

维护多个构建版本的制品是仓库管理的关键特性，而 Nexus 是一个流行的仓库管理器。可以从 www.sonatype.org/nexus/downloads/ 下载它。

安装后，可以从 http://<nexus host>:8081/nexus 访问：

Nexus 可以配置插件用于 Jenkins 集成：

使用 Jenkins 进行测试

Jenkins 提供许多开箱即用的功能和测试插件。该网站 wiki.jenkins.io/display/JENKINS/xUnit+Plugin 提供了这些插件：

下面显示了一系列可用的测试插件：

• JUnit 本身

• AUnit

• MSTest（从 MSTest 插件导入）

• NUnit（从 NUnit 插件导入）

• UnitTest++

• Boost Test Library

• PHPUnit

• Free Pascal Unit

• CppUnit

• MbUnit

• Google 测试

• EmbUnit

• gtester/glib

• QTestLib

设置单元测试

让我们执行以下步骤来设置单元测试：

1. 选择我们设置的项目：

2. 选择构建选项：

3. 选择一个 高级 选项：

4. 输入 build.xml 的位置：

5. 选择后构建选项，并选择 发布 JUnit 测试结果报告：

6. 在测试 reports.xml 中，将报告创建文件夹放入我们项目中，以便 Jenkins 检索通过运行 JUnit 测试用例生成的 XML 文件：

我们可以选择构建并深入到测试结果。

自动化测试套件

持续集成是验证构建以客观评估其进入下一级别准备就绪的过程；这通过自动化测试完成。因此，构建制品被设置为自动测试；Selenium 是最流行的框架。

可以从以下网站下载：

1. 在 Jenkins 的 插件管理器 下，选择 Selenium 插件并安装，重新启动以启动：

2. 配置selenium server JAR文件：

3. 配置我们创建的项目，以适应这个自动化框架：

4. 在构建过程中，添加选项SeleniumHQ htmlSuite Run：

5. Selenium IDE 将生成测试套件，通过启动 Selenium 驱动程序，Selenium 测试将通过 SuiteFile 启用：

持续交付-构建流水线

持续交付是从软件开发到部署的强大流水线构建过程。

1. 从管理插件安装构建流水线插件，如下所示：

2. 要设置构建流水线，请点击仪表板上所有标签旁边的+符号：

3. 选择构建流水线视图并为流水线选择一个名称：

4. 选择选项并创建项目：

5. 交付流水线视图通过显示项目每个阶段的状态来创建。

Jenkins 功能

• 客户端-服务器

• 安全

• 报告

较大的项目需要配置多个机器，而不是在一台机器上进行集中构建。同时，测试构建还需要多个不同的环境。Slave 机器可以有效地将这些负载从主服务器中卸载。

它们需要一个从主服务器通过 TCP/IP 套接字的双向通信链接，仅需要一个 Slave 代理，而不是完整的 Jenkins 包或已编译的二进制文件。

1. 要在 Jenkins 中设置 Slave/节点，请配置并选择管理节点选项，然后创建一个新节点：

2. 选择名称和傻瓜 Slave选项。

3. 需要提供 Slave 节点的详细信息，然后选择让 Jenkins 将 Windows Slave 视为 Windows 服务。需要提供机器的节点名称和登录凭证等详细信息。

4. Slave 机器将如图所示可用；新的作业可以配置为在此 Slave 机器上运行。

Jenkins 中的安全性

拥有相关权限的用户可以进行安全配置设置：

1. 在管理 Jenkins下，选择配置全局安全性，然后选择启用安全性选项：

2. 保存选项后，系统将提示您输入管理员用户信息。

3. 在Jenkins 管理设置中，选择管理用户选项来创建用户，然后设置执行作业所需的基于矩阵的安全授权：

4. 可以安装报告选项、度量选项和报告插件。

5. 有多种指标可供使用，例如构建历史指标插件：

   • 平均故障时间 (MTTF)

   • 平均恢复时间 (MTTR)

   • 构建时间的标准偏差

   

6. 它可以在管理插件下安装，选择构建历史指标插件，上述指标将在工作页面上显示。

7. 要查看图形化表示，请在管理插件下使用 Hudson global-build-stats 和全局构建统计插件。设置选项、初始化统计数据、创建新图表选项，所有现有的构建记录将显示出来。

总结

在本节课中，我们学习了使用仓库管理、代码审查和测试自动化来实现持续开发、持续集成和持续部署的过程和工具。

在下一节课中，我们将讨论基础设施配置管理作为持续部署代码的主题，使用的工具包括 Chef、Puppet 和 Ansible。我们还将讨论使用 Splunk 和 Nagios 进行的持续监控过程。

评估

1. 持续交付是延伸 __________ 的过程。

   1. 持续部署

   2. 持续监控

   3. 持续集成

   4. 持续交付

2. 判断以下陈述是对还是错：交付经理将批准接受测试，以同意部署测试系统。

3. 以下哪项是有效的机制，用于在变更被推送到主线之前通过识别问题来提出变更并检查变更的质量，从而避免返工？

   1. 在 Gerrit 中进行审查拉取

   2. SVN 中的拉取请求

   3. GitHub 中的拉取请求

   4. GitHub 中的拉取请求

4. 哪个命令用于安装 Jenkins？

   1. C:>java Jenkins.war

   2. C:>Java -jar Jenkins.war

   3. C:>Java –jar Jenkins.war

   4. C:>java –jar Jenkins.war

5. 以下哪项是从软件开发到部署构建强大管道的过程？

   1. 持续监控

   2. 持续部署

   3. 持续集成

   4. 持续交付

第四章：DevOps 持续部署

DevOps 持续部署使得更改能够快速地从开发转移到生产环境。基础设施和自动化在实现持续部署中发挥着关键作用。在本课程中，我们将学习配置自动化和使用 Chef、Ansible 等工具实现基础设施自动化（基础设施即代码）。我们还将讨论使用 Splunk 和 Nagios 等工具进行持续监控的过程：

• 持续部署

• Chef

  • 组件

  • 术语

  • 架构

• Ansible

  • 组件

  • 术语

  • 架构

• 持续监控

• Splunk

• Nagios

正如我们在前面的课程中所讨论的，以下图示展示了持续集成、持续部署和持续交付的对齐过程。

持续集成（CI）是指将开发、单元测试和构建过程以持续模式进行，而不是以分步方式进行的过程。在 CI 过程中，每个开发人员将其代码更改合并到中央版本控制系统中，每次提交都会触发自动构建。因此，最新版本始终可用，并且构建的可执行文件来自最新的代码。

持续交付（CD）是软件工程中持续集成过程的下一步，旨在通过短周期的测试和快速、频繁地发布软件。自动化测试过程确保软件可以随时可靠地发布。

持续部署是指最小化新代码开发与其在生产环境中可用之间的时间差（经过的时间）。为了实现这一目标，持续部署依赖于自动化各种步骤的基础设施，每次成功的代码集成符合发布标准后，便会进行部署，实时应用程序会更新为新代码。

传统上，新机器是由管理员和系统工程师根据文档、定制脚本等构建的。通过手动过程（如定制脚本、金像配置等）管理基础设施既耗时又容易出错。希望实现更快和更成熟部署的组织采用基础设施配置自动化，这意味着像管理软件代码一样管理基础设施，从而实现可重复的结果，因此这也被称为基础设施即代码。

就像软件开发生命周期（SDLC）过程一样，基础设施也可以通过类似的工具和过程进行管理，如版本控制、持续集成、代码审查和自动化测试，扩展到使基础设施配置变更更加健壮和自动化。

基础设施代码和配置变更将被持续测试、共享并推动到所有环境，从开发到 QA 测试系统，再到生产环境，过程更加轻松、迅速、安全且可靠，并带有详细的变更审计记录。通过基础设施代码作为服务，新机器的配置可以写成代码，并同时设置多个机器到期望的状态。这种可扩展的模型通过利用云的弹性变得更有效。采用 DevOps 的基础设施即代码，不仅限于简单的基础设施自动化，还扩展了以下多个好处：

• 确保无误的自动化脚本是可重复的

• 在多个服务器上重新部署

• 出现问题时能够回滚

• 可以有效执行基础设施代码测试标准，如单元测试、功能测试和集成测试

• 由于机器的文档状态是作为代码维护并保持最新，因此避免了书面文档的使用

• 促进开发与运维团队在基础设施配置和供应方面的协作，以及将基础设施代码作为变更管理的一部分！DevOps 持续部署

我们将从流行工具功能的角度讨论持续部署，如前图所示。

Chef

Chef 是一个著名的配置管理和基础设施自动化平台；它提供了完整的企业能力，如工作流、可视化和合规性。它使得从开发到生产的基础设施和应用程序的持续部署成为可能。基础设施配置自动化作为代码，可以通过 Chef 在云端、本地或混合环境中进行编写、测试、部署和管理，提供全面的 24/7 支持服务。例如，客户端系统、安全补丁可以通过从主服务器写入配置集并同时在多个节点上执行来更新。

如下图所示，Chef 平台支持多种环境，如 Amazon Web Services、Azure、VMware、OpenStack、Google Cloud 等。Windows、Linux、VMware 等平台都可以使用。所有流行的持续集成工具，如 Bitbucket、Jenkins、GitHub、CircleCI 等，都支持工作流集成。运行时环境可在 Kubernetes、Docker 和 Swarm 上运行。

Chef Landscape 组件

这里展示了 Chef 的整体环境，包括 Chef 的各个元素，如节点、服务器和工作站及其关系。我们将讨论每个组件、术语及其在生态系统中的作用，以便 Chef 客户端能够执行分配的任务。Chef 的术语类似于烹饪。Cookbook（食谱）是制作菜肴的公式，而 Recipe（配方）是原料。

Chef 的组件包括：

• Chef 服务器

• Chef 客户端

• Chef 工作站

• Chef 仓库

Chef 服务器

Chef 服务器是用于维护网络中配置数据的中心，存储食谱，向节点应用策略，并由 Chef 客户端管理每个注册节点的详细元数据。Chef 服务器通过安装在各个节点上的 Chef 客户端提供配置细节，如配方、模板和文件分发。相应地，Chef 客户端在其节点上实现配置，从而减轻了 Chef 服务器的处理任务。此模型具有可扩展性，能够在整个组织中一致地应用配置。

Chef 服务器的功能

带有管理控制台和搜索功能的 Web 用户界面

• Chef 服务器上的管理控制台是一个基于 Web 的界面，用于管理多个功能，如：

  • 网络中的节点

  • 食谱和配方

  • 分配的角色

  • 数据包——JSON 数据存储，可能包含加密数据

  • 环境详情

  • 用于索引数据的搜索功能

  • 用于 Chef 服务器访问的管理用户帐户和数据

• 搜索功能便于查询 Chef 服务器上索引的任何类型的数据，如节点、角色、平台、环境、数据包等。Apache Solr 搜索引擎是基础搜索引擎，并扩展了所有功能，如精确搜索、通配符搜索、范围搜索和模糊搜索。可以在配方、命令行、管理控制台搜索功能等不同选项中运行完整的索引搜索。

• 数据包位于 Chef 服务器的一个安全子区域中；它们存储敏感数据，如密码、用户帐户数据和其他机密类型的数据。它们只能被拥有由 Chef 服务器验证的有效 SSL 证书的节点访问。数据包通过 Chef 服务器访问，其全局变量以 JSON 格式存储，可以通过配方进行搜索和访问，并加载。

• 策略定义了如何根据业务和操作要求、流程以及生产工作流实施角色、环境和食谱版本：

  • 角色是一种根据组织中执行的特定职能、模式和流程来分配任务的方式，例如电力或业务用户等。每个节点、Web 或数据库服务器都有独特的属性，并且每个角色都分配一个运行列表。当一个节点执行任务时，它会将其属性列表与执行该功能所需的属性进行比较。Chef 客户端确保属性和运行列表与服务器上的数据保持同步。

  • 环境反映了组织的实际需求，如开发、预发布或生产系统，每个环境都由一个食谱版本进行维护。

  • 食谱书（Cookbooks）维护组织特定的配置策略。不同版本的食谱书被管理，就像源代码控制一样，包括相关环境、元数据、不同需求的运行列表；它们被上传到 Chef 服务器，并在配置节点时由 Chef 客户端应用。食谱书定义了一个场景，并包含支持该场景所需的一切，例如：

    • 配方指定了要使用的资源及其顺序

    • 属性值

    • 文件分发

    • 模板

    • Chef 扩展，如自定义资源和库

  • 运行列表包含 Chef 配置节点到期望状态所需的所有信息。它是一个按顺序排列的角色和配方列表，精确指定运行顺序以达到预期状态。每个节点都有定制的运行列表，并存储在 Chef 服务器上的节点对象中。它通过刀具命令（knife commands）或工作站上的 Chef 管理控制台进行维护，并上传到 Chef 服务器。

节点上的 Chef 客户端

Chef 客户端可以安装在不同类型的节点上——物理、虚拟、云、网络设备等，这些节点都已注册到 Chef 服务器。

• 节点类型：

  • 物理节点是连接到网络的活动设备（系统或虚拟机），并安装有 Chef 客户端，以便与 Chef 服务器通信。

  • 基于云的节点托管在外部云环境中，如 AWS、Microsoft Azure OpenStack、Google Compute Engine 或 Rackspace。带插件的刀具（Knife）支持外部云服务并创建实例，以部署、配置和维护这些实例。

  • 虚拟节点是一个像软件实现一样运行的系统，无法直接访问物理机器。

  • 网络节点，如交换机，可以使用 Chef 进行配置，并自动化物理和逻辑以太网链路属性及 VLAN。网络设备的示例有 Juniper Networks、Arista、Cisco 和 F5。

  • 容器是运行独立配置、共享相同操作系统的虚拟系统。容器在管理分布式和可扩展的应用程序与服务方面非常有效。

• Chef 客户端：

  • Chef 客户端执行实际配置。它定期联系 Chef 服务器以检索最新的食谱书，以根据食谱书的指令更新节点的当前状态（如果需要）。这个迭代过程由业务策略强制执行，以确保网络符合预期的目标状态。

  • Chef 客户端是安装并运行在每个已注册到 Chef 服务器上的节点上的本地代理，确保节点处于预期状态。Chef 客户端承担大部分计算工作。它通常是虚拟机、容器实例或物理服务器。

  • Chef 客户端与 Chef 服务器之间的身份验证通过每个事务请求的 RSA 公钥/私钥对进行。Chef 服务器上存储的数据在注册节点验证后共享。任何未经授权的数据访问都会被避免。

  • 在安装 Chef 客户端后，节点成为基础设施中的计算资源，由 Chef 管理，执行如下任务：

    • 将节点注册到 Chef 服务器

    • 认证服务

    • 创建节点对象

    • 与 Chef 服务器同步食谱

    • 所需的 cookbooks、食谱、属性和所有其他依赖项会被编译并加载

    • 根据要求配置节点

    • 异常处理和通知

Ohai

Ohai 是 Chef 客户端运行的工具，用于收集系统配置和度量数据，具有许多内置插件，用于确定系统状态以供食谱使用。Ohai 收集的度量数据包括：

• 操作系统

• 内核

• 主机名

• 完全限定域名

• 虚拟化

• 云服务提供商的元数据

• 网络

• 内存

• 磁盘

• CPU

由 Ohai 收集的属性会自动被 Chef 客户端使用，以确保这些属性与服务器上的定义保持一致。

工作站

工作站使用户能够编写、测试和维护食谱，并与 Chef 服务器和节点进行交互。Chef 开发工具包也会在工作站上安装和配置。Chef 开发工具包是一个包含一系列规定工具的包，其中包括 Chef、命令行工具、Test Kitchen、ChefSpec、Berkshelf 等。用户使用工作站进行以下操作：

• 开发食谱和测试食谱

• 在不同环境中测试 Chef 代码

• 与 Chef 仓库同步的版本源控制

• 定义和配置角色、环境及组织政策

• 强制执行数据包用于存储关键信息

• 在节点上执行引导操作

Cookbook 是存储文件、模板、食谱、属性、库、定制资源、测试和元数据的仓库。Chef 客户端通过 cookbooks 和食谱配置组织中的每个节点，配置的基本单元是 cookbook，并为食谱提供结构。基础设施状态定义为文件、模板或根据所需场景的策略分发中的包。

Chef cookbook 的编程语言是 Ruby，作为一门具有语法定义的完备编程语言。食谱是特定配置项的简单模式，例如软件包、文件、服务、模板和用户，包含定义属性和值的块。食谱是 cookbook 中的基本配置元素。Chef 食谱是一个文件，汇集了相关资源，例如配置 Web 服务器、数据库服务器或负载均衡器所需的一切。食谱存储在 cookbooks 中，且可以依赖于其他食谱。

Chef 仓库

如其名所示，Chef repo 是用于编写、测试和维护 cookbook 的仓库工件。Chef repo 像源代码一样管理，使用版本控制系统（如 GitHub、Bitbucket 等）进行同步。Chef repo 目录结构可以包含每个 cookbook 的 Chef repo，或者将所有的 cookbook 存储在一个 Chef repo 中。

knife是从工作站与 Chef 服务器进行通信的命令接口，用于上传 cookbook。要指定配置详情，使用knife.rb文件，knife帮助管理：

• 节点引导

• 配方和 cookbooks

• 环境、角色和数据包

• 各种云环境资源

• Chef 客户端安装到节点

• Chef 服务器的索引数据搜索功能

用于与 Chef 一起工作的工具和实用程序包称为Chef 开发工具包（Chef DK）。它包括与 Chef 交互的命令行工具，如knife Chef 服务器和 Chef 客户端，以及本地 Chef 代码库（chef-repo）。Chef DK 的组件如下：

• Chef 客户端

• Chef和knife命令行工具

• 测试工具 Test Kitchen、Cookstyle 和 Foodcritic

• 使用 InSpec 作为可执行代码的合规性和安全性要求

• Cookbooks 用于上传到 Chef 服务器

• 对数据包项进行加密和解密使用 Chef-Vault，并通过注册节点的公钥进行处理

• Cookbooks 依赖管理器

• 工作流工具 Chef

• 单元测试框架 Chef Specto 在本地测试资源

• 用于风格检查以编写干净 cookbook 的基于 Rubocop 的工具 Cookstyle

• Chef Automate 服务器上的持续交付工作流，也包括设置和执行的命令行工具

• 用于配方代码的静态分析的 Foodcritic 是一个 lint 工具

• 用于跨平台测试 cookbooks 的集成测试框架工具是 Test Kitchen

• 用于快速 cookbook 测试和容器开发，kitchen-dokken是test-kitchen插件，包含一个驱动程序、传输工具和用于 Docker 和 Chef 的配置器

• Vagrant 的厨房驱动程序是kitchen-vagrant

• 人们在同一个chef-repo和 Chef 服务器刀插件工作流中共同工作，刀插件是knife-spork

• Chef 的首选语言是 Ruby

配方是资源的集合，使用资源名称、属性值对和操作等模式进行定义。它是一个基本的配置元素，旨在以可预测的方式读取并执行，编写时使用 Ruby 编程语言。

以下是一些属性：

• 包含配置系统所需的所有内容

• 存储在 cookbook 中

• 为了使用 Chef 客户端，必须将其添加到运行列表中

• 它按照在运行列表中列出的顺序执行

• 只有在指示时，Chef 客户端才会运行配方

• 可能包含在另一个配方中

• 可能读取数据包的内容（加密数据包）

• 可能输入搜索查询的结果

• 可能依赖其他配方

• 通过给节点打标签，方便创建任意的分组

• 如果食谱是常量，那么重复执行也不会发生变化

Recipe DSL 是一种 Ruby DSL，用于从食谱内声明资源。它还帮助确保食谱与节点（及节点属性）按照预期的方式进行交互。大多数 Recipe DSL 方法会找到特定参数，指导 Chef 客户端根据节点参数采取相应的操作。

资源是一个配置策略声明，表示：

• 描述所需配置项的期望状态

• 声明了所需项目的步骤以达到期望的状态

• 资源类型被指定，如包、模板或服务

• 列出了其他资源属性

• 被分组到食谱中，描述工作配置

Chef 内置了覆盖常见平台的常见操作的资源，并且可以构建来处理任何定制化的需求。

通过不同版本的食谱，可以管理多个生产、预发布和开发/测试环境。

食谱模板资源用于为菜谱添加动态生成静态文本文件的功能。

为了管理配置文件，使用嵌入式 Ruby（ERB）模板。

食谱/模板目录包含具有 Ruby 表达式和语句的 ERB 模板文件。

食谱按照标准一致地编写，并经过测试。

通过单元和集成测试，食谱的菜谱得到了验证，代码质量的测试也被称为语法测试。

Test Kitchen、ChefSpec 和 Foodcritic 等是用于测试 Chef 食谱的工具。

属性文件按照食谱中定义的顺序执行。

Chef 建立在 Ruby 之上，是一种轻量级的领域特定语言（DSL），并具有用于组织定制需求的内建分类法。

为了管理环境、食谱、数据包，并为用户和组配置基于角色的访问，属性、执行列表、角色等，Chef 服务器用户界面是 Chef 管理控制台。

Chef Supermarket 是社区共享和管理的地方。任何 Chef 用户或组织都可以使用食谱。

Chef 的扩展功能

它是一个强大的自动化平台，可以将基础设施转化为可以在云端、本地或混合环境中运行的代码。无论组织规模大小，Chef Automate 都可以配置、部署和管理整个网络中的基础设施。Chef Automate 的核心组成部分包括 Chef、Habitat 和 InSpec。

以下图片展示了三个功能强大的开源引擎：

Chef 是基础设施自动化的核心引擎。Habitat 是一个应用程序自动化工具，模拟容器和微服务的概念。InSpec 通过指定可执行代码来确保合规性和安全性要求。

Habitat

Habitat 提供了一种规定的应用程序自动化打包格式；Habitat 管理器和应用程序依赖项作为一个整体打包和部署。Habitat 包格式定义了如何构建，这些包是隔离的、不可变的，可在任何类型的运行时环境（如容器、裸金属或 PaaS）中执行。Habitat 管理器管理包的对等关系、升级策略和安全政策，这些都是可审计的。

InSpec

InSpec 是一个开源工具，用于测试是否符合安全政策。它是一个框架，用于指定合规性、安全性和政策要求，以自动测试基础设施中的任何节点。合规性可以以代码的形式表达，并集成到部署管道中。

• InSpec 使用 Compliance DSL 可以快速简便地编写审计规则。

• InSpec 检查基础设施节点以在本地或远程运行测试。

• 安全性、合规性或政策问题的违规行为将被记录。

InSpec 审计资源框架与 Chef Compliance 完全兼容。

它可在多个平台上运行，使用 SSH 等远程命令或 Docker API，除了通过 API 确保合规性外，还可以访问数据库、进行检查，并可以限制服务或协议的使用以及虚拟机的配置。例如，可以限制客户端或服务器机器上的 Telnetd 或 FTP 服务。

持续部署全栈管道是 Chef Automate。它包括自动化测试以确保合规性和安全性。该工作流为应用程序和基础设施提供了可视性，以及从开发到生产的变更传播。

Chef 高级架构组件包括 Chef DK、Chef Server 和客户端：

Chef 服务器扮演多个角色，作为配置数据的中心。它存储 cookbook，将政策应用到系统，并根据基础设施以及为每个系统定义的元数据进行配置。

Cookbook 开发工作流由 Chef Development Kit 如下所示：

• 骨架 cookbook 创建：这是一个已经包含 Chef Development Kit 标准文件的 cookbook，Berkshelf 是一个包管理器，帮助管理 cookbook 和相关的依赖项。

• 使用 Test Kitchen 创建虚拟机环境：该环境用于开发 cookbook，并提供执行自动化测试和调试该 cookbook 的位置细节。

• 准备并调试 cookbook 的食谱：这是一个迭代过程，用于开发和测试 cookbook，修复 bug，并测试直到它们达成目的。Cookbook 可以使用任何文本编辑器编写，如 Sublime Text、vim、TextMate、EditPad 等。

• 进行验收测试：这些测试在完整的 Chef 服务器上执行，使用接近生产环境的环境，而不是开发环境。

• 通过所有接受测试的 cookbooks 将按照预期方式部署到生产环境中。

Chef Automate 工作流

Chef Automate 流水线是用于基础设施和应用程序的全栈持续交付。它支持安全部署任何应用程序，支持高速变更，并关联基础设施变更。

Chef Automate 流水线质量门控已自动化，能够将开发者的工作站中的变更从部署推送到生产环境。提出的变更经过团队批准后，接受测试也通过并被发布到相应的制品中，交付到生产环境。

此图显示了从开发、测试到 Chef 代码部署的工作流：

该制品在接受阶段后通过流水线，进入质量保证的联合阶段、排练（预生产）阶段和交付（生产）阶段。

Chef Automate 图形用户界面提供了对操作和工作流事件的视图。其数据仓库收集来自 Chef、Habitat、Automate 工作流和合规性的输入。仪表板跟踪每个变更的状态，通过管道，并提供查询语言来自定义仪表板。

合规性

通过在 InSpec 中创建自定义报告，结合合规规则，可以识别合规性问题、安全风险和过时的软件。内置的配置文件提供了针对安全框架的预定义规则集，如互联网安全中心（CIS）基准等。合规报告可以是独立的，也可以是集成的。此外，Chef Automate 服务器还提供了高可用性、容错性、实时基础设施数据和一致的搜索结果。

Chef 合规性服务器便于基础设施合规性的集中管理，执行以下任务：

• 创建和管理规则配置文件

• 按照组织的安全管理生命周期定期测试节点

• 扫描完全通过远程执行；节点上不安装任何脚印

• 合规报告确保基础设施符合安全要求

• 节点合规性的审计统计信息可用！合规性

Chef 合规报告详细列出了多个参数，例如节点级的补丁和合规性，详见以下内容：

从 Automate 查看 Chef 合规报告。

Chef Automate 提供了分析合规报告的能力，可以根据节点、节点平台、环境或配置文件来分析数据，并能够深入挖掘信息。

Chef Automate 合规控制状态报告提供了一个综合仪表板，展示了主要、次要、关键、补丁级别等信息。

Ansible

Ansible 是一个流行且强大的自动化框架，支持持续交付，具有以下主题中列出的功能和优点：

突出特性

Ansible 提供以下功能：

• 现代化

  • 自动化现有的部署流程

  • 管理遗留系统和流程，像 DevOps 一样进行更新

• 迁移

  • 一次定义应用程序，随时重新部署

• DevOps

  • 一切建模，持续部署

Ansible 的好处

使用 Ansible 带来如下多个优势：

• 简单易用

  • 无需特殊编码技能

  • 任务按顺序执行

  • 快速提高生产力

  • 自动化易于理解

• 功能强大

  • 应用部署

  • 配置管理

  • 工作流编排

  • 应用生命周期的编排

• 无代理

  • 无代理架构

  • 使用 OpenSSH 和 WinRM

  • 无需代理来利用或更新

  • 更高效且安全

Ansible 是一个多维的 IT 自动化引擎，简化了云资源供应、服务间编排、配置管理、应用部署以及许多其他 IT 功能的自动化。

Ansible 通过规定系统间的相互关系，模拟 IT 基础架构，适用于多层部署，而不是单独管理各个系统。

如功能部分所述，Ansible 不需要客户端代理或额外的自定义安全基础设施。它通过用一种名为 YAML 的简单英语语言描述自动化任务，并以 Ansible playbooks 的形式，使部署变得非常简单。

Ansible 架构如下所示：

Ansible 术语、关键概念、工作流和使用

Ansible Tower 是一个基于 Web 的企业自动化框架解决方案，旨在成为控制、保护和管理 Ansible 环境的中心，提供用户界面和 RESTful API。它提供以下丰富的功能：

• 访问控制基于角色，以确保环境安全，并且高效管理——允许共享 SSH 凭证但不进行传输

• 通过一键部署访问，即使是非特权用户，也可以通过实时提供访问权限来安全地部署整个应用程序

• 确保完整的审计和合规性，因为所有 Ansible 自动化操作都被集中记录

• 支持来自多种云源的广泛库存，可以进行图形化管理或同步

• 它基于强大的 REST API，能够与 LDAP 良好集成，并记录所有任务

• 与持续集成工具 Jenkins 的易集成，提供命令行工具选项

• 支持通过配置回调实现自动扩展拓扑

• Ansible Tower 通过 Ansible playbooks 进行安装！Ansible 术语、关键概念、工作流和使用

CMDB

Ansible 配置管理数据库（CMDB）在数据库中维护企业的所有配置信息，并支持多种格式的云创建选项，以适配不同的供应商。

Playbooks

Playbook 是用 YAML 编写的配置程序，用于自动化系统。Ansible 能够精细地编排多个基础设施拓扑实例，并对许多机器进行详细的控制。Ansible 的编排方法是通过简单的 YAML 语法或功能来管理精细调校的自动化代码。

Ansible playbook 描述了一个政策，用于在远程系统上执行编排操作，以进行配置和部署，从而强制执行一般的 IT 流程遵循步骤。

一个简单的类比是，主机清单是原材料，说明书是 playbook，Ansible 模块是工作坊中的工具。

要管理远程机器部署的配置，可以在基础层级使用 playbook。它们可以按顺序执行多层次的发布，包括涉及滚动更新的高级操作，途中与监控服务器和负载均衡器交互，并将操作委托给其他主机。

Playbook 是以基本的文本语言开发的，方便人类阅读。Playbook 和文件的组织可以有多种方式。

一个简单的 playbook 示例：

- hosts: webservers 
serial: 6 # update 6 machines at a time 
roles: 
- common 
- webapp 
- hosts: content_servers 
roles: 
- common 
- content 

模块

Ansible 模块可以控制系统资源，如服务、软件包或文件，以处理和执行系统命令。这些资源模块由 Ansible 推送到节点上，配置它们以达到所需的系统状态。这些 Ansible 模块通过 SSH（安全外壳）在目标节点上执行，并在完成任务后被移除。模块库默认随多种模块一起提供，可通过 playbook 或直接在远程主机上执行。这些模块可以驻留在任何机器上，不需要维护服务器、守护进程或数据库。模块和库是可定制的，通常通过任何终端程序和文本编辑器创建，为了跟踪内容的变化，版本控制系统被有效使用。

清单

Ansible 清单是资源的列表：

• 主机和组

• 主机变量

• 组变量

• 组和组变量的组合

• 默认组

• 拆分组、主机及特定数据

• 清单行为参数列表

• 非 SSH 连接类型

通过清单列表，Ansible 可同时在基础设施中的多个系统上工作。动态清单机制允许通过清单插件，使多个清单文件既灵活又可定制。清单列表可以放在默认位置，或从动态或云源（如 EC2、Rackspace、OpenStack 或不同格式）指定清单文件位置。

以下是一个纯文本清单文件的样子：

 [webservers] 
www1.example.com 
www2.example.com 
[dbservers] 
db0.example.com 
db1.example.com 

插件

Ansible 的核心功能通过许多便捷的插件得到增强，并且可以用 JSON（Ruby、Python、Bash 等）进行自定义。插件可以连接到任何数据源，扩展 SSH 以外的传输连接类型，回调日志，甚至添加新的服务器端行为。

Ansible Tower

提供多个功能，如：

• 可以连接 LDAP、AD、SAML 及其他目录

• 基于角色的访问控制引擎

• 无暴露存储的凭证

• 对首次使用者简单易用

• 启用智能搜索的信息查找

• 在运行时配置自动化

• 基于 REST API 的流程和工具集成

• Tower 集群扩展容量

Ansible Tower 可以调用多剧本工作流来连接多个剧本，使用不同的清单，以不同用户身份运行，批量执行，或使用不同的凭证。

Ansible Tower 工作流有助于完成许多复杂操作，构建工作流以配置机器，应用系统的基础配置，并通过不同的团队维护不同的剧本来部署应用程序。可以为 CI/CD 构建一个工作流来构建应用程序，部署到测试环境，运行测试，并根据测试结果自动推广应用程序。Ansible Tower 的直观工作流编辑器可以轻松建模复杂的过程，设置不同的剧本作为备选方案，以应对先前工作流剧本的成功或失败。

一个典型的工作流可能如下所示，它可以在多个系统上快速有效地使用，而不需要将基础设施下线。为了实现持续部署，自动化 QA 是至关重要的，它是达到这一水平的关键。

• 自动化脚本用于部署本地开发虚拟机。

• CI 系统（如 Jenkins）在每次代码更改后将部署到暂存环境

• 部署作业在每次部署时执行测试脚本，检查通过/失败状态

• 在部署作业成功后，相同的剧本会在生产环境清单上运行。

Ansible Tower 工作流带来以下功能和特性：

• 作业调度

• 内建通知功能，用于通知团队

• 稳定的 API 连接现有的工具和流程

• 新的工作流用于建模整个过程！Ansible Tower

Ansible Tower 仪表盘（参见图片）提供以下功能：

• 仪表盘和实时自动化更新

• 图形化清单管理

• 集成的 RBAC 和凭证管理

Ansible Vault

Ansible Vault 是一个用于将敏感数据以加密形式存储的功能，例如密码或密钥，而不是将它们以明文形式保存在角色或剧本中。这些 Vault 文件可以放入源代码控制或分发到多个位置。数据文件，如 Ansible 任务、处理程序、任意文件，甚至二进制文件，也可以通过 Vault 加密。这些文件会在目标主机上解密。

Ansible Galaxy

Ansible Galaxy 是一个开源网站，旨在为社区信息提供平台，并促进在构建 IT 自动化解决方案中的协作，旨在将管理员和开发人员汇集在一起。该网站提供了预配置的角色，可以通过 Galaxy 搜索索引下载并快速启动自动化项目。这些也可以通过 GitHub 账户访问。

使用 Ansible 的测试策略

尽管测试是一个非常组织化且特定于站点的概念，Ansible 集成测试通过 Ansible playbook 设计为一个有序且快速失败的系统。它通过基于推送的机制，直接在 Ansible playbook 中嵌入测试。

Ansible playbook 是系统理想状态的模型，确保声明的内容，如要启动的服务和要安装的包，符合声明性语句。Ansible 是一个基于顺序的系统，对于未处理的错误，主机会立即失败并阻止该主机的进一步配置，并在 Ansible 运行结束时显示总结。Ansible 是一个多层次的编排系统，将测试整合到 playbook 运行中，无论是作为任务还是角色。

在部署工作流中集成基础设施测试的应用测试，将有效地检查代码质量和性能，在进入生产系统之前。由于是基于推送的机制，工作流中的检查和均衡，甚至升级，都非常容易在本地或测试服务器上维护。

监控

企业监控是主要活动，它分类了监控开发的里程碑、应用日志、服务器健康状况、操作、基础设施、漏洞、部署和用户活动。这些通过以下方式实现：

• 收集和关键信息

• 成熟的监控工具

• 避免基于不确定性做出感知和决策

• 参与式监控与评估

• 选择和使用正确的指标

• 在业务上下文中解释指标结果

• 实时数据收集

• 管理数据和信息

开发里程碑：监控开发里程碑是衡量你的 DevOps 采纳策略有效性的指标，通过深入了解实际过程和团队的表现。一些度量指标包括冲刺范围的变化、现场和修复的错误数量以及承诺与交付功能的比例。这些度量指标是团队效率和遵守计划的推动因素，这项监控作为敏捷插件集成在问题跟踪中。

代码漏洞：监控应用代码中的漏洞，列出了由于不安全的编码实践而在顶层代码中引入的弱点。这些可以通过定期进行代码审查或更改第三方依赖项等方式来解决。

部署：部署监控是配置构建服务器，使其在过程中内置一些监控，及时通知团队。支持通知的持续集成服务器与聊天服务器通信，及时提醒团队构建和部署失败。

应用日志输出：如果服务是分布式的，应用日志输出应规划为集中式日志记录，以充分受益，错误和异常提供实时价值。从错误产生代码中追踪通知的能力以可搜索格式生成收益，提前了解生产前的情况。

服务器健康：监控可用资源的正常运行时间和性能，停机或过度使用的服务器属于此类别。入侵检测和健康监控系统与同一通知管道上的结合将提供额外的价值。

活动监控：用户活动监控既是功能开发，也是基础设施的扩展。随着监控开发的里程碑，数据量也在被监控。

集中存储应用日志、用户活动监控和项目历史的合并日志数据，增强了在全球范围内关联不同日志源，分析应用程序和项目状态的价值。

Splunk

Splunk 是一种流行的应用监控工具，可以实时查看由 DevOps 驱动的应用交付，支持持续交付或持续集成，从概念到生产的快速迁移。Splunk 企业版通过提高速度和质量，帮助改善应用交付对业务的影响。

Splunk 通过以下好处提高代码质量：

• 在客户看到问题之前解决代码问题

• 更快地检测并修复与生产相关的问题

• 提供客观的指标，以确保代码是可操作的并满足质量 SLA。

Splunk 是一个平台，用于捕捉和记录客户、机器数据、用户、交易、应用程序、服务器、网络和移动设备的所有活动和行为。

Splunk 平台通过集成的实时洞察，从应用开发到测试再到生产监控，提升了其对业务的影响。它提供了跨所有交付生命周期阶段的一体化视图，而不是离散的发布组件。

为业务和 DevOps 领导者提供关于开发和运营的业务相关数据的实时可视化，如应用性能、使用情况、收入系统、购物车履行和注册数据，提供洞察以更好地规划库存、报告并改善客户体验。

支持开发生命周期的集成和跨多阶段、多个应用程序的可视化：

操作生命周期集成和跨多个阶段和应用程序的可视化得到支持。使用分析，应用程序交付速度更快：

• 跨每个 DevOps 交付工具链组件的端到端可视化

• 在应用交付生命周期中，更快迭代的相关洞察

• 测量和基准化版本贡献，提升 DevOps 团队效率

Splunk 通过帮助组织建立反馈循环，评估代码变更对客户的实际影响，从而支持企业领导。持续的互动有助于构建有关机器行为和深度资产模型的更多智能。

这些好处反映了应用交付的业务影响：

• 通过将业务指标与代码变更相关联，获得新的业务洞察

• 通过交付性能更好的代码，增强用户体验

• 提供更安全、合规的代码有助于提升声誉

Nagios 基础设施监控工具

Nagios 开源工具有多种变体，适用于各个操作系统上的每个分段，专门用于监控关键任务基础设施组件：

• 网络监控软件

• 网络流量监控

• 服务器（Linux、Windows）监控

• 应用程序监控工具

• Web 应用程序监控

• 核心引擎和基础 web 界面监控

• Nagios 核心插件包与附加组件

• Nagios 日志服务器安全威胁与审计系统

Nagios 促进了对网络问题的监控，如数据链路过载、网络连接问题、监控路由器、交换机、服务器过载或崩溃等引发的问题。

Nagios 可以通过多种可视化表现形式和报告提供指标结果，监控网络中每个节点的可用性、正常运行时间和响应时间，支持基于代理和无代理的监控。

使用 Nagios 进行有效的应用监控可以帮助组织快速发现应用程序、服务或进程问题，并采取纠正措施，以防止应用程序用户出现停机。

Nagios 工具用于监控应用程序及其状态，涵盖 Windows 应用程序、Linux 应用程序、Unix 应用程序和 Web 应用程序。它拥有一个活跃的社区合作网络。

路由器监控功能提供的好处包括：对无响应机器的即时通知、通过检测网络中断和协议失败进行预警、提高服务器、服务和应用程序的可用性。

使用 Nagios 进行 Windows 监控可提高服务器、服务和应用程序的可用性，快速检测网络中断、服务失败、进程问题、批处理作业和协议失败等。系统指标、事件日志、应用程序（IIS、Exchange 等）、服务（Active Directory、DHCP、服务状态、进程状态、性能计数器等）收集了大量数据。

Nagios – 企业级服务器和网络监控软件

内置的高级功能包括：

• 提供综合仪表盘，整合源、检查、网络流量数据等的概览

• 安全性和可靠性网络分析器的可疑网络活动警报

• 提供关于网络流量、带宽、整体网络健康等的深入洞察和钻取选项，并附有高级可视化功能

• 监控特定应用程序的网络使用情况，提供自定义应用程序监控、自定义查询、视图和报告

• 通过专业视图显示的历史网络流量数据和子集网络流量信息

• 异常活动警报，具有自动警报系统，例如带宽使用超过指定阈值

• 集成的网络分析服务器负载与硬盘空间可用性度量

用于网络分析、监控和带宽的集成仪表板

Nagios 仪表板具有多种监控选项，例如源组、服务器 CPU、磁盘使用情况等，可以根据业务需求扩展和自定义更多选择。

摘要

本课我们学习了使用 Chef、Puppet 和 Ansible 等工具进行基础设施配置管理，以实现持续部署，并且学习了使用 Splunk 和 Nagios 进行持续监控的过程。

到此为止，我们已经完成了本书的内容。我希望你在旅程中顺利，收获了许多关于 DevOps 的知识。

祝愿你未来的项目一切顺利。继续学习和探索！

评估

1. 以下哪个是持续交付对齐的顺序？

   1. 构建、代码、集成、发布

   2. 代码、构建、集成、发布

   3. 构建、代码、发布、集成

   4. 代码、构建、发布、集成

2. 以下哪些是持续部署的工具？

   1. Git

   2. Nagios

   3. JUnit

   4. Jenkins

3. 资源是一个配置策略声明，它：

   1. 包括配置系统所需的一切

   2. 通过给节点打标签，便于创建任意分组

   3. 描述已配置项的期望状态

   4. 按照运行列表中列出的顺序执行

4. 以下哪项包含用于应用自动化的规定打包格式？

   1. Habitat

   2. InSpec

   3. Chef

   4. Ansible

5. ________ 是用 YAML 编写的配置程序，用于自动化系统。

   1. CMDB

   2. 模块

   3. Playbooks

   4. 库存

附录 A. 评估答案

第 1 课：DevOps 入门

问题编号	答案
1	3
2	1
3	2
4	4
5	1

第 2 课：DevOps 框架

问题编号	答案
1	1
2	3
3	2
4	3
5	1

第 3 课：DevOps - 持续集成与交付

问题编号	答案
1	3
2	错
3	4
4	2
5	4

第 4 课：DevOps 持续部署

问题编号	答案
1	2
2	4
3	3
4	1
5	3