【51CTO精选译文】大部分服务器自动化及流程解决方案，例如Puppet与Chef，都依赖于特定方案编码、Web UI以及命令行工具等要素的综合体，从而使整套体系正常运转。Ansible则有所不同。尽管也能够支持Web UI，Ansible在Unix管理员的监管范围内同样作用良好，即使用大量通用脚本以及命令行机制。
Ansible是一款极为灵活的开源工具套件，能够大大简化Unix管理员的自动化配置管理与流程控制方式。它利用推送方式对客户系统加以配置，这样所有工作都可在主服务器端完成。其命令行机制同样非常强大，允许大家利用商业许可Web UI实现授权管理与配置。
安装Ansible
安装Ansible非常简单。大家可以直接从Git资源库中克隆镜像，或者利用Linux或者Unix环境下的软件包管理工具下载并安装Ansible软件包。管理工具能保证大家获取必要的软件包以及Python 2.6可执行文件，而且前后只需数分钟，我们就能完成Ansible主服务器的配置任务。
总体而言，大家需要将Ansible部署在中央服务器当中，同时在Ansible主机文件内配置所需管理的客户端群组以及主机名称。托管主机的配置流程也非常精简，只需要安装功能性Python 2.4或者2.6并为连入的Ansible主服务器及各台主机配置SSH authorized_keys文件。
大家可以采取多种途径实现这一步骤，例如作为特定用户或者在主服务器上运行命令的用户将Ansible配置到全部接入主机当中。各位当然可以通过root权限用户搞定一切，但很多朋友可能更倾向于利用普通用户账户进行连接并使用sudo命令实现root权限。
举例来说，我们可以在自己的主服务器上建立一个名为“ansible”的用户；接下来将一个“ansible”用户添加至托管主机并为该用户提供无需密码的sudo使用能力。另外，我们也可以为主机上的sudo命令设定密码，或者指定一个其它用户名专门用于连接。总而言之，我们的最终目标在于保证Ansible的控制可执行文件通过SSH及运行命令接入同一台经过配置的主机。到这里，我们已经讲完了关于Ansible主服务器及客户机的全部配置流程。
Ansible如何运行
主服务器与托管主机的配置工作完成之后，现在我们可以着手了解Ansible的具体功能。下面举一个简单的例子：
- [ansible@ansible1: ~]$ ansible all -m ping -u ansible -sudo
- ansiblecentos.iwlabs.net | success >> {
- "changed": false,
- "ping": "pong"}
- ansibleubuntu.iwlabs.net | success >> {
- "changed": false,
- "ping": "pong"
- }
上述命令的作用在于确保我们的托管主机已经完成配置并能够正确应答请求。根据返回的结果，可以看到我们的目标主机已经准备好应对日常任务了。
现在，我们可以运行其它命令进一步探索其功能特性：
- [ansible@ansible1: ~]$ ansible all -m copy -a "src=/etc/myconf.conf dest=/etc/myconf.conf" -u ansible -sudo
- ansiblecentos.iwlabs.net | success >> {
- "changed": true,
- "dest": "/etc/myconf.conf",
- "gid": 500,
- "group": "ansible",
- "md5sum": "e47397c0881a57e89fcf5710fb98e566",
- "mode": "0664",
- "owner": "ansible",
- "size": 200,
- "src": "/home/ansible/.ansible/tmp/ansible-1379430225.64-138485144147818/source",
- "state": "file",
- "uid": 500
- }
- ansibleubuntu.iwlabs.net | success >> {
- "changed": true,
- "gid": 1000,
- "group": "ansible",
- "mode": "0664",
- "owner": "ansible",
- "path": "/etc/myconf.conf",
- "size": 200,
- "state": "file",
- "uid": 1000
- }
如大家所见，以上命令旨在将/etc/myconf.conf文件复制到我们的两台托管主机当中。在复制过程中，我们还会获得一个JSON返还对象，其中包括数据以及文件归属等信息。我们还可以通过命令行调整其归属、权限以及其它变量。
我们还可以通过以下命令确保服务会在主机启动的同时开始运行：
- [ansible@ansible1: ~]$ ansible webservers -m service -a "name=httpd state=running" u ansible -sudo
或者重新启动这些主机：
- [ansible@ansible1: ~]$ ansible webservers -m command -a "/sbin/reboot -t now"
或者提取一份包含全部主机的清单：
- [ansible@ansible1: ~]$ ansible all -m setup -u ansible --sudo
最后一行命令将输出用于描述每一台主机的JSON对象，其中包括总体内存、已使用内存、CPU、网络、磁盘信息、操作系统版本以及内核版本等等。
如各位所见，Ansible允许用户通过调整命令行参数执行命令、收集数据并向目标位置复制文件。
这项功能本身也可以单独通过SSH外加一些脚本来实现，毕竟利用远程主机上的SSH实现命令执行早已不是什么新闻。Ansible的进取之处在于有能力通过一条短短的参数集同时实现命令执行、分组、清单以及其它更高级别的主机管理功能。每一项Ansible命令行功能都提供多种选项，包括引用多个分组或者在单一子集（例如将前五十台服务器构建为一个分组子集）中运行命令。
Unix管理员当然能够立即上手这些功能，并快速利用Ansible的工具编写脚本、从而以非常简便的方式实现任务处理的自动化与流程化。除此之外，我们还可以创建Playbook以收集命令与任务集，这样能够大大降低管理工作的复杂程度。
Ansible Playbook
Playbook采用YAML语法结构，因此它们一般比较易于阅读并加以配置。举例来说，下面这条简单的Playbook能够确保NTPD始终以“ansible”用户身份运行在全部主机上、且利用sudo进行连接。
- ---
- - hosts: all
- remote_user: ansible
- tasks:
- - service: name=ntpd state=started
- sudo: yes
我们还可以利用Playbook实现文件复制。如下所示为Playbook文件复制版本，其中同时对归属及文件所在客户机的权限做出了指定：
- ---
- - hosts: all
- remote_user: ansible
- tasks:
- - name: Copy file to client
- copy: src=/etc/myconf.conf dest=/etc/myconf.conf
- owner=root group=root mode=0644
我们也可以在Playbook中使用各种变量：
- ---
- - hosts: webservers
- remote_user: root
- vars:
- ntp_service: 'ntpd'
- tasks:
- - service: name={{ ntp_service }} state=started
- sudo: yes
除了前面列举的例子之外，我们还可以使用模板。大家可以在建立的模板中引用变量，而后从Playbook当中调用这些模板、从而构建需要的文件。最后，为Apache配置创建一个模板文件，将该配置利用Playbook所指定的变量添加到客户机当中：
- template: src=/srv/templates/apache.conf dest=/etc/httpd/conf.d/{{ vhost }}.conf
当然，我们可能还需要在稍后重新启动服务——这一点可以通过notify及handler函数实现。
- notify:
- restart apache
- handlers:
- - name: restart apache
- service: name=apache state=restarted
在Playbook中包含上述命令能够确保虚拟主机配置文件被保存在客户机中的正确位置，而后重启Apache、从而使全部配置变更正常生效。
与大家的期望相同，我们可以在Playbook中包含文件。我们可以创建一个包含全部必要handler的文件，而后将该文件添加到新Playbook当中。如此一来，我们就能够集中对所有handler进行配置、同时又确保它们适用于全部Playbook。
更进一步，大家还可以通过配置角色在Playbook中收集handler、任务以及各种变量，从而供其它角色引用。举例来说，大家可能在数据库服务器的日常使用中涉及一系列handler与任务，这时就需要在数据库角色中包含这些文件，而后将角色添加到Playbook当中以容纳全部配置元素。大家还可以根据需要对关联性进行配置，从而使其它角色引用现有配置方案。
总而言之，Playbook的创建过程并不太直观，但精心调教出来的Playbook也确实能带来出色的扩展能力与顺畅的组织方式。值得一提的是，Playbookr运行非常便捷：
- [ansible@ansible1: ~]$ ansible-playbook myplaybook.yml -f 10
这条命令将并行运行十次Playbook的myplaybook.yml文件，也就是说服务器将一次性与十台客户机连接并在其中运行myplaybook.yml。
| While Ansible uses paramiko, a Python SSH2 implementation, or native SSH to communicate with clients, there can be a scalability issue when moving into large numbers of clients. To address this, Ansible 1.3 offers an accelerate mode that launches a daemon over SSH that provides AES-encrypted communication directly with the client. This feature can speed up client communications substantially when measured in large-scale implementations as compared to paramiko or native SSH. |
由于Ansible使用的是paramiko，一种Python SSH2方案，或者原生SSH与客户机通信，因此当对应的客户机数量过大时有可能出现扩展性问题。为了解决这一弊端，Ansible 1.3版本提供一套加速模式，通过在SSH上启动后台程序实现与客户机之间的直接加密通信。
Ansible模块
Ansible当中包含一系列模块，旨在实现其它扩展功能，例如针对云服务（以Amazon EC2为代表）的配置与管理以及针对各主流数据库服务器、文件操作以及网络设备的专用模块等。大家还可以通过创建自己的模块来满足特定需求。我们几乎能够使用任何一种编程语言来创建此类模块，除了Python之外、还包括Perl、Bash乃至C++。
我们可以通过编码让模块接纳变量，并要求其输出JSON对象以指明包括命令在内的各种能够在运行过程中收集到的相关状态信息。
AnsibleWorks AWX
Ansible也支持一套特定的Web UI，这就是AnsibleWorks AWX。这是一套付费解决方案，能够围绕Ansible提供清晰而简洁的Web UI。不过这套Web UI无法在默认状态下被直接添加到Ansible配置当中；如果大家已经在服务器上广泛安装了Ansible，那么直接将AWX添加进去并不能立刻获得Web样式的预期结构。相反，大家可以利用命令行工具将现有Ansible Inventory导入到AWX当中——如果需要让命令行与AWX保持一致，我们还需要在此后不断对二者加以同步。
一旦安装并开始运行AWX，大家可以根据自己的基础设施状况对用户、团队、Inventory、项目以及工作模板等进行配置。不过需要注意的是，大家必须以新增形式添加这些对象，它们并不以那些包含着全部主机及配置的现有配置文件为基础。AWX还提供RESTful API，并集成了LDAP与Active Directory以实现验证及授权功能。这种集成能够帮助大家更便捷地在UI当中将用户及群组与全局组织进行映射。
AWX Web UI提供的界面简洁而且比较直观，执行速度相当出色。该UI严格基于Playbook，因此无法使用任何命令行功能。我们需要通过创建Playbook来描述自己想要执行的命令行操作，然后将其添加到服务器中的特定目录之下。接下来在UI中的工作模板之下访问对应Playbook，而后将其作为Inventory的附加组件，这样包含在内的工作就能顺利进行了。
这套Web UI确实具备一定功能性，但它既不够完善也无法作用于命令行界面。举例来说，大家不能通过这套Web UI实现工作调度——相反，各位倒是可以很轻松地通过命令行中的cron满足这类需要。Playbook可以运行在Web UI与命令行两种环境下，因此如果大家的命令行安装体积太过庞大，不妨考虑将自己的Playbook换个平台，这几乎不会带来什么影响。当然，结构的其它部分仍然需要通过同步实现复制。
AnsibleWorks AWX还借助一系列Ansible模块带来基于Web的简单云服务集成效果，因此大家可以为内部用户及团队提供一套Web UI，从而通过本地管理控制台支撑起公共或者私有云服务，并利用本地LDAP或者AD基础设施实现身份验证与授权。通过这种方式，AWX完全能够充当一套针对内部客户的自助门户。
Ansible实际效果
长话短说，Ansible是一款极度化且易于设置及运行的自动化工具。其Web UI还算实用，但对于日常操作之外的深层任务，命令行的扩展性更好、效率也更高。
Ansible并未内置任何高可用性机制，但该方案的调度简洁设计允许用户轻松通过多套系统控制所有客户机。只要在各服务器上采用丰富的“Playbook”及配置元素，高可用性倒不是什么大问题。
缺乏对Windows环境的支持导致Ansible在互操作性环节得分偏低，但需要强调的是，这是一款真正为Linux及Unix管理所量身打造的工具，所以这也不算什么大毛病。
Ansible的设计与实际效果证明，这是一款专为Unix老鸟管理员打造的利器。Ansible不走Windows路线，而且也没有提供太多点缀和可有可无的小玩意。总而言之，这是一款确实能够快速简便打理Linux及Unix系统的优秀产品。
原文链接：
