Ansible 和 Infoblox 角色深度解析

Ansible 和 Infoblox 角色深度解析

正如 Sean Cavanaugh 在他之前的 Infoblox 博客文章中提到的，Ansible 2.5 版本引入了查找插件、动态清单脚本和五个模块，这些模块允许进行 Infoblox 自动化。这些模块和查找在角色中的组合提供了一个强大的 DNS 自动化框架。

摘要

今天，我们将演示如何使用 Ansible 自动化 Infoblox Core Network Services 可以帮助您轻松、快速和可靠地管理 IP 地址并在网络中路由流量。您的虚拟化和云网络系统需要快速的供应生命周期；Infoblox 可以帮助您管理这些生命周期。当与 Infoblox 配合使用时，Ansible 允许您自动化这些工作。Ansible 与 Infoblox 的集成灵活且强大：您可以使用模块或直接调用 Infoblox WAPI REST API 来自动化 Infoblox 任务。

这篇文章将引导您完成六个现实世界中的场景，在这些场景中，Ansible 和 Infoblox 可以简化您的网络任务

1. 在一个地方创建一个提供程序，该提供程序可在角色集合中重复使用。
2. 通过创建具有正向 DNS 区域的新子网来扩展您的网络。Ansible 的 Infoblox 模块使这个常见的两部分任务变得简单。
3. 创建反向 DNS 区域，例如，标记来自任何没有关联地址名称的 IP 地址的电子邮件。对于旧版本的 Ansible，您必须使用对 Infoblox API 的调用来执行此任务，但从 Ansible v2.7 开始，nios_zone 模块现在支持此功能。
4. 使用 Ansible 的强大 Jinja2 模板为新子网的网关地址保留主机记录。
5. 使用循环和 host_count 在子网中创建其他主机。
6. 管理 Infoblox Grid 以大规模自动化您的网络，其中一个 Infoblox 设备可能不够。Grid 在物理上分离您的托管网络并消除单点故障。

要根据您自己的 Infoblox 设备上的这些示例进行操作，您需要安装 dynamic-infoblox 角色 并将您的 Infoblox 凭据设置为提供程序。

Infoblox 凭据和 nios_provider

[任何时候您将 Ansible 与 Infoblox 一起使用时，调用 Infoblox 查找 或 模块 时，都必须指定 Infoblox IP、用户名和用户的密码。 我们的角色 将这些凭据统称为 nios_provider。通过将 nios_provider 字典创建为组变量，您可以在所有 playbook 和角色中一致地应用这些值，并在需要时在一行中引用它们。

*group_vars/all/main.yml*

nios_provider:
   #Infoblox out-of-the-box defaults specified here
    host: 192.168.1.2
    username: admin
    password: infoblox
wapi_version: “v2.7”

使用模块设置子网和正向 DNS 区域

准备就绪后，您可以运行一个 playbook，该 playbook 利用 dynamic Infoblox 角色创建子网和正向 DNS 区域；Ansible 模块可以轻松地完成此操作。创建子网是一个常见的网络项目：子网允许管理员扩展网络，以响应新的公司分支机构、办公室或业务线。正向 DNS 区域建立地址名称到 IP 地址的单向映射。企业可能需要一个新的 DNS 区域来扩展其全球覆盖范围到其他国家/地区（例如 .uk）或应对合并。此处显示的任务将 ansible_subnet 和 ansible_zone 定义为变量，因此您可以在每次创建新子网时覆盖它们。

- name: Create a test network subnet
  nios_network:
     network: "{{ ansible_subnet }}"
     comment: Test network subnet to add host records to
     state: present
     provider: "{{ nios_provider }}"

- name: "Create a forward DNS zone called {{ ansible_zone }}"
  nios_zone:
     name: "{{ ansible_zone }}"
     comment: local DNS zone
     state: present
     provider: "{{ nios_provider }}"

在此示例中，我们使用了默认的 Infoblox 视图。Infoblox 允许在单个 DNS 区域内使用多个视图。如果您希望将内部流量路由到本地服务器并将外部流量路由到公共云服务器，则可以通过设计具有两个 DNS 视图的 DNS 区域来实现。这种类型的设置可确保对员工内联网的流量不会占用客户使用的服务器，从而为客户提供更好的地理覆盖范围和更高级别的全天候覆盖范围。但是，对于上面的简单示例（以及后续示例），我们一直坚持使用默认视图。

使用 Infoblox API 设置反向 DNS 区域

到目前为止，您已经了解了如何使用 Ansible 模块来自动化 Infoblox 更改。我们的下一个示例展示了如何使用 Infoblox WAPI REST API 来自动化当前版本的 Ansible 中可能不可用的任务。反向 DNS 区域允许客户端在知道等效 IP 地址时查找地址名称。反向区域的重要性可以通过一个常见的示例来说明：电子邮件服务器。来自没有关联地址名称的 IP 地址的传入流量（通过反向 DNS）通常会被标记为垃圾邮件。反向区域还可以帮助解决其他用例，例如收集有关访问您网站的其他企业的真实数据。

nios_zone 模块已经可以创建正向 DNS 区域，但它只能使用最新版本的 Ansible 创建反向区域。但是，您仍然可以在旧版本的 Ansible 中自动化此任务 - 只需使用 Ansible 直接对 WAPI API 进行调用即可。您可以使用 uri 模块或 shell 脚本来执行此操作。我们建议使用 uri 模块，因为它有助于更具描述性地捕获集成并启用利用标准 REST 返回代码的幂等调用。在此，uri 模块充当一个伞形模块，以简洁的方式捕获 Ansible 模块生态系统中的单个 WAPI 调用。值得注意的是，WAPI API 的操作方式与 Ansible 模块非常相似：JSON 输入和 JSON 输出。如果您以 yaml 表示 API 调用的主体，则可以轻松使用 Jinja2 过滤器（稍后我们将深入探讨）在运行时将其转换为 JSON。

- name: Create a reverse DNS zone to complement forward zone
  uri:
    url: https://{{ nios_provider.host }}/wapi/{{ wapi_version }}/zone_auth
    method: POST
    user: "{{ nios_provider.username }}"
    password: "{{ nios_provider.password }}"
    body: "{{ reverse_zone_yml | to_json }}"
    #201 signifies successful creation
    #400 signifies existing entry
    #both signify a successful WAPI call
    status_code: 201,400
    headers:
        Content-Type: "application/json"
    validate_certs: no
  register: reverse_dns_create
  changed_when: reverse_dns_create.status == 201
  vars:
    reverse_zone_yml:
      fqdn: "{{ ansible_subnet }}"
      zone_format: "IPV4"

如果您在创建任何主机记录之前建立了子网、正向区域和反向区域，那么您在该正向区域中创建的每个主机记录都会自动创建相应的反向区域条目！定义了网络、正向区域和反向区域后，就可以开始为新子网创建主机记录了。

使用 Jinja2 模板保留网关地址

当您开始创建主机记录时，您希望将区域中的第一个（或最后一个）主机记录保留为网关地址，即转发目标 IP 地址位于紧邻网络之外的数据包的地址。如前所述，您可以使用 Jinja2 过滤器通过在其上调用简短的 python 函数来操作数据；Jinja2 过滤器语法有效地充当 linux 管道。Jinja2 过滤器是快速操作数据的一种方法，在本例中，我们使用其中两个（参见下面的示例）来遵守 Infoblox 网关地址命名约定。需要注意的是，相对于子网定义网关地址名称可以避免网关地址名称被覆盖，因为每个子网通常都有自己的网关地址。

- name: Create a host record for the gateway address
  nios_host_record:
     name: “gateway{{ ansible_subnet | ipaddr(‘first_usable’) |
  replace(".","_") }}.{{ ansible_zone }}”
     ipv4:
        - address: "{{ gateway_address }}"
     state: present
     provider: "{{ nios_provider }}"

此任务使用此复杂的 Jinja2 表达式逐步构建网关主机名。Ansible 打包的 ipaddr 过滤器 非常通用 - 它能够实现大量常规的 IP 地址操作。例如，如果您的 IP 范围是 192.168.1.0/24 并且您的 ansible_zone 是 ansible.local，则上面的任务中的过滤器将在一行中创建一个名称

1. 表达式以“gateway”开头
2. 中的部分执行了一些操作：a. 检索 ansible_subnet => 198.168.1.0/24 的 ansible_subnet 的模板化值 b. 使用检索到的 ansible_subnet 值并将其提供给 ipaddr('first_usable') 过滤器插件以获取第一个可用 IP 192.168.1.0/24 | ipaddr('first_usable') => 192.168.1.1 c. 使用下划线而不是点来格式化结果 IP 192.168.1.1 | replace('.', '_') => 192_168_1_1 d. 在子网值之前添加 . 分隔符 e. 检索 ansible_zone => ansible.local 的 ansible_zone 的模板化值

通过示例模板传递上述列出的值的网关主机名将是

gateway192_168_1_1.ansible.local

Jinja2 过滤器是一个复杂的 Ansible 主题；在构建您自己的 Jinja2 过滤器之前，您应该拥有坚实的 Ansible 基础。当您开始创建过滤器时，您可以在本地测试预期值，或者利用 Sivel 的 Ansible 模板测试器 在将过滤器用于 playbook 或角色之前查看其结果。 

使用循环和 host_count 生成主机记录

保留网关地址后，您可以使用循环生成已知数量的其他主机记录。在现实场景中，您可能会在子网内生成服务器组（例如，数据库服务器、应用程序服务器等）。对于此简单演示，您可以定义一个循环，该循环将根据用户提供的 host_count 值动态生成通用主机记录。此演示展示了 nios_next_ip 查找插件的功能，该插件可以获取单个下一个可用 IP 或一系列下一个可用 IP 以分配。在具有这两个任务的 Playbook 中（上面一个为网关地址创建主机记录的任务和下面一个生成主机记录的任务），如果您未定义 host_count，则 playbook 不会创建任何其他主机记录；只会创建网关地址。

#Generating records this way should be for demo purposes
#Normal scenario would be to iterate over a dictionary/list of hosts or populate via a static csv file
- name: “Dynamically generate {{ host_count }} host records at next available ip in {{ ansible_subnet }}”
  include_tasks: host_record_generation.yml
  loop_control:
     loop_var: count
  with_sequence: start=1 end={{ host_count }}
  when: host_count is defined

如果您基于用户提供的主机计数使用 Ansible 生成主机记录，那么在第二次运行时循环遍历主机计数是否可能导致索引问题？不幸的是确实会，但是保持已生成主机的总数可以解决此问题。一种方法是在控制节点上维护一个静态的总主机计数文件，将其视为真相来源。通过利用 Ansible 的查找插件功能来检索其内容，每次生成主机时，此文件中的计数都会递增，因此后续角色执行（尤其是在不同子网中自动执行的角色）不会覆盖彼此的记录！

这种生成主机记录的方式不同于大多数企业使用的命名约定生成主机记录的方式，但它是一种使用 nios_next_ip 查找开箱即用的简单方法，可以在不同的区域和/或子网中创建一些记录。Infoblox 还支持用于静态记录的 csv 记录导入功能。

使用 Ansible 预定义 Infoblox Grid

在前四个场景中，您已经了解了 Ansible 如何在主机和子网级别与 Infoblox 协同工作。Ansible 可以大规模地对 Infoblox 做什么？自动化单个 Infoblox 实例可以提供价值，但生产 Infoblox 系统通常设计为 Grid。Infoblox 网站解释了 Infoblox Grid 技术的全部功能。Infoblox Grid 在单个或配对设备之间建立分布式关系，以消除传统 DNS、DHCP 和 IP 地址管理基础设施中固有的单点故障和其他运营风险。每个 Grid 包含一个 Grid Master 和数量可变的其他 Grid 成员和/或 Grid Master 候选者。Grid 成员仅包含执行其工作所需的部分 Infoblox 数据库。另一方面，Grid Master 候选者具有 Grid Master 数据库的实时完整副本，以提供灾难恢复功能。您可以使用我们的 Ansible 角色预定义新的 Grid Master 候选者和 Grid 成员，如下所示

- name: Predefine a new Grid Master Candidate
  hosts: localhost
  connection: local
  roles:
    -  role: predefineGridmasterCandidate
       master_candidate_name: gmc.ansible.local
       master_candidate_address: 192.168.2.2
       master_candidate_gateway: 192.168.2.254
       master_candidate_subnet_mask: 255.255.255.0

- name: Predefine a new Grid Member
  hosts: localhost
  connection: local
  roles:
    -  role: predefineGridMember
       member_name: m3.ansible.local
       member_address: 192.168.2.3
       member_gateway: 192.168.2.254
       member_subnet_mask: 255.255.255.0

从这五个示例中可以看出，Ansible 和 Infoblox 协同工作，可以快速、轻松且可靠地管理您的网络基础设施及其承载的流量。Ansible 基于 Infoblox WAPI API 的强大功能。使用 Ansible 模块和对 WAPI API 的直接调用，您可以编写可重用的 Ansible 角色和剧本，这些角色和剧本可以快速适应处理不同的网络。如果您愿意，可以从自定义 ansible-networking 存储库 中的角色开始，这些角色连接了今天文章中讨论的所有 Ansible 概念。