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代码中处理业务逻辑了。
所有的ZStackagents包含三个文件:一个Python包(xxx.tar.gz)和init.d服务文件,和一个AnsibleYAML的配置,在$web_container_root/webapps/zstack/WEB-INF/classes/ansible文件夹下它们自己目录中,所以一个服务可以通过javaclasspath找到它的agent。Ansible YAML配置将所有的东西放在一起;它讲述了如何安装agent,agent的依赖,以及如何配置目标设备。引用KVM为例,其Ansible YAML配置中的一部分看起来像这样:
- name: install kvm related packages on RedHat based OS
when: ansible_os_family == 'RedHat'
yum: name=""
with_items:
- qemu-kvm
- bridge-utils
- wget
- qemu-img
- libvirt-python
- libvirt
- nfs-utils
- vconfig
- libvirt-client
- net-tools
- name: install kvm related packages on Debian based OS
when: ansible_os_family == 'Debian'
apt: pkg=""
with_items:
- qemu-kvm
- bridge-utils
- wget
- qemu-utils
- python-libvirt
- libvirt-bin
- vlan
- nfs-common
- name: disable firewalld in RHEL7 and CentOS7
when: ansible_os_family == 'RedHat' and ansible_distribution_version >= '7'
service: name=firewalld state=stopped enabled=no
- name: copy iptables initial rules in RedHat
copy: src="/iptables" dest=/etc/sysconfig/iptables
when: ansible_os_family == "RedHat" and is_init == 'true'
- name: restart iptables
service: name=iptables state=restarted enabled=yes
when: chroot_env == 'false' and ansible_os_family == 'RedHat' and is_init == 'true'
- name: remove libvirt default bridge
shell: "(ifconfig virbr0 &> /dev/null && virsh net-destroy default > /dev/null && virsh net-undefine default > /dev/null) || true"
像上面展示的这样,这个YAML配置会关心对一个KVM主机的所有设置。你不需要担心ZStack会要求你手动安装很多依赖软件,并且不会收到任何由于缺乏依赖或者错误配置引起的奇怪的错误。让一切运行在你的Linux机器上是ZStack的责任,不管你的Linux操作系统是Ubuntu还是CentOS,即使你只部署了一个最小的安装,ZStack也知道如何让它们准备就绪。
在java代码中的服务可以在某个恰当的时机,使用AnsibleRunner
去调用Ansible去部署或升级agents。KVM的AnsibleRunner
看起来像:
AnsibleRunnerrunner
=
new
AnsibleRunner();
runner.installChecker(checker);
runner.setAgentPort(KVMGlobalProperty.AGENT_PORT);
runner.setTargetIp(getSelf().getManagementIp());
runner.setPlayBookName(KVMConstant.ANSIBLE_PLAYBOOK_NAME);
runner.setUsername(getSelf().getUsername());
runner.setPassword(getSelf().getPassword());
if(info.isNewAdded())
{
runner.putArgument("init",
"true");
runner.setFullDeploy(true);
}
runner.putArgument("pkg_kvmagent",
agentPackageName);
runner.putArgument("hostname",String.format("%s.zstack.org",self.getManagementIp().replaceAll("\\.",
"-")));
runner.run(newCompletion(trigger)
{
@Override
public
void
success()
{
trigger.next();
}
@Override
public
void
fail(ErrorCode
errorCode)
{
trigger.fail(errorCode);
}
});
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自身来处理。