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

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

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

Выполнение на контрольном узле

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

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

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

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

Начиная с Ansible 2.6, рекомендуется использовать один из перечисленных выше типов постоянного подключения вместо local. С постоянными подключениями вы можете определить хосты и учетные данные только один раз, а не в каждой задаче. Более подробные сведения о применении каждого типа подключения на различных платформах см. на страницах специфичных для платформы.

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

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

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

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

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

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

Использование become для повышения привилегий

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

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

Устаревшие плейбуки: authorize для повышения привилегий

Если вы используете Ansible 2.5 или более раннюю версию, некоторые сетевые платформы поддерживают повышение привилегий, но не network_cli или httpapi подключения. Это включает все платформы в версиях 2.4 и более ранних, и подключения HTTPS, использующие eapi в версии 2.5. С local подключением вы должны использовать словарь 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 }}"

Обратите внимание, что, хотя Ansible 2.6 поддерживает использование connection: local с provider словарями, это использование будет устаревать в будущем и в конечном итоге будет удалено.

Дополнительную информацию см. в Раздел «Become и сети»