IaaS软件通常是一个包含很多小程序的组合软件。理想情况下，IaaS软件可以被写成一个中央管理软件，可以通过设备的SDK和设备对话；但在现实中，设备要么没有提供SDK，要么提供的SDK不完整，迫使IaaS软件必须部署一个叫agent的小程序去控制它们。部署agent的过程中，不仅需要安装agent和相关依赖的软件，还需要配置目标设备，这并不简单，而且通常需要用户做大量的手动工作。当IaaS软件管理着大量的设备的时候，这个问题变得非常显著，甚至会限制数据中心规模。部署、升级agent以及配置目标设备的问题都属于配置管理问题，Puppet、Chef、Salt和Ansible这类软件就是旨在解决这类问题。许多开发人员已经开始使用这些工具软件将IaaS软件包装成一个易于部署的方式。我们可以通过表3-1看一下这些工具的区别。
表3-1 各自动化部署工具对比
简单说明一下上面表格对比的内容。
□高可靠性
表格里列举的工具都提供了高可靠的机制，意味着可以有多个服务端提供服务，如果主节点出问题下线，其他节点仍然可以接管工作，例如：
●Chef：Chef提供了主备模式。主节点一旦出问题下线，Chef的备节点将会接管主节点的工作
●Puppet：Puppet提供了多主节点的架构。如果一个主节点出问题下线了，其他主节点将会接管失效主节点上的工作。
●Ansible：Ansible运行的时候只有一个节点，如果主节点出问题下线了，需要启动另外一个节点去接管原先工作节点的所有工作。
●Saltstack：Saltstack可以提供多主节点的配置。如果一个主节点下线了，agent将会按照配置列表里主节点的顺序连接其他主节点。
□安装配置便利性
可以毫不掩饰地说，Ansible是安装配置最便利的工具，我们可以通过下面的对比来看一下：
●Chef：Chef的架构是master-agent模式。Chef的服务端跑在master机器上，客户端作为agent跑在每一个client机器上。并且，Chef提供了一个额外的组件叫workstation，这个组件包含了所有的配置，这些配置将会被推送到chef的各个节点。因此，Chef的安装配置需要用户了解较多的概念，并且需要一定的配置。
●Puppet：Puppet在架构上和Chef一样，也是采用了master-agent模式。Puppet的服务端跑在master机器上，客户端作为agent跑在每一个client机器上。并且，agent和master之间需要做认证。因此，在初始化的时候不是非常便利。
●Ansible：Ansible只有一个master进程跑在服务端机器上，没有任何agent跑在客户端机器上。Ansible使用ssh去login客户端的系统，并生成一个临时的python文件，任务全部写在python文件里去执行，执行完之后删除python文件退出。因此，无需任何客户端的配置。可以让管理员非常快速的安装和配置。
●Saltstack：Saltstack也是master-agent模式。对Saltstack来说，服务端叫做salt master，客户端上的agent叫做saltminions。
□可管理性
在讲解可管理性之前，我们先了解一下pull模式和push模式，pull模式意味着slave节点将会主动从master节点拉取配置文件；而push模式意味着master节点主动推送配置文件到slave节点。Ansible和Saltstack使用的都是push模式，而puppet和chef使用的是pull模式。当然，Ansible也提供了一种机制可以实现pull模式，不在本章讨论范围。
那么，我们分别讨论一下这些工具的可管理性：
●Chef：因为Chef的配置文件遵循的是Ruby的DSL，因此，管理员在编辑配置文件时，需要有一定的Ruby基础。客户端将从服务端通过pull模式拉取配置。
●Puppet：Puppet使用了一种自定义的规范语言来撰写配置文件，因此，对初学者有一定的学习成本。Puppet的客户端也是通过pull模式从服务端拉取配置。并且，Puppet没有提供一种方式能够立刻执行配置，所以需要系统管理员对配置有一定的经验。
●Ansible：Ansible配置语法使用了标准的YAML语言，非常友好，并且ansible提供了非常完善的命令行方式供管理员立刻验证YAML配置的有效性。Ansible默认使用push方式执行最终生效的配置文件并推送到各个节点。
●Saltstack：Saltstack和Ansible一样，也使用YAML作为配置语法。和Ansible也非常类似，可以立刻验证配置的有效性，并且提供的是push方式执行服务端最终生效的配置文件到客户端。
□实现语言
Chef和Puppet基于Ruby语言，而Ansible和Saltstack基于Python语言。得益于Python社区的活跃度，使用Python做运维管理的管理员要远多于Ruby语言。用户在使用过程中，遇到的一些简单问题可以自己定位并排查。
□活跃度
虽然活跃度并无法证明工具软件本身是否好用。但是，活跃度高的项目，通常功能的完善度、迭代速度，以及在社区得到帮助、解决问题的效率也会高很多。可以看到，截止本书写稿时间，2019.5.14号，Ansible项目的活跃度远远高过其他几个项目。(www.xing528.com)
3.3.3.1 OpenStack自动化部署设计机制
OpenStack默认使用Puppet来实现自动化部署。
包括Redhat、Mirantis以及UnitedStack等，都使用Puppet作为自动化部署的工具，并在Puppet社区不断提交贡献。下图是Puppet的一个工作原理：
如图3-17所示，OpenStack默认的自动化部署机制就是原生的Puppet工作方式，通过在客户端部署agent，并和master节点进行认证。之后，在master节点上定义对应的manifest文件，运行puppet使所有的manifest文件定义的操作在客户端生效。由于OpenStack社区没有做太多自动化部署设计上的创新，本节不再赘述Puppet的工作方式。
图3-17 OpenStack使用Puppet自动化部署示意图
3.3.3.2 ZStack自动化部署设计机制
ZStack是通过Ansible来实现自动化部署。
首先，ZStack有一个典型的服务端-代理（server-agent）架构，服务器端包含所有驱动业务逻辑的编排服务，代理端执行来自于编排服务的命令，通过使用运行在不同的设备上的小的Python agent或者Go agent实现外部设备的管理。
图3-18 ZStack使用Ansible自动化部署示意图
服务和agents：ZStack对服务和agents有明确的定义。服务负责在云中完成一部分业务，例如存储服务。服务通常在ZStack管理节点运行的进程中，有自己的API和配置，与其他服务协同完成云上的业务。agent是一个被服务命令的小附属程序，可以通过使用它来操作没有提供像样SDK的外部设备；例如，Ceph主存储agent在一台安装了Ceph的Linux机器上和Ceph monitor节点通过RBD协议通信。服务和agent代理的设计原则是把所有复杂的业务逻辑放在服务中，使代理尽可能简单。
ZStack没有使用Ansible默认的YAML配置文件，而是直接调用Ansible的API实现agent部署过程中的精确控制。以下面这个封装的check＿nested＿kvm函数为例：
ZStack在添加物理机的时候，将会调用这个函数，去检查物理机的CPU是否支持嵌套虚拟化功能，如果不支持，意味着物理机无法启动虚拟机，将不会被添加到ZStack平台。这个过程中，ZStack调用了modprobe去注入kvm＿intel内核模块，这个函数最终的实现是通过封装Ansible API完成，如下所示。
在封装API的过程中，可以细粒度的输出日志，并且发送每一步操作的状态到管理节点。这个是使用YAML配置文件无法做到的，YAML配置文件在执行过程中，只能一次性打印出来所有的结果，并且无法细粒度的干涉每一步的工作。
通过封装Ansible API，实现自动化部署之后，用户不需要担心ZStack会要求你手动安装很多依赖软件，并且不会收到任何由于缺乏依赖或者错误配置引起的奇怪的错误。
在Java代码中的服务可以在某个恰当的时机，使用AnsibleRunner去调用Ansible去部署或升级agents。KVM的AnsibleRunner看起来像：
AnsibleRunner非常智能。它将跟踪每一个agent文件的MD5校验值，并在远程设备测试agent的端口连接性，保证Ansible只在需要的时候被调用。通常情况下，部署或升级的过程是对用户透明的，在服务定义的触发点被触发；例如，一个KVM agent将在添加一个新的KVM主机的时候自动被部署。然而，服务也提供叫做Reconnect的API，让用户用命令式的方式触发agent部署；例如，用户可以调用APIReconnectHostMsg让一个KVM agent重新部署，并完全还原物理机环境。重新部署的原因可能是为Linux操作系统修复一个关键的安全漏洞，或者是用户不小心破坏了他的物理机环境。
在软件升级过程中，用户在安装完一个新的ZStack版本并重启所有管理节点后，AnsibleRunner将检测到agents的MD5校验和发生了变化，并自动在外部设备升级agents。这个过程是对用户透明的且精心设计的；例如，主机服务如果它发现共有10 000台主机，将每次升级1 000台KVM主机，以避免管理节点的资源被耗尽；当然，我们也为用户提供了全局配置去优化这个行为（例如每次升级100台主机）。
综上所述，使用不同的自动化部署工具对用户的要求也不尽相同，在IaaS软件的安装部署升级过程中，笔者建议的最佳实践是屏蔽底层的细节，把复杂的配置和认证工作交给IaaS平台来处理，也就是说，通过API集成的方式细粒度的使用自动化部署工具，避免手动的修改配置文件。这样能够最高效率的完成平台的安装部署，并且能够通过定制化的方式，细粒度的展示安装部署的细节。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
