Agent是一种常见的IaaS软件管理设备的方式；例如，ZStack使用Python agents去管理KVM主机。因为海量的设备，安装和升级agents成为巨大的挑战，所以大多数IaaS软件把这个问题留给客户或分发商，从而导致解决方案变得脆弱，因为缺乏IaaS软件本身的支持。ZStack从一开始就在考虑这个问题，先后尝试了Puppet、Salt和Ansible，最后实现与Ansible无缝并对用户透明的集成。所有的ZStack agents通过Ansible自动部署、配置、升级；用户可能根本没有注意到他们的存在。
动机
IaaS软件通常是一个包含很多小程序的组合软件。理想情况下，IaaS软件可以被写成一个中央管理软件，可以通过设备的SDK和设备对话；但在现实中，设备要么没有提供SDK，要么提供的SDK不完整，迫使IaaS软件必须部署一个叫agent的小程序去控制它们。虽然ZStack把所有服务打包在一个单一的进程中（详见“进程内的Microservices架构”），部分agent依旧需要部署到不同的设备上以控制它们。部署agent的过程中，不仅需要安装agent和相关依赖的软件，还需要配置目标设备，这并不简单，而且通常需要用户做大量的手动工作。当IaaS软件管理着大量的设备的时候，这个问题变得非常显著，甚至会限制数据中心规模。
问题
部署、升级agent以及配置目标设备的问题都属于配置管理问题，Puppet、Chef、Salt和Ansible这类软件就是旨在解决这类问题。许多开发人员已经开始使用这些工具软件将IaaS软件包装成一个易于部署的方式；例如，为了安装OpenStack，你可能会试图找到一些puppet模块而不是依据它提供的文档手动完成每一步操作。这些第三方包装能在一定程度上缓解问题，但它们同时又是脆弱的，包装的软件发生任何变化都会破坏它们。另一方面，当用户想要配置软件包的某一部分的时候，他们可能不得不深入那些第三方包装去做一个即需的改变。最后，第三方包装无法处理封装的软件升级的状况，迫使用户重新面对他们试图隐藏的令人气馁的细节。
通过与配置管理软件Ansible无缝且透明的集成，ZStack解决了这个问题。使用的方式是对用户隐藏细节并承担了管理agent的责任，最终展示给用户一个可以简单下载和运行（或升级）的软件，完全满足在数据中心自动化完成一切的目标，并帮助管理员克服安装、配置和升级云的恐惧。
和Ansible集成
ZStack有一个典型的服务端-代理（server-agent）架构，服务器端包含所有驱动业务逻辑的编排服务，代理端执行来自于编排服务的命令，通过使用运行在不同的设备上的小的Python agents（如KVM agents、虚拟路由agents）。
服务和agents：ZStack对服务和agents有明确的定义。服务负责在云中完成一部分业务，例如存储服务。服务通常在ZStack管理节点运行的进程中，有自己的API和配置，与其他服务协同完成云上的业务。agent是一个被服务命令的小附属程序，可以通过使用它来操作没有提供像样SDK的外部设备；例如，SFTP备份存储agent在一台使用SFTP协议的Linux机器上创建了一个的备份存储。服务和代理的设计原则是把所有复杂的业务逻辑放在服务中，使代理尽可能简单。我们希望这个解释可以给你一个在ZStack中我们把什么称之为服务和代理的概念，因为其他IaaS软件可能有不同的想法，我们看到一些IaaS软件已经在agent代码中处理业务逻辑了。
所有的ZStack agents包含三个文件：一个Python包（xxx.tar.gz），一个init.d服务文件和一个Ansible YAML的配置文件。
在$web_container_root/webapps/zstack/WEB-INF/classes/ansible文件夹下它们自己目录中，所以一个服务可以通过java classpath找到它的agent。Ansible YAML配置将所有的东西放在一起；它讲述了如何安装agent，agent的依赖，以及如何配置目标设备。引用KVM为例，其Ansible YAML配置中的一部分看起来像这样：
像上面展示的这样，这个YAML配置会关心对一个KVM主机的所有设置。你不需要担心ZStack会要求你手动安装很多依赖软件，并且不会收到任何由于缺乏依赖或者错误配置引起的奇怪的错误。让一切运行在你的Linux机器上是ZStack的责任，不管你的Linux操作系统是Ubuntu还是CentOS，即使你只部署了一个最小的安装，ZStack也知道如何让它们准备就绪。
在java代码中的服务可以在某个恰当的时机，使用AnsibleRunner去调用Ansible去部署或升级agents。KVM的AnsibleRunner看起来像：
AnsibleRunner非常智能。它将跟踪每一个agent文件的MD5校验值，并在远程设备测试agent的端口连接性，保证Ansible只在需要的时候被调用。通常情况下，部署或升级的过程是对用户透明的，在服务定义的触发点被触发；例如，一个KVM agent将在添加一个新的KVM主机的时候自动被部署。然而，服务也提供叫做Reconnect API的API，让用户用命令式的方式触发agent部署；例如，用户可以调用APIReconnectHostMsg让一个KVM agent重新部署，重新部署的原因可能是为Linux操作系统修复一个关键的安全漏洞，在他们对KVM YAML配置做出了相应的改变之后。未来，ZStack将提供一个框架，允许用户执行他们定制的YAML配置而不用修改ZStack的默认配置。
在软件升级过程中，用户在安装完一个新的ZStack版本并重启所有管理节点后，AnsibleRunner将检测到agents的MD5校验和发生了变化，并自动在外部设备升级agents。这个过程是对用户透明的且精心设计的；例如，主机服务如果它发现共有10,000台主机，将每次升级1000台KVM主机，以避免管理节点的资源被耗尽；当然，我们也为用户提供了全局配置去优化这个行为（例如每次升级100台主机）。
总结
在这篇文章中，我们演示了ZStack与Ansible的无缝、透明的集成。通过这种方式，agent安装、配置和升级的过程是全自动的，让繁杂的细节远离用户，留给ZStack自身来处理。