建议收藏！2020 年必备的几个 DevOps 工具

时间 2020-06-12

标签建议收藏必备几个 devops 工具繁體版

原文原文链接

提到 DevOps 这个词，我相信不少人必定不会陌生。做为一个热门的概念，DevOps近年来频频出如今各大技术社区和媒体的文章中。到了 2020 年，DevOps 的革命也终于成为了一个主流，DevOps 相关工具的受欢迎程度也在激增。根据 Google 趋势，「DevOps 工具」的搜索量一直在稳定增加，而且这种趋势还在持续。git

DevOps 工具愈来愈多，了解它们以及知道在何时使用他们愈来愈重要。因为 DevOps 涵盖了整个软件开发生命周期，所以有不少工具可供选择。让咱们将其大体分为如下几类：数据库

开发和构建工具
自动化测试工具
部署工具
运行时 DevOps 工具
协做 DevOps 工具

成功且成熟地采用 DevOps 作法将始终拥有完整的渠道，其中包括适用于这五个类别的工具。确保评估您当前的工具堆栈，以确保您没有丢失 CI/CD 管道的关键部分。编程

开发和构建工具

这是 CI/CD 管道堆栈的基础。一切都从这里开始。该类别中最好的工具能够协调多个事件流，并能够轻松地与外部工具集成。后端

软件开发生命周期的这一部分中的工具分为三个子类别：安全

源代码控制管理（SCM）
持续集成（CI）
数据管理

2020年，推荐的SCM技术是GIT，所以咱们的SCM工具必须具备出色的GIT支持。对于CI，绝对须要在临时容器化环境中运行和执行构建的能力。对于数据管理，咱们须要可以对数据库架构进行更改并使它与应用程序版本保持一致。服务器

2020年排名第一的SCM + CI工具：Gitlab和Gitlab-CI

Gitlab无疑是2020年最伟大的DevOps Lifecycle工具，它将在可预见的将来成为创新的领导者。网络

Gitlab的核心功能提供了一个完美的GIT存储库管理工具。它基于Web的用户界面是最冗长且易于使用的。Gitlab的免费套餐可提供您所需的一切，而且具备SaaS和On-Prem尺寸。架构

市场上有不少SCM工具，可是没有一种工具像Gitlab多年来所作的那样将“持续集成”直接集成到您的存储库中。称为Gitlab-CI，将.gitlab-ci.yml文件粘贴到代码库的根目录中，任何GIT事件都会根据您在此处定义的内容触发操做。他们确实是按代码进行持续集成的领导者。框架

主要优点：编程语言

成熟度 - 该产品自2013年以来一直投放市场，而且很是稳定而且获得了很好的支持。
开源 - Gitlab的免费版没有削减开发团队所需的核心功能。每一个付费层都提供了附加功能，这些附加功能可根据组织的规模和需求带来极高的价值。
易用的 CI — 市场上没有其余工具能够像Gitlab-CI同样直接将持续集成直接嵌入到您的SCM中。使用Docker构建进行临时构建的能力提供了无忧的构建做业，而且内置的报告使调试构建失败变得容易。无需复杂的集成和业务流程就能够对多种工具进行编排。
无限集成 - Gitlab提供了每一个核心DevOps类别中所需工具的轻松集成。这使开发人员和操做人员在任何环境中均可以使用一个真实的来源来获取与其应用程序相关的信息。

竞争对手:

还有其余工具在此领域也很流行，可是它们不如Gitlab。缘由以下：

GitHub - GitHub一直是小型和早期开发商店的出色SaaS源代码管理系统。可是，对于须要在网络中保留其IP的大型企业，GitHub的惟一选择是.OVA不支持高可用性的虚拟机。这使其难以维护on-prem，而且只能在中型组织中运行，而后服务器自己才开始崩溃。它缺乏GitHub Actions（直到最近，但仍不在本地版本中）或CI-as-Code，这意味着您始终须要带上本身的CI工具并管理该集成。最后，它比任何Gitlab订价都昂贵。
Jenkins — 尽管Jenkins已经成为持续集成工具的默认标准，但它始终缺乏源代码控制元素。意味着，您将始终使用Jenkins 和 SCM工具。当像GitLab这样的工具同时提供这两种功能时，这简直是没必要要的复杂。它可怕的UX使得现代Web应用程序有不少不足之处。
BitBucket/Bamboo — 我不得不说，这是一个自动失败者，考虑到您须要两种工具来完成Gitlab的一项工做。尽管BitBucket云支持Gitlab-CI / GitHub Action功能，但没有一家公司（规模超过一家初创公司）能够轻易采用它。用于本地的 BitBucket服务器甚至不支持BitBucket管道！

2020年排名第一的数据管理工具：FlywayDB

Web应用程序开发中最容易被忽视的方面是数据库的自动化需求。在应用程序的新版本中部署数据库架构更改一般是过后的想法。模式更改一般会添加或重命名列或表。若是应用程序版本与架构版本不匹配，则该应用程序可能会彻底损坏。因为存在两个不一样的系统，所以经过应用程序升级来协调数据库更改也可能很困难。FlyWayDB解决了全部这些问题。

主要优点：

数据库版本控制 - FlyWay容许您简单地建立数据库版本，跟踪数据库迁移以及轻松地前滚或后退架构更改，而无需某些定制解决方案。
二进制或内置 - 您能够选择在应用程序启动时或做为二进制可执行文件运行Flyway。在代码中使用此工具，以便它在启动时检查版本功能并运行适当的迁移，从而使数据库和应用程序版本保持同步。您也能够临时运行cmd行，从而在不重建整个应用程序的状况下为现有数据库提供了灵活性。

竞争对手：

这个空间中没有太多工具。可是，让咱们来看几个：

LiquiBase — Liquibase是类似的，实际上，若是有人在个人组织中工做过，那么我很乐意经过FlyWay对该工具进行标准化。
Flocker - 这可能仅适用于容器化的应用程序-在容器中运行数据库很是困难，必须精心计划才能成功执行。我建议将RDS之类的服务用于数据库，而不要尝试运行存储在容器中的关键数据。

自动化测试工具

咱们必须首先将自动化工具安装到测试金字塔中，从而开始对自动测试工具进行评估。测试金字塔有4层：

单元测试 - 这是全部自动化测试的基础。就数量而言，与其余类型相比，您应该拥有最多的单元测试。这些测试应由软件开发人员编写和运行，以确保应用程序的一部分（称为“单元”）符合其设计并按预期运行。
组件测试 — 组件测试的主要目的是验证测试对象的输入/输出行为。这样能够确保测试对象的功能按照所需规范正确运行。
集成测试 — 这是测试阶段，在此阶段中，各个软件模块被组合在一块儿并做为一个总体进行测试。
端到端测试 - 此层是不言自明的。咱们正在研究从头至尾的应用程序流程，并使其表现出预期的效果。

因为单元和组件层测试仅由应用程序开发人员驱动，而且一般是特定于编程语言的，所以咱们不会在DevOps空间中评估这些工具。

2020年排名第一的集成测试工具：Cucumber

Cucumber将规范和测试文档合并为一个有凝聚力的有效文档。因为它们是由Cucumber自动测试的，所以您的规格始终是最新的。若是您想开始构建Web自动化测试框架并在Web应用程序上模拟用户行为，那么带有Java和Cucumber BDD的Selenium WebDriver是在项目中学习和实现Cucumber的好方法。

主要优点：

行为驱动的开发 — Cucumber用于BDD测试，它已成为一种入门测试框架（与传统的测试驱动开发相比）。
动态文档 - 记录您所作的事情老是很痛苦。因为您的测试被定义为代码，所以Cucumber测试会自动生成文档以进行匹配以确保它们始终保持同步。
支持 - 这里有不少工具可供选择，可是当状况变得严重时，您须要工具维护者的认真支持。黄瓜拥有足够的资金和支持结构来维持该工具的将来几年。

竞争对手：

在这个领域中有许多框架和特定于技术的工具，可是只有Cucumber接近于“一刀切”的解决方案。

端到端测试工具

进行端到端测试时，有两个重点领域须要关注：

功能测试
负载测试

功能测试显然是在测试咱们想要发生的事情是否实际发生。当我单击SPA上的某些页面，填写表格并单击Submit时，数据将显示在数据库中，而且屏幕显示成功！

咱们还须要可以测试在相同场景下工做的x数量的用户是否能够正确处理。

若是您在这两个方面都没有进行测试，则CI / CD管道中的差距将很大。

2020年排名第一的端到端测试工具 — 功能：SoapUI Pro

因为SOAP Web服务是默认的，所以SoapUI进入API测试领域已有很长时间了。尽管咱们再也不构建新的SOAP服务，而且该工具的名称没有更改，但这并不意味着它没有发展。SoapUI为构建后端Web服务的自动化功能测试提供了一种出色的结构。这些能够轻松地与持续集成工具集成，而且能够做为咱们的CI / CD管道的一部分运行。

主要优点：

普遍的文档 - 此工具已经存在了一段时间，所以有许多在线资源可帮助您肯定如何配置负载测试。
易于使用 — 尽管有多种API测试工具可用，但拥有一个用于多种服务的接口可使构建测试变得简单。

竞争对手：

Selenium - Selenium是该领域的另外一个出色工具。若是您正在构建和运行基于Java的应用程序，则建议使用它。可是，若是您要使用多种技术来处理一个完整的Web应用程序，那么对于非Java语言的用户来讲可能会有些笨拙。

2020年排名第一的端到端测试工具 — 负载测试：LoadRunner

说明：在对应用程序的各个方面进行负载测试时，只有LoadRunner才能完成。是的，这很昂贵并且入门有点困难，可是它是惟一能够执行测试的工具，可使我做为技术架构师相信新代码将在极端压力下执行。另外，我认为如今是时候让负载运行技巧从SQA资源转移到开发团队了。

主要优点：

普遍的文档 - 该工具已经存在了一段时间，所以有许多在线资源能够帮助您肯定如何配置负载测试。
协议支持 - 从ODBC到AJAX，再到HTTPS以及您的应用程序可能在某处使用的其余晦涩协议，LoadRunner支持该协议。咱们要避免串接多个负载测试工具-这只会增长复杂性。

击败竞争对手：

再说一次，在这个领域中没有太多的“一刀切”的工具，所以简单的解决方案是能够在任何环境中使用任何技术将其丢弃。

部署工具

部署工具多是应用程序开发中不为人知的方面。对于操做人员来讲，若是不深刻了解应用程序代码和功能，就很难使用部署工具。对于开发人员来讲，管理代码部署是一项新的职责，所以他们对许多部署工具的经验不多。

首先，让咱们将部署工具分为三个子类别：

构件管理
配置管理
部署方式

2020年排名第一的工件管理工具：Nexus

Nexus工件存储库支持几乎全部主要技术，从Java到NPM再到Docker。咱们可使用这一工具来存储咱们全部可部署的工件。经过使软件包更接近构建过程，代理远程软件包管理器的能力还大大提升了咱们CI配置的速度。这样作的另外一个好处是，咱们能够全局查看跨多个软件项目使用的全部软件包，从而锁定不安全的开源软件包，这些软件包多是咱们代码中的攻击媒介。

主要优点：

技术支持 - 该产品自2013年以来一直投放市场，而且很是稳定且获得了很好的支持。
开源 - Gitlab的免费版本没有削减开发团队须要的核心功能。每一个付费层均提供附加功能，这些附加功能可带来最大价值，具体取决于组织的规模和需求。

2020年排名第一的配置管理工具：Ansible

Ansible是这个领域的领导者，缘由很简单：无国籍。较早的现场配置管理工具着重于管理配置状态。若是它与所需的配置脱离同步，它将自行修复。在新的应用程序中，咱们只有无状态组件。新版本的代码是新的构件，并已部署以替换现有的构件。咱们拥有短暂的短暂环境。

主要优点：

无状态 - Ansible剧本是从操做员机器上运行的，并命中服务器目标。我不在意远程对象的状态，这使得使用Packer之类的工具来构建可部署对象变得更加容易。
开源 - 和CentOS同样，Ansible也由RedHat维护。该企业及其高级支持人员能够帮助维护社区，并确保高质量，易于使用的模块。
分子测试 — 由于配置管理和其余任何东西同样都是代码，因此若是不对其进行测试，咱们将无所不能。用于测试Ansible角色的分子框架能够无缝地工做，以确保咱们的按代码配置质量同样高，并遵循与应用程序代码相同的CI / CD管道。
YAML — 与其余工具相比，YAML更加容易使您头脑清醒。因为配置管理对于采用DevOps的任何人来讲一般都是新事物，所以这使其成为关键卖点。

竞争对手：

OpsCode Chef - 我以厨师食谱开发人员的身份开始了DevOps生涯。露比和厨师很亲密，个人心。可是，它们根本没法解决当今无状态，云原生应用程序的问题。对于更传统的遗留应用程序来讲，这是一个很好的工具，可是本文将重点放在将来。
Puppet — Puppet从未成长为一个庞大的社区，特别是与Chef and Ansible相比。它很是适合配置和裸机，但不支持Web应用程序类型的配置管理。

2020年排名第一的部署工具：Terraform

Terraform解决了从网络组件到实际服务器映像定义基础架构即代码的问题。自最初发布以来，它已经走了很长一段路，并创建了庞大的插件社区和支持社区，以帮助您解决可能遇到的几乎全部部署场景。支持本地，云中或其余任何类型的环境的能力是数一数二的。最后，最新版本在HCL中提供了许多与其余任何传统编程语言相同的逻辑功能和类，从而使开发人员能够轻松学习和学习。

主要优点：

不受云/环境影响 - Terraform利用提供的资源做为Terraform代码与与基础架构提供商进行通讯所需的全部API和后端逻辑之间的接口。这意味着我能够学习一种工具，而且可以在任何地方工做。

开源 — 一样，很难敲响免费工具。社区支持是一流的。

竞争对手：

AWS CloudFormation — 即便您仅在AWS云环境中工做，您也可能会在职业生涯中继续前进，而不是去那里。将您的技能和知识整合到一个平台中可能会有风险。此外，许多新的AWS服务一般在CloudFormation中可用以前做为Terraform模块提供。

运行时DevOps工具

任何开发项目的最终目标都是在生产中运行咱们的应用程序。在DevOps世界中，咱们但愿确保咱们对环境中的任何潜在问题具备可见性，而且还但愿将人工干预降至最低。选择正确的运行时工具集对于实现开发必不可少的条件相当重要。

运行时工具子类别为：

X 即服务
编排
监控方式
日志记录

2020年排名第一的X-as-a-Service工具：Amazon Web Services

亚马逊一直是云计算领域的领导者。他们也不只止步于此-他们为开发人员提供了许多新服务，以利用它可使您旋转。将任何技术和任何模式带到AWS上，就能够构建和运行它。与在本身的数据中心中构建，管理和维护传统硬件相比，它们的成本极其合理。免费服务层使任何人都有机会在必须作出购买决定以前进行尝试，这对于尝试以正确的方式构建应用程序而没必要因成本而形成损害很是有用。

主要好处：

行业标准 - 若是您有在AWS中构建应用程序的经验，那么您基本上能够在任何地方找到工做。企业喜欢AWS，而创业公司喜欢AWS的低成本。
Free-Tier — 与其余全部功能相比，AWS的业务确实如此。让我使用该服务并查看其工做原理，而后再决定将数千美圆投入可能有巨大陷阱的事物中。我从未为POC构建的任何产品都超过免费套餐限制。

竞争对手：

Azure – 自最初发布以来，Azure已经走了很长一段路，值得称赞。可是，区分自身的需求已致使其对服务的名称进行了怪异的命名，而这些服务要难一点了-到底什么是“ blob存储”？尽管.NET代码在Microsoft生态系统中效果更好，但不太可能仅将.NET用于应用程序的各个方面。
Heroku — 简而言之，除了在Heroku上的我的项目外，我什么都不会运行。透明度不高，企业没有理由将其用做平台。这对于在博客中演示某些内容很是有用，但对于实际应用程序来讲，很是感谢！

2020年排名第一的编排工具：OpenShift

您可能在应用程序堆栈中的某处使用了Docker或容器。无服务器应用程序很棒，但它们不能适合全部的架构模式。在没有业务流程平台的状况下运行容器根本行不通。从安全性和工具角度来看，Core Kubernetes带来了不少需求。OpenShift是惟一拥有Kubernetes平台的平台，它具备Source2Image构建，pod中的部署自动化以及甚至可追溯性和监视功能。它能够在本地，云中或同时在二者中运行。

主要优点：

内置的安全性 - 管理K8安全性几乎须要博士学位。必须仔细考虑并考虑全部细节。默认状况下，OpenShift所采用的安全机制减小了开发人员的工做量，并为他们的应用程序提供了更安全的平台。
多合一解决方案 – 与默认不包含负载平衡工具的香草K8不一样，OpenShift拥有一切。我可使用它来托管个人容器，构建容器，运行CI / CD工具，协调外部流程，管理机密等等。尽管GUI仍然须要作更多的工做，但API优先的方法意味着一切均可以编写脚本，而且与K8的其余GUI不一样，它使学习Kubernetes的基础知识变得更加简单，而无需首先得到该学位！

竞争对手：

Docker Swarm - Docker swarm尝试经过删除大量内容来简化K8。这对于较小的应用程序很是有用，但对于企业应用程序则根本不起做用。此外，AWS ECS之类的服务采用了相似的方法，可是使我可能正在与之交互的其余服务（Lambda，IAM等）的使用变得更容易。

2020年排名第一的监控工具：New Relic

New Relic的早期发行版确实作得很是好-APM监视。如今，它是一套完整的监视工具，使我能够监视服务器性能，容器性能，数据库性能，最终用户体验监视，固然还有APM监视。

主要优点：

易用性 - 我在担任系统工程师时曾使用过许多监视工具，但从未遇到过像New Relic这样易于使用的监视工具。这是一个SaaS，所以没必要设置服务器组件也很不错。
端到端可见性 - 其余工具尝试监视应用程序的一个特定方面。不管是CPU利用率仍是网络流量，全部这些层均可以协同工做，以使您的应用正常运行。New Relic使您可以组合全部数据以真实了解正在发生的事情。

竞争对手：

Zabbix — Zabbix是我最喜欢的监视系统，可是因为缺少向云原生环境和APM空间发展的能力，所以使其滞后。它仍然能够很好地监视传统的服务器基础结构，仅此而已。
DataDog - 此工具过于侧重于管理生产应用程序的过程视角，而对代码自己的关注不足。在真正的DevOps团队中，有开发人员参与生产，咱们无需依靠繁琐的工具来提供世界一流的支持。

2020年排名第一的测井工具：Splunk

很难反对Splunk。他们好久以来一直是日志聚合的领导者，而且他们继续作得最好。借助本地和SaaS产品，您能够在任何地方使用它。主要的缺点是，它仍然很难运行！

主要优点：

行业标准 —企业喜欢Splunk，他们也有钱为此付出代价。虽然初创企业可能难以证实其成本合理，但许多概念和技能能够转移到开源替代方案中。
可支持性 -简单地说，它能够正常工做。它具备许多默认值和即用型功能，所以您没必要花费大量时间阅读文档并尝试使一些没有明确说明的内容可以正常工做。

竞争对手：

ELK Stack - ElasticSearch，LogStash和Kibana，虽然彷佛老是很酷，由于它们不向您收取使用费用，但随着日志集的增加和机上愈来愈多的应用程序的维护，它的确变得更加困难您的工具。与使用Splunk相比，我在构建任何类型的仪表板以前花了更多的时间来设置工具。

协做DevOps工具

DevOps首先是组织内部的文化变革。虽然购买工具不会一晚上之间改变文化，但无疑能够帮助培养与同事合做的新方法。

协做工具子类别为：

问题跟踪
聊天操做
文献资料

2020年排名第一的问题跟踪工具：Jira

吉拉（Jira）继续保持头把交椅，尽管在这个领域竞争日益激烈。可是，Jira内置的强大灵活性使开发团队和运营团队能够管理其项目工做和冲刺任务。使用敏捷术语的内置标准有助于缓解从传统工做方法到更精益流程的文化转变。

主要优点:

行业标准 — 一样，就像许多工具同样，Jira处处都有使用。小型团队可使用便宜的许可证并得到所需的一切，而企业能够为任何人负担得起许可证。
集成 - 在这个领域处于领先地位而且快速增加意味着第三方工具会选择您首先构建本机集成，而它们只会增长您工具的价值，而Jira就是这种状况。咱们能够与现成的列表中的全部其余工具集成，而无需进行任何定制。

竞争对手:

Trello — Trello成为无偿使用的看板工具，所以迅速流行。可是，一旦事情开始扩展，而且您从数十个问题扩展到数千个问题，Trello将变得难以导航，搜索和报告。
Pivotal Tracker - 在初创公司工做期间，我很是喜欢该工具。可是，他们更多地关注产品管理，而不是技术任务。尽管从Jira进行产品管理比较困难，可是仍然能够完成此过程，而没必要获取彻底独立的工具。

2020年排名第一的ChatOps工具：MatterMost

说明：这多是2020年这份清单上最大的惊喜，这是一件好事！MatterMost经过使用之前最好的工具，但引入了本地部署而得到了普及。对于企业来讲，这是巨大的，由于它能够控制数据，还能够帮助与本地工具集成-咱们再也不须要为了新的事物而走出防火墙。

主要优点:

开源 - MatterMost的开源版本很是适合小型或大型团队。与Slack的免费层会丢失历史记录不一样，您本身运行服务器意味着您拥有数据。
集成 - 由于API几乎100％基于Slack API，因此几乎全部Slacks集成均可以直接与MatterMost一块儿使用。

竞争对手:

Slack - 松弛很棒，可是它们已经变得如此庞大，须要开始获利。他们业务的付费阶段即将到来，而且剥夺了Slack用来免费提供的许多价值，最关键的是聊天记录。
Microsoft Teams - 尝试将Microsoft产品与非Microsoft本地产品集成-祝您好运。这就是我要说的！

2020年排名第一的文档工具：Confluence

不管使用哪一种工具，都很难建立和维护高质量的技术文档。尽管最近有许多SaaS文档工具进入市场，但我很难接受将有关关键应用程序的敏感技术文档存储给第三方。我须要将数据和文档保留在本地，这就是Confluence为我所作的。

主要优点：

易于管理 - 大多数自托管工具的启动和运行可能有些复杂，而且大规模维护它们须要一些特定知识。开箱即用的Confluence服务器很是适合10个用户或10,000个用户。
插件－尽管建立具备默认融合功能的漂亮且易于浏览的文档已经很不错了，可是拥有用于几乎全部内容的插件的能力释放了Wiki的潜力。

竞争对手：

Read the docs — 很是适合开源公共代码，但永远不会考虑在这里存储关键的应用程序知识。
MarkDown — 尽管很是适合于记录有关个人代码的内容，但很难将体系结构，过程或其余类型的文档直接放入MarkDown格式中。
Jekyll — 在记录技术知识时，我并不想简单地构建一个新的静态站点，以便在每次更改时进行部署。简单的Confluence版本管理系统使内部文档的处理变得更加容易。

总结 2020 年最佳

市场上实际上有数百种DevOps工具。试图浏览应使用哪些以及什么时候实施它们可能会使人不知所措。遵循此简单指南，为完整的CI / CD管道选择DevOps工具堆栈。

将工具分为如下五个关键领域：

开发和构建工具
自动化测试工具
部署工具
运行时工具
协做工具

最后但愿你们切记：自动化全部能自动化的事情！

部分参考连接：
1. 《Must Learn DevOps Tools for 2020》
2. 《How to create a DevOps roadmap & Treebo’s 9 month DevOps Journey》
3. 《DevOps with AWS》
4. 《 Using this Time to Optimize Your Dev Team’s Workflow》