---

DevOps - 快速指南

更新于 2025/12/12 16:03:00

DevOps - 传统 SDLC

如今，我们看到公司一直在努力提高效率。他们希望团队能够更好地协作并更快地发布软件。这就是 DevOps 的作用所在。它将软件开发和运营团队连接起来，以便他们可以执行持续集成和交付等工作。DevOps 不仅仅是使用工具，它更像是一种工作方式。它帮助每个人分担责任并共同努力。

但在 DevOps 之前，我们使用传统软件开发生命周期 (SDLC)来构建软件。在传统的 SDLC 中，我们遵循循序渐进的过程。首先，我们收集需求，然后设计、开发、测试，最后部署和维护软件。在某些情况下，此过程有效，但它可能很慢，并且对于当今快节奏的需求来说不够灵活。

在本章中，我们将研究旧 SDLC 方法存在问题的原因。然后我们将了解 DevOps 如何解决这些问题。它为我们提供了一种更灵活、更基于团队的软件开发方式。我们还将比较传统 SDLC 与 DevOps，以了解为什么今天有更多团队选择 DevOps。

传统 SDLC 阶段

传统软件开发生命周期 (SDLC) 使用循序渐进的过程。它也被称为"瀑布模型"。每个阶段都接连发生。在完成上一个阶段之前，我们无法开始下一个阶段。下图简单分解了传统 SDLC 中的关键阶段 −

需求收集和分析

在这个第一阶段，我们专注于了解项目需要什么。业务分析师、利益相关者和客户共同收集有关软件必须执行的操作的所有详细信息。目标是确保每个人都了解系统应该实现的目标。

我们将所有这些需求记录在软件需求规范 (SRS)中。此文档非常重要，因为它有助于指导项目的其余部分。如果我们遗漏了某些内容或误解了需求，则以后可能会引起大问题。

设计阶段

在我们知道需要什么之后，我们进入设计阶段。在这里，软件架构师和设计师为软件制定计划。这包括系统的不同部分如何协同工作(高级设计)以及每个部分的细节(低级设计)。

我们还决定数据库结构、用户界面 (UI) 以及我们将使用哪种技术堆栈。此阶段的结果是设计文档。开发人员在开始构建软件时使用此文档作为指南。

开发阶段

接下来，我们进入开发阶段。在这里，开发人员根据设计文档编写代码。他们创建软件的不同部分或模块。此阶段花费的时间最多，因为开发人员需要编写、调试和测试代码。

通常，不同的人或团队负责不同的部分。有时，当这些部分组合在一起时，可能会出现延迟。

测试阶段

开发完成后，我们开始测试阶段。质量保证 (QA) 团队检查软件以查找错误或错误。他们还确保软件符合原始要求。我们运行多种类型的测试，如单元测试、集成测试、系统测试和用户验收测试 (UAT)。

测试阶段对于确保产品正常运行非常重要。在传统的 SDLC 中，我们在构建整个系统后执行此操作，这使得修复问题变得更加困难和缓慢。

部署阶段

当软件通过所有测试时，它已准备好进入部署阶段。我们将系统移至生产环境，用户可以开始使用它。在传统的 SDLC 中，这通常涉及手动步骤，这可能会导致延迟或错误，尤其是对于大型系统。部署后，我们会密切关注软件以确保其按预期运行。

维护阶段

部署后，我们进入维护阶段。这包括修复任何错误、进行更新以及根据需要添加新功能。维护可分为三种类型:

• 纠正 − 修复错误
• 适应 − 适应环境变化
• 完善 − 改进或优化系统

传统的 SDLC 通常发现此阶段很难。由于流程的严格、循序渐进性质，进行更改可能很慢且成本高昂。

传统 SDLC 中的挑战

虽然传统软件开发生命周期 (SDLC) 对许多项目都很有效，但在当今快速发展的世界中它存在一些问题。这些问题主要来自于其循序渐进的过程以及开发和运营团队之间缺乏团队合作。

让我们来看看传统 SDLC 中的主要挑战:

孤立的团队

开发、测试和运营团队无法协同工作。他们之间缺乏清晰的沟通。当一个问题需要多个团队共同解决时，就会造成延误并减慢工作进度。

较长的开发周期

循序渐进的过程使项目耗时更长。我们必须先完成一个阶段，然后才能开始下一个阶段。由于反馈较晚，因此需要时间来响应变化或新需求。

手动流程

测试、部署甚至一些开发任务都是手动完成的，这意味着更多的人为错误。手动操作会减慢项目进度，并降低更新频率。

频繁出错

我们之所以发现错误很晚，是因为我们没有尽早进行集成和测试。在项目后期修复这些问题需要花费更多时间和成本。开发团队无法从测试阶段获得快速反馈。

难以适应变化

一旦开始开发，循序渐进的过程就很难添加新功能或进行更改。如果客户需求或市场趋势发生变化，我们可能不得不重新开始该过程。这会导致延迟和额外成本。

由于这些挑战，许多公司现在更喜欢 DevOps。DevOps 更快、更灵活，并有助于团队更好地协作。

DevOps 如何解决传统 SDLC 的挑战?

DevOps 有助于解决我们在传统 SDLC 中看到的许多问题。它更注重团队合作、自动化任务和定期提供更新。以下是 DevOps 如何解决我们在使用旧 SDLC 方法时面临的常见问题:

DevOps 打破孤岛

DevOps 将开发、运营和 QA 团队聚集在一起。团队从一开始就一起工作。这意味着更好的沟通和共享工作。我们看到的延迟更少，问题得到更快的解决。

缩短开发周期

DevOps 使用持续集成 (CI)和持续交付 (CD)。这有助于我们更频繁地构建和测试功能。更新以更小、更频繁的部分交付。它为我们提供更快的反馈，并让我们更快地发布新版本。

自动化流程

自动化是 DevOps 的关键。它涵盖测试、部署甚至管理基础设施。我们使用自动化测试和管道，因此我们不必手动完成许多工作。这样可以减少错误并加快工作速度。

借助基础设施即代码 (IaC)等工具，我们可以自动设置和管理基础设施。它可以帮助我们轻松发展和维护系统。

减少错误

通过自动化测试和持续集成，我们可以尽早发现问题。由于我们经常测试和集成代码，因此错误不会持续很长时间。我们会在它们成为大问题之前修复它们。

我们还使用监控工具来监视系统，这有助于我们在用户注意到问题之前解决问题。

轻松适应变化

DevOps 非常灵活。当出现新需求或客户需求时，它可以帮助我们快速调整。通过持续交付，我们可以添加小的更改、测试它们并快速发布它们。我们不需要重新启动整个流程。这使得我们更容易及时了解市场趋势和客户反馈。

简而言之，DevOps 改变了我们开发软件的方式。它专注于自动化、团队合作和持续改进。这有助于我们更快地完成项目，减少错误，并更好地适应变化。

传统 SDLC 与 DevOps

下表重点介绍了传统 SDLC 与 DevOps 的区别 −

此比较突出了 DevOps 如何通过鼓励协作、自动化和灵活性来克服传统 SDLC 的局限性，从而实现更快、更高效的软件交付。

结论

在本章中，我们研究了传统的软件开发生命周期 (SDLC)。我们强调了它存在的问题。然后，我们探讨了 DevOps 如何帮助解决这些问题。

从严格的流程转变为灵活的工作方式使事情变得更好。它帮助我们尽早发现错误并更频繁地进行测试。这样，我们可以提高产品质量。最后，使用 DevOps 改变了软件开发。它使流程更快、响应更快。这在我们瞬息万变的技术世界中带来了更好的结果。

DevOps - 历史

DevOps 旨在使软件交付和运营变得更好、更快。在本章中，我们将了解 DevOps 的历史。我们将看到它如何从早期的软件开发实践开始，成为现代 IT 和软件工程的重要组成部分。

我们将研究帮助塑造 DevOps 的不同阶段。我们将讨论 DevOps 实践是如何开始的、其历史上的重要里程碑，以及这些变化如何改变了组织交付软件的方式。

历史背景

随着时间的推移，软件开发发生了很大的变化。起初，我们使用传统的 SDLC，它提供了一种逐步开发软件的方法。当项目简单且可预测时，它效果很好。

但随着软件变得越来越复杂，这种旧模式就不那么好了。我们需要更快的结果、更好的团队合作和灵活性。因此，敏捷 和后来的 DevOps 等新方法应运而生，帮助解决了这些问题。

敏捷开发的兴起

21 世纪初，敏捷宣言 改变了我们对软件开发的看法。敏捷带来的理念注重灵活性、与客户密切合作以及一点一点取得进展。

与传统的 SDLC 不同，Scrum 和 Kanban 等敏捷方法让团队在项目期间(而不是项目结束后)获得反馈并进行改进。这有助于我们快速适应变化。敏捷还为DevOps铺平了道路，从而进一步改善了团队合作和自动化。

软件系统日益复杂

随着企业开始更多地依赖软件，事情变得更加复杂。我们必须处理云计算、微服务和分布式系统。这让我们对如何开发、部署和管理软件有了不同的看法。

软件现在有许多相互连接的部分，需要频繁更新。使用旧方法扩展应用程序以处理更多用户变得困难。

对于移动和 Web 应用程序快速交付新功能的需求更大。 全球竞争让我们能够交付更快、更可靠的软件。

传统 SDLC 的挑战

当项目规模较小且简单时，传统 SDLC 效果很好。但它难以满足现代软件开发需求。

• 不灵活 − 一旦开发开始，就很难做出更改。
• 反馈缓慢 − 发现问题需要很长时间，因为测试要晚得多。
• 孤立的团队 − 开发人员、测试人员和操作人员之间交流不足，导致沟通问题。
• 手动工作 − 测试、部署和管理基础设施等工作都是手动完成的，导致更多错误。
• 难以处理变化 − 当需求发生变化时，成本很高，有时需要我们重新开始项目。

这些问题表明，我们需要更灵活、促进更好的团队合作和使用更多自动化的方法。这导致了 DevOps 的兴起。

DevOps 的出现

在 2000 年代后期，我们看到了 DevOps 的兴起。它的出现是因为我们需要更快更好地交付软件。开发和运营团队之间存在很大差距。这通常会减慢传统 SDLC 中的项目进度。

通过 DevOps，我们试图将这些团队聚集在一起。我们使用了更多的自动化并专注于持续交付。主要思想是将开发、测试和运营结合成一个顺畅的过程。这有助于加快软件交付速度，同时仍保持高质量。

DevOps 实践的早期采用

当 DevOps 开始发展时，许多公司都看到了巨大的改进。Google、Netflix 和 Amazon 等大公司很快就采用了 DevOps。他们使用自动化和CI 管道来加快开发速度。

我们使用自动化来处理测试和部署等无聊的任务。这使事情变得更快，错误更少。借助基础设施即代码 (IaC)，团队可以使用代码管理和设置基础设施。它使扩展更容易，环境更一致。

CI/CD 管道帮助公司更频繁、更自信地发布更新。我们还专注于监控和获得快速反馈。这有助于我们更快地发现和修复生产中的问题。

DevOps 思想领袖的影响

得益于DevOps 思想领袖，DevOps 也快速发展。他们通过书籍、演讲和领导社区来分享自己的想法。

• Gene Kim，《凤凰计划》和《DevOps 手册》的合著者，让 DevOps 流行起来。他讲故事并进行研究，以展示 DevOps 对 IT 团队的实用性。
• 《持续交付》的合著者>Jez Humble，帮助许多公司了解了为什么 CI/CD 很重要以及如何使用它。
• Patrick Debois 经常被称为"DevOps"一词的提出者。他帮助组织了早期的 DevOps 活动，并创办了 DevOps Days。
• Nicole Forsgren 因其撰写的 DevOps 现状报告 而闻名，她为我们提供了有关 DevOps 如何改善业务绩效的有用数据。

这些领导者塑造了 DevOps，并为我们提供了我们至今仍在使用的最佳实践。

主要科技公司对 DevOps 的采用

当大型科技公司采用 DevOps 时，它展示了它在大规模上的效果。Google、Amazon 和 Netflix 等公司是首批使用 DevOps 的公司之一。他们使用自动化和持续交付来更快地进行创新并提高可靠性。

• Google通过其站点可靠性工程 (SRE)运用了 DevOps 理念。它将软件工程和运营结合在一起，以确保服务的可靠性。
• Amazon以使用 DevOps 来扩大其运营而闻名。他们从发布大型版本转向小规模、持续更新。这一变化帮助亚马逊满足了巨大的需求，同时更快地交付了新功能。
• Netflix使用 DevOps 构建了一个强大、可扩展的系统。他们使用了持续交付、微服务和自动化。他们甚至制作了一个名为Chaos Monkey的工具来测试他们的系统强度，这成为了他们 DevOps 战略中一个著名的一部分。

这些大公司的成功案例让更多企业采用了 DevOps。他们表明，DevOps 不仅是可能的，而且是现代软件开发的必需品。

结论

总之，我们可以说 DevOps 改变了开发和运营团队的合作方式。它通过带来自动化、持续交付和共同责任文化，解决了旧工作方式中的许多问题。DevOps 有助于缩小这些团队之间的差距。它使软件交付更快、更可靠。这提高了速度和质量。

展望未来，AI、GitOps 和 DevSecOps 等趋势将使 DevOps 变得更好。这些趋势将帮助 DevOps 应对现代软件系统日益复杂的问题。

DevOps - 架构

在当今快速发展的软件开发世界中，我们看到通过 DevOps 架构将开发和运营结合起来对组织非常重要。这种方法有助于我们更好地协作，简化流程，并让我们快速交付高质量的软件。

在本章中，我们将介绍 DevOps 架构的基本部分。我们将讨论其主要原则、关键部分以及帮助我​​们使用它的工具。我们将讨论 DevOps 架构如何允许持续集成和持续交付 (CI/CD)、基础设施即代码 (IaC) 和监控等实践。所有这些都有助于我们创建更灵活、更快速的开发环境。

什么是 DevOps 架构?

DevOps 架构是一个混合了开发和运营实践的框架。它帮助我们创建一种更顺畅、更具合作性和更高效的软件交付方式。我们专注于打破团队之间的障碍。我们整合了软件开发生命周期 (SDLC) 的不同步骤。这有助于改善沟通、自动化和持续改进。

通过使用 敏捷 和精益方法的理念，DevOps 架构让我们能够快速响应市场需求。我们可以更快地提供新功能，并保持软件的高质量。

DevOps 架构的关键组件

以下是 DevOps 架构的关键组件 −

• 持续集成 (CI) − CI 是一种实践，我们每天多次自动将来自许多贡献者的代码更改合并到一个共享位置。此过程可帮助我们及早发现和修复问题。它使我们的软件变得更好。
• 持续交付 (CD) − CD 建立在 CI 之上。它确保组合后的代码始终可供使用。这样，我们可以快速可靠地发布新功能和修复。它帮助我们快速获得反馈并改进。
• 基础设施即代码 (IaC) − IaC 是通过代码管理和设置我们的基础设施。我们不是手动完成的。这样，我们可以自动、一致且重复地设置我们的基础设施。它减少了错误并加快了流程。
• 微服务架构 − 这种设计意味着将我们的应用程序分解为更小的服务。这些服务并非紧密相连。我们可以自行开发、部署和扩展它们。微服务为我们提供了更大的灵活性。它们让我们可以在不停止整个系统的情况下处理不同的部分。
• 自动化工具 − 自动化在 DevOps 架构中非常重要。我们使用 Jenkins、Ansible 和 Terraform 等工具来自动化任务。这些包括测试、部署和管理设置。这让我们的团队可以专注于更重要的工作。
• 监控和日志记录 − 我们需要一直监控我们的应用程序和基础设施。这是保持性能和可靠性的关键。监控工具收集数据和指标。日志记录工具收集详细的事件信息。这有助于我们快速发现和解决问题。
• 协作和沟通 − 开发和运营之间的良好团队合作是 DevOps 架构良好运行的关键。我们使用 Slack、Jira 和 Confluence 等工具来帮助我们沟通和管理项目。这样，在开发过程中，每个人都保持一致并了解情况。
• 安全性 (DevSecOps) − 我们通过 DevSecOps 将安全性添加到 DevOps 流程中。这确保了安全步骤是开发每个阶段的一部分。这样，我们就可以尽早发现问题并保持合规。我们这样做不会减慢交付速度。

DevOps 架构的核心原则

DevOps 架构的核心原则对于创建以团队为中心且有效的软件开发环境非常重要。这些原则有助于增强团队合作并使流程更容易。它们还支持持续交付和良好的反馈监控。

遵循这些原则可使组织使其开发工作流程更顺畅。他们还可以提高软件质量并更快地响应市场需求。以下是 DevOps 架构关键原则的摘要 −

DevOps 示例分步说明

为了展示典型的 DevOps 工作流程如何工作，让我们看一个电子商务应用程序的示例。此应用程序想要添加新功能。它想要为产品创建一个推荐系统。以下是 DevOps 流程的发生方式:

步骤 1:规划和需求收集

首先，开发团队与利益相关者合作。他们收集推荐系统的需求。他们讨论用户的期望、技术需求和目标。此步骤对于设置下一步开发工作非常重要。

步骤 2:设计架构

收集需求后，团队设计新功能的架构。他们选择微服务架构。这样，推荐系统就可以独立运行，而不依赖于主应用程序。设计还包括如何存储数据和连接当前服务。

步骤 3:开发

接下来，开发人员开始编写推荐系统代码。他们将任务分解并分配给不同的团队成员。他们使用 Git 等版本控制系统来共同管理代码更改。每个开发人员都在不同的分支上工作。这使他们可以同时工作而不会出现问题。

步骤 4:持续集成 (CI)

当开发人员将他们的代码更改提交到存储库时，Jenkins 等 CI 工具会自动开始构建。CI 流程运行测试以检查新代码是否与旧代码配合良好。如果任何测试失败，开发人员会立即收到警报以解决问题。

第 5 步:持续交付 (CD)

代码通过所有测试后，将进入持续交付管道。此管道会自动部署到暂存环境以进行更多测试。在此环境中，将运行更多自动化测试。这些测试包括集成和性能测试，以查看该功能在不同情况下的工作方式。

第 6 步:部署

在暂存环境中测试成功后，推荐系统即可上线。团队使用 Ansible 或 Terraform 等工具将新功能部署到生产环境中。他们密切关注部署情况，以确保它不会干扰现有服务。

第 7 步:监控和反馈

推荐系统上线后，监控工具会跟踪其性能和用户参与度。它们收集响应时间、系统负载和用户交互等指标。用户的反馈有助于检查该功能的有效性并找到改进方法。

第 8 步:持续改进

使用指标和用户反馈，开发团队找到改进方法。他们可能会发现推荐算法需要改进，或者新功能可以帮助改善用户体验。这将启动新的规划会议，开发周期再次开始。这使得应用程序不断发展以满足用户需求。

DevOps 工具链

在我们的 DevOps 工具链中，我们有许多工具可以帮助软件开发的不同阶段。这些工具帮助我们协同工作、自动化任务并提高效率。这使我们能够快速可靠地交付优质软件。当我们一起使用这些工具时，我们可以创建一个顺畅的工作流程。

下表总结了我们在 DevOps 中常用的不同类型的工具 −

结论

在本章中，我们研究了它的基本思想、关键部分以及它随着时间的推移是如何变化的。我们首先定义了 DevOps 以及它在今天的重要性。我们讨论了核心思想，例如协同工作、自动化任务以及持续集成和持续部署 (CI/CD)。这些想法有助于我们很好地使用 DevOps。我们还查看了 DevOps 工具链中的工具。

DevOps - 生命周期

有了良好的 DevOps 策略，我们可以改进工作，更快地推出产品，并确保软件更可靠。在本章中，我们将介绍 DevOps 生命周期。我们将解释规划、开发、部署和运营等阶段。我们还将了解获得反馈如何帮助我们改进每个阶段。在此过程中，我们将分享使 DevOps 生命周期更好地工作的最佳实践。

什么是 DevOps 生命周期?

DevOps 生命周期是一个持续的过程，我们将整个软件交付流程中的开发和运营工作整合在一起。它有规划、开发、部署、运营和反馈等阶段。这些阶段相互联系。这有助于我们更好地作为一个团队工作，自动执行任务，并更快、更可靠地发布。

DevOps 生命周期的各个阶段

拥有清晰的 DevOps 生命周期有助于我们顺利交付软件，并能够随着需求的增长而增长。以下是 DevOps 生命周期的关键阶段 −

• 规划和设计 − 我们定义需求并规划解决方案。
• 开发 − 这是我们编码、控制版本和运行自动化测试的地方。
• 部署 − 我们使用持续集成和交付。我们还将基础设施作为代码来处理。
• 运营 − 在这里，我们监控、管理问题并提高性能。
• 反馈 − 我们通过指标和用户的定期反馈来改进工作。

第 1 阶段:规划和设计

规划和设计阶段是良好 DevOps 设置的主要基础。这意味着了解业务目标、定义系统需求和设计基础设施。此外，选择正确的工具也很重要。此步骤可确保我们的 DevOps 管道符合项目的技术和运营需求。

需求收集

在此步骤中，团队收集并编写功能性和非功能性需求 −

• 业务需求 − 主要目标是什么?
• 技术要求 − 需要哪些功能或系统链接?
• 安全性和合规性 −我们应该遵循哪些规则或安全检查?

解决方案架构

在这里，我们计划如何构建应用程序。重点是扩展和强度 −

• 将应用程序分解为微服务或小部分。
• 规划数据如何在服务和其他系统之间移动。
• 查找要链接的第三方服务或 API。

基础设施设计

此步骤显示我们将如何设置和管理环境 −

• 云与本地 − 我们选择基础设施的位置(如 AWS、Azure 或本地)。
• 可扩展性 −确保系统可以随着工作负载的增长而增长。
• 网络设计 − 规划网络、安全检查和负载平衡。

DevOps 工具选择

选择正确的工具是让流程更快、更简单的关键 −

• 版本控制 − 使用 Git 或 SVN 等工具进行代码管理。
• CI/CD 工具 − Jenkins、CircleCI 或 Travis CI 帮助我们实现持续集成和交付。
• 基础设施即代码 − Terraform 或 Ansible 等工具可自动设置和管理环境。

第 2 阶段:开发

开发阶段涉及以简单且团队友好的方式编写、管理和测试代码。我们专注于自动化工作并尽早发现问题。这有助于我们快速交付优质代码。

代码开发

代码开发是根据系统计划编写和改进应用代码 −

• 将任务分解为称为冲刺的较小部分。它有助于我们更快地完成任务。
• 团队一起工作。我们进行代码审查和结对编程以保持良好的代码质量。
• 我们遵循编码规则并尝试编写可再次使用的代码。

版本控制

版本控制系统帮助我们跟踪变更并顺利协作 −

• Git、SVN − 这些是管理代码版本的常用工具。
• 分支策略 − 我们使用 GitFlow 或功能分支等方法来分离不同的工作。
• 协作 − 许多开发人员可以在同一个项目上工作而不会产生问题。

持续集成

持续集成 (CI) 确保来自不同开发人员的代码被添加到一个共享位置 −

• 自动构建 − Jenkins、Travis CI 或 CircleCI 等工具可自动构建代码。
• 频繁集成 − 开发人员经常添加他们的代码以便尽早发现问题。
• 构建验证 − 我们确保新代码不会破坏现有系统。

自动化测试

自动化测试可帮助我们检查代码是否运行良好并减少错误 −

• 单元测试 − 我们逐一测试应用程序的小部分。
• 集成测试 − 我们确保应用程序的不同部分能够很好地协同工作。
• 测试自动化工具 − Selenium、JUnit 或 PyTest 等工具可帮助我们自动测试。

第 3 阶段:部署

部署阶段是我们将代码从开发环境移至生产环境的阶段。此阶段在 DevOps 生命周期中非常重要。我们使用不同的工具和方法来确保代码快速且无问题地送达用户。

持续交付

在持续交付中，我们确保代码始终可以上线。我们会自动对其进行测试。每次更改后，我们都可以部署代码。

我们的主要目标是随时部署代码。我们可以更频繁地向用户发布更改。这有助于我们尽早发现错误。

基础设施即代码

基础设施即代码 (IaC) 意味着我们使用代码来管理和设置基础设施，而不是手动进行。它使创建和管理服务器、数据库和网络变得容易。

我们编写脚本来设置服务器和存储等所有内容。我们使用 Terraform 或 Ansible 等工具来自动执行任务。这节省了我们的时间并防止了错误。

配置管理

配置管理帮助我们确保所有系统都以相同的方式设置。它还可以使系统随着时间的推移保持一致。

我们跟踪对服务器或系统所做的所有更改。Chef、Puppet 和 Ansible 等工具帮助我们管理设置。这使得修复问题变得容易，因为我们知道发生了什么变化。

部署管道

部署管道是一个逐步的过程，代码从开发到生产都遵循该过程。它包括构建、测试和部署等所有阶段。

我们自动化每个阶段以减少手动工作。开发人员将代码推送到管道，系统完成剩下的工作。管道帮助我们快速部署，并且不会出错。

第 4 阶段:运营

在运营阶段，我们专注于保持应用程序平稳运行。我们监控系统并管理事件。我们的目标是确保一切正常高效地运行。

监控和日志记录

监控和日志记录帮助我们观察系统的运行情况。我们跟踪重要指标和日志以快速发现问题。

我们使用工具检查服务器的运行状况和性能。我们收集日志以查看系统中发生了什么。这有助于我们在问题影响用户之前发现它们。

事件管理

当出现问题时，我们需要快速处理。事件管理是关于快速解决问题并减少停机时间。

我们有一个报告和响应事件的流程。当事件发生时，团队成员知道他们的工作。我们从每个事件中吸取教训，以防止将来再次发生。

容量规划

容量规划帮助我们决定应用程序需要多少资源。我们确保我们有足够的服务器和存储空间供用户使用。

我们查看过去的使用情况以预测未来的需求。我们调整资源以避免速度变慢或崩溃。这样，我们就可以为用户提供良好的体验。

性能优化

性能优化是关于让我们的应用程序运行得更快、更好。我们找到提高速度和效率的方法。

我们搜索系统中的瓶颈并修复它们。我们测试不同的设置以查看哪种设置最有效。我们的目标是通过快速响应让用户满意。

第 5 阶段:反馈和改进

在反馈和改进阶段，我们专注于从流程中学习并使其变得更好。我们希望通过获得持续反馈和定期检查来改进我们的工作和结果。

持续反馈循环

持续反馈循环帮助我们定期收集用户和团队成员的意见。

每次部署或重大变更后，我们都会征求反馈。用户洞察帮助我们了解哪些有效，哪些无效。我们根据此反馈更改流程以获得更好的结果。

回顾会议

回顾会议对于思考我们的工作很重要。我们在每个冲刺或项目后举行这些会议。团队成员分享哪些进展顺利以及我们可以改进的地方。我们创建行动项目以在下一个周期解决问题。

数据驱动的决策

数据驱动的决策帮助我们根据事实和数字做出选择。我们查看性能数据来指导我们的行动。这样，我们减少了猜测并获得更好的结果。我们跟踪关键绩效指标 (KPI) 来衡量我们的成功。

迭代开发

迭代开发让我们一点一点地改进我们的产品。我们以小周期工作以更频繁地发布更新。每个周期都建立在上一个周期的基础上，改进功能。这种方法帮助我们快速响应变化和用户需求。

结论

在本章中，我们研究了 DevOps 生命周期的关键部分。这包括规划、开发、部署、运营、反馈和改进。我们讨论了自动化、协作和数据驱动的决策等实践的重要性。这些实践有助于我们简化流程并提高产品质量。

当我们使用这些实践时，我们的团队可以更好地工作。我们可以快速响应用户需求并不断改进我们的工作流程。采用 DevOps 生命周期有助于我们更快地交付高质量的软件。这为用户带来了更多价值，并使我们的开发过程更加成功。

DevOps - 工具

在本章中，我们将介绍团队在 DevOps 生命周期的各个阶段使用的不同 DevOps 工具。我们将探索版本控制、持续集成、持续交付、基础设施即代码和配置管理的工具。我们还将介绍用于监控、容器化和云平台的工具。我们将了解这些工具的作用、它们如何提供帮助以及如何设置它们以改进 DevOps 流程。

在本章结束时，您将对支持 DevOps 的主要工具以及它们如何帮助软件项目取得成功有一个很好的了解。

什么是 DevOps 工具?

DevOps 工具是帮助我们自动化和管理 DevOps 生命周期不同部分的软件。这些工具让开发和运营团队更好地合作。它们有助于加快我们交付应用程序的速度并确保我们保持高质量。DevOps 工具可以做很多事情。它们有助于版本控制、持续集成、部署、监控和管理基础设施。

DevOps 工具涵盖从规划和开发到部署和监控的所有内容。这些工具使团队之间的沟通和合作变得更加容易。它们自动执行我们经常执行的任务，从而减少错误并节省时间。

DevOps 工具的重要性

DevOps 工具很重要，因为它们使软件开发和交付更快、更可靠。它们帮助我们处理复杂的系统，同时保持部署快速稳定。如果没有这些工具，我们将面临速度减慢和手动操作带来的更多错误。

DevOps 工具帮助我们自动化测试、部署和监控等工作。它们使团队更容易合作。我们得到持续的反馈，这意味着我们可以更快地改进。此外，DevOps 工具有助于保持我们的代码质量，并减少应用程序在生产中运行时的停机时间。

顶级 DevOps 工具

下表重点介绍了顶级 DevOps 工具及其类别 −

结论

在本章中，我们研究了版本控制、持续集成、持续交付、基础设施即代码、配置管理、监控和云平台等重要领域的不同 DevOps 工具。

我们讨论了 Git、Jenkins、Terraform、Docker 和 AWS 等工具。我们解释了它们的功能、优势以及如何使用它们。这些工具帮助我们自动化任务、更好地协作并提高团队效率。当我们使用这些工具时，它可以简化我们的工作流程、提高生产力并帮助更快、更可靠地交付软件。

DevOps 工具常见问题解答

在本节中，我们收集了一组有关 DevOps 工具的常见问题解答，并附上答案 –

1. 哪种 DevOps 工具最好?

"最佳"DevOps 工具取决于我们的项目需要什么。一些常见的工具是用于 CI/CD 的 Jenkins、用于版本控制的 Git、用于容器的 Docker、用于管理容器的 Kubernetes 和用于配置的 Ansible。在选择时，我们应该考虑功能、它的扩展能力、社区支持以及它如何与我们当前的工具配合使用。

2. Jira 是 DevOps 工具吗?

Jira 主要用于项目管理和跟踪问题。但我们可以将其与其他 DevOps 工具连接起来，以帮助管理整个开发过程。虽然它不完全是一个核心的 DevOps 工具，但它仍然有助于我们规划、跟踪和协调 DevOps 设置中的任务。

3. DevOps 是一个工具吗?

不，DevOps 不是一个单一的工具。它更像是一套帮助开发和运营团队更好地合作的想法和方法。它是关于使用不同的工具和技术来自动化任务并加快软件开发和交付速度。

4. Jenkins 有什么用?

Jenkins 主要用于 CI/CD。它有助于自动化构建、测试和部署软件的过程。我们可以将它与版本控制系统、测试工具和部署环境连接起来。这有助于建立顺畅的持续交付管道。

5. Docker 是 CI/CD 工具吗?

Docker 本身不是 CI/CD 工具，但它是 CI/CD 管道中非常重要的一部分。它帮助我们将应用程序及其依赖项打包到容器中。这确保了开发、测试和生产过程中的环境相同。像 Jenkins 这样的 CI/CD 工具使用 Docker 来构建、测试和部署在容器中运行的应用程序。

DevOps - 自动化

在本章中，我们将研究 DevOps 中自动化的不同方面。我们首先解释 DevOps 中的自动化是什么意思。然后，我们将讨论不同类型的自动化以及它们如何帮助我们。我们将涵盖基础设施自动化、管理配置和持续集成等主题。测试和监控自动化也将成为其中的一部分。

此外，我们将分享一些采用自动化的最佳实践，讨论我们面临的挑战，并考虑安全性以确保环境安全。

DevOps 中的自动化是什么?

DevOps 中的自动化是现代软件开发的关键部分。它帮助我们加快工作流程，减少错误，并使我们的系统更高效。通过自动化代码部署、管理基础设施和测试等任务，我们可以专注于更重要的事情，例如改进产品和解决更大的问题。

DevOps 自动化让我们能够更快、更高质量地交付软件。它还能在生产中保持一致性和可靠性。

自动化类型

DevOps 中的自动化可以分为几种主要类型。每种类型都有其用途，有助于使我们的工作流程更加顺畅。通过了解这些类型，我们可以制定符合我们需求的良好自动化策略。

基础设施自动化

基础设施自动化意味着我们可以自动化服务器、网络和基础设施其他部分的设置、配置和管理。这有助于我们快速一致地部署资源。

• 配置管理 − 配置管理确保我们基础设施中的所有系统都正确设置并长期保持这种状态。我们使用 Ansible、Puppet 和 Chef 等工具来实现这一点。
• 基础设施即代码 (IaC) − IaC 让我们能够使用代码管理基础设施。我们可以对其进行版本控制并像应用程序代码一样进行部署。这为我们提供了更快的速度和更大的灵活性。在这里，我们通常使用 Terraform 和 AWS CloudFormation 等工具。

部署自动化

部署自动化使将应用程序部署到不同环境的过程变得更加容易。这有助于我们更快、更可靠地发布。

• 持续集成 (CI) − 持续集成是指我们自动测试代码更改并将其合并到共享存储库中。Jenkins、Travis CI 和 GitLab CI 等 CI 工具可帮助实现这一点。
• 持续交付 (CD) − 持续交付建立在 CI 之上。它确保代码更改已准备好发布到生产中。这有助于我们更快地交付新功能。

测试自动化

测试自动化帮助我们使测试过程更加高效和有效。这使我们能够更快地获得反馈并提高软件质量。

• 单元测试 − 单元测试会单独检查应用程序的各个部分。这可确保每个部分都能正常工作。
• 集成测试 − 集成测试可确保不同的模块或服务能够正确协同工作。这对于发现组件交互方式中的问题非常重要。
• 端到端测试 − 端到端测试会从头到尾检查整个应用程序。这可确保系统在实际情况下按预期运行。要点包括:

监控和日志自动化

监控和日志自动化帮助我们关注系统的性能和可靠性。这让我们能够在问题变得严重之前解决问题。

• 警报 − 警报系统会立即通知团队有关问题或故障的信息。这有助于我们快速应对潜在问题。
• 分析 − 分析自动化涉及收集和分析来自应用程序和基础设施的数据。这为我们提供了更好的决策见解。

DevOps 自动化的挑战和最佳实践

下表重点介绍了 DevOps 自动化中的挑战和最佳实践 −

结论

在本章中，我们研究了自动化在 DevOps 中的重要作用。我们重点介绍了基础设施、部署、测试和监控自动化等不同类型。我们讨论了成功使用的最佳实践。从小处着手并鼓励团队合作是其中一些实践。我们还讨论了我们面临的挑战，例如复杂性和安全问题。

通过充分利用自动化，我们可以提高生产力。我们可以减少错误并更快地交付高质量的软件。这有助于组织快速响应市场需求并在快速变化的技术世界中保持竞争力。

DevOps - 工作流程

阅读本章以了解DevOps 工作流程。在这里，您将了解拥有清晰的工作流程为何如此重要。我们还将研究从规划和编码到部署和运营的每个步骤。

在本章结束时，您将了解如何创建 DevOps 工作流，以改善团队的协作方式并提高效率。

循序渐进的 DevOps 工作流

任何 DevOps 工作流的第一步都是规划和设计。我们需要一个强大的基础来确保开发、测试和部署的一切顺利进行。对于电子商务网站，此部分为整个项目设定了路径。

步骤 1:定义项目目标和目的

我们首先为电子商务平台设定明确的目标。例如，为客户提供流畅的购物体验，确保其能够在大型促销期间处理高流量。

步骤 2:收集和分析需求

接下来，我们收集业务和技术需求:

• 业务需求 − 易于使用的界面、安全的付款方式和快速结账。
• 技术需求 − 支持不同的付款方式、与库存系统链接，并确保其适合移动设备。

步骤 3:设计解决方案架构

我们设计一个可扩展且安全的架构:

• 前端 − 使用 React 或 Angular 等框架的 Web 应用程序。
• 后端 −使用 Node.js、Python 或 Java 构建的微服务。
• 数据库 − 选择 SQL(如 PostgreSQL)或 NoSQL(如 MongoDB)。
• 云基础设施 − 使用 AWS、GCP 或 Azure 进行托管和扩展。

步骤 4:选择合适的 DevOps 工具

我们选择符合项目需求的工具:

• 版本控制 − 使用 GitHub 管理代码。
• CI/CD − Jenkins 用于设置持续集成和交付。
• 基础设施即代码 (IaC) − Terraform 自动管理云资源。

在 DevOps 的开发阶段，我们专注于编写和集成代码。此阶段对于确保电子商务网站中的产品目录、购物车和支付系统等功能顺利开发非常重要。我们使用自动化来减少错误并加快速度。

第 5 步:使用版本控制开发代码

我们在与团队合作时使用Git等版本控制系统 (VCS) 来管理代码。在电子商务平台上，开发人员可能会处理不同的工作，例如结帐流程或产品列表。Git 让他们可以一起工作而不会弄乱彼此的更改。

• 分支 − 开发人员为每个功能(如 checkout-feature 或 search-bar-update)创建单独的分支。这样，他们可以独立工作而不会破坏主代码。
• 合并 − 一旦功能完成并测试完毕，我们就会将其合并回主代码

第 6 步:实施持续集成实践

持续集成 (CI) 可帮助我们保持代码整洁，并防止在合并代码时出现大问题。当开发人员推送更改时，Jenkins 或 CircleCI 等工具会自动构建和测试代码。

例如，当开发新功能(如 "add-to-cart")时，CI 会确保它与其余代码相适应，不会造成问题。

第 7 步:编写自动化测试

我们编写自动化测试以尽早发现错误并确保我们的代码运行良好。在电子商务网站中，测试可能会检查产品搜索、将商品添加到购物车或完成购买等内容。

• 单元测试 − 测试代码的一小部分，例如确保支付模块正确计算税金。
• 集成测试 −检查不同部分(如登录和结帐)是否能很好地协同工作。
• 端到端 (E2E) 测试 − 模拟用户的操作，如选择产品、将其添加到购物车和结帐。

步骤 8:进行代码审查

代码审查有助于提高代码质量。在我们合并新功能(如产品推荐引擎)之前，高级开发人员或同行会检查代码以发现问题并确保其遵循最佳实践。

在 DevOps 工作流中，测试阶段可确保平台稳定且运行良好。我们专注于测试电子商务网站的不同部分，以确保其运行顺畅并为用户提供良好的购物体验。

步骤 9:执行单元测试

单元测试检查小段代码，如函数或组件。在电子商务网站中，这可能意味着检查诸如如何计算总价或检查折扣代码之类的内容。

确保平台的每个部分都能正常工作。例如，测试根据客户居住地计算运费的功能。

步骤 10:执行集成测试

集成测试检查不同模块是否能很好地协同工作。在电子商务网站中，这可能意味着确保支付网关和结帐流程正常工作，以及在有人购买商品后库存得到更新。

确保不同的服务(如支付和订单管理)可以毫无问题地协同工作。例如，测试在购买商品并付款后库存数量是否会下降。

步骤 11:进行系统测试

系统测试检查整个平台，而不仅仅是平台的一部分。我们进行测试，以查看在实际情况下一切是否正常运行。

测试整个系统，以确保所有功能都能正常工作。例如，模拟用户浏览网站、将商品添加到购物车并购买商品，检查是否存在加载缓慢或付款错误等问题。

第 12 步:进行验收测试

验收测试检查平台是否满足业务需求并为用户服务。这通常是网站上线前的最后一个阶段。

确保系统满足业务目标。例如，测试用户是否可以搜索产品、将其添加到购物车并顺利结账。我们希望确保用户体验良好。

在部署阶段，我们为客户准备好电子商务网站。这涉及设置资源、部署应用程序以及确保一切运行良好。让我们分解一下关键步骤。

第 13 步:使用基础设施即代码来配置资源

我们使用基础设施即代码 (IaC)来设置我们电子商务网站所需的服务器和其他资源。这种方式可以轻松创建和管理基础设施，而无需手动操作。

IaC 帮助我们以相同的方式快速设置资源。我们可以轻松地在不同的地方复制我们的设置，例如开发和生产。我们可以使用 Terraform 或 Ansible 等工具在代码中定义我们的基础设施。

第 14 步:配置环境

接下来，我们为电子商务网站设置不同的环境。每个环境都有不同的工作。

• 开发 − 这是我们构建和测试新功能的地方。
• 准备 − 在这里，我们一起测试具有所有功能的站点，就像它将在生产中一样。
• 生产 − 这是客户购物的实时站点。

配置好这些环境可确保在上线之前一切正常。

第 15 步:部署应用程序

环境准备就绪后，我们将部署电子商务应用程序。此步骤将代码和功能移至生产环境，以便用户使用它们。

我们上传代码、设置数据库并检查所有服务是否正在运行。例如，当我们启动新的支付网关时，我们会对其进行部署，以便客户可以立即使用它。

第 16 步:实施持续交付管道

我们使用持续交付 (CD)管道来自动化部署过程。这有助于我们更快地发布新功能，并且风险更低。

每当我们更改代码时，CD 管道都会自动测试和部署这些更改。这意味着我们可以快速可靠地发布电子商务网站的更新，例如新产品功能或错误修复。

在运营阶段，我们专注于保持电子商务网站的良好运行。这意味着我们要监控性能、管理问题，并确保一切都安全并遵守规则。

步骤 17:监控应用程序和基础设施性能

我们需要观察电子商务网站的表现。这包括检查应用程序和基础设施。Prometheus 和 Grafana 等工具可帮助我们跟踪性能指标，例如页面加载时间、服务器运行状况和用户活动。通过监控这些指标，我们可以在问题影响客户之前发现它们。

步骤 18:管理事件和解决问题

即使我们尽了最大努力，问题仍然可能发生。当它们发生时，我们必须快速管理事件。例如，如果用户在结账时遇到问题，我们需要迅速采取行动，找出问题所在并进行修复。

步骤 19:优化资源利用率

我们希望充分利用我们的资源。这包括服务器、数据库和存储。为了优化资源利用率，我们:

• 扩展资源 − 我们根据流量大小添加或删除服务器。例如，在销售期间，我们可能需要更多服务器来处理额外的流量。
• 审查成本 − 我们检查是否在资源上花费过多，并寻找节省的方法。

这样，我们就可以保持网站运行良好而不会浪费金钱。

第 20 步:确保安全性和合规性

确保电子商务网站的安全非常重要。我们必须保护客户数据并遵守规则。以下是我们的做法:

• 定期安全审核 − 我们进行审核以查找和修复任何薄弱环节。
• 数据加密 − 我们使用加密技术来确保用户数据在进行交易时的安全。
• 合规性检查 − 我们确保网站符合 GDPR 等保护用户数据的规则。

在反馈和改进阶段，我们专注于根据用户的反馈和我们看到的数据来改进我们的电子商务网站。这有助于我们确保满足客户需求并始终改进我们的流程。

步骤 21:收集利益相关者的反馈

我们要求所有参与电子商务网站的人员提供反馈，包括客户、团队成员和业务合作伙伴。

步骤 22:根据反馈和见解迭代流程

我们收集反馈和数据分析，并使用它们来更改我们的流程。这意味着我们根据所学知识进行更新和改进。

我们经常更新我们的功能、修复错误并改善用户体验。例如，如果反馈显示移动用户难以浏览网站，我们可能会重新设计移动布局以使其更易于使用。

结论

在本章中，我们研究了 DevOps 工作流程的主要阶段。这些阶段包括规划和设计、开发、测试、部署、运营以及反馈和改进。我们在电子商务网站的背景下讨论了所有这些内容。

DevOps - 管道

在本章中，我们将解释什么是 DevOps 管道以及它们为何重要。我们还将研究 DevOps 管道的主要部分。这些部分包括源代码管理、持续集成 (CI)、持续交付 (CD)、部署策略和监控反馈。我们将帮助您设置 DevOps 管道。

什么是 DevOps 管道?

DevOps 管道是自动运行的流程。它们帮助我们进行软件应用程序的持续集成和持续交付 (CI/CD)。这些管道有一系列代码更改要经历的步骤。这从第一次开发开始，一直到在生产环境中部署。

DevOps 管道的主要目标是使软件开发生命周期更加顺畅。这有助于我们更快、更可靠地交付高质量的软件。

DevOps 管道的关键组件

DevOps 管道有几个协同工作的关键部分。它们帮助我们简化软件开发和部署过程。每个部分都很重要，以使管道运行良好且快速。

源代码管理

源代码管理 (SCM) 系统帮助我们跟踪和管理代码更改。它们确保我们拥有版本控制并允许开发人员之间的协作。

工具(如 Git、Subversion、Mercurial)用于源代码管理。关键功能包括版本控制、分支和合并策略、协作和代码审查

持续集成 (CI)

持续集成可自动将代码更改添加到共享位置。它帮助我们确保新代码顺利合并并在进入下一步之前进行测试。

持续交付 (CD)

持续交付以 CI 为基础，通过自动化我们将应用程序交付到测试和生产环境的方式。它确保代码始终可以部署。

部署

部署是将应用程序移至生产环境的过程。这是最终用户可以使用它的地方。良好的部署策略有助于我们减少停机时间并确保可靠性。

监控和反馈

监控工具帮助我们关注应用程序性能、用户操作和系统运行状况。反馈对于尽早发现问题和保持软件高质量非常重要。

监控和反馈的关键方面包括实时性能监控(如延迟和错误率)、日志记录和警报系统(以便尽早发现问题)以及用户反馈渠道(用于收集未来改进的想法)。

如何设置 DevOps 管道?

设置 DevOps 管道有几个步骤。这些步骤帮助我们自动化软件开发生命周期。下面是创建 DevOps 管道的指南，其中包含代码示例。

步骤 1:设置您的 DevOps 环境

首先，我们需要选择工具和技术。一些流行的源代码管理选择是 Git。对于持续集成和交付，我们可以使用 Jenkins 或 Travis CI。对于容器化，我们经常使用 Docker，对于编排，我们选择 Kubernetes。

选择工具后，我们需要在本地机器或服务器上安装软件。要安装 Docker，我们运行 −

sudo apt-get install docker-ce docker-ce-cli containerd.io

要在 Ubuntu 上安装 Jenkins，我们可以使用这些命令 −

sudo apt-get update
sudo apt-get install openjdk-11-jre
wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list
sudo apt-get update
sudo apt-get install jenkins

步骤 2:创建源代码存储库

接下来，我们创建一个源代码存储库。我们首先为我们的项目创建一个 Git 存储库。我们可以通过创建一个新目录并运行 git init 来做到这一点。以下是操作方法 −

mkdir my-app
cd my-app
git init

使用良好的分支策略也很重要。我们可以使用 git checkout -b feature/my-new-feature 等命令为功能、错误修复和发布创建分支。

步骤 3:实现持续集成

设置源代码管理后，我们实现持续集成 (CI)。我们首先配置 Jenkins 等 CI 工具。我们为项目创建一个新的 Jenkins 作业并将其连接到我们的 Git 存储库。

接下来，我们编写构建脚本来自动化构建过程。我们可能会创建一个名为 build.sh 的脚本，其中包含构建应用程序的命令。这是一个简单的例子 −

#!/bin/bash
echo "Building the project..."
# Add commands to build your application

我们还需要将自动化测试添加到我们的 CI 流程中，以便在每次代码提交时运行单元测试和集成测试。Jenkins 管道配置可能如下所示 −

pipeline {
   agent any
   stages {
      stage('Build') {
         steps {
            sh './build.sh'
         }
      }
      stage('Test') {
         steps {
            sh './run_tests.sh'
         }
      }
   }
}

第 4 步:实现持续交付

持续集成之后，我们实现持续交付 (CD)。我们在 Jenkins 或其他 CI/CD 工具中设置部署管道，以自动化部署。例如，我们可以像这样设置 Jenkins 管道 −

pipeline {
   agent any
   stages {
      stage('Deploy to Staging') {
         steps {
            sh './deploy_to_staging.sh'
         }
      }
      stage('Deploy to Production') {
         steps {
            input 'Approve Production Deployment?'
            sh './deploy_to_production.sh'
         }
      }
   }
}

我们还应该管理好环境配置。我们可以使用配置文件来处理不同的环境，如开发、暂存和生产。

第 5 步:容器化和编排

容器化是 DevOps 管道中的关键步骤。我们可以使用 Docker 创建一个定义应用程序环境的 Dockerfile。这是一个 Dockerfile 的简单示例−

FROM node:14
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

创建 Docker 映像后，我们使用 Kubernetes 管理容器。我们可以创建 YAML 格式的部署清单，例如 deploy.yaml −

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        ports:
        - containerPort: 3000

第 6 步:自动化部署

对于部署阶段，我们需要根据应用程序需求使用蓝绿部署、滚动更新或灰度发布(又名金丝雀发布)等良好策略。我们可以使用 Terraform 或 Ansible 等基础设施即代码 (IaC) 工具来自动化基础设施。一个简单的 Terraform 脚本可能如下所示 −

provider "aws" {
   region = "us-west-2"
}
resource "aws_instance" "app" {
   ami           = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

第 7 步:监控和日志记录

最后，我们需要设置监控和日志记录以保持应用程序健康。我们可以使用 Prometheus 和 Grafana 等工具来监控应用程序性能和系统健康状况。对于日志记录，我们可以使用 ELK Stack，它具有 Elasticsearch、Logstash 和 Kibana。基本的 Logstash 配置可能如下所示 −

input {
   file {
      path => "/var/log/my-app/*.log"
      start_position => "beginning"
   }
}
output {
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "my-app-logs-%{+YYYY.MM.dd}"
   }
}

结论

设置 DevOps 管道意味着我们选择正确的工具。我们配置环境并自动化构建、测试和部署应用程序的流程。通过遵循这些步骤并使用代码示例，我们可以为我们的项目创建强大而有效的 DevOps 管道。

DevOps 管道常见问题

在本节中，我们收集了一组有关 DevOps 管道的常见问题及其答案 –

1. DevOps 中的 CI/CD 管道是什么?

CI/CD 管道是软件开发和交付过程中自动发生的一系列步骤。我们有持续集成 (CI)，其中代码更改被构建、测试并添加到共享存储库。然后我们有持续交付 (CD)，其中构建和测试的代码被发送到不同的环境。CI/CD 管道帮助我们提高软件质量。它们使交付更快，让我们经常发布更新。

2.什么是 Jenkins 管道?

Jenkins 管道是 CI/CD 管道中按特定顺序运行的一组步骤。我们可以使用声明方式或脚本方式在 Jenkins 中定义管道。这让我们有机会进行自定义并保持灵活性。Jenkins 管道可以包含构建、测试、部署和监控应用程序的步骤。

3. Kubernetes 是 CI/CD 工具吗?

Kubernetes 本身不是 CI/CD 工具。但它在许多 CI/CD 管道中非常重要。Kubernetes 是一个帮助我们管理和扩展容器化应用程序的平台。它具有部署、扩展和自我修复等功能。这使得它非常适合自动化我们在 CI/CD 管道中部署和管理应用程序的方式。

DevOps - 好处

阅读本章，了解为什么越来越多的公司选择 DevOps 来解决他们在传统软件开发生命周期 (SDLC) 中面临的问题。我们将讨论 DevOps 如何帮助加快软件交付速度、提高质量和改善团队合作。我们还将看到哪些类型的公司转向 DevOps 以及它有助于解决的问题。最后，我们将讨论为什么 DevOps 现在对现代企业非常重要。

DevOps 有什么好处?

我们看到越来越多的公司转向 DevOps，因为它有助于解决旧方式带来的问题。他们希望速度更快、更好地合作并更快地发布他们的软件。在当今速度至关重要的快速市场中，DevOps 已成为公司的关键战略。

DevOps 有助于解决延迟、团队之间沟通不畅和反应时间慢等问题。此外，它仍能保持软件质量和可靠性。

以下是转向 DevOps 的好处 −

1.缩短上市时间

DevOps 帮助团队更快地开发软件，因此公司可以快速发布新功能、更新或错误修复。例如，亚马逊使用 DevOps 每 11.7 秒发布一次新代码。

CI/CD 管道通过自动化构建、测试和部署来提供帮助，从而减少手动工作并加快发布速度。

2. 更好的协作和沟通

DevOps 打破了开发、运营和测试团队之间的壁垒。每个人都分担责任。Slack、Jira 和 GitHub 等工具可帮助团队实时沟通，使工作更轻松、更快捷。这样，问题得到更快的解决，生产力也随之提高。

3. 更好的质量和可靠性

DevOps 使用自动化测试和监控，确保软件在整个过程中得到测试。例如，Netflix 使用"混沌工程"来测试其系统是否存在任何故障，从而提高其系统的可靠性。自动化可以尽早发现错误，因此生产中出现的问题更少。

4. 更频繁的部署

旧的开发模型每年只允许几次部署。但 DevOps 可以根据需要每天或每周进行多次部署。例如，Facebook 使用 DevOps 进行持续部署，以快速提供新功能。自动化的工作流程和测试确保频繁发布的版本是稳定的。

5. 可扩展性和灵活性

DevOps 可与 AWS、Google Cloud 和 Azure 等云服务配合使用。这些平台提供灵活的基础设施，可随着公司需求的增长而增长。基础设施即代码 (IaC) 可帮助团队通过代码管理其基础设施，从而使扩展更加容易。

6. 缩短恢复时间

DevOps 可帮助团队更快地发现和修复问题，从而缩短平均恢复时间 (MTTR)。例如，Etsy 使用 DevOps 将恢复时间从一小时缩短到几分钟。

Prometheus 和 Grafana 等监控工具提供有关系统健康状况的实时信息，使发现和修复问题变得更加容易。

7. 安全性改进

DevOps 引入了 DevSecOps，将安全实践尽早引入开发周期。自动安全测试可在软件发布之前发现漏洞。例如，Google 在其 CI/CD 管道中添加了安全检查，确保所有代码在生产之前都是安全的。

8.成本效率

DevOps 通过自动执行重复任务和减少手动工作来降低成本。它还可以优化资源，尤其是云基础设施，减少浪费并改善成本管理。

最终，企业采用 DevOps 是为了更快地发布、更好地进行团队合作和更稳定的系统。随着越来越多的公司使用云计算、微服务和容器，DevOps 现在已成为在当今科技世界中保持领先地位的关键。

传统 SDLC 中的挑战

下表重点介绍了在新时代的软件开发中遵循传统 SDLC 方法为何具有挑战性 −

倾向于切换到 DevOps 的组织类型

下表重点介绍了倾向于从传统 SDLC 过渡到 DevOps 的组织类型 −

结论

在本章中，我们研究了使用 DevOps 的好处。我们讨论了传统软件开发生命周期 (SDLC) 模型的问题。这些问题使组织需要更灵活的方法。

我们还讨论了喜欢转向 DevOps 的组织类型。其中包括科技初创公司和金融机构。他们都使用 DevOps 来提高效率、安全性并快速响应市场需求。通过使用 DevOps 实践，我们可以使我们的开发流程更加顺畅。我们可以帮助团队更好地协同工作。

DevOps - 用例

在本章中，我们将了解DevOps 的用例。我们将了解这些实践如何在现实世界中用于解决软件开发和 IT 运营中的常见问题。我们将研究基本的 DevOps 案例，例如持续集成和持续部署，以及微服务、安全集成 (DevSecOps) 和弹性监控等高级领域。

到本章结束时，您将清楚地了解主要的 DevOps 用例。您将看到它们带来的好处以及在复杂设置中应用 DevOps 时应对挑战的最佳方法。

DevOps 的常见用例

下表重点介绍了 DevOps 的一些常见用例 −

持续集成 (CI)

持续集成 (CI) 是一种 DevOps 方式，开发人员经常将他们的代码更改合并到共享存储库中。他们通常每天执行多次。每次集成都会触发自动构建和测试。这有助于尽早发现错误并提高快速反馈和代码质量。

示例 − 开发团队使用 Jenkins 来自动化 CI 任务。构建和测试从每次代码提交开始，确保只有无错误的代码才能进入主分支。

持续部署 (CD) 和持续交付

持续部署 (CD) 会在代码通过测试后立即自动将其发布到生产环境中。持续交付 将代码发送到暂存区，需要手动批准才能上线。两者都节省了手动工作并加快了发布过程。

示例 −一家采用微服务设置的公司使用 Kubernetes 进行自动化部署，允许频繁进行小规模更新且几乎不会造成中断。

基础设施即代码 (IaC)

基础设施即代码 (IaC) 允许团队使用代码而不是手动步骤来管理和设置基础设施。这带来了更多的自动化、一致性和轻松扩展。

示例 − 团队使用 Terraform 脚本来设置云基础设施。这让他们可以为开发、准备和生产创建相同的环境。

自动化测试和质量保证

自动化测试在 DevOps 中非常重要。它可以帮助团队通过在 CI/CD 管道中自动运行的测试来检查代码。这些工具和框架可确保代码更改不会破坏或添加新错误。

示例 − QA 团队使用 Selenium 对 Web 应用程序进行自动化 UI 测试。每次部署都会运行测试，确保所有更新都能使应用正常运行。

微服务和容器化

借助微服务，我们将应用拆分为更小的独立服务。每个服务都可以单独构建、部署和扩展。容器化通过将每个服务及其所需文件打包到小容器中来帮助微服务，确保它们以相同的方式在不同环境中工作。

示例 − 一家公司从大型单一架构(单片)转向使用 Docker 和 Kubernetes 的微服务设置。这让团队可以更新特定服务而不会影响整个应用。

监控和可观察性

监控帮助我们了解应用和基础设施的运行状况和性能。可观察性更深入。它让我们看到系统的行为方式，从而更容易修复问题并提高性能。总之，它们是保持系统平稳运行并为用户提供更好体验的关键。

示例 − 一家电子商务网站使用 Prometheus 进行监控，使用 Grafana 制作图表。DevOps 团队可以针对任何延迟或资源过度使用设置警报。

安全集成 (DevSecOps)

在 DevSecOps 中，我们在 DevOps 流程的每一步都添加了安全性。安全性不是我们只在最后检查的东西。我们在 CI/CD 管道中设置了自动安全检查和漏洞扫描。

示例 − 一家金融公司在其 CI/CD 管道中添加了 SonarQube 等静态代码分析工具。这可以在开发和测试阶段发现安全漏洞。

用例 1:为大型应用程序实施 CI/CD

在大型应用程序中，许多开发人员会快速更改代码，CI/CD 管道通过自动化代码构建、测试和部署来帮助我们。这有助于我们减少错误，并加快发布更新的速度。

示例 − 拥有数百万用户的社交媒体平台使用 Jenkins 进行 CI，使用 Spinnaker 进行 CD。他们自动化测试并缓慢推出新功能。通过这种方式，他们可以快速将更新投入生产，同时保持一切稳定和低风险。

用例 2:使用 IaC 和容器扩展基础设施

随着我们的应用程序的增长，手动扩展基础设施变得越来越困难。 基础设施即代码 (IaC) 和 容器化 通过自动化扩展过程为我们提供帮助。这使我们能够在代码中定义环境并快速部署它们。

示例 − 一家金融科技初创公司使用 AWS 和 Terraform 进行 IaC。这让他们能够在需求高涨时自动扩展资源。借助由 Kubernetes 管理的 Docker 容器，他们可以根据负载增加或减少服务。这有助于我们节省成本并提高绩效。

用例 3:确保 CI/CD 管道中的安全性和合规性

在规则严格的行业中，我们需要确保安全性和合规性是每次部署的一部分。DevSecOps 将安全检查添加到 CI/CD 管道中。这有助于我们尽早发现问题，并确保我们的应用程序在上线前遵守行业规则。

示例 − 一家医疗保健提供商通过在其管道中添加 SonarQube 和 Aqua Security 等工具来使用 DevSecOps。这些工具检查代码是否存在安全问题，以满足 HIPAA 规则。这确保了在部署之前每个代码更改都是安全的。

这些 DevOps 的真实示例向我们展示了 CI/CD、IaC 和 DevSecOps 如何帮助我们在复杂而繁忙的环境中提高可扩展性、效率和安全性。

结论

在本文中，我们研究了 DevOps 的主要用例。我们专注于持续集成 (CI)、持续部署 (CD)、基础设施即代码 (IaC)、自动化测试、微服务、监控和可观察性以及通过 DevSecOps 实现的安全性。

每个用例都展示了 DevOps 如何帮助我们使开发流程更顺畅。它还可以改善团队合作、软件质量和安全性。

DevOps - 利益相关者

利益相关者是关心项目成功的人或团体。他们的参与对于促进团队合作和协调我们的目标非常重要。这确保我们有效地实现开发和运营目标。

在本章中，我们将研究 DevOps 环境中的主要利益相关者。我们将探讨他们的角色、职责以及合作的重要性。我们将确定开发团队、运营、质量保证、安全团队和业务管理等利益相关者。我们将看到他们的互动如何帮助 DevOps 计划取得成功。

识别 DevOps 中的关键利益相关者

下表重点介绍了 DevOps 中的关键利益相关者及其在软件开发周期中的作用 −

DevOps 利益相关者之间的协作

在本节中，让我们讨论 DevOps 中的不同利益相关者在软件开发周期中如何相互协作。

沟通渠道

良好的沟通对于 DevOps 中的团队合作非常重要。建立清晰的沟通渠道有助于信息在团队之间轻松流动。这样，他们可以快速做出决策并更快地解决问题。

• 定期会议 − 每日站立会议、冲刺规划和回顾会议使所有团队保持一致。例如，混合团队每周举行一次会议，讨论项目进度和问题。这有助于他们快速做出更改。
• 即时通讯平台 − Slack 或 Microsoft Teams 等工具可让团队成员实时交流并分享快速更新。
• 文档 − 使用 Confluence 等集中式文档平台可确保所有利益相关者都拥有最新的项目信息和决策。

支持协作的工具和技术

许多工具和技术有助于改善 DevOps 中利益相关者之间的团队合作。这些工具有助于实现工作自动化、集成系统和跟踪任务。

• 版本控制系统 − Git 可帮助开发人员共同编写代码、跟踪更改和管理代码审查。例如，使用 GitHub，团队可以发出代码审查的拉取请求。这让他们可以在合并之前讨论并确保代码质量。
• CI/CD 工具 − Jenkins、CircleCI 和 GitLab CI 等持续集成和持续部署工具有助于实现测试和部署的自动化。这促进了开发和运营之间的团队合作。例如，每当推送新代码时，CI/CD 管道都会自动运行测试。这可以让所有利益相关者立即了解构建状态。
• 项目管理工具 − Jira 或 Trello 等平台显示项目进度并帮助跨团队管理任务。例如，产品经理使用 Jira 创建用户故事并分配任务。这有助于开发人员和 QA 团队查看进度和更新。

持续反馈循环

持续反馈循环在 DevOps 中很重要。它们帮助利益相关者从每个周期中学习并改进他们的工作。这些循环确保不仅收集反馈，而且还采取行动。

• 自动化测试 − 在 CI/CD 管道中添加自动化测试可让团队快速获得有关代码质量的反馈。例如，当开发人员推送代码时，自动化测试就会运行。结果将传达给整个团队，这样他们就可以快速发现问题。
• 用户反馈 − 与最终用户交谈以了解他们对新功能的想法有助于团队根据实际需求改变开发重点。例如，在发布功能后，产品团队会进行用户调查并检查使用数据。这有助于找到需要改进的领域。
• 回顾 − 定期的回顾会议有助于团队思考他们的流程、成功和问题。这鼓励了一种改进的文化。例如，在每个冲刺结束时，团队都会讨论哪些方面做得好，哪些方面可以改进。他们为下一个周期做出可行的改变。

通过使用良好的沟通渠道、协作工具和持续的反馈循环，DevOps 利益相关者可以更好地合作。这使得软件交付过程更加有效

DevOps 中的利益相关者挑战

在本节中，我们重点介绍了不同 DevOps 利益相关者必须面对的挑战类型 −

文化阻力

文化阻力是使用 DevOps 实践时面临的一大挑战。开发、运营和其他团队之间的旧障碍可能使改变变得困难。

• 思维转变 − 团队可能会坚持使用旧流程。他们可能不想尝试新的合作方式。例如，开发人员可能不想在早期谈判中加入运营。他们担心这会减慢他们的快速开发周期。
• 害怕失业 − 员工可能认为 DevOps 自动化可能会夺走他们的工作。这可能会导致他们抵制新技术。例如，运营团队可能会拒绝使用自动化部署工具。他们担心会失去对部署的控制。

目标不一致

当团队的目标不一致时，可能会损害 DevOps 项目的成功。如果团队只关注自己的目标，而不关注公司的整体目标，则会导致问题和冲突。

• 缺乏共同愿景 − 不同的团队可能专注于不同的目标。这可能会导致延迟和混乱。例如，开发团队可能希望快速交付功能。同时，运营团队可能希望保持系统稳定。这会导致紧张局势。
• 沟通差距 − 关于项目目标的沟通不足会使不一致情况更加严重。例如，产品经理可能会在没有与开发和 QA 进行充分沟通的情况下为功能发布设定截止日期。这会导致工作仓促和错误。

资源限制

有限的资源确实会影响利益相关者的合作和使用 DevOps 实践。这可能来自预算限制、人员不足或缺少工具。

• 预算限制 − 组织可能很难花钱购买所需的工具、培训或招聘来支持 DevOps 项目。例如，由于预算限制，公司可能不得不等待使用新的 CI/CD 工具。这可能会让他们更长时间地陷入手动流程。
• 技能差距 − 缺乏足够的 DevOps 培训或技能可能会阻止团队使用新工具和方法。例如，如果开发团队不了解 Docker 等容器工具，使用微服务架构可能会减慢速度。

通过解决这些挑战，组织可以为成功使用 DevOps 和利益相关者之间的团队合作创造更好的环境。

结论

在本章中，我们研究了利益相关者在 DevOps 环境中的重要作用。我们确定了开发、运营、QA、安全和业务管理等关键团队。我们展示了他们如何通过良好的沟通、有用的工具和持续的反馈来协同工作。

我们还强调了利益相关者面临的问题。其中包括文化阻力、不同的目标和缺乏资源。通过了解这些问题，组织可以建立更好的合作和创新文化。

DevOps - 认证

在当今瞬息万变的科技世界中，我们看到对熟悉 DevOps 的专业人士的需求很大。但是，面对众多工具、方法和最佳实践，我们很容易感到迷失。这就是为什么认证对于任何想要展示自己在这一领域技能的人来说都很有用的原因。

在本章中，我们将探讨 DevOps 认证。我们将研究它们为何重要以及我们在各个职业阶段可以选择的不同选项。我们将讨论我们可以获得的认证类型，指出一些最受认可的认证，并解释我们需要了解哪些内容才能为每种认证做好准备。

DevOps 认证的类型

我们可以将 DevOps 认证分为两种主要类型:行业认可的认证和特定角色的认证。每种类型都有其用途，并且是为 DevOps 世界中的不同人设计的。

行业认可的认证

这些认证表明我们了解全球知名的 DevOps 原则、实践和工具。它们专注于跨不同平台和技术工作的最佳实践。如果我们想证明我们在 DevOps 方面的技能，这将为我们打下坚实​​的基础。

行业认可的认证通常不与任何一家公司挂钩。这让我们能够展示我们在广泛使用的 DevOps 方法方面的技能。它们通常涵盖持续集成、持续交付、基础设施即代码和云原生实践等主题。

角色特定认证

这些认证是针对 DevOps 领域的特定工作而设立的。他们根据我们的工作角色为我们提供特殊培训。

角色特定认证满足不同专业人士的需求和任务。它们帮助我们获得在工作中取得成功所需的技能和知识。这些认证可能侧重于对开发人员、运营人员或安全专家很重要的某些工具、实践或方法。

无论我们想获得一般知识还是专注于特定角色，我们都可以找到有助于我们在 DevOps 中发展职业生涯的认证。

顶级 DevOps 认证

以下是一些顶级 DevOps 认证的详细概述。

AWS 认证 DevOps 工程师

• 目标受众 − 具有 AWS 和 DevOps 经验的专业人士。
• 级别 − 专业级
• 难度 − 中级到高级
• 涵盖的主题 − 持续交付和自动化、监控和日志记录、安全和合规性、事件和事件响应
• 合适的角色 − DevOps 工程师、云工程师、自动化工程师
• 链接 − 了解有关 AWS 认证 DevOps 工程师的更多信息

Microsoft 认证:DevOps 工程师专家

• 目标受众 − 熟悉 Azure DevOps 实践和工具的 IT 专业人员。
• 级别 − 专家
• 难度 − 中级到高级
• 涵盖的主题 − 持续集成和交付、基础设施即代码、配置管理、应用程序洞察
• 合适的角色 − DevOps 工程师、Azure 开发人员、IT 运营工程师
• 链接 − 了解有关 Microsoft 认证:DevOps 工程师专家的更多信息

认证 Kubernetes 管理员 (CKA)

• 目标受众 − 具有 Kubernetes 经验的 IT 专业人士。
• 级别 − 专业
• 难度 − 中级到高级
• 涵盖的主题 − Kubernetes 架构和安装、网络、存储和日志记录、应用程序生命周期管理、故障排除和维护
• 合适的角色 − Kubernetes 管理员、云工程师、DevOps 工程师
• 链接 − 了解有关认证 Kubernetes 管理员 (CKA) 的更多信息

HashiCorp 认证:Terraform 助理

• 目标受众 − 使用 Terraform 进行基础设施管理的专业人士。
• 级别 − 助理
• 难度 − 中级
• 涵盖的主题 − 基础设施即代码原则、Terraform 核心概念、管理 Terraform 状态、配置和部署资源
• 合适的角色 − DevOps 工程师、云工程师、基础设施工程师
• 链接 − 了解有关 HashiCorp 认证:Terraform Associate 的更多信息

Google 专业 DevOps 工程师

• 目标受众 − 具有 Google Cloud Platform (GCP) 经验的 IT 专业人士。
• 级别 − 专业
• 难度 − 中级到高级
• 涵盖的主题 −站点可靠性工程 (SRE)、服务监控和日志记录、持续交付和基础设施自动化、事件响应和管理
• 合适的角色 − DevOps 工程师、云架构师、站点可靠性工程师
• 链接 − 了解有关 Google 专业 DevOps 工程师的更多信息

当我们参加 DevOps 认证时，我们需要了解要求和帮助我们成功所需的经验。每个认证都有自己的需求。做好充分的准备可以提高我们通过考试的机会。

DevOps 认证的先决条件

虽然每个认证的要求可能会有所不同，但我们可以看看一些常见的基础知识 −

• 对 DevOps 概念的基本理解 − 我们应该了解重要的 DevOps 理念。这些包括持续集成、持续交付以及开发和运营团队之间的协作。
• 熟悉工具和技术 − 了解流行的 DevOps 工具(如 Git、Jenkins、Docker 和 Kubernetes)会有所帮助。许多认证都要求我们具备使用这些工具的一些基本技能。
• 编程知识 −了解至少一种编程或脚本语言，如 Python、Java 或 Bash，可以帮助完成许多 DevOps 工作和认证。

推荐的经验和知识

除了先决条件之外，我们还应该考虑可以帮助我们的某些级别的经验和知识 −

• 专业经验 − 大多数认证都建议在 DevOps 环境中拥有实践经验。这通常意味着 1 到 3 年的工作。这种经验有助于我们在实际情况下运用所学知识，这对于通过考试非常重要。
• 了解云平台 − 对于与云相关的认证，我们应该了解 AWS、Azure 或 Google Cloud 等平台。了解云服务及其工作原理可以帮助我们理解认证材料。
• CI/CD 实践 − 持续集成和持续部署方面的经验通常很重要，因为这些是 DevOps 方法的关键部分。
• 基础设施即代码 (IaC) − 对于专注于 Terraform 或 Ansible 等工具的认证，我们应该了解 IaC 的理念和实践。
• 软技能 − 合作、沟通和解决问题等技能在 DevOps 工作中很重要。即使这些技能并不总是列在认证要求中，但它们确实可以帮助我们取得成功。

通过满足这些要求并获得正确的经验，我们可以为 DevOps 认证做好更充分的准备。这将帮助我们在 DevOps 职业生涯中取得成功。

DevOps 认证的准备

准备 DevOps 认证需要一个良好的计划和正确的工具。以下是一些有用的策略，可让您的学习更上一层楼 −

通过使用这些准备策略，我们可以在参加认证考试之前打下坚实的基础并感到更加自信。

DevOps 认证的好处

获得 DevOps 认证有很多好处，可以帮助您的职业生涯。这些认证可以展示您的技能并提高您在行业中的专业形象。以下是一些重要的好处 −

• 职业发展 − 您可以找到新的工作机会并获得晋升。
• 增加收入潜力 − 您可以比没有认证的人赚更多的钱。
• 行业认可 − 它证明了您的技能和对该领域的承诺。
• 增强知识 − 您可以了解有关 DevOps 方法和工具的更多信息。
• 交流机会 − 您可以结识其他专业人士和行业领袖。
• 增强信心 − 您对使用 DevOps 理念更有信心。
• 保持最新状态 −您可以随时了解 DevOps 的新趋势和技术。

通过获得 DevOps 认证，我们可以在快速变化的就业市场中变得更有知识、更有竞争力。

结论

在本章中，我们研究了 DevOps 认证的要点。我们讨论了它们的类型、要求、最佳认证、如何准备以及为什么继续学习很重要。当我们了解 DevOps 认证及其带来的好处(例如更好的工作机会、更高的薪水和行业认可)时，我们可以为自己的职业做出明智的选择。

通过获得这些认证，您可以获得重要的技能。它还可以使您成为竞争激烈的技术领域中备受追捧的资源。认证可以帮助您在 DevOps 中获得成功且有益的职业生涯。

DevOps - 基本技能

在本章中，我们将研究良好 DevOps 实践所需的技能。我们将讨论一些技术技能，例如版本控制系统、持续集成、持续部署 (CI/CD) 和基础设施即代码 (IaC)。我们还将了解为什么容器化、编排、监控和云计算在 DevOps 中很重要。

在本章结束时，您将很好地了解成为 DevOps 工程师所需的关键技能。您还将了解这些技能如何帮助我们更好地工作并改善团队合作。

DevOps 所需的关键技能

DevOps 需要许多技能。这些包括技术技能和软技能。下面，我们将介绍成功的 DevOps 职业所需的关键技能。我们将给出清晰的解释和示例来说明这些技能的重要性以及我们如何使用它们。

版本控制系统

版本控制系统 (VCS) 帮助我们管理代码更改。它们让许多开发人员能够协同工作，并保留项目中的变更历史记录。

关键工具 − Git 是最流行的版本控制系统。它帮助我们跟踪变更、返回早期版本并轻松地协同编写代码。

示例 − 一个开发 Web 应用程序的开发人员团队可以使用 Git。每个开发人员都会创建一个分支来处理特定功能。当该功能准备就绪并经过测试后，该分支会通过拉取请求合并回主分支。这样，我们可以在部署之前检查代码并确保其良好。

持续集成和持续部署 (CI/CD)

CI/CD 是一套自动化集成和部署过程的实践。持续集成意味着我们会自动测试和合并代码变更。持续部署可帮助我们快速安全地将代码变更发布到生产环境中。

关键工具 − Jenkins、GitLab CI、CircleCI。这些工具可自动执行构建、测试和部署过程。这让我们可以更专注于开发。

示例 − 使用 Jenkins，团队可以设置 CI/CD 管道。每当我们将代码推送到存储库时，它都会运行构建和测试。如果测试通过，Jenkins 会自动将应用程序部署到暂存区以供进一步测试。如果一切正常，代码只需很少的手动工作即可投入生产。

基础设施即代码 (IaC)

IaC 让我们能够使用代码来管理和设置基础设施，而无需手动操作。此方法有助于保持一致性、减少人为错误并加快设置速度。

关键工具 − Terraform、Ansible、Puppet。这些工具可帮助我们自动完成基础设施的设置、配置和管理。

示例 − 使用 Terraform，DevOps 工程师可以为 Web 应用的基础设施编写代码。这包括服务器、数据库和网络。如果需要更改，工程师只需更新代码，Terraform 会更改基础设施以进行匹配。

容器化和编排

容器化帮助我们将应用程序及其依赖项打包到容器中。这确保它们在不同环境中以相同的方式工作。编排工具管理我们如何部署、扩展和运行这些容器。

关键工具 − Docker(用于容器化)、Kubernetes(用于编排)。这些工具可帮助我们轻松部署和管理应用程序。

示例 − 开发团队使用 Docker 打包其微服务应用程序。每个服务都在其容器中运行。Kubernetes 管理这些容器。它根据流量进行扩展、进行滚动更新并帮助进行服务发现。这使部署更加容易。

监控和日志记录

监控和日志记录对于保持应用程序健康运行非常重要。它们让我们深入了解应用程序的行为方式，帮助我们发现问题并让我们快速做出响应。

关键工具 − Prometheus、Grafana、ELK Stack(Elasticsearch、Logstash、Kibana)。这些工具可帮助我们查看指标和日志。这使得我们更容易关注我们的应用程序。

示例 − 使用 Prometheus，一个团队为他们的 Web 应用程序设置了监控。它收集响应时间和错误率等指标。Grafana 帮助我们创建仪表板以实时显示这些指标。如果错误率激增，团队可以使用 ELK Stack 快速检查日志以查找和解决问题。

云计算

云计算通过互联网为我们提供资源和服务。这使得我们的基础架构易于扩展和灵活。了解云服务对于在 DevOps 中部署应用程序非常重要。

关键提供商 − AWS、Azure、Google Cloud。这些平台提供许多服务，如计算、存储和网络。

示例 − 使用 AWS 的公司可以使用 EC2 等服务作为虚拟服务器、S3 用于存储和 RDS 用于托管数据库。通过使用这些服务，团队可以根据需求更改资源。这有助于节省成本并提高性能。

协作和沟通

良好的协作和沟通在 DevOps 中非常重要。团队跨不同职能部门协同工作。这意味着我们需要共享知识、解决问题并协调我们的目标。

关键工具 − Slack、Microsoft Teams、JIRA - 这些工具帮助我们在团队成员之间沟通和管理项目。

示例 − DevOps 团队使用 Slack 进行快速聊天，为不同的项目创建频道。他们还使用 JIRA 来跟踪问题和任务。这有助于每个人就项目进度和优先级保持一致。

DevOps 中的安全性 (DevSecOps)

将安全性纳入 DevOps 流程意味着安全性是开发和运营团队中每个人的工作。这样，我们就可以在软件开发过程的早期发现漏洞。

关键工具 − Snyk、Aqua Security、HashiCorp Vault - 这些工具有助于自动执行安全检查并管理敏感信息。

示例 − 开发团队使用 Snyk 检查其应用程序是否存在安全问题。在 CI/CD 管道中，任何问题都会在部署前被标记以进行修复。这确保我们在整个开发过程中都专注于安全性。

软技能和敏捷方法

除了技术技能外，沟通、团队合作和解决问题等软技能在 DevOps 中也非常重要。了解敏捷方法有助于团队适应变化并逐步实现价值。

示例 − DevOps 团队使用 Scrum 方法来管理他们的工作。他们定期开会讨论进展和问题。这种敏捷方式有助于提高透明度和问责制。它让团队能够快速适应新的挑战。

如何在简历中添加 DevOps 经验?

在简历中展示您的 DevOps 经验非常重要。这有助于表明您在这方面很熟练。以下是一些简单的提示，可帮助您突出自己的 DevOps 技能和经验 −

• 针对您申请的每份工作更改您的简历。重点介绍与职位描述相匹配的 DevOps 技能和经验。
• 将您的简历组织成清晰的部分，如"技术技能"、"专业经验"和"项目"。这样更易于阅读。
• 列出您了解的重要 DevOps 工具和技术。包括 Git、Jenkins、Docker、Kubernetes、Terraform 和云服务等内容。
• 使用数字展示您的工作。例如，说"使用 CI/CD 将部署时间缩短了 30%。"
• 添加"项目"部分。在这里，您可以谈论您参与过的具体 DevOps 项目。解释您的角色、您使用的技术以及结果。
• 谈谈您如何与不同的团队合作。提及您使用过的任何敏捷方法，例如 Scrum 或 Kanban。
• 包括您拥有的任何相关认证，例如 AWS 认证 DevOps 工程师或 Docker 认证助理。这证明了您的技能。
• 使用职位描述中的单词。这可以帮助您通过申请人跟踪系统 (ATS)。
• 提及 DevOps 中的任何正在进行的教育、研讨会或培训。这表明您想继续学习该领域。

通过使用这些技巧，您可以清楚地展示您的 DevOps 经验。这将有助于您的简历在雇主面前脱颖而出。

结论

在本章中，我们研究了在 DevOps 中取得良好职业所需的关键技能。这些技能包括版本控制、CI/CD 实践、基础设施即代码、容器化、监控、云计算、与他人良好合作以及安全性。

我们还讨论了如何在简历中添加 DevOps 经验。针对每份工作更改您的申请非常重要。展示您的相关技能并使用数字来突出您的成就。通过学习这些技能并很好地展示它们，您可以成为竞争激烈的 DevOps 世界中的有力候选人。

DevOps - 工作机会

随着企业不断向数字化转变，我们看到对熟练的 DevOps 工作者的需求正在大幅增长。这种变化为不同行业创造了许多就业机会。在本章中，我们将介绍塑造这一领域的 DevOps 职位和趋势。

我们将介绍 DevOps 工程师、站点可靠性工程师和自动化工程师等热门职位。我们还将分享有关薪资预期、网络技巧以及如何建立投资组合的详细信息。无论您是想转向 DevOps 的专业人士，还是想进入该领域的初学者，本章都将为您提供探索 DevOps 机会所需的知识。

DevOps 中的热门职位

下表重点介绍了 DevOps 中的一些热门职位 −

行业需求和就业市场趋势

对 DevOps 工作者的需求不断增长。这表明开发和运营团队合作的重要性。它们有助于快速安全地交付软件。本节讨论当前的就业市场事实以及不同行业中 DevOps 职位的兴起。

当前就业市场统计数据

DevOps 就业市场强劲。许多公司都需要熟练的工人。以下是有关当前就业市场的一些重要事实 −

• 职位空缺 − 许多招聘网站表示，DevOps 职位的招聘信息更多。 LinkedIn 近几个月有超过 40,000 条 DevOps 职位的活跃招聘信息。
• 薪资趋势 − DevOps 职位的平均薪资正在上涨。Glassdoor 表示，DevOps 工程师的年薪约为 115,000 美元。经验更丰富的员工可以赚到超过 150,000 美元。站点可靠性工程师也能获得类似的薪资，因为他们的技能需求量很大。
• 技能差距 − DevOps Institute 的一项调查显示，86% 的公司发现其 DevOps 团队存在技能差距。这意味着想要加入该领域的人有很大的机会。公司寻找同时具备技术和软技能的人才。
• 招聘趋势 − 2023 年 DevOps 状况报告称，74% 的公司计划在明年扩大其 DevOps 团队。这种增长源于对更快的软件交付和更好的团队合作的需求。

各行业 DevOps 角色的增长

DevOps 实践不仅限于一个行业。它们在许多领域都变得重要。以下是 DevOps 角色在关键行业中增长的方式:

• 科技行业是 DevOps 员工的最大雇主。从初创公司到大型公司，公司都在投资 DevOps 以改善软件交付。谷歌、亚马逊和微软等大公司都有自己的 DevOps 团队来保持竞争力。
• 银行和金融公司正在使用 DevOps 来加快其数字变革。他们需要快速的软件更新并满足规则，因此他们需要更多的 DevOps 员工。摩根大通和高盛等公司聘请 DevOps 工程师和 SRE 来改善其运营。
• 医疗保健行业也看到了 DevOps 的好处。它有助于开发用于患者护理和数据管理的应用程序。由于规则严格且需要快速更改，医疗保健公司聘请 DevSecOps 工程师来增强其开发流程的安全性。
• 零售业的网上购物越来越多。这增加了使用 DevOps 来管理网站和客户体验的需求。沃尔玛和塔吉特等大型零售商正在使用 DevOps 方法来改善其数字服务并提高工作效率。
• 随着工业 4.0 的发展，制造公司使用 DevOps 来改善其生产。他们通过自动化和物联网 (IoT) 来实现这一点。智能设备对持续软件交付的需求为该领域的 DevOps 工作者创造了新的就业机会。

DevOps 中的薪资预期

对 DevOps 工作者的需求正在增长。正因为如此，这些工作的薪资预期也在上升。了解不同职位的平均工资以及影响这些工资的因素可以帮助那些想要从事 DevOps 工作的人。

按职位划分的平均工资

DevOps 职位的工资可能会有很大变化。它们取决于每项工作所需的经验、地点和技能。以下是重要 DevOps 角色的平均薪酬 −

DevOps 工程师 − 平均工资从 115,000 美元到 150,000 美元。技术熟练的工人可以赚到超过 150,000 美元，尤其是在需求旺盛的地区。

站点可靠性工程师 (SRE) − SRE 通常赚得更多。他们的薪酬范围从120,000 美元到 160,000 美元。这是因为他们是保持系统良好运行的关键。

发布经理 − 平均工资在100,000 美元到 140,000 美元之间。这取决于他们的经验和工作职责。

自动化工程师 − 他们的工资范围从110,000 美元到 145,000 美元。这是因为许多行业对自动化技能的需求很高。

DevSecOps 工程师 − 平均工资从115,000 美元到 155,000 美元。这是因为安全性在 DevOps 流程中非常重要。

影响薪资的因素(经验、地点)

许多因素都会影响 DevOps 工作者的薪资。以下是其中一些因素 −

经验水平

• 入门级 DevOps 工作起薪通常为 80,000 至 100,000 美元。随着经验的增加，薪水会大幅上涨。
• 具有 3-5 年 经验的中级员工可赚取 100,000 至 130,000 美元。
• 具有 5 年以上 经验的高级员工可赚取超过 150,000 美元。对于 SRE 或 DevSecOps 等工作尤其如此。

地理位置 − 薪水会因地点而异。 旧金山、纽约、西雅图和奥斯汀等大型科技城市通常薪酬更高。这是因为生活成本和对技术工人的需求。例如，旧金山的 DevOps 工程师可能赚取约 160,000 美元。在较小的城市，同样的工作可能支付约 100,000 美元。

远程工作也在改变薪资预期。许多公司现在从任何地方聘请人才，有时无论员工住在哪里，他们都会提供不错的薪水。

行业 − DevOps 工作者所在的行业可以改变他们的薪酬。金融和医疗保健等领域有严格的规则，需要强大的安全性，通常比监管较少的行业支付更多。

技能和认证 −特殊技能，例如了解云平台(AWS、Azure、GCP)、容器工具(Docker、Kubernetes)和自动化工具(Jenkins、Ansible)，可以带来更高的薪水。

拥有 AWS 认证 DevOps 工程师或认证 Kubernetes 管理员等认证可以使候选人更具吸引力并提高他们的薪酬潜力

结论

在本章中，我们研究了 DevOps 领域的就业机会。我们讨论了 DevOps 工程师、站点可靠性工程师和 DevSecOps 工程师等热门职位。我们描述了他们的任务和所需的技能。我们查看了当前的就业市场统计数据。我们看到 DevOps 角色在许多行业中都在增长。这表明对熟练工人的需求正在上升。

我们还讨论了薪资预期。我们按角色细分了平均工资。我们研究了影响薪酬的因素，例如经验、地点和行业。了解这些有助于新专业人士规划他们的职业生涯。它还可以帮助公司在瞬息万变的 DevOps 世界中寻找和留住最优秀的人才。

DevOps - Agile

在本章中，我们将探讨 DevOps 和 Agile 的主要思想。我们将研究它们的原则和实践。我们将讨论如何将 Agile 方法与 DevOps 管道相结合。这将改善团队合作并自动执行任务以实现顺畅的工作流程。

我们还将检查 Scrum 和 Kanban 等关键的 Agile 框架，以及它们如何帮助 DevOps 实践。在本章结束时，我们将了解如何使用 DevOps 和 Agile 来改善我们的软件开发。

为什么我们需要结合 DevOps 和 Agile?

DevOps 和 Agile 方法已成为帮助团队快速交付高质量软件并适应变化的重要工具。DevOps 专注于开发和运营之间的协作。它建立了持续集成、交付和部署的文化。另一方面，Agile 支持小步骤的开发。这有助于团队对需求和市场条件的变化做出快速反应。

对于希望改进软件开发的组织来说，结合 DevOps 和 Agile 方法非常重要。这种组合创造了一种团队合作和不同团队共同承担责任的文化。它有助于打破开发、运营和其他团队之间的旧障碍。

通过将 DevOps 理念与敏捷实践相结合，我们可以加快交付周期。这让我们能够快速响应客户反馈和市场需求。

此外，DevOps 和 Agile 之间的联系有助于我们通过循序渐进的流程和自动化不断改进。Agile 专注于进行小改动，因此团队可以更频繁地发布新功能。DevOps 确保这些发布高效可靠地进行。这种组合不仅加快了整个开发过程，而且还提高了软件产品的质量。这会让客户更满意，并让我们在市场上占据优势。最终，将 DevOps 和 Agile 结合起来可以帮助组织快速创新，同时保持高质量和可靠性。

敏捷和 DevOps 的关键原则

下表重点介绍了敏捷和 DevOps 的关键原则 −

敏捷框架和 DevOps 集成

将敏捷框架与 DevOps 结合起来有助于团队更好地工作。它使工作流程更简单，并改进了我们开发软件的方式。让我们看看三个流行的敏捷框架 - Scrum、Kanban 和 Lean - 看看我们如何将它们与 DevOps 连接起来。

Scrum

Scrum 是一个敏捷框架。它专注于通过称为冲刺的短时期交付小部分工作。这些冲刺通常持续 1 到 4 周。Scrum 重视团队合作、责任感和改变计划的能力。

与 DevOps 集成

在 Scrum 中，DevOps 可以通过让开发和运营团队在冲刺期间合作来发挥作用。例如，在冲刺规划中，开发团队可以邀请运营人员讨论部署需求并发现任何问题。这种团队合作有助于使部署更顺畅，更快地解决问题。

示例

使用 Scrum 制作 Web 应用程序的软件团队可以设置 DevOps 管道。此管道可以自动执行测试和部署任务。在每个冲刺结束时，团队可以使用持续集成/持续部署 (CI/CD) 工具。这些工具会自动测试应用程序的最新版本并将其部署到暂存区。此过程允许快速反馈和更改。

看板

看板 是一种敏捷方法。它使用称为看板的板来显示工作。这种方法侧重于限制正在进行的工作，使工作更高效、更顺畅。

与 DevOps 集成

通过添加自动监控和部署工具，DevOps 可以改进看板的可视化工作系统。此设置可让团队查看他们的任务、部署状态和运营数据。

示例

使用看板的团队可以创建看板来跟踪开发任务和部署任务。当开发人员完成功能时，他们可以使用 CI/CD 管道触发到生产区域的自动部署。实时监控工具可以显示性能数据。这样，团队就可以快速发现和解决问题。

精益框架

精益是一个敏捷框架，旨在提供最大的价值，同时减少浪费。它专注于改进流程和效率，并为客户提供价值。

与 DevOps 集成

将精益引入 DevOps 有助于组织简化流程并减少软件交付中的浪费。这种结合凸显了自动执行重复任务和减少延迟的重要性。

示例

遵循精益理念的公司可以创建一个 DevOps 计划，以自动执行测试和部署任务。这种自动化可以节省不增加价值的任务的时间，例如手动测试和部署。例如，如果团队需要几个小时来部署新功能，则自动执行此任务可以使部署更快。这一变化有助于团队更快地响应客户需求。

衡量 DevOps 和 Agile 的成功

衡量 DevOps 和 Agile 工作的成功非常重要。它可以帮助我们看到我们做得如何，并找到改进的方法。我们需要使用与我们的组织目标相匹配的关键绩效指标 (KPI) 和指标。

关键绩效指标 (KPI)

KPI 是清晰的数字，显示团队在实现特定目标方面的表现。在 DevOps 和 Agile 中，一些常见的 KPI 是 −

• 交付周期 − 这是功能从开发到部署所需的时间。交付周期越短，流程就越高效。
• 部署频率 − 这衡量我们部署到生产的频率。部署越多意味着我们可以快速交付功能和修复。
• 变更失败率 − 这是导致失败或需要回滚的变更的百分比。较低的变更失败率表明我们拥有更高质量和更稳定的版本。
• 平均恢复时间 (MTTR) − 这是从生产故障中恢复所需的平均时间。较短的恢复时间表明我们具有弹性并且可以做出良好的响应。

通过定期检查这些 KPI，我们可以了解趋势，发现瓶颈并做出明智的决策以改进我们的 DevOps 和 Agile 实践。

持续改进的指标

持续改进是 DevOps 和 Agile 的关键部分。指标在此过程中非常有用。它们让我们了解团队的表现以及工作流程的效率。一些重要的指标是 −

• 周期时间 − 这是从我们开始执行任务到完成任务的总时间。缩短周期时间有助于我们更快地交付价值。
• 在制品 (WIP) − 跟踪当前正在进行的工作量有助于我们管理产能并避免延误。
• 客户满意度 − 衡量客户反馈和满意度分数可以让我们深入了解软件满足用户需求的程度。
• 质量指标 − 这包括发布后报告的缺陷数量以及我们的测试效果。良好的质量指标表明我们拥有强大的测试流程。

案例研究和真实示例

许多公司在 DevOps 和 Agile 实践方面都做得很好。这些变化使他们的软件开发得到了很大的改进。

一个很好的例子是零售巨头Target。Target 使用敏捷实践来改善其团队之间的团队合作。他们专注于 Scrum 以短跑方式工作。这样，他们就可以快速响应市场需求。同时，他们添加了 DevOps 工具以实现持续集成和部署。这种组合帮助 Target 将推出新功能的时间从几周缩短到几天。这一变化让客户更满意，并有助于提高销售额。

另一个例子是在线市场Etsy。Etsy 在部署频率和系统可靠性方面存在问题。通过使用 DevOps 原则，他们实现了部署管道的自动化。现在，他们每天可以进行多次部署。他们还添加了敏捷实践来帮助团队更好地协同工作。因此，Etsy 大大降低了变更失败率。这一变化使他们的平台更加稳定，并改善了用户体验。

结论

在本章中，我们研究了 DevOps 和 Agile 如何协同工作。我们讨论了它们在当今软件开发中的重要性。我们介绍了关键思想和不同的敏捷框架，如 Scrum、Kanban 和 Lean。我们了解了这些框架如何与 DevOps 实践很好地协同工作。

DevOps - 精益原则

当我们将精益原则引入 DevOps 时，它有助于改善软件交付。精益专注于消除浪费、改善团队合作和优先考虑客户价值。这种组合有助于团队更快地交付。它还可以节省资金并保持高质量。

什么是精益原则?

精益是一种减少浪费和改善我们交付价值的方式的工作方式。它始于制造业，但现在在软件交付中也运行良好。它有助于简化流程并获得更好的结果。

以下是精益的主要思想 −

• 消除浪费 − 停止执行没有增加价值的任务。
• 不断改进 − 始终寻找改进的方法。
• 关注价值 − 提供客户需要的东西。
• 团队授权 − 共同努力，共担责任。

为什么精益原则在 DevOps 中很重要?

精益和 DevOps 相得益彰。两者都注重效率和质量。当我们将精益与 DevOps 结合使用时，它可以帮助我们 −

• 缩短周期时间 −加快开发和部署。
• 更好地合作 − 打破团队障碍。
• 提高质量 − 确保每一步都做得很好。
• 满足客户需求 − 提供用户期望的产品。

通过将精益与 DevOps 结合使用，团队可以更快地交付、更好地利用资源并快速适应客户需求。

DevOps 中的关键精益原则

精益原则帮助 DevOps 团队更高效地工作。他们专注于团队合作和持续改进。这些原则使更快交付优质软件变得更加容易。以下是我们在 DevOps 中遵循的主要思想。

如何在 DevOps 中应用精益原则?

我们可以通过查找和移除慢点来改进 CI/CD 管道。我们简化工作流程并使其自动化以加快代码部署。这有助于我们更快地部署并减少手动工作。

我们的目标是减少从开发到生产所需的时间。我们可以通过缩短开发周期来实现这一目标。我们还专注于更好的团队合作以及自动化测试和部署，以避免延迟并提高速度。

我们自动执行反复执行的任务，例如测试代码、构建、部署和设置基础设施。这有助于我们减少错误、更快地交付并在不同环境中保持一致。

通过使用这些精益实践，我们可以使我们的 DevOps 流程更加高效。我们可以在保持高质量的情况下更快地交付软件。

DevOps 中的精益工具和技术

以下精益工具和技术为我们提供了在软件开发和交付中改善协作、速度和质量的实用方法 −

价值流映射是一种帮助我们了解整个工作流程(从构思到交付)的技术。我们可以通过查看每个步骤来发现问题和浪费。这有助于我们发现延迟、慢点和需要改进的领域。通过这样做，我们可以专注于增加价值并改善流程和生产力的活动。

看板是一种帮助我们跟踪工作和管理正在进行的工作的工具。它限制了同时处理的任务数量(WIP)，以防止出现瓶颈。这有助于工作流程顺利进行并加快交付速度。通过定期检查流程效率，我们可以发现并消除障碍，从而加快工作在流程中的推进速度。

Kaizen 是指随着时间的推移做出小幅改进。在 DevOps 中，这意味着我们会定期查看流程、获取反馈并做出改进。我们建立了一种持续改进的文化，以便我们能够创新、尽早解决问题，并不断改进，以更快、更高质量地交付。

衡量 DevOps 中精益的指标

在本节中，我们重点介绍了衡量 DevOps 中精益的关键指标 &​​minus;

交付时间

交付时间是指一项工作(如功能或错误修复)从开发开始到投入生产所需的时间。交付时间越短，意味着我们可以更快地交付并更有效地工作。

示例 −如果开发人员在周一提交代码，而该功能在周四上线，则交付周期为 4 天。

部署频率

此指标显示我们将软件部署到生产环境的频率。高部署频率意味着我们拥有快速的 CI/CD 管道，可以快速交付功能或修复。

示例 − 如果我们每天将代码部署到生产环境三次，则部署频率为每天三次。

变更失败率

变更失败率衡量导致问题(如错误或崩溃)的部署百分比。较低的失败率表明代码质量和测试更好。

示例 −如果发生 10 次部署，其中 2 次导致生产错误，则变更失败率为 20%。

平均恢复时间 (MTTR)

MTTR 告诉我们在发生故障后恢复服务需要多长时间。较短的 MTTR 表明我们可以快速解决问题并恢复正常。

示例 − 如果服务在上午 10 点发生故障并在中午 12 点之前修复，则 MTTR 为 2 小时。

通过跟踪这些指标，我们可以衡量我们的精益 DevOps 实践的效果。它帮助我们找到需要改进的领域并改善我们的软件交付流程。

结论

在本章中，我们探讨了 DevOps 中精益的主要思想。我们研究了它的原则、工具、技术和衡量成功的重要指标。我们讨论了精益实践(例如改进 CI/CD 管道、缩短周期时间和自动化任务)如何帮助我们更快地工作、更快地交付并获得更好的结果。

我们还强调了团队在 DevOps 中使用精益时必须面对的挑战以及解决这些挑战的共享解决方案。使用精益原则，我们可以改善团队合作、减少浪费并改进软件交付流程。这有助于我们创建更敏捷、更有效的 DevOps 环境。

DevOps - AWS 解决方案

DevOps 是一种将软件开发 (Dev) 和 IT 运营 (Ops) 结合在一起的工作方式。它专注于团队合作、自动化和快速交付更新，以加快软件开发生命周期 (SDLC)。

DevOps 的主要原则

DevOps 的主要原则包括 −

• 持续集成 (CI) − 频繁将代码合并到共享存储库中。
• 持续交付 (CD) − 自动化部署以加快发布速度。
• 基础设施即代码 (IaC) − 使用代码管理基础设施以实现一致性和更轻松的扩展。
• 监控和反馈 −实时了解性能和问题。

AWS 在 DevOps 工作流中的重要性

AWS 为我们提供了强大的工具，使 DevOps 顺利运行 −

• 可扩展性和灵活性 − EC2、Lambda 和 ECS/EKS 等服务会调整基础设施以处理不断变化的工作负载。
• 端到端工具链 − CodePipeline、CodeBuild 和 CodeDeploy 等工具支持 CI/CD 流程的每一步。
• 自动化 − AWS CloudFormation 和 CDK 帮助我们自动化和重复基础设施设置。
• 全球影响力 − AWS 的全球网络可实现可靠且低延迟的部署。

AWS 使我们更容易遵循 DevOps 最佳实践。它还加快了我们交付应用程序的速度。

DevOps 的关键 AWS 服务

AWS 为我们提供了许多专为 DevOps 设计的服务。这些服务有助于实现自动化、扩展和简化工作流程。

AWS 上的持续集成和交付

当我们在 AWS 上使用 CI/CD 工作流时，它可以使集成代码更改、运行测试和跨环境部署变得顺畅且一致。CodePipeline、CodeBuild 和 CodeDeploy 等 AWS 服务协同工作，为这些任务创建可靠的管道。

使用 AWS CodePipeline 构建 CI/CD 管道

AWS CodePipeline 帮助我们构建完整的 CI/CD 工作流。它自动执行从源代码控制到部署的步骤。管道可以根据代码提交或设置计划等事件启动。

示例

查看以下示例 −

源阶段 − 我们设置管道以跟踪 GitHub 存储库中的更改。

ActionProvider: GitHub

RepositoryName: my-app

BranchName: main  

构建阶段 − 使用 AWS CodeBuild 编译和测试应用程序。

部署阶段 − AWS CodeDeploy 可以将最终工件推送到 EC2 或 Lambda。

CodePipeline 实时运行每个阶段。它还为我们提供详细的日志以调试任何问题。

使用 AWS CodeBuild 自动构建

AWS CodeBuild 编译我们的代码、运行测试并创建构建输出。它适用于多种编程语言和环境。我们可以使用预定义的构建映像或自定义 Docker 映像。

示例 buildspec.yml

version: 0.2  

phases:  

  install:  

    commands:  

      - echo Installing dependencies  

      - npm install  

  build:  

    commands:  

      - echo Building the app  

      - npm run build  

artifacts:  

  files:  

    - '**/*'  

与 CodePipeline 链接时，CodeBuild 会自动处理构建阶段。每次提交都会触发经过测试和编译的工件。

使用 AWS CodeDeploy 的部署策略

AWS CodeDeploy 处理应用程序部署到 EC2、Lambda 甚至本地服务器。它提供不同的策略来确保顺利更新并最大程度地减少停机时间:

就地部署 − 更新现有实例。最适合允许少量停机的小型应用程序。

蓝/绿部署 − 使用更新的代码创建新设置并缓慢移动流量。通过保持旧版本就绪来避免停机。

EC2 的示例 AppSpec.yml

version: 0.0  

os: linux  

files:  

  - source: /src  

    destination: /var/www/html  

hooks:  

  BeforeInstall:  

    - location: scripts/install_dependencies.sh  

      timeout: 300  

  ApplicationStart:  

    - location: scripts/start_server.sh  

借助 CodeDeploy，我们可以使用 Amazon CloudWatch 监控部署。如果出现故障，它可以自动回滚。

通过将 CodePipeline、CodeBuild 和 CodeDeploy 结合使用，AWS 为我们提供了可扩展、安全且高效的 CI/CD 流程。它使我们的工作流程可靠且易于管理。

使用 AWS 实现基础设施即代码 (IaC)

基础设施即代码 (IaC) 是 DevOps 中的重要实践。它让我们可以使用代码来管理基础设施，而不是手动执行操作。AWS 拥有 CloudFormation 和 AWS 云开发工具包 (CDK) 等实用工具。这些工具可帮助我们实现自动化、保持一致性并扩展我们的基础设施。

使用 AWS CloudFormation

AWS CloudFormation 可帮助我们使用 JSON 或 YAML 中的模板创建和管理 AWS 资源。这些模板描述了我们基础设施中的所有内容，例如 EC2 实例、VPC、Lambda 函数等。这让我们每次都能一致地部署相同的基础设施。

CloudFormation 很好，因为我们只需要告诉它我们想要什么。它会负责配置和管理依赖项。

示例:CloudFormation 模板

这是一个创建 S3 存储桶的简单 CloudFormation YAML 模板 −

AWSTemplateFormatVersion: '2010-09-09'  

Resources:  

  MyS3Bucket:  

    Type: 'AWS::S3::Bucket'  

    Properties:  

      BucketName: my-awesome-bucket  

使用此模板，CloudFormation 会自动创建一个具有我们提供的名称的 S3 存储桶。如果我们更改模板(例如添加 EC2 实例)，CloudFormation 将自动更新基础设施。这可以使一切保持一致并减少人为错误。

CloudFormation 还支持堆栈更新、更改集和嵌套堆栈等功能。这些功能可帮助我们管理更大、更复杂的基础设施。我们还可以将 CloudFormation 与其他 AWS DevOps 工具(如 CodePipeline)一起使用，以自动在 CI/CD 管道中创建我们的基础设施。

AWS CDK 简介

AWS CDK 是一个框架，可帮助我们使用 Python、TypeScript、Java 和 C# 等编程语言定义云基础设施。它让开发人员能够使用更高级别的概念而不是低级细节，从而使 IaC 变得更加简单。

借助 CDK，我们使用构造(预构建的 AWS 服务)来隐藏 CloudFormation 的复杂部分。CDK 获取我们的代码并将其转换为 CloudFormation 模板。然后使用此模板创建资源。

示例:Python 中的 CDK

以下是我们如何在 Python 中使用 AWS CDK 定义 S3 存储桶 −

from aws_cdk import core  

import aws_cdk.aws_s3 as s3  

class S3BucketStack(core.Stack):  

    def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:  

        super().__init__(scope, id, **kwargs)  

        s3.Bucket(self, "MyS3Bucket", bucket_name="my-awesome-bucket")  

app = core.App()  

S3BucketStack(app, "S3BucketStack")  

app.synth()  

在此示例中，S3BucketStack 类定义了一个 S3 存储桶，app.synth() 创建了 CloudFormation 模板。CDK 通过使用面向对象的概念简化了我们的工作，从而减少了重复代码并帮助开发人员提高工作效率。

CDK 还使使用 VPC 或 ECS 集群 等更高级的概念变得更加容易。我们不必处理详细的资源。例如，我们只需几行代码就可以使用应用程序负载均衡器定义 Amazon ECS 集群。这使得 CDK 非常适合那些喜欢使用代码而不是长 YAML 或 JSON 模板的开发人员。

在 AWS 中为 DevOps 进行监控和记录

以下 AWS 工具用于监控和记录 DevOps 管道中的活动 -

用于监控的 AWS CloudWatch

CloudWatch 帮助我们实时监控 AWS 资源和应用程序。它收集和跟踪指标、日志和事件。我们可以根据某些阈值设置警报以自动扩展或获取通知。

示例

为 EC2 CPU 使用率设置警报 −

aws cloudwatch put-metric-alarm --alarm-name HighCPUUsage 
--metric-name CPUUtilization --namespace AWS/EC2 
--statistic Average --period 300 --threshold 80 
--comparison-operator GreaterThanThreshold 
--dimensions Name=InstanceId,Value=i-1234567890abcdef0  

用于审计的 AWS CloudTrail

CloudTrail 跟踪并记录 AWS 中执行的所有 API 调用。它让我们可以全面了解整个账户的操作。它帮助我们监控和记录活动以确保安全性和合规性。我们可以将 CloudTrail 与 CloudWatch 连接起来，以自动发出可疑活动的警报。

示例

设置跟踪以审计 Lambda 调用。

使用 Amazon OpenSearch 进行集中日志记录

OpenSearch(以前称为 Elasticsearch)为我们提供了可扩展的日志记录解决方案。我们可以从许多来源(例如 EC2、Lambda、CloudWatch)收集日志并将其存储在 OpenSearch 中。 Kibana 与 OpenSearch 配合使用，帮助我们分析和可视化日志。

示例

将日志从 EC2 推送到 OpenSearch，以便于存储和分析。

AWS 上的 DevOps 管道中的安全性

以下 AWS 解决方案用于在 DevOps 管道中实现安全性 −

实现 IAM 角色和权限

我们使用 IAM(身份和访问管理) 角色来控制谁可以访问 DevOps 管道中的 AWS 资源。始终根据最小特权原则授予权限(仅授予所需的权限)。

示例

创建一个允许部署到 EC2 但不删除资源的 IAM 角色。

使用 AWS Secrets Manager 管理机密

AWS Secrets Manager 帮助我们存储和管理敏感信息，如数据库密码和 API 密钥。它与其他 AWS 服务配合使用，可自动将机密注入应用程序。

示例

将数据库密码存储在 Secrets Manager 中，并使用 AWS Secrets Manager SDK 在 Lambda 函数中安全地访问它们。

保护 CI/CD 管道

我们使用IAM 角色和策略来控制对 CodePipeline、CodeBuild 等服务的访问。机密(例如 API 密钥)应存储在 AWS Secrets Manager 中，而不是代码存储库中。确保 CodeBuild 和 CodePipeline 中的所有工件和日志都已加密。

示例

使用 aws kms encrypt 保护管道中的敏感数据。

DevOps 工作流中的扩展和弹性

在本节中，我们重点介绍了有助于 DevOps 工作流中的扩展和弹性的 AWS 工具 −

使用 AWS Elastic Beanstalk 进行自动扩展

Elastic Beanstalk 会根据需求自动调整 EC2 实例的数量。它根据我们设置的阈值进行扩展。

示例

为 Elastic Beanstalk 环境设置自动扩展，以更好地处理流量高峰。

使用 Amazon ECS/EKS 管理容器化应用程序

Amazon ECS(Elastic Container Service)和Amazon EKS(Elastic Kubernetes Service)使管理容器变得更加容易。ECS 与 AWS Fargate 配合使用以运行无服务器容器。 EKS 帮助我们管理 Kubernetes 集群，以实现更灵活的应用程序。

示例

使用 ECS 服务自动扩展功能，根据 CPU 使用率扩展容器。

使用 AWS 故障注入模拟器确保弹性

AWS 故障注入模拟器 让我们可以模拟故障并测试系统的弹性。它帮助我们发现应用程序中的弱点并提高容错能力。

示例

模拟网络故障，查看应用程序如何应对中断并改进恢复计划。

结论

在本章中，我们解释了 DevOps 工作流的所有重要 AWS 服务和实践。我们研究了使用 AWS CloudWatch 进行监控、使用 CloudTrail 进行审计以及使用 OpenSearch 进行集中日志记录。我们还讨论了如何使用 IAM 角色、AWS Secrets Manager 以及弹性和可扩展性的最佳实践来保护 CI/CD 管道。我们介绍了 Elastic Beanstalk、ECS/EKS 和 AWS 故障注入模拟器等服务。

通过使用这些 AWS 工具，DevOps 团队可以更好地实现自动化、提高安全性、确保可扩展性并使系统更具弹性。这可以实现更快、更可靠的软件交付。

DevOps - Azure 解决方案

Azure 上的 DevOps 就是将开发和 IT 运营结合在一起。它帮助我们更快地交付软件，质量更高，可靠性更高。Azure 为我们提供了一个强大的平台来设置 DevOps。它具有用于持续集成 (CI)、持续交付 (CD)、基础设施即代码 (IaC) 和监控的工具。

借助 Azure DevOps，我们可以管理代码存储库、自动化工作流，并轻松将应用部署到 Azure App Service 或 Kubernetes 等服务。它具有不同的服务，如 Azure Repos、Pipelines、Boards、Artifacts 和 Test Plans。这些服务在 DevOps 生命周期的每一步都有所帮助。它们使协作变得简单，并创建了顺畅的交付流程。

为什么选择 Azure 进行 DevOps?

Azure 为我们提供了完整的 DevOps 解决方案。它配备了企业级工具、出色的可扩展性和全球可用性。它支持多种编程语言、框架和第三方工具。这使其能够灵活地适用于不同类型的项目。

Azure DevOps 以其强大的 CI/CD 管道而闻名。它与 GitHub 配合良好，使将应用程序部署到 Azure 云变得简单。安全性是一大重点。Azure Key Vault 等工具可帮助我们管理机密，而 Azure Policy 则负责治理。

Azure 还使用 AI 为我们提供见解和监控工具，例如 Application Insights。这些有助于在问题变成大问题之前解决问题并提高性能。所有这些使 Azure 成为现代 DevOps 实践的绝佳平台。

设置 Azure DevOps

Azure DevOps 为我们提供了处理整个软件流程的工具，从规划到部署。设置很简单。我们准备环境，创建组织，并使用 Azure Repos 和 Pipelines 等服务。让我们一步一步来。

先决条件

开始之前，请确保已准备好这些 −

• Azure 帐户 − 您可以在 Azure 门户 上创建一个。
• 订阅 −高级功能需要有效的 Azure 订阅。
• Git 已安装 − 检查 Git 是否已安装。使用 git --version 进行确认。
• 开发环境 − 使用 Visual Studio 或 VS Code 等工具。它们可直接与 Azure DevOps 配合使用。

创建 Azure DevOps 组织

Azure DevOps 中的组织就像项目和用户的主要容器。

登录 −转到 Azure DevOps 并使用您的 Microsoft 帐户登录。

创建组织

• 单击"新建组织"。
• 输入名称(如 MyDevOpsOrg)，然后选择区域。
• 单击"继续"。
• 添加项目:
• 在您的组织内，单击新建项目。
• 添加详细信息，如项目名称、可见性(私有或公共)和版本控制(Git 或 TFVC)。

下面给出了用于设置管道的示例 YAML −

trigger:
  - main
pool:
  vmImage: 'ubuntu-latest'
steps:
  - script: echo "Hello Azure DevOps!"
    displayName: 'Print Message'

Azure DevOps 服务概述

Azure DevOps 提供多种服务。我们可以选择并仅使用我们需要的服务 −

Azure Repos − 帮助我们管理代码存储库。推送代码的示例 −

git init
git remote add origin https://dev.azure.com/MyDevOpsOrg/MyProject/_git/MyRepo
git add .
git commit -m "Initial commit"
git push -u origin main

Azure Pipelines − 自动化 CI/CD 工作流。例如，部署 Node.js

app:
pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '14.x'
  - script: npm install
    displayName: 'Install Dependencies'
  - script: npm test
    displayName: 'Run Tests'

Azure Boards − 跟踪任务、冲刺和总体进度。

Azure Test Plans − 让我们管理和自动化测试。

Azure Artifacts − 处理和共享 npm、Maven 或 NuGet 等包。

此设置可轻松将 Azure DevOps 融入现有工作流。它高效且可扩展以满足不同的需求。

Azure Pipelines:CI/CD

Azure Pipelines 帮助我们自动构建、测试和部署应用程序。它有两个选项 - YAML 管道(提供更大的灵活性)和具有简单图形界面的经典管道。以下是我们如何创建和使用这些管道进行持续集成 (CI) 和持续部署 (CD)。

创建构建管道

构建管道可帮助我们编译源代码、运行测试和创建构建工件。

创建步骤

• 在 Azure DevOps 项目中打开管道。
• 单击新建管道。
• 选择所需的存储库(如 GitHub 或 Azure Repos)。
• 选择 YAML 文件或使用模板进行设置。

.NET 项目的 YAML 构建管道示例 −

trigger:
  - main
pool:
  vmImage: 'windows-latest'
steps:
  - task: UseDotNet@2
    inputs:
      packageType: 'sdk'
      version: '6.x'
  - script: dotnet build
    displayName: 'Build the project'
  - script: dotnet test
    displayName: 'Run Unit Tests'

将此文件作为 azure-pipelines.yml 保存在您的存储库的主文件夹中。

每次我们推送到主分支时，此管道都会运行。

设置发布管道

发布管道让我们可以将构建工件部署到暂存或生产等环境中。

创建步骤 −

• 转到管道 >发布。
• 单击新建管道并选择一个模板(如 Azure 应用服务部署)。
• 将其链接到构建管道中的构建工件。
• 添加部署阶段(例如，开发、测试、生产)。

Web 应用部署的示例配置 −

• 工件源 − 链接到构建管道的输出。
• 任务 − 添加 Azure 应用服务部署任务。填写应用服务名称、包或文件夹以及 Azure 订阅。

YAML 管道与传统管道

下表重点介绍了 YAML 管道与传统管道的不同之处 −

trigger:
  - main
pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: AzureWebApp@1
    inputs:
      azureSubscription: '<Your Azure Subscription>'
      appName: '<Your App Service Name>'
      package: '$(Pipeline.Workspace)/drop/*.zip'

YAML 管道最适合大型项目和团队。它们允许自动化和协作。经典管道更简单，适合快速设置，或者当 YAML 看起来太复杂时。

使用 Azure 实现基础设施即代码 (IaC)

基础设施即代码 (IaC) 帮助我们使用代码管理云资源。它使配置自动化和更简单。Azure 支持许多 IaC 工具。这些工具带来一致性、版本控制和易于重复性。我们可以使用 Azure 资源管理器 (ARM) 模板、Terraform 或类似工具轻松定义和部署基础设施。

Azure 上的 IaC 简介

Azure 使用 − 支持 IaC

• ARM 模板 − 这些是专为 Azure 制作的基于 JSON 的模板。
• Terraform −可跨不同云(包括 Azure)运行的第三方工具。

使用 IaC 可减少错误，因为它消除了大多数手动步骤。它使环境保持一致，并使回滚更改更加容易。当我们将 IaC 与 CI/CD 管道结合使用时，它可确保基础设施的顺利和自动化设置。

使用 Azure 资源管理器 (ARM) 模板

ARM 模板以 JSON 形式定义 Azure 资源。它们以声明方式工作，因此我们编写所需的内容，然后 Azure 进行设置。

结构

• 资源 − 列出要部署的 Azure 服务。
• 参数 − 这些使模板可重复使用。我们可以提供名称或区域等输入。
• 输出 −它们在部署后返回关键信息。

虚拟机的 ARM 模板示例

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vmName": { "type": "string" },
    "adminUsername": { "type": "string" },
    "adminPassword": { "type": "securestring" }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2021-07-01",
      "name": "[parameters('vmName')]",
      "location": "eastus",
      "properties": {
        "hardwareProfile": { "vmSize": "Standard_DS1_v2" },
        "osProfile": {
          "computerName": "[parameters('vmName')]",
          "adminUsername": "[parameters('adminUsername')]",
          "adminPassword": "[parameters('adminPassword')]"
        }
      }
    }
  ]
}

部署 − 使用 Azure CLI 进行部署。

使用 Terraform 和 Azure 管理 IaC

Terraform 是我们可以用来管理 Azure 资源的另一种工具。它非常灵活，支持多个云，并跟踪资源的状态。

安装 Terraform − 从 Terraform 下载 下载 Terraform。

创建 Terraform 配置

provider "azurerm" {
   features {}
}
resource "azurerm_resource_group" "example" {
   name     = "example-resources"
   location = "eastus"
}
resource "azurerm_storage_account" "example" {
   name                     = "examplestorageacct"
   resource_group_name      = azurerm_resource_group.example.name
   location                 = azurerm_resource_group.example.location
   account_tier             = "Standard"
   account_replication_type = "LRS"
}

使用以下命令管理资源 −

初始化

terraform init

计划

terraform plan

应用

terraform apply

Terraform 让我们可以重复使用配置、管理状态并使用许多社区模块。这些使管理 Azure 资源变得更容易、更快捷。

使用 Azure 进行监控和日志记录

Azure 为我们提供了强大的工具来跟踪资源的执行情况、应用程序的运行情况以及发现任何问题。以下是表格形式的简单概述。

Azure DevOps 中的安全性

Azure DevOps 提供内置安全功能来保护我们的资源、管理机密数据并确保管道安全。以下是简要摘要。

使用 Key Vault 集成进行安全部署的 YAML 示例 −

trigger:
  - main
pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: AzureKeyVault@2
    inputs:
      azureSubscription: 'MyAzureSubscription'
      KeyVaultName: 'MyKeyVault'
      SecretsFilter: '*'
  - script: echo $(mySecret)
    displayName: 'Display Secret for Debugging'

结论

在本章中，我们重点介绍了如何设置 Azure DevOps、创建 CI/CD 管道、使用 ARM 模板和 Terraform 的基础设施即代码 (IaC)，以及确保我们的监控、日志记录和安全实践强大。

通过使用 Azure Monitor、Application Insights 和 Log Analytics，我们改善了资源管理和可观察性。我们还讨论了如何通过控制访问、使用 Azure Key Vault 管理机密以及向管道添加安全测试来保护 Azure DevOps。这些实践有助于自动化、保护和监控软件交付过程，使 Azure 上的 DevOps 工作流更高效、更可靠、更安全。

DevOps - 持续开发

持续开发 (CD) 意味着自动化和改进软件开发的各个阶段，从编写代码到部署代码。这有助于快速顺利地发布更新。

持续开发的目标

持续开发的关键目标是:

• 频繁的代码更新 − 快速提供新功能、改进和错误修复。
• 自动化 − 自动化集成、测试和构建，以减少人为错误并加快开发速度。
• 协作 − 改善开发人员、QA 团队和运营团队合作，以实现顺利部署。
• 质量 −即使频繁更新，也能保持较高的代码质量和稳定性。

主要目的是加快上市时间、降低风险，并帮助团队更快地响应用户需求和业务目标。

持续开发如何融入 DevOps 生命周期?

持续开发是 DevOps 生命周期的重要组成部分。它专注于在代码发布到生产之前实现自动化和改进开发。以下是它如何融入 −

• 持续开发在持续集成 (CI) 之后开始。在 CI 中，代码更改会合并到共享存储库中。CI 确保代码经过测试并自动构建。
• CD 更进一步，实现了构建和集成过程的自动化。代码集成后，将经历自动构建和准备阶段，为部署做好准备。
• 开发阶段结束后，即使代码已准备好投入生产，CD 也能确保代码能够顺利进入部署或准备阶段。

简而言之，持续开发可帮助 DevOps 团队保持稳定的流程。它让他们能够快速处理许多代码更改和发布，同时保持流程的顺畅和自动化。

现在，让我们继续了解持续开发中的一些关键概念。

代码集成和协作

在持续开发中，代码集成和协作是使开发过程更快更顺畅的关键。它有助于团队成员有效地协同工作。以下是主要要点 −

• 开发人员经常推送代码。这有助于及时更新共享存储库。
• GitHub、GitLab 或 Bitbucket 等工具可帮助团队协同工作。它们可以轻松完成代码审查和合并。
• CI 管道提供自动反馈。这有助于开发人员尽早发现问题并改善团队合作，从而减少集成问题。

主要目标是保持稳定的更新流，减少冲突，并确保所有更改都能顺利融入通用代码库。

版本控制在持续开发中的作用

版本控制在持续开发中非常重要。它可以帮助团队简单地管理和跟踪代码更改。这就是它重要的原因:

• 像 Git 这样的版本控制系统 (VCS) 会跟踪每个代码更改。开发人员可以查看更改历史记录，并在需要时返回到早期版本。
• VCS 允许许多开发人员在同一个项目上工作，而不会覆盖彼此的工作。通过分支和合并，团队可以同时处理不同的功能或修复。
• 版本控制有助于管理不同的代码版本。它使发布新版本和应用补丁变得容易，而不会影响主要生产代码。

通过使用分支策略(如功能分支和修补程序)，团队可以确保他们的工作是分开的。他们可以在准备就绪时合并它，在允许持续开发的同时保持主代码的稳定性。

构建持续开发管道

持续开发管道自动将代码从提交移动到部署就绪的过程。基本工作流程有几个阶段 −

• 代码提交 −开发人员将他们的更改提交给 Git 等共享版本控制系统。
• 构建 − 使用 Jenkins 或 GitLab CI 等 CI 工具自动构建代码。这确保更改与现有代码配合良好。
• 静态代码分析 − 自动化工具检查代码质量，例如 linting 和安全扫描。
• 工件创建 − 代码被打包成可部署的工件，例如 Docker 镜像或 JAR 文件。
• 暂存/预生产 − 代码被部署到暂存环境。它就像最终测试的生产环境一样。
• 生产批准 −如果代码通过了所有测试，则将其标记为已准备好进行生产部署。

此管道有助于以更少的人力和更快的速度集成、构建和准备用于生产的代码。

工具和技术:Git、Jenkins、GitLab 等

许多工具对于设置和管理持续开发管道都很重要 −

• Git − 这是主要的版本控制系统。它帮助我们跟踪更改、分支和与团队成员协作。
• Jenkins − Jenkins 是一种流行的自动化服务器。它与许多工具配合使用，可自动执行构建、测试和部署代码等任务。我们可以自定义 Jenkins 来支持复杂的工作流程。
• GitLab − GitLab 是一个完整的 DevOps 平台。它将 Git 版本控制与内置的 CI/CD 功能相结合。GitLab 将代码管理与 CI 管道顺利连接起来。
• CircleCI − CircleCI 是一个 CI/CD 平台。它专注于通过可扩展性和易用性实现开发工作流程的自动化。
• Travis CI − Travis CI 是一个基于云的 CI 工具。它与 GitHub 集成以自动化构建和部署任务。

这些工具协同工作以自动化整个管道，从提交代码到使其准备好部署。这确保我们拥有顺畅一致的开发过程。

自动化代码编译和构建过程

持续开发中的自动化有助于消除手动步骤。这可以节省时间并减少错误。代码编译和构建过程是自动化最重要的部分之一。步骤通常包括 −

• 代码编译 − 源代码会自动编译为可执行代码或库。
• 构建自动化 − 我们使用 Maven(用于 Java)、Gradle 或 npm(用于 JavaScript)等工具将代码打包成可部署的工件。
• 工件管理 − Nexus 或 Artifactory 等工具存储和管理这些构建工件。这样，我们在需要部署时就可以轻松访问它们。

通过自动执行这些步骤，我们确保每个代码更改都自动构建和测试。这样可以保持一切一致，并消除人为错误的可能性。

使用 Jenkins 设置自动构建

Jenkins 是一种用于管理持续开发管道的著名自动化工具。以下是我们在 Jenkins 中设置自动构建的方法:

安装 Jenkins − 从 jenkins.io 下载 Jenkins。将其安装在服务器上或作为容器运行。

创建新作业:在 Jenkins 中，单击"新项目"，命名作业，然后选择"自由式项目"。单击确定以创建作业。

连接到 Git 存储库:在源代码管理部分下，选择Git。输入存储库 URL 和身份验证详细信息(如果需要)。例如，

Repository URL: https://github.com/yourrepo/yourproject.git
Credentials: your-credentials-id

定义构建步骤 − 在构建部分，添加构建步骤以使用构建工具编译代码。例如，对于 Maven 项目，它将像这样 −

mvn clean install

构建后操作 −我们可以定义构建后的操作，例如存档构建工件或运行部署脚本。例如，

Archive Artifacts: target/*.jar

安排或触发构建 − 我们可以设置触发器来运行构建。这可以是代码推送(使用 Git webhook)或计划。

示例 − 根据代码更改进行构建

Build Triggers: GitHub hook trigger for GITScm polling

设置完成后，每当发生更改时，Jenkins 都会自动构建代码。这确保了构建过程保持一致和可靠，而无需我们手动执行。

简化持续开发:最佳实践、工具和策略

下表重点介绍了简化持续开发时应用的最佳实践、工具和策略 −

结论

在本章中，我们探讨了简化持续开发的关键思想和最佳实践。我们专注于管理频繁的代码更改、改善协作以及以良好的方式使用版本控制。我们讨论了 Git、Jenkins 和 Slack 等工具如何帮助我们获得更快的反馈、更顺畅的集成和更高效的工作流程。

通过使用功能分支、合并请求和分支模型(如 GitFlow 或基于主干的开发)等策略，我们可以使开发周期更快、更具可扩展性。这些做法有助于我们保持高质量、持续的交付。它们还可以减少摩擦并改善开发和运营团队之间的协作。

DevOps - 持续集成

持续集成 (CI) 是 DevOps 的关键部分。这意味着开发人员每天多次将他们的代码更改合并到共享存储库中。每次集成都会启动自动构建和测试过程。这有助于在开发过程的早期发现错误。目标是更快地修复错误，提高软件质量，并使产品始终准备好部署。

什么是持续集成 (CI)?

CI 可以轻松地将来自多个贡献者的代码更改合并到一个项目中。Jenkins、GitLab CI/CD 和 GitHub Actions 等工具有助于设置用于构建、测试和检查代码的管道。

例如，在基于 Git 的项目中，开发人员将其代码提交到分支。然后，CI 工具会自动编译代码、运行测试并提供有关更改的反馈。

为什么我们需要 SDLC 中的持续集成?

CI 对于开发人员之间的顺畅团队合作非常重要。它解决了"集成地狱"，即合并来自不同开发人员的代码会导致重大冲突或错误。

借助 CI，团队可以执行以下操作 −

• 尽早发现问题 − 自动化构建和测试可以快速捕获语法错误或测试失败等问题。例如，如果开发人员添加了单元测试失败的代码，则 CI 管道会发现问题并阻止损坏的代码影响其他代码。
• 避免合并冲突 − 定期集成可减少代码发生冲突的可能性。
• 加快交付速度 − 自动化减少了手动工作，因此发布速度更快。例如，CI 管道可在不到 10 分钟的时间内编译代码、测试代码并创建部署包。

通过使用 CI，团队可以创建更好的软件并在软件开发生命周期 (SDLC) 中更快地工作。

持续集成的关键概念

持续集成基于一些关键思想。这些思想确保开发过程顺利且自动化。让我们来了解一下。

版本控制系统 (VCS) 和 CI

Git、Subversion 或 Mercurial 等版本控制系统 (VCS) 有助于跟踪代码更改。CI 管道与 VCS 配合使用，以监视代码存储库中的新提交或拉取请求。当发生任何变化时，管道会自动运行。

示例

在 Git 中，类似分支的功能/新登录会合并到主分支中。 CI 工具注意到了这一点并启动管道。

配置 (GitHub Actions YAML) −

on:
  push:
    branches:
      - main

此设置确保在将每个更改添加到主分支之前对其进行检查。

自动构建

自动构建将源代码转换为可执行二进制文件或工件。此步骤检查代码是否有语法错误或未解决的依赖项。

示例

使用 Jenkins 的 Node.js 项目可以自动执行构建过程。

脚本 (Jenkinsfile)−

pipeline {
   stages {
      stage('Build') {
         steps {
            sh 'npm install'
            sh 'npm run build'
         }
      }
   }
}

此脚本安装依赖项并创建可用于生产的版本。

自动测试

CI 包含自动测试，用于检查代码是否符合预定义规则。这些测试可以包括单元测试、集成测试或功能测试。

示例

使用 pytest 运行单元测试的 Python 项目。

GitLab CI/CD YAML −

test:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest

如果任何测试失败，管道就会停止。这可以防止错误代码进一步发展。

CI 管道及其组件

CI 管道可自动化整个过程。它有几个重要部分 −

• 触发器 − 提交、合并或拉取请求等事件。示例触发器:在 GitHub Actions 中 on: push。
• 阶段 − 构建、测试和部署等步骤。
• 作业 − 每个阶段内的任务，例如运行测试。
• 工件 − 输出，如日志或构建文件。
• 通知 −当某项操作成功或失败时向开发人员发送消息。

示例

CI 管道的 Jenkinsfile −

pipeline {
   agent any
   stages {
      stage('Build') {
         steps {
            sh 'mvn package'
         }
      }
      stage('Test') {
         steps {
            sh 'mvn test'
         }
      }
   }
   post {
      always {
         mail to: 'team@example.com',
         subject: "Pipeline ${currentBuild.result}",
         body: "Pipeline completed with status: ${currentBuild.result}"
      }
   }
}

管道的每个部分都确保代码更改经过适当测试并准备好部署。

CI 工具示例:Jenkins

Jenkins 是持续集成 (CI) 最流行的工具之一。它是开源的，支持许多用于构建、测试和部署应用程序的插件。我们可以轻松设置它并开始自动化我们的工作流程。

安装和配置 Jenkins

安装 − 在您的系统或服务器上安装 Jenkins。对于 Ubuntu，请按照以下步骤 −

sudo apt update
sudo apt install openjdk-11-jre
wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt update
sudo apt install jenkins

在浏览器中打开 Jenkins，网址为 http://<your-server-ip>:8080。

初始配置:获取管理员密码 −

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

登录 Jenkins，安装建议的插件，然后创建管理员用户。

集成 Git − 转到 管理 Jenkins > 插件管理器。安装 Git 插件。在"管理 Jenkins">"全局工具配置"下配置您的 Git 存储库。

设置基本 Jenkins 管道

创建新的管道作业。单击新项目>"管道">"确定"。

将管道脚本添加到作业配置。在管道部分中使用此脚本:

pipeline {
   agent any
   stages {
      stage('Clone Repository') {
         steps {
           git 'https://github.com/your-repo/sample-app.git'
         }
      }
   }
}

每次管道运行时，这将克隆您的存储库。

添加阶段:构建、测试和部署

我们可以通过添加构建、测试和部署应用程序的阶段来改进管道。

Jenkinsfile 示例

pipeline {
   agent any
   stages {
      stage('Clone Repository') {
         steps {
            git 'https://github.com/your-repo/sample-app.git'
         }
      }
      stage('Build') {
         steps {
            sh './build.sh' // or your build command
         }
      }
      stage('Test') {
         steps {
            sh './run-tests.sh' // Run unit tests
         }
      }
      stage('Deploy') {
         steps {
            sh './deploy.sh' // Deploy to staging
         }
      }
   }
   post {
      success {
         echo 'Pipeline completed successfully.'
      }
      failure {
         echo 'Pipeline failed.'
      }
   }
}

重要配置:

• 使用项目特定命令更新 ./build.sh、./run-tests.sh 和 ./deploy.sh。
• 使用电子邮件扩展等插件向团队发送通知。

此 Jenkins 管道可自动执行代码集成。它通过测试确保质量并帮助高效部署应用程序。它完美遵循了 CI 原则，使开发过程更加顺畅。

持续集成的最佳实践

下表总结了持续集成中的一些最佳实践 −

持续集成中的挑战

下表重点介绍了开发人员在实施持续集成时必须面对的挑战以及克服这些挑战的解决方案 −

结论

在本章中，我们研究了持续集成 (CI) 的主要思想。我们讨论了 CI 在软件开发生命周期 (SDLC) 中的重要性。我们还介绍了经常提交代码、使用自动构建和测试等关键实践。然后，我们讨论了 CI 管道的结构。

我们还探索了 Jenkins 作为实用的 CI 工具。我们研究了有助于改进 CI 流程的最佳实践。最后，我们讨论了常见问题，例如合并冲突和大型团队的 CI 扩展。

通过使用这些方法，团队可以加快交付速度、提高代码质量并更好地协同工作。这将有助于创建强大而高效的软件开发流程。

DevOps - 持续测试

持续测试意味着在软件交付过程中自动运行测试。它可以快速反馈软件的质量。这有助于我们尽早发现和解决问题，从而加快开发速度并提高效率。

DevOps 中的持续测试是什么?

在 DevOps 中，持续测试内置于 CI/CD 管道的每个步骤中。它会在进入下一阶段之前检查代码更改是否符合质量标准。

持续测试的主要部分是:

• 自动化 −我们自动化可重复的测试任务，使其更快、更可靠。
• 集成 − 它可与 CI/CD 工具(如 Jenkins、GitLab 或 CircleCI)顺利配合使用。
• 反馈循环 − 开发人员和利益相关者可实时获取测试结果更新。

以下是 DevOps 中持续测试的好处 −

• 早期错误检测 − 在生产之前尽早发现问题。
• 更快的上市时间 −加快开发和交付。
• 提高代码质量 − 保持测试标准一致。

为什么我们需要在 DevOps 中进行持续测试?

持续测试在 DevOps 中非常重要，因为它支持快速且重复的开发周期。原因如下 −

• 降低风险 − 尽早发现错误。这降低了生产中出现大问题的可能性。
• 更快的交付 − 自动化测试节省了时间，帮助我们更快地发布软件而不会降低质量。
• 增强协作 − 它将测试与开发联系起来。这有助于开发人员、测试人员和运营团队更好地协作。
• 更好的客户体验 − 尽早解决问题可确保为用户提供稳定可靠的应用程序。

通过在 DevOps 流程的每一步添加测试，我们可以跟上现代软件开发的快速步伐，同时保持高质量。

持续测试的关键组成部分

持续测试取决于三个主要因素。这些是用于测试的自动化工具、与生产相匹配的环境以及与 CI/CD 管道集成以实现顺畅的工作流程。

测试自动化工具

测试自动化工具使重复和复杂的测试变得简单。它们帮助我们获得更快、更可靠的结果。

流行的测试自动化工具包括以下内容 −

• Selenium − 自动化浏览器操作以进行功能测试。
• JUnit/TestNG − 帮助进行 Java 应用程序的单元测试和回归测试。
• Postman − 使用集合和脚本使 API 测试变得简单。
• Cypress −专注于现代 Web 应用的端到端测试。

测试环境和基础设施

良好的测试环境和可扩展的基础设施非常重要。它们确保我们的测试像在现实生活中一样运行。

• 容器化 − Docker 等工具为开发和测试提供了相同的环境。
• 基于云的环境 − AWS Device Farm 或 BrowserStack 等服务让我们可以在不同的设备和操作系统上进行测试。
• 基础设施即代码 (IaC) − Terraform 等工具帮助我们使用代码创建和管理测试设置。

保持测试环境与生产设置相似。经常更新环境以匹配新的依赖项和版本。

与 CI/CD 管道集成

持续测试在成为 CI/CD 工作流的一部分时效果最佳。它确保在软件交付的每个步骤中都进行质量检查。

这就是它的工作原理 −

• 每次提交或构建代码时，测试都会自动运行。
• 如果测试失败，管道会立即停止，开发人员会得到快速反馈。
• Jenkins、GitLab CI 和 Azure DevOps 等工具使流程更容易。

同时运行测试以节省时间。对单元、集成和性能测试使用不同的管道。自动化测试报告，以便更好地跟踪和问责。

这些组件共同帮助我们更快地交付软件，降低风险，提高质量。

在 DevOps 中设置持续测试

我们使用持续测试来检查 DevOps 生命周期每个阶段的质量。设置它涉及建立强大的框架、选择正确的工具以及顺利地将测试添加到 CI/CD 工作流程中。让我们一步一步地分解。

步骤 1. 准备测试框架

测试框架就像基础。它帮助我们自动化和管理测试。以下是要遵循的步骤 –

• 定义要测试的内容 − 决定要自动化哪些测试(单元、集成或性能)。
• 选择框架 − 选择与您的语言和测试类型相匹配的框架。例如:使用 JUnit 进行 Java 单元测试。使用 PyTest 进行 Python。
• 设置 −组织文件夹并安装依赖项。

JUnit 的 Maven pom.xml 示例−

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.13.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

创建模块化结构以重用测试用例。添加日志和报告以更快地进行调试。

第 2 步。选择正确的测试工具

我们必须选择适合项目需求并与 DevOps 流程配合使用的工具。

• 了解需求 − 对于 UI 测试，请尝试 Selenium 或 Cypress。对于 API 测试，请使用 Postman 或 Rest-Assured。
• 检查工具兼容性 −确保工具可与 Jenkins 或 GitLab 等 CI/CD 系统配合使用。然后，设置该工具。

示例:将 Selenium 添加到 Java 项目 −

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.1.0</version>
</dependency>

安装驱动程序并设置浏览器设置。

选择支持并行运行的工具以节省时间。确保工具可以在项目增长时处理更多测试用例。

第 3 步。将测试集成到 DevOps 工作流中

为了使测试顺利进行，我们需要将其与 CI/CD 管道连接起来。首先，将测试添加到 CI/CD。查看以下示例 −

示例 Jenkins 管道 −

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
    }
}

设置触发器 − 每当有代码提交或拉取请求时，运行测试。

创建报告 − 使用 Allure 等插件或内置工具清晰地查看测试结果。

每次提交时运行小型测试(如单元测试)。较少运行大型测试(如性能测试)。关注测试速度并改进管道。

持续测试的类型

下表总结了持续测试的类型 −

实施测试自动化

我们可以通过在 DevOps 管道中实施测试自动化来改进测试过程。这有助于加快速度并使软件交付更加可靠。该过程包括编写自动化测试脚本、管理测试用例和数据以及作为 CI/CD 管道的一部分自动运行测试。

编写自动化测试脚本

编写自动化测试脚本对于无需人工帮助即可测试应用程序非常重要。这些测试可确保代​​码在每次更新或更改后都能按预期工作。

以下是编写自动化测试脚本所需的工具 −

• Selenium 用于在浏览器中测试 UI。
• JUnit 或 TestNG 用于 Java 应用程序中的单元测试。
• PyTest 用于 Python 应用程序。

确保脚本清晰、可重用且易于维护。使用页面对象模型 (POM) 进行 UI 测试，使脚本更易于管理。

示例(计算器应用程序的 JUnit 测试) −

@Test
public void testAddition() {
    Calculator calc = new Calculator();
    int result = calc.add(2, 3);
    assertEquals(5, result);
}

管理测试用例和数据

我们需要妥善管理可扩展测试套件的测试用例和数据。这涉及组织测试用例、管理测试数据以及确保测试环境在所有测试执行中保持一致。

测试用例管理 − 使用 TestRail 或 Jira 等工具来组织和跟踪测试用例。

测试数据管理 − 将测试数据存储在配置文件或数据库中。使用 Mockaroo 或 Factory Boy 等工具生成动态测试数据。

示例(测试用例中测试数据的 YAML 配置) −

test_data:
  - input: "2, 3"
    expected_output: "5"
  - input: "4, 5"
    expected_output: "9"

自动触发测试

我们可以将测试作为 CI/CD 管道的一部分自动运行。这样，每次代码更改时都会运行测试，从而快速向开发人员提供反馈。

CI/CD 集成:将测试集成到 CI/CD 工具中，例如 Jenkins、GitLab CI 或 Azure DevOps。

示例(用于触发测试的 Jenkins 管道配置) −

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
    }
}

提交时触发 − 设置管道以在每次提交或拉取请求时自动触发测试。

计划运行 − 使用 Cron 等工具或内置的 Jenkins 功能定期运行测试，并确保新的代码更改不会导致问题。

通过自动执行这些步骤，我们可以更快、更可靠地执行测试。这有助于提高开发流程的效率和质量。

持续测试的最佳实践和挑战

下表重点介绍了持续测试的最佳实践和挑战 −

结论

在本章中，我们讨论了 DevOps 中持续测试的关键点。我们介绍了它的重要性、主要部分以及实施它的步骤。我们讨论了测试自动化、管理测试用例和数据以及将测试添加到 CI/CD 管道中。

我们还研究了常见问题，例如测试不稳定、可扩展性问题以及保持测试环境一致。通过使用这些策略，团队可以提高软件交付的速度、可靠性和效率。这有助于在更快的开发周期中创建更好的产品。

DevOps - 持续交付

持续交付 (CD) 是一种软件开发实践。它专注于自动化将代码更改交付到类似于生产的环境的方式。主要目标是始终保持代码随时可以部署。这允许更频繁的发布。CD 通过自动化发布过程建立在持续集成 (CI) 的基础上。但它在代码直接部署到生产环境之前就停止了。

在典型的 CD 管道中，自动化测试、构建流程和暂存环境可确保软件始终可以部署。CD 在 DevOps 中非常重要。它有助于快速、可靠且频繁地发布软件。它还改善了开发和运营团队的协作方式。

持续部署 (CI) 和持续交付 (CD) 之间的区别

持续集成 (CI) 和持续交付 (CD) 都有助于改进软件发布流程。但它们在某些方面有所不同 −

• 持续集成 (CI) − CI 是关于经常将代码更改合并到主代码库中。它运行自动化测试以确保软件始终处于工作状态。CI 不会自动将软件发布到生产环境。
• 持续交付 (CD) − CD 建立在 CI 的基础上。它自动将部署过程部署到与生产环境类似的环境中。CD 确保通过自动化测试的每项更改都已准备好投入生产。但它不会自动部署。

主要区别在于最后一步。CI 专注于集成和测试。CD 自动化发布过程，但部署到生产环境可能仍需要人工批准。

为什么我们需要在 DevOps 环境中进行持续交付?

出于多种原因，持续交付在 DevOps 中很重要 −

• 更快的发布: − 自动化发布过程可加快代码从开发到生产的进程。这允许更快、更频繁地发布。
• 提高质量 − 通过自动化测试和部署，CD 可确保只有经过测试的代码才能投入生产。这减少了错误和缺陷。
• 更好的协作 − CD 帮助开发和运营团队更好地协作。它使从开发到部署的交接更加顺畅。
• 更少的手动工作 − 自动化部署步骤降低了人为错误的可能性。这使流程更加可靠。
• 可扩展性 − CD 帮助组织发展其交付流程。随着团队和应用程序的增长，CD 支持更快的变更和更多的创新。

简而言之，CD 帮助 DevOps 团队以更快的速度、更好的质量和更低的风险交付价值。它是现代软件开发的关键部分。

构建持续交付管道

持续交付 (CD) 管道自动化了将代码从开发转移到生产的过程。管道有几个阶段，如构建、测试、部署和监控。

目标是确保代码始终以自动化和可靠的方式准备好投入生产。 CD 管道包括版本控制、构建自动化、自动化测试、部署自动化和监控工具等重要部分。

关键阶段通常包括以下内容:

• 源代码 − 从版本控制系统 (VCS) 获取代码。
• 构建 − 编译代码、解决依赖关系并创建可部署工件。
• 测试 − 运行自动化测试以检查代码的质量和正确性。
• 部署 − 将应用程序部署到暂存或生产环境。
• 监控 − 确保应用程序在部署后运行良好。

设计和构建持续交付管道

良好的 CD 管道将流程分为几个阶段，每个阶段都有其工作。以下是典型管道的设置方式 −

源代码阶段 − 这是第一阶段。当更改被推送到版本控制系统(例如 Git)时，管道就会启动。它会从存储库中获取最新代码。请看以下示例 −

git:
  branch: master
  repository: https://github.com/your-repo.git

构建阶段 − 构建阶段编译代码、修复依赖项并生成工件(例如 JAR、WAR 文件)。这里使用 Maven、Gradle 或 npm 等工具。

示例(Maven 构建) −

$ mvn clean install

测试阶段 − 运行自动测试(单元测试、集成测试)以检查代码。此阶段确保新更改不会破坏任何内容。

示例(JUnit 测试命令) −

$ mvn test

部署阶段 −此阶段自动将应用程序部署到暂存或生产环境。通常使用 Docker、Kubernetes 或 Ansible。

示例(使用 Docker 部署)−

docker build -t myapp .
docker run -d myapp

监控阶段 − 部署后，监控工具(例如 Prometheus、Grafana)会检查应用程序的运行状况和性能，以确保其正常运行。

集成版本控制、构建自动化和部署工具

CD 管道使用多种工具协同工作以自动化交付过程:

版本控制 − Git 通常用于源代码管理。每个更改都会在存储库中进行跟踪，从而启动管道。

Jenkins 中的 Git 配置示例 −

pipeline {
   agent any
   stages {
      stage('Checkout') {
         steps {
            git branch: 'master', url: 'https://github.com/your-repo.git'
         }
      }
   }
}

构建自动化 − Maven、Gradle 或 npm 等工具负责编译代码并将其打包成可部署的工件。

示例(Jenkins 中的 Gradle 构建) −

pipeline {
   agent any
   stages {
      stage('Build') {
         steps {
            script {
               sh 'gradle build'
            }
         }
      }
   }
}

部署工具 − Docker、Kubernetes 或 AWS CodeDeploy 等工具可自动部署到不同的环境。Docker 可用于容器化应用程序，确保其在任何环境中都能正常工作。

示例(使用 Jenkins 进行 Docker 部署) −

pipeline {
   agent any
   stages {
      stage('Deploy') {
         steps {
            script {
               sh 'docker build -t myapp .'
               sh 'docker run -d -p 8080:8080 myapp'
            }
         }
      }
   }
}

使用 Jenkins、GitLab CI 或 CircleCI 实现构建和测试阶段的自动化

自动化构建和测试阶段对于顺利的持续交付过程非常重要。Jenkins、GitLab CI 和 CircleCI 等工具可以自动执行这些步骤，减少手动工作并确保一致性。

Jenkins − Jenkins 是一种广泛使用的 CI/CD 工具。它可以自动化构建和测试过程，并与 Git、Maven、Docker 和 Kubernetes 等工具集成。

示例(用于构建和测试的 Jenkins 管道) −

pipeline {
   agent any
   stages {
      stage('Build') {
         steps {
            script {
               sh 'mvn clean install'
            }
         }
       }
       stage('Test') {
          steps {
             script {
                sh 'mvn test'
             }
          }
       }
   }
}

GitLab CI − GitLab CI 提供集成的 CI/CD 管道，可根据 Git 推送自动运行作业。它使用 .gitlab-ci.yml 文件进行配置。

示例(用于构建和测试的 GitLab CI 管道) −

stages:
  - build
  - test
build:
  stage: build
  script:
    - mvn clean install
test:
  stage: test
  script:
    - mvn test

CircleCI − CircleCI 是一种基于云的 CI/CD 服务，可与 GitHub 等版本控制系统集成。它使用 .circleci/config.yml 文件进行配置。

示例(用于构建和测试的 CircleCI 管道)−

version: 2.1
jobs:
  build:
    docker:
      - image: circleci/python:3.8
    steps:
      - checkout
      - run:
          name: Install dependencies
          command: pip install -r requirements.txt
      - run:
          name: Run tests
          command: pytest
workflows:
  version: 2
  build_and_test:
    jobs:
      - build

这些工具可以顺利地融入到管道中。它们有助于自动化构建、测试和部署，从而降低错误风险并加快软件交付速度。

持续交付中需要记住的要点

下表重点介绍了持续交付中需要注意的要点 −

结论

在本章中，我们研究了持续交付 (CD) 的主要部分。我们讨论了重要的主题，例如自动化测试、使用 Docker 和 Kubernetes 进行容器化、蓝绿和灰度部署(又名金丝雀部署)、安全实践以及大型团队的扩展。我们还讨论了如何集成 CI/CD 工具、管理功能切换、处理自动回滚以及探索自我修复管道等高级想法。

通过了解这些方法和工具，我们可以使我们的工作流程更加顺畅，提高部署可靠性，创建更好的版本，并减少手动工作。这有助于我们构建更强大、更高效的 DevOps 管道。

DevOps - 持续部署

持续部署 (CD) 是 DevOps 流程的高级部分。它会自动将经过验证的更改从版本控制直接推送到生产环境。此过程中无需手动批准。与等待人工批准的持续交付不同，持续部署使用自动化来确保更快的发布。

持续部署的主要功能

以下是持续部署的主要功能 −

• 用于构建、测试和部署代码的完全自动化流程。
• 强大的测试和验证机制，如单元、集成和性能测试。
• 可以顺利处理基础设施和应用程序更新的工具和脚本。

持续部署、持续集成和持续交付

下表重点介绍了持续部署、持续集成和持续交付之间的主要区别 −

设置持续部署管道

我们可以通过自动化构建、测试和部署代码的过程来设置持续部署 (CD) 管道。让我们一步一步来创建这个工作流程。

步骤 1:选择和配置版本控制系统 (VCS)

像 Git 这样的版本控制系统可以帮助我们管理代码更改。当开发人员将他们的更新推送到存储库时，CD 管道会自动启动。

示例:创建一个新的 GitHub 存储库 −

# 在本地初始化 Git 存储库
git init

# 添加远程存储库
git remote add origin https://github.com/user/project.git

# 提交并推送代码
git add .  
git commit -m "Initial commit"  
git push -u origin main  

我们可以使用 webhook 将此存储库连接到 Jenkins 或 GitHub Actions 等 CI/CD 工具。

第 2 步:设置 CI/CD 工具

我们需要一个 CI/CD 工具，如 GitHub Actions、Jenkins 或 GitLab CI/CD。此工具可自动执行构建、测试和部署等步骤。

示例:(GitHub Actions 配置)

在存储库中创建一个 .github/workflows/deployment.yml 文件 −

name: CI/CD Pipeline
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Install Dependencies
        run: npm install
      - name: Run Tests
        run: npm test
      - name: Build Application
        run: npm run build
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Server
        run: |
          scp -r ./build user@your-server:/var/www/app

此管道执行两项操作 −

• 每次我们将代码推送到主程序时，它都会构建和测试应用程序
• 它使用 scp 将应用程序部署到服务器。

步骤 3:自动化测试

自动化测试对于确保代码稳定非常重要。我们可以添加单元测试、集成测试和端到端测试。

示例(用于单元测试的 Jest)

将测试脚本添加到 package.json −

"scripts": {
  "test": "jest"
}

使用 − 在管道中自动运行这些测试

npm test

步骤 4:配置部署自动化

部署自动化有助于将测试过的代码转移到生产环境，而无需手动操作。Terraform 等工具使这个过程变得顺畅。

示例(Terraform for AWS 部署) −

provider "aws" {
   region = "us-west-2"
}
resource "aws_s3_bucket" "static_site" {
   bucket = "my-static-site"
   acl    = "public-read"
}
resource "aws_s3_bucket_object" "index" {
   bucket = aws_s3_bucket.static_site.bucket
   key    = "index.html"
   source = "build/index.html"
   content_type = "text/html"
}

运行 Terraform 命令进行部署 −

terraform init
terraform apply

第 5 步:集成基础设施即代码 (IaC)

Kubernetes 等 IaC 工具可帮助我们管理环境。

示例 (Kubernetes 部署) −

编写一个 deploy.yaml 文件−

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app-image:latest
        ports:
        - containerPort: 80

应用此配置。

kubectl apply -f deploy.yaml

第 6 步:实现监控和反馈循环

我们需要监控工具来检查应用程序的性能。Prometheus 和 Grafana 等工具很有帮助。

示例(Prometheus 配置)−

scrape_configs:
  - job_name: "app"
    static_configs:
      - targets: ["localhost:9090"]

第 7 步:测试端到端管道

最后，将更改推送到存储库并确保一切正常:

• 构建 − 编译应用程序。
• 测试 − 运行测试以查找问题。
• 部署 − 将应用推送到服务器。

通过结合版本控制、CI/CD 工具、测试和 IaC，我们可以确保管道顺畅可靠。这有助于更快地交付更新并减少错误。

实施部署策略

下表重点介绍了 DevOps 中的持续部署策略 −

结论

在本章中，我们解释了如何设置可靠的部署管道。我们还研究了蓝绿和灰度发布(又名金丝雀发布)等策略。我们讨论了如何使用自动扫描和漏洞检查来确保安全性和合规性。

通过使用这些技术和工具，开发团队可以使部署过程更顺畅，减少停机时间，保持高安全性并轻松扩展应用程序。这将有助于加快软件交付周期并提高整体运营绩效。

DevOps - 持续监控

DevOps 中的持续监控 (CM) 意味着实时监视、跟踪和检查系统、应用程序和基础设施的指标。主要目标是保持一切运行良好，尽早发现问题，并在影响用户之前修复它们。

持续监控包括以下内容 −

• 从应用程序和基础设施收集日志、指标和跟踪。
• 当某些东西超过设定的限制时发送警报。
• 提供对性能、可靠性和安全性的洞察。

与老式监控不同，CM 非常适合 DevOps 管道。这确保了反馈循环在软件交付过程中保持顺畅。

持续监控在 DevOps 生命周期中的作用

持续监控对于保持 DevOps 工作流程的可靠性和高效性非常重要。它在许多方面都有帮助 −

• 改善反馈循环 −为团队提供部署的实时更新，以便他们能够更快地发现和修复问题。
• 增强自动化 − 与 CI/CD 工具配合使用，自动处理各种事情，例如回滚不良部署或扩展资源。
• 支持性能优化 − 检查资源的使用方式以及应用程序的运行情况，以改善情况。
• 确保安全合规性 −实时监视安全问题、未经授权的访问和合规性问题。

通过在 DevOps 流程的每个步骤中添加监控，我们可以提供更好的软件，减少停机时间，让用户更满意。

持续监控的组件

下表简要说明了持续监控的关键组件。

监控指标:要测量什么

当我们进行持续监控时，我们需要跟踪不同的指标。这些指标可帮助我们保持系统健康、使应用程序运行良好并实现业务目标。让我们看看关键类型的指标、它们的重要性以及一些示例。

系统指标:CPU、内存、磁盘和网络利用率

系统指标显示我们的基础设施的运行情况。

• CPU 利用率 − 告诉我们使用了多少 CPU。如果太高，可能会导致性能问题。
• 内存使用情况 − 跟踪已使用和可用内存。内存不足可能会导致崩溃。
• 磁盘 I/O − 测量读写速度。帮助我们找到存储瓶颈。
• 网络利用率 − 检查带宽、数据丢失和延迟。确保数据正常流动。

示例(Prometheus 查询)

# 所有节点的 CPU 利用率
rate(node_cpu_seconds_total{mode!="idle"}[5m])

# 内存使用率
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

# 磁盘读取/写入
rate(node_disk_read_bytes_total[5m]), rate(node_disk_write_bytes_total[5m])

应用程序指标:请求率、响应时间和错误率

这些指标确保应用程序保持可靠并满足用户期望 −

• 请求率 − 跟踪每秒有多少请求。显示工作负载模式。
• 响应时间 − 说明处理请求需要多长时间。对用户体验很重要。
• 错误率 − 以百分比形式跟踪失败的请求。数字高可能意味着存在错误或过载。

示例(示例 Nginx 配置)

# 启用响应时间日志记录
log_format timed_combined '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" $request_time';
# Prometheus Exporter(响应时间示例指标)
http_server_requests_seconds_sum{job="nginx"}

业务指标:SLA、SLO 和用户体验指标

这些指标将系统性能与业务目标联系起来。

• SLA(服务水平协议) − 我们向客户承诺的内容，例如 99.9% 的正常运行时间。
• SLO(服务水平目标) − 满足 SLA 的内部目标，例如将响应时间保持在 200 毫秒以下。
• 用户体验指标 −跟踪延迟、可用性和无错误交互。

示例(使用 Prometheus 和 Alertmanager 的 SLO 配置)

# 定义响应时间的 SLO
- alert: ResponseTimeHigh
  expr: histogram_quantile(0.99, rate(http_server_requests_seconds_bucket[5m])) > 0.2
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "High response time detected"

通过跟踪系统、应用程序和业务指标，我们可以更快地解决问题。这可以保持性能平稳，并使 IT 与业务需求保持一致。Prometheus、Grafana 和 Nginx 日志等工具可以更轻松地设置强大的监控系统。

设置持续监控基础设施

要设置持续监控，我们需要工具来收集数据、显示指标和发送警报。下面，我们将逐步使用 Prometheus(用于监控)、Grafana(用于仪表板)和 Alertmanager(用于警报)创建一个完整的监控系统。

步骤 1:安装和配置 Prometheus

Prometheus 是监控的主要工具。它从系统和应用程序收集指标。

Prometheus 配置文件 (prometheus.yml)−

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node_exporter' # Monitor system metrics
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'app'
    static_configs:
      - targets: ['localhost:8080'] # Your application metrics endpoint

首先，下载 Prometheus 并安装它。然后，使用配置文件 − 运行 Prometheus

./prometheus --config.file=prometheus.yml

第 2 步:安装 Node Exporter 以获取系统指标

我们使用 Node Exporter 收集系统数据，如 CPU 和内存使用情况。

安装和启动 Node Exporter 的命令:

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xvf node_exporter-1.6.0.linux-amd64.tar.gz
./node_exporter &

步骤 3:配置应用程序指标(例如 Spring Boot)

我们的应用程序需要公开指标以供 Prometheus 收集。

将 Micrometer 依赖项添加到 pom.xml −

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

在 application.properties 中公开指标端点 −

management.endpoints.web.exposure.include=prometheus
management.metrics.export.prometheus.enabled=true

第 4 步:设置 Grafana 进行可视化

Grafana 帮助我们在图表和仪表板中查看指标。

• 安装 Grafana 并在 http://localhost:3000 中打开它。
• 添加 Prometheus 作为数据源。
• 使用预构建的仪表板来获取系统和应用指标。

仪表板查询示例(CPU 使用率)

rate(node_cpu_seconds_total{mode!="idle"}[5m])

第 5 步:使用 Alertmanager 配置警报

Prometheus 与 Alertmanager 配合使用发送警报。

prometheus.yml 中的警报规则 −

rule_files:
  - "alert_rules.yml"
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

示例 alert_rules.yml

groups:
  - name: system_alerts
    rules:
      - alert: HighCPUUsage
        expr: avg(rate(node_cpu_seconds_total[2m])) > 0.8
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High CPU Usage Detected"

运行 Alertmanager −

./alertmanager --config.file=alertmanager.yml

步骤 6:验证并测试设置

在 Grafana 中检查 系统指标，如 CPU 和内存。查看 应用指标，如请求率和错误计数。通过创建高 CPU 负载来测试 警报。

通过此设置，我们拥有一个强大的监控系统。Prometheus 收集数据，Grafana 显示仪表板，Alertmanager 发送警报。这有助于 DevOps 团队跟踪性能并快速处理任何问题。

日志记录和分布式跟踪

日志记录和分布式跟踪对于发现问题、提高性能和跟踪微服务中发生的情况非常重要。以下是设置集中式日志记录和分布式跟踪的简单指南。我们还将展示如何配置日志聚合和跟踪采样。

集中式日志记录解决方案(例如 ELK Stack、Fluentd)

集中式日志记录意味着将来自许多服务的日志收集到一个地方。这使得分析和修复问题变得更加容易。

ELK Stack(Elasticsearch、Logstash、Kibana)

• Elasticsearch 存储日志并允许我们搜索它们。
• Logstash 处理日志并将其发送到 Elasticsearch。
• Kibana 让我们使用 Web 界面查看和分析日志。

配置示例(Logstash 到 Elasticsearch) −

input {
   file {
      path => "/var/log/*.log"
      start_position => "beginning"
   }
}
filter {
   grok {
      match => { "message" => "%{COMMONAPACHELOG}" }
   }
}
output {
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "logs-%{+YYYY.MM.dd}"
   }
}

Fluentd − Fluentd 是一个可以收集、处理并将日志发送到 Elasticsearch、Kafka 或云存储等地方的工具。

配置示例(Fluentd 与 Elasticsearch)−

<source>
   @type tail
   path /var/log/*.log
   pos_file /var/log/fluentd.pos
   format none
</source>
<match **>
   @type elasticsearch
   host localhost
   port 9200
   index_name fluentd
</match>

微服务的分布式跟踪(例如 Jaeger、Zipkin)

分布式跟踪可帮助我们跟踪请求在不同微服务中的移动情况。它让我们清楚地了解系统中发生延迟或错误的位置。

Jaeger − Jaeger 是一个用于分布式跟踪的开源工具。它可帮助我们跟踪请求在微服务中的移动情况并发现问题。

Jaeger 与 Spring Boot 集成的示例 −

<dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.7.0</version>
</dependency>

配置(application.properties)−

spring.sleuth.sampler.probability=1.0
spring.sleuth.trace-id128=true
spring.zipkin.enabled=true
spring.zipkin.baseUrl=http://localhost:9411/

Zipkin − Zipkin 是微服务中使用的另一种跟踪工具。它收集有关请求如何移动的数据并帮助发现延迟等问题。

Zipkin 集成(Spring Boot 示例)−

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

配置(application.properties)−

spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability=1.0

配置日志聚合和跟踪采样

日志聚合 − 像 ELK 或 Fluentd 这样的集中式系统会从不同的来源(服务器、应用程序、容器)收集日志并将它们发送到一个地方。

在微服务中，我们可以向日志添加标签，例如服务名称和跟踪 ID，以连接不同服务之间的事件。

示例日志格式(带跟踪 ID) −

{
   "timestamp": "2024-11-22T14:00:00Z",
   "service": "payment-service",
   "trace_id": "abcd1234",
   "message": "Transaction successful"
}

跟踪采样 − 采样在分布式跟踪中非常重要。它帮助我们避免发送过多数据，从而降低系统速度。我们可以设置采样率来控制发送的数据量。

示例 配置(Jaeger 采样率) −

sampling:
  rate: 0.1  # 抽样 10% 的请求

示例配置(Zipkin 采样率)−

spring.sleuth.sampler.probability=0.1

日志记录和分布式跟踪对于理解系统的工作方式和修复微服务中的问题非常重要。像 ELK 和 Fluentd 这样的集中式日志记录工具可以轻松收集日志。Jaeger 和 Zipkin 帮助我们跟踪跨服务的请求流。

配置跟踪采样和日志聚合有助于保持系统快速运行并使故障排除更容易。这让 DevOps 团队能够确保其系统的高可靠性和可用性。

结论

在本章中，我们讨论了 DevOps 中持续监控的重要部分。我们介绍了一些关键内容，例如监控工具、指标、警报系统以及集中式日志记录和分布式跟踪的需求。

我们研究了 ELK 堆栈、用于日志聚合的 Fluentd 以及用于跨服务跟踪请求的 Jaeger 和 Zipkin 等解决方案。我们还提供了示例并展示了如何配置这些工具。这些实践和工具对于保持系统可靠性、提高性能和快速解决问题非常重要。

DevOps - 持续改进

在 DevOps 中，持续改进有助于使开发流程更加顺畅，并减少代码集成、测试、部署和监控等步骤之间的问题。它使用自动化、指标和反馈来不断改进流程。

通过持续改进，我们可以尽早发现和解决问题。这使团队能够快速适应技术和业务需求的变化。 CI 还支持精益方法，例如 Kaizen，其中小的更改有助于随着时间的推移提高质量和效率。

DevOps 中的持续改进依赖于 −

• 自动测试，用于在每次更改后检查代码质量。
• 自动部署，可快速轻松地发布。
• 反馈循环，让团队快速响应生产中的问题，确保问题得到快速修复。

CI 在 DevOps 文化中的重要性

持续改进在 DevOps 中非常重要，因为它鼓励团队合作并使事情更有效率。持续改进周期中的快速反馈有助于尽早发现问题，从而降低修复问题的成本和时间。

CI 还符合 DevOps 原则，该原则专注于快速且频繁地交付价值。这让团队几乎可以实时改进软件解决方案。

以下是 CI 在 DevOps 文化中很重要的主要原因:

• 更快的发布 − 持续集成和交付可实现更快、更小的发布，从而缩短上市时间。
• 提高质量 −通过始终自动测试和部署代码，我们可以快速发现并修复错误，从而提高质量。
• 协作 − CI 加强了开发、运营和 QA 团队之间的团队合作，帮助他们共同交付可靠的软件。
• 可扩展性 −随着团队的成长和项目的扩大，CI 可以让流程保持高效和灵活，即使是在大型分布式团队中也是如此。

最终，CI 提倡一种不断变化的思维方式，使其成为 DevOps 的重要组成部分，以鼓励创新并在快速变化的开发世界中创造价值。

DevOps 中持续改进的关键原则

DevOps 中持续改进的关键原则包括以下 −

• 精益原则
• Kaizen 方法
• 反馈循环和迭代过程

让我们更详细地了解这三个关键原则。

精益原则

它专注于在 DevOps 中获得最大价值并减少浪费。它适用于开发和运营。它强调以下方面 −

• 消除浪费 − 查找并删除不必要的步骤或延迟，例如额外的测试或手动交接。
• 扩大学习 − 使用快速反馈并进行小幅更改以不断改进流程。
• 尽可能晚地做出决定 − 使用最新和最可靠的数据做出决策，以避免以后不必要的工作。
• 尽可能快地交付 − 加快开发周期以快速释放价值并获得即时反馈。

DevOps 中的 Kaizen 方法

Kaizen 是一种持续改进的方法，专注于小而稳定的变化。随着时间的推移，它可以改进流程、工具和团队合作。

Kaizen 方法强调以下几点 −

• 小规模、渐进式改进 − 不要进行大变革，而是进行小规模、定期的改进。
• 员工参与 − 从开发人员到运营团队，每个人都在帮助改进。
• 标准化 − 遵循最佳实践并设定程序，以确保我们获得可预测的高质量结果。
• 关注根本原因 − 解决导致效率低下的主要问题，而不仅仅是症状。

反馈循环和迭代过程

持续的反馈和开发周期是提高质量和满足不断变化的业务需求的关键。它主要关注以下方面 –

• 实时反馈 − 持续的测试、监控和日志记录可立即提供有关应用程序运行情况的详细信息。
• 频繁发布 − 较短的发布周期使团队能够更快地获得用户反馈并更快地解决问题。
• 协作和沟通 − 定期反馈可帮助团队保持同步并在需要时快速做出更改。
• 适应性 − 通过迭代开发和反馈，团队可以保持灵活性并在获得新信息时做出改变。

衡量和监控持续改进的进展

衡量和监控 DevOps 的进展非常重要。它帮助我们跟踪改进，发现瓶颈，并改善软件交付管道。

持续监控让我们可以检查我们是否达到了目标。它还有助于确保我们遵循 DevOps 原则，如速度、质量和团队合作。KPI 和指标是其中的关键。它们帮助我们衡量变化的影响并指导我们进一步改进。

DevOps 的关键绩效指标 (KPI)

DevOps 的 KPI 关注软件交付管道的效率和效果。这些指标帮助我们了解开发速度、运营稳定性和整体性能。一些常见的 KPI 是 −

• 部署频率 − 这衡量我们将代码部署到生产中的频率。高频率意味着我们拥有强大的 CI/CD 管道，并且能够很好地协同工作。
• 前置时间 − 这是将代码从开发转移到生产所需的时间。更短的前置时间意味着更快的交付和更快的变更。
• 变更失败率 − 这跟踪生产中失败的部署百分比。低失败率表明代码质量良好且部署稳定。
• 平均恢复时间 (MTTR) − 这衡量故障后恢复服务所需的时间。较低的 MTTR 意味着我们可以快速恢复并很好地管理事件。

跟踪改进的指标

在 DevOps 中，我们跟踪特定指标以显示软件交付和运营效率的改进。这些指标帮助我们找到需要改进的领域并衡量进度。

部署频率 −高部署频率意味着我们经常发布小更新。我们可以使用 Jenkins 或 GitLab CI 等 CI/CD 工具来跟踪这一点。这些工具可帮助我们监控一段时间内成功部署的数量。

查看以下示例 −

# Jenkins Pipeline:跟踪部署频率
pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                echo "Deploying to production"
                sh './deploy.sh'
            }
        }
    }
}

前置时间 − 这跟踪从代码提交到部署的时间。Jira 或 GitLab 等工具可以自动记录从提交到发布的前置时间。

Jira 中的指标查询示例 −

SELECT AVG(time_to_deploy) FROM deploys WHERE status = 'successful';

变更失败率 − 我们可以从日志中获取此指标，并使用 Prometheus 等工具对其进行监控。它跟踪部署后的应用程序故障。高故障率表明测试或部署中存在问题。

示例 Prometheus 查询 −

rate(http_requests_total{status="5xx"}[5m])

MTTR(平均恢复时间) − 我们通过测量修复事件所需的时间来跟踪 MTTR。Datadog 或 Splunk 等工具为我们提供有关事件响应时间的实时数据，这有助于我们减少 MTTR。

用于监控和收集指标的工具

为了很好地监控和收集指标，DevOps 团队使用特殊工具。这些工具帮助我们捕获、查看和分析性能数据。一些流行的工具是:

Prometheus − 一个强大的开源监控工具。它使用 PromQL 收集时间序列数据并查询指标。Prometheus 与 Kubernetes 和 Docker 配合良好，使其成为 DevOps 管道的绝佳选择。

用于监控部署指标的 Prometheus 配置示例 −

scrape_configs:
  - job_name: 'deployment-metrics'
    static_configs:
      - targets: ['localhost:8080']

Grafana − 它帮助我们可视化来自 Prometheus 或其他来源的数据。Grafana 仪表板让我们可以创建 KPI 的自定义视图，从而轻松发现趋势和瓶颈。

示例 Grafana 仪表板配置部署频率 −

{
  "title": "Deployment Frequency",
  "panels": [
    {
      "type": "graph",
      "targets": [
        {
          "expr": "rate(deployment_success_total[1d])",
          "legendFormat": "Deployments"
        }
      ]
    }
  ]
}

Datadog − 一个基于云的平台，提供指标、日志和跟踪的实时监控。它与许多 DevOps 工具集成，并提供系统性能的完整视图。

Datadog 与 CI/CD 管道集成的示例 −

- name: Deploy to Production
  action: datadog.monitoring.deploy
  config:
    metric: "deployment.frequency"
    value: 1
    tags: ["env:production"]

Elasticsearch、Logstash 和 Kibana (ELK Stack) − 此工具链可帮助我们收集、搜索和可视化来自不同服务的日志。它对于跟踪应用程序性能和错误非常有用。

配置 Logstash 以将部署日志发送到 Elasticsearch 的示例 −

input {
   file {
      path => "/var/log/deployments.log"
   }
}
output {
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "deployments"
   }
}

通过使用这些工具并跟踪正确的指标，DevOps 团队可以持续衡量进度，找到需要改进的地方，并在软件开发和交付中保持高性能。

自动化反馈循环以实现持续改进

自动化反馈循环有助于我们更快地进行更改，更快地发现错误，并在整个开发过程中不断学习。

• 收集反馈 − 我们使用 Jira 和 GitLab Issues 等工具收集来自开发、测试和运营的反馈。这些工具有助于跟踪错误报告和功能请求。
• 自动化测试 − 我们在每次提交后自动运行测试以检查代码是否良好。Selenium、JUnit 和 TestNG 等工具可帮助我们尽早发现错误。
• CI/CD 管道 − CI/CD 管道自动化了从提交到生产的代码流程。这确保我们经常发布代码，而无需太多人力。

基础设施即代码 (IaC) 的持续改进

IaC 通过使用代码使基础设施管理更加容易。这确保一切都是一致且自动化的。

• IaC 的最佳实践 − 我们使用 Terraform、Ansible 和 Puppet 等工具以一致的方式创建基础设施。
• 版本控制 − 我们将 IaC 配置存储在 Git 存储库中。这使得跟踪更改并在需要时将其回滚变得容易。
• 自动化基础设施更改 −我们通过自动化基础设施更新并通过 CI/CD 管道推动它们来不断改进。

用于 DevOps 持续改进的工具链

合适的工具可帮助我们自动化工作、收集反馈并改善系统。

• 必备工具 − Jenkins、GitLab、CircleCI 和 SonarQube 等工具将测试、部署和代码质量检查集成到我们的管道中。
• 工具集成 − 我们使用可以很好地协同工作的工具来自动化测试、监控和部署。
• 选择工具 − 我们根据工具与我们当前系统的配合程度以及可扩展性来选择工具。这有助于我们提高效率。

持续学习和培训

学习文化有助于我们跟上新技术并进行创新。

• 创建学习文化 − 我们通过指导和 Confluence 或 Slack 等工具鼓励知识共享和成长心态。
• 知识共享 − 我们建立了系统来分享最佳实践、学习和故障排除指南，以便每个人都可以轻松访问它们。
• 培训和技能提升 −我们提供新工具和技术(如 Kubernetes 或云技术)的持续培训，以确保团队保持竞争力和效率。

实施持续改进的挑战

下表重点介绍了实施持续改进的常见挑战，并提供了克服这些挑战的解决方案 −

结论

在本章中，我们研究了 DevOps 中持续改进的主要思想和实践。我们讨论了反馈循环、自动化测试和 CI/CD 管道。我们还介绍了监控、扩展以及如何处理常见问题。

通过使用这些策略，我们可以帮助 DevOps 团队提高效率、质量和交付速度。选择正确的工具、建立学习文化和解决瓶颈问题，使开发环境更加可靠和可扩展。

最终，遵循持续改进的思维方式有助于团队保持竞争力并适应快速变化的技术世界。

DevOps - 基础设施

DevOps 基础设施是现代软件开发和运营的基础。它可以帮助团队协同工作、轻松扩展和自动执行任务。主要思想是混合工具、方法和实践，以在整个软件过程中更好地处理基础设施。

当开发和运营团队一起工作时，手动工作就会减少。它还使流程更快、更可靠。这样，我们可以提供更高质量的应用程序。

DevOps 中的基础设施是什么?

在 DevOps 中，基础设施是指我们创建、部署和运行应用程序所需的资源。这些资源可以是物理的、虚拟的或基于云的。它们包括 −

• 服务器 − 运行应用程序的机器(物理或虚拟)或容器。
• 网络 − 用于数据传输、平衡负载和连接服务的设置。
• 存储 − 文件存储、数据库和数据处理工具等系统。
• 工具和服务 − 用于自动执行任务、监控系统、管理 CI/CD 管道和设置配置的平台。

DevOps 将基础设施视为代码。这意味着我们可以使用基础设施即代码 (IaC) 来管理它，就像我们管理应用程序代码一样。 IaC 确保一切都一致且易于重复或扩展。

DevOps 基础设施的关键原则

下表重点介绍了 DevOps 基础设施的关键原则 −

基础设施即代码 (IaC):端到端示例

基础设施即代码 (IaC) 帮助我们使用代码管理和设置基础设施。它用自动化取代了手动工作。这使事情变得一致、易于扩展和可重复。Terraform、AWS CloudFormation 或 Ansible 等工具通常用于 IaC。

IaC 与 DevOps 管道配合良好。它支持持续交付，并让我们可以像使用代码一样跟踪基础设施中的变化。

分步示例:使用 Terraform 配置 Web 服务器

先决条件

首先，在您的机器上安装 Terraform。接下来，设置一个 AWS 账户并使用凭证配置 aws-cli。

目录结构

像这样排列项目文件 −

/iac-example
  ├── main.tf
  ├── variables.tf
  ├── outputs.tf

定义变量 (variables.tf)

此文件可帮助我们灵活地进行设置 −

variable "region" {
   description = "AWS region"
   default     = "us-east-1"
}
variable "instance_type" {
   description = "EC2 instance type"
   default     = "t2.micro"
}

配置资源 (main.tf)

我们在此定义基础设施 −

provider "aws" {
   region = var.region
}
resource "aws_instance" "web" {
   ami           = "ami-0c02fb55956c7d316" # Amazon Linux 2 AMI
   instance_type = var.instance_type
   tags = {
      Name = "TerraformExampleWebServer"
   }
   provisioner "remote-exec" {
      inline = [
         "sudo yum update -y",
         "sudo yum install -y httpd",
         "sudo systemctl start httpd",
         "sudo systemctl enable httpd"
      ]
   }
}
resource "aws_security_group" "web_sg" {
   name_prefix = "web-sg-"
   ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
   }
   egress {
      from_port   = 0
      to_port     = 0
      protocol    = "-1"
      cidr_blocks = ["0.0.0.0/0"]
   }
}

输出信息 (outputs.tf)

设置后显示重要详细信息 −

output "instance_public_ip" {
   value = aws_instance.web.public_ip
}

执行 Terraform 工作流

运行这些命令来创建基础设施 −

terraform init # 初始化 Terraform 环境
terraform plan # 查看执行计划
terraform apply # 应用更改

验证设置

运行 terraform apply 后，Terraform 将为您提供 EC2 实例的公共 IP。在浏览器中打开 IP 以检查 Web 服务器是否正常运行。

此示例展示了如何使用 Terraform 在 AWS 上设置一个简单的 Web 服务器。IaC 简化了现代基础设施管理。它帮助我们更快更好地开展 DevOps 实践。

云基础设施

云基础设施是通过互联网提供存储、网络和计算能力等计算资源所需的硬件和软件的组合。

AWS、Microsoft Azure 和 Google Cloud Platform (GCP) 等云服务提供商管理此基础设施。借助云基础设施，我们可以随时访问资源，而无需物理硬件。它具有可扩展性、灵活性，并且可以按需工作。

公有云、私有云和混合云

公有云 − 公有云由 AWS、Azure 或 GCP 等第三方公司管理。他们通过互联网提供资源。在公有云中，许多组织使用相同的基础设施。这使得它便宜、可扩展且易于使用，采用即用即付模式。示例包括 Amazon EC2 和 Microsoft Azure 虚拟机。

私有云 −私有云专用于一个组织。它可以在本地或由第三方提供商托管。与公共云相比，这种类型的云提供更好的安全性、更多的控制和定制。但是，它可能更昂贵。私有云非常适合需要高数据隐私的行业。

混合云 − 混合云结合了公共云和私有云。这允许数据和应用程序在两者之间移动。混合模型很灵活。它允许企业使用公共云的可扩展性，同时将敏感数据保留在私有云中。这有助于管理工作负载、安全性和合规性

使用 AWS / GCP / Azure 进行基础设施管理

以下每个云平台都有自己的优势。最佳选择取决于我们的需求、当前设置和业务要求。

AWS(亚马逊网络服务)

AWS 提供许多服务，如计算(EC2)、存储(S3)和数据库(RDS、DynamoDB)。它还提供 CloudFormation 和 AWS OpsWorks 等工具来实现自动化。AWS 提供托管服务，例如用于 Web 应用的 AWS Elastic Beanstalk 和用于无服务器计算的 AWS Lambda。

GCP(Google Cloud Platform)

GCP 适用于机器学习、分析和 AI。主要工具是用于虚拟机的 Google Compute Engine、用于容器的 Google Kubernetes Engine (GKE) 和 Google Cloud Storage。GCP 对于使用 BigQuery 等工具进行数据分析特别有用。

Microsoft Azure

Azure 是 Microsoft 的云平台。它提供计算(Azure 虚拟机)、存储(Azure Blob 存储)和网络(Azure 虚拟网络)。Azure 与 Microsoft 软件配合良好。它还支持使用 Azure Arc 的混合云设置。许多使用 Microsoft 工具的企业更喜欢 Azure。

云基础设施的高级概念

下表重点介绍了云基础设施的一些高级概念 −

结论

在本章中，我们研究了现代基础设施管理的关键部分。我们介绍了设置 CI/CD 管道、网络、安全、扩展、灾难恢复和基础设施测试。 Jenkins、GitLab CI 和 ArgoCD 等工具可帮助我们轻松实现管道自动化。我们还讨论了负载平衡、服务网格和云扩展如何提高性能并保持可用性。

我们还讨论了使用 DevSecOps 和 Vault 等实践来保护基础设施。为了确保一切保持弹性，我们讨论了使用混沌工程和自动恢复。通过理解和使用这些想法，我们可以构建强大、可扩展且安全的基础设施，以支持持续交付、安全性和平稳运行。

DevOps - Git

Git 是一个分布式版本控制系统。它在 DevOps 工作流中发挥着重要作用。我们使用 Git 来管理源代码、帮助开发人员协作以及自动化持续集成/持续部署 (CI/CD) 管道。 Git 可以轻松跟踪版本、创建分支和合并代码更改。

这些功能对于快速协作和快速开发周期非常重要。Git 存储库是 DevOps 管道的核心。它们触发自动构建、测试和部署。这确保我们快速、一致地交付软件，并具有完全的可追溯性。

为 DevOps 工作流设置 Git

在本节中，让我们了解如何为 DevOps 工作流设置 Git。

安装和配置 Git

要在 DevOps 工作流中开始使用 Git，首先，我们需要在我们的系统上安装它 −

Linux

sudo apt-get install git

macOS

brew install git

Windows

我们可以从官方网站下载并安装 Git。

安装 Git 后，我​​们需要全局设置我们的用户详细信息 −

git config --global user.name "您的姓名"
git config --global user.email "you@example.com"

这确保我们的提交正确链接到我们。要检查设置，我们可以使用 −

git config --list

将 Git 与 CI/CD 工具(Jenkins、GitLab CI 等)集成

Git 可与 Jenkins、GitLab CI 等 CI/CD 工具配合使用。它有助于自动触发构建和部署。

Jenkins

首先，我们需要在 Jenkins 中安装 Git 插件。在 Jenkins 作业设置中，我们添加了 Git 存储库 URL 和我们的凭据。我们将构建配置为基于 Git 事件(如推送或拉取请求)启动。请查看以下示例 −

scm:
  git:
    - url: 'https://github.com/your-repository.git'
      branch: 'main'

GitLab CI

我们在存储库中名为 .gitlab-ci.yml 的文件中定义 CI/CD 管道。请查看以下示例−

stages:
  - build
  - test
  - deploy
build:
  stage: build
  script:
    - npm install
test:
  stage: test
  script:
    - npm test
deploy:
  stage: deploy
  script:
    - ./deploy.sh

这可确保每次推送到 Git 存储库都会触发正确的 CI/CD 管道。

DevOps 中的分支策略

在 DevOps 中，分支策略可帮助我们管理如何在 Git 存储库中对代码进行更改。良好的分支策略对于更好的团队合作、更快的开发和顺畅的 CI/CD 管道非常重要。我们使用的一些常见策略是 Git Flow、GitHub Flow 和基于主干的开发。

Git Flow 与 GitHub Flow 与基于主干的开发

Git Flow − Git Flow 是一种旧方法。在此策略中，主分支具有用于生产的稳定代码，而开发分支具有最新的开发更改。新功能进入单独的功能分支。我们从发布分支创建发布，任何紧急修复都在修补程序分支中完成。此方法适用于需要计划发布的大型项目。

git flow init

GitHub Flow − GitHub Flow 更简单，最适合持续交付。在此方法中，我们从主分支创建功能分支，对其进行处理，一旦准备就绪，就将其合并回主分支。这对于经常部署并使用拉取请求来审查代码的团队非常有用。

git checkout -b feature-branch
git push origin feature-branch

基于主干的开发 − 基于主干的开发专注于直接向主分支(或主干)进行小规模、频繁的提交。我们经常创建短暂的功能分支，或者有时直接在主分支上工作并每天多次合并更改。此方法支持持续集成和交付，且分支最少。

git checkout main
git pull origin main
git merge feature-branch

创建和管理功能、发布和修补程序分支

在 DevOps 中，我们为功能、发布和修补程序创建和管理不同的分支。这有助于我们在不干扰主代码的情况下处理不同的任务。

功能分支 − 我们使用功能分支来开发新功能或改进，而无需更改主代码。这些分支是从主分支或开发分支创建的。

git checkout -b feature/login-ui

发布分支 − 发布分支帮助我们准备代码以供部署。在合并回主分支和开发分支之前，我们会使用它们进行最后一刻的更改、错误修复和版本控制。

git checkout -b release/1.0.0

修补程序分支 − 修补程序分支用于在生产环境中进行快速修复。修复问题后，我们将修补程序重新合并到主分支和开发分支中，以使其保持最新状态。

git checkout -b hotfix/fix-crash

团队协作中的合并和变基策略

我们可以使用合并或变基将不同分支的更改整合在一起。

合并 − 合并将一个分支的更改合并到另一个分支，同时保留提交历史记录。当我们想要维护每个更改的完整上下文时，这很有用。

git merge feature-branch

变基 − 变基将整个分支移动到从目标分支的最新提交开始，从而提供更清晰的历史记录。当我们想要避免额外的合并提交时，它很有帮助。

git rebase main

何时使用合并或变基

• 当我们想要保留更改的准确历史记录时，我们更喜欢合并。
• 当我们想要一个干净的历史记录时，我们使用变基，特别是在将功能分支合并到主分支之前。

我们选择的策略取决于我们团队的工作流程、发布计划，以及我们是否想要详细或干净的提交历史记录。

DevOps 自动化中的 Git Hooks

Git Hooks 是在 Git 流程的不同点运行的简单脚本。它们有助于在某些 Git 操作之前或之后自动执行任务。使用钩子可以使我们的工作流程更加顺畅，并有助于在 DevOps 管道中实施良好的实践。

• pre-commit − 此钩子在创建提交之前运行。它对于检查代码样式或运行 linters 以保持代码清洁很有用。
• commit-msg − 它在提交消息写入之后但在提交完成之前运行。它确保提交消息遵循一定的样式。
• post-commit − 这个钩子在提交后运行。它通常用于通知团队或运行额外的测试。
• pre-push − 此钩子在将更改推送到远程存储库之前运行。它可用于在推送之前运行单元测试或验证检查。
• post-merge − 这在合并后运行。它可以在合并代码后触发部署脚本或运行额外的测试。

我们通常将这些钩子放在 .git/hooks/ 文件夹中。我们也可以根据我们的 DevOps 管道需求对其进行自定义。

使用 Git Hooks 自动执行 Linting、测试和部署

Git Hooks 非常适合在开发过程中自动执行 Linting、测试和部署等任务。例如:

预提交(Linting)

我们可以在每次提交之前自动对代码进行 Linting，以确保代码干净。

预提交 Hooks 示例(使用 eslint 进行 JavaScript) −

# .git/hooks/pre-commit
#!/bin/sh
npm run lint
if [ $? -ne 0 ]; then
  echo "Linting failed, commit aborted!"
  exit 1
fi

预推送(测试)

我们可以在推送之前运行单元测试，以确保代码不会破坏任何东西。

预推送钩子示例(使用 jest 进行测试) −

# .git/hooks/pre-push
#!/bin/sh
npm test
if [ $? -ne 0 ]; then
   echo "Tests failed, push aborted!"
   exit 1
fi

提交后(部署)

提交后，我们可以触发部署脚本，尤其是对于暂存或生产环境。

提交后钩子的示例(部署到服务器) −

# .git/hooks/post-commit
#!/bin/sh
./deploy.sh

这些钩子有助于自动执行检查代码、运行测试和部署等任务，同时与 Git 工作流紧密集成。

结论

在本章中，我们解释了在 DevOps 环境中使用 Git 的关键方面。我们介绍了如何为工作流设置 Git、自动执行常见的 Git 操作、管理分支、使用 Git 钩子以及自动执行部署脚本。

通过在 DevOps 管道中使用 Git 的强大功能，我们可以确保一致的代码质量。它还帮助我们简化测试和部署并改善协作。

DevOps - Docker

我们看到 DevOps 和 Docker 在当今的软件开发和部署中非常重要。它们有助于简化流程并改善团队合作。在本章中，我们将介绍 Docker 的基本思想。我们还将检查其架构以及它在 DevOps 生命周期中的工作方式。

首先，我们将学习如何在 DevOps 环境中设置 Docker。然后，我们将管理镜像和容器。之后，我们将查看网络设置。最后，我们将了解如何将 Docker 与 CI/CD 管道连接起来。这将帮助我们更有效地交付软件。

了解 Docker 架构

在 Docker 架构中，我们有许多重要的部分协同工作以帮助我们使用容器化。

Docker 架构的关键组件如下所列 −

• Docker Daemon (dockerd) − 这是负责 Docker 容器、镜像、网络和卷的主要服务。它监听 API 请求并管理容器任务。
• Docker 客户端 (docker) − 这是我们用来与 Docker 守护进程通信的命令行工具。我们运行 docker run、docker build 和 docker ps 等命令
• Docker 镜像 − 这些是我们用来创建容器的只读模板。我们从 Dockerfile 构建它们。Dockerfile 告诉我们如何制作镜像。
• Docker 容器 − 这些是 Docker 镜像的运行版本。它们让我们可以在单独的空间中运行应用程序。我们使用命令 docker run 从镜像创建它们。
• Docker 注册表 − 这是一个存储和共享 Docker 镜像的地方，就像 Docker Hub 一样。它允许我们推送和拉取图像。

在 DevOps 环境中设置 Docker

为了在 DevOps 工作中很好地使用 Docker，我们可以按照这些简单的步骤进行安装和设置。

步骤 1. 安装 Docker

对于 Ubuntu:使用以下命令在 Ubuntu 上安装 Docker −

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install docker-ce

适用于 Windows / Mac −我们可以从官方网站下载 Docker Desktop 应用程序。

第 2 步。启动 Docker 服务

我们需要使用这些命令启动 Docker 服务 −

sudo systemctl start docker
sudo systemctl enable docker

第 3 步。将用户添加到 Docker 组

为了不使用 sudo 执行 Docker 命令，我们可以将用户添加到 Docker 组 −

sudo usermod -aG docker $USER

不要忘记注销然后重新登录以进行更改工作。

步骤 4. 验证安装

我们可以使用这些命令检查 Docker 是否正常工作 −

docker --version
docker run hello-world

步骤 5. 配置 Docker Daemon

我们可以编辑 /etc/docker/daemon.json 文件进行一些自定义设置 −

{
  "storage-driver": "overlay2",
  "log-level": "error"
}

之后，我们需要重新启动 Docker 服务 −

sudo systemctl restart docker

现在我们已经准备好 Docker，我们可以开始容器化我们的应用程序并将它们添加到我们的 CI/CD 管道中。

Docker 镜像和容器:最佳实践

如果遵循一些最佳实践，我们可以在 DevOps 环境中很好地使用 Docker 镜像和容器。

Docker 镜像

最小化镜像大小 − 我们应该使用像 alpine 这样的小型基础镜像。这有助于使我们的镜像更小，下载速度更快。

层管理 − 我们可以在一个 RUN 语句中组合命令。这将帮助我们减少层数。例如 −

RUN apt-get update && apt-get install -y \
    package1 \
    package2 \
    && rm -rf /var/lib/apt/lists/*

使用 .dockerignore − 就像 .gitignore 一样，我们可以列出要从构建上下文中排除的文件。这也有助于缩小我们的镜像大小。

标记 − 让我们对标记使用语义版本控制。例如，我们可以使用 myapp:1.0.0。我们应该小心使用最新版本。

Docker 容器

资源限制 − 我们需要设置 CPU 和内存的限制。这有助于阻止我们的容器使用过多的资源 −

docker run --memory="256m" --cpus="1.0" myapp

环境变量 − 我们可以使用环境变量进行配置。这样，我们就不会在代码中硬编码敏感信息。

定期更新 − 我们应该保持镜像更新。这有助于修复漏洞。我们需要定期扫描镜像以查找安全问题。

通过遵循这些做法，我们可以提高 Docker 镜像和容器的性能、安全性和维护性。

Docker 网络:概念和配置

我们可以使用 Docker 网络让我们的容器相互通信并与外部系统通信。了解不同的网络模式对于管理好我们的容器非常重要。Docker 为我们提供了几种网络选项 −

桥接网络

这是我们容器的默认网络。它允许容器在同一主机上相互通信

docker network create my_bridge_network
docker run -d --name container1 --network my_bridge_network nginx
docker run -d --name container2 --network my_bridge_network nginx

主机网络

主机网络跳过 Docker 网络堆栈。它将容器直接连接到主机网络。

docker run --network host nginx

覆盖网络

覆盖网络允许不同 Docker 主机上的容器进行通信。当我们使用 Swarm 模式时，它很有用。

docker network create -d overlay my_overlay_network

Macvlan 网络

这使我们的容器拥有自己的 MAC 地址。它们看起来像网络上的真实设备。

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 my_macvlan_network

当我们理解了这些想法和设置后，我们可以在 DevOps 环境中更好地管理 Docker 容器。

使用 Docker Compose 管理 Docker 容器

我们使用 Docker Compose 来帮助管理多容器 Docker 应用程序。它使仅使用一个 YAML 文件定义和运行这些应用程序变得容易。这样，编排变得更简单。

主要功能

• 服务定义 − 我们在 docker-compose.yml 文件中定义服务、网络和卷。
• 环境配置 − 我们可以轻松管理容器的环境变量。
• 扩展 − 我们可以使用简单的命令来扩展或缩小服务。

docker-compose.yml 的基本结构 −

version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: example

常用命令

启动服务 −

docker-compose up

停止服务 −

docker-compose down

扩展服务 −

docker-compose up --scale web=3

使用 Docker Compose 可帮助我们简化应用程序的开发和部署。它使管理多容器设置的依赖项和配置更加容易。

与 Docker 的 CI / CD 集成

通过将 Docker 添加到我们的持续集成和持续部署 (CI/CD) 管道中，我们可以更好地进行开发。 Docker 帮助我们创建一致的构建并使应用程序的部署更加容易。

以下是关键组件 −

Dockerfile − 此文件告诉我们如何构建 Docker 映像。

FROM node:14

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

CMD ["npm", "start"]

CI / CD 工具 − 我们可以将 Jenkins、GitLab CI、CircleCI 和 GitHub Actions 等流行工具与 Docker 结合使用。

管道示例

构建 − 我们从 Dockerfile 创建 Docker 映像。

docker build -t myapp:latest

测试 − 我们在容器内运行测试。

docker run --rm myapp:latest npm test

部署 −我们将镜像推送到注册表并将其部署到生产环境中。

docker push myapp:latest

结论

在本章中，我们了解了 DevOps 框架中 Docker 的基础知识。我们讨论了它的结构以及如何设置它。我们还分享了使用镜像和容器的最佳方法。

网络设置是我们讨论的另一个主题。最后，我们讨论了如何使用 Docker Compose 管理 Docker。我们还展示了如何将 Docker 添加到 CI/CD 管道中。

DevOps - Selenium

在本章中，我们将了解 DevOps 和 Selenium 如何协同工作以及它们如何帮助软件测试。

我们将讨论关键思想。首先，我们将了解为什么 DevOps 在测试中很重要。然后，我们将研究 Selenium 如何融入自动化框架。最后，我们将分享在持续集成和交付环境中使用这些工具的一些最佳实践。

Selenium 概述及其在自动化中的作用

我们知道 Selenium 是一个强大的开源工具。它帮助我们在不同的浏览器和平台上自动化 Web 应用程序。它适用于许多编程语言，如 Java、C#、Python 和 Ruby。这使得它对开发人员和测试人员都很有用。

Selenium 的关键组件

• Selenium WebDriver − 这为我们提供了一种创建和运行测试脚本的方法。它直接与浏览器对话。这给了我们更多的控制权，并使其更加灵活。
• Selenium Grid − 这帮助我们在不同环境中同时运行测试。这使我们的测试更快。
• Selenium IDE − 这是一个让我们快速记录和回放测试的工具。它对初学者来说很好。

自动化中的作用:

• 跨浏览器测试 − 这会检查我们的应用程序是否在不同的浏览器(如 Chrome、Firefox 和 Safari)上运行良好。
• 持续测试 − 我们可以将其与 CI/CD 管道一起使用。这有助于我们自动化回归测试并获得快速反馈。
• 测试覆盖率 − 它支持多种类型的测试。这包括功能测试、回归测试和性能测试。

Python 中简单的 Selenium 测试示例

from selenium import webdriver

# 初始化 WebDriver
driver = webdriver.Chrome()

# 打开网页
driver.get("https://example.com")

# 查找元素并执行操作
driver.find_element_by_name("q").send_keys("Selenium")

# 关闭浏览器
driver.quit()

将 Selenium 与 CI/CD 管道集成

我们可以通过在持续集成和持续部署 (CI/CD) 管道中使用 Selenium 来改善我们的软件测试。这有助于我们自动运行测试。它还确保我们的应用程序在开发过程中保持良好的质量。

将 Selenium 与 CI/CD 集成的步骤

版本控制系统 (VCS) 集成 − 我们可以使用 Git 等工具来处理我们的代码。我们应该在提交代码时运行测试。

持续集成工具 − 我们可以使用 Jenkins、CircleCI 和 GitLab CI 等工具来自动化构建和测试。

以下是 Jenkins Pipeline 设置的示例 −

pipeline {
   agent any
   stages {
      stage('Build') {
         steps {
            sh 'mvn clean package'
         }
      }
      stage('Test') {
         steps {
            sh 'mvn test'
         }
      }
   }
}

测试环境设置 − 我们可以使用 Docker 为我们的 Selenium 测试创建单独的空间。我们需要设置 Selenium WebDriver 以与我们的应用程序配合使用。

自动触发测试 − 我们应该设置 webhook 或轮询。这将帮助我们在部署或更改代码时运行 Selenium 测试。

报告 − 我们可以添加报告工具，如 Allure 或 ExtentReports。它们将帮助我们查看测试结果。

通过执行这些步骤，我们可以确保我们的 Selenium 测试很好地适应我们的 CI/CD 管道。这将帮助我们更快、更可靠地交付软件。

使用 Docker 对 Selenium 测试进行容器化

我们知道容器化可以帮助我们每次都拥有相同的测试环境。这在 DevOps 管道中非常重要。Docker 可以轻松设置和运行 Selenium 测试。它通过将测试及其所需的内容放入容器来实现这一点。这样，我们可以避免因开发和测试中的不同设置而导致的问题。

对 Selenium 测试进行容器化的关键步骤

创建 Dockerfile − 我们需要为 Selenium 测试定义环境。

FROM selenium/standalone-chrome:latest

WORKDIR /app
COPY . /app

RUN apt-get update && apt-get install -y \
    curl \
    && rm -rf /var/lib/apt/lists/*

CMD ["python", "test_script.py"]

构建 Docker 映像 −

docker build -t selenium-test .

运行容器 −

docker run --rm -v $(pwd):/app selenium-test

将 Selenium 测试 Docker 化的好处

以下是将 Selenium 测试 Docker 化的好处 −

• 隔离 − 每个测试套件都在自己的空间中运行。
• 可扩展性 − 我们可以轻松地同时运行多个测试。
• 版本控制 −我们可以管理测试设置的不同版本。

通过使用 Docker，我们可以更快地获得反馈，并在开发和测试中更好地协同工作。

实现 Selenium Grid 进行并行测试

我们可以使用 Selenium Grid 同时在许多浏览器和环境中运行测试。这有助于我们节省测试运行时间。它还使我们在 DevOps 管道中的测试流程更好。

Selenium Grid 的关键组件

• Hub − 这是控制测试运行的主要点。它将测试发送到已注册的节点。
• Node −这是一台在特定浏览器版本和平台上运行测试的机器。

设置 Selenium Grid

启动 Hub − 我们需要运行此命令来启动 Hub −

java -jar selenium-server-standalone.jar -role hub

启动节点 − 下一步是向 Hub 注册一个节点 −

java -Dwebdriver.chrome.driver=path/to/chromedriver 
   -jar selenium-server-standalone.jar -role node 
   -hub http://localhost:4444/grid/register

示例测试配置

DesiredCapabilities capabilities = DesiredCapabilities.chrome();
WebDriver driver = new RemoteWebDriver
    (new URL("http://localhost:4444/wd/hub"), capabilities);

通过使用 Selenium Grid，我们提高了测试效率。这有助于我们更好地适应 CI/CD 工作流程。## 在 DevOps 中监控和报告测试结果

我们知道，在 DevOps 环境中，监控和报告测试结果非常重要。这有助于我们保持高质量并不断改进。让我们看看我们应该考虑的一些关键点。

关键组件

实时监控 −我们可以使用 Prometheus 或 Grafana 等工具实时查看测试执行和系统性能。

集中报告 − Allure 或 TestNG 等工具可以帮助我们创建收集多次测试结果的报告。

报告实践

自动报告 − 我们应该将我们的测试框架与 Jenkins 或 GitLab CI 等 CI/CD 工具链接起来，以便在每次构建后自动生成报告。

仪表板可视化 − 让我们创建仪表板，以显示测试的可视化结果、随时间变化的趋势和重要指标。

与 Jenkins 集成的示例

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                script {
                    sh 'mvn clean test'
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
        stage('Report') {
            steps {
                // Generate Allure report
                allure includeProperties: false, jdk: '', results: [[path: 'allure-results']]
            }
        }
    }
}

要监控的指标

• 通过/失败率 − 我们需要跟踪通过的测试数量和失败的测试数量。
• 执行时间 − 我们应该测量测试套件运行所需的时间。
• 失败趋势 − 找到测试失败的模式很重要，这样我们才能修复重复出现的问题。

通过使用这些实践，我们可以改善对测试过程的看法。这有助于我们尽早响应问题并保持较高的软件质量。

结论

在本章中，我们研究了 DevOps 和 Selenium 如何协同工作。我们了解了为什么持续测试在软件开发中非常重要。我们讨论了 Selenium 对自动化的作用。我们还讨论了它如何与 CI/CD 管道相适应。

我们分享了最佳实践，并讨论了使用容器化和 Selenium Grid 进行并行测试带来的好处。通过使用这些策略，我们可以提高软件质量。我们还可以加快交付时间，并在 DevOps 流程中创造更好的团队合作文化。

DevOps - Jenkins

在本章中，我们将介绍 Jenkins，它是一个开源自动化服务器。它在简化持续集成和交付方面发挥着重要作用。

我们将讨论 Jenkins 架构。我们还将讨论如何设置它、配置作业以及将其与版本控制系统连接起来。最后，我们将解释如何将管道用作代码。这将为我们在 DevOps 实践中使用 Jenkins 提供完整的指南。

了解 Jenkins 架构

Jenkins 是一个强大的自动化服务器，可帮助我们进行持续集成和持续交付，我们称之为 CI/CD。它的设计基于主代理模型。该模型有助于我们提高可扩展性和可靠性。

• Jenkins Master − 这是运行构建过程的主要控制单元。它安排作业、将构建发送给代理并检查其进度。它为我们提供了用于设置和监控的 Web 界面。
• Jenkins Agents (Slaves) − 这些是从主服务器执行作业的独立机器。它们可以在不同的系统(如 Windows 或 Linux)上工作。它们允许我们以分布式方式运行构建，从而加快速度。
• 作业配置 − 我们将作业定义为 Jenkins 将运行的一系列步骤。我们可以使用用户界面或配置文件来设置它们。
• 插件 − Jenkins 具有灵活的设计。这意味着我们可以添加许多插件。这些插件可以帮助我们进行通知、版本控制、构建工具等。

这种设计让我们可以使用 Jenkins 来管理不同环境中复杂的 CI/CD 任务。

设置 Jenkins 环境

我们可以按照这些简单的步骤设置 Jenkins 环境。

以下是先决条件 −

• Java −我们需要确保安装了 Java 开发工具包 (JDK)。它应该是 Java 8 或更高版本。
• 操作系统 − 它可以在 Windows、macOS 或 Linux 上运行。

安装步骤

下载 Jenkins − 我们转到 Jenkins 下载页面 并为我们的系统选择正确的软件包。

安装 Jenkins − 对于 Windows，运行安装程序并按照安装向导进行操作即可。对于 Linux，请使用如下包管理器 −

sudo apt update
sudo apt install jenkins

对于 macOS − 我们可以像这样使用 Homebrew −

brew install jenkins-lts

启动 Jenkins − 在 Linux 上，我们运行此命令 −

sudo systemctl start jenkins

在 Windows 上，我们在服务中查找 Jenkins 并从那里启动它。

访问 Jenkins

我们打开浏览器并转到 http://localhost:8080。我们需要使用初始管理员密码解锁 Jenkins。我们可以通过运行此命令找到它 −

cat /var/lib/jenkins/secrets/initialAdminPassword

配置 Jenkins

按照安装向导操作。它可以帮助我们安装建议的插件并创建管理员用户。

创建和配置 Jenkins 作业

在 Jenkins 中创建和配置作业对于自动化构建和部署非常重要。Jenkins 可以处理不同类型的作业。这些包括自由式项目、管道项目和多分支管道。

创建 Jenkins 作业的步骤

访问 Jenkins 仪表板 − 在 Web 浏览器中打开 Jenkins。

创建新作业 −单击仪表板上的"新项目"。输入我们的作业名称。

我们选择作业类型，如自由式项目或管道，然后单击"确定"。

配置作业设置 −

• 常规 − 我们添加描述。我们还可以选择丢弃旧版本。
• 源代码管理 − 我们设置了我们的版本控制系统，如 Git。

Repository URL: https://github.com/user/repo.git
Credentials: [Add credentials if needed]]

• 构建触发器 −我们设置触发器，例如"定期构建"或"轮询 SCM"。
• 构建环境 − 我们配置任何所需的环境设置。
• 构建步骤 − 我们定义要运行的步骤。例如，我们可以调用 shell 脚本。

# 示例 shell 命令
echo "Building the project..."

构建后操作 − 我们指定构建后要执行的操作。这可以是发送通知或存档工件。

保存并构建:我们单击"保存"以保留设置。我们可以从作业页面单击"立即构建"来开始构建。

通过这些设置，我们可以创建能够很好地自动化流程的 Jenkins 作业。

将 Jenkins 与版本控制系统集成

我们需要将 Jenkins 与版本控制系统 (VCS) 集成以自动化构建过程。Jenkins 可与许多 VCS 配合使用，例如 Git、Subversion (SVN) 和 Mercurial。

将 Jenkins 与 Git 集成的步骤

安装 Git 插件 − 转到管理 Jenkins，然后转到管理插件。安装"Git 插件"。

配置 Jenkins 全局设置 − 单击管理 Jenkins，然后单击全局工具配置。设置 Git 安装路径。

创建一个新的 Jenkins 作业 − 我们单击新建项目，选择自由式项目，然后为其命名。

配置源代码管理 − 在作业设置中，我们选择 Git。我们输入存储库 URL，如 https://github.com/user/repo.git。如果存储库是私有的，我们添加凭据。

设置构建触发器 −我们启用 Poll SCM 来检查特定时间的更改，例如 H/5 * * * *。

示例配置

# Jenkins 作业配置
scm:
  git:
    branches:
      - master
    remote:
      url: https://github.com/user/repo.git

通过执行这些步骤，Jenkins 将从我们指定的 VCS 中提取最新的代码更改。这有助于我们进行持续集成。

使用 Jenkins 实现持续集成

持续集成 (CI) 是我们开发软件的一种方式。在这种方法中，我们会自动构建、测试和部署代码更改。这有助于我们保持质量和集成。Jenkins 通过自动执行这些步骤帮助我们进行 CI。

使用 Jenkins 实现 CI 的步骤

创建 Jenkins 作业 − 我们可以选择 Freestyle 或 Pipeline 作业类型。我们需要设置源代码存储库。例如，我们可以使用 Git。

配置构建触发器 − 我们设置触发器来检查 SCM 或使用 webhook。这有助于自动构建。

triggers {
    scm('H/5 * * * *') // 每 5 分钟检查一次 SCM
}

定义构建步骤 − 我们指定构建工具。这可以是 Maven、Gradle 或脚本。

steps {
    sh 'mvn clean package' // 这是针对 Maven 项目的
}

添加构建后操作 − 我们可以设置通知、保存工件或部署构建。

post {
    success {
        archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
    }
}

测试自动化 − 我们可以添加测试框架，如 JUnit 或 Selenium。它们会在构建后自动运行测试。

监控构建 − 我们可以使用 Jenkins 仪表板。这有助于我们查看构建状态和日志。

通过遵循这些步骤，我们可以轻松地在开发工作中使用 Jenkins 实现持续集成。

声明式管道示例

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Building...'
                sh 'make'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing...'
                sh 'make test'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying...'
                sh 'make deploy'
            }
        }
    }
}

通过使用 Pipelines as Code，我们可以使我们的 DevOps 更好地工作并改进我们的部署方式。

结论

在本章中，我们了解了 Jenkins 的基础知识。我们讨论了它的设计、如何设置它、如何配置作业以及如何将其与版本控制系统连接。我们还讨论了如何使用持续集成和 Jenkins Pipeline as Code。

DevOps - Puppet

Puppet 帮助我们将基础架构管理为代码。这意味着我们可以自动化配置管理和部署等工作。

在本章中，我们将了解 Puppet 的架构。我们将介绍安装它的步骤。我们还将学习如何编写良好的清单。我们将讨论管理模块、分类节点以及如何将 Puppet 与 CI/CD 管道连接起来。

了解 Puppet 架构

我们可以将 Puppet 架构视为一种管理配置和跨多个系统自动执行任务的方法。它有一些关键部分 −

• Puppet Master − 这是主服务器。它控制配置数据并将其发送到我们管理的节点。它汇总清单并为每个节点制作目录。
• Puppet Agent − 我们在管理的节点上安装这些代理。它们向 Puppet Master 请求更新、应用配置，然后反馈其状态。
• PuppetDB −这是一个可选数据库。它保存 Puppet 创建的数据，如事实和报告。它帮助我们更快地找到数据并提高性能。
• 事实 − 这些是有关系统的信息。Puppet 代理从其节点收集这些信息。事实包括操作系统版本、IP 地址和已安装的软件包等。我们使用事实来做出有关配置的决策。
• 清单 − 我们用 Puppet 的特殊语言(称为 DSL)编写这些清单。清单显示了我们希望如何设置节点。我们将它们保存在模块中。
• 模块 − 这些是清单、文件和模板的组。它们包含特定的配置或应用程序。

Puppet 架构流程

Puppet 代理使用 HTTPS 与 Puppet Master 对话。 Puppet Master 根据代理提供的清单和事实创建目录。代理使用目录来确保节点的设置符合我们的要求。

此架构可帮助我们以灵活且可扩展的方式管理基础架构。它使 Puppet 成为 DevOps 实践中的强大工具。

安装 Puppet

要安装 Puppet，我们需要按照我们的操作系统的步骤进行操作。Puppet 可在 Linux、macOS 和 Windows 等许多平台上运行。以下是在 Linux 系统上安装它的简单步骤 −

先决条件 − 我们需要 root 或 sudo 访问权限。让我们更新包管理器。

安装步骤

对于 Debian/Ubuntu

sudo apt-get update
sudo apt-get install -y puppet

对于 Red Hat/CentOS

sudo yum install -y epel-release
sudo yum install -y puppet

对于 Windows

我们需要从 Puppet 下载页面下载 Puppet 安装程序。然后，我们运行安装程序并按照显示的步骤操作。

验证安装

安装后，我们应该检查 Puppet 是否安装正确。我们可以通过检查版本来做到这一点 −

puppet --version

Puppet 配置

Puppet 的主要配置文件位于 /etc/puppet/puppet.conf。我们可以编辑此文件来更改环境和日志记录等设置。

按照以下步骤，我们可以安装 Puppet 并为我们的配置和管理任务做好准备。

编写 Puppet 清单

我们使用 Puppet 清单作为 Puppet 配置管理的主要部分。这些清单是用 Puppet 的特殊语言编写的。它们向我们展示了我们希望我们的基础设施和资源是什么样子。

清单的基本结构

清单通常具有 −

• 类 − 这些保存配置。
• 资源 −这些显示了我们想要的系统部分(如包、服务和文件)的状态。

简单清单示例

class apache {
   package { 'httpd':
      ensure => installed,
   }

   service { 'httpd':
      ensure => running,
      enable => true,
   }

   file { '/var/www/html/index.html':
      ensure  => file,
      content => 'Welcome to Apache!',
   }
}

定义资源

• 资源类型 − 一些常见类型是包、服务、文件和用户。
• 属性 − 这些属性告诉我们有关属性的信息，例如确保、内容、所有者和模式。

包括类

要将类用于节点，我们可以编写 include 语句 −

include apache

Puppet 清单帮助我们进行模块化和可重用的配置。这使我们更轻松地管理基础设施。

管理 Puppet 模块

我们可以将 Puppet 模块视为帮助我们管理系统各部分的文件组。它们包括清单、模板、文件和其他内容。使用 Puppet 模块有助于我们重用代码并保持其井然有序。以下是我们如何管理 Puppet 模块 −

模块结构

Puppet 模块通常如下所示 −

my_module/
├── manifests/
│   └── init.pp
├── templates/
├── files/
└── metadata.json

创建模块

我们可以使用 Puppet 模块工具创建一个新模块，如下所示 −

puppet module generate my_module

管理依赖项

我们需要在 metadata.json 文件中列出我们的依赖项。以下是示例 −

{
   "name": "my_module",
   "version": "0.1.0",
   "dependencies": [
      {
         "name": "puppetlabs-apt",
         "version_requirement": ">= 7.0.0"
      }
   ]
}

安装模块

要从 Puppet Forge 获取模块，我们可以使用此命令 −

puppet module install <module_name>

更新模块

当我们想要更新模块时，我们只需运行 −

puppet module update <module_name>

模块版本控制

我们应该始终为模块使用像 Git 这样的版本控制。这有助于我们跟踪变化并更好地协同工作。

通过以良好的方式管理 Puppet 模块，我们可以确保我们的基础设施即代码是模块化的、易于维护的，并且可以在需要时进行扩展。

Puppet 环境和分类节点

我们使用 Puppet 环境来管理部署管道每个阶段的不同设置。这包括开发、测试和生产。每个环境都可以有自己的清单和模块。这有助于我们独立测试和开发。

设置 Puppet 环境

目录结构:

我们需要在 下为每个环境创建单独的文件夹 −

/etc/puppetlabs/code/environments/:
 	/etc/puppetlabs/code/environments/
  ├── production/
  └── development/

Puppet 配置:我们应该更改 puppet.conf 以指定我们正在使用的环境 −

    [main]
environment = production

对节点进行分类

节点分类非常重要。它帮助我们将正确的配置应用于正确的节点。Puppet Enterprise 为我们提供了一个用于分类的 GUI。Puppet 还可以在清单中使用节点定义。

示例节点定义

node 'webserver' {
   include apache
}

node 'dbserver' {
   include mysql
}

使用外部节点分类器 (ENC)

对于复杂的设置，我们可以使用 Foreman 或 Hiera 等 ENC。这些工具可以根据节点事实或外部数据动态分配类。这使我们的工作更加灵活，更易于管理。

将 Puppet 与 CI/CD 管道集成

通过将 Puppet 与 CI/CD 管道集成，我们可以更好地交付软件。Puppet 帮助我们实现自动化并保持一致性。我们可以在 CI/CD 流程的不同阶段使用 Puppet 来轻松管理和设置环境。

让我们看看这种集成的关键步骤 −

• 版本控制 − 我们应该将 Puppet 清单和模块存储在 Git 等版本控制系统中。这有助于我们跟踪变化并更好地协同工作。
• CI/CD 工具 − 我们可以使用 Jenkins、GitLab CI 或 CircleCI 等工具来启动 Puppet 运行。我们需要设置构建作业以在部署时应用 Puppet 清单。
• Puppet 代理和服务器 − 代理会自动从 Puppet Master 获取配置。服务器:当我们提交代码时，它会发送更新。
• 环境管理 − 让我们使用 Puppet 环境将配置分开用于开发、测试和生产。

Jenkins 管道片段示例

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                script {
                    sh 'puppet apply /path/to/manifests'
                }
            }
        }
    }
}

结论

在本章中，我们了解了 DevOps 的基础知识。我们重点介绍了 Puppet。我们讨论了 Puppet 的架构及其安装方法。我们还分享了如何创建清单和模块。

我们讨论了如何管理环境和分类节点。我们研究了如何将 Puppet 与 CI/CD 管道连接起来。

DevOps - Ansible

Ansible 是一个强大的工具，可以帮助我们自动化任务。它使配置管理和应用程序部署更加容易。因此，它是 DevOps 的关键资源。

在本章中，我们将了解 Ansible 的结构。我们将讨论清单和剧本等关键思想。我们还将学习如何设置它以用于良好的 DevOps 使用。我们将讨论如何编写好的剧本以及如何使用 Ansible 进行持续集成和部署。

了解 Ansible 架构

我们知道 Ansible 是一个免费的自动化工具。它使用客户端-服务器设置，主要无需主服务器即可工作。其设置包含一些重要部分:

• 控制节点 − 这是我们安装 Ansible 的机器。我们从这里开始任务。它运行剧本并与托管节点对话。
• 托管节点 − 这些是 Ansible 工作所在的机器。它们可以是真实服务器、虚拟机或云实例。我们不需要在这些节点上安装任何代理。 Ansible 使用 SSH 进行通信。
• 库存 − 库存文件显示所有托管节点。它可以是静态的，如 INI 或 YAML 格式。如果我们从云提供商或其他地方提取它，它也可以是动态的。
• 模块 − Ansible 有许多执行特定任务的模块。他们可以安装包、复制文件或管理服务。我们也可以创建自己的模块。
• 剧本 − 这些是 YAML 文件。它们告诉我们我们希望托管节点是什么样的。它们列出了要执行的任务以及执行这些任务的顺序。
• 插件 − Ansible 可以通过插件进行扩展。这些可以改变它的工作方式或添加新功能。例如，我们有连接、操作或过滤器插件。

通过使用此设置，Ansible 很简单，并且可以轻松扩展。这使得它成为 DevOps 实践的绝佳选择。

Ansible 清单

我们在 Ansible 中使用清单来显示我们将运行任务的主机和主机组。清单可以是静态的，如简单的文本文件，也可以是动态的，由脚本创建。

静态清单示例

静态清单通常位于文件中，如 hosts.ini −

[webservers]
web1.example.com
web2.example.com

[databases]
db1.example.com

动态库存

我们可以从云提供商或其他来源获取动态库存。例如，当我们使用 AWS −

ansible-cmd -i aws_ec2.py all -m ping

Ansible Playbooks

我们将 Ansible Playbooks 用作 YAML 文件。它们帮助我们定义一组我们想要在主机上运行的任务。Playbooks 对于自动化任务非常重要。它们帮助我们以可重复和有组织的方式做事。每个 Playbook 都有一个或多个"plays"。这些 play 将我们的主机与我们想要执行的任务联系起来。

Playbook 的结构

---
- name: Playbook Example
  hosts: webservers
  tasks:
    - name: Install Apache
      yum:
        name: httpd
        state: present

    - name: Start Apache
      service:
        name: httpd
        state: started

关键组件

• 主机 − 这些是我们在清单中定义的目标机器。
• 任务 − 这些是我们需要执行的操作。我们为此使用模块。
• 模块 − 这些是内置或自定义脚本。例如，yum 和 service 是我们用来运行任务的模块。

剧本对于管理复杂的工作流程非常重要。它们帮助我们在不同环境中保持配置一致。

Ansible 角色

角色帮助我们更好地组织 Ansible 代码。角色可以有任务、处理程序、变量和模板。这使得在不同的剧本中使用相同的角色变得容易。

角色目录结构

my_role/
  ├── tasks/
  │   └── main.yml
  ├── handlers/
  │   └── main.yml
  ├── vars/
  │   └── main.yml
  └── templates/
      └── config.j2

这些想法清单、剧本和角色构成了 Ansible 配置管理和自动化的主要部分。

为 DevOps 设置 Ansible

我们可以按照一些简单的步骤为 DevOps 设置 Ansible。这将帮助我们进行配置管理和部署。

以下是先决条件 −

• Ansible 在 Linux 上运行效果最佳。我们需要确保我们有一个兼容的操作系统。
• Ansible 需要 Python 才能运行。我们可以使用我们的包管理器(如 apt 或 yum)安装它。

使用包管理器安装(例如 Ubuntu)−

sudo apt update
sudo apt install ansible

使用 pip(Python 包管理器)安装−

pip install ansible

使用以下命令验证安装−

ansible --version

配置

库存文件 − 我们需要在 /etc/ansible/hosts 或自定义文件中定义我们的主机 −

[webservers]
web1.example.com
web2.example.com

Ansible.cfg:我们可以在 ansible.cfg 中更改一些设置 −

[defaults]
inventory = ./inventory
remote_user = your_user

SSH 访问

我们必须确保无需密码即可访问托管节点 −

ssh-keygen -t rsa
ssh-copy-id user@node

此设置可帮助我们使用 Ansible 轻松地在许多服务器上自动执行任务。

编写有效的剧本

我们知道 Ansible 剧本是 YAML 文件。它们定义了我们想要在托管节点上运行的自动化任务。当我们编写有效的剧本时，我们会使其更易于阅读、重用和维护。

以下是一些重要提示:

• 为您的剧本选择清晰的描述性名称。这有助于我们了解每个剧本的作用。
• 组织好剧本。我们可以使用角色来分组任务。这使一切都变得整洁。
• 在单独的 vars 中定义变量如果您有敏感信息，请使用 Ansible Vault。这是一个示例 −

vars:
app_version: "1.0.0"

确保剧本可以多次运行。如果不需要，它们不应更改系统状态。使用幂等的 Ansible 模块。

使用 处理程序 来管理服务。它们仅在发生变化时通知。以下是示例 −

handlers:
  - name: restart web server
    service:
      name: httpd
      state: restarted

添加注释来解释复杂的任务或逻辑。例如 −

# 安装最新版本的 nginx
- name: Install nginx
  yum:
    name: nginx
    state: latest

通过遵循这些技巧，我们可以制作高效且易于管理的 Ansible 剧本。这将有助于我们的 DevOps 工作。

使用 Ansible 进行持续集成和部署

我们可以使用 Ansible 使持续集成 (CI) 和持续部署 (CD) 更容易。Ansible 帮助我们设置和管理环境、部署应用程序并自动运行测试。以下是我们如何将 Ansible 放入我们的 CI/CD 管道中。

使用 Ansible，我们可以多次运行剧本，而不会在第一次运行后更改结果。这使我们的部署更加可预测。

Ansible 不需要目标机器上的代理。这有助于我们保持简单。

工作流程示例

环境设置 − 我们可以使用 Ansible 自动设置和配置环境−

- hosts: all
  tasks:
    - name: Install Docker
      apt:
        name: docker.io
        state: present

代码部署 − 我们可以使用剧本部署我们的应用程序代码 −

- hosts: webservers
  tasks:
    - name: Deploy application
      copy:
        src: /local/path/to/app
        dest: /var/www/app

测试 − 我们可以在部署后自动运行测试 −

- hosts: testservers
  tasks:
    - name: Run tests
      command: /path/to/test_script.sh

与 CI/CD 工具集成

• Jenkins − 我们可以使用 Ansible 插件将剧本作为构建步骤运行。
• GitLab CI − 我们可以从 .gitlab-ci.yml 调用 Ansible 来自动化部署。

通过在 CI/CD 中使用 Ansible，我们可以更快、更可靠地交付软件。它还帮助我们减少手动工作的需求。

结论

在本章中，我们了解了 Ansible 的基础知识。我们讨论了它的结构和重要思想，如清单、剧本和角色。我们还展示了如何为 DevOps 环境进行设置。

编写好的剧本和管理好配置非常重要。Ansible 帮助我们进行持续集成和部署。借助 Ansible，我们可以更好地实现自动化。我们还可以使工作流程更简单，并改善我们在软件开发中的工作方式。

DevOps - Kubernetes

Kubernetes 帮助我们自动化部署、扩展和管理容器化应用程序的方式。这使它成为我们在 DevOps 中的重要工具。

在本章中，我们将介绍 Kubernetes 的基础知识。我们将讨论其架构以及如何设置集群。我们还将讨论如何部署应用程序、管理配置、集成 CI/CD 以及监控策略。

了解 Kubernetes 架构

我们可以将 Kubernetes 架构视为主从设置。它有许多部分可以协同工作以管理容器中的应用程序。主要部分是:

1.控制平面

• API 服务器 − 这是 Kubernetes 控制平面的前端部分。它处理所有 REST 操作。
• 调度程序 − 这有助于将工作负载分配给节点。它查看可用的资源并遵循某些规则。
• 控制器管理器 − 它管理用于检查集群状态的控制器。例如，它与复制控制器一起工作。
• etcd − 这是一个分布式键值存储。它保存所有集群数据，是主要的事实来源。

2. 工作节点

工作节点运行应用程序。他们有 −

• Kubelet − 这是一个与控制平面对话的代理。它管理容器的生命周期。
• Kube Proxy − 它负责服务的网络路由和负载平衡。
• 容器运行时 − 这是运行容器的软件。示例包括 Docker 和 containerd。

3. 网络

Kubernetes 网络帮助 Pod 和服务相互通信。它使用:

• Cluster IP − 这是用于访问服务的内部 IP。
• NodePort − 这会在每个节点 IP 上的固定端口上公开服务。
• LoadBalancer − 它与云提供商合作，为服务设置负载均衡器。

我们需要很好地理解这个架构。它帮助我们有效地管理和部署 Kubernetes 中的应用程序。

设置 Kubernetes 集群

我们可以通过几个步骤设置 Kubernetes 集群。我们可以在本地机器、云服务或我们自己的服务器上执行此操作。在这里，我们将展示使用 kubeadm 设置 Kubernetes 集群的步骤。这是启动集群的常用工具。

以下是先决条件 −

• 操作系统 − 我们需要 Ubuntu、CentOS 或其他 Linux 系统。
• 硬件 − 每个节点至少应有 2 个 CPU 和 2GB RAM。
• Docker −我们必须安装 Docker 并确保它正在运行以管理容器映像。

设置 Kubernetes 集群的步骤

安装 Kubernetes 组件 − 首先，我们运行这些命令 −

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

初始化集群 − 在主节点上，我们运行 −

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

设置本地 Kubeconfig −我们需要为我们的用户设置 kubeconfig −

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

安装 Pod 网络插件(如 Calico) − 我们可以使用此命令安装 Calico −

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

加入工作节点 − 对于每个工作节点，我们使用初始化步骤中的令牌 −

kubeadm join <master-ip>:6443 --token <token> 
   --discovery-token-ca-cert-hash sha256:<hash>

验证 − 要检查节点的状态，我们运行 −

kubectl get nodes

此命令向我们显示主节点和工作节点的状态。这样，我们可以确认我们已正确设置了 Kubernetes 集群。

在 Kubernetes 上部署应用程序

我们可以通过使用 Kubernetes 清单定义应用程序的外观，在 Kubernetes 上部署应用程序。我们通常用 YAML 编写这些清单。我们用于部署的最常见资源是 Pod、ReplicaSet 和 Deployments。在本节中，我们将讨论部署的关键步骤 −

创建部署 − 我们需要在部署清单中定义我们的应用程序的外观。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app-image:latest
        ports:
        - containerPort: 80

应用清单 − 我们使用 kubectl 应用部署 −

kubectl apply -f deploy.yaml

公开应用程序 − 我们创建一个服务以让外部流量到达我们的应用程序。

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: my-app

验证部署 − 我们检查 Pod 和服务的状态 −

kubectl get pods
kubectl get services

通过遵循这些步骤，我们可以在 Kubernetes 集群上成功部署和管理应用程序。

管理配置和机密

在 Kubernetes 中，我们看到配置和机密非常重要。它们帮助我们管理应用程序设置并确保敏感数据的安全。Kubernetes 为我们提供了 ConfigMaps 来处理非敏感配置数据。它还为我们提供了密码或 API 密钥等敏感信息的机密。

ConfigMaps

ConfigMaps 将配置设置保存为键值对。我们可以从文件、文件夹或直接值创建 ConfigMaps。

kubectl create configmap my-config --from-literal=key1=value1 
   --from-file=my-config-file.conf

在 Pod 中使用 − 我们可以将 ConfigMaps 挂载为卷，也可以将其用作环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: CONFIG_KEY
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: key1

Secrets

Secrets 可确保敏感数据的安全。它们以 Base64 编码。我们像 ConfigMaps 一样创建 Secrets，但使用 kubectl create secret 命令。

kubectl create secret generic my-secret --from-literal=password=my-password

在 Pod 中的使用 − Secrets 也可以作为卷安装或用作环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  containers:
  - name: my-secure-container
    image: my-secure-image
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

使用 Kubernetes 实现 CI/CD 管道

我们知道持续集成 (CI) 和持续部署 (CD) 管道在 DevOps 中非常重要。它们帮助我们自动化应用程序的交付方式。Kubernetes 为我们提供了一个强大的平台来部署、管理和扩展应用程序，从而使 CI/CD 变得更好。

关键组件

• 源代码控制 − 我们使用 Git 存储库来存储应用程序代码。
• CI/CD 工具 − 我们使用的工具包括:Jenkins、GitLab CI 和 ArgoCD。
• 容器注册表 −我们可以使用 Docker Hub 或私有注册表来保存我们的镜像。

CI/CD 流程

代码提交 − 我们将代码更改推送到存储库。

构建阶段 − 我们的 CI 工具构建 Docker 镜像。

docker build -t myapp:latest .

测试阶段 − 运行自动测试来检查我们的代码。

推送到注册表 − 我们将成功的构建推送到容器注册表。

docker push myapp:latest

部署 −我们使用 Kubernetes 清单(YAML 文件)进行部署。

 	apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest

Kubernetes 上的 CI/CD 工具

• Helm − 它是 Kubernetes 的包管理器。
• Tekton − 这是一个 Kubernetes 原生的 CI/CD 框架。
• ArgoCD − 我们使用这个 GitOps 持续交付工具。

通过将所有这些部分组合在一起，我们可以使 Kubernetes 中的软件部署过程自动化、高效且可靠。

Kubernetes 中的监控和日志记录

我们知道良好的监控和日志记录对于保持 Kubernetes 集群健康且正常运行非常重要。这些工具可以帮助我们发现问题、检查性能并快速解决问题。

监控工具

• Prometheus − 它是一个用于监控和警报的开源工具。它使用 HTTP 上的拉取模型收集数据。它允许我们使用多维数据和灵活的查询。
• Grafana − 这是一个与 Prometheus 配合使用的可视化工具。我们可以创建仪表板来清楚地查看我们的指标。
• Kube-state-metrics − 此工具为我们提供有关 Kubernetes 对象(如部署和 pod)状态的指标。它为我们提供了详细的监控信息。

日志解决方案

• Fluentd −它是一个数据收集器，可帮助我们整合来自不同地方的日志。它帮助我们轻松地从节点和容器收集日志。
• Elasticsearch & Kibana − Elasticsearch 存储日志。Kibana 帮助我们可视化它们。这些工具非常适合搜索和检查日志。

Prometheus 配置示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
    scrape_configs:
      - job_name: 'kubernetes-nodes'
        kubernetes_sd_configs:
          - role: node

结论

在本章中，我们了解了 Kubernetes 的基础知识。我们讨论了它的结构、如何设置集群、部署应用程序、管理配置、集成 CI/CD 以及监控系统。

DevOps - Jira

JIRA 是一个著名的项目管理工具。它通过提供适合敏捷开发和改进我们运营方式的功能来帮助我们更好地协作。

在本章中，我们将了解如何在 DevOps 设置中使用 JIRA。我们将研究如何设置它、如何将其与 CI/CD 工具连接，并分享一些管理工作流和事件的最佳技巧。

在 DevOps 上下文中理解 JIRA

我们都知道 JIRA。这是 Atlassian 推出的一款用于跟踪问题和项目的流行工具。JIRA 对于 DevOps 实践非常重要。它有助于连接开发和运营团队。此工具提供了一个管理任务、问题和项目的单一位置。

JIRA 在 DevOps 中的主要功能

• 问题跟踪 − 我们可以使用 JIRA 在开发周期中创建、跟踪和管理问题。
• 敏捷方法 − JIRA 支持 Scrum 和看板。这有助于我们的团队更好地管理积压和冲刺。
• 协作 − JIRA 改善了开发人员、QA 和运营之间的沟通。它帮助我们更好地合作。
• 可定制的工作流程 − 我们可以设置工作流程以适应我们自己的流程。这使得任务管理更加高效。
• 集成 − JIRA 可以与许多 CI/CD 工具配合使用，例如 Jenkins 和 GitLab。它还可以与 Splunk 和 New Relic 等监控工具连接。

为 DevOps 团队设置 JIRA

我们可以按照一些简单的步骤为 DevOps 团队设置 JIRA。

• 项目创建 − 首先，我们在 JIRA 中创建一个新项目。我们应该选择一个适合我们团队工作流程的模板。我们可以选择Scrum、Kanban或自定义模板。
• 用户角色和权限 − 接下来，我们定义用户角色。例如，开发人员、测试人员和 DevOps 工程师。然后，我们为每个角色设置权限。这样，团队成员就可以访问他们需要的内容，而不会出现任何安全问题。

• 问题类型 − 我们自定义问题类型。这有助于我们反映适合我们的 DevOps 流程的任务、错误和用户故事。
• 自定义字段 − 我们添加了部署日期、环境和版本号等字段。这些字段可帮助我们跟踪重要的 DevOps 信息。
• Boards Configuration − 我们设置 Scrum 或 Kanban 板。这有助于我们查看工作流程并实时跟踪任务。
• 通知 − 我们配置通知方案。这可让团队随时了解任何更改或更新。
• 集成 − 我们确保 JIRA 可与 Git、Jenkins 和 CI/CD 管道等工具配合使用。这使我们的协作更加轻松。

通过遵循这些步骤，我们可以确保我们的 JIRA 设置已为 DevOps 团队做好准备。这将帮助我们提高生产力并更好地协同工作。

将 JIRA 与 CI/CD 工具集成

通过将 JIRA 与持续集成 (CI) 和持续部署 (CD) 工具集成，我们可以更轻松地开展工作。这种连接帮助我们自动执行许多任务。它还帮助我们跟踪问题、构建和部署。这样，我们的开发团队就可以与项目管理保持同步。

与 JIRA 集成的常见 CI/CD 工具

• Jenkins − 我们可以使用 Jenkins 的 JIRA 插件。它将根据构建结果自动更新 JIRA 问题。
• GitLab CI/CD − 我们可以在 GitLab 设置中设置 JIRA 集成。这会将提交和合并请求链接到 JIRA 问题。
• CircleCI − 我们可以使用 JIRA API。这使我们能够从构建和部署状态创建指向问题的链接。

Jenkins 的示例配置

• 安装 JIRA 插件 − 在 Jenkins 中，我们转到"管理 Jenkins">"管理插件"，然后安装 JIRA 插件。
• 配置 JIRA 站点 − 接下来，我们转到"管理 Jenkins">"配置系统"。在这里，我们添加 JIRA 站点 URL 和凭据。
• 构建后操作 − 在我们的 Jenkins 作业配置中，我们添加了构建后操作。此操作将使用构建结果更新 JIRA 问题。

通过将 JIRA 与 CI/CD 工具集成，我们可以确保跟踪所有开发工作。这有助于我们实现项目目标并支持更好的 DevOps 文化。

在 DevOps 工作流中安装 JIRA

在 DevOps 工作流中设置 JIRA 有助于管理项目并有效跟踪问题。它与开发和运营工具很好地集成。让我们一步一步来。

1. 先决条件

• 服务器或云实例 − 选择 JIRA Cloud 或自行托管。
• 系统要求(自托管) − 确保您的服务器满足 JIRA 硬件和软件要求。
• 数据库 − 准备好兼容的数据库，如 PostgreSQL、MySQL 或 Oracle，用于自托管。

2.自托管 JIRA 的安装步骤

步骤 1 − 下载 JIRA 软件 − 转到 Atlassian JIRA 下载页面。下载适用于您的操作系统(Linux、Windows 或 macOS)的安装程序。

步骤 2 − 安装 JIRA −在 Linux 上，使用 .bin 文件 −

sudo chmod a+x atlassian-jira-software-x.x.x-x64.bin

运行安装程序 −

./atlassian-jira-software-x.x.x-x64.bin

按照步骤设置端口和目录。

在 Windows 上，运行安装程序。按照屏幕上的提示进行操作。如果需要，将其设置为作为服务运行。

在 Docker 上，拉取镜像 −

docker pull atlassian/jira-software

运行容器 −

docker run -d -p 8080:8080 --name jira -v jiraVolume:/var/atlassian/application-data/jira atlassian/jira-software

步骤 3 − 配置数据库 − 使用设置向导选择数据库。通过 .properties 文件或 UI 添加数据库连接设置。

步骤 4 − 许可和设置 −在浏览器中打开安装向导，网址为 http://<your-server-ip>:8080。输入 Atlassian 网站 上的许可证密钥。创建管理员帐户并设置项目默认值。

3. 与 DevOps 工具集成

• JIRA 和 CI/CD 工具 − 将 JIRA 与 Jenkins、GitLab 或 GitHub 链接以自动化工作流程。示例 − 在 Jenkins 中，使用 JIRA 插件在构建后更新问题。
• JIRA 和 SCM − 连接 GitHub 或 Bitbucket 等存储库以跟踪更改。在提交消息中添加 JIRA 问题键以自动链接它们。
• JIRA 和事件管理 − 使用 PagerDuty 或 Opsgenie 等工具将事件和警报与 JIRA 同步

为敏捷实践配置工作流

我们知道在 JIRA 中为敏捷实践配置工作流非常重要。它帮助我们使流程更顺畅，并改善我们作为一个团队的合作方式。JIRA 让我们能够改变工作流程。我们可以将它们融入我们自己的敏捷方法，如 Scrum 或看板。

配置敏捷工作流的关键步骤

• 定义工作流阶段 − 找出敏捷流程的各个阶段。例如，待办、进行中、代码审查、完成。
• 创建新工作流 − 转到 JIRA 管理 > 问题 > 工作流。然后，单击 添加工作流。您可以在此处设置阶段及其连接方式。
• 设置转换 − 定义问题在各个阶段之间的移动方式。例如，从"进行中"到"代码审查"。使用条件、验证器和后置函数来管理这些转换。
• 将工作流分配给项目 − 我们转到项目设置 > 工作流。然后我们将自定义工作流链接到我们想要的项目。

示例工作流配置

有效敏捷工作流程的提示 − 使用泳道来更好地查看正在进行的工作。使用 Scrum 中的冲刺来管理我们的时间限制工作。应用自动化规则来减少手动更新并加快我们的工作速度。

通过以正确的方式在 JIRA 中设置工作流程，您可以帮助您的敏捷团队更好地工作。

结论

在本章中，我们研究了如何在 DevOps 框架中使用 JIRA。我们讨论了如何设置它、如何配置工作流程以及如何将其与 CI/CD 工具连接起来。我们还分享了它在管理事件中的作用以及报告和指标为何如此重要。

DevOps - ELK

良好的日志管理和数据可视化有助于我们保持系统良好可靠地运行。ELK Stack 是一个很好的工具。它包括 Elasticsearch、Logstash 和 Kibana。此堆栈可帮助我们收集、分析和显示来自许多不同来源的日志数据。

在本章中，我们将介绍 ELK Stack 的各个部分。我们还将了解如何设置它以实现更好的日志管理。此设置将帮助我们轻松连接 CI/CD 管道并遵循 DevOps 工作中的最佳实践。

DevOps 中的 ELK Stack

ELK Stack 有三个主要工具:Elasticsearch、Logstash 和 Kibana。此堆栈对于在 DevOps 中记录和显示数据非常有用。我们可以使用它来收集、查看和显示来自许多地方的日志数据。这有助于我们更快地解决问题并关注性能。

ELK Stack 的组件

以下是 ELK Stack 的三个组件 −

• Elasticsearch −这是一个帮助我们搜索和分析数据的工具。它存储和组织日志数据。这样，我们可以快速搜索并轻松收集信息。
• Logstash − 它就像一个数据管道。它从不同的来源获取数据，对其进行更改，然后将其发送到 Elasticsearch。Logstash 可以获取多种类型的数据，例如日志、指标和事件。
• Kibana − 这是我们在网上用来查看数据的工具。它帮助我们创建仪表板、图表和图形。使用 Kibana，我们可以以简单的方式可视化我们的日志数据。

设置 Elasticsearch 进行日志管理

我们知道 Elasticsearch 是一个分布式搜索和分析引擎。它对于 ELK Stack 非常重要。要设置 Elasticsearch 进行日志管理，我们可以按照以下简单步骤操作。

Elasticsearch 安装

对于 Debian 或 Ubuntu，使用以下命令 −

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.x.x-amd64.deb
sudo dpkg -i elasticsearch-7.x.x-amd64.deb

对于基于 RPM 的系统，我们可以运行以下命令 −

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.x.x-x86_64.rpm
sudo rpm -ivh elasticsearch-7.x.x-x86_64.rpm

启动 Elasticsearch − 我们可以使用此命令启动 Elasticsearch −

sudo service elasticsearch start

Elasticsearch 配置

编辑 elasticsearch.yml − 在 /etc/elasticsearch/ 中找到此文件。像这样更改它 −

network.host: localhost
http.port: 9200
cluster.initial_master_nodes: ["node-1"]

验证安装

检查 Elasticsearch 是否正在运行。我们可以使用此命令 −

curl -X GET "localhost:9200/"

索引创建

现在我们为日志管理创建一个索引。我们可以运行此命令 −

curl -X PUT "localhost:9200/logs/"

此设置有助于 Elasticsearch 很好地收集、存储和管理日志。它还允许我们以强大的方式搜索和分析数据。

配置 Logstash 以进行数据提取

我们知道 Logstash 是一种强大的数据处理工具。它从不同的地方获取数据，对其进行更改，然后将其发送到我们选择的地方，例如 Elasticsearch。要设置 Logstash，我们需要在配置文件中定义输入、过滤器和输出插件。

基本配置结构

标准 Logstash 配置文件有三个主要部分 −

input {
   # Define input sources
   beats {
      port => 5044
   }
}

filter {
   # Data transformation
   grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
   }
   date {
      match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
   }
}

output {
   # Define output destination
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "logs-%{+YYYY.MM.dd}"
   }
}

请注意以下要点 −

• 使用输入插件确认数据来自何处(如 Beats、Kafka 或文件)。
• 过滤插件帮助我们更改数据(如解析或添加信息)。
• 使用输出插件将数据发送到我们想要的位置(如 Elasticsearch 或文件)。

示例输入插件

要从文件获取输入，我们可以使用 −

input {
   file {
      path => "/var/log/myapp/*.log"
      start_position => "beginning"
   }
}

运行 Logstash

要使用我们的配置启动 Logstash，我们可以运行 −

bin/logstash -f path/to/your/logstash.conf

此设置允许 Logstash 获取日志、处理日志并将其发送到 Elasticsearch 进行进一步检查。

使用 Kibana 进行数据可视化

我们可以使用 Kibana 作为强大的可视化工具。它与 Elasticsearch 配合得很好。它帮助我们以简单的方式探索和显示数据。我们可以使用其易于使用的界面轻松创建交互式仪表板、图表和图形。

以下是Kibana 的主要功能 −

• 仪表板 − 我们可以将许多可视化效果组合到一个视图中。这让我们可以全面了解我们的数据。
• 可视化 − 我们可以创建不同类型的可视化效果。这包括折线图、饼图和地图。
• 搜索和过滤 − 我们可以使用 Lucene 查询语言。这有助于我们更好地搜索和过滤日志。

开始使用 Kibana

首先，让我们安装 Kibana −

sudo apt-get install kibana

接下来，您需要配置 Kibana。我们需要更改 kibana.yml 文件以将其连接到我们的 Elasticsearch −

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://localhost:9200"]

现在让我们启动 Kibana −

sudo service kibana start

要访问 Kibana，请打开浏览器并转到 http://localhost:5601。

创建可视化

您可以使用"可视化"选项卡选择所需的可视化类型。然后，选择与我们的数据匹配的索引模式。接下来，设置指标和存储桶。它将帮助您决定如何显示和分组数据。

通过使用 Kibana，您可以实时了解应用程序的执行情况以及日志数据的查看方式。

将 ELK Stack 与 CI/CD 管道集成

通过将 ELK Stack 添加到我们的 CI/CD 管道中，我们可以更好地进行监控和故障排除。这为我们提供应用程序日志和性能数据的实时视图。以下是我们如何将 ELK 组件添加到我们的 CI/CD 工作流 −

• 持续日志收集 − 我们可以在构建和部署阶段使用 Logstash 或 Filebeat 从我们的应用程序获取日志。我们应该以相同的方式格式化日志，以便它们更易于阅读。
• 自动数据提取 − 让我们设置 Logstash 以自动从不同来源获取日志 −

input {
   beats {
      port => 5044
   }
}
filter {
   # 用于解析应用程序日志的过滤器示例
   grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
   }
}
output {
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "app-logs-%{+YYYY.MM.dd}"
   }
}

• 仪表板创建 − 我们可以使用 Kibana 制作显示应用程序性能和错误率的仪表板。我们应该自动化在 CI/CD 管道中部署 Kibana 仪表板的方式。
• 警报 − 我们需要在 Kibana 中设置警报或使用 Elasticsearch Watcher。这将帮助我们在部署时告知团队严重问题。
• 反馈循环 − 我们可以使用 ELK 中的日志和指标来不断改进我们的 CI/CD 流程。

通过执行这些步骤，我们可以将 ELK Stack 紧密集成到我们的 CI/CD 管道中。这将帮助我们更清楚地了解问题并更快地做出响应。

结论

在本章中，我们研究了 ELK Stack 的重要部分。这些部分是 Elasticsearch、Logstash 和 Kibana。它们在改善 DevOps 方面发挥着重要作用。

我们设置了 Elasticsearch 来管理日志。我们还配置了 Logstash 来接收数据。然后，我们使用 Kibana 以清晰的方式显示数据。通过将 ELK Stack 与 CI/CD 管道结合在一起，我们展示了它如何帮助我们监控和修复问题。

DevOps - Terraform

在本章中，我们将介绍 Terraform 的基本思想。我们将讨论其结构、配置文件以及我们如何管理状态。我们还将研究为什么使用 Terraform 模块有利于可重用性。我们将了解如何在 CI/CD 管道中使用 Terraform。最后，我们将分享最佳实践，以便在我们的 DevOps 工作流中充分利用 Terraform。

了解基础设施即代码 (IaC)

基础设施即代码或 IaC 是一项重要的 DevOps 实践。它帮助我们用代码管理基础设施，而不是手工操作。使用 IaC，我们可以使用简单的配置语言定义、创建和管理我们的基础设施。这为我们提供了更多的一致性、可重复性和发展能力。

常见的 IaC 工具

以下是一些常见的 IaC 工具 −

• Terraform − 用于构建、更改和跟踪基础设施的工具。
• Ansible − 用于管理配置和编排的工具。
• CloudFormation −用于 AWS 设置资源的特殊 IaC 工具。

使用 IaC 时，我们可以缩短部署周期并更好地管理我们的基础设施。

Terraform 架构和组件

我们将讨论 Terraform 的工作原理。它使用客户端-服务器结构，其中包含一些重要部分。这有助于我们更好地管理我们的基础设施。

以下是 Terraform 架构的关键组件:

• Terraform CLI 是我们用来运行 Terraform 命令的命令行工具。我们可以在这里管理我们的基础设施并使用配置文件。
• 提供程序是帮助 Terraform 连接到不同云服务(如 AWS、Azure 或 Google Cloud)的插件。每个提供商都有我们可以使用的自己的资源。
• 资源是 Terraform 中的基本构建块。它们代表云中的服务或基础设施的一部分。例如，我们可以创建 EC2 实例或 S3 存储桶。以下是示例配置 −

resource "aws_instance" "example" {
   ami = "ami-0c55b159cbfafe01e"
   instance_type = "t2.micro"
}

状态文件 − 这些是 JSON 文件，用于跟踪我们基础设施的当前状态。它们对于将现实世界的资源链接到我们的配置非常重要。

模块 − 这些是我们一起使用的资源组。它们帮助我们重用代码并保持井然有序。以下是一个例子 −

module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

后端 − 这是我们存储状态文件的地方。它可以是本地的，也可以是远程的，比如 S3 或 Terraform Cloud。这有助于我们协同工作并管理状态。

了解这些部分对于我们在 DevOps 设置中很好地使用 Terraform 非常重要。

编写 Terraform 配置文件

我们使用 HashiCorp 配置语言 (HCL) 编写 Terraform 配置文件。这种语言易于人类阅读，也适用于机器。这些文件帮助我们定义我们想要创建和管理的基础设施资源。

Terraform 配置通常具有这些主要部分 −

提供商块 − 这显示我们正在使用哪个云提供商。例如，我们可以使用 AWS 或 Azure。

provider "aws" {
   region = "us-west-2"
}

资源块 − 这部分告诉我们想要创建什么资源。

resource "aws_instance" "web" {
   ami = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

输出块 − 这显示我们运行配置后的信息。

output "instance_ip" {
   value = aws_instance.web.public_ip
}

变量和输入

我们可以定义变量，使我们的配置更易于重用 −

variable "instance_type" {
    description = "Type of instance"
    default = "t2.micro"
}

我们可以在资源定义中使用这些变量 −

resource "aws_instance" "web" {
   ami = "ami-0c55b159cbfafe1f0"
   instance_type = var.instance_type
}

管理 Terraform 状态

管理 Terraform 状态非常重要。它帮助我们跟踪配置创建的资源并让我们正确地更改它们。Terraform 保留一个名为 terraform.tfstate 的状态文件。此文件显示我们基础设施的当前状态。如果我们管理得当，我们可以保持一切一致并避免配置漂移。

让我们了解它的一些关键概念 −

• 状态文件 − 这是一个 JSON 文件。它将我们配置中的资源与现实世界的项目联系起来。
• 远程状态 −当我们远程存储状态文件时，例如在 AWS S3、Azure Blob Storage 或 Terraform Cloud 中，它可以帮助我们更好地协作并防止我们丢失数据。

状态管理的最佳实践

使用远程后端 − 这有助于我们进行锁定和版本控制。以下是 AWS S3 的示例配置 −

terraform {
   backend "s3" {
      bucket  = "my-terraform-state"
      key = "terraform.tfstate"
      region = "us-east-1"
      dynamodb_table = "terraform-locks"
   }
}

状态锁定 − 这会同时停止可能扰乱状态的多个操作。

状态加密 − 我们应确保在存储状态文件中的敏感数据时对其进行加密。

状态命令

• terraform state list − 此命令向我们显示状态中的资源。
• terraform state show <resource> − 此命令提供有关特定资源的详细信息。
• terraform state rm <resource> − 此命令从状态中删除资源，但不会销毁它。

Terraform 模块和可重用性

Terraform 模块是容纳我们一起使用的不同资源的盒子。它们帮助我们制作可以重复使用的部分。这使我们的代码更易于管理，我们不必一遍又一遍地编写相同的内容。

模块通常具有以下三个文件 −

• tf − 此文件具有资源定义。
• tf − 此文件定义输入变量。
• tf − 此文件显示模块的输出。

您可以通过在我们的 Terraform 配置文件中编写模块块来使用模块。 −

module "vpc" {
   source = "./modules/vpc"
   cidr_block = "10.0.0.0/16"
   availability_zones = ["us-west-2a", "us-west-2b"]
}

简单模块示例

# modules/vpc/main.tf
resource "aws_vpc" "main" {
    cidr_block = var.cidr_block
}
# modules/vpc/variables.tf
variable "cidr_block" {
    description = "VPC 的 CIDR 块"
    type = string
}
# modules/vpc/outputs.tf
output "vpc_id" {
    value = aws_vpc.main.id
}

正确使用模块可以简化我们的 Terraform 设置，并帮助我们遵循管理基础设施的良好做法。

在 CI/CD 管道中实现 Terraform

我们可以在 CI/CD 管道中使用 Terraform 来自动化我们设置基础设施的方式。这有助于我们保持一致性，并允许我们快速部署。以下是将 Terraform 添加到我们的 CI/CD 工作流中的简单方法:

现在让我们了解集成 Terraform 的步骤 −

• 首先，确保您的 CI/CD 工具(如 Jenkins、GitLab CI 或 GitHub Actions)可以访问正确的凭据。这将使其与我们的云提供商对话。
• 将您的 Terraform 配置文件 保存在 Git 等版本控制的存储库中。使用环境变量或机密管理工具来管理 API 密钥等敏感数据是个好主意。
• 运行 terraform plan 以制定执行计划。这向我们展示了在不应用它们的情况下会发生哪些变化。

terraform init
terraform plan -out=tfplan

我们可以添加一个步骤来手动批准重要更改。然后，运行 terraform apply 来设置基础架构。

terraform apply tfplan

您应该在部署基础架构后添加测试来检查它是否正常工作。如果需要，请使用 terraform destroy 清理资源。

CI/CD 工具集成示例

GitHub Actions −

name: Terraform CI
on:
  push:
    branches:
      - main
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 1.0.0
      - name: Terraform Init
        run: terraform init
      - name: Terraform Plan
        run: terraform plan

DevOps 中 Terraform 的最佳实践

我们需要在 DevOps 环境中很好地使用 Terraform。这意味着我们应该遵循一些最佳实践。这有助于我们保持工作易于管理、发展和协同工作。以下是一些重要提示 −

组织配置文件 − 我们应该以清晰的方式安排我们的 Terraform 文件。它有助于为每个环境(如开发、暂存和生产)使用不同的文件夹。

├── main.tf
├── variables.tf
├── outputs.tf
├── dev/
│   ├── main.tf
├── prod/
│   ├── main.tf

您可以为基础设施的通用部分制作可重用模块。这有助于我们遵循 DRY 原则，即不要重复自己。

使用远程状态存储(如 AWS S3)和 DynamoDB 进行锁定非常重要。这有助于我们安全地协同工作并避免问题。以下是后端设置示例 −

terraform {
   backend "s3" {
      bucket = "my-terraform-state"
      key = "statefile.tfstate"
      region = "us-east-1"
      dynamodb_table = "terraform-locks"
   }
}

您应该经常运行 terraform fmt 和 terraform verify 命令。这样可以保持代码质量良好且易于阅读。

结论

在本章中，我们研究了 DevOps 框架中 Terraform 的重要部分。我们讨论了基础设施即代码 (IaC) 原则。我们还介绍了 Terraform 架构、如何编写配置、状态管理、模块可重用性以及如何将其集成到 CI/CD 管道中。

---