迈克尔·德汉（Michael DeHaan）是创建Ansible的人。 温和地说，系统管理员，发行版和DevOps工程师经常做的许多事情都没有意思。 DeHaan希望这些人腾出时间来处理更多有趣的事情（在工作中或在办公室门外），并编写产品代码以节省管理员的时间。
更多的时间，更少的上班时间肾上腺素，更少的脚本和更少的错误。
顺便说一句，您可以改为阅读6月6日
在此处直播的内容，以完成本段的阅读。
如果您仍然继续阅读...
Ansible：持续集成和交付
Ansible是功能强大的开源自动化语言。 是的，这不仅对管理非常重要，而且对IT系统的部署和编排也非常有用。 Ansible最初是为有效解决各种自动化任务而创建的，并且是替代传统控件的简单通用基础，但最终在许多领域却非常有用。 例如，在确保连续集成和应用程序交付（CI / CD）期间零停机的同时。 通常，由于软件的广泛改进，各种软件包的使用以及每种特定配置所独有的许多技巧而解决了此问题。 Ansible最初是专门为此类业务流程设计的，并提供了“一体式”的交钥匙解决方案。
持续集成和应用交付（CI / CD）
一些常识。 在过去10年中开发软件系统的实践表明，与短周期（所谓的“迭代”或敏捷开发）相比，软件版本的长生命周期（级联开发模型）具有更高的开销。 一切都与心律不齐有关：当程序员刚刚开始使用新版本时，负责测试和部署的IT人员根本没有什么要做。 但是，版本与发行版越接近，IT专业人员就越忙，程序员也就越需要切换上下文，在处理错误和计划下一个版本之间进行切换。
此外，较长的周期增加了识别和消除软件错误与缺陷之间的间隔，这对于拥有数百万美元用户的大型Web系统而言尤其重要。 因此，软件行业正以“更快，更频繁地发布”的口号迅速采用敏捷方法，以便开发过程中的参与者可以更少地切换其工作环境，并更快地创建，调试和实施改进和创新。
质量控制自动化，通过测试开发TDD和其他相关技术进一步提高了新工作方法的有效性。 自动化在哪里？ 使齿轮旋转更快并将人的参与减少到严格必要的最低限度的技术在哪里？
例如，这里有Red Hat的Ansible and Ansible Tower，用于将IT系统编排为现代软件开发流程的一部分。
零停机时间
更加明显。 停机意味着损失利润和不满意的客户。 因此，在Web排队系统中，其用户分布在所有时区中，仅在非常严重的情况下才允许计划的关闭，其列表中没有明确包含更新应用程序的版本。 在企业环境中，情况相似，企业内部网络或会计系统的不可访问性极大地降低了员工的工作效率。 因此，任何流程自动化都应在不中断操作的情况下提供更新-换句话说，停机时间为零。
很有可能实现零停机时间，但是为此，我们需要适当的工具-例如提供高级，多层次和多阶段的编排，例如Ansible系统。
应用程序构建系统
持续交付（CD）从持续集成（CI）开始。 监视源代码存储库中的更改的系统，独立运行相应的测试，并随着每次代码更新自动构建（理想情况下测试）应用程序的新版本，例如Jenkins项目（jenkins.io）。
为了在成功组装新版本的应用程序后将接力棒传递到CD系统，CI系统构建子系统可以调用Ansible，以立即向执行单元或集成测试的人员提供此新版本。 特别是，Jenkins可以使用Tower在各种环境中部署程序集，并且可以在生产环境的基础上对测试或中间环境进行建模，从而极大地提高了整个软件生命周期的可预测性。 Ansible从自动化脚本的执行结果中返回的数据可以直接包含在Tower系统的Build Systems作业中。 实际上，Tower甚至允许您在“战斗”服务器上运行它们之前在中间环境中测试部署方案。
多层应用程序一一更新
CD系统必须能够协调多级应用程序的滚动更新过程。 得益于推式架构和多级多级业务流程的功能，Ansible可以通过逐级更新任何应用程序并在它们之间交换数据的方式来完成此任务。
为了实现一对一的更新，Ansible使用Play脚本，使您可以精确地指定目标主机组并分配必须在目标主机上执行的任务（角色）。 任务通常是声明特定的IT资源必须处于给定状态，例如，对于一个软件版本，必须安装某个软件包，对于另一个版本，则必须检查代码存储库。 通常，Web应用程序拓扑要求严格地对其进行更新，并且您仍然不能同时在所有计算机上更新应用程序和系统配置。
重新启动该服务后，它会在一段时间内不可用，并且替换应用程序的版本也不会立即发生。 因此，在更新系统之前，我们将其从平衡池中收回。 因此，您需要能够自动执行从池中连接和断开计算机的操作。 始终是关键词。 Ansible可以非常精确地控制连续更新的窗口大小。 好吧，此类更新的开发非常仔细地进行，并且如果在某个阶段发生故障，则该更新将被挂起，以免禁用其余的IT基础架构。
持续部署自动化脚本
除了以商业运行模式运行的服务具有CD功能外，您还可以自己组织自动化脚本的连续部署（Ansible Playbook指令集。不要停止阅读，在第二部分中将有Playbook的示例）。 这使系统管理员和开发人员可以使用源代码存储库管理脚本，在中间环境中测试这些脚本，并在成功侵入后自动将它们转移到生产环境中。 换句话说，使用脚本时，您将获得开发软件时惯用的中央代码存储库的所有方法和其他优点。
更改软件和系统配置是计划外停机的主要原因之一。 因此，除了自动测试之外，还有人为控制。 可以通过与
Gerrit之类的代码检查系统集成来进行组织，并且只有在经过负责同志的批准后才能应用更改。
备用更新和负载平衡系统
执行连续更新时，Ansible与负载平衡系统非常独立地工作。 因此，您可以简单地在Playbook脚本中编写一组主机的任何周期，例如“代表主机Y在系统X上执行此操作”，而Ansible将负责其余的工作。
Ansible与所有类型的负载均衡器都可以很好地交互，并且可以设置一个标志来临时断开主机的连接，以便在更新期间取消对主机的可用性监视。 简单的方案“关闭监视-从池中删除-更新所需的软件级别-返回池-打开监视”很容易实现具有零停机时间且没有错误警报的顺序更新。 所有这一切都在全自动模式下进行，无需操作员干预。
综合中级测试
Tower可以使用各种资源清单文件（清单），这使得在“战斗”服务器上运行它们之前，可以轻松地在中间环境中测试连续的更新方案。 为此，足以在测试环境中模拟生产环境，使用“ -i”参数运行Ansible并指出在运行脚本时应使用哪个库存文件-用于测试环境还是用于生产环境。 脚本本身不需要修改。
版本控制部署
有些人喜欢将应用程序与OS软件包（RPM，deb等）打包在一起，但通常，尤其对于Web应用程序，这种打包是不必要的。 因此，Ansible包括几个模块，用于直接从版本控制系统部署应用程序。 在Playbook脚本中，您可以为指定的标记或版本号编写与代码存储库的对帐，此后，Ansible将在所有目标服务器上检查此情况，并仅在需要更换版本时才激活下一步，从而消除了不必要的服务重启。
与监控工具集成
作为成熟的编排系统，Ansible在监视级别支持与基于APM的应用程序性能管理系统的集成。 例如，在部署或集成测试阶段，必须使用该应用程序安装或升级APM软件代理。 Ansible对此具有特殊作用，在安装和激活代理后，Ansible可以在APM监视堆栈中对其进行配置（如果尚未配置），以便应用程序管理者可以立即验证是否已安装新版本并且可以正常工作。 。
如果在生产环境中更新应用程序后出现问题，则监视工具可能会调用Ansible回滚到以前的版本。 当然，只有允许这种回滚。
活动通知
在CI / CD范例中，每个人都希望尽快收到事件通知。 Ansible提供了内置功能，包括电子邮件模块，以及与外部通知工具（例如即时通讯工具，社交网络或事件注册系统）的集成。
使用资源状态模型进行部署
Ansible的关键功能之一（使其成为部署应用程序的非常有用的工具）是在软件更新过程中常规使用资源状态模型，这种状态在管理系统配置中广受欢迎。 与传统的开源控件不同，Ansible不需要配备任何其他软件或特殊脚本来组织应用程序交付。
在Ansible中，您可以非常准确地注册和控制不同体系结构级别的事件顺序，从而可以将操作委派给其他系统，以及将资源模型的指令（例如“程序包X必须处于状态Y”）和传统的脚本命令（例如“运行脚本”）组合在一起.sh“）。
Ansible还可以轻松地对各种条件进行验证并根据结果进行决策。 在单个工具链中结合系统配置和应用程序部署的过程比具有多个专用工具的方案要有效得多，此外，还可以提高OS策略和应用程序的一致性。
部署测试
机会越多，责任越高。 连续交付流程的自动化极大地增加了在系统的所有节点上部署失败的配置的风险。 为了降低风险，Ansible建议在脚本中插入控制测试，如果出现问题，这将中断顺序更新。 为了测试各种条件，包括服务的运行状态，您可以使用Command或Script模块部署任意测试，甚至可以将这些测试创建为单独的Ansible模块。
故障模块可以随时中断主机上脚本的执行，这使您可以在顺序更新的早期阶段捕获故障。 例如，由于中间环境和生产环境之间的差异，后者会产生配置错误，从而禁用“战斗”服务器。 在这种情况下，可以在顺序更新的第一阶段在Playbooks脚本中注册紧急出口。 而且，如果您有100台服务器，并且连续更新窗口的大小为10，那么这样的紧急停止将使您有时间冷静地解决它，修复脚本并继续更新。
万一发生故障，Ansible将无法继续工作，将系统置于半配置状态，并会产生错误以引起操作员的注意，并告诉他更新主机在哪些主机上出现了错误以及每个平台上进行了多少更改。 Ansible具有模拟运行模式，当系统生成报告时，如果脚本在没有实际执行的情况下执行，则将进行哪些更改。
符合性检查
在某些环境中，只有在没有配置的情况下配置才会更改。 在这种环境下的任何变化都会被预先分析。 它使用“有保留”的连续交付系统。
当系统生成有关执行脚本时将进行哪些更改的报告时，Ansible具有模拟运行模式（通过“ --check”标志激活）。 在这种情况下，不会实际执行脚本，模拟运行不会捕获错误，但有助于更好地理解和分析建议的更改的细节和结果。
另一方面，即使持续部署新程序集，Ansible仍允许您更频繁地运行一致性检查，以赶上生产环境中某些情况由于人为干预而发生更改的时刻，并且必须通过运行相应的Ansible脚本进行修复（例如，更改）软件版本，调整权限等
自动驾驶仪部署
如果您生活在顺序软件更新的多层次，多阶段编排的世界中，而停机时间为零，则很有可能CI / CD完全由操作员执行（手动和部分自动化），并且就像在循环中一样要求所有过程参与者的协调行动。 Ansible及其独特的体系结构以及目标主机上不存在软件代理（提高安全性并消除了管理管理系统本身的需要）可以轻松描述并轻松实现复杂的部署过程自动化，即Ansible在此处实现了完全自动驾驶模式。
可以在
GitHub上找到Ansible自动化脚本的示例，现在我们将提供一个基础和一个示例，说明如何编写可在Ansible或Ansible Tower中运行的Playbook脚本。 连同
模块列表和
其他文档一起，她将帮助您学习如何创建自己的Playbook脚本。
什么是剧本？
Playbook脚本实质上是一组戏剧，被发送以在单个远程主机或一组主机上执行。 就像《宜家家具组装指南》一样：严格按照说明进行操作，并完全获得您在商店中看到的东西。 这就是脚本的工作方式。
模组
我们将创建一个Playbook，该Playbook将Web服务器安装在RHEL / CentOS 7主机上，并根据脚本中指定的模板在其上创建index.html文件。 此处显示的示例脚本可以完全使用并可以使用。 下面我们将看一个Playbook脚本示例，并展示如何使用这些模块。
作者（作者）
作者是创建将由模块执行的指令的人（通常与其他值一起使用：参数，位置等）。 这些模块将按照它们在Playbook脚本中的排列顺序在目标主机上执行（包括include'y和其他包含在其中的其他文件）。 主机的状态根据模块执行的结果而改变（或不改变），这些结果以Ansible和Tower输出的形式显示。
剧本脚本执行
首先，您需要了解一些有关运行Playbook脚本的知识。 Playbook是一种符号系统，可告知模块执行某些任务的必要性。 要成功启动Playbook，了解以下几点很重要：
1.目标系统（Target）由于Playbook脚本提供了有关模块的指令并与模块进行交互，因此Ansible相信您了解您要执行的操作并使其自动化。 这就是为什么我们说Playbook就像指令或指示一样：您告诉自动化元素如何配置任务。 但是同时，您自己需要很好地了解运行Playbook脚本的目标主机是如何工作的。
2.任务如果您需要在Playbook的某些部分中启动Web服务器，则需要了解如何完成此操作，以便知道为此使用哪个服务模块并按名称启动Web服务器。 如果Playbook安装了软件包，则您应该知道如何在目标主机上执行此操作。 您还应该至少在基本级别上了解所执行任务的本质。 您要安装的软件是否需要其他主机配置？ 是否有分支取决于参数的条件和值？ 如果在该过程中传递了任何变量，则必须确切了解什么以及原因。
剧本脚本示例以下Playbook脚本示例将帮助您了解刚刚阅读的内容。 其中的目标主机是RHEL / CentOS 7服务器，我们的脚本在该服务器上安装NGINX Web服务器，然后在默认的webroot目录中创建index.html文件。 , -.
*: Playbook Ansible Tower inventory .Playbooks YAML (---), :
Name : , Playbook.
Hosts : , Ansible.
Become : , , nginx ( ).
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true
缩进为前三行，即为
task ：指令，其后为其他缩进（根据YAML嵌套规则），列出了任务（播放）。 在此示例中，我们有两个任务，并且都使用Yum模块。 第一个任务添加一个epel-release存储库，以便您可以安装nginx。 epel出现在系统上之后，第二个任务将安装nginx软件包。
state ：指令意味着Ansible必须在执行任何其他操作之前检查目标主机的状态。 在我们的示例中，如果主机上已经存在一个存储库或nginx，则Ansible理解不必执行这两项任务，然后继续进行以下操作。
1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present
在nginx中默认使用的下载页面非常适合检查nginx是否已正确安装，但是您可能希望使用起始html文件来完成此操作。 在此示例中，为简单起见，索引文件模板位于Playbook所在的目录中。 目标只是nginix中的默认路径，未配置任何站点。
1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html
我们Playbook的最后一行仅用于验证nginx服务是否已成功启动（如果未成功，则启动它）。
1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started
整个Playbook脚本的长度与这篇文章的开始部分的长度相同：
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started
总结
剧本脚本是使用少量代码即可完成很多事情的简便方法。 在上面的示例中，我们使用了三个模块-yum，模板和服务，以在服务器上安装存储库和软件包，从本地模板创建文件，然后启动刚刚安装的服务。 同时，我们的Playbook脚本发布时间比此优惠要长一点！ 尽管我们在一台主机上运行它，但它也可以在数十台和数百台服务器上运行，为此，只需对其进行很小的更改。 此外，Tower允许您将Playbook脚本放入作业模板中，以在AWS云或公司数据中心的一组服务器上运行。
Ansible的体系结构功能以及与Jenkins等CI系统集成的能力不仅可以自动执行配置管理流程，还可以自动执行更多IT任务。 这就是为什么我们亲切地将Ansible称为集成的编排系统，而不仅仅是软件部署和配置管理工具。