原文：https://insights.sei.cmu.edu/devops/2015/03/devops-technologies-fabric-or-ansible.html
部署代码就跟工作流本身一样古老，有许多业务与部署过程相关，包括计算资源需求，设计一个生成系统和配置产品服务器，发布代码等，在这篇博文中我聚焦业务配置远程服务器安装包和软件去执行你的代码。
这个业务部署方案有许多不同的组件并且互相竞争的技术，例如：Chef、Puppet、Fabric、Ansible、Salt 和 Foreman，这只是在你通往 DevOps 之路中听到过的其中几个而已，所有这些技术都是免费提供，让你的脚本提交到你的存储库，然后完成工作。
更具体来说，这篇文章更多的是对 Fabric 和 Ansible 的探讨， 如果想了解更多其它 infrastructure-as-code 解决方案，可以去看 Joe Yankel’s blog post on Docker 或 my post on Vagrant。
Fabric 和 Ansible 区别之一是 Fabric 会在几分钟内给你要的结果，而 Ansible 则需要花更多的努力去理解如何使用。Ansible 通常非常强大，因为它提供了更深和更复杂的语义多层架构模型，比如这些阵列的 web 和数据库主机。从操作者看，Fabric 有更多的文档和基本的 API，都是使用 python 编写的，而 Ansible 通过定制 YAML 可以提供丰富的行为（后面会讨论），我们将在这篇文章中展示它们的使用例子。
Fabric 和 Ansible 在大多数情况下是通过 SSH 去完成它们的工作，Fabric 利用 SSH 执行简单的命令，Ansible 推动模块到远程主机，然后执行这些模块，类似Chef,两个工具都用语义封装了这些命令完去成基本任务，例如文件拷贝，重启服务器和安装在软件包。他们最大的不同是功能和复杂性。
这是Fabric在远程主机安装Apache的代码：
fabfile.py
fromfabric.api import run,env
env.hosts = ['foo.bang.whiz.com']
def install_apache():
run('apt-get install apache2',with_sudo=True)
脚本执行：
$ fab install_apache
很明显我们是用 python 写的， 这样提供给运维人员所有特性的语义， 在这个 Fabric 例子，我们创建了一个任务 task：install_apache，调用 run()，然后执行我们想执行的命令，Fabric 从我们设置的环境变量中读取主机名。
我们再看，用 Ansible 脚本完成跟 Fabric 上面一样的工作，用 “playbook” 和 “role”
hosts
foo.bang.whiz.com
roles/web/tasks/main.yml
name: install Apache
apt: name=apache2 state=present
site.yml
name: install Apache
hosts: foo.bang.whiz.com
roles:
- web
脚本执行：
$ ansible-playbook deploy.yml
playbook 的入口点是 site.yml。这个脚本声明了 plays，和每个主机每个角色应该怎么被应用。每个 plays，开始于一个名称参数，声明目标主机和角色使用。定义的角色本身是包含更多的 YAML 的子文件夹结构，定义了什么模块执行哪些参数的作用为那些角色。在这个例子中，我们定义了一个 web 角色包含 apt 模块。
对角色有一个微妙的区别：主机没有角色。相反，主机根据 playbook 装饰角色。一个 playbook 可以有多个，多个角色可以应用到一个主机，角色可以有多个任务文件和任务可以有多个模块。此外，我们甚至可以为主机和定义组织把这些组到更别组。
这是更复杂的 Ansible 例子：
hosts
[webservers]
foo01.bang.whiz.com
foo02.bang.whiz.com
[dbservers]
db.bang.whiz.com
site.yml
name: configure a webserver
hosts: webservers
roles:
- web
name: configure a database server
hosts: dbservers
roles:
- db
roles/web/tasks/main.yml
name: install apache
apt: name=apache2 state=present
roles/db/tasks/main.yml
name: install mysql
apt: name=mysql-server state=present
All the elements in this example areexecuted with:
$ ansible-playbook site.yml
首先，注意我们加了更多的主机和组在 host 文件中，其次我们加了第二个 play。
一个不错的功能，我们没有看到通过看 playbook 和角色是 Ansible 收集信息在运行时的所有主机，只有应用变化需要获得所需的状态。换句话说，如果没坏，就不要修复它。同时，注意这是一个精简 Ansible 的例子，并且不体现它的许多其他功能，如在一个模块中定义和遍历列表调用，使用元数据等主机在运行时动态 IP 地址和操作系统版本，和链接角色作为依赖项。我强烈看 Ansible 快速启动视频。
现在，回到 Fabric，这是大致相同的结果用 Fabric 工具：
from fabric.api import env,hosts,run,execute
env.roledefs['webservers'] = ['foo01.bang.whiz.com', 'foo02.bang.whiz.com']
env.roledefs['dbservers'] = ['db.bang.whiz.com']
@roles('webservers')
def install_apache():
run('apt-get install apache2', with_sudo=True)
@roles('dbservers')
def install_mysql():
run('apt-get install mysql-server', with_sudo=True)
def deploy():
execute(install_apache)
execute(install_mysql)
Note that we arecontained to a single file, although the raw size of our configuration in bytesis roughly the same as in Ansible. On a more technical level, Fabric’ssemantics are much “thinner” than Ansible’s. For example, when wetarget a host with a role in Ansible, we are effectively asking it to check thehost for a multitude of data points and evaluate its state before running anycommands. Fabric is more of a what-you-see-is-what-you-get implementation, asdemonstrated by its API: “run”, “put”, “reboot”,and “cd” are common operations. A consequence of this simplicity is alack of the rich features that we see in Ansible, such as its ability to pull inhost information dynamically and use that information during execution.
Here is a simple example of usingAnsible’s dynamic host information:
roles/web/tasks/main.yml
name: install apache
apt: name=apache2 state=present
name: deploy apache configuration
template: src=apache.conf.j2 dest=/etc/apache2/sites-enabled/apache.conf
roles/web/templates/apache.conf.j2
<VirtualHost {{ ansible_default_ipv4.address }}:80>
...
</VirtualHost>
Here we see a new module being used:“template”. By convention, Ansible will look in the role’s"templates" folder for the file supplied to the "src"attribute and deploy it to the location supplied to the “dest” attribute.But the magic here is that prior to application of this role, Ansible gathers alist of what are actually called “facts” from the host and providesthat data to us in the scope of our YAML. In this example, it means we cansupply our Apache configuration file with the IP address of whatever host towhich the role is applied. Getting this kind of behavior with Fabric is workleft to the operator.
One last topic is how these toolshandle authentication.
Ansible’s answer to this is in theplaybook:
site.yml
- hosts: webservers
remote_user: alice
sudo: yes # optional
sudo_user: bob # optional
With Fabric, we simply set theenvironment variable:
from fabric.api import env
env.user = 'alice'
Both Fabric and Ansible can use yourpublic key, as well to remove the need to enter passwords.
This blog posting provided a lightintroduction to two fairly powerful solutions to the infrastructure-as-codeproblem. By this point, you may have already decided which direction you wantto go, but it’s more likely that you have more questions than you started with.There are many features of both Fabric and Ansible that are best left to theirrespective and official documentation, but hopefully this post helped to youget started.
Every two weeks, the SEI will publisha new blog post offering guidelines and practical advice for organizationsseeking to adopt DevOps in practice. We welcome your feedback on this series,as well as suggestions for future content. Please leave feedback in thecomments section below.
