Как отличается автоматизация сети

Автоматизация сети использует базовые концепции Ansible, но существуют важные различия в работе модулей сети. Это введение поможет вам понять упражнения в этом руководстве.

• Выполнение на управляющем узле
• Несколько протоколов связи
• Модули, организованные по платформам сети
• Масштабирование привилегий: authorize и become

Выполнение на управляющем узле

В отличие от большинства модулей Ansible, модули сети не выполняются на управляемых узлах. С точки зрения пользователя, модули сети работают как любые другие модули. Они работают с разовыми командами, плейбуками и ролями. Однако за кулисами модули сети используют другую методологию, чем другие модули (Linux/Unix и Windows). Ansible написан и выполняется на Python. Поскольку большинство сетевых устройств не могут запускать Python, модули сети Ansible выполняются на управляющем узле Ansible, где выполняется ansible или ansible-playbook.

Выполнение на управляющем узле определяет два других различия в работе модулей сети:

• Модули сети не выполняют каждую задачу в плейбуке. Сначала запрашивается текущая конфигурация, текущая конфигурация сравнивается с состоянием, описанным в задаче или плейбуке, и задача выполняется только в том случае, если она изменяет состояние управляемого узла.
• Модули сети, которые предлагают резервную копию, записывают резервные файлы на управляющий узел. В модулях Linux/Unix, где файл конфигурации уже существует на управляемом узле(ах), резервный файл по умолчанию записывается в ту же директорию, что и новый, измененный файл. Модули сети не обновляют файлы конфигурации на управляемых узлах, потому что сетевая конфигурация не записывается в файлы. Модули сети записывают резервные файлы на управляющий узел, в директорию backup в корневом каталоге плейбука.

Несколько протоколов связи

Поскольку модули сети выполняются на управляющем узле, а не на управляемых узлах, они могут поддерживать несколько протоколов связи. Протокол связи (XML по SSH, CLI по SSH, API по HTTPS), выбранный для каждого модуля сети, зависит от платформы и назначения модуля. Некоторые модули сети поддерживают только один протокол; некоторые предлагают выбор. Наиболее распространенный протокол — CLI по SSH. Вы устанавливаете протокол связи с помощью переменной ansible_connection.

Начиная с Ansible 2.5, мы рекомендуем использовать network_cli или netconf для ansible_connection всякий раз, когда это возможно. Подробную информацию об использовании подключений API по HTTPS см. на страницах специфичных для платформы.

Модули, организованные по платформам сети

Платформа сети — это набор сетевых устройств с общей операционной системой, которые можно управлять с помощью набора модулей. Модули для каждой платформы сети имеют общий префикс, например:

• Arista: eos_
• Cisco: ios_, iosxr_, nxos_
• Juniper: junos_
• VyOS vyos_

Все модули одной сетевой платформы имеют определенные требования. У некоторых сетевых платформ есть специфические различия — см. документацию специфичную для платформы для получения подробной информации.

Масштабирование привилегий: authorize и become

Несколько сетевых платформ поддерживают масштабирование привилегий, где определенные задачи должны выполняться привилегированным пользователем. Это обычно известно как режим enable (аналог режима sudo в администрировании *nix). Модули сети Ansible предлагают масштабирование привилегий для тех сетевых устройств, которые его поддерживают. Однако разные платформы используют масштабирование привилегий по-разному.

Платформы сети, которые поддерживают connection: network_cli и масштабирование привилегий, используют верхнеуровневый параметр Ansible become: yes с become_method: enable. Для модулей на этих платформах файл group_vars будет выглядеть так:

ansible_connection: network_cli
ansible_network_os: ios
ansible_become: yes
ansible_become_method: enable

Мы рекомендуем использовать network_cli соединения всякий раз, когда это возможно.

Некоторые сетевые платформы поддерживают масштабирование привилегий, но пока не могут использовать network_cli соединения. Это включает все платформы в более старых версиях Ansible (< 2.5) и подключения HTTPS, использующие eapi в версии 2.5. С этими подключениями вы должны использовать словарь provider и включить authorize: yes и auth_pass: my_enable_password. В этом случае файл group_vars выглядит так:

ansible_connection: local
ansible_network_os: eos
# provider settings
eapi:
  authorize: yes
  auth_pass: " {{ secret_auth_pass }}"
  port: 80
  transport: eapi
  use_ssl: no

И вы используете переменную eapi в вашем плейбуке(ах) или задаче(ях):

tasks:
- name: provider demo with eos
  eos_banner:
    banner: motd
    text: |
      this is test
      of multiline
      string
    state: present
    provider: "{{ eapi }}"

Для получения более подробной информации см. Статус и сети