Agent是一種常見的IaaS軟件管理設(shè)備的方式铜异;例如连舍,ZStack使用Python agents去管理KVM主機(jī)。因?yàn)楹A康脑O(shè)備泡仗,安裝和升級agents成為巨大的挑戰(zhàn),所以大多數(shù)IaaS軟件把這個問題留給客戶或分發(fā)商猜憎,從而導(dǎo)致解決方案變得脆弱娩怎,因?yàn)槿狈aaS軟件本身的支持。ZStack從一開始就在考慮這個問題胰柑,先后嘗試了Puppet截亦、Salt和Ansible,最后實(shí)現(xiàn)與Ansible無縫并對用戶透明的集成柬讨。所有的ZStack agents通過Ansible自動部署崩瓤、配置、升級踩官;用戶可能根本沒有注意到他們的存在却桶。
動機(jī)
IaaS軟件通常是一個包含很多小程序的組合軟件。理想情況下蔗牡,IaaS軟件可以被寫成一個中央管理軟件颖系,可以通過設(shè)備的SDK和設(shè)備對話;但在現(xiàn)實(shí)中辩越,設(shè)備要么沒有提供SDK嘁扼,要么提供的SDK不完整,迫使IaaS軟件必須部署一個叫agent的小程序去控制它們黔攒。雖然ZStack把所有服務(wù)打包在一個單一的進(jìn)程中(詳見“進(jìn)程內(nèi)的Microservices架構(gòu)”)趁啸,部分agent依舊需要部署到不同的設(shè)備上以控制它們。部署agent的過程中督惰,不僅需要安裝agent和相關(guān)依賴的軟件不傅,還需要配置目標(biāo)設(shè)備,這并不簡單姑丑,而且通常需要用戶做大量的手動工作蛤签。當(dāng)IaaS軟件管理著大量的設(shè)備的時(shí)候,這個問題變得非常顯著栅哀,甚至?xí)拗茢?shù)據(jù)中心規(guī)模震肮。
問題
部署、升級agent以及配置目標(biāo)設(shè)備的問題都屬于配置管理問題留拾,Puppet戳晌、Chef、Salt和Ansible這類軟件就是旨在解決這類問題痴柔。許多開發(fā)人員已經(jīng)開始使用這些工具軟件將IaaS軟件包裝成一個易于部署的方式沦偎;例如,為了安裝OpenStack,你可能會試圖找到一些puppet模塊而不是依據(jù)它提供的文檔手動完成每一步操作豪嚎。這些第三方包裝能在一定程度上緩解問題搔驼,但它們同時(shí)又是脆弱的,包裝的軟件發(fā)生任何變化都會破壞它們侈询。另一方面舌涨,當(dāng)用戶想要配置軟件包的某一部分的時(shí)候,他們可能不得不深入那些第三方包裝去做一個即需的改變扔字。最后囊嘉,第三方包裝無法處理封裝的軟件升級的狀況,迫使用戶重新面對他們試圖隱藏的令人氣餒的細(xì)節(jié)革为。
通過與配置管理軟件Ansible無縫且透明的集成扭粱,ZStack解決了這個問題。使用的方式是對用戶隱藏細(xì)節(jié)并承擔(dān)了管理agent的責(zé)任震檩,最終展示給用戶一個可以簡單下載和運(yùn)行(或升級)的軟件琢蛤,完全滿足在數(shù)據(jù)中心自動化完成一切的目標(biāo),并幫助管理員克服安裝抛虏、配置和升級云的恐懼虐块。
和Ansible集成
ZStack有一個典型的服務(wù)端-代理(server-agent)架構(gòu),服務(wù)器端包含所有驅(qū)動業(yè)務(wù)邏輯的編排服務(wù)嘉蕾,代理端執(zhí)行來自于編排服務(wù)的命令,通過使用運(yùn)行在不同的設(shè)備上的小的Python agents(如KVM agents霜旧、虛擬路由agents)错忱。
服務(wù)和agents:ZStack對服務(wù)和agents有明確的定義。服務(wù)負(fù)責(zé)在云中完成一部分業(yè)務(wù)挂据,例如存儲服務(wù)以清。服務(wù)通常在ZStack管理節(jié)點(diǎn)運(yùn)行的進(jìn)程中,有自己的API和配置崎逃,與其他服務(wù)協(xié)同完成云上的業(yè)務(wù)掷倔。agent是一個被服務(wù)命令的小附屬程序,可以通過使用它來操作沒有提供像樣SDK的外部設(shè)備个绍;例如勒葱,SFTP備份存儲agent在一臺使用SFTP協(xié)議的Linux機(jī)器上創(chuàng)建了一個的備份存儲。服務(wù)和代理的設(shè)計(jì)原則是把所有復(fù)雜的業(yè)務(wù)邏輯放在服務(wù)中巴柿,使代理盡可能簡單凛虽。我們希望這個解釋可以給你一個在ZStack中我們把什么稱之為服務(wù)和代理的概念,因?yàn)槠渌鸌aaS軟件可能有不同的想法广恢,我們看到一些IaaS軟件已經(jīng)在agent代碼中處理業(yè)務(wù)邏輯了凯旋。
所有的ZStack agents包含三個文件:一個Python包(xxx.tar.gz)和init.d服務(wù)文件,和一個Ansible YAML的配置,在$web_container_root/webapps/zstack/WEB-INF/classes/ansible文件夾下它們自己目錄中至非,所以一個服務(wù)可以通過java classpath找到它的agent钠署。Ansible YAML配置將所有的東西放在一起;它講述了如何安裝agent荒椭,agent的依賴谐鼎,以及如何配置目標(biāo)設(shè)備。引用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配置會關(guān)心對一個KVM主機(jī)的所有設(shè)置。你不需要擔(dān)心ZStack會要求你手動安裝很多依賴軟件信卡,并且不會收到任何由于缺乏依賴或者錯誤配置引起的奇怪的錯誤隔缀。讓一切運(yùn)行在你的Linux機(jī)器上是ZStack的責(zé)任,不管你的Linux操作系統(tǒng)是Ubuntu還是CentOS傍菇,即使你只部署了一個最小的安裝猾瘸,ZStack也知道如何讓它們準(zhǔn)備就緒。
在java代碼中的服務(wù)可以在某個恰當(dāng)?shù)臅r(shí)機(jī)丢习,使用AnsibleRunner去調(diào)用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校驗(yàn)值咐低,并在遠(yuǎn)程設(shè)備測試agent的端口連接性揽思,保證Ansible只在需要的時(shí)候被調(diào)用。通常情況下见擦,部署或升級的過程是對用戶透明的钉汗,在服務(wù)定義的觸發(fā)點(diǎn)被觸發(fā);例如鲤屡,一個KVM agent將在添加一個新的KVM主機(jī)的時(shí)候自動被部署损痰。然而,服務(wù)也提供叫做Reconnect API
的API酒来,讓用戶用命令式的方式觸發(fā)agent部署卢未;例如,用戶可以調(diào)用APIReconnectHostMsg
讓一個KVM agent重新部署堰汉,重新部署的原因可能是為Linux操作系統(tǒng)修復(fù)一個關(guān)鍵的安全漏洞辽社,在他們對KVM YAML配置做出了相應(yīng)的改變之后。未來翘鸭,ZStack將提供一個框架爹袁,允許用戶執(zhí)行他們定制的YAML配置而不用修改ZStack的默認(rèn)配置。
在軟件升級過程中矮固,用戶在安裝完一個新的ZStack版本并重啟所有管理節(jié)點(diǎn)后失息,AnsibleRunner
將檢測到agents的MD5校驗(yàn)和發(fā)生了變化譬淳,并自動在外部設(shè)備升級agents。這個過程是對用戶透明的且精心設(shè)計(jì)的盹兢;例如邻梆,主機(jī)服務(wù)如果它發(fā)現(xiàn)共有10,000臺主機(jī),將每次升級1000臺KVM主機(jī)绎秒,以避免管理節(jié)點(diǎn)的資源被耗盡浦妄;當(dāng)然,我們也為用戶提供了全局配置去優(yōu)化這個行為(例如每次升級100臺主機(jī))见芹。
總結(jié)
在這篇文章中剂娄,我們演示了ZStack與Ansible的無縫、透明的集成玄呛。通過這種方式阅懦,agent安裝、配置和升級的過程是全自動的徘铝,讓繁雜的細(xì)節(jié)遠(yuǎn)離用戶耳胎,留給ZStack自身來處理。