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

 

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=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自身來處理。