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

• Понимание модулей сетевых и информационных ресурсов

• Разработка модулей сетевых и информационных ресурсов

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

• Примеры

  • Структура каталога коллекции
  • Структура каталога роли
  • Использование коллекции
  • Использование роли
• Структура и рабочий процесс модуля ресурсов
• Запуск 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, либо коллекции.
• Последующее использование конструктора модулей ресурсов заменит только арспек модуля и файл, содержащий строку документации модуля.
• Позволяет хранить сложные примеры рядом с моделью в одном каталоге.
• Поддерживает модель как источник истины для модуля и использует конструктор модулей ресурсов для обновления исходных файлов по мере необходимости.
• Генерирует рабочие образцы модулей для <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.0'
        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: interfaces

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: interfaces

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

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

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

----
- 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

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

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

- 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.
• Сравнивает собранные факты и заданные значения ключей, если разницы не поддерживается.
• Генерирует окончательную конфигурацию.

Утилиты

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

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

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

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

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

• setup —> test —> assert —> повторный test (для идемпотентности) —> assert —> разборка (при необходимости) -> готово. Это предотвращает превращение книг задач тестов в монолитные и сложные для отладки.
• Включите имя для каждой задачи, которая не является утверждением. Вы можете добавить имена к утверждениям тоже, но легче определить сломанную задачу в не пройденном тесте, если вы добавите имя для каждой задачи.
• Файлы, содержащие тестовые случаи, должны заканчиваться на .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.

См. тестирование модулей unit для получения общей информации о модульных тестах.

Пример: Тестирование модулей 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 для практического примера.