Ansible与仅在Vagrant中运行Provisioning Bash Shell有何不同？

#1 楼

我从没使用过Ansible，但从几周以来，我试图弄清楚与壳牌相比，Ansible有什么好处-至少在我的情况下，这证明了它们运行的​​困扰很大的广告系列有效！经过多次失败的尝试（证明他们的文档未能回答最明显的问题之一），我想我终于明白了。检查系统是否符合所需状态； 2.与Ansible Tower集成的能力，Ansible Tower是一个付费系统，似乎包含监视功能。在某些重要情况下，例如在实现不可变服务器模式时，要点1可能不是很有用，因此优点列表很薄。正如文档所介绍的那样，shell脚本在少数几个可用模块很好涵盖的乐观情况下可能是明智的，但在一般情况下很小甚至是假设的。对于熟练的shell编程人员而言，这些好处很可能会与其他方面的权衡取舍。

，但是我的结论也许只能证明，介绍材料在展示Java的实际优势方面有多糟糕。该软件！

现在，我建议观看介绍视频，并以潜在的新用户身份通过​​Ansible的介绍材料随机访问，让我们将其与熟练的Shell程序员在合理的时间内所产生的内容进行比较。

快速入门视频：

有一个快速入门视频。它始于一个页面，声称……好吧，这些并不是真正的声明，而是项目符号列表，这是一种人工制品，通常用于暂停演示中的批判性判断（因为未显示逻辑，因此不能批评！） /> 1。 Ansible很简单：

1.1可读的自动化–规格是技术文档，怎么可能

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

比在shell脚本中找到相应的yum调用更容易阅读？此外，任何与AppleScript接触的人在阅读“可读性强的自动化工具”时都会死于笑。

1.2不需要特殊的编码技能–如果不编写正式规范，这是什么编码？ Ansible具有条件和变量，因此，它不怎么编码？为什么我需要我无法编程的东西，从那以后就变得僵硬了？该声明很不正确！ br />1.4快速提高生产力–熟练的shell程序员现在可以高效地工作。此反论点与初始论点一样严重。

2。 Ansible功能强大

一个流行的推销员推销手工艺品的方法是欺骗人们，使他们相信他们将获得这些手工艺品的“力量”。汽车或等渗饮料广告的历史应该提供令人信服的示例列表。

这里Ansible可以进行“应用程序部署” –但是shell脚本当然可以进行“配置管理”，但这仅是陈述该工具的目的，而不是功能，以及“工作流程编排”看起来有些自命不凡，但本文档中没有任何示例超出了GNU Parallel的能力。 Ansible是无代理的。

他们用三种不同的方式填写该专栏，即只需要ssh，众所周知，ssh是一个守护进程，与遍布配置管理世界的这些代理无关！

视频的其余部分

视频的其余部分介绍了清单，清单是资源（例如服务器）的静态列表，并演示了如何在三台服务器上同时部署Apache。这确实与我的工作方式不匹配，在我的工作方式中资源是高度动态的，并且可以由我的云提供程序提供的命令行工具枚举，并且可以使用管道|运算符由Shell函数使用。另外，我不会同时在三台服务器上部署Apache，而是构建一个主实例映像，然后使用该映像启动三个实例，它们是另一个实例的精确副本。因此，论证的“编排”部分看起来不太相关。某些Ansible模块支持。 （还提供了其他流行的云计算提供程序。）： />

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

或JSON版本

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --image-id …   
}

两个版本本质上是相同的，有效载荷的大部分是初始化值的枚举

随机文档步骤2：持续交付和滚动升级

本指南的最大部分没有显示任何真正有趣的功能：它引入了变量（IIRC，shell脚本也有变量）！，还有一个处理mysql的Ansible模块，因此，如果不是在搜索“我如何在XY上创建具有特权的mysql用户”，而以类似
/>

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"  
}

provision_a_set_of_instances__json()
{
  cat <<EOF
{
    "ImageId": … 
}
EOF
}

搜索“如何在ansible中创建具有XY特权的mysql用户”，并以

结束。区别仍然可能不是很有意义。在该页面上，我们还发现Ansible具有模板元编程语言。

create_application_db_user()
{
  mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
}

当我看到这个时，我碰巧真的在我的舒适区。这种用于声明性语言的简单元编程与BSD Makefile完全一样，是一种理论范例！我恰好进行了广泛的编程该摘录向我们展示了使用YAML文件的承诺被打破了（例如，我无法通过YAML解析器运行我的剧本）。它还向我们表明，Ansible必须讨论评估顺序的微妙技巧：我们必须确定变量是在语言的“声明部分”还是在语言的“命令性”元部分扩展的。在这里，shell编程更简单，除了显式eval或外部脚本采购之外，没有元编程。假设的等效外壳摘录为

与Ansible变体相比，其复杂性是可以忍受的：它仅使用该语言的普通，常规，无聊的构造。

随机文档步骤3：测试策略

最后，我们遇到了Ansible的第一个真正有趣的功能：“ Ansible资源是期望状态的模型。因此，不必测试服务是否已启动，软件包是否已安装或其他类似的事情。 Ansible是将确保这些事情在声明上是正确的系统。而是在您的剧本中声明这些内容。”现在开始变得有点有趣了，但是：除了一些可用模块容易实现的标准情况外，我还必须自己提供实现测试的位，这将
在实现不可变服务器模式的情况下，检查安装的一致性可能不是很重要：通常所有运行的系统都是从主映像（实例映像或docker映像）生成的例如），并且从不更新-而是由新的替换。

未解决的问题：可维护性

Ansible的介绍性材料忽略了可维护性的问题。在基本上没有类型系统的情况下，shell脚本可以轻松实现JavaScript，Lisp或Python的可维护性：只有借助广泛的自动化测试套件或至少允许轻松进行交互式测试的设计，才能成功实现大量重构。话虽如此，尽管Shell脚本是系统配置和维护的通用语言，但几乎每种编程语言都具有与Shell的接口。因此，通过使用高级语言将外壳配置位的各个位粘合在一起来利用高级语言的可维护性优势是完全可行的。对于OCaml，我写了Rashell，它本质上为子流程提供了一种常见的交互模式，这使得配置脚本到OCaml的翻译基本上是微不足道的。以及元编程功能的存在，使情况基本上与shell脚本一样糟糕，其缺点是，如何为Ansible编写单元测试并不明显，而引入ad-hoc的论点是级别的语言无法被模仿。

配置步骤的等效性

Ansible的文档提请注意编写幂等配置步骤的必要性。更准确地说，应该编写配置步骤，以便可以将步骤序列a b a简化为a b，即我们不需要重复配置步骤。这比幂等要强。由于Ansible允许剧本使用任意的shell命令，因此Ansible本身无法保证会遵守此更严格的条件。这仅依赖于程序员的纪律，并且在编写配置脚本时这种幂等性变化的重要性当然不是什么新鲜事。


圣经后。由于此答案似乎相对受欢迎，因此我修复了一些令人尴尬的语法错误和错别字。由于生活的转折，我还不得不在工作中使用Ansible两年。总的来说，我的经验证实了我在这里的预见，并且我几乎无法想到这样一种情况，shell脚本实际上会被Ansible超越。在某些方面，Ansible比shell脚本更糟糕。至少外壳具有功能，可以模拟这些功能，可以测试其中的全部功能，因此总体而言，外壳具有比Ansible更好的软件工程功能。在Shell脚本中，还可以处理数据，并且awk可以表达SQL所能执行的所有操作，这在编程配置时非常重要–我们在此使用的信息本质上不是分层的，因此需要提取重写。 Ansible很难提取和重写数据！必须在剧本步骤级别上混合使用YAM1模板和词典成员级别上的Jinja方言来表示处理方式……这麻烦，丑陋，难写，难以测试且记录不佳（我经常查看Jinja过滤器实现！）。

#2 楼

当您这样说时，即使Ansible具有某些固有的优势，使用其熟悉的工具（在这种情况下为Shell脚本）的好处也必须被抵消。我认为没有一个明确的答案。
访问可重用的片段（即剧本）以获取行业流行的服务。
通过重试，滚动逻辑等可靠地管理远程执行。用他们所知道的知识。

毕竟，您可以在BASH中实现“守卫”。您可以在那里找到许多BASH现有工作来解决各种服务器配置任务（实际上，任何Dockerfile都有90％bash安装代码）。您可以非常接近Ansible / Salt / Chef-Zero所提供的功能，而无需实际将整个现有解决方案移植到那些工具中。 ，并抛出良好的已建立脚本以支持更健壮的解决方案。寻找具有Ansible经验的人比寻找具有您自己的特定脚本CM工具经验的人要容易得多。严格来说，这不是技术上的考虑，而是文化上的考虑。您想成为发明自己的Ansible的怪异组织，还是想成为找到合适工作工具的合理组织？这些决定会影响您吸引人才的能力。

#3 楼

上面的答案涵盖了其中的一部分，但是却忽略了重要的要素之一：收敛设计。我前一阵子在https://coderanger.net/thinking/在Chef的上下文中写了一些关于这个的单词，但是简短的版本是bash脚本是一组指令，而Ansible剧本（或Chef的食谱，Salt）状态等）是对所需状态的描述。通过记录所需的状态而不是要达到的状态，您可以应对更多的起始状态。这是CFEngine早已概述的Promise Theory的核心，并且我们（配置管理工具）此后一直在复制设计。 bash代码说明了如何做某事。

#4 楼

值得一提的是，在远程主机上运行ansible剧本的问题也会减少。因为这是运行ansible的主要原因。使用shell脚本编写时，您仍然需要一种将scp's脚本编写到远程主机的方法。

#5 楼

到了2019年，我花了几天时间学习了ansible的学习曲线，这是绝对的事实：
Ansible并不值得麻烦。不能在Windows上运行，并且YAML配置和误导性错误消息的组合会使您流血。这似乎是故意的，我是认真的。显然，这是redhat sysadmins沮丧的开发人员端项目的产物。可能是时髦人士。

如果您除了配置之外不需要任何其他功能，那么您只能在一个特定的操作系统上进行配置。出于可惜的缘故，编写一个不错的shell.script。用于配置图形设置。
不知道吗？您应该坚持使用Windows ...也许我会交配..快乐的VI-ing。

使用Docker。优先于任何事物。 Docker非常简单，功能强大。

但是，如果您绝对必须提供预先存在的锡，该怎么办？
真正的替代品是什么？
但是我会向你保证，除非ansible变得更好，否则很快就会出现。因为无论狂热者多么努力地推销它，并原谅它是失败的……努力中的十分之五。