Docker世界中的配置管理

任何管理多台服务器的人都可以确认手动执行此任务是浪费时间和风险。 配置管理（CM）已有很长时间了，我没有一个唯一的原因可以想到为什么不使用其中一种工具。 问题不在于是否采用其中之一，而是要选择哪一个。 那些已经拥抱彼此并投入大量时间和金钱的人可能会争辩说，最好的工具就是他们选择的工具。 通常情况下，选择会随着时间而变化，而今天一个选择与另一个选择的理由可能会有所不同。 在大多数情况下，选择不是基于可用的选项，而是基于我们誓言要维护的遗留系统的体系结构。 如果要忽略这样的系统，或者有足够的勇气和财力的人愿意对其进行现代化，那么当今的现实将由容器和微服务主导。 在这种情况下，我们昨天做出的选择肯定不同于我们今天可以做出的选择。

发动机

CFEngine可被视为配置管理之父。 它创建于1993年，彻底改变了我们服务器设置和配置的方式。 它最初是一个开源项目，并在2008年发布第一个企业版时实现了商业化。

CFEngine用C编写，只有很少的依赖关系，并且闪电般快。 实际上，据我所知，没有其他工具能够克服CFEngine的速度。 那曾经是，现在仍然是它的主要优势。 但是，它有其缺点，可能是主要的编码技能要求。 在许多情况下，普通操作员无法使用CFEngine。 它需要C开发人员来管理它。 但这并没有阻止它在一些大型企业中被广泛采用。 但是，由于年轻人通常会随着年龄的增长而胜出，因此会创建新的工具，如今由于公司对其进行的投资，很少有人选择CFEngine而不被“强迫”这样做。

木偶

后来， 木偶应运而生。 它还开始于一个开源项目，随后是企业版。 与CFEngine相比，它具有模型驱动的方法和较小的学习曲线，因此被认为更“友好操作”。 最后，运维部门可以利用一种配置管理工具。 与CFEngine使用的C语言不同，Ruby被证明更易于推理，并为ops所接受。 CFEngine的学习曲线可能是Puppet进入配置管理市场并慢慢将CFEngine推向历史的主要原因。 这并不意味着不再使用CFEngine。 是的，而且似乎并不会很快消失，就像Cobol仍然存在于许多银行和其他金融相关业务中一样。 但是，它因选择武器而声名狼藉。

厨师

然后， 厨师许诺解决木偶的一些细微差别。 确实有一段时间了。 后来，随着Puppet和Chef的受欢迎程度不断提高，他们进入了“零和游戏”。 他们中的一个提出新的或某些改进后，另一个人就采纳了。 两者都具有越来越多的工具，这些工具往往会增加其学习曲线和复杂性。 Chef有点“对开发人员友好”，而Puppet则被认为更面向操作和sysadmin类型的任务。 两者之间都没有一个明显的优势，因此通常根据个人经验进行选择。 Puppet和Chef都已经成熟，被广泛采用（尤其是在企业环境中），并且具有大量的开源贡献。 唯一的问题是，对于我们要完成的任务而言，它们太复杂了。 他们俩都没有考虑到容器的设计。 他们都不知道Docker会改变“游戏”，因为在他们设计之时它并不存在。

到目前为止，我们提到的所有配置管理工具都在尝试解决采用容器和不可变部署时不应该出现的问题。 我们之前遇到的服务器混乱不再了。 现在，我们正在尝试处理大量容器以及数量非常有限的其他任何东西，而不是数百甚至数千个软件包，配置文件，用户，日志等。 这并不意味着我们不需要配置管理。 我们的确是！ 但是，选择工具应做的范围要小得多。 在大多数情况下，我们需要一个或两个用户才能启动并运行Docker服务，还有其他一些事情。 其余的都是容器。 部署正成为一组不同工具的主题，并重新定义了CM应该做什么的范围。 Docker Compose和Kubernetes只是我们今天可能使用的快速增长的部署工具中的少数几个。 在这种情况下，我们的配置管理选择应该比其他事情更重视简单性和不变性。 语法应该简单易懂，即使对于从未使用过该工具的人也是如此。 不变性可以通过强制执行不需要在目标服务器上安装任何东西的推送模型来实现。

Ansible

Ansible试图解决与其他配置管理工具相同的问题，但是方式却截然不同。 一个重要的区别是它通过SSH执行所有操作。 CFEngine和Puppet要求将客户端安装在应管理的所有服务器上。 尽管Chef声称不支持，但它对无代理运行的支持功能有限。 与不要求服务器有任何特殊要求的Ansible相比，这本身就是一个巨大的差异，因为SSH几乎始终存在。 它利用定义良好且使用广泛的协议来运行需要运行的任何命令，以确保目标服务器符合我们的规范。 唯一的要求是大多数Linux发行版中已经预安装了Python。 换句话说，与试图迫使您以某种方式设置服务器的竞争对手不同，Ansible利用了现有的现实，不需要任何东西。 由于其体系结构，您只需要在Linux或MacOS计算机上运行的单个实例即可。 例如，我们可以通过笔记本电脑管理所有服务器。 尽管不建议这样做，并且Ansible可能应在“真实”服务器上运行（最好是在安装了其他持续集成和部署工具的同一服务器上），但笔记本电脑示例说明了其简单性。 以我的经验，像Ansible这样的基于推的系统比我们之前讨论的基于拉的工具更容易推理。

与掌握其他工具所需的所有复杂性相比，Learn Ansible只需花费一小部分时间。 它的语法基于YAML（又一种标记语言），并且一眼就能看懂一本剧本，即使从未使用过该工具的人也可以理解发生了什么。 与由开发人员为开发人员编写的Chef，Puppet尤其是CFEngine不同，Ansible由开发人员编写，其对象是比其他语言和/或DSL学习能力更好的人。

有人指出，主要缺点是Ansible对Windows的有限支持。 客户端甚至无法在Windows上运行，并且可在剧本中使用并在其上运行的模块数量非常有限。 我认为，假设我们正在使用容器，这是一个不利条件。 Ansible开发人员没有浪费时间尝试创建一个全面的工具，而是专注于最有效的工具（Linux上通过SSH的命令）。 无论如何，Docker尚未准备好在Windows中运行容器。 可能是在将来，但是在此刻（或至少在我撰写本文时），这在路线图上，结果令人怀疑。 即使我们忽略容器及其在Windows上的可疑未来，其他工具在Windows上的性能也比Linux差很多。 简而言之，Windows体系结构对CM目标的友好程度不如Linux。

我可能已经走得很远了，在Windows上应该不要太苛刻，并质疑您的选择。 如果您确实喜欢Windows服务器而不是某些Linux发行版，那么我对Ansible的所有赞扬都是徒劳的。 您应该选择Chef或Puppet，并且除非已经使用，否则请忽略CFEngine。

个人选择

如果几年前有人问我应该使用哪种工具，我将很难回答。 今天，如果可以选择切换到容器（无论是Docker还是其他类型）和不可变的部署，那么选择就很明确了（至少在我提到的工具中）。 Ansible（与Docker和Docker部署工具结合使用）在一天中的任何时候都可以赢得胜利。 我们甚至可能会争论是否完全需要CM工具。 举个例子，人们完全依赖CoreOS，容器和诸如Docker Swarm或Kubernetes之类的部署工具。 我还没有如此激进的意见，但我认为CM仍然是军火库中的宝贵工具，但是。 由于CM工具需要执行的任务范围，Ansible正是我们需要的工具。 任何更复杂或更难学的东西都是过大的。 我尚未找到维护Ansible剧本有困难的人。 因此，配置管理很容易成为整个团队的责任。我并不是要说基础架构应该轻描淡写（绝对不应该这样）。 但是，在任何类型的任务中，都有整个团队参与项目的贡献是一个很大的优势，CM也不例外。 CFEngine，Chef和Puppet因其复杂的架构和陡峭的学习曲线而显得过高。 至少与Ansible相比。

我们简短介绍过的四个工具绝不是我们唯一可以选择的工具。 您可能会轻易争辩说，这些都不是最好的，然后投票赞成其他东西。 很公平。 这完全取决于我们要归档的首选项和目标。 但是，与其他人不同，Ansible几乎不会浪费时间。 很容易学习，即使您选择不采用它，也无法说浪费了很多宝贵的时间。 此外，我们学到的一切都会带来新的东西，并使我们成为更好的专业人员。

如果您想了解更多有关在Docker中使用Ansible的实际示例 ，请在此博客中搜索 。

翻译自: https://www.javacodegeeks.com/2015/08/configuration-management-in-the-docker-world.html