Новые возможности автоматизации сети в Red Hat Ansible

    В свете значительных усовершенствований, реализованных в Ansible Engine 2.6, а также с учетом выхода Ansible Tower 3.3 и недавнего выпуска Ansible Engine 2.7, рассмотрим подробнее перспективы автоматизации сетей.



    В этом посте:

    • Плагин подключения 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 можно найти в документации.
    Red Hat
    90,00
    Программные решения с открытым исходным кодом
    Поделиться публикацией

    Комментарии 0

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

    Самое читаемое