ansible剧本如何写_我学过的3课：写Ansible剧本

ansible剧本如何写

自2013年以来，我就一直使用Ansible，并且至今仍保留着一些原始剧本。它们随着Ansible从1.4版发展到当前版本（在撰写本文时为2.9版）。

一路走来，随着Ansible从拥有数十个模块发展到如今成千上万个模块，我已经学到了很多有关如何确保我的剧本随着系统的发展而可维护和可扩展的知识。即使对于简单的项目（例如我用来管理自己的笔记本电脑的剧本），它也可以避免常见的陷阱，并做出决策，使您对未来充满感恩而不是后悔。

这次体验的三个主要收获是：

保持井井有条
尽早测试
简化，优化

我所学的每堂课的重要性也按此顺序排列。尝试优化已经组装不良的东西（第3点）（第1点）是没有用的。每个步骤都基于上述步骤，因此我将指导您完成每个步骤。

保持井井有条

至少，您应该将Ansible剧本存储在Git存储库中 。这可以帮助很多事情：

一旦有了已知的工作状态，就可以提交工作（理想情况下，带有标记主要版本的标签，例如第一个稳定版本为1.0.0，升级或重写为2.0.0）。
如有必要，您始终可以将更改退回到先前的已知工作状态（例如，使用git reset或git checkout <tag> ）。
可以在分支机构中进行大规模更改（例如，添加功能或进行重大升级），因此您仍然可以维护现有的剧本，并有足够的时间进行重大更改。

在Git中存储剧本还有助于第二种重要的组织技术： 从构建服务器运行您的剧本 。

无论您使用Ansible Tower ， Jenkins还是其他构建系统，使用中央界面执行剧本都可以确保一致性和稳定性-您不必冒险让一位管理员以某种方式运行剧本（例如，使用错误的角色版本或旧的结帐），然后其他人以另一种方式运行它，从而破坏了服务器。

它也有帮助，因为它迫使您确保将所有剧本的资源封装在剧本的存储库和构建配置中。理想情况下，整个构建（包括作业配置）将被捕获在存储库中（例如，通过使用Jenkinsfile或其等效文件）。

组织的另一个重要方面是文件 ; 至少，我在每个剧本资料库中都有一个自述文件，内容如下：

剧本的目的
链接到相关资源（CI构建状态，外部文档，问题跟踪，主要联系人）
本地测试和开发说明

即使您通过构建服务器使剧本自动化，重要的是要有透彻且正确的文档，以其他方式（例如，在测试环境中本地）运行剧本。我想确保我的项目很容易上手-不仅对于最终可能需要与他们合作的其他人，还有我自己！在运行剧本时，我经常会忘记细微差别或依赖性，而自述文件是概述任何特性的理想场所。

最后，Ansible任务本身的结构很重要，我想通过拥有小的可读任务文件以及将相关任务集提取为Ansible角色来确保自己具有可维护的结构。

include_tasks包括那些文件。如果我发现一组独立运行的任务，并且可以分解为自己的Ansible角色，则将继续提取这些任务以及相关的处理程序，变量和模板。

使用角色是加强Ansible剧本维护的最佳方法；我经常必须在许多（如果不是大多数）剧本中执行类似的任务，例如管理用户帐户或安装和配置Web服务器或数据库。将这些任务抽象为Ansible角色意味着我可以维护一组在许多剧本中使用的任务，并在需要时提供变量以提供灵活性。

如果您能够使Ansible角色成为通用角色并为代码提供开放源代码许可，那么也可以通过Ansible Galaxy将其角色贡献回社区。我为Galaxy贡献了一百多个角色，并且由于成千上万的其他剧本（除我本人以外）依赖于它们，并且如果角色中存在错误，它们也会中断，从而使它们变得更好。

关于角色的最后一点说明：如果您选择使用外部角色（来自Galaxy或私有Git存储库），建议将角色提交到存储库中（而不是将其添加到.gitignore文件中，并在每次运行时下载角色）您的剧本），因为我希望避免每次运行剧本时都依赖于Ansible Galaxy的下载。您仍应使用requirements.yml文件定义角色依赖关系并为角色定义特定版本，以便可以选择何时升级依赖关系。

尽早测试

Ansible允许您将基础结构定义为代码。与任何软件一样，必须能够验证所编写的代码是否符合您的期望。

像任何软件一样，最好测试一下Ansible剧本。当我考虑为自己构建的任何单个Ansible项目进行测试时，都会想到我可以使用的一系列CI测试选项，从最容易实现到最难实现：

yamllint
ansible-playbook --syntax-check
ansible-lint
分子测试（整合测试）
ansible-playbook --check （针对生产进行测试）
建立并行基础架构

前三个选项（在剧本上添加和运行语法检查）基本上是免费的；它们运行非常快，可以帮助您避免剧本的任务结构和格式设置中最常见的问题。

它们提供了一些价值，但是除非剧本非常简单，否则我不仅仅喜欢基本的功能，而且还使用Molecule运行测试。我通常使用Molecule的内置Docker集成来针对本地Docker实例运行我的剧本，该实例运行与生产服务器相同的基本OS。对于我在不同Linux发行版上运行的某些角色（例如CentOS和Debian），我为每个发行版运行一次Molecule测试手册，有时还会针对更复杂的角色使用额外的测试场景。

如果您有兴趣学习如何使用Molecule来测试角色，几年前，我写了一篇有关该主题的博客文章，名为“ 使用Molecule测试您的Ansible角色” 。测试完整剧本的过程相似，并且在两种情况下，测试都可以在大多数CI环境中运行（例如，我的geerlingguy.apache角色通过Travis CI运行一组分子测试）。

最后两个测试选项，即在--check模式下运行剧本或构建并行生产基础架构，需要进行更多的设置工作，并且通常超出了有效测试过程所必需的范围。但是，在剧本管理着对业务收入至关重要的服务器的情况下，则很有必要。

在运行测试以及定期检查或更新您的剧本时，还需要注意一些其他事项：

确保跟踪（并修复）在Ansible输出中看到的所有DEPRECATION WARNING 。通常，在警告导致最新的Ansible版本失败之前，您需要等待一到两年，因此，您可以越早更新剧本代码，就越好。
每个Ansible版本都有一个移植指南（），当您从一个版本更新到另一个版本时，该指南非常有用。
如果您在使用诸如command类的模块时在剧本输出中看到烦人的WARN消息，并且知道可以放心地忽略它们，则可以添加warn: no任务中的args下的warn: no 。最好抑制这些警告，以便一眼就能注意到更多可操作的警告（例如弃用警告）。

最后，我想确保我的CI环境始终运行最新的Ansible版本（并且不锁定到我知道可与我的剧本一起使用的特定版本），因为我知道剧本是否会在新版本发布后立即中断。我的构建服务器被锁定到特定的Ansible版本中，该版本可能比最新版本落后一两个版本，因此这使我有时间确保在将构建服务器升级到最新版本之前，我能修复在CI测试中发现的所有新问题。。

简化，优化

“ YAML不是一种编程语言。”
—杰夫·吉林

剧本的简单性使维护和将来的更改变得更加容易。有时我会看一个剧本并困惑的是，发生了什么事，因为有多个when ，并until有一堆的Python的条件与神社滤波器混合。

如果我开始看到不止一个或两个链式过滤器或Python方法调用（尤其是与正则表达式有关的任何事情），我将其视为将所需功能重写为Ansible模块的主要候选人。该模块可以用Python维护并独立测试，并且将其更严格地维护为严格的Python代码，而不是将所有Python内联与YAML任务定义混合在一起。

所以我的第一点是：尽可能坚持使用Ansible的模块和简单的任务定义。尝试尽可能使用Jinja过滤器，并避免一次在一个变量上链接多个一两个过滤器。如果您有很多复杂的嵌入式Python或Jinja，是时候考虑将其重构为自定义Ansible模块了。

我看到人们经常做的另一件事，尤其是在第一次建立角色时，是使用复杂的dict变量，而单独的“扁平”变量可能更灵活。

例如，与其在一个巨型词典中扮演许多选项的apache角色，不如：

apache :

        startservers : 2

        maxclients : 2

并考虑使用单独的平面变量：

apache_startservers : 2

        apache_maxclients : 2

原因很简单：使用平面变量可使剧本轻松覆盖一个特定值，而不必重新定义整个字典。当角色中有数十个（或在极少数情况下为数百个）默认变量时，这特别有用。

一旦剧本和角色代码看起来不错，就该开始考虑优化了。

我首先要看的几件事是：

我可以禁用gather_facts吗？并非每个剧本都需要所有事实，并且每次运行，每个服务器上都会增加一些开销。
我可以增加Ansible用途的forks数量吗？默认值为5，但是如果我有50台服务器，我可以一次在20台或25台上运行以大大减少Ansible在所有服务器上运行剧本的时间吗？
在CI中，我可以并行化测试方案吗？如果我可以一次开始所有测试，则不必先运行一个测试，然后再运行下一个测试，这将使我的CI测试周期更快。如果CI变慢，您将倾向于忽略它，或者不等到测试运行完成，因此确保测试周期短很重要。

当我浏览角色或剧本中的任务时，我还会发现某些模块常见的明显性能问题：

使用package （或apt ， yum ， dnf等）时，如果要管理多个软件包，则应将列表直接传递给name参数，而不要通过with_items或loop传递-这样，Ansible可以在一次性完成整个列表，而不是逐个打包。
使用copy ，正在复制多少个文件？如果只有一个文件或什至几十个文件，可能没问题，但是如果要复制数百或数千个文件，则copy模块会非常慢（最好使用synchronize模块，或者使用其他策略复制文件） tarball并将其在服务器上展开）。
如果在循环中使用lineinfile ，则改为使用template并一次控制整个文件可能会更有效率（有时更易于维护）。

一旦我获得了大部分低调的成果，我就喜欢介绍我的剧本，而Ansible为此提供了一些内置工具。您可以通过在ansible.cfg defaults下设置callback_whitelist选项，配置额外的回调插件来衡量角色和任务的性能：

[ defaults ] 

        callback_whitelist = profile_roles, profile_tasks, timer

现在，当您运行剧本时，您将获得最慢的角色和任务的摘要：

Monday 10 September       22:31:08 -0500 (0:00:00.851)       0:01:08.824 ******

        ===============================================================================

        geerlingguy.docker ------------------------------------------------------ 9.65s

        geerlingguy.security ---------------------------------------------------- 9.33s

        geerlingguy.nginx ------------------------------------------------------- 6.65s

        geerlingguy.firewall ---------------------------------------------------- 5.39s

        geerlingguy.munin-node -------------------------------------------------- 4.51s

        copy -------------------------------------------------------------------- 4.34s

        geerlingguy.backup ------------------------------------------------------ 4.14s

        geerlingguy.htpasswd ---------------------------------------------------- 4.13s

        geerlingguy.ntp --------------------------------------------------------- 3.94s

        geerlingguy.swap -------------------------------------------------------- 2.71s

        template ---------------------------------------------------------------- 2.64s

        ...

如果任何事情花费的时间超过几秒钟，那么最好弄清楚为什么要花费这么长时间。

`摘要`

我希望您了解了一些使Ansible Playbooks更易于维护的方法。就像我在开始时所说的那样，三个要点（保持组织，测试，然后简化和优化）中的每一个都在前一个基础上构建的，因此首先要确保您具有干净的文档化代码，然后确保已对它们进行了充分的测试，最后看看如何使它变得更好更快。

本文是Jeff在AnsibleFest 2018上演讲``使您的Ansible剧本灵活，可维护和可扩展''的后续文章，您可以在此处观看。

翻译自: https://opensource.com/article/20/1/ansible-playbooks-lessons

ansible剧本如何写