在开源领域 Linux 风声水起，缘于一众富有想象力的开源工具。在 Linux 服务器的自动化管理方面，也有众多选择，例如 Puppet、Chef、SaltStack、Ansible。前三个管理工具采用的是服务端/客户端模式，换而言之，既要配置客户端又要配置服务端才能让它们工作。Ansible 与它们不同，它充分利用 Linux 服务器的现有设施。使用 Ansible 无需安装服务端和客户端，只要配置好 OpenSSH 服务即可。Ansible 的配置文件采用的是易读格式，例如，Ansible 的主机文件使用 INI 格式，支持分组，能够指定模式；而 Playbook 则是 YAML 格式。这比 Puppet 等工具使用独有配置文件格式要容易读写。当前使用 Ansible 较为知名的用户包括 Fedora、Rackspace、Evernote 等等。
1、安装 Ansible
Ansible 能够安装到 Linux、BSD、Mac OS X 等平台，Python 版本最低要求为 2.6。大多数 Linux 发行版可以通过包管理器安装 Ansible。例如，对于 Red Hat 系来说，需要配置 EPEL 源，然后执行
$ sudo yum install ansible
Debian 系只需
$ sudo apt-get install ansible
Gentoo 可执行
$ sudo emerge -avt ansible
如果所用系统的软件包仓库中找不到 Ansible 或者系统本身没有软件仓库，那么也可以通过 pip 来安装 Ansible
$ pip install --user ansible
上述命令行执行同时也会安装 paramiko、PyYAML、jinja2 等 Python 依赖库。 现在来看看 Ansible 是否能正常工作：
$ ansible 127.0.0.1 -m ping -u james -k
请注意此地连接的是本地主机，为保证 ansible 正常工作，需在本地配置 OpenSSH 服务并以允许密码认证方式登录，同时还需创建 james 账户。
2、Ansible 的主机文件
Ansible 的主机文件用来定义你要管理的主机，系统级主机文件的默认位置在 /etc/ansible/hosts。当然也可以设置 Ansible 的用户级主机文件，它可覆盖系统级主机文件，具体来说就是在用户家目录创建 Ansible 配置文件并在其中指定用户级主机文件的路径，例如
$ nano -w ~/.ansible.cfg [defaults] # some basic default values... # ansible 1.8 or ago #hostfile = $HOME/.ansible/hosts # ansible 1.9 or later inventory = $HOME/.ansible/hosts $ mkdir -p ~/.ansible $ touch ~/.ansible/hosts
最后，还可通过 ansible 命令行选项 -i 指定主机文件的路径，它能覆盖前面两者的配置。主机文件是一些被管理的机器的 IP 或域名组成的。这些主机可以分组存放，组名可以使用 [] 指定，未分组的机器需保留在主机文件的顶部，主机文件中可以指定远程主机的 SSH 端口。例如：
202.121.111.8 [vps] 202.121.111.10 [web] 202.121.111.18 172.16.10.124:5555 [db] 202.121.111.19
同时，分组也能嵌套：
[vps:child] web db
此外，也可以通过数字和字母模式来指定一系列连续主机，如：
202.121.111.[1:3] # 相当于 202.121.111.1、202.121.111.2、202.121.111.3 [a:c].exmaple.org # 相当于 a.example.org b.example.org、c.example.org
3、Ansible 的 Ad-Hoc 模式
Ansible 的强大很大程度上体现在它 Playbook 上，后者基本上就是一些写好的 "Ansible 脚本"。不过在正式介绍它之前，先从简单的 ansible 命令行开始，这就是 ansible 的 Ad-Hoc 模式。Ad-Hoc 模式与在 Bash Shell 中执行单行命令差不多，用来快速完成简单任务。先来看看 ansible 的命令行选项：
- -i,--inventory-file=：指定主机文件，不指定的话默认依顺序使用用户级、系统级的主机文件
- all：针对主机文件中定义的所有主机执行，也可以指定组名或模式
- -m,--module-name=：指定所用的模块，不指定的话默认使用 command 模块
- -a：指定所用模块的参数，不指定的话所用模块不使用参数
- -u,--user=：指定远端机器的用户，若不指定，默认是执行 ansible 的本地用户账户名
- -c,--connection=：指定远端主机用户登录时的认证模块，通常有 smart、paramiko、sshpass，默认是 smart
- -f,--forks=：参数让 ansible 在主机上并行运行指令
- -k,--ask-pass：询问 SSH 密码；若使用 SSH 密匙，请不要使用 -k
通常，执行 Ansible 需要 SSH 密码认证，提示 SSH 密码：
$ ansible all -m ping -u root --ask-pass
在一些机器上使用 --ask-pass 会需要指定连接方式，例如：
$ ansible all -m ping -u root --ask-pass -c paramiko
当然也可以使用模块 sshpass，然而 sshpass 并不总是在标准的仓库中提供，因此 paramiko 可能更为简单。需要注意，操作很多主机时需逐个输入账户名与密码，这些都是相当麻烦的。为简单起见，可做下述配置
$ sudo nano -w /etc/ansible/hosts #定义被控主机 [webservers] 172.16.10.123 ansible_ssh_user=root ansible_ssh_pass=centos 172.16.10.125 ansible_ssh_port=5555 ansible_ssh_user=root ansible_ssh_pass=centos web1 ansible_ssh_host=172.16.10.126 ansible_ssh_port=5555 ansible_ssh_user=root ansible_ssh_pass=centos [dbservers] 172.16.10.125 ansible_ssh_user=root ansible_ssh_pass=centos
下面再看看远端主机的 uptime：
$ ansible webservers -a 'uptime'
此处省略了 -i，ansible 使用默认的主机文件；webservers 代表默认主机文件中的某个主机组；也省略了 -m，ansible 默认使用 command 模块；-a 指定模块的参数，即执行 uptime 命令。如果被管理端主机的 Python 为 2.4，那么需要 python-simplejson 包，可以通过以下命令在所有 CentOS 主机上安装它：
$ ansible webservers -m raw -a 'yum -y install python-simplejson'
此处使用 Ansible 的 raw 模块，它的作用相当于直接在 OpenSSH 中执行 -a 后面的命令。再如利用 Ansible 可执行系统更新
$ ansible webservers -m raw -a 'yum update -y'
或者安装某些服务
$ ansible webservers -m raw -a 'yum -y install httpd' $ ansible webservers -m raw -a "service httpd start" $ ansible webservers -m raw -a "chkconfig httpd on"
实际上，将 OpenSSH 密码放入主机文件是非常不安全的，强烈推荐为 Ansible 设置 SSH 公钥认证。除了密码安全问题之外，对于非超级用户登录远程主机并执行超级用户命令，需要开启 su 或 sudo 权限。例如，vps 组中的账户 james 配置了 sudo 权限，可用该账户升级系统，例如
$ ansible vps -m raw -a "yum upgrade -y" -u james -k -b --become-user=root --become-method=sudo
或者
$ ansible vps -m raw -a "sudo yum upgrade -y" -u james -k
4、Ansible 的帮助文档
Ansible 的强大功能均是由它众多模块提供的，诸如为 Linux 创建用户及组、安装软件包、分发配置文件、管理服务等等。要想了解 Ansible 模块的全部功能，必要的文档是不可少的。在命令行下，可通过 ansible-doc 查询模块文档，如：
$ ansible-doc raw
列出模块 raw 中相关指令
$ ansible-doc -s raw
要查看所有安装模块
$ ansible-doc -l
若 Ansible 提供了模块功能，尽量使用模块，例如 Red Hat 系有 yum 模块，因此前述 CentOS 上的操作可替换为
$ ansible webservers -m yum -a 'name=* state=latest' $ ansible webservers -m yum -a 'name=httpd state=latest' $ ansible webservers -m service -a 'name=httpd state=started' $ ansible webservers -m service -a 'name=httpd enabled=yes'
5、设置 SSH 公钥认证
现在让我们创建和配置 SSH 公钥认证，以便省去 -c 和 --ask-pass 选项。首先，生成密匙对：
$ ssh-keygen -t rsa
上述命令会在当前用户的 ~/.ssh 中生成密匙对，假设当前用户为 james。显然有很多种方式把 SSH 公匙放到远程主机上，既然要介绍 ansible 的用法，就用它来完成这个操作吧：
$ ansible all -m copy -a "src=/home/james/.ssh/id_rsa.pub dest=/tmp/id_rsa.pub" --ask-pass -c paramiko
下一步，把公钥文件添加到远程服务器里。输入：
$ ansible all -m shell -a "cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys" --ask-pass -c paramiko
由于把密匙放入超级用户目录，但又没有指定 -u 选项，因此默认登录远程主机的账户是执行 ansible 的本地账户，通常会因权限不够执行会失败。不要急，需要用 root 来执行这个命令，加上 -u 参数即可：
$ ansible all -m shell -a "cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys" --ask-pass -c paramiko -u root
刚才演示了通过 ansible 来传输文件的操作。事实上 ansible 有一个更加方便的内置 SSH 密钥管理支持：
$ ansible all -m authorized_key -a "user=james key='{{ lookup('file', '/home/james/.ssh/id_rsa.pub') }}' path=/home/james/.ssh/authorized_keys manage_dir=no" --ask-pass -c paramiko
至此，公钥已经设置好了。试着随便跑一个命令，比如 hostname，希望不会被提示要输入密码
$ ansible all -m shell -a "hostname" -u root
现在可以用 root 来执行命令，并且不会被输入密码的提示干扰了。最后，把 /tmp 中的公钥文件删除：
$ ansible all -m file -a "dest=/tmp/id_rsa.pub state=absent" -u root
下面来做一些更复杂的事情，而且无须输入密码。例如：
$ ansible all -m yum -a "name=httpd state=latest" -u root
利用 Ansible 的 yum 模块安装好了最新版的 Apache 服务器。实际上，上一条命令可以用下述 Playbook 替代：
--- - name: test.yaml # Playbook 的名称 hosts: webservers # Playbook 所作用的主机列表 remote_user: root # 远程主机的用户名 tasks: # 任务列表 - yum: name=httpd state=latest # 使用 yum 模块执行任务一
现在有一个简单的 Playbook 了，可以这样运行它：
$ ansible-playbook test.yaml -f 10
既然 Playbook 的操作如此简单，不妨把导入 SSH 公钥的操作从 ansible 命令行转移到 Playbook 中，这将在设置新主机的时候提供很大的方便，甚至让新主机直接可以运行一个 Playbook。为了演示，把之前的公钥例子放进一个 Playbook 里：
---
- hosts: webservers # Playbook 所作用的主机列表
remote_user: james # 执行任务的远程主机用户名
sudo: yes # 启用 sudo 权限执行任务
tasks:
- authorized_key:
user=root
key="{{ lookup('file', '/home/james/.ssh/id_rsa.pub') }}"
path=/root/.ssh/authorized_keys
manage_dir=no
在准备开始写更多更复杂的 Playbook 之前，另一个值得考虑的事情是，引入版本管理器可以有效节省时间。虽然需要管理的 Linux 的服务器需求会不断变化，然而并不需要在每次机器发生变化时都重新写一个 Playbook，只需要更新相关的部分并提交这些修改。这里强烈推荐版本管理器 Git 来管理各类 Playbook 脚本。
6、使用 Playbook 管理复杂任务
对于需反复执行的、较为复杂的任务，我们可以通过定义 Playbook 来搞定。Playbook 是 Ansible 真正强大的地方，它允许使用变量、条件、迭代以及模板，也能通过角色及包含指令来重用既有内容。我们来看一个简单的例子，该例子在远端机器上创建一个新的用户：
$ nano -w user.yaml
---
- name: create user # Playbook 的名称
hosts: vps # 执行任务的主机表
user: root # 执行任务的远程主机用户
gather_facts: false # 不获取远程主机的信息
vars: # 自定义变量列表
- user1: "toy" # 第一个自定义变量
tasks: # 任务列表
- name: create {{ user1 }} on vps # 第一个任务的名称
user: name="{{ user1 }}" # 任务格式："action: module options" 或 "module: options"
- name: template configuration file # 第二个任务的名称
template: src=template.j2 dest=/etc/foo.conf
notify: # 可用于在每个 play 的最后被触发，避免多次有改变发生时每次都执行指定的操作，取而代之，仅在所有的变化发生完成后一次性地执行指定操作。
- restart memcached # 调用 handler 中定义的操作名
- restart apache
handlers: # 用于当关注的资源发生变化时采取一定的操作。handler 是 task 列表，这些 task 与前述的 task 并没有本质上的不同。
- name: restart memcached # 第一个 handler 名
service: name=memcached state=restarted
- name: restart apache # 第二个 handler 名
service: name=httpd state=restarted
首先，我们给 Playbook 指定了一个名称；接着，通过 hosts 让该 Playbook 仅作用于 vps 组；user 指定以 root 帐号执行，Ansible 也支持普通用户以 sudo 方式执行任务；gather_facts 的作用是搜集远端机器的相关信息，稍后可通过变量形式在 Playbook 中使用；vars 用于定义变量，也可单独放在文件中；tasks 指定要执行的任务，其中 notify 用来监视资源变化，据此调用相关的 handlers；handlers 类似于 tasks，但它仅根据 notify 信号来决定是否执行相应的 handler。要执行 Playbook，可以敲入：
$ ansible-playbook user.yaml
6.1、Ansible 中的变量
正如前述例子中所看到的，Ansible 的 Playbook 中是可以定义变量的。Ansible 的变量名仅能由字母、数字和下划线组成，且只能以字母开头。Ansible 本身也保存了一些变量，它们称之为 facts。facts 是由正在通信的远程目标主机发回的信息，这些信息被保存在 Ansible 变量中。要获取指定的远程主机所支持的所有 facts，可使用如下命令进行：
$ ansible vps -m setup
通过上述命令，Ansible 会存储很多远程主机相关的变量供 Playbook 使用，例如 ansible_os_family 等。 Ansible 可以通过角色传递变量。当给一个远程主机应用角色的时候可以传递变量，然后在角色内使用这些变量。例如：
---
- hosts: webservers
roles: # 角色列表
- common # 第一个角色
- { role: wordpress, dir: '/var/www/htdocs/blog', port: 8080 } # 第二个角色
Ansible 通过 register 把任务的输出定义为变量，然后用于其他任务，示例如下:
---
- tasks:
- shell: /usr/bin/foo
register: foo_result # 将该任务的输出作为 foo_result 变量，
ignore_errors: True
除此之外，Ansible 可以通过命令行传递变量。在运行 Playbook 的时候，通过命令行可以传递一些变量供 Playbook 使用。例如：
$ ansible-playbook test.yml --extra-vars "hosts=www user=mageedu"
上述命令行传入了 hosts 与 user 变量可覆盖 Playbook 中的相关定义。
6.2、Ansible 中的条件
如果需要根据变量、facts 或此前任务的执行结果来作为某 task 执行与否的前提时要用到条件测试。只需在 tasks 后添加 when 子句即可使用条件测试；when 语句支持 Jinja2 表达式语法。when 语句中还可以使用 Jinja2 的大多 filter，例如要忽略此前某语句的错误并基于其结果（failed 或者 success）运行后面指定的语句，可使用类似如下形式：
---
- tasks:
- command: /bin/false
register: result # 注册器
ignore_errors: True # 忽略错误信息
- command: /bin/something
when: result|failed # 第一条命令失败时（result 为 failed 时），才执行第二条命令
- command: /bin/something_else
when: result|success #（result 为 success 时），才执行
- command: /bin/still/something_else
when: result|skipped # skipped：已经执行过跳过执行
此外，when 语句中还可以使用 facts 或 Playbook 中定义的变量。例如：
---
- tasks:
- name: "shutdown Red Hat flavored systems"
command: /sbin/shutdown -h now
when: ansible_os_family == "RedHat" #条件测试，ansible_os_family 来自 facts
6.3、Ansible 中的迭代
在迭代中只能使用 item 变量，变量引用为{{ }}两个大括号，变量两边有空格。当有需要重复性执行的任务时，可以使用迭代机制。其使用格式为将需要迭代的内容定义为 item 变量引用，并通过 with_items 语句来指明迭代的元素列表即可。例如：
---
- name: add several users
user: name={{ item }} state=present groups=wheel stae=present # 用户得存在且加入 wheel 组中
with_items:
- testuser1 # 分别使用 testuser1 替换 name={{item}} 中的 item 项
- testuser2
上面语句的功能等同于下面的语句：
--- - name: add user testuser1 user: name=testuser1 state=present groups=wheel - name: add user testuser2 user: name=testuser2 state=present groups=wheel
事实上，with_items 中可以使用元素还可为 hashes，例如：
---
- name: add several users
user: name={{ item.name }} state=present groups={{ item.groups }}
with_items:
- { name: 'testuser1', groups: 'wheel' }
- { name: 'testuser2', groups: 'root' }
迭代还支持列表，使用 with_flattened 语句。例如
---
- vars:
- packages_LNMP: # 定义列表
- [ 'nginx', 'mysql-server', 'php-fpm' ]
- tasks:
- name: Install LNMP
yum: name={{ item }} state=present
with_flattened:
- packages_LNMP # 再在迭代中引用它
6.4、Ansible 中的角色
Playbook 还可以构造非常重要的文档目录组织结构，也即被称为角色，一个带有角色的 Playbook 的结构如下
$ tree /root/lamp
/root/lamp/
├── hosts
├── group_vars
│ └── all
├── roles
│ ├── Apache
│ │ ├── defaults
│ │ │ └── main.yml
│ │ ├── files
│ │ │ └── httpd.conf
│ │ ├── handlers
│ │ │ └── main.yml
│ │ ├── meta
│ │ │ └── main.yml
│ │ ├── tasks
│ │ │ ├── delete_httpd.yml
│ │ │ └── main.yml
│ │ ├── templates
│ │ │ └── file.j2
│ │ └── vars
│ │ └── main.yml
│ ├── MariaDB
│ │ ├── tasks
│ │ │ └── main.yml
│ │ ...
│ └── PHP
│ ├── tasks
│ │ └── main.yml
│ ...
└── site.yml
以上显示了名为 lamp 的 Playbook 的目录结构。其中 site.yml 是该 Playbook 的主文件，，它里面的可能写法是
--- - name: install LAMP hosts: all user: root roles: - Apache # 调用 roles/Apache/tasks/main.yml - MariaDB # 调用 roles/MariaDB/tasks/main.yml - PHP # 调用 roles/PHP/tasks/main.yml
hosts 是该 Playbook 的主机文件，它只在该 Playbook 中有效；roles 目录中有三个角色 Apache、MariaDB 与 PHP。下面再来看看角色 Apache 中各个子目录或文件的作用：
- defaults：当前 role 中的各种变量，主要存放在 defaults/main.yml 中，也可以通过 include 包含更多。它具有最低级别，可被 vars 等处的变量覆盖；
- files：存放各种文件，Ansible 默认会到这里目录去找文件，对应 task 里面的 copy 或 script 等模块；
-
tasks：tasks：任务列表主要存放在 tasks/main.yml 中，也可以通过 include 包含更多的任务列表。可能的写法如下
--- - name: install httpd yum: name=httpd state=present - name: configuration Apache copy: src=httpd.conf dest=/etc/httpd/httpd.conf - name: configuration iptables template: src=file.js2 dest=/etc/sysconfig/iptables notify: # 会调用 roles/Apache/handlers/main.yml - restart httpd # 对应 name 为 restart httpd 和 restart iptables 的相应命令并执行， - restart iptables # 若之前 Apache 服务已安装，再次执行，不会触发 notify #- include: delete_httpd.yml
-
handlers：处理列表主要存放在 handlers/main.yml 中，也可以通过 include 包含更多的处理列表。可能的写法如下
--- - name: restart httpd service: name=httpd state=restarted - name: restart iptables service: name=iptables state=restarted
- templates：存放模板，对应 tasks 里面的模块 template，会自动在此目录中寻找 Jinja2 模板文件；
- vars：定义的变量主要存放在 vars/main.yml 中，也可以通过 include 包含更多。它只对当前 role 有作用；
-
meta：元信息主要存放在 meta/main.yml 中，也可以通过 include 包含更多。它的作用是定义 role 和 role 直接的依赖关系，标准格式如下
--- dependencies: - { role: Apache, port: 80 } - { role: mariadb, dbname: blarg, other_parameter: 12 }
group_vars 目录中存放供各个角色共同使用的 Ansible 全局变量，一般存放在 group_vars/all 文件中，也可以通过 include 包含更多。
运行带角色的 Playbook 方法与前面类似，只需要调用该 Playbook 的主文件。例如：
$ ansible-playbook site.yml
6.5、Ansible 中的 include
通过一个具体的 Playbook 的例子来说明 include 的用法
$ tree /root/sample
/root/sample/
├── hosts
├── roles
│ └── install_client
│ └── tasks
│ ├── db.yml
│ ├── app.yml
│ └── main.yml
└── site.yml
$ nano -w ~/sample/hosts
[db]
192.168.24.10
[app]
192.168.24.11
$ nano -w ~/sample/site.yml
---
- hosts: '{{ myhosts }}'
user: james
sudo: yes
sudo_user: root
roles:
- install_client
$ nano -w ~/sample/roles/install_client/tasks/main.yml # 本次测试的关键地方
---
- include: db.yml
when: "myhosts == 'db'"
- include: app.yml
when: "myhosts == 'app'"
$ nano -w ~/sample/roles/install_client/tasks/db.yml
---
- name: Touch db file
shell: touch /tmp/db.txt
$ nano -w ~/sample/roles/install_client/tasks/app.yml
---
- name: Touch app file
shell: touch /tmp/app.txt
6.6、Ansible 中的标签
当 Playbook 中有很多配置工作时，若中间的某个环节出错了，修改后重新执行的话，会发现有一大堆无关步骤可能隐藏错误。虽然 Ansible 提供了 retry 文件，但它却只是根据主机来判断是否重新执行，仍然不够方便；又或者，中间的某些步骤特别耗时，比如下载一个很大的数据包，每次执行特别浪费时间。注释掉 Playbook 中不需要的部分是绕过它中间环节的办法之一，但不是最最好的办法。实际上，Playbook 中有一个名为 tags 的关键字，它可以有效的解决 Playbook 的调试问题。tags 可以和一个 play（就是很多个 task）或者一个 task 进行捆绑；而 ansible-playbook 提供了 "--skip-tags" 和 "--tags" 来指明是跳过特定的 tags 还是执行特定的 tags。请看例子：
---
- name: test1.yml
hosts: test-agent
tasks:
- command: echo "test1"
tags:
- test1
- command: echo "test2"
tags:
- test2
- command: echo "test3"
tags:
- test3
执行
$ ansible-playbook test1.yml --tags="test1,test3"
则只会执行 test1 和 test3 的 echo 命令。执行
$ ansible-playbook test1.yml --skip-tags="test2"
同样只会执行 test1 和 test3 的 echo 命令。
