第1章
Ansible基礎入門

“未來主體是傳統行業利用互聯網技術，以云端用人工智能的方式處理大數據”，在騰訊“云+未來”技術峰會上，馬化騰這樣形容未來。15年前，電腦還只是少數人的專屬，那時的網吧還很火，還沒人知道“網咖”是什么。而現在人手一部智能手機，物聯網更是讓日常生活中的普通家電也能在互聯網占據一席之地。這一切都推動著互聯網如火如荼發展，IT技術的發展更是日新月異，IT工種的分類日益精細專業化。

從早期All In One（所有應用部署在一臺服務器上）的簡單應用，到后期集群、高可用、緩存、消息隊列、配置中心、主從分離、負載均衡、大數據存儲等尖端技術的復雜應用，對運維的技術專業度和綜合技能要求越來越高，運維的交付標準不再以周或天為單位，而是以分鐘為單位。在現在是如此，在未來更是如此。運維不再如早期一樣，手動一臺臺地登錄服務器、部署應用配置環境、手動交付（諸如亞馬遜、Google等巨型企業早已實現自動擴縮容，配置應用自動化，流程自動交付等功能）。該方式耗時耗力，很難避免人為因素的錯誤，最主要的是這些重復手工勞動無法讓運維有更大的價值釋放，這一切都是不合理的，需要有更好的解決方式。

相信看到這里，大家都明白，我們需要一套自動化管理工具來幫助運維更高質量、更有效地完成手頭工作，以證明運維能創造的價值不止于此，況且生活不止眼前的茍且，還有詩和遠方，不是嗎？但當下SaltStack、Puppet、Fabric、Chef等自動化工具遍地開花，為什么還要推薦Ansible呢？讀完本章你會有些許想法，未來已來，只是尚未流行。

1.1 Ansible是什么

隨著移動互聯、物聯網、互聯網+、大數據、云計算等大規模應用的催生推動，以及人們日常生活的互聯網化，互聯網的蓬勃發展不僅沖擊影響著整個經濟體，更對人們的生活理念影響深遠。在體驗到互聯網帶來的便利和舒適的同時，人們也不再滿足于“可以用”，而是要“用得爽”，在政策、需求、利益、趨勢等原因的刺激下，互聯網的發展速度可想而知。眾所周知，智能的背后意味著復雜，這一現象在互聯網的發展中體現得淋漓盡致。在互聯網迅猛發展的同時，運維這個工種也從默默無聞的后臺逐步走向公眾視野，被更多的人所知曉。早期公司業務有數十臺、上百臺服務器已經是非常龐大的規模，每個運維同時操作10～20臺機器，忙碌地奔波于各電腦之間配置重啟服務，數十人摩肩接踵的場面是何等壯觀。只是每個人都在數十臺機器上做同樣的修改、配置、操作，如何保證每臺機器的操作都完全一樣呢？又如何保證其他所有人的操作都能準確無誤、沒有遺漏過失呢？更何況，隨著互聯網的迅猛發展，一個公司擁有幾十臺上百臺機器早已不是稀奇事，巨型公司數以萬計的機器都不在話下，再沿用老一套辦法一臺臺地人工修改配置已然不現實，這該怎么辦呢？相信此時你已然明白運維自動化具體是什么了。簡單來講，運維自動化就是將日常重復性的工作通過規則設定使其遵循預先既定規則，在指定的范圍時間內自動化運行，但整個過程無需人工參與。而Ansible正是幫助運維人員實現自動化的工具之一。

Ansible是近年越來越火的一款運維自動化工具，其主要功能是幫忙運維實現IT工作的自動化、降低人為操作失誤、提高業務自動化率、提升運維工作效率，常用于軟件部署自動化、配置自動化、管理自動化、系統化系統任務、持續集成、零宕機平滑升級等。它豐富的內置模塊（如acl、command、shell、cron、yum、copy、file、user等，多達569個）和開放的API接口，同時任何遵循GPL協議的企業或個人都可以隨意修改和發布自己的版本。

Ansible在其官網上定義如下：Ansible is a radically simple IT automation engine。即Ansible是一款極其簡單的IT自動化工具。這里特別使用了radically simple來形容Ansible的簡單程度，在0.X版本的Ansible官網中，更“過分”地使用Stupid Simple來形容Ansible是“令人發指的簡單”。在Ansible官網的通篇文檔中也不時使用Incredibly Simples、Keep It Simple、Power+Simplicity等字眼，可見Ansible這款自動化工具的設計非常注重Simple的理念。但Ansible的功能卻非常不簡單，完全沒有因為使用方式上的簡單而縮水，其自身內置模塊的數量達500多個，而且還在快速地增加新模塊，以下是這些模塊的覆蓋面的大致分類。

?系統層：支持的系統有Linux、Windows、AIX等，對應的模塊有acl、cron、pip、easy_install、yum、authorized_key等大量的內置模塊；

?知名第三方平臺支持：支持的云平臺有AWS、Azure、Cloudflare、Openstack、Google、Linode、Digital Ocean等，對應的模塊有ec2、azure_rm_deployment、cloudflare_dns、clc_aa_policy、glance_image、gc_storage、digital_ocean等；

?虛擬化：VMware、Docker、Cloudstack、LXC、Openstack等，對應的模塊有vmware_vmkernel、docker、cs_account、lxc_container、glance_image等；

?商業化硬件：F5、ASA、Citrix、Eos等，對應的模塊有bigip_facts、asa_acl、netscaler、eos_command等；

?系統應用層：Apache、Zabbix、Rabbitmq、SVN、GIT等，對應的模塊有apache2_module、zabbix_group、rabbitmq_binding、subversion、git等。

GitHub上有眾多開源愛好者為Ansible貢獻功能模塊，這些模塊完全可以滿足日常工作所需。官方對模塊也從使用者角度進行詳細分類，如Cloud Modules（云主機模塊）、Clustering Modules（集群模塊）、Commands Modules（命令模塊）、Database Modules（數據庫模塊）等。詳細的模塊分類可參考官方模塊列表：http://docs.ansible.com/ansible/modules_by_category.html，該網址內容的更新速度非常快，如果公司在使用Ansible，建議最少兩周關注一次。

Ansible名字其實是來源于其作者喜歡的一本書——奧森·斯科特·卡特的《安德的游戲》，該書中Ansible是一種能跨越時空的即時通信工具，使用Ansible可以在相距數光年的距離遠程實時控制前線的艦隊戰斗。Michael DeHaan希望借這個名詞比喻控制遠端大量的服務器，因此便將自己的這款產品命名為Ansible。

Web界面是一款功能完善的管理工具的必備功能，Tower是Ansible的Web化管理界面，但免費版的容量只有10臺主機，付費版則無容量限制。基于此原因，本書的第12～14章會介紹搭建屬于自己的Web化管理界面的方法，并代碼全開源，具體地址大家可從GitHub上下載，同時讀者遇到的問題都可以通過QQ群“Ansible中文權威”咨詢，或在微信公眾號“運維部落”留言。

更多信息請參考：

?Ansible官方地址：https://docs.ansible.com/；

?GitHub地址：https://github.com/ansible/ansible/blob/devel/docsite/rst/index.rst；

?Ansible中文權威地址：http://www.ansible.com.cn/。

1.2 Ansible發展史

Ansible的第一個版本是0.0.1，發布于2012年3月9日，其作者兼創始人是Michael DeHaan。Michael DeHaan曾經供職于Puppet Labs、RedHat、Michael，在配置管理和架構設計方面有豐富的經驗。其在RedHat任職期間主要開發了Cobble，經歷了各種系統簡化、自動化基礎架構操作的失敗和痛苦，在嘗試了Puppet、Chef、Cfengine、Capistrano、Fabric、Function、Plain SSH等各式工具后，決定自己打造一款能結合眾多工具優點的自動化工具， Ansible由此誕生。

其第一個版本號被非常謹慎地定義為0.01。到目前為止共發布107個版本，最新穩定版是Stable 2.1.1.0-1，最新Beat版Beat 2.1.1.0-0.1.rc1。值得一提的是，作為自動化工具新秀， Ansibe已被RedHat官方收購，在GitHub上被關注的勢頭也極為迅猛，Star和Fork數是當下紅極一時的SaltStack的2倍多。同類自動化工具GitHub關注程度如表1-1所示。從表可以看出Ansible的受歡迎度。被RedHat收購后，其未來發展潛力更是不可估量。

Ansible版本更新速度非常快，有時會一天推出多個Dev版本，7天推出一個穩定版本。所以使用Ansible的過程中也需多留意官網的更新。

1.3 為什么選擇Ansible

Ansible自2012年發布以來，沒多久便在美國開始流行。快速被IT人員接受的原因較大方面得益于Michael DeHaan在美國IT圈的名氣和影響力。隨后它逐步在各國流行。而筆者選擇Ansible的原因主要有如下幾個方面：

?Ansible完全基于Python開發，而DevOps在國內已然是一種趨勢，Python被逐步普及，運維人員自己開發工具的門檻逐步降低，得益于此，方便對Ansible二次開發；

?Ansible豐富的內置模塊，甚至還有專門為商業平臺開發的功能模塊，近600個模塊完全可以滿足日常功能所需；

?在Ansible去中心化概念下，一個簡單的復制操作即可完成管理配置中心的遷移；

?Agentless（無客戶端），客戶端無需任何配置，由管理端配置好后即可使用，這點非常誘人。在第10章會介紹如何部署配置Windows系統的主機端，用后會有深切的感受。

自Ansible發布后，也陸續被AWS、Google CloudPlatform、Microsoft Azure、Cisco、HP、VMware、Twitter等大公司接納并投入使用。關于筆者個人與Ansible的一些故事，有興趣的朋友可以參考本書前言。

1.4 Ansible是如何工作的

Ansible沒有客戶端，因此底層通信依賴于系統軟件，Linux系統下基于OpenSSH通信， Windows系統下基于PowerShell，管理端必須是Linux系統，使用者認證通過后在管理節點通過Ansible工具調用各應用模塊將指令推送至被管理端執行，并在執行完畢后自動刪除產生的臨時文件。Ansible具體的工作機制官方有專欄介紹https://www.ansible.com/how-ansible-works，但整體稍過簡略。我們參考從官網視頻中的截圖來詳細了解下其工作方式，如圖1-1所示。根據Ansible使用過程中的不同角色，我們將其分為：

?使用者

?Ansible工具集

?作用對象

（1）使用者

如圖1-1中Ansible工作機制所示，Ansible使用者來源于多種維度，圖中為我們展示了4種方式：

第一種方式：CMDB（Configuration Management Database，配置管理數據庫）, CMDB存儲和管理著企業IT架構中的各項配置信息，是構建ITIL項目的核心工具，運維人員可以組合CMDB和Ansible，通過CMDB直接下發指令調用Ansible工具集完成操作者所希望達成的目標；

第二種方式：PUBLIC/PRIVATE方式，Ansible除了豐富的內置模塊外，同時提供豐富的API語言接口，如PHP、Python、PERL等多種當下流行語言，基于PUBLIC（公有云）/PRIVATE（私有云）, Ansible以API調用的方式運行；

第三種方式：USERS直接使用Ad-Hoc臨時命令集調用Ansible工具集來完成任務執行， Ad-Hoc將在第3章有詳細介紹；

第四種方式：USERS預先編寫好的ANSIBLE PLAYBOOKS，通過執行Playbooks中預先編排好的任務集按序完成任務執行。

（2）Ansible工具集

ansible命令是Ansible的核心工具，ansible命令并非自身完成所有的功能集，其只是Ansible執行任務的調用入口，大家可心理解為“總指揮”，所有命令的執行通過其“調兵遣將”最終完成。ansible命令共有哪些兵將可供使喚呢？大家看中間綠色框中有INVENTORY（命令執行的目標對象配置文件）、API（供第三方程序調用的應用程序編程接口）、MODULES（豐富的內置模塊）、PLUGINS（內置和可自定義的插件）這些可供調遣。

（3）作用對象

Ansible的作用對象，不僅僅是Linux和非Linux操作系統的主機（HOSTS），同樣也可以作用于各類公有云/私有云，商業和非商業設備的網絡設施。

同樣，如果我們按Ansible工具集的組成來講，由圖1-1可以看出Ansible主要由6部分組成。

?ANSIBLE PLAYBOOKS：任務劇本（任務集），編排定義Ansible任務集的配置文件，由Ansible順序依次執行，通常是JSON格式的YML文件；

?INVENTORY:Ansible管理主機的清單；

?MODULES:Ansible執行命令的功能模塊，多數為內置的核心模塊，也可自定義；

?PLUGINS：模塊功能的補充，如連接類型插件、循環插件、變量插件、過濾插件等，該功能不常用。

?API：供第三方程序調用的應用程序編程接口；

?ANSIBLE：該部分圖中表示的不明顯，組合INVENTORY、API、MODULES、PLUGINS的綠框大家可以理解為是Ansible命令工具，其為核心執行工具；

Ansible執行任務，這些組件相互調用關系如圖1-2所示：

使用者使用Ansible或Ansible-playbook（會額外讀取Playbook文件）時，在服務器終端輸入Ansible的Ad-Hoc命令集或Playbook后，Ansible會遵循預先編排的規則將Playbooks逐條拆解為Play，再將Play組織成Ansible可識別的任務（Task），隨后調用任務涉及的所有模塊（Module）和插件（Plugin），根據Inventory中定義的主機列表通過SSH（Linux默認）將任務集以臨時文件或命令的形式傳輸到遠程客戶端執行并返回執行結果，如果是臨時文件則執行完畢后自動刪除。

1.5 Ansible通信發展史

Ansible主推的賣點是其無需任何Daemon維護進程即可實現相互間的通信，且通信方式是基于業內統一標準的安全可靠的SSH安全連接。同時因為SSH是每臺Linux主機系統必裝的軟件，所以Ansible無需在遠程主機端安裝任何額外進程，即可實現Agentless（無客戶端），進而助力其實現去中心化的思想。盡管穩定、快速、安全的SSH連接是Ansible通信能力的核心，但SSH的連接效率一直被詬病，所以Ansible的通信方式和效率在過去的數年中也在不停地改變和提高。基于以上認識，我們先來了解Ansible SSH的工作機制，再來回顧其發展史。

1．Ansible SSH工作機制

Ansible執行命令時，通過其底層傳輸連接模塊，將一個或數個文件，或者定義一個Play或Command命令傳輸到遠程服務器/tmp目錄的臨時文件，并在遠程執行這些Play/Comand命令，然后刪除這些臨時文件，同時回傳整體命令執行結果。這一系列操作在未來的Ansible版本中會越來越簡單、直接，同時快速、穩定、安全。通過了解其工作機制及其一直以來秉承的去中心化思想，我們可以總結，Ansible是非C/S架構，自身沒有Client端，其主要特點如下。

?無客戶端，只需安裝SSH、Python即可，其中Python建議版本為2.6.6以上。

?基于OpenSSH通信，底層基于SSH協議（Windows基于PowerShell）。

?支持密碼和SSH認證，因可通過系統賬戶密碼認證或公私鑰認證，所以整個過程簡單、方便、安全。建議使用公私鑰方式認證，因為密碼認證方式的密碼需明文寫配置文件，雖然配置文件可加密，但會增加Ansible使用的復雜度。

?支持Windows，但僅支持客戶端，服務端必須是Linux系統。

如Ansible官方介紹，如上特性是希望實現以下最終目標：

?Clear（簡易）:YAML語法，Python語言編寫，易于管理，API簡單明了；

?Fast（敏捷）：快速學習，設置簡單，無需任何第三方軟件；

?Complete（全面）：配置管理、應用部署、任務編排等功能集于一身，豐富的內置模塊滿足日常功能所需；

?Efficient（高效）：沒有額外軟件包消耗系統性能；

?Secure（安全）：沒有客戶端，底層基于OpenSSH，保證通信的安全可靠性。

2．Ansible通信方式發展歷程

Ansible底層基于安全可靠的SSH協議通信，但一直被人們詬病于其效率，通信功能作為Ansible最核心的功能之一，官方也一直在做改進。本節我們來了解Ansible通信發展史。

（1）Paramiko通信模塊

最初，Ansible只使用Paramiko 實現底層通信功能，但是Paramiko只是Python語法的一個第三方庫，發展速度遠不及OpenSSH 。同時，Paramiko的性能和安全性較OpenSSH稍遜一籌（在筆者眼里）。

在后續發布的新版本中，Ansible仍繼續兼容Paramiko，甚至在諸如RHEL 5/6等不支持ControlPersist（只在OpenSSH 5.6+版本中支持）的系統中封裝其為默認通信模塊。

（2）OpenSSH

從Ansible 1.3版本開始，Ansible默認使用OpenSSH連接實現各服務器間通信，以支持ControlPersist（持續管理）。Ansible從0.5版本起即支持OpenSSH功能，但直到1.3版本開始才將其設置為默認。

多數本地SSH配置參數，諸如Hosts、公私鑰文件等是默認支持的，但如果希望通過非默認的22端口運行命令等操作，則需要在Inventory文件中配置ansible_ssh_port的值。OpenSSH相比Paramiko更快、更可靠。

（3）加速模式

據官網介紹：開啟加速模式后Ansible通信速度有質的提升，是開啟ControlPersist后的SSH的2～6倍，是Paramiko通信速度的10倍。

盡管加速模式對Ad-Hoc命令不友好，但是Playbook通過加速模式會收到更高的性能。加速模式拋棄SSH多次連接的方式，通過SSH初始化后，帶著AES key的初始化連接信息通過特定的端口（默認5099，但可配置）執行命令傳輸文件。使用加速模式唯一需要的額外包是python-keyczar，如此一來，幾乎所有的常規模塊OpenSSH/Paramiko均工作在加速模式，但如下使用sudo的情況例外：

1）sudoers文件需要關閉其中的requiretty功能，注釋掉或者設置每個用戶的默認值為username ! requiretty。sudoers的man文檔說明如下。

    requiretty
    If set, sudo will only run when the user is logged in to a real tty.   When this
    flag is set, sudo can only be run from a login session and not via other means
    such as cron(8) or cgi-bin scripts.   This flag is off by default.

2）開啟加速模塊必須事先設置sudo文件NOPASSWD配置，禁用sudo后的PASSWORD交互認證過程。加速模式相對OpenSSH可以提供2～4倍的性能提升（尤其對于文件傳輸功能），在Playbook的應用中可以通過增加配置開關來實現。

    ---
    - hosts: all
    accelerate: true
    accelerate_port: 5099
    [...]

其中的端口也可以在ansible.cfg中單獨配置。

    [accelerate]
    accelerate_port = 5099

加速模式是現在已經被廢棄的Fireball模式的進化版，類似于Ansible加速通信方式，但需控制機事先安裝ZeroMQ服務（這與Ansible簡單、無依賴、無Daemon的理念是相違背的），并且一點也不支持sudo操作。

（4）Faster OpenSSH in Ansible 1.5+

Ansible 1.5+版本中的OpenSSH有了非常大的改進，舊版本中實現方式是復制文件至遠程服務器后運行，然后刪除這些臨時文件，而新版本的替代方案是通過OpenSSH發送執行命令，將所有操作附帶在SSH連接過程中同步實現。該方式只在Ansible 1.5+版本有效，且需在/etc/ansible/ansible.cfg的[ssh_connection]區域開啟pipelining=True功能。

關于加速模式我們還需要關注如下內容：

?pipelining=True需結合sudo的requiretty配置方可生效，請確保/etc/sudoers的Defaults requiretty為注釋狀態。絕大多數現有流行系統默認開啟該選項。

?在Mac OSX、Ubuntu、Windows的Cygwin或其他流行OS最好選擇5.6以上的OpenSSH版本，這些版本對ControlPersist有更友好的支持。

?如Ansible運行的主機系統是RHEL或CentOS，然而希望升級當前OpenSSH到最新版本以支持Faster/Persistent連接模式，可以通過yum update openssh升級最新版本。

本節內容可以通過如圖1-1所示的Ansible通信方式發展史魚骨圖來概括，從最開始的Paramiko，后來初步演變為OpenSSH，加速模式官方推薦Pipelining方式。

在了解Ansible通信原理及發展史后，我們進一步學習Ansible自身的發展史。要知道，在Chef、Puppet、SaltStack、Fabric等自動化工具群雄爭霸的市場背景下，Ansible依然能夠殺出重圍，在GitHub取得如此驚人成就，并且被紅帽官方收購，其發展史不得不讓人刮目相看。

1.6 Ansible應用場景

Ansible底層基于Python，以簡單著稱，配置文件格式也以INI和YAML為主，與其他管理工具相比，學習成本較低，學習曲線也很平滑，無論是基礎運維人員還是資深運維工程師都可以較快上手，稍加練習便可以熟練掌握。如果具備Dev基礎，熟悉Python、PHP等主流語言，基于Ansible開放API接口做二次開發，可以靈活有效地發揮其價值。Ansible自身也包括非常豐富的內置模塊，從Windows系統到開源Linux系統，從文件同步到命令執行，從軟件的安全升級到配置的維護變更，從商業硬件A10、F5到公（私）有云AWS、Digital、VMware、Docker等，幾乎囊括了運維日常所有的技術應用。系統下所有的操作可從運維操作角度劃分為兩類。

?文件傳輸：文件的本地傳輸和異地傳輸，所有文件的空間形態、時間形態變化均構成文件傳輸類操作。

?命令執行：終端所有操作對系統來講都是指令的組成，最終轉換為基礎硬件可接受的電信號完成任務集。對運維操作的用戶行為來講，除文件傳輸以外的其他操作均可稱為命令執行。

從自動化工作類型角度歸類如下。

（1）應用部署

現今的應用功能越來越強大，同步應用部署過程的依賴和規則也日趨復雜，但對應用運維的要求沒有隨之降低，有效快速正確平滑的應用部署需求日趨強烈。Ansible內置網絡、應用、系統、第三方云平臺擴展等完善的功能模塊，協助運維快速完成應用的安裝、卸載、升級、啟停、配置等部署類工作，即使對跨平臺或知名的商業硬件也同樣支持。

（2）配置管理

配置管理（Configuration Management, CM）是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟件產品的演化過程，確保軟件開發者在軟件生命周期中各個階段都能得到精確的產品配置。在日益復雜的IT環境和用戶需求下，Ansible內置File、Template，結合Jinja、Lineinfile等內置模塊，同時無縫結合GitHub、GitLab、Git、SVN、Jenkins等主流版本控制和CI持續集成工具，助力配置管理自動化。

（3）任務流編排

有效保證Tasks任務流按既定規則和順序完成事先制訂的目標和計劃，同時Roles編排方式又能在一定程度上從書寫習慣和代碼層編排上保證整體項目的可架構性和規范性，協助控制項目維護成本不致過高。

如上場景適用于網絡管理員、系統運維、應用運維、桌面運維、DevOps、基礎架構運維等多領域運維行業，以及無運維崗但服務規模又需有一定精力投入維護的小型公司，開發人員經過簡單的了解即可初步上手。同樣也適用于中大型公司，可以投入人力、精力、財力對Ansible進行二次開發，使其更加適用。

1.7 Ansible的安裝部署

了解完Ansible是什么、通信原理及發展史、Ansible發展歷程及其應用場景后，接下來為大家介紹Ansible的安裝部署。

Ansible的安裝部署非常簡單，其僅依賴于Python和SSH，而系統默認均已安裝。除Windows外，RedHat、Debian、CentOS、OSX 均可作為管理節點部署Ansible。Ansible被RedHat紅帽 官方收購后，其安裝源被收錄在EPEL中，如已安裝EPEL可直接YUM或APT安裝，通過pip和easy_install的Python第三方包管理器也可以便捷安裝Ansible，下面我們詳細介紹部署方式。

1.7.1 PIP方式

Ansible底層也是基于Python編寫，所以可以通過PIP方式安裝Ansible。

步驟1：安裝python-pip及python-devel程序包。

    // 安裝python-pip程序包及python-devel,
    yum install python-pip python-devel -y

返回類似如下結果則表示安裝成功：

        Installing : python-devel-2.7.5-34.el7.x86_64                                   1/2
        Installing : python-pip-7.1.0-1.el7.noarch                                       2/2
        Verifying   : python-pip-7.1.0-1.el7.noarch                                       1/2
        Verifying   : python-devel-2.7.5-34.el7.x86_64                                   2/2
    Installed:
        python-devel.x86_64 0:2.7.5-34.el7          python-pip.noarch 0:7.1.0-1.el7
    Complete!

步驟2：安裝Ansible服務。

    // 安裝請前確保服務器的gcc、glibc開發環境均已安裝，系統幾乎所有的軟件包編譯環境均基于gcc，如
    不確認可先執行如下命令：
    yum install gcc glibc-devel zlib-devel   rpm-build openssl-devel -y
    //升級本地PIP至最新版本
    pip install --upgrade pip
    //安裝Ansible服務
    pip install ansible -upgrade

執行命令ansible --version，有類似如下返回結果則表示Ansible安裝成功并可正常使用。

    ansible 2.1.1.0
        config file = /etc/ansible/ansible.cfg
        configured module search path = Default w/o overrides

如下其他驗證安裝是否成功的方式也一樣，均可執行ansible--version驗證，后面不一一列出。

1.7.2 YUM方式

YUM（Yellow dog Updater, Modified）是一個在Fedora和RedHat以及CentOS中的Shell前端軟件包管理器。基于RPM包管理，能夠從指定的服務器自動下載RPM包并且安裝，可以自動處理依賴性關系，并且一次安裝所有依賴的軟件包，無需煩瑣地一次次下載、安裝。YUM安裝Ansible過程如下：

    //需事先安裝EPEl【注：EPEL:EPEL（Extra Packages for Enterprise Linux，企業版Linux的額外軟件包）是Fedora小組維護的一個軟件倉庫項目，為RHEL/CentOS提供它們默認不提供的軟件包。】 源后方可找到并安裝Ansible
    rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
    // 安裝Ansible
    yum install ansible -y

安裝速度視網絡情況而定，因為安裝過程會安裝非常多的依賴包，又因各系統環境的差異性，如返回類似如下結果則表示安裝成功：

    Installed:
        ansible.noarch 0:2.1.1.0-1.el7
    Dependency Installed:
        PyYAML.x86_64 0:3.10-11.el7             libtomcrypt.x86_64 0:1.17-23.el7
        libtommath.x86_64 0:0.42.0-4.el7      python-babel.noarch 0:0.9.6-8.el7
        python-httplib2.noarch 0:0.7.7-3.el7 python-jinja2.noarch 0:2.7.2-2.el7
        python-keyczar.noarch 0:0.71c-2.el7   python-markupsafe.x86_64 0:0.11-10.el7
        python-pyasn1.noarch 0:0.1.6-2.el7    python2-crypto.x86_64 0:2.6.1-9.el7
        python2-ecdsa.noarch 0:0.13-4.el7     python2-paramiko.noarch 0:1.16.1-1.el7
        sshpass.x86_64 0:1.05-5.el7
    Complete!

1.7.3 Apt-get方式

Apt-get全稱是Advanced Package Tool，是一款適用于UNIX和Linux系統的應用程序管理器，適用于Ubuntu、Debian等deb包管理式的操作系統，主要用于自動地從互聯網的軟件倉庫中搜索、安裝、升級、卸載軟件或操作系統。

    // 添加Ansible源
    apt-add-repository -y ppa:ansible/ansible
    // 升級庫文件
    apt-get update
    // 安裝Ansible
    apt-get install -y ansible

1.7.4 源碼安裝方式

源碼安裝本身就是一道很高的門檻，作為剛接觸Linux的新手不建議使用該方式。

在什么情況下我們需要從源代碼安裝軟件呢？其實源碼安裝是相對于二進制安裝而言的，所謂的二進制安裝即前言講到的，PIP、YUM、Apt-get都是二進制的安裝方式，一般當新軟件推出了新的版本，而所用的發行版并沒有及時跟進，這時候，想要“嘗鮮”的話，就非得靠自己而不可使用源碼編譯安裝；另一種情形是，不管是軟件的開發者還是現用的系統都沒有提供可直接使用的二進制包，而自己又非要使用該軟件，那么也需源碼安裝才行。當然，還有其他的情形。總而言之，學會源碼安裝軟件方式是一項非常重要的技能，但又因其編譯環境準備起來復雜不堪，同時安裝過程又需人工逐一解決安裝過程中可能遇到的各項應用層依賴和系統庫依賴，所以門檻較高，故不建議初學者使用該方式。

    // 不建議安裝Beta版
    //安裝Git【注：Git:Git是一款免費、開源的分布式版本控制系統，用于敏捷高效地處理任何或小或大的項目。Git可以有效、高速地處理從很小到非常大的項目版本管理。Git是Linus Torvalds為了幫助管理Linux內核開發而開發的一個開放源碼的版本控制軟件。】  客戶端
    yum install git -y

整個安裝過程無報錯，有類似如下返回結果則表示安裝成功。

    Installed:
        git.x86_64 0:1.8.3.1-5.el7
    Dependency Installed:
        libgnome-keyring.x86_64 0:3.8.0-3.el7 perl-Error.noarch 1:0.17020-2.el7
        perl-Git.noarch 0:1.8.3.1-5.el7         perl-TermReadKey.x86_64 0:2.30-20.el7
    Complete!

安裝Ansible軟件包。

    // 使用Git將拉取指定的Ansible版本至本地當前目錄
    git clone git://github.com/ansible/ansible.git -recursive
    // 切換至程序包目錄
    cd ./ansible
    // 執行env-setup腳本，安裝Ansible軟件包
    source ./hacking/env-setup

1.7.5 驗證安裝結果

如上列舉了互聯網主流系統的Ansible安裝方式，如整個過程均無報錯，則執行如下命令應有類似結果返回：

    ansible --version
    ansible 1.9.6

如上述命令能正常執行，表示Ansible安裝成功，并可正常使用。通常情況下，Ansible的安裝簡單順利，但確實會有安裝報錯的情況發生，多數情況是由本地復雜的系統環境導致的。下面我們為大家介紹Python多環境管理，來解決該類問題。

1.8 Python多環境擴展管理

眾所周知，Python發展至今，版本眾多，部分版本功能差異較大，在使用過程中經常遇到第三方庫依賴的Python版本和系統Python版本不一致的情況。同時又因系統底層需調用當前版本Python，所以不能隨意變更當前系統Python版本。如此情景下就會有Python多版本共存的情況。于是，Python多環境管理工具應運而生。這里為大家介紹兩款工具，分別是Pyenv和Virtualenv。Pyenv和Virtualenv均為Python管理工具，不同的是，前者是對Python的版本進行管理，實現不同版本間的切換和使用；而后者則通過創建虛擬環境，實現與系統環境以及其他Python環境的隔離，避免相互干擾。

1.8.1 Pyenv的部署與使用

Pyenv是一個簡單的Python版本管理工具，以前叫作Pythonbrew。它讓你能夠方便地切換全局Python版本，安裝多個不同的Python版本，設置獨立的某個文件夾或者工程目錄特異的Python版本，同時創建Python虛擬環境（virualenv's）。所有這些操作均可以在類UNIX系統的機器上（Linux和OS X）不需要依賴Python本身執行，而且它工作在用戶層，不需要任何sudo操作。

（1）部署

Pyenv作為Python的版本管理工具，通過改變Shell的環境變量來切換不同的Python版本，以達到多版本共存的目的。該工具不支持Windows系統。具體工作原理如下。

1）Pyenv安裝后會在系統PATH中插入shims路徑，每次執行Python相關的可執行文件時，會優先在shims里尋找Python路徑～/.pyenv/shims:/usr/local/bin:/usr/bin:/bin；

2）系統選擇Python版本，依如下順序選擇Python的版本：

?Shell變量設置（執行pyenv shell查看）

?當前可執行文件目錄下的．python_version文件里的版本號（執行pyenv shell查看）

?上層目錄查詢找到的第一個．pyenv-version文件

?全局的版本號在～/.pyenv/version文件內（執行pyenv global查看）

3）確定版本文件的位置和Python版本后，Pyenv會根據版本號在～/.pyenv/versions/文件夾中查找對應的Python版本。執行命令pyenv versions可查看系統目前安裝的Python版本。

接下來開始部署Pyenv，具體部署方式如下：

    //clone pyenv至家目錄
    git clone git://github.com/yyuu/pyenv.git ～/.pyenv
    // 修改環境變量
    echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ～/.bashrc
    echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ～/.bashrc
    echo 'eval "$(pyenv init -)"' >> ～/.bashrc
    //重啟當前 Shell
    exec $Shell -l

執行pyenv versions命令，有類似如下返回結果表示安裝正常：

    * system (set by /home/o2o/.pyenv/version)
        2.7.8

接下來我們來了解Pyenv的使用方式。

（2）通過Pyenv管理多Python版本

Pyenv命令使用規則如下：

    Usage: pyenv <command> [<args>]

我們通過Pyenv安裝Python 3.4.1版本來熟悉其用法。

    // 查看可安裝的版本列表
    pyenv install -list
    // 安裝指定的Python版本
    pyenv install 3.4.1
    // 切換當前目錄Python版本為3.4.1
    pyenv local   3.4.1
    // 切換全局目錄Python版本為3.4.1
    pyenv global   3.4.1
    // 刷新shims
    pyenv rehash

Pyenv更多用法如下：

    commands            列出pyenv的所有可用命令
    local               設置或列出當前環境下Python版本號
    global              設置或列出全局環境下Python版本號
    shell               設置或列出Shell環境下Python版本
    install             安裝指定的Python版本
    uninstall          卸載指定的Python版本
    rehash              重新加載Pyenv的shims路徑（安裝完Python版本后需執行該命令）
    version             展示當前Python版本號及其生效的路徑
    versions            列出Pyenv管控的所有可用Python版本
    which               列出要使用命令的絕對路徑
    whence              列出后綴命令的所有可用版本

至此，Pyenv介紹完畢，接下來再介紹一款Python多管理工具Virtualenv，它不是通過多版本管理的方式來實現系統同時兼容多Python環境。Virtualenv是底層基于Python開發的Python環境隔離工具，其通過虛擬目錄的方式來實現多環境的并存。其工作原理很簡單：在你所需的地方創建工作目錄，該目錄類似系統安裝的Python目錄，保留完整的Python環境、解釋器、標準庫和第三方庫等，當我們需要時，切換環境變量激活即可使用。接下來我們進一步學習Virtualenv的安裝部署及版本管理。

1.8.2 Virtualenv的部署與使用

Python的第三方包成千上萬，在一個Python環境下開發時間越久、安裝依賴越多，就越容易出現依賴包沖突的問題。為了解決這個問題，開發者們開發出了Virtualenv，它可以搭建虛擬且獨立的Python環境。這樣就可以使每個項目環境與其他項目獨立開來，保持環境的干凈，避免包沖突問題。另外，在開發Python應用程序的時候，所有第三方的包都會被PIP安裝到系統Python版本的site-packages目錄下。但如果我們要同時開發多個應用程序，那這些應用程序會共用一個Python，這意味著所有的包都安裝在系統的Python目錄下，這不僅影響我們的正常開發工作，還有可能因為隨意變更系統Python版本信息而造成系統的不穩定。這種情況下，每個應用可能需要各自擁有一套“獨立”的Python運行環境。Virtualenv就是用來為一個應用創建一套“隔離”的Python運行環境的。下面我們來看看Virtualevn的部署，以及它如何管理Python環境。

（1）部署

假設你已經學習過我們上節內容并安裝好PIP了，那么Virtualenv的安裝非常簡單，操作如下：

    // 安裝virtualenv
    pip install virtualenv

返回如下結果表示安裝成功：

    Installing collected packages: virtualenv
    Successfully installed virtualenv-15.0.3

（2）通過Virtualenv管理多Python版本

需強調說明的是：Virtualenv不是通過多版本管理的方式來實現系統同時兼容多Python環境的，而是其通過在工作目錄中虛擬完整的Python環境來實現Python多環境并存。接下來我們看Virtualenv的使用方式。

Virtualenv命令的使用格式如下：

    virtualenv [OPTIONS] DEST_DIR

中括號OPTIONS表示參數選項，是可選項，即可有可無；DEST_DIR表示命令要執行的目錄，如：

    // 創建/data/magedu/的虛擬目錄
    virtualenv /data/magedu/

可用的OPTIONS選項如下：

    --version  顯示當前版本號。
    -h, --help  顯示幫助信息。
    -v, --verbose  顯示詳細信息。
    -q, --quiet  不顯示詳細信息。
    -p PYTHON_EXE, --python=PYTHON_EXE  指定所用的python解析器的版本，比如--python=python2.5
    就使用2.5版本的解析器創建新的隔離環境。默認使用的是當前系統安裝(/usr/bin/python)的python解
    析器。
    --clear  清空非root用戶的安裝，并從頭開始創建隔離環境。
    --no-site-packages  令隔離環境不能訪問系統全局的site-packages目錄。
    --system-site-packages  令隔離環境可以訪問系統全局的site-packages目錄。
    --unzip-setuptools  安裝時解壓Setuptools或Distribute。
    --relocatable   重定位某個已存在的隔離環境。使用該選項將修正腳本，并令所有．pth文件使用相應
    路徑。
    --distribute   使用Distribute代替Setuptools，也可設置環境變量VIRTUALENV_DISTRIBUTE
    達到同樣效果。
    --extra-search-dir=SEARCH_DIRS   用于查找setuptools/distribute/pip發布包的目錄。可
    以添加任意數量的-extra-search-dir路徑。
    --never-download   禁止從網上下載任何數據。此時，如果在本地搜索發布包失敗，virtualenv就會
    報錯。
    --prompt==PROMPT  定義隔離環境的命令行前綴。

下面詳細看看virtualenv在工作中的應用方式。我們先創建一個/data/datafile/software/virtualpy/的虛擬工作目錄，而后再切換至虛擬環境。

    // 創建虛擬工作目錄
    virtualenv /data/datafile/software/virtualpy/
    // 通過source加載環境變量，使本地環境切換至虛擬工作目錄
    source /data/datafile/software/virtualpy/bin/activate

看到如圖1-4所示的Virtualenv虛擬工作目錄標識，表示已切換至虛擬工作目錄。

退出虛擬環境命令如下：

    // 退出虛擬環境
    Deactivate

看到如圖1-5所示的退出虛擬工作目錄顯示正常的BASH Shell提示符，表示即已退出虛擬工作目錄。

至此，多版本Python環境管理工具Pyenv和Virtualenv介紹完畢。如果基于系統默認Python版本安裝有問題，可嘗試基于Pyenv或Virtualenv切換Python版本后，再次重試1.7節Ansible的安裝步驟。

1.9 本章小結

Ansible是運維自動化工具的后起之秀。本章前半部分我們學習了Ansible是什么，底層通信發展史，Ansible發展歷程等概念性知識。后半部分我們詳細介紹了Ansible安裝部署方式，同時考慮本地復雜環境可能導致的部署問題，本章后半部分我們也引申介紹了Python多環境擴展管理，以方便大家應對部署過程中可能出現的各類問題。當然，Ansible的部署總體非常簡單，一般出問題多數是因為系統的glibc、gcc等開發環境沒有安裝或不完整導致。在學習過程中還請嚴格參考本章安裝操作步驟循序漸進，相信大家學完本章也有所體會。