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

Автоматизация сетей использует базовые концепции 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, это использование будет устаревшим в будущих версиях и в конечном итоге будет удалено.

Для получения дополнительной информации см. Масштабирование привилегий и сети