Ansible 2.7 移植指南

本节讨论 Ansible 2.6 和 Ansible 2.7 之间的行为变化。

其目的是帮助您更新您的剧本、插件以及 Ansible 基础架构的其他部分，以便它们能够与 Ansible 的此版本一起工作。

我们建议您阅读此页面以及 Ansible 2.7 的变更日志，以了解您可能需要进行哪些更新。

本文档是移植集合的一部分。完整的移植指南列表可在 移植指南 中找到。

命令行

如果您在命令行上多次指定 --tags 或 --skip-tags，Ansible 将合并指定的标签。在之前的 Ansible 版本中，如果您只想保留最后指定的 --tags，可以将 merge_multiple_cli_tags 设置为 False。此配置选项是为了向后兼容性而存在的。覆盖行为在 2.3 版本中已弃用，默认行为在 2.4 版本中已更改。Ansible 2.7 移除此配置选项；现在始终合并多个 --tags。

如果您有一个依赖于将 merge_multiple_cli_tags 设置为 False 的 shell 脚本，请升级您的脚本，使其只在升级到 Ansible 2.7 之前添加您实际想要的 --tags。

Python 兼容性

Ansible 已放弃对控制器上的 Python 2.6 的兼容性（运行 /usr/bin/ansible 或 /usr/bin/ansible-playbook 的主机）。Ansible 附带的模块仍然可以用于管理只有 Python 2.6 的主机。您只需要一台安装了 Python 2.7 或 Python 3.5 或更高版本的机器来管理这些主机。

这会影响的一件事是使用 /usr/bin/ansible-pull 管理安装了 Python 2.6 的主机的能力。ansible-pull 在被管理的主机上运行，但它是一个控制器脚本，而不是一个模块，因此它需要更新的 Python。积极开发的并附带 Python 2.6 的 Linux 发行版有一些安装更新的 Python 版本的方法（例如，您可以在 RHEL 6 上通过 SCL 安装 Python 2.7），但您可能还需要安装许多常用模块的 Python 绑定才能工作（例如，对于 RHEL 6，需要为更新的 Python 安装安装 selinux 绑定和 yum）。

决定放弃对控制器上 Python 2.6 的支持是因为许多依赖库在那里变得不可用。特别是，python-cryptography 对于 Python 2.6 已不可用，而 pycrypto（python-cryptography 的替代方案）的最后一个版本存在已知的安全漏洞，这些漏洞将永远不会被修复。

剧本

角色加载期间的角色优先级修复

Ansible 2.7 对加载角色时的变量优先级做了一个小的更改，解决了这个 bug，确保角色加载符合 变量优先级预期。

在 Ansible 2.7 之前，加载角色时，在角色的 vars/main.yml 和 defaults/main.yml 中定义的变量在解析角色的 tasks/main.yml 文件时不可用。这阻止了角色在被解析时使用这些变量。当 import_tasks 或 import_role 与在角色的 vars 或 defaults 中定义的变量一起使用时，问题就会显现。

在 Ansible 2.7 中，角色 vars 和 defaults 现在在 tasks/main.yml 之前解析。如果在 play 级别和角色级别使用相同变量但值不同，并且在 import_tasks 或 import_role 中使用它来定义要导入的角色或文件，这可能会导致行为发生变化。

include_role 和 import_role 变量暴露

在 Ansible 2.7 中，一个名为 public 的新模块参数被添加到 include_role 模块中，它决定角色的 defaults 和 vars 是否会在角色外部暴露，从而允许这些变量被后续任务使用。此值默认为 public: False，与当前行为一致。

import_role 不支持 public 参数，并且会无条件地将角色的 defaults 和 vars 暴露给剧本的其余部分。此功能使 import_role 更接近于在 play 中的 roles 标题中列出的角色。

include_role（动态）暴露角色变量的方式与 import_role（静态）的方式存在重要区别。import_role 是一个预处理器，defaults 和 vars 在剧本解析时进行评估，使变量可用于 play 中任何位置列出的任务和角色。include_role 是一个条件任务，defaults 和 vars 在执行时进行评估，使变量可用于 include_role 任务之后列出的任务和角色。

include_tasks/import_tasks 内联变量

从 Ansible 2.7 开始，include_tasks 和 import_tasks 不再接受内联变量。任务应该在 vars 关键字下提供变量，而不是使用内联变量。

旧版本 在 Ansible 2.6（及更早版本）中，以下为指定变量的有效语法

- include_tasks: include_me.yml variable=value

新版本 在 Ansible 2.7 中，任务应更改为使用 vars 关键字

- include_tasks: include_me.yml
  vars:
    variable: value

使用未知算法的 vars_prompt

如果在 encrypt 中指定的哈希算法不受控制器支持，vars_prompt 现在会抛出一个错误。这提高了 vars_prompt 的安全性，因为它以前在算法未知时会返回 None。一些模块，特别是用户模块，将 None 密码视为不设置密码的请求。如果您的剧本由于此原因开始出错，请更改此过滤器使用的哈希算法。

已弃用

加速弃用：在 AnsibleModule 中使用 __file__

注意

在 Ansible 2.7 中已弃用使用 __file__ 变量，并且**将在 Ansible 2.8 中移除**。这比我们通常的 4 个版本弃用周期要快得多。

我们正在弃用使用 __file__ 变量来引用当前正在运行的代码所在的文件。这种常见的 Python 技术用于查找文件系统路径并不总是有效（即使在普通的 Python 中也是如此）。有时可以从虚拟位置（例如 zip 文件内部）导入 Python 模块。发生这种情况时，__file__ 变量将引用指向 zip 文件内部的虚拟位置。例如，如果代码试图使用 __file__ 来查找包含 Python 模块的目录以写入一些临时信息，则可能会导致问题。

在 Ansible 2.1 中引入 AnsiBallZ 之前，在 AnsibleModule 中使用 __file__ 有时有效，但是任何使用它的模块在启用管道时都会失败（因为模块将被管道传输到 Python 解释器的标准输入，因此 __file__ 将不包含文件路径）。AnsiBallZ 无意中使得使用 __file__ 成为可能，因为它始终为 AnsibleModule 创建一个临时文件。

Ansible 2.8 将不再为 AnsibleModule 创建临时文件；而是它将从 zip 文件中读取文件。此更改应该可以加快模块执行速度，但这意味着从 Ansible 2.8 开始，在 AnsibleModule 中引用 __file__ 将始终失败。

如果您是使用 __file__ 与 AnsibleModule 的第三方模块的作者，请立即更新您的模块，因为现在 __file__ 的使用已被弃用，但仍然可用。__file__ 最常见的用途是查找要写入临时文件的目录。在 Ansible 2.5 及更高版本中，您可以改用 AnsibleModule 实例上的 tmpdir 属性，如下面的 apt 模块 代码所示。

-    tempdir = os.path.dirname(__file__)
-    package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)[1]))
+    package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)[1]))

通过 squash_actions 在包模块上使用循环

使用 squash_actions 调用包模块（例如“yum”）以仅调用一次模块已被弃用，并将从 Ansible 2.11 中移除。

不要依赖于隐式压缩，任务应该直接将列表提供给模块的 name、pkg 或 package 参数。自 Ansible 2.3 以来，大多数模块都支持此功能。

旧版 在 Ansible 2.6（及更早版本）中，以下任务将仅调用一次“yum”模块来安装多个包。

- name: Install packages
  yum:
    name: "{{ item }}"
    state: present
  with_items: "{{ packages }}"

新版 在 Ansible 2.7 中，它应该更改为如下所示。

- name: Install packages
  yum:
    name: "{{ packages }}"
    state: present

模块

此处详细介绍了常用模块中的重大更改。

  • DEFAULT_SYSLOG_FACILITY 配置选项告诉 Ansible 模块在所有受管理机器上记录信息时使用特定的 syslog 设施。由于旧版 Ansible 版本存在错误，此设置不会影响使用安装了 systemd Python 绑定的 journald 的机器。在这些机器上，即使您设置了 DEFAULT_SYSLOG_FACILITY，Ansible 日志消息也会发送到 /var/log/messages。Ansible 2.7 修复了此错误，根据为 DEFAULT_SYSLOG_FACILITY 设置的值路由所有 Ansible 日志消息。如果您已配置 DEFAULT_SYSLOG_FACILITY，则使用 journald 的系统上的远程日志位置可能会更改。

已移除的模块

以下模块不再存在。

弃用通知

以下模块将在 Ansible 2.11 中移除。请相应地更新您的 playbook。

  • na_cdot_aggregate 请改用 na_ontap_aggregate。

  • na_cdot_license 请改用 na_ontap_license。

  • na_cdot_lun 请改用 na_ontap_lun。

  • na_cdot_qtree 请改用 na_ontap_qtree。

  • na_cdot_svm 请改用 na_ontap_svm。

  • na_cdot_user 请改用 na_ontap_user。

  • na_cdot_user_role 请改用 na_ontap_user_role。

  • na_cdot_volume 请改用 na_ontap_volume。

  • sf_account_manager 请改用 na_elementsw_account。

  • sf_check_connections 请改用 na_elementsw_check_connections。

  • sf_snapshot_schedule_manager 请改用 na_elementsw_snapshot_schedule。

  • sf_volume_access_group_manager 请改用 na_elementsw_access_group。

  • sf_volume_manager 请改用 na_elementsw_volume。

值得注意的模块更改

  • 现在 command 和 shell 模块支持检查模式。但是，只有在指定 creates 或 removes 时才有效。如果指定了这两个选项中的任何一个，模块将检查文件是否存在并报告正确的更改状态；如果没有包含它们，模块将像以前一样跳过。

  • win_chocolatey 模块最初要求 proxy_username 和 proxy_password 来转义值中的任何双引号。现在不再需要此操作，并且转义可能会导致更多问题。

  • win_uri 模块已删除弃用的选项 use_basic_parsing，因为自 Ansible 2.5 以来此选项无效。

  • win_scheduled_task 模块已删除以下弃用的选项：

    • executable，请改用操作条目中的 path

    • argument，请改用操作条目中的 arguments

    • store_password，请改用 logon_type: password

    • days_of_week，请改用触发器条目中的 monthlydow

    • frequency，请改用触发器条目中的 type

    • time，请改用触发器条目中的 start_boundary

  • na_ontap_net_vlan 的模块选项 interface_name 已删除，应从您的 playbook 中删除。

  • win_disk_image 模块已弃用返回值 mount_path，请改用 mount_paths[0]。这将在 Ansible 2.11 中移除。

  • 现在可以直接从 ansible（adhoc）和 ansible-console 使用 include_role 和 include_tasks。

    #> ansible -m include_role -a 'name=myrole' all

  • pip 模块添加了对 setuptools 的依赖以支持版本要求，此要求适用于执行模块的 Python 解释器，而不是模块管理的 Python 解释器。

  • 在 Ansible 2.7.10 之前，replace 模块在同时使用 before 和 after 选项时与预期相反。现在它可以正常工作了，但可能需要更改任务。

插件

  • 如果指定的哈希算法不受控制器支持，则 hash_password 过滤器现在将抛出错误。这提高了过滤器的安全性，因为它以前在算法未知时返回 None。一些模块（特别是用户模块）将 None 密码视为不设置密码的请求。如果您的 playbook 开始因此而出现错误，请更改此过滤器使用的哈希算法。

移植自定义脚本

无显著变化。

网络

无显著变化。