10 分钟读懂 DevOps 工具链

【译文】上周，我和我的几位非常资深的同事都在评论说，有很多新的DevOps工具正在出现，而且每天都越来越难跟踪它们，以及它们在DevOps 领域的定位。我问了他们几个工具，Ansible、Terraform、Salt、Chef、Bamboo、CloudFormation这些工具的定位在哪里？我为什么要用这个而不是那个？它们甚至是同一种东西吗？我是不是漏掉了一个主要角色？我得到了什么，一些白眼和问题。所以，我想我会做一些研究，阅读，并试图让我们所有人理解它，以便我们可以将那些产品都分类到我们都熟悉的类别或用途。

原文：https://levelup.gitconnected.com/the-10-minute-read-to-understanding-devops-tools-bc4ac807a25d

在我们开始谈论DevOps工具和类别之前，让我们退一步讨论几个基本的（但往往是超载的）术语以及它们的含义。

计算机/服务器 - Computer/Server：具有中央处理器（CPU）、内存（RAM）、本地存储（磁盘）并运行操作系统的物理设备。

虚拟机 - Virtual Machine：在主机上运行的计算机系统的模拟器（虚拟机管理程序）；vm 通常可以在CPU、内存和磁盘使用方面与其他操作系统隔离。

容器–Containers：打包一个软件及其所有依赖，使其能够在任何基础设施上统一、一致地运行。Docker容器是最流行的。它们允许你打包一堆东西（你的软件、配置和其他软件），以便于部署和传输。你可以把容器看作是虚拟化的下一代进化（继虚拟机之后）。

网络设备 - Network Device：在设备之间路由网络流量的硬件。例如路由器、负载平衡器和防火墙。

软件 - Software：编码并在操作系统上运行的代码。

DevOps - 传统上有 “开发”（你来构建它），还有 “运维”（我们将运行它），他们两者之间的一切都受制于作坊式的工作方式。从2010年左右开始，到2018年左右DevOps 已经发展为几乎无处不在的现象，DevOps的理念是：“一套实践，目的是在保证高质量的前提下，缩短从提交系统变更到变更投入正常生产环境之间的时间”。

当你在考虑构建和运行一个非同寻常的系统时，其实还有很多不得不做的事情。以下是需要考虑到的传统的事项清单。

获取计算机/服务器硬件（Obtaining the computer/server hardware）
配置计算机/服务器硬件（操作系统、网络布线等）（Configuring the computer/server hardware (operating systems, network wiring, etc.)）
监控计算机/服务器硬件（Monitoring the computer/server hardware）
获取网络设备（负载均衡器、防火墙、路由器等）（Obtaining the network devices (load balancers, firewalls, routers, etc.)）
配置网络设备（Configuring the network devices）
监控网络设备（Monitoring the network devices）
编写软件（Constructing the software）
构建软件（Building the software）
测试软件（Testing the software）
软件打包（Packaging the software）
部署/发布软件（Deploying/releasing the software）
监测软件（Monitoring the software）

在DevOps之前，我们曾经有四个不同的团队在做这项工作。

Developer 开发人员 — 他们会做 #7, #8 ，有时候包括 #10
QA 测试人员— 他们会做 #9 ，有时候包括 #11
System Administrator 系统管理员 — 他们会做 #1, #2, #3, #12
Network Administrator 网络管理员 — 他们会做 #4, #5, #6

对于硬件、网络设备和软件的配置，每个团队很可能会使用自己的一套脚本和工具，而且在很多情况下，会通过手工操作来实现 “软件发布”。

随着DevOps的出现，对我来说，关键的想法是打破这些部门墙，让每个人都成为 “一个 " 团队的一部分，为所有事物的配置、部署和管理方式带来一致性。

云–Cloud：定义信息技术史上最流行的名词是很难的，但我喜欢那件T恤，上面写着 “没有云，只是别人的电脑”。最初，当云服务开始的时候，它们真的只是别人的电脑（或者运行在电脑上的虚拟机），或者存储。随着时间的推移，它们已经演变成到了现在的状态，包含很多很多的增值服务。硬件大部分已经被抽象掉了，现在大多数云服务中，你不能购买它们的硬件设备，但你可以购买这些硬件设备所提供的各种云服务。

基础架构即代码(IAC)–：一种新的能力或概念，它允许我们通过定义或配置文件来完整的定义数据中心中所有项目的设置，包括虚拟机、容器和网络设备。这个概念是我可以创建一些配置和一些脚本，然后使用我们即将讨论的一个工具来运行它们，它们会自动为我们按需配制出数据中心的所有服务。CI/CD是IAC的前身，多年来我们一直致力于自动化我们的构建/测试/集成/部署周期，在我们的云基础设施上做这个工作是一个自然的延伸。这带来了成本的降低，更快的上市时间，以及更小的风险（人为错误）。

随着IAC的出现，许多传统的开发工具现在可以用于管理基础设施。像软件仓库、构建工具、CI/CD、代码分析器和测试工具等类别的工具（如下所列），传统上是由软件开发人员使用的，现在可以被DevOps工程师用来构建和维护基础设施。

AGAIN: “随着DevOps的出现，对我来说，关键的理念是……让每个人都成为’一个’团队的一部分，为所有事物的配置、部署和管理方式带来一致性。”

因此，现在我们已经定义了以上基础术语/概念，让我回到试图对DevOps工具进行分类的任务，以使我们更容易确定什么工具是用于什么目的的。

软件仓库 – 管理软件版本的工具–目前使用最广泛的是Git。
构建工具–有些软件在打包或使用前需要编译，传统的构建工具包括Make、Ant、Maven和MSBuild。
持续集成工具–在配置好以后，每次将代码提交到存储库中时，它都会对软件进行构建、部署和测试。这通常可以提高软件质量和上市时间。这个市场上最流行的工具是 Jenkins、Travis、TeamCity和Bamboo。
代码分析/审查工具–这些工具可以查找代码中的错误，检查代码格式和质量，以及测试覆盖率。这些工具因编程语言而异。SonarQube是这个领域的一个流行工具，还有其他各种 “轻量的 “工具。
配置管理–配置管理工具和数据库通常存储所有关于你的硬件和软件项目的信息，以及提供一个脚本和/或模板系统，用于自动化常见任务。在这个领域似乎有很多玩家。传统的玩家是Chef、Puppet和Salt Stack。
部署工具–这些工具有助于软件的部署。许多CI工具也是CD（持续部署）工具，它们协助软件的部署。传统上在Ruby语言中，Capistrano工具被广泛使用；在Java语言中，Maven被很多人使用。所有的编排工具也都支持某种形式的部署。
编排工具–这些工具配置、调度和管理计算机系统和软件。它们通常将 “自动化 “和 “工作流 “作为其服务的一部分。Kubernetes是一个非常流行的编排工具，它专注于容器。Terraform是一个非常流行的编排工具，它的关注点更广，包括云编排。另外，每个云提供商都有自己的一套工具（CloudFormation、GCP Deployment Manager, 和ARM）。
监控工具 - 这些工具允许监控硬件和软件。通常，它们包括监控代理程序，用于监视进程和日志文件，以确保系统的健康。Nagios是一种流行的监控工具。
测试工具 - 测试工具用于管理测试，以及测试自动化，包括性能和负载测试等。

当然，和其他任何一套产品一样，类别也不一定完全清晰。许多工具都是跨类别的，并提供两个或多个类别的功能。下面是我试图展示大多数非常流行的工具，并可视化它们在这些类别中的位置。

正如你所看到的，有几个玩家，如Ansible、Terraform和云工具(AWS、GCP和Azure)，正试图通过他们的产品覆盖部署、配置管理和编排类别。老牌工具集Puppet、Chef和Salt Stack专注于配置管理和自动化，但已经扩展到编排和部署的。还有像GitLab和Azure DevOps这样的工具，几乎试图跨越DevOps的所有类别。

我希望这个概述能帮助你了解DevOps的基础知识，可用工具的类别，以及目前市场上的各种产品如何在这些类别中的一个或多个类别中提供帮助。在Solution Street，多年来我们已经使用了许多这样的工具，对我们来说，没有一个单一的 “一招鲜 “的工具能胜任所有情况下使用。使用什么是基于所使用的技术，在哪里托管（以及未来可能在哪里托管），以及团队的人才和构成。

教练观点：敏捷教练不能回避DevOps 工具链的话题，中低层管理人员更应该在宏观上深刻理解 SLDC 所有环节的技术概要和工具需求，需要具备基础的概念知识，具备和工程师讨论所必备的语言。工程师们更要有工具链整体优化的意识，而不仅仅是精通某个环节，或局限在与自己的上下游工具上，工作在这个系统中的所有人需要有全局协作和优化的意识，优化价值流的流量、流速，关注价值的产生。警惕—-整个工具链的自动化程度越高，不一定工作效率越高，加班越少，公司盈利越多。它们其实是相互作用的。