学习如何使 Ansible 自动对一系列台式机和笔记本应用配置。
Ansible 是一个令人惊讶的自动化的配置管理工具。其主要应用在服务器和云部署上，但在工作站上的应用（无论是台式机还是笔记本）却鲜少得到关注，这就是本系列所要关注的。
在这个系列的第一部分，我向你展示了 ansible-pull 命令的基本用法，我们创建了一个安装了少量包的剧本。它本身是没有多大的用处的，但是为后续的自动化做了准备。
在这篇文章中，将会达成闭环，而且在最后部分，我们将会有一个针对工作站自动配置的完整的工作解决方案。现在，我们将要设置 Ansible 的配置，这样未来将要做的改变将会自动的部署应用到我们的工作站上。现阶段，假设你已经完成了第一部分的工作。如果没有的话，当你完成的时候回到本文。你应该已经有一个包含第一篇文章中代码的 GitHub 库。我们将直接在之前创建的部分之上继续。
首先，因为我们要做的不仅仅是安装包文件，所以我们要做一些重新的组织工作。现在，我们已经有一个名为 local.yml 并包含以下内容的剧本：
- hosts: localhost
become:true
tasks:
- name:Install packages
apt: name={{item}}
with_items:
-htop
- mc
-tmux
如果我们仅仅想实现一个任务那么上面的配置就足够了。随着向我们的配置中不断的添加内容，这个文件将会变的相当的庞大和杂乱。最好能够根据不同类型的配置将我们的动作play分为独立的文件。为了达到这个要求，创建一个名为任务手册taskbook的东西，它和剧本playbook很像但内容更加的流线型。让我们在 Git 库中为任务手册创建一个目录。
mkdir tasks
local.yml 剧本中的代码可以很好地过渡为安装包文件的任务手册。让我们把这个文件移动到刚刚创建好的 task 目录中，并重新命名。
mvlocal.yml tasks/packages.yml
现在，我们编辑 packages.yml 文件将它进行大幅的瘦身，事实上，我们可以精简除了独立任务本身之外的所有内容。让我们把 packages.yml 编辑成如下的形式：
- name:Install packages
apt: name={{item}}
with_items:
-htop
- mc
-tmux
正如你所看到的，它使用同样的语法，但我们去掉了对这个任务无用没有必要的所有内容。现在我们有了一个专门安装包文件的任务手册。然而我们仍然需要一个名为 local.yml 的文件，因为执行 ansible-pull 命令时仍然会去找这个文件。所以我们将在我们库的根目录下（不是在 task 目录下）创建一个包含这些内容的全新文件：
- hosts: localhost
become:true
pre_tasks:
- name: update repositories
apt: update_cache=yes
changed_when:False
tasks:
-include: tasks/packages.yml
这个新的 local.yml 扮演的是导入我们的任务手册的索引的角色。我已经在这个文件中添加了一些你在这个系列中还没见到的内容。首先，在这个文件的开头处，我添加了 pre_tasks，这个任务的作用是在其他所有任务运行之前先运行某个任务。在这种情况下，我们给 Ansible 的命令是让它去更新我们的发行版的软件库的索引，下面的配置将执行这个任务要求：
apt: update_cache=yes
通常 apt 模块是用来安装包文件的，但我们也能够让它来更新软件库索引。这样做的目的是让我们的每个动作在 Ansible 运行的时候能够以最新的索引工作。这将确保我们在使用一个老旧的索引安装一个包的时候不会出现问题。因为 apt 模块仅仅在 Debian、Ubuntu 及它们的衍生发行版下工作。如果你运行的一个不同的发行版，你要使用特定于你的发行版的模块而不是 apt。如果你需要使用一个不同的模块请查看 Ansible 的相关文档。
下面这行也需要进一步解释：
changed_when:False
在某个任务中的这行阻止了 Ansible 去报告动作改变的结果，即使是它本身在系统中导致的一个改变。在这里，我们不会去在意库索引是否包含新的数据；它几乎总是会的，因为库总是在改变的。我们不会去在意 apt 库的改变，因为索引的改变是正常的过程。如果我们删除这行，我们将在过程报告的后面看到所有的变动，即使仅仅库的更新而已。最好忽略这类的改变。
接下来是常规任务的阶段，我们将创建好的任务手册导入。我们每次添加另一个任务手册的时候，要添加下面这一行：
tasks:
-include: tasks/packages.yml