В свете значительных усовершенствований, реализованных в Ansible Engine 2.6, а также с учетом выхода Ansible Tower 3.3 и недавнего выпуска Ansible Engine 2.7, рассмотрим подробнее перспективы автоматизации сетей.
В этом посте:
Не забывайте, что выход каждой новой версии Ansible сопровождается обновлением руководства по портированию, которое значительно облегчит вам переход на новую версию.
Плагины подключения (connection plugins) – это то, что позволяет Ansible подключаться к целевым хостам, чтобы затем выполнять на них задачи. Начиная с версии Ansible 2.5 появился новый плагин такого типа, который называется network_cli. Он избавляет от необходимости использовать параметр provider и стандартизует порядок выполнения сетевых модулей, в результате чего плейбуки для сетевых устройств теперь оформляются, выполняются и работают точно так же, как и плейбуки для Linux-хостов. В свою очередь, для Ansible Tower исчезает разница между сетевыми устройствами и хостами, и ему больше не надо различать логины-пароли для сетевых устройств и для машин. Подробнее это разбиралось здесь, но если вкратце, то логины-пароли для Linux-сервера и коммутатора Arista EOS или маршрутизатор Cisco теперь можно использовать и хранить аналогичным образом.
В Ansible 2.5 подключаться через методы eAPI и NX-API можно было только с помощью старого метода provider. В Ansible 2.6 этого ограничения больше нет и можно свободно использовать высокоуровневый метод подключения httpapi. Давайте посмотрим, как это делается.
Вначале надо включить eAPI или NX-API на сетевом устройстве, чтобы затем можно было использовать метод httpapi. Это легко делается соответствующей командой Ansible, например, вот как включить eAPI на коммутаторе Arista EOS.
При подключении к реальному коммутатору Arista EOS команда show management api http-commands покажет, что API включен:
Приведенный ниже сценарий Ansible Playbook просто выполняет команду show version, а затем в секции debug возвращает только версию из JSON-вывода задачи.
Запуск это сценария приведет к следующему результату:
ПРИМЕЧАНИЕ: Arista eAPI не поддерживает сокращенные версии команд (типа «show ver» вместо «show version2), поэтому приходится писать их полностью. Дополнительные сведения о плагине подключения httpapi можно найти в документации.
Ansible 2.6 и вышедшая в октябре версия 2.7 предлагают семь новых модулей для автоматизации сети.
Модули net_get и net_put не привязаны к оборудованию какого-то конкретного производителя и просто копируют файлы с сетевого устройства и на устройства, используя стандартные протоколы передачи SCP или SFTP (задается параметром protocol). Оба этих модуля требуют использования метода подключения network_cli, а также работают, только если на контроллере установлен scp (pip install scp), а на сетевом устройства включен SCP или SFTP.
Будем считать, что в примере с нашим плейбуком, мы уже выполнили следующую команду на устройстве Leaf01:
Вот как выглядит плейбук с двумя задачами (первая копирует файл с устройства Leaf01, а вторая копирует файл на устройство Leaf01):
Сетевой протокол управления NETCONF (Network Configuration Protocol) разработан и стандартизован IETF. Согласно RFC 6241, NETCONF может использоваться для установки, манипулирования и удаления конфигураций сетевых устройств. NETCONF – это альтернатива командной строке SSH (network_cli) и API-интерфейсам наподобие Cisco NX-API или Arista eAPI (httpapi).
Для демонстрации новых модулей netconf мы вначале включим netconf на маршрутизаторах Juniper с помощью модуля junos_netconf. Netconf поддерживается не всех моделях сетевого оборудования, поэтому прежде чем его использовать, сверьтесь с документацией.
Juniper Networks предлагает Junos XML API Explorer для Operational Tags и для Configuration Tags. Рассмотрим пример операционного запроса, который Juniper Networks использует в своей документации иллюстрации RPC-запроса конкретного интерфейса.
Это легко транслируется на язык Ansible Playbook. get-interface-information – это RPC-вызов, а дополнительные параметры задаются как пары ключ-значение. В этом примере есть только один параметр – interface-name – и на нашем сетевом устройстве мы просто хотим посмотреть em1.0. Мы используем заданный ну ровне задачи параметр register, просто чтобы сохранить результаты, поэтому используем модуль debug и выводим результаты на экран терминала. Модуль netconf_rpc также позволяет транслировать XML-вывод прямо в JSON.
После запуска плейбука получим вот что:
Дополнительные сведения можно найти в Juniper Platform Guide и в документации по NETCONF.
Появившиеся в Ansible Engine 2.7 модули cli_command и cli_config также не привязаны к оборудованию какого-то конкретного производителя и могут применяться для автоматизации различных сетевых платформ. Они отталкиваются от значения переменной ansible_network_os (задается в файле inventory или в папке group_vars), чтобы использовать нужный плагин cliconf. Список всех значений переменной ansible_network_os приводится в документации. В этой версии Ansible по-прежнему можно использовать и старые модули для конкретных платформ, так что не торопитесь переписывать имеющие плейбуки. Дополнительные сведения можно найти в oфициальных руководствах по портированию.
Давайте посмотрим, как эти модули используются в Ansible Playbook. Этот плейбук будет запускаться на двух системах Cisco Cloud Services Routers (CSR) под управлением IOS-XE. Для переменной ansible_network_os в файле inventory задано значение ios.
Вот как используются cli_config и cli_command:
А вот вывод этого плейбука:
Обратите внимание, что эти модули являются идемпотентыми до тех пор, пока вы используете соответствующий синтаксис для соответствующих сетевых устройств.
Веб-интерфейс в Red Hat Ansible Tower 3.3 стал удобнее и функциональнее, позволяя меньше щелкать мышкой при выполнении различных задач.
Управление учетными данными, планировщик заданий, сценарии инвентаризации, управление доступом на основе ролей, уведомления и многое другое теперь собраны в главном меню в левой части экрана и доступны в один клик. Экран просмотра заданий Jobs View сразу отображает важную дополнительную информацию: кто и когда запускал задание; какие inventory отрабатывались в ходе его выполнения; из какого проекта был взят плейбук.
В Red Hat Ansible Tower 3.3 стало гораздо проще управлять логинами-паролями для сетевых устройств. В новом веб-интерфейсе команда Credentials расположена сразу в главном меню, в группе Resources.
В Ansible Tower 3.3 остался специальный, так называемый «сетевой» тип учетных данных (Network), который задает переменные среды ANSIBLE_NET_USERNAME и ANSIBLE_NET_PASSWORD, используемые в старом методе provider. Все это по-прежнему работает, как написано в документации, чтобы можно было использовать уже имеющиеся сценарии Ansible Playbooks, Однако для новых высокоуровневых методов подключения httpapi и network_cli сетевой тип учетных данных больше не нужен, поскольку теперь Ansible одинаково работает с логинами-паролями как при подключении к сетевым устройствам, так и что при подключении к Linxu-хостам. Поэтому для сетевых устройств теперь надо выбирать тип учетных данных Machine – просто выбираете его и вводите логин-пароль или предоставляете ключ SSH.
ПРИМЕЧАНИЕ: Ansible Tower шифрует пароль сразу после того, как вы сохраняете учетные данные.
Благодаря шифрованию учетные данные можно безопасно делегировать другим пользователям и группам – они просто не увидят и не узнают пароль. Дополнительные сведения о том, как работают учетные данные, какое шифрование при этом применяется, какие еще есть типы учетных данных (типа Amazon AWS, Microsoft Azure и Google GCE) можно найти в документации по Ansible Tower.
Более подробное описание Red Hat Ansible Tower 3.3 можно найти здесь.
Допустим, мы хотим, чтобы одни плейбуки выполнялись через Ansible Engine 2.4.2, а другие – через Ansible Engine 2.6.4. В Tower есть для этого специальный инструмент virtualenv для создания изолированных сред Python во избежание проблем с конфликтующими зависимостями и отличающимися версиями. Ansible Tower 3.3 позволяет задавать virtualenv на разных уровнях – Organization, Project или Job Template. Вот как выглядит Job Template, который мы создали в Ansible Tower для резервного копирования нашей сети.
Когда у вас есть хотя бы две виртуальные среды, то в главном меню Ansible Tower появляется раскрывающее меню Ansible Environment, где можно легко задать, какая версия Ansible должна использоваться при выполнении задания.
Поэтому, если у вас есть микс из плейбуков для автоматизации сети, часть из которых использует старый метод provider (Ansible 2.4 и предыдущие версии), а часть – новые плагины httpapi или network_cli (Ansible 2.5 и выше), вы можете легко назначить каждому заданию необходимую версию Ansible. Кроме того, эта возможность будет полезна, если разработчики и продакшн используют разные версии Ansible. Иначе говоря, вы можете спокойно обновлять Tower, не беспокоясь, что после этого придется переходить на какую-то одну версию Ansible Engine, что сильно повышает гибкость при автоматизации различных типов сетевого оборудования и сред, а также сценариев использования.
Дополнительные сведения по использованию virtualenv можно найти в документации.
В этом посте:
- Плагин подключения httpapi.
- Поддержка Arista eAPI и Cisco NX-API.
- Новые модули сетевой автоматизации.
- net_get и net_put.
- netconf_get, netconf_rpc и netconf_config.
- cli_command и cli_config.
- Улучшенный веб-интерфейс Ansible Tower.
- Управление учетными данными в Ansible Tower при работе с сетевыми устройствам.
- Одновременное использование различных версий Ansible в Tower
Не забывайте, что выход каждой новой версии Ansible сопровождается обновлением руководства по портированию, которое значительно облегчит вам переход на новую версию.
Плагин подключения HTTPAPI
Плагины подключения (connection plugins) – это то, что позволяет Ansible подключаться к целевым хостам, чтобы затем выполнять на них задачи. Начиная с версии Ansible 2.5 появился новый плагин такого типа, который называется network_cli. Он избавляет от необходимости использовать параметр provider и стандартизует порядок выполнения сетевых модулей, в результате чего плейбуки для сетевых устройств теперь оформляются, выполняются и работают точно так же, как и плейбуки для Linux-хостов. В свою очередь, для Ansible Tower исчезает разница между сетевыми устройствами и хостами, и ему больше не надо различать логины-пароли для сетевых устройств и для машин. Подробнее это разбиралось здесь, но если вкратце, то логины-пароли для Linux-сервера и коммутатора Arista EOS или маршрутизатор Cisco теперь можно использовать и хранить аналогичным образом.
В Ansible 2.5 подключаться через методы eAPI и NX-API можно было только с помощью старого метода provider. В Ansible 2.6 этого ограничения больше нет и можно свободно использовать высокоуровневый метод подключения httpapi. Давайте посмотрим, как это делается.
Вначале надо включить eAPI или NX-API на сетевом устройстве, чтобы затем можно было использовать метод httpapi. Это легко делается соответствующей командой Ansible, например, вот как включить eAPI на коммутаторе Arista EOS.
[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01
leaf01 | SUCCESS => {
"ansible_facts": {
"eos_eapi_urls": {
"Ethernet1": [
"https://192.168.0.14:443"
],
"Management1": [
"https://10.0.2.15:443"
]
}
},
"changed": false,
"commands": []
}
При подключении к реальному коммутатору Arista EOS команда show management api http-commands покажет, что API включен:
leaf01# show management api http-commands
Enabled: Yes
HTTPS server: running, set to use port 443
<<<rest of output removed for brevity>>>
Приведенный ниже сценарий Ansible Playbook просто выполняет команду show version, а затем в секции debug возвращает только версию из JSON-вывода задачи.
---
- hosts: leaf01
connection: httpapi
gather_facts: false
tasks:
- name: type a simple arista command
eos_command:
commands:
- show version | json
register: command_output
- name: print command output to terminal window
debug:
var: command_output.stdout[0]["version"]
Запуск это сценария приведет к следующему результату:
[user@rhel7]$ ansible-playbook playbook.yml
PLAY [leaf01]********************************************************
TASK [type a simple arista command] *********************************
ok: [leaf01]
TASK [print command output to terminal window] **********************
ok: [leaf01] => {
"command_output.stdout[0][\"version\"]": "4.20.1F"
}
PLAY RECAP***********************************************************
leaf01 : ok=2 changed=0 unreachable=0 failed=0
ПРИМЕЧАНИЕ: Arista eAPI не поддерживает сокращенные версии команд (типа «show ver» вместо «show version2), поэтому приходится писать их полностью. Дополнительные сведения о плагине подключения httpapi можно найти в документации.
Новые модули автоматизации сети
Ansible 2.6 и вышедшая в октябре версия 2.7 предлагают семь новых модулей для автоматизации сети.
- net_get – копирует файл с сетевого устройства на Ansible Controller.
- net_put – копирует файл из Ansible Controller на сетевое устройство.
- netconf_get – извлекает конфигурацию/данные о состоянии из сетевого устройства с включенным NETCONF.
- netconf_rpc – выполняет операции на сетевом устройства с включенным NETCONF.
- netconf_config – конфигурация устройства netconf, модуль позволяет пользователю отправить XML-файл на устройства netconf и проверить, изменилась ли конфигурация.
- cli_command – запускает команду cli на сетевых устройствах, имеющих интерфейс командной (cli).
- cli_config – отправляет (push) текстовую конфигурацию на сетевые устройства через network_cli.
net_get и net_put
- net_get – копирует файл с сетевого устройства на Ansible Controller.
- net_put – копирует файл из Ansible Controller на сетевое устройство.
Модули net_get и net_put не привязаны к оборудованию какого-то конкретного производителя и просто копируют файлы с сетевого устройства и на устройства, используя стандартные протоколы передачи SCP или SFTP (задается параметром protocol). Оба этих модуля требуют использования метода подключения network_cli, а также работают, только если на контроллере установлен scp (pip install scp), а на сетевом устройства включен SCP или SFTP.
Будем считать, что в примере с нашим плейбуком, мы уже выполнили следующую команду на устройстве Leaf01:
leaf01#copy running-config flash:running_cfg_eos1.txt
Copy completed successfully.
Вот как выглядит плейбук с двумя задачами (первая копирует файл с устройства Leaf01, а вторая копирует файл на устройство Leaf01):
---
- hosts: leaf01
connection: network_cli
gather_facts: false
tasks:
- name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER
net_get:
src: running_cfg_eos1.txt
- name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE
net_put:
src: temp.txt
netconf_get, netconf_rpc и netconf_config
- netconf_get – извлекает конфигурацию/данные о состоянии из сетевого устройства с включенным NETCONF.
- netconf_rpc – выполняет операции на сетевом устройства с включенным NETCONF.
- netconf_config – конфигурация устройства netconf, модуль позволяет пользователю отправить XML-файл на устройства netconf и проверить, изменилась ли конфигурация.
Сетевой протокол управления NETCONF (Network Configuration Protocol) разработан и стандартизован IETF. Согласно RFC 6241, NETCONF может использоваться для установки, манипулирования и удаления конфигураций сетевых устройств. NETCONF – это альтернатива командной строке SSH (network_cli) и API-интерфейсам наподобие Cisco NX-API или Arista eAPI (httpapi).
Для демонстрации новых модулей netconf мы вначале включим netconf на маршрутизаторах Juniper с помощью модуля junos_netconf. Netconf поддерживается не всех моделях сетевого оборудования, поэтому прежде чем его использовать, сверьтесь с документацией.
[user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli
rtr4 | CHANGED => {
"changed": true,
"commands": [
"set system services netconf ssh port 830"
]
}
rtr3 | CHANGED => {
"changed": true,
"commands": [
"set system services netconf ssh port 830"
]
}
Juniper Networks предлагает Junos XML API Explorer для Operational Tags и для Configuration Tags. Рассмотрим пример операционного запроса, который Juniper Networks использует в своей документации иллюстрации RPC-запроса конкретного интерфейса.
<rpc>
<get-interface-information>
<interface-name>ge-2/3/0</interface-name>
<detail/>
</get-interface-information>
</rpc>
]]>]]>
Это легко транслируется на язык Ansible Playbook. get-interface-information – это RPC-вызов, а дополнительные параметры задаются как пары ключ-значение. В этом примере есть только один параметр – interface-name – и на нашем сетевом устройстве мы просто хотим посмотреть em1.0. Мы используем заданный ну ровне задачи параметр register, просто чтобы сохранить результаты, поэтому используем модуль debug и выводим результаты на экран терминала. Модуль netconf_rpc также позволяет транслировать XML-вывод прямо в JSON.
---
- name: RUN A NETCONF COMMAND
hosts: juniper
gather_facts: no
connection: netconf
tasks:
- name: GET INTERFACE INFO
netconf_rpc:
display: json
rpc: get-interface-information
content:
interface-name: "em1.0"
register: netconf_info
- name: PRINT OUTPUT TO TERMINAL WINDOW
debug:
var: netconf_info
После запуска плейбука получим вот что:
ok: [rtr4] => {
"netconf_info": {
"changed": false,
"failed": false,
"output": {
"rpc-reply": {
"interface-information": {
"logical-interface": {
"address-family": [
{
"address-family-flags": {
"ifff-is-primary": ""
},
"address-family-name": "inet",
"interface-address": [
{
"ifa-broadcast": "10.255.255.255",
"ifa-destination": "10/8",
"ifa-flags": {
"ifaf-current-preferred": ""
},
"ifa-local": "10.0.0.4"
},
<<<rest of output removed for brevity>>>
Дополнительные сведения можно найти в Juniper Platform Guide и в документации по NETCONF.
cli_command и cli_config
- cli_command – запускает команду на сетевых устройствах, используя их интерфейс командной строки (если такой там есть).
- cli_config – отправляет (push) текстовую конфигурацию на сетевые устройства через network_cli.
Появившиеся в Ansible Engine 2.7 модули cli_command и cli_config также не привязаны к оборудованию какого-то конкретного производителя и могут применяться для автоматизации различных сетевых платформ. Они отталкиваются от значения переменной ansible_network_os (задается в файле inventory или в папке group_vars), чтобы использовать нужный плагин cliconf. Список всех значений переменной ansible_network_os приводится в документации. В этой версии Ansible по-прежнему можно использовать и старые модули для конкретных платформ, так что не торопитесь переписывать имеющие плейбуки. Дополнительные сведения можно найти в oфициальных руководствах по портированию.
Давайте посмотрим, как эти модули используются в Ansible Playbook. Этот плейбук будет запускаться на двух системах Cisco Cloud Services Routers (CSR) под управлением IOS-XE. Для переменной ansible_network_os в файле inventory задано значение ios.
<config snippet from inventory>
[cisco]
rtr1 ansible_host=34.203.197.120
rtr2 ansible_host=34.224.60.230
[cisco:vars]
ansible_ssh_user=ec2-user
ansible_network_os=ios
Вот как используются cli_config и cli_command:
---
- name: AGNOSTIC PLAYBOOK
hosts: cisco
gather_facts: no
connection: network_cli
tasks:
- name: CONFIGURE DNS
cli_config:
config: ip name-server 8.8.8.8
- name: CHECK CONFIGURATION
cli_command:
command: show run | i ip name-server
register: cisco_output
- name: PRINT OUTPUT TO SCREEN
debug:
var: cisco_output.stdout
А вот вывод этого плейбука:
[user@rhel7 ~]$ ansible-playbook cli.yml
PLAY [AGNOSTIC PLAYBOOK] *********************************************
TASK [CONFIGURE DNS] *************************************************
ok: [rtr1]
ok: [rtr2]
TASK [CHECK CONFIGURATION] *******************************************
ok: [rtr1]
ok: [rtr2]
TASK [PRINT OUTPUT TO SCREEN] ****************************************
ok: [rtr1] => {
"cisco_output.stdout": "ip name-server 8.8.8.8"
}
ok:
[rtr2] => {
"cisco_output.stdout": "ip name-server 8.8.8.8"
}
PLAY RECAP **********************************************************
rtr1 : ok=3 changed=0 unreachable=0 failed=0
rtr2 : ok=3 changed=0 unreachable=0 failed=0
Обратите внимание, что эти модули являются идемпотентыми до тех пор, пока вы используете соответствующий синтаксис для соответствующих сетевых устройств.
Улучшенный интерфейс Ansible Tower
Веб-интерфейс в Red Hat Ansible Tower 3.3 стал удобнее и функциональнее, позволяя меньше щелкать мышкой при выполнении различных задач.
Управление учетными данными, планировщик заданий, сценарии инвентаризации, управление доступом на основе ролей, уведомления и многое другое теперь собраны в главном меню в левой части экрана и доступны в один клик. Экран просмотра заданий Jobs View сразу отображает важную дополнительную информацию: кто и когда запускал задание; какие inventory отрабатывались в ходе его выполнения; из какого проекта был взят плейбук.
Управление учетными данными для сетевых устройств в Ansible Tower
В Red Hat Ansible Tower 3.3 стало гораздо проще управлять логинами-паролями для сетевых устройств. В новом веб-интерфейсе команда Credentials расположена сразу в главном меню, в группе Resources.
В Ansible Tower 3.3 остался специальный, так называемый «сетевой» тип учетных данных (Network), который задает переменные среды ANSIBLE_NET_USERNAME и ANSIBLE_NET_PASSWORD, используемые в старом методе provider. Все это по-прежнему работает, как написано в документации, чтобы можно было использовать уже имеющиеся сценарии Ansible Playbooks, Однако для новых высокоуровневых методов подключения httpapi и network_cli сетевой тип учетных данных больше не нужен, поскольку теперь Ansible одинаково работает с логинами-паролями как при подключении к сетевым устройствам, так и что при подключении к Linxu-хостам. Поэтому для сетевых устройств теперь надо выбирать тип учетных данных Machine – просто выбираете его и вводите логин-пароль или предоставляете ключ SSH.
ПРИМЕЧАНИЕ: Ansible Tower шифрует пароль сразу после того, как вы сохраняете учетные данные.
Благодаря шифрованию учетные данные можно безопасно делегировать другим пользователям и группам – они просто не увидят и не узнают пароль. Дополнительные сведения о том, как работают учетные данные, какое шифрование при этом применяется, какие еще есть типы учетных данных (типа Amazon AWS, Microsoft Azure и Google GCE) можно найти в документации по Ansible Tower.
Более подробное описание Red Hat Ansible Tower 3.3 можно найти здесь.
Одновременное использование различных версий Ansible в Tower
Допустим, мы хотим, чтобы одни плейбуки выполнялись через Ansible Engine 2.4.2, а другие – через Ansible Engine 2.6.4. В Tower есть для этого специальный инструмент virtualenv для создания изолированных сред Python во избежание проблем с конфликтующими зависимостями и отличающимися версиями. Ansible Tower 3.3 позволяет задавать virtualenv на разных уровнях – Organization, Project или Job Template. Вот как выглядит Job Template, который мы создали в Ansible Tower для резервного копирования нашей сети.
Когда у вас есть хотя бы две виртуальные среды, то в главном меню Ansible Tower появляется раскрывающее меню Ansible Environment, где можно легко задать, какая версия Ansible должна использоваться при выполнении задания.
Поэтому, если у вас есть микс из плейбуков для автоматизации сети, часть из которых использует старый метод provider (Ansible 2.4 и предыдущие версии), а часть – новые плагины httpapi или network_cli (Ansible 2.5 и выше), вы можете легко назначить каждому заданию необходимую версию Ansible. Кроме того, эта возможность будет полезна, если разработчики и продакшн используют разные версии Ansible. Иначе говоря, вы можете спокойно обновлять Tower, не беспокоясь, что после этого придется переходить на какую-то одну версию Ansible Engine, что сильно повышает гибкость при автоматизации различных типов сетевого оборудования и сред, а также сценариев использования.
Дополнительные сведения по использованию virtualenv можно найти в документации.