ZStack--經過Ansible實現全自動化

 

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)架構

http://zstack.org/images/blogs/scalability/ansible1.png

服務和agentsZStack對服務和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自身來處理。

相關文章
相關標籤/搜索