Поддержка сетевых операций

• Работа с сетевыми устройствами
• Установка сетевой автоматизации
• Доступные сетевые модули
• Подключение к сетевым устройствам
• Сетевые переменные среды
• Условные операторы в сетевых модулях

Работа с сетевыми устройствами

Начиная с версии Ansible 2.1, вы можете использовать знакомые модели Ansible для написания playbooks и разработки модулей для управления разнородными сетевыми устройствами. Ansible поддерживает всё большее количество сетевых устройств с использованием CLI по SSH и API (если доступно).

Установка сетевой автоматизации

• Установите последнюю версию Ansible здесь.

Доступные сетевые модули

Большинство стандартных модулей Ansible предназначены для работы с машинами Linux/Unix или Windows и не будут работать с сетевыми устройствами. Некоторые модули (включая «slurp», «raw» и «setup») являются независимыми от платформы и будут работать с сетевыми устройствами.

Чтобы узнать, какие модули доступны для сетевых устройств, пожалуйста, просмотрите “раздел «networking» в индексе модулей Ansible.

Подключение к сетевым устройствам

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

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

Каждый основной сетевой модуль поддерживает некоторые базовые аргументы для настройки передачи данных:

• host - определяет имя хоста или IP-адрес удалённого хоста
• port - определяет порт для подключения
• username - определяет имя пользователя для аутентификации подключения
• password - определяет пароль для аутентификации подключения
• transport - определяет тип транспортного протокола соединения
• authorize - включает повышение привилегий для устройств, которые этого требуют
• auth_pass - определяет пароль, если необходимо, для повышения привилегий

Отдельные модули могут установить значения по умолчанию для этих аргументов, соответствующие значениям по умолчанию в настройках устройства. Например, значение по умолчанию для transport — это «cli». Некоторые модули поддерживают другие значения, такие как EOS (eapi) и NXOS (nxapi), в то время как некоторые поддерживают только «cli». Все аргументы подробно документированы для каждого модуля.

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

Одним из недостатков этого подхода является то, что каждая задача должна включать необходимые аргументы. Вот где пригодится аргумент provider. Аргумент provider принимает ключевые аргументы и передает их задаче для назначения параметров подключения и аутентификации.

Два следующих конфигурационных модуля по существу идентичны (используя nxos_config) как пример, но это применимо ко всем основным сетевым модулям:

---
nxos_config:
   src: config.j2
   host: "{{ inventory_hostname }}"
   username: "{{ ansible_ssh_user }}"
   password: "{{ ansible_ssh_pass }}"
   transport: cli

---
vars:
   cli:
      host: "{{ inventory_hostname }}"
      username: "{{ ansible_ssh_user }}"
      password: "{{ ansible_ssh_pass }} "
      transport: cli


nxos_config:
   src: config.j2
   provider: "{{ cli }}"

Учитывая вышеупомянутые два эквивалентных примера, аргументы также могут использоваться для установления приоритета и значений по умолчанию. Рассмотрим следующий пример:

---
vars:
    cli:
       host: "{{ inventory_hostname }}"
       username: operator
       password: secret
       transport: cli

tasks:
- nxos_config:
   src: config.j2
   provider: "{{ cli }}"
   username: admin
   password: admin

В этом примере значения admin для username и admin для password переопределяют значения operator в cli[‘username’] и secret в cli[‘password’])

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

---
vars:
    cli:
       host: "{{ inventory_hostname }}"
       username: operator
       password: secret
       transport: cli

tasks:
  - nxos_config:
      src: config.j2
      provider: "{{ cli }}"
      transport: nxapi

Если все значения предоставлены через аргумент provider, правила требований всё ещё соблюдаются для модуля. Например, рассмотрите следующую ситуацию:

---
vars:
  conn:
     password: cisco_pass
     transport: cli

tasks:
- nxos_config:
  src: config.j2
  provider: "{{ conn }}"

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

"msg": "missing required arguments: username,host"

В целом, это предоставляет очень точный контроль над тем, как используются учётные данные с модулями. Это даёт разработчику playbooks максимальный контроль над изменением контекста во время выполнения playbook по мере необходимости.

Сетевые переменные среды

Для сетевых модулей Ansible доступны следующие переменные среды:

username ANSIBLE_NET_USERNAME

password ANSIBLE_NET_PASSWORD

ssh_keyfile ANSIBLE_NET_SSH_KEYFILE

authorize ANSIBLE_NET_AUTHORIZE

auth_pass ANSIBLE_NET_AUTH_PASS

Переменные оцениваются в следующем порядке, от низшего к высшему приоритету:

• Значение по умолчанию
• Переменная среды
• Provider
• Аргументы задачи

Условные операторы в сетевых модулях

Ansible позволяет использовать условные операторы для управления потоком playbooks. Сетевые командные модули Ansible используют следующие уникальные условные операторы.

• eq - Равно
• neq - Не равно
• gt - Больше
• ge - Больше или равно
• lt - Меньше
• le - Меньше или равно
• contains - Объект содержит указанный элемент

Условные операторы оценивают результаты команд, выполняемых удалённо на устройстве. После выполнения задачи набора команд, аргумент waitfor может использоваться для оценки результатов перед возвратом управления Ansible playbook.

Например:

---
- name: wait for interface to be admin enabled
  eos_command:
      commands:
          - show interface Ethernet4 | json
      waitfor:
          - "result[0].interfaces.Ethernet4.interfaceStatus eq connected"

В задаче выше команда show interface Ethernet4 | json выполняется на удалённом устройстве, и результаты оцениваются. Если путь (result[0].interfaces.Ethernet4.interfaceStatus) не равен “connected”, то команда повторяется. Этот процесс продолжается до тех пор, пока условие не будет выполнено или количество попыток не истечёт (по умолчанию это 10 попыток с интервалом в 1 секунду).

Модуль commands также может оценивать несколько наборов результатов команд на интерфейсе. Например:

---
- name: wait for interfaces to be admin enabled
  eos_command:
      commands:
          - show interface Ethernet4 | json
          - show interface Ethernet5 | json
      waitfor:
          - "result[0].interfaces.Ethernet4.interfaceStatus eq connected"
          - "result[1].interfaces.Ethernet4.interfaceStatus eq connected"

В приведённом выше примере выполняются две команды на удалённом устройстве, и результаты оцениваются. Указав значение индекса результата (0 или 1), проверяется корректный выходной результат относительно условного оператора.

Аргумент waitfor всегда должен начинаться с result и затем с индексом команды в [], где 0 — это первая команда в списке команд, 1 — вторая команда, 2 — третья и так далее.