Разработка модулей ресурсов сети

• Изучение модулей ресурсов сети и безопасности

• Разработка модулей ресурсов сети и безопасности

  • Понимание модели и генератора модулей ресурсов
  • Доступ к генератору модулей ресурсов
  • Создание модели
  • Создание каркаса коллекции из модели ресурса

• Примеры

  • Структура каталога коллекции
  • Структура каталога роли
  • Использование коллекции
  • Использование роли
• Структура и рабочий процесс модулей ресурсов
• Запуск ansible-test sanity и tox для модулей ресурсов

• Тестирование модулей ресурсов

  • Интеграционные тесты модулей ресурсов
  • Требования к модульным тестам

• Пример: Модульное тестирование модулей Ansible сетевых ресурсов

  • Использование имитационных объектов для модульного тестирования модулей Ansible сетевых ресурсов
  • Моделирование данных устройства

Изучение модулей ресурсов сети и безопасности

Сетевые и защитные устройства разделяют конфигурацию на разделы (например, интерфейсы, VLANы и т. д.), которые применяются к сетевому или защитному сервису. Модули ресурсов Ansible используют это для возможности конфигурации подразделов или ресурсов в конфигурации устройства. Модули ресурсов обеспечивают единый опыт работы с различными сетевыми и защитными устройствами. Например, модуль сетевого ресурса может обновлять только конфигурацию определённой части сетевых интерфейсов, VLANов, ACL и т. д. для сетевого устройства. Модуль ресурса:

1. Извлекает часть конфигурации (сбор фактов), например, конфигурацию интерфейсов.
2. Преобразует полученную конфигурацию в пары ключ-значение.
3. Размещает эти пары ключ-значение в внутренний агностичный структурированный формат данных.

Теперь, когда данные конфигурации нормализованы, пользователь может обновить и изменить данные, а затем использовать модуль ресурса для отправки данных конфигурации обратно на устройство. Это приводит к полному обновлению конфигурации без необходимости в ручном разборе, манипулировании данными и управлении моделью данных.

Модуль ресурса имеет два ключа верхнего уровня - config и state:

• config определяет модель данных конфигурации ресурса как пары ключ-значение. Тип параметра config может быть dict или list of dict в зависимости от управляемого ресурса. То есть, если устройство имеет одну глобальную конфигурацию, она должна быть типа dict (например, глобальная конфигурация LLDP). Если устройство имеет несколько экземпляров конфигурации, она должна быть типа list с каждым элементом в списке типа dict (например, конфигурация интерфейсов).
• state определяет действие, которое модуль ресурса выполняет на конечном устройстве.

state для нового модуля ресурса должен поддерживать следующие значения (по мере необходимости для устройств, которые их поддерживают):

merged

Ansible объединяет конфигурацию на устройстве с предоставленной конфигурацией в задаче.

replaced

Ansible заменяет подсекцию конфигурации на устройстве предоставленной подсекцией конфигурации в задаче.

overridden

Ansible перезаписывает подсекцию конфигурации на устройстве для ресурса предоставленной конфигурацией в задаче. Будьте осторожны с этим состоянием, так как вы можете удалить доступ к устройству (например, перезаписав конфигурацию интерфейса управления).

deleted

Ansible удаляет подсекцию конфигурации на устройстве и восстанавливает все значения по умолчанию.

gathered

Ansible отображает детали ресурса, собранные с сетевого устройства и доступные с помощью ключа gathered в результате.

rendered

Ansible отображает предоставленную конфигурацию в задаче в формате, специфичном для устройства (например, Cisco IOS CLI). Ansible возвращает эту отображенную конфигурацию в ключе rendered в результате. Обратите внимание, что это состояние не взаимодействует с сетевым устройством и может использоваться оффлайн.

parsed

Ansible анализирует конфигурацию из параметра running_configuration в структурированные данные Ansible в ключе parsed в результате. Обратите внимание, что это не собирает конфигурацию с сетевого устройства, поэтому это состояние может использоваться оффлайн.

Модули в поддерживаемых коллекциях Ansible должны поддерживать эти значения состояния. Если вы разрабатываете модуль только с «present» и «absent» для состояния, вы можете отправить его в коллекцию сообщества.

Разработка модулей ресурсов сети и безопасности

Команда Ansible Engineering гарантирует, что дизайн модуля и шаблон кода в поддерживаемых коллекциях Ansible являются единообразными для ресурсов и платформ, чтобы обеспечить независимость от поставщика и обеспечить качественный код. Рекомендуется использовать генератор модулей ресурсов для разработки модуля ресурса.

Процесс разработки модуля ресурса в общих чертах:

1. Создайте и поделитесь дизайном модели ресурса в репозитории моделей модулей ресурсов в виде PR для проверки.
2. Загрузите последнюю версию генератора модулей ресурсов.
3. Запустите resource module builder для создания каркаса коллекции из вашей одобренной модели ресурса.
4. Напишите код для реализации модуля ресурса.
5. Разработайте интеграционные и модульные тесты для проверки вашего модуля ресурса.
6. Создайте PR в соответствующую коллекцию, в которую вы хотите добавить ваш новый модуль ресурса. См. Вклад в поддерживаемые коллекции Ansible для получения подробностей о определении правильной коллекции для вашего модуля.

Понимание модели и генератора модулей ресурсов

Генератор модулей ресурсов — это Ansible Playbook, который помогает разработчикам создавать и поддерживать модуль ресурса Ansible. Он использует модель в качестве единственного источника истинности для модуля. Эта модель — файл yaml, который используется для раздела DOCUMENTATION модуля и спецификации аргументов.

Генератор модулей ресурсов имеет следующие возможности:

• Использует определённую модель для создания структуры каталога модуля ресурса и начальных файлов класса.
• Создаёт каркас либо для Ansible роли, либо для коллекции.
• Последующие использования генератора модулей ресурсов заменят только arspec модуля и файл, содержащий строку документации модуля.
• Позволяет хранить сложные примеры вместе с моделью в одном каталоге.
• Поддерживает модель в качестве единственного источника истинности для модуля и использует генератор модулей ресурсов для обновления исходных файлов по мере необходимости.
• Генерирует рабочие образцы модулей как для <network_os>_<resource>, так и для <network_os>_facts.

Доступ к генератору модулей ресурсов

Для доступа к генератору модулей ресурсов:

1. клонировать репозиторий github:

git clone https://github.com/ansible-network/resource_module_builder.git

2. Установить необходимые пакеты:

pip install -r requirements.txt

Создание модели

Вы должны создать модель для вашего нового ресурса. Модель — единственный источник истинности как для argspec, так и для строки документации, поддерживая их синхронизацию. После утверждения вашей модели вы можете использовать генератор модулей ресурсов для создания трёх элементов на основе модели:

• Каркас для нового модуля
• Argspec для нового модуля
• Строка документации для нового модуля

Для любых последующих изменений функциональности сначала обновите модель, а затем используйте генератор модулей ресурсов для обновления argspec модуля и строки документации.

Например, генератор модулей ресурсов включает пример myos_interfaces.yml в директории models, как показано ниже:

---
GENERATOR_VERSION: '1.0'

NETWORK_OS: myos
RESOURCE: interfaces
COPYRIGHT: Copyright 2019 Red Hat
LICENSE: gpl-3.0.txt

DOCUMENTATION: |
  module: myos_interfaces
  version_added: 1.0.0
  short_description: 'Manages <xxxx> attributes of <network_os> <resource>'
  description: 'Manages <xxxx> attributes of <network_os> <resource>.'
  author: Ansible Network Engineer
 notes:
    - 'Tested against <network_os> <version>'
  options:
    config:
      description: The provided configuration
      type: list
      elements: dict
      suboptions:
        name:
          type: str
          description: The name of the <resource>
        some_string:
          type: str
          description:
          - The some_string_01
          choices:
          - choice_a
          - choice_b
          - choice_c
          default: choice_a
        some_bool:
          description:
          - The some_bool.
          type: bool
        some_int:
          description:
          - The some_int.
          type: int
          version_added: '1.1'
        some_dict:
          type: dict
          description:
          - The some_dict.
          suboptions:
            property_01:
              description:
              - The property_01
              type: str
    state:
      description:
      - The state of the configuration after module completion.
      type: str
      choices:
      - merged
      - replaced
      - overridden
      - deleted
      default: merged
EXAMPLES:
  - deleted_example_01.txt
  - merged_example_01.txt
  - overridden_example_01.txt
  - replaced_example_01.txt

Обратите внимание, что вы должны включать примеры для каждого из состояний, которые поддерживает ресурс. Генератор модулей ресурсов также включает их в примере модели.

Поделитесь этой моделью в виде PR для проверки в репозитории моделей модулей ресурсов. Вы также можете увидеть больше примеров моделей на этом сайте.

Создание каркаса коллекции из модели ресурса

Для использования генератора модулей ресурсов для создания каркаса коллекции из вашей одобренной модели ресурса:

ansible-playbook -e rm_dest=<destination for modules and module utils> \
                 -e structure=collection \
                 -e collection_org=<collection_org> \
                 -e collection_name=<collection_name> \
                 -e model=<model> \
                 site.yml

Где параметры следующие:

• rm_dest: Каталог, куда модуль сборки ресурсов помещает файлы и каталоги для модуля ресурсов и модулей фактов.

• structure: Тип структуры каталогов (роль или коллекция)

  • role: Сгенерировать структуру каталогов для роли.
  • collection: Сгенерировать структуру каталогов для коллекции.
• collection_org: Организация коллекции, необходимая при structure=collection.
• collection_name: Название коллекции, необходимое при structure=collection.
• model: Путь к файлу модели.

Чтобы использовать модуль сборки ресурсов для создания шаблона роли:

ansible-playbook -e rm_dest=<destination for modules and module utils> \
                 -e structure=role \
                 -e model=<model> \
                 site.yml

Примеры

Структура каталогов коллекции

Этот пример демонстрирует структуру каталогов для следующих элементов:

• network_os: myos
• resource: интерфейсы

ansible-playbook -e rm_dest=~/github/rm_example \
                 -e structure=collection \
                 -e collection_org=cidrblock \
                 -e collection_name=my_collection \
                 -e model=models/myos/interfaces/myos_interfaces.yml \
                 site.yml

├── docs
├── LICENSE.txt
├── playbooks
├── plugins
|   ├── action
|   ├── filter
|   ├── inventory
|   ├── modules
|   |   ├── __init__.py
|   |   ├── myos_facts.py
|   |   └──  myos_interfaces.py
|   └──  module_utils
|       ├── __init__.py
|       └──  network
|           ├── __init__.py
|           └──  myos
|               ├── argspec
|               |   ├── facts
|               |   |   ├── facts.py
|               |   |   └──  __init__.py
|               |   ├── __init__.py
|               |   └──  interfaces
|               |       ├── __init__.py
|               |       └──  interfaces.py
|               ├── config
|               |   ├── __init__.py
|               |   └──  interfaces
|               |       ├── __init__.py
|               |       └──  interfaces.py
|               ├── facts
|               |   ├── facts.py
|               |   ├── __init__.py
|               |   └──  interfaces
|               |       ├── __init__.py
|               |       └──  interfaces.py
|               ├── __init__.py
|               └──  utils
|                   ├── __init__.py
|                   └──  utils.py
├── README.md
└──  roles

Структура каталогов роли

Этот пример отображает структуру каталогов роли для следующих элементов:

• network_os: myos
• resource: интерфейсы

ansible-playbook -e rm_dest=~/github/rm_example/roles/my_role \
                 -e structure=role \
                 -e model=models/myos/interfaces/myos_interfaces.yml \
                 site.yml

roles
└── my_role
    ├── library
    │   ├── __init__.py
    │   ├── myos_facts.py
    │   └── myos_interfaces.py
    ├── LICENSE.txt
    ├── module_utils
    │   ├── __init__.py
    │   └── network
    │       ├── __init__.py
    │       └── myos
    │           ├── argspec
    │           │   ├── facts
    │           │   │   ├── facts.py
    │           │   │   └── __init__.py
    │           │   ├── __init__.py
    │           │   └── interfaces
    │           │       ├── __init__.py
    │           │       └── interfaces.py
    │           ├── config
    │           │   ├── __init__.py
    │           │   └── interfaces
    │           │       ├── __init__.py
    │           │       └── interfaces.py
    │           ├── facts
    │           │   ├── facts.py
    │           │   ├── __init__.py
    │           │   └── interfaces
    │           │       ├── __init__.py
    │           │       └── interfaces.py
    │           ├── __init__.py
    │           └── utils
    │               ├── __init__.py
    │               └── utils.py
    └── README.md

Использование коллекции

В этом примере показано, как использовать сгенерированную коллекцию в playbook:

----
- hosts: myos101
  gather_facts: False
  tasks:
  - cidrblock.my_collection.myos_interfaces:
    register: result
  - debug:
      var: result
  - cidrblock.my_collection.myos_facts:
  - debug:
      var: ansible_network_resources

Использование роли

В этом примере показано, как использовать сгенерированную роль в playbook:

- hosts: myos101
  gather_facts: False
  roles:
  - my_role

- hosts: myos101
  gather_facts: False
  tasks:
  - myos_interfaces:
    register: result
  - debug:
      var: result
  - myos_facts:
  - debug:
      var: ansible_network_resources

Структура и рабочий процесс модуля ресурсов

Структура модуля ресурсов включает следующие компоненты:

Модуль

• library/<ansible_network_os>_<resource>.py.
• Импортирует пакет ресурсов module_utils и вызывает API execute_module:

def main():
    result = <resource_package>(module).execute_module()

Аргументы модуля

• module_utils/<ansible_network_os>/argspec/<resource>/.
• Аргументы для ресурса.

Факты

• module_utils/<ansible_network_os>/facts/<resource>/.
• Заполнение фактов для ресурса.
• Элемент в module_utils/<ansible_network_os>/facts/facts.py для API get_facts для синхронизации модуля <ansible_network_os>_facts и собранных фактов для модуля ресурсов для каждого подмножества.
• Элемент подмножества ресурса в списке FACTS_RESOURCE_SUBSETS в module_utils/<ansible_network_os>/facts/facts.py для работы сбора фактов.

Пакет модуля в module_utils

• module_utils/<ansible_network_os>/<config>/<resource>/.
• Реализация API execute_module для загрузки конфигурации на устройство и генерации результата с ключами changed, commands, before и after.
• Вызов API get_facts, возвращающего фактические данные конфигурации <resource> или возвращающего разницу, если устройство поддерживает onbox diff.
• Сравнение собранных фактов и заданных значений ключ-значение, если diff не поддерживается.
• Генерация окончательной конфигурации.

Утилиты

• module_utils/<ansible_network_os>/utils.
• Утилиты для платформы <ansible_network_os>.

Запуск ansible-test sanity и tox для модулей ресурсов

Перед отправкой PR в поддерживаемую Ansible коллекцию необходимо запустить ansible-test sanity и tox -elinters из корневой директории коллекции. CI выполняет оба теста, и процесс завершится ошибкой, если эти тесты не пройдут. Подробности о ansible-test sanity см. в Тестирование Ansible.

Для установки необходимых пакетов:

1. Убедитесь, что у вас настроена действительная среда разработки Ansible. Подробности см. в Настройка среды.
2. Запустите pip install -r requirements.txt из корневой директории коллекции.

Запуск tox -elinters:

• Читает tox.ini из корневой директории коллекции и устанавливает необходимые зависимости (например, black и flake8).
• Выполняет их с предварительно настроенными параметрами (например, длина строки и игнорирование).
• Запускает black в режиме проверки, чтобы показать, какие файлы будут отформатированы, не выполняя форматирование.

Тестирование модулей ресурсов

Тесты полагаются на роль, сгенерированную модулем сборки ресурсов. После изменений в модуле сборки ресурсов роль необходимо перегенерировать, а тесты — модифицировать и выполнить по мере необходимости. Для перегенерации роли после изменений:

rm -rf rmb_tests/roles/my_role
ansible-playbook -e rm_dest=./rmb_tests/roles/my_role \
                 -e structure=role \
                 -e model=models/myos/interfaces/myos_interfaces.yml \
                 site.yml

Интеграционные тесты модуля ресурсов

Основные требования к интеграционному тестированию новых модулей ресурсов следующие:

1. Напишите тестовый случай для каждого состояния.
2. Напишите дополнительные тестовые случаи для проверки поведения модуля при указании пустого config.yaml.
3. Добавьте тестовый случай с обратным циклом. Он включает операцию merge, за которой следует gather_facts, обновление merge с дополнительной конфигурацией, а затем возврат к базовой конфигурации с использованием ранее собранных фактов с state установленным в overridden.
4. В тех случаях, когда это применимо, утверждения должны проверять значения после и до dicts по сравнению со строго заданным Источником Истины.

Мы используем Zuul в качестве CI для запуска набора интеграционных тестов для каждого PR, включая новые тесты, внедренные этим PR.

• Чтобы просмотреть отчет, нажмите «Подробности» на комментарии CI в PR
• Чтобы просмотреть отчет об ошибке, нажмите «ansible/check» и выберите не пройденный тест.
• Чтобы просмотреть журналы во время выполнения теста, проверьте свой номер PR на панели состояния Zuul по адресу Zull status board.
• Чтобы исправить ошибку статического теста локально, запустите команду tox -e black в корневой папке коллекции.

Для просмотра журналов выполнения Ansible и отладки сбоев тестов:

1. Нажмите на не пройденный тест, чтобы получить сводку, и нажмите «Журналы», чтобы получить журнал.
2. Нажмите «консоль» и прокрутите вниз, чтобы найти не пройденный тест.
3. Нажмите «>» рядом с не пройденным тестом для получения полной информации.

Структура интеграционных тестов

Каждый тестовый случай, как правило, должен следовать этому шаблону:

• настройка —> тест —> утверждение —> повторный тест (для идемпотентности) —> утверждение —> разборка (при необходимости) —> завершено. Это помогает предотвратить превращение тестовых playbooks в монолитные и сложные для отладки.
• Включите имя для каждой задачи, которая не является утверждением. Вы также можете добавить имена к утверждениям, но легче идентифицировать сломанную задачу в случае сбоя теста, если вы добавите имя для каждой задачи.
• Файлы, содержащие тестовые случаи, должны заканчиваться на .yaml

Реализация

Для платформ, которые поддерживают connection: local и connection: network_cli, используйте следующие рекомендации:

• Называйте каталоги targets/ по имени модуля.
• Файл main.yaml должен просто ссылаться на транспорт.

Следующий пример продемонстрирует интеграционные тесты для модуля vyos.vyos.vyos_l3_interfaces в коллекции vyos.vyos:

test/integration/targets/vyos_l3_interfaces/tasks/main.yaml

---
- include: cli.yaml
  tags:
    - cli

test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml

---
- name: collect all cli test cases
  find:
    paths: "{{ role_path }}/tests/cli"
    patterns: "{{ testcase }}.yaml"
  register: test_cases
  delegate_to: localhost

- name: set test_items
  set_fact: test_items="{{ test_cases.files | map(attribute='path') | list }}"

- name: run test cases (connection=network_cli)
  include: "{{ test_case_to_run }} ansible_connection=network_cli"
  with_items: "{{ test_items }}"
  loop_control:
    loop_var: test_case_to_run

- name: run test case (connection=local)
  include: "{{ test_case_to_run }} ansible_connection=local ansible_become=no"
  with_first_found: "{{ test_items }}"
  loop_control:
    loop_var: test_case_to_run

test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml

---
- debug:
 msg: START vyos_l3_interfaces merged integration tests on connection={{ ansible_connection
   }}

- include_tasks: _remove_config.yaml

- block:

 - include_tasks: _populate.yaml

 - name: Overrides all device configuration with provided configuration
   register: result
   vyos.vyos.vyos_l3_interfaces: &id001
     config:

       - name: eth0
         ipv4:

           - address: dhcp

       - name: eth1
         ipv4:

           - address: 192.0.2.15/24
     state: overridden

 - name: Assert that before dicts were correctly generated
   assert:
     that:
       - "{{ populate | symmetric_difference(result['before']) |length == 0 }}"

 - name: Assert that correct commands were generated
   assert:
     that:
       - "{{ overridden['commands'] | symmetric_difference(result['commands'])\
         \ |length == 0 }}"

 - name: Assert that after dicts were correctly generated
   assert:
     that:
       - "{{ overridden['after'] | symmetric_difference(result['after']) |length\
         \ == 0 }}"

 - name: Overrides all device configuration with provided configurations (IDEMPOTENT)
   register: result
   vyos.vyos.vyos_l3_interfaces: *id001

 - name: Assert that the previous task was idempotent
   assert:
     that:
       - result['changed'] == false

 - name: Assert that before dicts were correctly generated
   assert:
     that:
       - "{{ overridden['after'] | symmetric_difference(result['before']) |length\
         \ == 0 }}"
always:

 - include_tasks: _remove_config.yaml

Обнаружение тестовых ресурсов во время выполнения

Тесты должны обнаруживать ресурсы (например, интерфейсы) во время выполнения, а не жестко их кодировать в тесте. Это позволяет тесту работать на различных системах.

Например:

- name: Collect interface list
  connection: ansible.netcommon.network_cli
  register: intout
  cisco.nxos.nxos_command:
    commands:
      - show interface brief | json

- set_fact:
    intdataraw: "{{ intout.stdout_lines[0]['TABLE_interface']['ROW_interface'] }}"

- set_fact:
    nxos_int1: '{{ intdataraw[1].interface }}'

- set_fact:
    nxos_int2: '{{ intdataraw[2].interface }}'

- set_fact:
    nxos_int3: '{{ intdataraw[3].interface }}'

Полный пример такого теста см. по адресу https://github.com/ansible-collections/cisco.nxos/blob/master/tests/integration/targets/prepare_nxos_tests/tasks/main.yml.

Запуск сетевых интеграционных тестов

Ansible использует Zuul для запуска набора интеграционных тестов для каждого PR, включая новые тесты, добавленные в этом PR. Чтобы найти и исправить проблемы в сетевых модулях, запустите сетевой интеграционный тест локально перед отправкой PR.

Сначала создайте файл инвентаризации, указывающий на ваши тестовые машины. Группа инвентаризации должна соответствовать имени платформы (например, eos, ios):

cd test/integration
cp inventory.network.template inventory.networking
${EDITOR:-vi} inventory.networking
# Add in machines for the platform(s) you wish to test

Для запуска этих сетевых интеграционных тестов используйте ansible-test network-integration --inventory </path/to/inventory> <tests_to_run>:

ansible-test network-integration  --inventory ~/myinventory -vvv vyos_facts
ansible-test network-integration  --inventory ~/myinventory -vvv vyos_.*

Для запуска всех сетевых тестов для определенной платформы:

ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_.*

Этот пример запустит все модули vyos. Обратите внимание, что vyos_.* — это совпадение по регулярному выражению, а не символ подстановки bash — включите . при модификации этого примера.

Для запуска интеграционных тестов для определенного модуля:

ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces

Для запуска отдельного тестового случая для определенного модуля:

# Only run vyos_l3_interfaces/tests/cli/gathered.yaml
ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces --testcase gathered

Для запуска интеграционных тестов для определенного транспорта:

 # Only run nxapi test
ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking  --tags="nxapi" nxos_.*

# Skip any cli tests
 ansible-test network-integration --inventory  /path/to-collection-module/test/integration/inventory.networking  --skip-tags="cli" nxos_.*

См. test/integration/targets/nxos_bgp/tasks/main.yaml, как это реализовано в тестах.

Для получения дополнительных параметров:

ansible-test network-integration --help

Если вам нужна дополнительная помощь или отзывы, обратитесь в #ansible-network на Freenode.

Требования к тестированию модулей

Основные требования к тестированию модулей, которым должны следовать новые модули ресурсов:

1. Напишите тестовые случаи для всех состояний со всеми возможными комбинациями значений конфигурации.
2. Напишите тестовые случаи для проверки условий ошибок (отрицательные сценарии).
3. Проверьте значения ключей changed и commands в каждом тестовом случае.

Все тестовые случаи выполняются на нашем тестовом наборе Zuul, на последней версии Python, поддерживаемой нашей настройкой CI.

Используйте те же процедуры, что и для интеграционных тестов, для просмотра отчетов и журналов Zuul по тестам модулей.

См. тестирование модулей в едином стиле для общей информации о тестировании модулей.

Пример: Модульное тестирование модулей ресурсов сети Ansible

Этот раздел демонстрирует пример разработки модульных тестов для модулей ресурсов Ansible.

См. Модульные тесты и Модульное тестирование модулей Ansible для общей документации по модульным тестам Ansible для модулей. Пожалуйста, сначала прочитайте эти страницы, чтобы понять модульные тесты и почему и когда их следует использовать.

Использование эмулируемых объектов для модульного тестирования модулей ресурсов сети Ansible

Эмулируемые объекты могут быть очень полезны при создании модульных тестов для особых или сложных случаев, но они также могут привести к сложным и запутанным ситуациям программирования. Одно из хороших применений эмуляции — это имитация API. Пакет mock поставляется с Ansible (используйте import units.compat.mock).

Вы можете эмулировать подключение к устройству и вывод с устройства следующим образом:

self.mock_get_config = patch( "ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.get_config"
)
self.get_config = self.mock_get_config.start()

self.mock_load_config = patch(
"ansible_collections.ansible.netcommon.plugins.module_utils.network.common.network.Config.load_config"
)
self.load_config = self.mock_load_config.start()

self.mock_get_resource_connection_config = patch(
"ansible_collections.ansible.netcommon.plugins.module_utils.network.common.cfg.base.get_resource_connection"
)
self.get_resource_connection_config = (self.mock_get_resource_connection_config.start())

self.mock_get_resource_connection_facts = patch(
"ansible_collections.ansible.netcommon.plugins.module_utils.network.common.facts.facts.get_resource_connection"
)
self.get_resource_connection_facts = (self.mock_get_resource_connection_facts.start())

self.mock_edit_config = patch(
"ansible_collections.arista.eos.plugins.module_utils.network.eos.providers.providers.CliProvider.edit_config"
)
self.edit_config = self.mock_edit_config.start()

self.mock_execute_show_command = patch(
"ansible_collections.arista.eos.plugins.module_utils.network.eos.facts.l2_interfaces.l2_interfaces.L2_interfacesFacts.get_device_data"
)
self.execute_show_command = self.mock_execute_show_command.start()

Файл фактов модуля теперь содержит новый метод get_device_data. Вызовите get_device_data здесь для эмуляции вывода устройства.

Имитация данных устройства

Чтобы имитировать получение результатов от устройств или предоставлять другие сложные структуры данных, поступающие из внешних библиотек, можно использовать fixtures для чтения предварительно сгенерированных данных. Текстовые файлы для этих предварительно сгенерированных данных находятся в test/units/modules/network/PLATFORM/fixtures/. См., например, файл eos_l2_interfaces.cfg.

Загрузите данные с помощью метода load_fixture и установите эти данные в качестве возвращаемого значения метода get_device_data в файле фактов:

def load_fixtures(self, commands=None, transport='cli'):
    def load_from_file(*args, **kwargs):
        return load_fixture('eos_l2_interfaces_config.cfg')
    self.execute_show_command.side_effect = load_from_file

См. файл модульного теста test_eos_l2_interfaces для практического примера.