第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等开发环境没有安装或不完整导致。在学习过程中还请严格参考本章安装操作步骤循序渐进，相信大家学完本章也有所体会。