Agent是一種常見的IaaS軟件管理設備的方式；例如，ZStack使用Python agents去管理KVM主機。因為海量的設備，安裝和升級agents成為巨大的挑戰(zhàn)，所以大多數(shù)IaaS軟件把這個問題留給客戶或分發(fā)商，從而導致解決方案變得脆弱，因為缺乏IaaS軟件本身的支持。ZStack從一開始就在考慮這個問題，先后嘗試了Puppet、Salt和Ansible，最后實現(xiàn)與Ansible無縫并對用戶透明的集成。所有的ZStack agents通過Ansible自動部署、配置、升級；用戶可能根本沒有注意到他們的存在。
動機
IaaS軟件通常是一個包含很多小程序的組合軟件。理想情況下，IaaS軟件可以被寫成一個中央管理軟件，可以通過設備的SDK和設備對話；但在現(xiàn)實中，設備要么沒有提供SDK，要么提供的SDK不完整，迫使IaaS軟件必須部署一個叫agent的小程序去控制它們。雖然ZStack把所有服務打包在一個單一的進程中（詳見“進程內的Microservices架構”），部分agent依舊需要部署到不同的設備上以控制它們。部署agent的過程中，不僅需要安裝agent和相關依賴的軟件，還需要配置目標設備，這并不簡單，而且通常需要用戶做大量的手動工作。當IaaS軟件管理著大量的設備的時候，這個問題變得非常顯著，甚至會限制數(shù)據(jù)中心規(guī)模。
問題
部署、升級agent以及配置目標設備的問題都屬于配置管理問題，Puppet、Chef、Salt和Ansible這類軟件就是旨在解決這類問題。許多開發(fā)人員已經開始使用這些工具軟件將IaaS軟件包裝成一個易于部署的方式；例如，為了安裝OpenStack，你可能會試圖找到一些puppet模塊而不是依據(jù)它提供的文檔手動完成每一步操作。這些第三方包裝能在一定程度上緩解問題，但它們同時又是脆弱的，包裝的軟件發(fā)生任何變化都會破壞它們。另一方面，當用戶想要配置軟件包的某一部分的時候，他們可能不得不深入那些第三方包裝去做一個即需的改變。最后，第三方包裝無法處理封裝的軟件升級的狀況，迫使用戶重新面對他們試圖隱藏的令人氣餒的細節(jié)。
通過與配置管理軟件Ansible無縫且透明的集成，ZStack解決了這個問題。使用的方式是對用戶隱藏細節(jié)并承擔了管理agent的責任，最終展示給用戶一個可以簡單下載和運行（或升級）的軟件，完全滿足在數(shù)據(jù)中心自動化完成一切的目標，并幫助管理員克服安裝、配置和升級云的恐懼。
和Ansible集成
ZStack有一個典型的服務端-代理（server-agent）架構，服務器端包含所有驅動業(yè)務邏輯的編排服務，代理端執(zhí)行來自于編排服務的命令，通過使用運行在不同的設備上的小的Python agents（如KVM agents、虛擬路由agents）。
服務和agents：ZStack對服務和agents有明確的定義。服務負責在云中完成一部分業(yè)務，例如存儲服務。服務通常在ZStack管理節(jié)點運行的進程中，有自己的API和配置，與其他服務協(xié)同完成云上的業(yè)務。agent是一個被服務命令的小附屬程序，可以通過使用它來操作沒有提供像樣SDK的外部設備；例如，SFTP備份存儲agent在一臺使用SFTP協(xié)議的Linux機器上創(chuàng)建了一個的備份存儲。服務和代理的設計原則是把所有復雜的業(yè)務邏輯放在服務中，使代理盡可能簡單。我們希望這個解釋可以給你一個在ZStack中我們把什么稱之為服務和代理的概念，因為其他IaaS軟件可能有不同的想法，我們看到一些IaaS軟件已經在agent代碼中處理業(yè)務邏輯了。
所有的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配置中的一部分看起來像這樣：
- 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操作系統(tǒng)是Ubuntu還是CentOS，即使你只部署了一個最小的安裝，ZStack也知道如何讓它們準備就緒。
在java代碼中的服務可以在某個恰當?shù)臅r機，使用AnsibleRunner去調用Ansible去部署或升級agents。KVM的AnsibleRunner看起來像：
AnsibleRunner runner = 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(new Completion(trigger) {
@Override
public void success() {
trigger.next();
}
@Override
public void fail(ErrorCode errorCode) {
trigger.fail(errorCode);
}
});
AnsibleRunner非常智能。它將跟蹤每一個agent文件的MD5校驗值，并在遠程設備測試agent的端口連接性，保證Ansible只在需要的時候被調用。通常情況下，部署或升級的過程是對用戶透明的，在服務定義的觸發(fā)點被觸發(fā)；例如，一個KVM agent將在添加一個新的KVM主機的時候自動被部署。然而，服務也提供叫做Reconnect API的API，讓用戶用命令式的方式觸發(fā)agent部署；例如，用戶可以調用APIReconnectHostMsg讓一個KVM agent重新部署，重新部署的原因可能是為Linux操作系統(tǒng)修復一個關鍵的安全漏洞，在他們對KVM YAML配置做出了相應的改變之后。未來，ZStack將提供一個框架，允許用戶執(zhí)行他們定制的YAML配置而不用修改ZStack的默認配置。
在軟件升級過程中，用戶在安裝完一個新的ZStack版本并重啟所有管理節(jié)點后，AnsibleRunner將檢測到agents的MD5校驗和發(fā)生了變化，并自動在外部設備升級agents。這個過程是對用戶透明的且精心設計的；例如，主機服務如果它發(fā)現(xiàn)共有10,000臺主機，將每次升級1000臺KVM主機，以避免管理節(jié)點的資源被耗盡；當然，我們也為用戶提供了全局配置去優(yōu)化這個行為（例如每次升級100臺主機）。
總結
在這篇文章中，我們演示了ZStack與Ansible的無縫、透明的集成。通過這種方式，agent安裝、配置和升級的過程是全自動的，讓繁雜的細節(jié)遠離用戶，留給ZStack自身來處理。
