Ansible-core 2.14 迁移指南 

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

本指南旨在帮助您更新 Playbook、插件以及 Ansible 基础设施的其他部分，以便它们能与此版本的 Ansible 协同工作。

我们建议您在阅读本页的同时，参考 ansible-core 2.14 版本变更日志，以了解您可能需要进行哪些更新。

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

Playbook 

条件语句 - 由于在 ansible-core 2.14.12 中修复了安全漏洞 CVE-2023-5764，当嵌入式模板块查询来自不可信源（如模块结果或标记为 !unsafe 的变量）的数据时，带有嵌入式模板块的条件表达式可能会报错：“Conditional is marked as unsafe, and cannot be evaluated.”（条件被标记为不安全，无法进行求值）。在引用不可信数据时，带有嵌入式模板的条件语句可能会成为恶意模板注入的来源，并且几乎总可以在不使用嵌入式模板的情况下进行重写。Playbook 任务的条件关键字（如 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 中，如果 or 的第一部分求值为 True，则不需要评估第二部分，因此表达式 {{ defined_variable or undefined_variable }} 不会因 undefined_variable 而失败。需要注意的一个具体行为变化案例是下面使用 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 文档。