「云头条」人见人爱的九大开源DevOps工具

虽然我们一直在打造自己的SaaS公司，但一直也在花费大量的时间来研究和决定哪些工具应添加到DevOps工具箱当中。我们依托IT行业的多年经验来做出这些决定，主要处理基础设施。通过构建PB级的数据分析基础设施，我们的架构、工具和流程已成为技术和运营的重要组成部分。我们不遗余力地选择、横向比较以及不断改进我们选择的工具。

作为一家在开源堆栈（ELK）基础上构建解决方案的公司，我们的团队积极参与开源社区，为Camel和Kafka等多个项目做贡献，同时定制工具以满足自己的需要。我们内部使用的工具绝大多数是开源工具。通过分享我们不断收集并磨练的一些工具，我们希望有助于DevOps社区内部讨论可以做出什么进一步的改进。

你可能多年前就已经听说了下面介绍的一些工具，另一些工具可能很新颖。当然，我们欢迎任何反馈，尤其是来自使用替代工具的人士的反馈。

必不可少的DevOps工具

Nagios（和Icinga）

我们还调查了Icinga，它最初是作为Nagios的一个分支而开发的。其开发者旨在添加新的功能和现代用户体验，让Nagois可以更上一层楼。开源社区内部对于Nagios及其分支的优点确实有争论，不过现在我们在继续使用Nagios，对其规模和性能颇为满意。将来，随着我们不断发展，改用像Icinga这些更新颖的技术可能很合适。

基础设施监控是拥有众多解决方案的领域……从Zabbix到Nagios，以及另外几十个开源工具。尽管现在这个领域有新玩家，但Nagios却是一款历史悠久的监控解决方案，由于拥有庞大的社区，众多贡献者在为这款工具开发插件，它非常高效。Nagios并不包括自动发现新的实例和服务方面我们想要的所有功能，于是我们不得不使用社区的插件，解决这些问题。幸好，这并不是太困难，Nagios效果很不赖。

Monit

有时候，最简单的工具也是最有用的，简单的监控工具 Monit就证明了这点。其作用是确保机器上的任何特定进程在正常运行。比如说，Apache出现故障后，Monit就会有助于重新启动Apache进程。安装和配置起来非常容易，尤其适用于拥有数百个微服务的多服务架构。如果你在使用Monit，务必要监控它执行的重启活动，以便发现问题，实施解决方案（而不是仅仅重启、忽略故障）。想做到这一点，只要监控Monit的日志文件，并确保每次重启都提醒你。

ELK：Elasticsearch、Logstash和Kibana（通过Logz.io）

ELK堆栈是现代IT环境中最常见的日志分析解决方案。它收集来自某个环境中的所有服务、应用程序、网络、工具、服务器及更多系统的日志后，放入到一个集中式位置，以便处理和分析。我们用它来分析目的（比如说排查问题、监控服务，缩短解决运营问题所花的时间）。这个工具的另一个用途是，用于安全和审计（比如监控安全组方面的变化和权限方面的变化）。收到这些问题方面的提醒后，很容易对未授权的用户和活动采取相应措施。我们还使用ELK用于商业智能，比如监控我们的用户及其行为。你可以架设自己的ELK，也可以将它作为一种服务来购买。我们为社区写了一篇指南（http://logz.io/blog/elk-monitor-platform-performance/?utm_source=devops.com&utm_medium=referral&utm_content=9_open_source_devops_tools&utm_campaign=contributed_article），介绍如何使用ELK来监控应用程序的性能。

免责声明：Logz.io是我们在自己的环境中使用的ELK即服务。你可以说，我们在吃自己的狗粮。

Consul.io

Consul很适合用于使用微服务构建的现代弹性应用程序当中的服务发现和配置。这款开源工具充分利用了为服务提供内部DNS名称的最新技术。它充当一种代理，可帮助登记和注册名称，让你能够访问服务名称，而不是特定的机器。比如说，如果你有一个多个机器组成的集群，只要将它们注册为Consul下面的单一实体，然后可以轻松访问该集群。这款工具的效率值得点赞，不过我们仍觉得它还有更多的工作要做。如果你也使用它，欢迎介绍你自己的使用场合。

Jenkins

Jenkins人人皆知，是不是？它不是最快速或最花哨的，但是确实很容易开始使用，它还有一个出色的生态系统，拥有丰富的插件和附件。它还经过了优化，以便轻松定制。我们配置了Jenkins，以便构建代码，创建Docker容器（参见下一个工具），运行大量测试，并推送到试运行/生产环境。这是一款出色的工具，不过扩展和性能方面也有一些问题（这其实很常见）。我们探究了其他很酷的解决方案，比如Travis和CircleCI，两者都是托管解决方案，不需要我们任何维护。不过眼下，既然我们已致力于Jenkins，会继续使用它。

Docker

我们已经说过Docker在彻底改变IT环境。它甚至改变了IT人士的生活，不过我们仍遇到Docker方面的一些挑战。我们在生产环境中使用Docker，用于大多数服务。它让容器可以从一个地方转移到另一个地方，从而简化了配置管理、控制问题和扩展。

我们使用一道包括12层的数据处理流水线，开发了SaaS解决方案。结合Jenkins和Docker，我们得以在单单一台Mac上就能运行涉及所有层的整条流水线。Docker没有任何复杂性可言，这是错误的说法，因为连小小的容器也要大量的时间来构建。然而，我们希望确保，我们的开发人员尽可能满意，让他们能够迅速工具。由于牵涉存储、安全和网络方面的所有管理，加上围绕容器的一切，这可能是一大挑战。

我们看到Docker在不断发展，期望这家公司推出新的管理和编排解决方案。有些读者在使用Docker方面可能有问题，我们还整理出了一份列表，列出了迁移到Docker时遇到的挑战和解决办法（http://logz.io/blog/migrating-to-docker/?utm_source=devops.com&utm_medium=referral&utm_content=9_open_source_devops_tools&utm_campaign=contributed_article）。

Ansible

再说一下，简单是关键。Ansible是一款类似Puppet和Chef的配置管理工具。就个人而言，我们发觉这两款工具开销更大，就我们的使用场合而言很复杂，于是我们决定改而使用Ansible。我们知道，Puppet和Chef可能拥有更丰富的功能特性，但是简单是我们在这里需要的关键绩效指标（KPI）。我们看到使用Ansible的配置管理与使用Docker容器，终止或启动新的应用程序实例这个选项各有一些利弊。如果使用Docker，我们几乎从来没有升级过机器，而是选择启用新的机器，这减少了升级EC2云实例的需要。Ansible主要用于部署配置。我们将它用来推送变更、重新配置刚部署的机器。此外，其生态系统很出色，拥有编写自定义应用程序这个轻松的选项。

Collectd / Collectl

Collectd/Collectl是两款小巧的工具，运行在某个系统上，用来收集并存储关于该系统的统计数据，它们比其他工具要灵活得多。它们让用户可以测量多个系统度量指标的值；不像其他日志收集工具旨在测量特定的系统参数，Collectd/Collectl可以并行监控不同的参数。我们使用这两款工具来测量客户的性能参数，并将它们发送到我们的ELK即服务平台。我们专门用Docker容器包装了一个Collectl代理，然后用Ansible将它发送到我们的所有服务器。它每隔几秒钟就会收集信息，然后发送到ELK，让我们得以运行报告、发送提醒。如果你想看看一个具体的例子，表明我们在自己的环境中如何做这一点、别人如何也能做到，我们已为大家编写了一篇指南（http://logz.io/blog/elk-monitor-platform-performance/?utm_source=devops.com&utm_medium=referral&utm_content=9_open_source_devops_tools&utm_campaign=contributed_article）。

Git（GitHub）

Git是10年前开发的，起因是Linux社区需要可支持分布式系统的SCM（源代码控制管理）软件。Git可能是如今市面上最常见的源代码管理工具。在内部运行了Git一小段时间后，我们认识到使用GitHub更合适。除了其出色的分支和合并请求功能外，GitHub还有可与Jenkins结合起来的插件，便于集成和部署。我认为，向现代IT团队提到Git不是什么突发新闻，不过由于它对我们来说大有价值，我还是决定将它添加到本文中。

还有其他的选择吗？

现代DevOps领域向来不乏出色而独特的开源工具，它就好比是片热带丛林。我们发现本文介绍的这些工具是同类中最佳的，认为它们应该添加到每个DevOps工程师的最终名单。

是不是我选错了？你的工具箱里又有哪些开源DevOps工具？欢迎留言交流。

云头条编译｜未经授权谢绝转载

相关阅读：

欢迎加入交流，群主微信：aclood