Agent是一種常見的IaaS軟件管理設備的方式;例如,ZStack使用Python agents去管理KVM主機。由於海量的設備,安裝和升級agents成爲巨大的挑戰,因此大多數IaaS軟件把這個問題留給客戶或分發商,從而致使解決方案變得脆弱,由於缺少IaaS軟件自己的支持。ZStack從一開始就在考慮這個問題,前後嘗試了Puppet、Salt和Ansible,最後實現與Ansible無縫並對用戶透明的集成。全部的ZStack agents經過Ansible自動部署、配置、升級;用戶可能根本沒有注意到他們的存在。java
動機python
IaaS軟件一般是一個包含不少小程序的組合軟件。理想狀況下,IaaS軟件能夠被寫成一箇中央管理軟件,能夠經過設備的SDK和設備對話;但在現實中,設備要麼沒有提供SDK,要麼提供的SDK不完整,迫使IaaS軟件必須部署一個叫agent的小程序去控制它們。雖然ZStack把全部服務打包在一個單一的進程中(詳見「進程內的Microservices架構」),部分agent依舊須要部署到不一樣的設備上以控制它們。部署agent的過程當中,不只須要安裝agent和相關依賴的軟件,還須要配置目標設備,這並不簡單,並且一般須要用戶作大量的手動工做。當IaaS軟件管理着大量的設備的時候,這個問題變得很是顯著,甚至會限制數據中心規模。web
問題shell
部署、升級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代碼中處理業務邏輯了。app
全部的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=newAnsibleRunner();
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
publicvoidsuccess(){
trigger.next();
}
@Override
publicvoidfail(ErrorCodeerrorCode){
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自身來處理。