我使用 Ansible 来自动部署站点 (LinuxJobs.fr、Journal du hacker) 与应用 (Feed2toot、Feed2tweet)。在本文中将会讲述我是如何配置以实现在本地测试 Ansbile playbook的。
为何要测试 Ansible
我需要一种简单而迅速的方法来在我的本地笔记本上测试 Ansible 的部署情况，尤其在刚开始写一个新的时候，因为直接部署到生产服务器上不仅特别慢而且风险还很大。
我使用 Vagrant 来将部署到 VirtualBox 虚拟机上而不是部署到远程服务器。这使得修改的结果很快就能看到，以实现快速迭代和修正。
责任声明：我并不是专业程序员。我只是描述一种我觉得适合我的，即简单又有效的用来测试 Ansible 的解决方案，但可能还有其他更好的方法。
我的流程
开始写新的 Ansible
启动一台新的虚拟机（VM）并使用 Vagrantt 将部署到这台虚拟机中
修复或应用中的错误
重新在虚拟机上部署
如果还有问题，回到第三步。否则销毁这台虚拟机，重新创建新虚拟机然后测试一次全新部署
若没有问题出现，则标记你的 Ansible 版本，可以在生产环境上发布产品了
你需要哪些东西
首先，你需要 Virtualbox。若你使用的是 Debian 发行版，这个链接 描述了安装的方法，可以从 Debian 仓库中安装，也可以通过官网来安装。
其次，你需要 Vagrant。为什么要 Vagrant？因为它是介于开发环境和虚拟机之间的中间件，它允许通过编程的方式重复操作，而且可以很方便地将你的部署环境与虚拟机连接起来。通过下面命令可以安装 Vagrant：
# apt install vagrant
设置 Vagrant
Vagrant 的一切信息都存放在 Vagrantfile 文件中。这是我的内容：
Vagrant.require_version">= 2.0.0"
Vagrant.configure(1) do config
config.vm.box ="debian/stretch64"
config.vm.provision"shell", inline:"apt install --yes git python3-pip"
config.vm.provision"ansible" do ansible
ansible.verbose ="v"
ansible.playbook ="site.yml"
ansible.vault_password_file ="vault_password_file"
end
end
第一行指明了需要用哪个版本的 Vagrant 来执行 Vagrantfile。
文件中的第一个循环，你要定义为多少台虚拟机执行下面的操作（这里为 1）。
第三行指定了用来创建虚拟机的官方 Vagrant 镜像。
第四行非常重要：有一些需要的应用没有安装到虚拟机中。这里我们用 apt 安装 git 和 python3-pip。
下一行指明了 Ansible 配置开始的地方
第六行说明我们想要 Ansible 输出详细信息。
第七行，我们定义了 Ansible 的入口。
第八行，若你使用 Ansible Vault 加密了一些文件，在这里指定这些文件。
当 Vagrant 启动 Ansible 时，类似于执行这样的操作：
$ ansible-playbook --inventory-file=/home/me/ansible/test-ansible-playbook/.vagrant/provisioners/ansible/inventory -v --vault-password-file=vault_password_file site.yml
执行 Vagrant
写好 Vagrantfile 后，就可以启动虚拟机了。只需要简单地运行下面命令：
$ vagrant up
这个操作会很慢，因为它会启动虚拟机，安装 Vagrantfile 中定义的附加软件，最终应用你的。你不要太频繁地使用这条命令。
Ok，现在你可以快速迭代了。在做出修改后，可以通过下面命令来快速测试你的部署：
$ vagrant provision
Ansible 搞定后，通常要经过多次迭代（至少我是这样的），你应该一个全新安装的虚拟机上再测试一次，因为你在迭代的过程中可能会对虚拟机造成修改从而引发意料之外的结果。
使用下面命令进行全新测试：
$ vagrant destroy && vagrant up
这又是一个很慢的操作。你应该在 Ansible 差不多完成了的情况下才这样做。在全新虚拟机上测试部署之后，就可以发布到生产上去了。至少准备要充分不少了吧 :p
有什么改进意见？请告诉我
本文中描述的配置对我自己来说很有用。我可以做到快速迭代（尤其在编写新的的时候），除了外，对我的最新应用，尚未准备好部署到生产环境上的应用也很有帮助。直接部署到远程服务器上对我的生产服务来说不仅缓慢而且很危险。
我本也可以使用持续集成（CI）服务器，但这不是本文的主题。如前所述，本文的目的是在编写新的 Ansible 之初尽可能的快速迭代。
在编写 Ansible 之初就提交，推送到你的 Git 仓库然后等待 CI 测试的执行结果，这有点太过了，因为这个时期的错误总是很多，你需要一一个地去调试。我觉得 CI 在编写 Ansible 的后期会有用的多，尤其当多个人同时对它进行修改而且你有一整套代码质量规范要遵守的时候。不过，这只是我自己的观念，还有待讨论，再重申一遍，我不是个专业的程序员。
如果你有更好的测试 Ansible 的方案或者能对这里描述的方法做出一些改进，请告诉我。你可以把它写到留言框中或者通过社交网络联系我，我会很高兴的。