Ansible-core 2.14 移植指南 

本节讨论 ansible-core 2.13 和 ansible-core 2.14 之间的行为变化。

旨在帮助您更新您的剧本、插件以及 Ansible 基础设施的其他部分，以便它们能够与这个版本的 Ansible 一起使用。

建议您阅读此页面以及 ansible-core 2.14 的变更日志，以了解您可能需要进行哪些更新。

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

剧本 

条件语句 - 由于在 ansible-core 2.14.12 中缓解了安全问题 CVE-2023-5764，带有嵌入模板块的条件表达式可能会失败，并显示消息“Conditional is marked as unsafe, and cannot be evaluated.”，当嵌入的模板从不受信任的来源（例如模块结果或标记为 !unsafe 的变量）中获取数据时。带有嵌入模板的条件语句在引用不受信任数据时可能是恶意模板注入的来源，并且几乎总能无需嵌入模板的情况下重新编写。剧本任务条件关键字（例如 when 和 until）长期以来一直显示警告，不鼓励在条件语句中使用嵌入模板；此警告现已扩展到非任务条件语句，例如 assert 操作。
```
- name: task with a module result (always untrusted by Ansible)
  shell: echo "hi mom"
  register: untrusted_result

# don't do it this way...
# - name: insecure conditional with embedded template consulting untrusted data
#   assert:
#     that: '"hi mom" is in {{ untrusted_result.stdout }}'

- name: securely access untrusted values directly as Jinja variables instead
  assert:
    that: '"hi mom" is in untrusted_result.stdout'
```
变量现在以惰性方式进行评估；只有在它们实际使用时才进行评估。例如，在 ansible-core 2.14 中，表达式 {{ defined_variable or undefined_variable }} 在 undefined_variable 上不会失败，如果 or 的第一部分被评估为 True，因为它不需要评估第二部分。值得注意的一个行为变化的特殊情况是下面的任务，它使用了 undefined 测试。在 2.14 版本之前，这会导致致命错误，试图访问字典中的未定义值。在 2.14 中，断言通过，因为字典通过其未定义值之一被评估为未定义

- assert:
    that:
      - some_defined_dict_with_undefined_values is undefined
  vars:
    dict_value: 1
    some_defined_dict_with_undefined_values:
      key1: value1
      key2: '{{ dict_value }}'
      key3: '{{ undefined_dict_value }}'

命令行 

控制器节点上的 Python 3.9 是此版本的硬性要求。
在启动时，会检查文件系统编码和区域设置，以验证它们是否为 UTF-8。如果不是，则进程将退出并显示错误，报告错误的编码。如果您之前使用的是 C 或 POSIX 区域设置，您可能可以使用 C.UTF-8。如果您之前使用的是 en_US.ISO-8859-1 等区域设置，您可能可以使用 en_US.UTF-8。为简便起见，可以使用 LC_ALL 环境变量导出适当的区域设置。修改系统区域设置的另一种方法是在 UTF-8 模式下运行 Python；有关更多信息，请参阅 Python 文档。

弃用 

没有值得注意的更改

模块 

没有值得注意的更改

已移除的模块 

以下模块不再存在

没有值得注意的更改

弃用通知 

没有值得注意的更改

值得注意的模块更改 

没有值得注意的更改

插件 

没有值得注意的更改

移植自定义脚本 

没有值得注意的更改

网络 

没有值得注意的更改